SISTEMA DE GESTIÓN

DE COMPRAS, INVENTARIO Y VENTAS

PARA LA EMPRESA TECNO PC SYSTEM

CHRISTIAN OCAMPO GÓMEZ

SEÑORES
COMITÉ CURRICULAR

UNIVERSIDAD CATÓLICA DE PEREIRA

FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍAS
INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
2016
 SISTEMA DE GESTIÓN
DE COMPRAS, INVENTARIO Y VENTAS
PARA LA EMPRESA TECNO PC SYSTEM

CHRISTIAN OCAMPO GÓMEZ

ASESORA

DIANA CAROLINA LÓPEZ LÓPEZ

PROYECTO DE GRADO PARA OPTAR POR EL TÍTULO DE INGENIERO DE

SISTEMAS Y TELECOMUNICACIONES

UNIVERSIDAD CATÓLICA DE PEREIRA

FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍAS
INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES
2016
 AGRADECIMIENTOS

Primero quiero agradecerle a Dios por permitirme realizar esta meta tan
importante en mi vida, a mi esposa e hija por su apoyo y comprensión durante
todo este proceso, a mis padres y a mi hermana. Gracias a ellos es que esto se
ha hecho realidad.

A la Universidad Católica de Pereira por su apoyo incondicional y por supuesto

a todos mis profesores y tutores.

Espero que este proyecto sirva de apoyo a nuevos estudiantes que buscan
superarse y crecer como personas.
 TABLA DE CONTENIDO

TABLA DE CONTENIDO ..................................................................................... 4

TABLA DE ILUSTRACIONES ........................................................................... 10
RESUMEN ......................................................................................................... 12
1. INTRODUCCIÓN .......................................................................................... 1
2. OBJETIVOS .................................................................................................. 2
2.1. OBJETIVO GENERAL .............................................................................. 2
2.2. OBJETIVO ESPECÍFICO. ......................................................................... 2
3. DELIMITACIÓN Y ALCANCES DEL PROYECTO ....................................... 3
3.1. DELIMITACIÓN DE TIEMPO Y ESPACIO ............................................ 3
3.2. DELIMITACIÓN DEL ESPACIO ............................................................. 3
3.3. POBLACIÓN Y MUESTRA .................................................................... 3
3.4. ALCANCES ............................................................................................ 3
4. APORTE TEÓRICO PRÁCTICO .................................................................. 4
5. SITUACIÓN PROBLEMÁTICA ..................................................................... 5
6. MARCO CONTEXTUAL ............................................................................... 6
6.1. TECNO PC SYSTEM ............................................................................. 6
6.1.1. MISIÓN ............................................................................................ 6
6.1.2. VISIÓN ............................................................................................. 6
6.1.3. SERVICIOS ..................................................................................... 6
6.1.4. UBICACIÓN ..................................................................................... 6
6.1.5. VALORES ........................................................................................ 7
7. JUSTIFICACIÓN ........................................................................................... 8
8. PROBLEMA ................................................................................................ 10
9. CONSECUENCIAS ..................................................................................... 10
10. ANTECEDENTES .................................................................................... 11
11. MARCO TEÓRICO .................................................................................. 14
11.1. LA GESTIÓN DE COMPRAS ........................................................... 14
11.2. DEFINICIÓN DE ADMINISTRACIÓN DE VENTAS ......................... 14
11.3. ÁREAS DE LA ADMINISTRACIÓN DE VENTAS............................. 15
11.4. REQUERIMIENTOS ......................................................................... 15
11.5. PRODUCTO ...................................................................................... 15
11.6. GENERALIDADES DE LOS INVENTARIOS.................................... 16
11.7. ORÍGENES DE LOS INVENTARIOS ............................................... 16
11.8. DEFINICIÓN DE INVENTARIOS ...................................................... 17
11.9. PRINCIPIOS ..................................................................................... 17
11.10. TIPOS DE INVENTARIO ............................................................... 18
11.11. COSTOS DE INVENTARIO........................................................... 18
11.12. TASA DE ROTACIÓN DE INVENTARIO ...................................... 20
11.13. PROYECCIÓN DE LA DEMANDA ................................................ 20
11.14. SISTEMAS DE CONTROL DE INVENTARIOS ............................ 20
11.15. POLÍTICAS DE INVENTARIO ....................................................... 21
11.16. DEMANDA DEPENDIENTE E INDEPENDIENTE ........................ 22
11.17. TIEMPO DE ENTREGA O TIEMPO DE ANTICIPACIÓN ............. 22
11.18. EL ANALISIS ABC ......................................................................... 23
11.19. DIAGRAMA DE PARETO .............................................................. 23
11.20. CONSTRUCCIÓN DE LA GRÁFICA DE PARETO ....................... 24
11.21. RAZONES PARA DIFERENCIAR ENTRE PRODUCTOS SEGÚN
SU CRITERIO CUANTITATIVO ..................................................................... 24
11.22. ESTRATEGIAS DE GESTIÓN DE INVENTARIO ......................... 25
11.23. CANTIDAD ÓPTIMA A PEDIR ...................................................... 25
11.24. GESTIÓN DE ALMACENES ......................................................... 25
11.25. FUNCIONES DEL ALMACÉN. ...................................................... 26
11.26. GASTOS DE ALMACENAMIENTO. .............................................. 26
11.27. COSTOS DE ALMACENAMIENTO............................................... 26
11.28. GESTIÓN DE ALMACÉN .............................................................. 27
11.29. DIAGNÓSTICO DEL ALMACÉN ................................................... 27
11.30. PROCESOS DE ALMACÉN .......................................................... 28
11.31. DESARROLLO DE SOFTWARE ................................................... 28
11.32. USABILIDAD COMO PRINCIPAL OBJETIVO EN EL
DESARROLLO WEB ...................................................................................... 29
11.33. OPERABILIDAD ............................................................................ 29
11.34. NAVEGADORES DE INTERNET .................................................. 30
 11.35. ARQUITECTURA CLIENTE SERVIDOR. ..................................... 30
11.36. VENTAJAS E INCONVENIENTES DE LA ARQUITECTURA
CLIENTE/SERVIDOR .................................................................................... 31
11.36.1. Las ventajas de la arquitectura cliente/servidor son las
siguientes: ................................................................................................... 31
11.37. LOS INCONVENIENTES DE LA ARQUITECTURA
CLIENTE/SERVIDOR SON LAS SIGUIENTES:............................................ 31
11.38. INGENIERÍA DE SOFTWARE ...................................................... 32
11.39. CALIDAD DE SOFTWARE ............................................................ 32
11.40. CONFIABILIDAD ........................................................................... 32
11.41. CONTROL DE CALIDAD............................................................... 33
11.42. LA GARANTÍA DE CALIDAD DE SOFTWARE ENGLOBA: ......... 34
11.43. REVISIONES DE TÉCNICAS FORMALES .................................. 34
11.43.1. Objetivos ..................................................................................... 34
11.43.2. Directrices de la revisión ............................................................ 34
11.44. PLANIFICACIÓN Y ESTÁNDARES DE LA GARANTÍA DE
CALIDAD DE SOFTWARE ............................................................................ 34
12. ENFOQUE METODOLÓGICO ................................................................ 35
12.1. TIPO Y DISEÑO DE INVESTIGACIÓN ............................................ 35
12.2. MODALIDAD DE INVESTIGACIÓN ................................................. 36
13. MODELO TEÓRICO. ............................................................................... 37
13.1. CARACTERÍSTICAS ESENCIALES DE RUP .................................. 38
1. Procesos dirigidos por Casos de Usos: ................................................. 38
2. Proceso centrado en la Arquitectura: ......................................................... 38
3. Iterativo e Incremental: ............................................................................... 38
13.2. RATIONAL UNIFIED PROCESS (RUP) ........................................... 38
13.3. HISTORIA ......................................................................................... 39
13.4. CARACTERÍSTICAS ESENCIALES ................................................. 39
Dirigido por Casos de Uso .......................................................................... 39
13.5. PROCESO CENTRADO EN LA ARQUITECTURA .......................... 41
13.6. PROCESO ITERATIVO E INCREMENTAL ...................................... 42
13.7. OTRAS PRÁCTICAS ........................................................................ 43
13.7.1. Gestión de requisitos .................................................................. 43
 13.7.2. Desarrollo de software iterativo .................................................. 44
13.7.3. Desarrollo basado en componentes........................................... 44
13.7.4. Modelado visual (usandoUML) ................................................... 44
13.7.5. Verificación continúa de la calidad ............................................ 44
13.7.6. Gestión de los cambios .............................................................. 44
13.7.7. Estructura del proceso ............................................................... 45
13.7.8. Estructura Dinámica del proceso. Fases e iteraciones .............. 45
13.8. UML ................................................................................................... 51
13.9. ESTEREOTIPO UML..................................................................... 52
14. FACTIBILIDAD......................................................................................... 53
14.1. FACTIBILIDAD TÉCNICA ................................................................. 53
14.2. FACTIBILIDAD ECONÓMICA .......................................................... 53
14.3. FACTIBILIDAD OPERACIONAL....................................................... 53
15. Planificación del proyecto ........................................................................ 54
15.1. LENGUAJE DE PROGRAMACIÓN Y BASES DE DATOS. ............. 54
Inventio Lite: Sistema de Inventario y Ventas Open Source ...................... 54
15.2. CARACTERÍSTICAS ........................................................................ 55
15.2.1. Productos ................................................................................... 55
15.2.2. Vender ........................................................................................ 55
15.2.3. Clientes ....................................................................................... 55
15.2.4. Proveedores ............................................................................... 55
15.2.5. Inventario .................................................................................... 55
15.2.6. Cortes de Caja............................................................................ 55
15.2.7. Usuarios ..................................................................................... 56
15.2.8. Reportes en Word ...................................................................... 56
16. CONCRECIONES ................................................................................... 57
16.1. CASOS DE PRUEBA ........................................................................ 57
16.2. ESTIMACION COCOMO .................................................................. 57
16.3. ITERACION 1 .................................................................................... 58
16.3.1. Modelo relacional ....................................................................... 59
16.3.2. Casos de uso.............................................................................. 60
16.3.3. Proceso Centrado en la Arquitectura ......................................... 61
 16.3.4. Diagrama de actividad ................................................................ 62
16.3.5. Cronograma................................................................................ 63
16.3.6. Modelo iterativo incremental: ..................................................... 64
16.3.7. Excel de compras y ventas ........................................................ 65
16.3.8. Excel de precios de productos ................................................... 66
16.3.9. Factura de venta......................................................................... 67
16.3.10. Clasificación ABC ....................................................................... 68
Requerimientos ........................................................................................... 68
Personal involucrado................................................................................... 68
16.3.11. Perspectiva del producto ............................................................ 68
16.3.12. Funcionalidad del producto ........................................................ 69
16.3.13. Características de los usuarios .................................................. 70
16.3.14. Restricciones .............................................................................. 70
16.3.15. Requerimiento No. 1 .................................................................. 71
16.3.16. Caso de prueba 1. Login de usuario .......................................... 72
16.4. ITERACION 2 .................................................................................... 73
16.4.1. Requerimiento 11 ....................................................................... 74
16.4.2. Caso de prueba 2. Base de datos .............................................. 74
16.5. ITERACION 3 .................................................................................... 75
16.5.1. Requerimiento 2. ........................................................................ 76
16.5.2. Requerimiento 3 ......................................................................... 77
16.5.3. Requerimiento 4 ......................................................................... 77
16.5.4. Requerimiento 5 ......................................................................... 78
16.5.5. Requerimiento 6 ......................................................................... 79
16.5.6. Requerimiento 7 ......................................................................... 79
16.5.7. Requerimiento 8 ......................................................................... 80
16.5.8. Requerimiento 9 ......................................................................... 81
16.5.9. Requerimiento 10 ....................................................................... 81
16.5.10. Caso de prueba 3. Registrar en el sistema ................................ 82
16.5.11. Caso de prueba 4. Editar usuarios ............................................. 82
16.5.12. Caso de prueba 5. Registrar cliente........................................... 84
16.5.13. Caso de prueba 6. Editar cliente ................................................ 84
 16.5.14. Caso de prueba 7. Registrar nuevo proveedor .......................... 86
16.5.15. Caso de prueba 8. Editar proveedor .......................................... 86
16.5.16. Caso de prueba 9. Registrar categoría ...................................... 88
16.5.17. Caso de prueba 10. Editar categoría ......................................... 88
16.5.18. Caso de prueba 11. Registrar producto ..................................... 90
16.5.19. Caso de prueba 12. Editar producto .......................................... 90
16.5.20. Caso de prueba 13. Generar inventario ..................................... 93
16.5.21. Casos de prueba 14. Reabastecimiento .................................... 94
16.5.22. Caso de prueba 15. Reporte reabastecimiento ......................... 94
16.5.23. Casos de prueba 16. Venta........................................................ 96
16.5.24. Caso de prueba 17. Factura de venta........................................ 96
16.5.25. Caso de prueba 18. Reporte producto bajo ............................... 99
16.5.26. Caso de prueba 19. Reporte ventas totales ............................ 100
16.5.27. Caso de prueba 20. Reporte ventas por fechas ...................... 101
16.5.28. Caso de prueba 21. Reporte entradas y salidas ...................... 101
16.5.29. Caso de prueba 22. Reporte más vendidos ............................ 101
16.5.30. Caso de prueba 23. Envió de reportes .................................... 101
16.6. ITERACION 4 .................................................................................. 105
16.6.1. Maquetación y diseño .............................................................. 105
17. CONCLUSIONES .................................................................................. 108
18. RECOMENDACIONES.......................................................................... 109
19. ANEXOS ................................................................................................ 109
20. BIBLIOGRAFÍA ..................................................................................... 110
 TABLA DE ILUSTRACIONES

Ilustración 1. Gráfico de Pareto ......................................................................... 24

Ilustración 2. Historia de RUP ........................................................................... 39
Ilustración 3. Los Casos de Uso integran el trabajo .......................................... 40
Ilustración 4. Trazabilidad a partir de los Casos de Uso ................................... 40
Ilustración 5. Evolución de la arquitectura del sistema ................................ 41
Ilustración 6. Una iteración RUP........................................................................ 42
Ilustración 7Estructura de RUP ......................................................................... 45
Ilustración 8. Fases e hitos en RUP .................................................................. 46
Ilustración 9. Distribuciones típicas de esfuerzo y tiempo................................. 46
Ilustración 10. Distribución típica de recursos humanos ................................... 47
Ilustración 11. Relación entre roles, actividades, artefactos ............................. 51
Ilustración 12. Detalle de un workflow mediante roles, actividades y artefactos51
Ilustración 13. Modelo relacional. ...................................................................... 59
Ilustración 14. Casos de Uso ............................................................................. 60
Ilustración 15. Proceso centrado en la arquitectura .......................................... 61
Ilustración 16. Diagrama de actividad ............................................................... 62
Ilustración 17. Cronograma de Actividad .......................................................... 63
Ilustración 18. Modelo Iterativo Incremental ...................................................... 64
Ilustración 19. Excel de compras y ventas ........................................................ 65
Ilustración 20. Excel de productos..................................................................... 66
Ilustración 21. Factura de venta ........................................................................ 67
Ilustración 22. Login........................................................................................... 72
Ilustración 23. Pantalla de inicio ........................................................................ 73
Ilustración 24. Base de datos ............................................................................ 75
Ilustración 25. Lista de usuarios ........................................................................ 82
Ilustración 26. Agregar usuario .......................................................................... 83
Ilustración 27. Editar usuario ............................................................................. 84
Ilustración 28. Editar o eliminar clientes ............................................................ 85
Ilustración 29. Registro de cliente ..................................................................... 85
Ilustración 30. Edición cliente ............................................................................ 86
Ilustración 31. Directorio proveedores ............................................................... 87
Ilustración 32. Agregar proveedor ..................................................................... 87
Ilustración 33. Editar proveedor ......................................................................... 88
Ilustración 34. Categorías .................................................................................. 89
Ilustración 35. Nueva categoría ......................................................................... 89
Ilustración 36. Editar categoría .......................................................................... 90
Ilustración 37. Lista de productos ...................................................................... 91
Ilustración 38. Nuevo producto .......................................................................... 92
Ilustración 39. Editar producto ........................................................................... 92
Ilustración 40. Inventario.................................................................................... 93
Ilustración 41. Historial global producto ............................................................ 94
Ilustración 42 reabastecer ................................................................................. 95
Ilustración 43. Reabastecimientos..................................................................... 96
Ilustración 44. Realizar venta ............................................................................ 97
Ilustración 45. Agregar otro producto o finalizar venta ...................................... 98
Ilustración 46. Factura ....................................................................................... 98
Ilustración 47. Producto bajo en inventario ....................................................... 99
Ilustración 48. E-mail producto bajo en inventario .......................................... 100
Ilustración 49 reporte de ventas totales .......................................................... 101
Ilustración 50. Ventas totales por fecha .......................................................... 103
Ilustración 51. Reporte por fecha de entradas y salidas ................................. 103
Ilustración 52. Productos más vendidos .......................................................... 104
Ilustración 53. Envío de reportes ..................................................................... 104
Ilustración 54. Maquetación final 1 .................................................................. 105
Ilustración 55. Maquetación final 2 .................................................................. 106
Ilustración 56. Maquetación final 3 .................................................................. 107
 RESUMEN

El proyecto consta de desarrollar el sistema de compras, inventario y ventas de

la empresa Tecno PC System mejorándolo con una aplicación que gestione,
controle e informe en tiempo real las compras, el inventario y las ventas de la
empresa, generando un informe estadístico diario y enviándolo al correo
electrónico al correo cuando el stock de un producto se encuentre en baja
existencia y notificará a un distribuidor cuando éste se encuentre agotado. Esto
con el fin de crear un ambiente laboral con fluidez, logrando mejorar costos y
beneficios.

Para poder competir con éxito en los mercados actuales es fundamental una
correcta administración de sus bienes tangibles e intangibles, en especial de sus
inventarios.

Palabras clave: Gestión, Sistema de inventario, compras, ventas, Ingeniería de

Software, RUP, modelo iterativo, casos de uso, PHP, MySQL, bootstrap 3, open
sourse, Tecno Pc System, web, host, responsivo.
 ABSTRACT

The project consists of developing the system of purchasing, inventory and sales
Tecno PC System improving it with an application to manage, monitor and report
real-time purchases, inventory and sales company, generating a daily statistical
report and email sending mail when the stock of a product is in low supply and
notify a distributor when the latter is exhausted. This in order to create a work
environment fluent, managing to improve costs and benefits.

To compete successfully in today's markets is essential to the proper

administration of its tangible and intangible assets, particularly inventories.

Keywords: Management System, inventory, purchasing, sales, Software

Engineering, RUP, iterative model, use cases, PHP, MySQL, Bootstrap 3, open
sourse Techno Pc System, web, host, responsive.
 1. INTRODUCCIÓN

El trabajo de investigación que se muestra en el presente documento tiene como

objetivo proponer la actualización del sistema de gestión de compras, inventario
y ventas de la empresa TECNO PC SYSTEM. En este se encontrarán los
fundamentos teóricos que soportan la investigación.
Para poder competir con éxito en los mercados actuales es fundamental una
correcta administración de sus bienes tangibles e intangibles, en especial de sus
inventarios, puesto que con frecuencia se toman decisiones sobre compras,
ventas, servicio al cliente, planeamiento de producción y otras actividades
ligadas directamente a la gestión de compras, inventario y ventas.
La metodología que se presenta en el desarrollo de la investigación aborda el
diagnóstico del proceso de gestión de inventario de la empresa, luego la
aplicación de la metodología ABC para la clasificación del inventario, todo esto
enfocado a mejorar el manejo de este, concluyendo con esta metodología una
propuesta de mejoras en el proceso de almacén.
En el presente documento se encuentra desarrollado todo lo concerniente
al diagnóstico del proceso de inventario, detallando aspectos que comprenden
desde los artículos almacenados, el manejo que se le dan a estos artículos,
las funciones de la administración del inventario en la empresa.
De igual manera procede a aplicar la metodología ABC para clasificar el
inventario de la empresa en mención, para esto se tuvo en cuenta el índice de
rotación de cada artículo del inventario, y el volumen anual demandado de estos,
las decisiones de clasificación fueron soportadas bajo la regla 80-20 de Pareto.
Después de haber aplicado la metodología ABC, en el tercer capítulo se procede
a definir estrategias de gestión para el inventario clasificado, además del
establecimiento de políticas para el manejo de éste teniendo en cuenta criterios
como lo son la cantidad económica a pedir, el punto de reaprovisionamiento e
inventario de seguridad.
Se desarrolla una propuesta de gestión de compras, inventario y ventas, de
acuerdo a la clasificación ABC anteriormente aplicada, además de esto, se
encuentran descritas y caracterizadas las actividades más importantes en este
proceso.

1
 2. OBJETIVOS

2.1. OBJETIVO GENERAL

Desarrollar el sistema de gestión de compras, inventario y ventas para la

empresa TECNO PC SYSTEM.

2.2. OBJETIVO ESPECÍFICO.

 Diagnosticar el proceso de Actualización del sistema de gestión de

compras, inventario y ventas para la empresa TECNO PC SYSTEM.

 Diseñar el sistema teniendo en cuenta la metodología ABC para

clasificar el inventario de productos terminados que permita
priorizar la gestión de compras, inventario y ventas.

 Codificar EL SISTEMA DE GESTION DE COMPRAS, INVENTARIO Y

VENTAS

 Probar el sistema de gestión de compras, inventario y ventas para la

empresa TECNO PC SYSTEM

2
 3. DELIMITACIÓN Y ALCANCES DEL PROYECTO

3.1. DELIMITACIÓN DE TIEMPO Y ESPACIO

La investigación se realizará basada en la información histórica mensual de

ventas y producción hechas en el periodo transcurrido entre el año 2010 y 2015.

3.2. DELIMITACIÓN DEL ESPACIO

El proyecto se realizará en la empresa TECNO PC SYSTEM de la ciudad de

Pereira, especialmente en los departamentos de producción y ventas.

3.3. POBLACIÓN Y MUESTRA

La población está compuesta por todos los empleados de la empresa, que

participan de manera directa o indirecta en los procesos objeto de estudio, y
la información registrada en la empresa que contenga información acerca del
consumo y gasto de materiales, registros.

3.4. ALCANCES

Pretender que durante el desarrollo del proyecto se logre diseñar e implementar

un servicio de gestión de compras, inventario y ventas en el cual la empresa
podrá hacer uso del mismo para optimizar al máximo sus productos de interés
en relación a las necesidades de los clientes.

Es importante señalar, que el entorno gráfico de la aplicación está orientado

a la estructura de las necesidades de la empresa, para de esta manera lograr el
análisis estadístico que ayudará a mejorar los productos ofrecidos por la
empresa TECNO PC SYSTEM, ya que su objetivo es de uso personal.

El servicio posee una interfaz sencilla, fresca y fácil de manipular sin necesidad
de tener conocimientos previos y estará disponible a través de internet para
disponer de ella cuando desee, y desde cualquier dispositivo con conexión a
internet.

3
 4. APORTE TEÓRICO PRÁCTICO

A nivel práctico, el desarrollo de esta aplicación de gestión de compras,

inventario y ventas para la empresa TECNO PC SYSTEM, representa un gran
avance para esta empresa, abordando con precisión los problemas que
actualmente se presentan en la aplicación de los procesos de compras, control
de inventario y ventas que optimicen y generen de manera ágil mayor ganancia
en tiempo.
Otro de los aportes de este trabajo, se encuentra en el hecho de que a través de
su ejecución, se abren las posibilidades de mejoramiento del sistema de gestión,
inventario y ventas, hasta ahora utilizados por la empresa TECNO PC SYSTEM
y, por lo tanto, una mayor rapidez de los mismos para la atención de clientes y
proveedores.
Finalmente, el trabajo es de importancia para el propio autor, puesto que servirá
para poner en práctica los conocimientos adquiridos en la universidad, en
relación a ingeniería de software.

4
 5. SITUACIÓN PROBLEMÁTICA

El problema radica en la necesidad de la empresa de implementar un sistema

de gestión de compras, inventario y ventas, para el manejo de su gran variedad
de productos y servicios. Al no contar con este sistema no se puede saber con
exactitud qué cantidad de ventas diarias realiza, diferenciando que producto se
vende más que otros, y que le generen un crecimiento como empresa mejorando
así mismo las ventas y la rentabilidad misma, dándole un crecimiento sólido y
competitivo en el mercado.

El problema de los inventarios es que su nivel no debe ser tan alto, de tal manera
que represente un costo extremo al tener paralizado un activo que podría
emplearse en otra operación que genere más beneficio. Además de esto, si se
cuenta con muy poco, provocaría que la empresa produzca sobre pedido,
situación igualmente desfavorable puesto que se debe satisfacer de inmediato
las demandas de los clientes. Para lo anterior la empresa debe determinar el
nivel apropiado de inventario, poniendo en una misma balanza los costos de
inventario, el nivel de servicio y el costo por pedido.
“Entre los artículos en inventario que tiene una empresa, sólo un pequeño
porcentaje de ellos merecen la más cuidadosa atención y el mayor grado de
control.” (Krajewski, 2000). Por ende el análisis ABC es un proceso que ayuda a
dividir los artículos en tres clases, de acuerdo con su uso monetario, de modo
que los gerentes puedan concentrar su atención en los que tengan el valor
monetario más alto.
Lo mencionado anteriormente se encuentra en un lugar conocido como el
almacén y en la empresa objeto de estudio se sitúan varios problemas que
afectan la gestión del almacén, entendiéndose como gestión del almacén todo
el proceso de recepción, identificación del producto, almacenamiento,
conservación y mantenimiento, preparación de pedidos, organización y control
de las existencias . Siendo la razón de ser del almacén la imposibilidad práctica
de reducir a cero el periodo de tiempo entre la preparación para consumo de un
material y el acto de producir el bien final.

5
 6. MARCO CONTEXTUAL

6.1. TECNO PC SYSTEM

6.1.1. MISIÓN

Brindar a nuestros clientes servicios en áreas de informática para empresas y

particulares, permitiendo así su disponibilidad en funcionamiento de su negocio
por medio del soporte con nuevas tecnologías y precisas, atención personalizada
y dando respuesta ágil y clara a sus necesidades, sustentado por un equipo
técnico y profesional, altamente capaz y dedicado.

6.1.2. VISIÓN

Ser el principal servicio en el mercado en atención local y virtual de soporte

informático para empresas y particulares, por medio de nuevas tecnologías, la
excelencia y la calidad del servicio.

También brindar los servicios computacionales que así requiera para que
nuestros clientes obtengan la mejor experiencia de nuestros productos y atender
a sus necesidades y dar respuestas tecnológicas en busca de altos niveles de
rendimiento y efectividad.

6.1.3. SERVICIOS

Tecno Pc System ofrece soluciones a empresas en:

 Diseño y desarrollo de páginas web

 Mantenimiento y venta de computadores
 Fabricación de sellos
 Diseño de publicidad

6.1.4. UBICACIÓN

Estamos Ubicados en la Calle 19 No. 12 - 69 Centro Comercial Fiducentro

entrada 3 Local 32 Pasillo Morado Pereira - Risaralda
Tel: 325 1609 Cel.: 310 595 6803

Tecno Pc System lleva más de 5 años compitiendo en el mercado, lo que nos

diferencia de otras empresas es:

6
  Nuestro interés son las relaciones a largo plazo.
 Buscamos superar nuestras expectativas y conocimientos
 Disfrutamos de nuestro trabajo.
 Comprender las necesidades de nuestros clientes es nuestra prioridad.

En la empresa Tecno Pc System Trabajan 2 personas el Propietario y una

Secretaria

6.1.5. VALORES

Transparencia: Realizamos nuestra gestión de forma objetiva, clara y verificable.

Respeto: Interactuamos reconociendo los intereses colectivos, la diversidad
individual, la sostenibilidad de los recursos naturales y la institucionalidad.
Equidad: Procedemos con justicia, igualdad e imparcialidad, buscando un
impacto social positivo e inclusivo.
Integridad: Actuamos con firmeza, rectitud, honestidad, coherencia y sinceridad.

7
 7. JUSTIFICACIÓN

Hoy en día los inventarios no son únicamente un activo que debe ser registrado
contablemente, sino que también son un activo estratégico que permiten a las
organizaciones conseguir el nivel de servicio deseado o esperado para sus
actividades y consumidores, teniendo en cuenta esto, la correcta gestión de los
mismos puede hacer que se vean como aliados financieros o al contrario como
un fuerte dolor de cabeza. “Una de las razones por la que este tema recibe
especial atención es porque en muchas empresas representan un alto
porcentaje del capital invertido (por lo general entre 20 y 40%)” (Negron, 2009).

En cuanto a la adquisición de inventario y la ubicación de ellos en la planta, es

fundamental para el cumplimiento de operaciones en las empresas, y no es la
excepción para la empresa TECNO PC SYSTEM, donde el estado de los
productos que ofrece y el cumplimiento de las ordenes de servicios son aspectos
importantes para satisfacer al cliente y mantener a la empresa compitiendo en el
mercado, es a través del mejoramiento de los procesos de gestión inventario y
gestión del almacén que se puede tener una mejora muy significativa en el
desempeño de la empresa. Según (Martínez Robles, 2005) lo ideal es que los
inventarios sean tan bajos como sea posible para así mantener el flujo de
producción necesario para atender la demanda de los clientes.

Teniendo en cuenta que los clientes son cada vez más exigentes y que el
mercado es cada vez más competitivo, las empresas deben mejorar sus
procesos de tal manera que tengan la capacidad de reaccionar a nuevos
requerimientos del cliente y otros cambios que se presentan en el entorno, para
así también poder llegar a mantenerse y aumentar la demanda de los productos
y servicios.

La justificación inicial de los almacenes se basa en la necesidad de mantener

inventarios, de tal manera que se puede concebir como un lugar donde los
artículos están a la espera, la gestión del almacén se hace necesaria para
disminuir la acumulación excesiva de materiales en proceso. De acuerdo con
(MUTHER, 1981), las posibles ventajas de una gestión de almacén son el
incremento de la producción, la disminución en los retrasos en la producción, el
ahorro del área ocupada y la reducción del manejo de materiales. Esto es de
gran importancia para la empresa, ya que al reducir las distancias recorridas (lo
que significaría reducir tiempo de recorrido), se ahorrarían horas de trabajo de
los operarios. Si se logra un ahorro en tiempos, esto significaría un ahorro en
dinero para la empresa.

El lograr que se identifique y clasifique el inventario de acuerdo a la metodología

de clasificación ABC va a facilitar que la empresa determine que artículos
representan la mayor parte del valor del inventario, midiéndose su uso en dinero
y si es justificable que se haga una inmovilización monetaria por él. Así como

8
también una adecuada recepción, almacenamiento y movimiento ayudaría a
optimizar el espacio sin dejar de tener en cuenta que una buena gestión del
almacén permite agilizar otros procesos logísticos.
Este proyecto cobra importancia ya que con él se planea incorporar los
requerimientos de la organización para tener el inventario correcto en las
cantidades correctas, en el tiempo y lugar correcto. De acuerdo con Logenecker,
Moore, Petty y (Palich, 2010) La administración de inventarios es de particular
importancia en las pequeñas empresas que venden al menudeo o al mayoreo,
ya que el inventario suele representar una fuerte inversión financiera para estas
empresas.

Esta investigación brinda la oportunidad de ampliar el conocimiento adquirido y

poner en práctica lo aprendido a lo largo de la carrera bien sea para el estudio
de la profesión o cualquier otra que se presente en la vida profesional.

Dada la necesidad de la empresa en mejorar su sistema actual de gestión de

compras, inventario y ventas, siendo esto un tema crítico, debido a que su
sistema actual es obsoleto y poco productivo, no cumple con objetivos básicos
como mantener actualizada la información de stock en el inventario, no genera
notificaciones cuando un producto se encuentra agotado en el stock, tampoco
genera estadísticas sobre los productos más comercializados para poder crear
estrategias que mejoren las ventas y la rentabilidad misma, dándole un
crecimiento sólido y competitivo en el mercado.

Se propone actualizar el sistema de gestión de compras inventario y ventas para

poder tener información en tiempo real de productos y ventas, además de las
estadísticas de ventas y un informe diario de las mismas, para lograr el
crecimiento sólido de la empresa, esto con el fin de los siguientes beneficios:

 Automatización del proceso de pedir a un distribuidor un producto que se

encuentre agotado en el stock

 Información al instante y en tiempo real

 Eliminar la perdida de inventario por descuido

 Aumentar la eficiencia de flujo de productos dentro de la empresa

 Generar cuadros estadísticos de productos vendidos

 Enviar notificaciones a proveedores.

 Actualizar automática de productos en stock

9
 8. PROBLEMA

Actualmente la empresa TECNO PC SYSTEM carece de un sistema que le

permita obtener con exactitud información vital para su gestión y toma de
decisiones tal como ventas realizadas, productos más vendidos, productos en
bodega entre otros, conllevando a perdida en ventas y clientes, baja calidad en
la materia prima a causa de su caducidad y deterioro por mal manejo.

9. CONSECUENCIAS

Las consecuencias de este proyecto son positivas respecto a la actualidad social

en la que se vive que tiende a crear un entorno en el que todo se pueda acceder
desde internet para ahorrar tiempo y agilizar procesos que hoy en día todavía
son bastante tardíos y tediosos, y de esta manera contribuir a una sociedad
moderna que cada vez exige más tecnología y aplicaciones que agilicen sus
comunicaciones.

Con este proyecto de actualización de gestión de compras, inventario y ventas,

se busca generar un medio seguro y fácilmente accesible para agilizar trámites
y ahorrar gastos en un alto porcentaje, por consiguiente lo mejor de la tecnología
es que permite obtener acceso a aquello que se necesita desde un solo lugar a
un bajo costo con un enorme beneficio.

10
 10. ANTECEDENTES

En el presente trabajo se registran una serie de investigaciones y software

similares que presentan algunos criterios que soportan fuertemente el trabajo de
investigación que se está ejecutando.

 1Inventoria, software para inventarios, Control de stock y manejo de

inventario para empresas
 Organice y haga un seguimiento de su inventario fácilmente
 Mantenga niveles óptimos de inventario, con las alertas e informes
 Acceso remoto al sistema para múltiples usuarios, con la función de
acceso a la nube
 Se instala y ejecuta en solo minutos

 2Kardex Tauro® El Software de Inventarios Kardex Tauro® está diseñado

para administrar eficazmente su Bodega o Almacén y se aprende a
manejar en muy corto tiempo.

 La versión registrada permite interconectar varios Tauro.

 Su bodega en una ciudad, el almacén en otra, y usted controla
desde casa.

 Todo lo que se ve, se convierte en reporte y se exporta a Excel o

Word.

 Control interno de auditoria. Quien prendió el Tauro, a qué horas,

en cual PC.

 Cree productos a partir de insumos, defina los "ingredientes" y sus

cantidades. Luego genere Órdenes de Producción.

 Samba Software contable3, de facturación y gestión administrativa, con

Samba podrás conectar todos los procesos de negocio, tendrás un mejor
control y un mejor funcionamiento. Gestiona tus ventas, tus clientes, tus
proyectos, todo desde un solo lugar, déjanos ser aliados de tus metas,
crece con Samba.
Puedes programar la generación de las facturas en forma automática
Seguridad basada en perfiles que puedes personalizar para que solo
accedan hasta donde tú quieras
Anexar archivos a las facturas, a los terceros y hasta los documentos
contables

1
Inventoria software para inventarios http://www.nchsoftware.com/inventory/es/index.html
2
Kardex Tauro http://inventarios-kardex-tauro.sysmaya.net/
3
Samba Software Contable http://www.sambaerp.com/

11
 Sistema de control de inventario
Exportar a Excel y a Pdf
Puedes hacer pagos múltiples en la cartera
Tener un seguimiento de las acciones de los usuarios en los documentos
más importantes
La nómina más automática que existe en la nube (Colombia)

 4El trabajo de investigación de FLOR ALBA LUCIA TOVIO ALMANZA y

PAOLA PATRICIA TERAN RANGEL, realizado en el año 2006, que tiene
por título ANÁLISIS Y DISEÑO DE UN PLAN DE MEJORAMIENTO DE
LOS PROCESOS DE GESTIÓN DE STOCKS, GESTIÓN DE ALMACEN
Y GESTIÓN DE PEDIDOS Y DISTRIBUCIÓN PARA LA EMPRESA UNO
A DEL CARIBE, tomada de la base de datos de la Universidad de
Cartagena, esta investigación tiene como objetivo plantear los cambios
pertinentes en la empresa en mención para mejorar los procesos de
gestión de inventario, de pedidos y para la distribución en la planta,
además tiene como uno de sus puntos más importantes, la determinación
de los niveles adecuados de inventarios, que eviten tener problemas de
suministros de materiales tanto en tiempo como en las cantidades, uno
de los puntos más relevantes de esta investigación es el análisis de la
gestión de stock y la aplicación de un modelo de reaprovisionamiento que
permita tener un mejor manejo de las existencias y una reducción en sus
costos.

 5En el año 2008 “DISEÑO DE UN SISTEMA DE GESTION DE

INVENTARIOS, COMPRAS Y ALMACEN PARA LA EMPRESA JAIME
CIFUENTES E.U.”, tomada de la base de datos de la UNIVERSIDAD DE
CARTAGENA, Facultad de Ciencias Económicas, Programa de
Administración Industrial, de la autoría de HÉCTOR DAZA ZAPATEIRO,
OSCAR FABIAN ANGARITA CASTRO. Esta investigación tiene como
objetivo principal optimizar los recursos invertidos en los procesos de
inventarios , compras y almacén , por medio de un modelo de gestión
propuesto, la importancia de este proyecto es porque genera
herramientas y procedimientos estandarizados que sirven de guía para la
empresa en la gestión de sus inventarios , además por medio de este se
optimiza cada una de las partes del sistema de almacenamiento actual,
sumando a esto la creación de un manual de inventarios que permite
conocer, visualizar y medir los procesos en la gestión de suministros
directos e indirectos, uno de los aspectos más novedosos de esta
propuesta fue la de diseñar un programa informático que permita el control
de ingreso de salidas, costos y consumo de los inventarios y que

4
Investigación de Floralba Lucia Tovio y Paola Patricia Teran http://docplayer.es/6396048-Propuesta-de-
mejora-del-proceso-de-gestion-de-inventario-y-gestion-del-almacen-para-la-empresa-fb-soluciones-y-servicios-s-a-s.html
5
Diseño de un sistema de gestión de inventarios, compras y almacén para la empresa Jaime
Cifuentes E.U. http://docplayer.es/6396048-Propuesta-de-mejora-del-proceso-de-gestion-de-
inventario-y-gestion-del-almacen-para-la-empresa-fb-soluciones-y-servicios-s-a-s.html

12
 suministra a su vez de forma automática la información de los niveles de
inventarios.

 6En el año 2000 “APLICACIÓN DEL MÉTODO ABC DE CONTROL DE

INVENTARIOS EN UNA BODEGA DE REPUESTOS E INSUMOS DE
UNA EMPRESA DE SERVICIOS.”, tomada de la base de datos de la
Escuela Superior Politécnica del litoral, Facultad de ingeniería en
mecánica y ciencias de la producción de la autoría de Clara Camino
Obregón Guayaquil Ecuador.

Este trabajo tiene como objetivo principal establecer políticas de inventarios

adecuadas para los diferentes productos, mediante una clasificación de
inventarios ABC, para disminuir los costos asociados a los inventarios. Dada
la investigación realizada por el autor, éste llego a la conclusión de que en
esta empresa no se le ha dado la atención que se requiere a los inventarios.
El Sistema que se utiliza es bastante limitado e incurre en desperdicios y
gastos innecesarios, así como tampoco apoya la gestión de la gerencia
debido a que provee información incompleta para la toma de decisiones. El
sistema solo permite saber cuánto y en que se gastó pero no permite saber
si lo que se compra es lo necesario, si no se está gastando innecesariamente,
y si la compañía está protegida de un desabastecimiento. En las
investigaciones citadas anteriormente se hace hincapié en el hecho de que
uno de los aspectos más importantes a tener en cuenta es el análisis de la
gestión de stock, el manejo de las existencias y una reducción en sus costos.
Además de los distintas formas de llevar la información y el control que se
ejerce en las salidas y entrada de artículos, teniendo en cuenta éstas se
puede tener idea de acuerdo a como se encuentra el estado del arte de la
temática que se trata.

6
Aplicación del método Abc de control de inventarios en una bodega de
repuestos e insumos de una empresa de servicios
http://www.dspace.espol.edu.ec/bitstream/123456789/4483/1/7003.pdf

13
 11. MARCO TEÓRICO

11.1. LA GESTIÓN DE COMPRAS

La práctica de una correcta gestión de compras asegura que la empresa tenga

los mejores proveedores para abastecer los mejores productos y servicios, al
mejor valor total. La función de compras a menudo gasta más dinero que
cualquier otra función de la empresa, así que compras proporciona una buena
oportunidad para reducir los costos y aumentar los márgenes de beneficio. Dado
que la compra ha dejado de ser una actividad más para convertirse en un
elemento estratégico de la organización, hoy más que nunca resulta necesario
conocer las aristas fundamentales referidas a esta temática. (Tejero A. , 2000)

Las empresas en la actualidad operan en mercados cada vez más globalizados

y se enfrentan a una fuerte competencia con sus similares ya sean nacionales o
extranjeros.
Debido a esto, reducir los costos es básico para el desempeño eficiente y eficaz
de cualquier entidad. Ninguna organización encuentra que sea económico
fabricar todo el material que utiliza. Las ventajas de la especialización son
demasiado importantes. La función de compras a menudo gasta más dinero que
cualquier otra función de la empresa, así que compras proporciona una buena
oportunidad para reducir los costos y aumentar los márgenes de beneficio.
La compra ha dejado de ser una actividad más para convertirse en un elemento
estratégico de la organización. La práctica de la estrategia de compra es
asegurar que la empresa tenga los mejores proveedores para abastecer los
mejores productos y servicios, al mejor valor total.

La actividad de compras juega un importante papel en la mayor parte de las

organizaciones, dado que los materiales adquiridos generalmente representan
entre el 40 y el 60 % del valor de las ventas de productos finales. Esto significa
que reducciones de costos relativamente pequeñas pueden tener un mayor
impacto sobre los beneficios que iguales mejoras en otras áreas de la
organización. (Ballou, 1991)

11.2. DEFINICIÓN DE ADMINISTRACIÓN DE VENTAS

Administración de ventas se define como el sistema de administración que

mediante el uso de la planeación, organización, dirección, control y coordinación
contribuye al incremento de las ventas y sus beneficios.

14
 11.3. ÁREAS DE LA ADMINISTRACIÓN DE VENTAS

Las áreas de la administración de ventas son: la programación de los esfuerzos

de venta, innovaciones en las ventas, comunicación, etc. (Dr. Salvador Mercado,
2004)

11.4. REQUERIMIENTOS

 Definir estrategias de gestión de compras, inventario y ventas que incluya

cantidad óptima a pedir, política de pedidos y políticas de revisión de
existencia para cada clasificación ABC que mejoren el manejo del
inventario.

 Proponer mejoras en el proceso de gestión de compras, inventario y

ventas de la empresa que incluya la distribución física, procedimientos y
caracterización de los proceso.

11.5. PRODUCTO

El producto es la variable básica de marketing y ello porque sin producto no hay

nada que intercambiar y, por lo tanto, no habría función comercial. Más aun, sin
producto no se puede decir siquiera que hay empresa.

Según el diccionario de la Real Academia Española de la lengua (21.*Ed), el

producto tiene varias acepciones:
1. Cosa producida
2. Caudal que se obtiene de una cosa que se vende, o el que ella reditúa
3. Cantidad que resulta de la multiplicación
4. Producto Nacional Bruto: Valor de todos los bienes y servicios producidos
en la economía de un país en un periodo de tiempo dado
5. Producto Nacional Neto: resultado del PNB menos el valor asignado a la
depreciación del capital utilizado en la producción

También en macroeconomía se habla de Producto Nacional Bruto (o neto),

como conjunto de la producción global de una economía de las compras
realizadas en el mercado exterior.

Ninguna de estas acepciones nos vale para entender el producto cuando se

le contempla desde la óptica de marketing, ya que en todos los casos
enumerados se contempla al producto como algo pasivo, como el resultado
de un proceso de producción; y aunque todas estas acepciones sean válidas
desde la perspectiva de la producción, no podemos admitirlas para explicar
la complejidad comercial del producto. (Gomez, 2005)

15
 11.6. GENERALIDADES DE LOS INVENTARIOS.

A continuación se desarrollará la temática concerniente a los orígenes,

definición, importancia, propósito, tipos de inventario costos de inventario,
indicadores y sistemas de inventario, de acuerdo a la definición de distintos
autores, los cuales darán soporte al desarrollo del proyecto.

11.7. ORÍGENES DE LOS INVENTARIOS

Desde tiempos antiguos, los egipcios y otros pueblos de la antigüedad,

acostumbraban a acopiar grandes porciones de alimentos para utilizarlos cuando
escaseaban. Debido a lo anterior aparece el problema de los inventarios, como
estrategia para contrarrestar los periodos de escasez, que le aseguraran la
subsistencia de la vida y el desarrollo de sus actividades normales. Esta forma
de almacenamiento de todos los bienes y alimentos necesarios para sobrevivir
motivó la existencia de los inventarios o stock (Ramirez, 2007).

Más adelante con el transcurrir de la historia se seguía viendo como los

inventarios derrotaban a la información, la gran mayoría de veces por que la
información no era precisa, y las empresas ocultaban su ignorancia del mercado
por medio de un inventario adicional. La eficiencia de este proceso se debe en
un principio a los japoneses que implementaron una mejora en los mismos con
el Kanban. Anaya (Kanban, 2007) Afirma: Los sistemas Kanban se caracterizan
por una máquina/operación recibe una señal cuando la siguiente
máquina/operación necesita trabajo. La estandarización de los contenedores
permitirá enviar de una operación a otra una cantidad determinada de trabajo.

El progreso de los inventarios y los sistemas para hacer control del mismo han
ido tomando cada vez más importancia, es así como hasta principios de los años
80 los stocks tenían, en la mayoría de los casos, un valor económico de
especulación.

Durante las últimas dos décadas se ha manifestado una tendencia que apunta
hacia el incremento del nivel de eficiencia del proceso de manufactura. Un
objetivo es tener menos inventario disponible en proceso, lo cual se conoce
como inventario JIT (Render, 2006).

“En la actualidad se han convertido en un instrumento más para conseguir

satisfacer las necesidades de los clientes, asegurando que los productos llegan
en el momento que los precisa y en la forma y cantidad adecuada”. (Navascués,
2001).

De la misma manera Cos y Navascués (2001) encontraron que la tendencia

hacia la reducción general de nivel de los stocks, e incluso hacia su posible
eliminación, ha provocado una auténtica revolución en las técnicas de

16
organización de empresas. En efecto el análisis de los origines de dichos niveles
de stock o de las causas de su creación demuestran, en la mayoría de casos,
defectos en la estructura de la propia empresa o en su operatividad.

“Los inventarios juegan un papel importante ya que los mismos en un nivel

adecuado permitan un buen desempeño y un equilibrio entre el nivel de servicio
y las afectaciones económicas que ocasionan los mismos inventarios” (Flores,
2004).

11.8. DEFINICIÓN DE INVENTARIOS

Según (Viveros, 2007), El inventario representa la existencia tanto de bienes

muebles como inmuebles, que pertenecen a la empresa y que son susceptibles
de acciones comerciales, generando ingresos económicos directa o
indirectamente relacionados con el ejercicio o actividad básica de la empresa.
Se define inventario como la acumulación de materiales que posteriormente
serán usados para satisfacer una demanda futura.

Por otro lado (Herrera, 2007) afirma que de manera general se puede definir
inventario como la existencia de todo tipo de material, sin procesar o transformar,
procesado total o parcialmente, artículos y productos, que se utilizan de manera
directa o indirecta dentro de las organizaciones manufactureras o de servicio.

11.9. PRINCIPIOS

De acuerdo con (Mónica Míguez Pérez, 2006), se pueden definir los principios
básicos de los inventarios como las razones para mantener y utilizar dichos
inventarios en una empresa. Estos principios son los siguientes:

Desacoplar demanda y producción: esta es la función principal. Podemos

considerar el inventario como un colchón entre la oferta y la demanda.

Ser utilizados como medio para la planificación y el control de la producción: La

empresa debe poseer un inventario de productos terminados para atender a la
demanda.

Permitir cierta flexibilidad en la programación de la producción y la

independencia de las operaciones: Existen empresas que realizan su producción
en lotes cada cierto tiempo, en vez de hacerlo siguiendo fielmente la demanda.
Permitir el tránsito de los ítems entre las distintas etapas del proceso:

A veces existe la necesidad de mover las piezas de un lugar a otro para continuar
el proceso productivo, pero mientras se realiza ese movimiento las máquinas no

17
deben pararse, por lo que es imprescindible que haya un stock de productos en
cada máquina, para poder seguir produciendo.

Proporcionar un buen nivel de servicio al cliente: Esto supone que el cliente

pueda llevarse el producto cuando lo necesite.

Intentar mantener la producción a un ritmo regular: Las operaciones de

fabricación deben realizarse lo más eficientemente posible para así mantener la
producción.

11.10. TIPOS DE INVENTARIO

De acuerdo con (Monks, 1997). Los inventarios son recursos ociosos que
poseen un valor económico. Las empresas generalmente clasifican sus
inventarios como 1) materia prima, 2) productos en proceso o 3) producto
terminado. Todos los inventarios representan una inversión designada para
facilitar las actividades de producción y servir a los consumidores.

Dentro de este marco (Foster, 2007) se refiere a los tipos de inventario: de la

siguiente forma:

Las compañías del sector de manufactura compran materiales y componentes y

los convierten en diversos productos terminados. Por lo general estas empresas
tienen uno o más de los siguientes tres tipos de inventario:

1. Inventario de materiales directos. Materiales directos en existencia, listos para

el proceso de fabricación (por ejemplo, chips de computadora y los componentes
necesarios para fabricar teléfonos celulares).

2. Inventario de productos en proceso. Productos parcialmente elaborados pero

que aún no se terminan (por ejemplo, teléfonos celulares en diversas etapas
antes de ser acabados por completo en el proceso de manufactura). También se
le conoce como producción en proceso.

3. Inventario de productos terminados. Los productos (por ejemplo, teléfonos

celulares) acabados pero que aún no se han vendido.

11.11. COSTOS DE INVENTARIO

De acuerdo con (Müller C. , 2004), Los inventarios traen consigo una serie de
costos. Pueden formar parte de estos costos los siguientes: dinero, espacio,
mano de obra para recibir, controlar la calidad, guardar, retirar, seleccionar,
empacar, enviar y responsabilizarse, deterioro, daño y obsolescencia, hurto, etc.

18
Por lo general, los costos de inventario se clasifican como costos de pedido y
costos de almacenaje. Los costos de pedido, o adquisición, se producen
independientemente del valor real de las mercancías. Tales costos comprenden
los salarios de quienes compran el producto, los costos de despacho, etc.

Por consiguiente, (Müller C. , 2004) también plantea que:

Los costos de almacenaje comprenden los costos del capital inmovilizado en el

inventario (el costo de oportunidad del dinero), los costos de almacenamiento,
por ejemplo el alquiler, y los costos de manejo del producto, entre ellos los del
equipo, el personal de bodegas y de mantenimiento de existencias, las pérdidas
o desperdicios de existencias, los impuestos, etc.

Los costes que afectan la gestión de stocks los podemos agrupar en los
siguientes: Costes de compra, costes de hacer los pedidos, costes de
mantenimiento y costes de ruptura.

Costes de Compra: el coste originado por la adquisición de las existencias, es

igual al precio unitario por el número de unidades que se compran.

El precio de compra o coste de adquisición puede ser independiente de la

cantidad comprada en cada periodo o bien dependiente. Se obtienen descuentos
por volumen de compra, el coste de adquisición dependerá del volumen de lote.
Costes de lanzar un pedido: Estos costes comprenden todos los gastos
ocasionados por el hecho de tramitar la compra. Podrán citar entre ellos:

Salarios de los agentes de los servicios de aprovisionamiento, gastos con motivo

del estudio del mercado de compras, trámites administrativos de lanzar el
pedido: notificaciones por escrito o por teléfono, y los gastos de reclamaciones
de este pedido en el plazo previsto, controles cualitativos y cuantitativos de la
factura de compra, gasto accesorio del funcionamiento de todos los servicios del
departamento de compras, gasto del local, energía eléctrica, calefacción, etc.

Costes de mantenimiento: los costes de mantenimiento son los inherentes a la

existencia misma del stock: los que soporta la empresa por el hecho de tener
existencias.

El stock, cualquiera que sea la naturaleza de los productos o materias que los
componen, representan unos capitales inmovilizados durante un tiempo más o
menos largo. Su valor pertenece al activo de la empresa, pero esta partida del
activo tiene una particularidad, y es que, al contrario que otras de sus partidas,
la realidad física que este valor cubre está en constante modificación.

Costes de ruptura:

19
No tener existencias en el almacén cuesta dinero. Si partimos del fin que justifica
la existencia de los stocks en el almacén, que no es otro que a utilidad que
proporciona un bien al disponer de el en el lugar y en el momento en el que se
necesita, la carencia de los stocks, una vez que es precisa su utilización, supone
unos costes que denominamos costes de ruptura.

11.12. TASA DE ROTACIÓN DE INVENTARIO

De acuerdo con (Müller C. , 2004), la Tasa de rotación de inventario mide cuantas

veces en promedio se renueva el inventario en un periodo de tiempo. En su
sentido más simple, una rotación de inventario sucede cada vez que se recibe
un artículo, se utiliza o se vende, para luego restituirse.
Además de lo anterior también afirma: La rotación de inventario es una medida
importante, por cuanto la capacidad de mover el inventario con rapidez tiene un
efecto sobre la liquidez de la compañía. La rotación de inventario se calcula como
sigue:
Tasa de rotación de inventario = Costo de las mercancías vendidas + inventario
promedio

11.13. PROYECCIÓN DE LA DEMANDA

Según (Heizer, 2004), Los pronósticos de la demanda son proyecciones de la

demanda de productos o servicios de la compañía. Estos pronósticos también
se conocen como pronósticos de ventas y ayudan a orientar los sistemas de
producción, capacidad y programación de la empresa, y sirven como factores en
la planeación financiera, marketing y personal.

También, define al pronóstico de ventas “como un cálculo estimado de ventas

para un período determinado, con el fin de preparar un plan de comercialización”
(Mercado, 2004).

Ahora bien Los métodos más utilizados para su cálculo se agrupan en dos
categorías, Cualitativos y Cuantitativos; siendo la primera enmarcada en
métodos como La Opinión de Expertos, Sistematización de los Encargados de
Ventas, Método Delphi y el Panel de Consenso. En el caso de los cuantitativos,
tenemos métodos como: Análisis de Tendencia, Series de Tiempo y Análisis de
Regresión.

11.14. SISTEMAS DE CONTROL DE INVENTARIOS

Todas las organizaciones cuentan con algún tipo de sistema de control y

planeación de inventarios. Los bancos tienen métodos para llevar a cabo el
control de su inventario de efectivo. Los hospitales también cuentan con

20
procedimientos para llevar el control de sus existencias de sangre y de otros
artículos importantes. (Render, 2006).

Los sistemas de monitoreo periódico y continuo, en sí mismo, son esencialmente

técnicas de espaciamiento de pedidos. Prev zeen el uso de un promedio histórico
como base para solicitar menos pedidos. (Monks, 1997).

A continuación se hará referencia a los Sistemas periódicos y sistemas

perpetuos, los cuales son muy comunes para llevar el control de los inventarios.
Los sistemas periódicos descansan en un conteo de inventario a intervalos
periódicos, tales como semanal o mensual. Es ordenada entonces una cantidad
variable de inventarios en esta base de intervalos fijo. La cantidad ordenada Q
es la necesaria para mantener el intervalo disponible en un nivel específico, el
cual puede ser ajustado para reflejar cambios esperados en la demanda.
(Monks, 1997).

Los sistemas perpetuos son continuos, ya que mantiene un registro actualizado

del nivel de inventarios de cada artículo en base continua. Cuando la cantidad
disponible disminuye a un nivel predeterminado (el punto de reorden), es
ordenada una cantidad fija Q. Esta puede ser un CEP. Algunos sistemas
continuos usan un proceso por lotes para acumular las adiciones de inventarios
y las reducciones de requerimientos en un periodo corto y actualizan los registros
regularmente (por lo general diario) mientras que otros son totalmente en línea,
(Monks, 1997).

Los sistemas de control de inventario monitorean ambos, la demanda y el tiempo

de entrega, (Monks, 1997).

11.15. POLÍTICAS DE INVENTARIO

De acuerdo con Welsch, Glenn y Cols (2005), los objetivos de las políticas de
inventario deben ser: 1) Planificar el nivel óptimo de la inversión en inventarios y
2) A través del control, mantener de manera razonable estos niveles óptimos.

Los niveles de los inventarios deben mantenerse entre dos extremos: un nivel
excesivamente elevado (que origina costos excesivos de mantenimiento de
inventarios) y un nivel insuficiente para satisfacer en forma oportuna las
demandas de ventas y de producción (que genera un costo elevado por falta de
existencias). Una consideración importante, al controlar y planificar los
inventarios, es la de que éstos deben absorber la diferencia en las existencias,
entre los niveles del volumen de venta y el de la producción (o compras).

A menudo, los gerentes realizan ajustes que incrementan los niveles de los
inventarios. Estas decisiones de política sobre manufactura y operaciones

21
deberían quedar bien sustentadas en el análisis de costos. (Evertt E Adam,
1989).

11.16. DEMANDA DEPENDIENTE E INDEPENDIENTE

De acuerdo con (Monks, 1997), un inventario de demanda dependiente está

compuesto por las materias primas, los componentes, y los sub ensambles que
son usados en la producción de artículos que sirven para la fabricación de otros
artículos o para la fabricación de productos finales. Por ejemplo la demanda de
teclados de computadora depende del artículo original, las computadoras.
El autor también afirma que los inventarios de demanda independiente constan
de los productos terminados, las partes de servicio, y otros artículos cuya
demanda aumenta más directamente del ambiente incierto de mercado. Las
demandas dependientes normalmente pueden calcularse, mientras que las
demandas independientes usualmente requieren alguna clase de pronóstico.
“En los inventarios sujetos a demanda independiente, la demanda de un
elemento que se lleva en inventario es independiente de la demanda de
cualquier otro elemento que se lleve también en dicho inventario” (Gaither,
2003).

Según expresa (Sabater J. P., 2004)

Se considera demanda independiente la que únicamente está limitada por las
decisiones de los clientes que no pueden ser anticipadas. Al contrario, se
considera demanda dependiente a la de aquellos componentes, sub montajes o
productos cuya cantidad es resultado de definir unos niveles de compra o
fabricación para otros productos

11.17. TIEMPO DE ENTREGA O TIEMPO DE ANTICIPACIÓN

“Los stocks tienen una relación directa con el tiempo. La disponibilidad de tiempo
productivo no se puede almacenar, sin embargo si se puede almacenar el
producto fabricado. Así si se pudiera fabricar de modo instantáneo no haría falta
stock de producto acabado” (Sabater J. P., 2004).

Se define como el tiempo que transcurre entre el momento en que se coloca una
orden, y el momento en que se recibe ese pedido, siempre y cuando la orden se
haga por medio de una compra.”

El autor también dice que cuando el inventario se produce, el tiempo de entrega

se define como el tiempo que transcurre entre el momento en que se coloca la
orden de producción, y el momento en que se comienza a fabricarse esa orden
de producción.

22
 11.18. EL ANALISIS ABC

El análisis ABC permite identificar los artículos que tienen un impacto importante
en un valor global (de inventario, de venta, de costes....). Permite también crear
categorías de productos que necesitaran niveles y modos de control distintos.

Ejemplo aplicable a la gestión de stock:

 "Clase A" el stock que incluirá generalmente artículos que representan el

80% del valor total de stock y 20% del total de los artículos. En esto la
clasificación ABC es una resultante del principio de Pareto.
 "Clase B" los artículos que representan el 15% del valor total de stock y
40% del total de los artículos.
 "Clase C " los artículos que representan el 5% del valor total de stock y
40% del total de los artículos.

A continuación se presentan las etapas para realizar un análisis ABC.

 Seleccionar un criterio (ventas/uso) basado en niveles de importancia.
 Clasificar los productos del inventario de acuerdo a este criterio.
 Calcular las ventas o uso acumulado para todos los productos.
 Clasificar los productos en grupo A, B, C según su importancia y los
factores cualitativos.
 Asignar niveles de inventario y espacio en almacén para cada producto.
(Sabater J. P., 2004).

11.19. DIAGRAMA DE PARETO

En 1907 el economista italiano Wilfredo Pareto (1848-1923) expreso su creencia

de que en Italia entre el 80 y 85 por ciento del dinero lo tenía solo entre el 15 y
el 20 de la población del país. Al grupo pequeño le denomino “minoría vital” y a
todos los demás “mayoría trivial”. Con el tiempo se conoció a esto como la “Regla
80-20” o ley de Pareto. (Müller, 2007).

Aplicación del análisis de Pareto.

Para establecer la clasificación ABC y su representación gráfica mediante la

curva de Pareto debemos seguir los pasos siguientes:
Primero: se ordenan los artículos de mayor a menor valor. Partiendo de la
variable a utilizar (existencias medias, ventas, beneficio, valor de la inversión,
etc.).

Segundo: calculamos él % que representa cada artículo sobre la inversión total.

Tercero: obtenemos la inversión acumulada del stock, es decir, las existencias
absolutas acumuladas.
Cuarto: Calculamos el % de inversión acumulada.

23
Quinto: Representamos gráficamente los valores obtenidos.

11.20. CONSTRUCCIÓN DE LA GRÁFICA DE PARETO

Los resultados del análisis ABC se representan mediante una gráfica

denominada Curva de Pareto. Se establece una relación entre el valor de la
inversión y los productos almacenados; para ello, se representa en el eje de las
abscisas los porcentajes acumulados de los artículos y en el de las ordenadas
los porcentajes acumulados del importe de la inversión como se muestra en la
grafico 1:

Ilustración 1. Gráfico de Pareto

Fuente: Escudero 2009

11.21. RAZONES PARA DIFERENCIAR ENTRE PRODUCTOS

SEGÚN SU CRITERIO CUANTITATIVO

Los motivos que hacen interesante diferenciar entre productos según su criterio
cuantitativo son varios entre ellos se consideran más importante los siguientes:

 Lo que no se puede medir no se puede mejorar, y el análisis ABC es un

medio que permite medir.

 Dado que el coste del servicio al cliente es elevado y los recursos

limitados no parece adecuado tratar todos los productos por igual.

 Dado que no todos los productos se solicitan igual el nivel de cumplimiento

no afecta igualmente a todos los productos.

24
  No todos los productos son igualmente rentables ni la falta de todos los
productos igualmente importante. (Sabater J. P., 2004).

11.22. ESTRATEGIAS DE GESTIÓN DE INVENTARIO

Después de haber aplicado el método de clasificación ABC para el inventario de

la empresa en mención, se procede a realizar sobre la clasificación aplicaciones
de métodos que permitan ayudar a resolver interrogantes sobre los inventarios,
como son los de ¿Cuánto pedir? Y ¿Cuándo pedir?, para esto se utilizara el
modelo de cantidad optima a pedir, sobre los artículos clasificados en el grupo
A, ya que estos merecen mayor atención, según la clasificación realizada.

11.23. CANTIDAD ÓPTIMA A PEDIR

Para la utilización de este modelo, es necesario tener en cuenta los siguientes

supuestos:

Este modelo se puede aplicar cuando la demanda de un producto posee una

tasa que es constante, o casi, y cuando la cantidad total que se pide llega al
inventario en un punto del tiempo. Es muy raro que en la práctica se encuentre
un producto cuya demanda sea constante. Sn embargo, al hacer esta
suposición, se puede obtener la cantidad de pedido que corresponda al mínimo
costo total.

El CEP puede llevar a la empresa una política de inventario óptima y de bajo

costo.

11.24. GESTIÓN DE ALMACENES

Según (Gutierrez, 2007), el almacenamiento consiste en la ubicación de los

productos recibidos en el lugar que les corresponde, de acuerdo con su módulo
de almacenaje.

Esta necesidad de almacenar surge por el hecho de regular la producción con la

demanda, debido a que esta última presenta en muchos casos una curva
irregular y en otros lapsos de tiempo puede ser estacional, mientras que si se
habla de la producción suele efectuarse atendiendo a los ritmos de grandes
series.

25
 11.25. FUNCIONES DEL ALMACÉN.

Se entiende por concepto de función como un conjunto de actividades

relacionadas entre sí, la función general de almacén se puede decir que es el
conjunto de actividades desarrolladas con mercancías y productos que hay que
mover y conservar para el cumplimiento de los fines productivos y comerciales
previstos en el ciclo de operaciones de la empresa.

Según (Gómez, 2006), las funciones del almacén son las de recepción de
mercancías, almacenamiento, conservación y manutención, expedición,
organización, inspección y control de existencias.

A modo general los almacenes atienden a tres funciones las cuales se pueden
expresar como la de coordinador de los desequilibrios entre la oferta y la
demanda, es el hecho de que la demanda de un producto no siempre coincide
en tiempo y cantidad con su oferta por lo que se hace necesario tener cierto
inventario dado que la demanda insatisfecha de un cliente por alguna
eventualidad puede provocar la pérdida del mismo. Otra función de almacén es
la de servir como reductora de costes, esto se produce cuando es más rentable
adquirir grandes lotes de artículos y transportarlos en cargas consolidadas hacia
lugares de almacenamiento cercano que adquirir lotes más pequeños para
satisfacer demandas puntuales. Y la función del almacén como complemento del
proceso productivo, siempre y cuando el producto final necesite de un proceso
anterior de tratado como un periodo de maduración o de enfriado para su previo
consumo.

11.26. GASTOS DE ALMACENAMIENTO.

Según (Tejero J. J., 2008), se puede decir que un almacén debe responder
fundamentalmente a los requerimientos de un espacio debidamente
dimensionado, para una ubicación y manipulación eficiente de materiales y
mercancías, teniendo en cuenta que el 48% es gasto de personal, 42% espacio
ocupado y 10% equipos.

Sin embargo, con la evolución de los almacenes la implementación de técnicas

más avanzadas como la mecanización o la robótica han hecho que la forma en
que se distribuyen los gastos cambia, siendo el gasto por mantener estos
equipos más altos que los gastos del personal.

11.27. COSTOS DE ALMACENAMIENTO

La excelencia de la logística del almacén no solo se debe juzgar por los

rendimientos o tiempos de respuesta de los diferentes procesos operativos, si

26
no que se deben conocer el coste de los recursos invertidos para conseguir los
objetivos, todo esto ayudara a establecer políticas de mejoras e inversiones.
Según (Tejero J. J., 2008), se pueden mencionar entre estos costes los
siguientes: coste de almacenamiento de los productos, coste de manipulación
de los productos y coste de posesión de los stocks.

11.28. GESTIÓN DE ALMACÉN

La forma en que funcionan la mayoría de los almacenes existentes es

susceptible a ser mejorada. Las razones son varias. Debido a que puede que su
plan inicial tuvo en cuenta datos de la época en que se proyectaron. Desde
entonces, la experiencia de la empresa ha podido cambiar, entendiendo que
sobre este influyen los clientes, los pedidos, y el inventario.

Por otro lado, ha habido varios cambios, apareciendo métodos de análisis más
precisos, así como equipos nuevos y más eficientes para los procesos, sin dejar
de lado a las nuevas tecnologías de la información, que a su vez se introducen
fácil y rápidamente en la gestión de los mismos.

Cuando se habla de almacén, puede que a las personas que no se encuentran

enteradas del tema, les pase por la cabeza diferentes conceptos en función de
las prácticas de su diario vivir, por ejemplo pueden entender fácilmente que no
es igual un almacén de frutas para distribución, que un almacén de cuero para
la elaboración de zapatería. Se puede entender que los requerimientos son
totalmente diferentes.

(F, 2006) Afirma: “cualquier tipo de almacén realiza unas funciones comunes
y mínimas, sobre la base de las cuales podemos identificar los procesos para su
gestión a saber: aprovisionamiento, entrada y ubicación de material, salida y
distribución de artículos, gestión de stock.”.

Se puede decir que mientras la disponibilidad es fundamentalmente

responsabilidad directa del gestor del inventario, ya que es quien tiene que
decidir el nivel de stocks requerido en el almacén, la rapidez y fiabilidad de las
entregas dependen en gran medida de una correcta gestión de la función de
almacenaje. Según Anaya J (2008), “el objetivo fundamental de una correcta
gestión de almacenes se basa en el principio de conseguir el grado de servicio
requerido por el mercado, a un nivel de costes aceptables para la empresa”.

11.29. DIAGNÓSTICO DEL ALMACÉN

A continuación se profundiza en los procesos de almacén teniendo en cuenta la

situación actual de la empresa.

27
 11.30. PROCESOS DE ALMACÉN

 Recepción

Proceso de recibimiento de los materiales que se utilizan en planta, incluye el

conteo, inspección y registro de datos en sistema.

 Preparación

Proceso de disponer la materia terminada en el empaque y embalaje adecuado,

según sea el destino que tenga dichos materiales.

 Almacenamiento

Proceso de acopiar temporalmente las materias primas o productos en proceso.

Actualmente se almacenan en tanques las tuberías de cobre cortadas, cajas los
otros insumos y son guardados en racks.

 Despacho

Proceso de enviar los productos terminados a los clientes internos y externos,

correctamente embalados, de manera oportuna y al lugar solicitado, a los
clientes internos se les envía la materia en proceso en cajas o baldes según sea
el tipo.

 Embalajes

El embalaje son todos los materiales, procedimientos y métodos que sirven para
acondicionar, presentar, manipular, almacenar, conservar y transportar la
mercancía, actualmente la persona responsable de esta actividad, prepara
la mercancía para la entrega, recubriendo con diferentes materiales de
conservación que van desde bolsas, láminas de cartón y material impermeable.

 Delimitación

Son métodos y mecanismos utilizados para realizar trabajos, reparaciones,

mantenimiento o limpieza, actividad la cual debe llevarse a cabo por personal
especializado que haya acreditado esta condición, actualmente en la planta no
se encuentra ninguna de las áreas de trabajo señalizadas como tal.

11.31. DESARROLLO DE SOFTWARE

(Winder, 1995) El desarrollo de un sistema basado en una computadora es la

actividad consistente en transformar una idea para utilizar en un sistema de
computadoras en un sistema que funcione.

28
Aunque la programación es una actividad individual dentro de un desarrollo de
software (un subconjunto de las actividades necesarias para desarrollar un
sistema de software completo), se trata de un microcosmos de la ingeniería del
software.

11.32. USABILIDAD COMO PRINCIPAL OBJETIVO EN EL

DESARROLLO WEB

(Durango, 2015) Usabilidad es la medida de la facilidad del usuario para ejecutar

alguna funcionalidad del sistema. Esa facilidad está conectada directamente a la
comprensibilidad, a la facilidad de aprendizaje, a la operabilidad, a cuanto el
usuario se siente atraído por el sistema y a la adhesión de estándares de
usabilidad, que son las sub-características de la usabilidad:

 Comprensibilidad, o la capacidad del usuario para entender el sistema.

Esta característica está conectada a la cantidad de conceptos que el
usuario necesita saber previamente para trabajar con el sistema o a la
calidad o cantidad de la documentación del sistema. La comprensibilidad
sirve para que el usuario decida si el software sirve para él o no.
 La facilidad de aprendizaje está conectada directamente a la
comprensibilidad. Sin embargo en este caso, la calidad es que el usuario
aprenda a usar el software, si él sabe que el software sirve para él. Las
métricas de esa calidad también están relacionadas a la cantidad de
conceptos u operaciones que el usuario necesita aprender para hacer que
el software funcione.

11.33. OPERABILIDAD

Operabilidad es la capacidad del usuario para operar y controlar el sistema. Esta

calidad es muy importante en grandes sistemas de software, donde hay un tipo
de usuario que es el administrador del sistema. El administrador desea ser capaz
de realizar operaciones sobre el sistema que, comúnmente, no están entre las
funciones que interesan a los usuarios más comunes: conectar, desconectar o
verificar estado de servidores, realizar backup de los datos etc. En sistemas de
redes sociales, por ejemplo, entre los servicios proporcionados al operador, está
la posibilidad de expulsar usuarios del sistema o moderarlos, no permitiendo que
esos usuarios realicen algunas funciones, como enviar mensajes o eliminando
conexiones de acuerdo con la dirección de origen. (Durango, 2015)

29
 11.34. NAVEGADORES DE INTERNET

Un navegador web es un programa que permite visualizar páginas escritas en

HTML o en otros lenguajes de programación web, que estén alojadas en el
equipo en una red local o en internet.

La navegación es posible a través de los hipervínculos que contiene la página

web y mediante el uso de los botones de herramientas presentes en el
navegador.

Los navegadores más utilizados son Internet Explorer, Mozilla Firefox, Safari y
Google Chrome.

Cada navegador tiene sus peculiaridades, que van cambiando con frecuencia en
las sucesivas versiones o con el añadido de complementos. Todos ellos
incorporan herramientas de personalización, configuración de seguridad,
navegación hacia atrás, hacia adelante o sobre el historial, gestión de favoritos,
pagina (para buscar algo en la página actual, ampliar mediante zoom, cambiar
el tamaño de los caracteres, etc.). (Purificacion Aguilera, 2012)

11.35. ARQUITECTURA CLIENTE SERVIDOR.

Según (Falgueras, 2003) La idea básica de la arquitectura cliente/servidor es que

un programa, gestiona un recurso compartido concreto y hace determinadas
funciones solo cuando las pide otro, el cliente, que es quien interactúa con el
usuario.

Un ejemplo sencillo de entorno cliente/servidor seria tener un sistema de gestión

de bases de datos activado en un servidor, y que los programas que se ejecutan
en los ordenadores clientes pudiesen emitir instrucciones de SQL para acceder
a esta base de datos.

Normalmente, estos dos programas, el servidor y el cliente, están en

ordenadores distintos.

Los requerimientos de los ordenadores clientes en lo que respecta a velocidad,

memoria y capacidad de disco son muy diferentes de los servidores; unos y otros
pueden ser ordenadores de modelo y marca diferente y, además, con frecuencia
utilizan un sistema operativo diferente.

30
 11.36. VENTAJAS E INCONVENIENTES DE LA ARQUITECTURA
CLIENTE/SERVIDOR

11.36.1. Las ventajas de la arquitectura cliente/servidor

son las siguientes:

a) Permite que la información se procese cerca de donde se ha generado.

b) Dado que las funciones del software quedan repartías entre varias
máquinas, es posible utilizar pc o estaciones de trabajo para los clientes,
y maquinas UNIX (por ejemplo) para los servidores, todas de un coste
mucho menor que los mainframes.

c) El crecimiento de hardware puede ser gradual:

 Se puede aumentar gradualmente el número de clientes sin que sea

necesario cambiar cada vez el servidor.

 Se puede sustituir el servidor sin que los clientes se vean afectados.

 Se puede aumentar la capacidad de un cliente sin tener que cambiar ni el

servidor ni a los otros clientes.

 En algunas modalidades, se pueden añadir servidores sin tener que

rediseñar la arquitectura en su conjunto.

d) Facilita el uso de interfaces graficas de usuario y aplicaciones multimedia;

la razón es que estas funciones necesitan el tratamiento de un volumen
importante de información. Este tratamiento, se tuviese que hacer de
forma centralizada, necesitaría un host de gran capacidad y unos envíos
de información muy considerables mediante las líneas.

Muchas de estas ventajas significan simplemente que se consiguen en

mayor o menor grado, los objetivos de los entornos distribuidos.

11.37. LOS INCONVENIENTES DE LA ARQUITECTURA

CLIENTE/SERVIDOR SON LAS SIGUIENTES:

a) El servidor puede ser cuello de botella.

b) El software distribuido es más complejo que el no distribuido, y también

es más difícil probarlo y depurar errores en él; también la administración
y la problemática de seguridad son bastantes más complejas.

31
 c) Cualquier sistema distribuido tiende a fallar con más frecuencia que un
sistema centralizado, ya que tiene más componentes que pueden fallar
independientemente.

11.38. INGENIERÍA DE SOFTWARE

La ingeniería del software comprende los métodos y las técnicas que se utilizan
en el desarrollo profesional del software. Se trata de un campo muy amplio, del
cual esta materia solo trata una parte.

La ingeniería del software consta principalmente de dos familias de técnicas:

 Las estructuradas, cronológicamente las más antiguas.
 Las orientadas a objetos (OO), que constituyen la parte principal de esta
obra, con la exclusiones mencionadas. (Falgueras, 2003)

11.39. CALIDAD DE SOFTWARE

Es la concordancia con los requerimientos funcionales y de rendimiento

explícitamente establecidos, con los estándares de desarrollo explícitamente
documentados y con las características implícitas que se esperan de todo
software desarrollado profesionalmente. (Falgueras, 2003)

Existen 3 puntos importantes de la definición de calidad de software:

1- Los requerimientos del software son los fundamentos desde los que se
mide la calidad.

2- Los estándares específicos definen un conjunto de criterios de desarrollo

que guían la forma de aplicación de la ingeniería de software

3- Existen requerimientos implícitos que no se mencionan

Un producto de alta calidad requiere menos mantenimiento y facilita tanto el

desarrollo como el mantenimiento de la productividad. Con la medición de la
calidad se pueden lograr estos objetivos. En lo que se refiere al mantenimiento,
la medición de la calidad del software ayuda a identificar problemas de
confiabilidad y a mejorar las técnicas para identificar las necesidades de
mantenimiento.

11.40. CONFIABILIDAD

Es la probabilidad de operación libre de fallas de un programa de computadora

en un entorno determinado y durante un tiempo específico.

32
El fallo es cualquier no concordancia con los requerimientos del software. Hay
distintos grados de fallos, estos pueden ser simplemente desconcertantes o
catastróficos.

La confiabilidad del software se encuentra en un etapa de formación de

desarrollo y es la característica de rendimiento más costosa de conseguir y difícil
de conseguir y de difícil de garantizar. La naturaleza del proyecto ayuda para la
formulación de estimaciones de costo y el esfuerzo que asegure la confiabilidad
requerida.

Los modelos de confiabilidad del software se usan para caracterizar y predecir

el comportamiento importante para directores e ingenieros.

La generación de fallos depende del código desarrollado, tales como tamaño y

las características del proceso de desarrollado tales como las tecnologías y
herramientas de ingeniería de software usadas.

La eliminación de fallos depende del tiempo y del perfil operativo. Los modelos
de confiabilidad del software son generalmente procesos aleatorios. Estos
modelos se pueden dividir en 2 grandes categorías:

1- modelos que predicen la confiabilidad como una función cronológica del

tiempo

2- modelos que predicen la confiabilidad como una función del tiempo de

procesamiento transcurrido.

11.41. CONTROL DE CALIDAD

El costo de corregir y detectar errores producidos en las primeras fases de

desarrollo de software es mayor a medida que nos encontramos más alejados
de éstas. A causa de esto, la propuesta de control de calidad es empujar las
tareas relacionadas con la calidad desde las primeras fases del proyecto. Esto
permite encontrar los errores en forma temprana sin que se sigan propagando
en las siguientes fases.

Otro motivo para el control de calidad es que la prueba de software no puede

garantizar que encuentre todos los errores. Los programadores profesionales
pueden y deben producir software el cual esté libre de errores desde el
comienzo. Esto puede ser llevado a cabo a través del control de calidad.

33
 11.42. LA GARANTÍA DE CALIDAD DE SOFTWARE ENGLOBA:

1- métodos y herramientas de análisis, diseño, codificación y prueba

2- revisiones y técnicas formales que se aplican en cada fase de la ingeniería de
software
3- una estrategia de prueba multi-escala
4- el control de la documentación del software y de los cambios efectuados
5- un procedimiento que asegure un ajuste a los estándares de desarrollo
6- mecanismos a medida y de información

11.43. REVISIONES DE TÉCNICAS FORMALES

11.43.1. Objetivos

1- descubrir errores en la función, la lógica o la implementación del software

2- verificar que el software bajo revisión alcanza sus requerimientos
3- garantizar el uso de estándares predefinidos
4- conseguir que el software se desarrolle de forma uniforme
5- hacer que los proyectos sean más manejables

11.43.2. Directrices de la revisión

1- revisar el producto no productor

2- fijar agenda y mantenerla
3- enunciar problemas no resueltos
4- limitar el debate y las impugnaciones
5- tomar notas
6- limitar el número de participantes
7- desarrollar una lista de comprobaciones para cada producto que pueda ser
revisado
8- disponer de recursos y planificación de tiempos
9- entrenar los participantes
10- reparar las revisiones anteriores

11.44. PLANIFICACIÓN Y ESTÁNDARES DE LA GARANTÍA DE

CALIDAD DE SOFTWARE

Tareas que se deben llevar a cabo en un plan de GCS:

1- revisión del diseño del sistema

2- revisión de requerimientos de software
3- revisión del diseño preliminar
4- revisión del diseño detallado (a nivel módulos)

34
5- revisión del plan de prueba de integración
6- revisión del código
7- revisión de los procedimientos
8- auditorías de los estándares de documentación
9- auditorías del control de configuración
10- auditorías de prueba
11- recolección, evaluación y análisis de los datos de defectos
12- certificación de herramientas
13- mantenimiento de registros
(Falgueras, 2003)

12. ENFOQUE METODOLÓGICO

Desarrollar una aplicación que sea útil y adaptable a la necesidad de la empresa

para su organización de compras, inventarios y ventas manera que tengan un
mayor y ágil beneficio

La metodología del proyecto incluye el tipo o tipos de investigación, las técnicas

y los instrumentos que serán utilizados para llevar a cabo la investigación. Es el
“cómo” se realizará el estudio para responder el problema planteado. En
términos científicos se puede decir que la investigación es un proceso
metódico y sistemático dirigido a la solución de problemas o preguntas
científicas, mediante la producción de nuevos conocimientos, los cuales
constituyen la solución o respuestas a tales interrogantes. (Arias, 2012)

El diseño de la investigación está conformado por un conjunto de aspectos que

han de considerarse, entre ellos se tienen: definir el tipo de
investigación, la modalidad de la misma, los pasos a seguir para abordar cada
uno de los objetivos, las técnicas (medios empleados para recolectar el dato e
información) e instrumentos que se emplearan de acuerdo a la naturaleza del
datos e información, las fuentes de información (primarias y secundarias).

12.1. TIPO Y DISEÑO DE INVESTIGACIÓN

El diseño de la investigación es una estrategia de acción para desarrollar el

proyecto propuesto de acuerdo a las etapas y momentos que se requiere, todo
ello depende del tipo de investigación que se opte.

Según (Peñaloza, 2008). Su objeto es proporcionar un modelo de verificación

que permita contrastar hechos con teorías, y su forma es la de una estrategia o
plan general que determina las operaciones necesarias para hacerla.

35
El estudio del presente proyecto se encuentra apoyado en una investigación de
campo, debido a que el levantamiento y recaudación de la información y datos
se obtienen directamente de la realidad, es decir, del lugar en donde se
desarrolla el proyecto. En este sentido se trata de investigaciones a partir de
datos originales o primarios.

La investigación de campo es aquella que consiste en la recolección de datos

directamente de los sujetos investigados, o de la realidad donde ocurren
los hechos (datos primarios), sin manipular o controlar variable alguna, es decir,
el investigador obtiene la información pero no altera las condiciones existentes.
De allí su carácter de investigación no experimental. (Arias, 2012).

12.2. MODALIDAD DE INVESTIGACIÓN

Por tratarse del desarrollo de actualizar el sistema actual con una aplicación que
gestione, controle e informe en tiempo real las compras, inventario y ventas de
la empresa, el proyecto se encaja dentro de un proceso de desarrollo de
software.

De acuerdo a lo definido por (Sommerville, 2005) el proyecto de desarrollo de

software es “un conjunto de actividades y procesos asociados que producen un
producto de software”. En este sentido, las actividades fundamentales comunes
para todos los procesos del software son agrupadas en cuatro por el mismo
autor, a saber:

1. Especificación del software: donde los interesados en el uso del mismo

conjuntamente con los expertos definen el software a producir y las restricciones
sobre su operación.

2. Desarrollo del software: donde el software se diseña y programa.

3. Validación del software: para asegurar que el producto software obtenido

satisfaga las expectativas y requerimientos previamente establecidos.

4. Evolución del software: donde el software se modifica para adaptarlo a los

cambios requeridos en el contexto de su aplicación, a lo largo del tiempo.

Teniendo en cuenta los objetivos y alcances del proyecto planteado, se

pretenden alcanzar todas las actividades descritas anteriormente para cubrir con
todas las expectativas de este trabajo.

La gestión del proyecto de software es el primer nivel del proceso de ingeniería

de software, porque cubre todo el proceso de desarrollo. Para conseguir un
proyecto de software fructífero se debe comprender el ámbito del trabajo a

36
realizar, los riesgos en los que se puede incurrir, los recursos requeridos, las
tareas a llevar a cabo, el esfuerzo a consumir y el plan a seguir

13. MODELO TEÓRICO.

En la actualidad, para llevar a cabo el desarrollo de aplicaciones es casi

imposible omitir el uso de las metodologías, debido a la gran necesidad de llevar
el control de las variables que conllevan al desarrollo del mismo, y para la
ordenada elaboración de las aplicaciones, por lo tanto, seguir
metodologías y estándares nos llevan al éxito.

Desde el punto de vista de la Ingeniería del Software, es importante dotar de

mecanismos adecuados, para que la realización de Servicios Web satisfaga las
necesidades de los usuarios al cual será dirigido. Sin embargo, en la actualidad
no existe un método universalmente aceptado que guíe el proceso de desarrollo
e integración de Arquitectura Orientados a Servicios (SOA).

Actualmente, para el desarrollo de Servicios Web, se usan metodologías

implementadas para la realización de software tradicionales ya que en
cuanto a arquitectura y diseño no son tan diferentes a los SOA, entre las
metodologías más usadas para el desarrollo de software orientados a servicios
podemos mencionar: orientadas a objetos, propietarias, ágiles, informales, entre
otras.

Es de suma importancia elegir la metodología adecuada, así como las

herramientas de implementación, ya que el software debe ser pensado, diseñado
y desarrollado como un producto sujeto a normas de calidad. Es por ello que
para el presente proyecto se usara como guía metodología el Proceso Unificado
Racional, Rational Unified Process en inglés, y sus siglas RUP, adaptado a la
arquitectura de software basado en servicios con ayuda del Método Para El
Desarrollo de Servicios Web “DESWeb”, desarrollado por (Diaz, 2006) Mérida,
Venezuela.

Según (Ivar Jacobson, 2000) El nombre Proceso Unificado se usa para describir
el proceso genérico que incluye aquellos elementos que son comunes a la
mayoría de los refinamientos existentes.

RUP, es un proceso de desarrollo de software y junto con el Lenguaje Unificado

de Modelado UML, constituye la metodología estándar más utilizada para el
análisis, implementación y documentación de sistemas orientados a objetos.
RUP es un proceso que define claramente quien, cómo, cuándo y qué debe
hacerse para lograr el óptimo desarrollo del proyecto, no es un sistema con
pasos firmemente establecidos, sino que trata de un conjunto de metodologías
adaptables al contexto y necesidades de cada organización, donde el software

37
es organizado como una colección de unidades atómicas llamados objetos,
constituidos por datos y funciones, que interactúan entre sí.

13.1. CARACTERÍSTICAS ESENCIALES DE RUP

Es importante mencionar que los diferentes autores que describen RUP

destacan que el proceso de software propuesto por esta metodología tiene tres
características esenciales: está dirigido por los Casos de Uso, está centrado en
la arquitectura, y es iterativo e incremental.

1. PROCESOS DIRIGIDOS POR CASOS DE USOS: Los Casos de Uso

constituyen un elemento integrador y una guía del trabajo. En RUP los
constituyen una herramienta para especificar los requisitos del sistema,
guían su diseño, implementación y prueba.

Según Kruchten, P(2000), los Casos de Uso son una técnica de captura de
requisitos que fuerza a pensar en términos de importancia para el usuario y no
sólo en términos de funciones que sería bueno contemplar. Los Casos de Uso
representan los requisitos funcionales del sistema. (Falgueras, 2003)

2. PROCESO CENTRADO EN LA ARQUITECTURA: En el caso de RUP

además de utilizar los Casos de Uso para guiar el proceso se presta especial
atención al establecimiento temprano de una buena arquitectura que no se vea
fuertemente impactada ante cambios posteriores durante la construcción y el
mantenimiento. Además la definición de la arquitectura debe tomar en
consideración elementos de calidad del proyecto de software, rendimiento,
reutilización y capacidad de evolución por lo que debe ser flexible durante todo
el proceso de desarrollo.

3. ITERATIVO E INCREMENTAL: La estrategia que se propone en RUP es tener

un proceso iterativo e incremental en donde el trabajo se divide en partes más
pequeñas o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso
y arquitectura se vaya logrando durante cada mini proyecto, y así durante todo
el proceso de desarrollo. El proceso iterativo e incremental consta de una
secuencia de iteraciones. Cada iteración aborda una parte de la funcionalidad
total, pasando por todos los flujos de trabajo relevantes y refinando la
arquitectura.

13.2. RATIONAL UNIFIED PROCESS (RUP)

Este documento presenta un resumen de Rational Unified Process (RUP). Se

describe la historia de la metodología, características principales y estructura del

38
proceso. RUP es un producto comercial desarrollado y comercializado por
Rational Software, una compañía de IBM.

13.3. HISTORIA

La Figura 1 ilustra la historia de RUP. El antecedente más importante se ubica

en 1967 con la Metodología Ericsson (Ericsson Approach) elaborada por Ivar
Jacobson, una aproximación de desarrollo basada en componentes, que
introdujo el concepto de Caso de Uso. Entre los años de 1987 a 1995 Jacobson
fundó la compañía Objectory AB y lanza el proceso de desarrollo Objectory
(abreviación de Object Factory).

Ilustración 2. Historia de RUP

Posteriormente en 1995 Rational Software Corporation adquiere Objectory AB y

entre 1995 y 1997 se desarrolla Rational Objectory Process (ROP) a partir de
Objectory 3.8 y del Enfoque Rational (Rational Approach) adoptando UML como
lenguaje de modelado.

Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James

Rumbaugh, Rational Software desarrolló e incorporó diversos elementos para
expandir ROP, destacándose especialmente el flujo de trabajo conocido como
modelado del negocio. En junio del 1998 se lanza Rational Unified Process.

13.4. CARACTERÍSTICAS ESENCIALES

Dirigido por Casos de Uso

Los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar
en términos de importancia para el usuario y no sólo en términos de funciones
que sería bueno contemplar. Se define un Caso de Uso como un fragmento de

39
funcionalidad del sistema que proporciona al usuario un valor añadido. Los
Casos de Uso representan los requisitos funcionales del sistema.
En RUP los Casos de Uso no son sólo una herramienta para especificar los
requisitos del sistema. También guían su diseño, implementación y prueba. Los
Casos de Uso constituyen un elemento integrador y una guía del trabajo como
se muestra en la Figura 2.

Ilustración 3. Los Casos de Uso integran el trabajo

Los Casos de Uso no sólo inician el proceso de desarrollo sino que proporcionan
un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que
son generados en las diferentes actividades del proceso de desarrollo.

Como se muestra en la Figura 3, basándose en los Casos de Uso se crean los

modelos de análisis y diseño, luego la implementación que los lleva a cabo, y
se verifica que efectivamente el producto implemente adecuadamente cada
Caso de Uso. Todos los modelos deben estar sincronizados con el modelo de
Casos de Uso.

Ilustración 4. Trazabilidad a partir de los Casos de Uso

40
 13.5. PROCESO CENTRADO EN LA ARQUITECTURA

La arquitectura de un sistema es la organización o estructura de sus partes más

relevantes, lo que permite tener una visión común entre todos los involucrados
(desarrolladores y usuarios) y una perspectiva clara del sistema completo,
necesaria para controlar el desarrollo.

En el caso de RUP además de utilizar los Casos de Uso para guiar el proceso
se presta especial atención al establecimiento temprano de una buena
arquitectura que no se vea fuertemente impactada ante cambios posteriores
durante la construcción y el mantenimiento.

Cada producto tiene tanto una función como una forma. La función corresponde
a la funcionalidad reflejada en los Casos de Uso y la forma la proporciona la
arquitectura. Existe una interacción entre los Casos de Uso y la arquitectura, los
Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la
arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos,
actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos de
Uso deban evolucionar en paralelo durante todo el proceso de desarrollo de
software.

En la Figura 4 se ilustra la evolución de la arquitectura durante las fases de

RUP. Se tiene una arquitectura más robusta en las fases finales del proyecto.
En las fases iniciales lo que se hace es ir consolidando la arquitectura por medio
de baselines y se va modificando dependiendo de las necesidades del
proyecto.

Ilustración 5. Evolución de la arquitectura del sistema

Es conveniente ver el sistema desde diferentes perspectivas para comprender

mejor el diseño por lo que la arquitectura se representa mediante varias vistas
que se centran en aspectos concretos del sistema, abstrayéndose de los
demás. Para RUP, todas las vistas juntas forman el llamado modelo
4+1 de la arquitectura, el cual recibe este nombre porque lo forman las vistas
lógica, de implementación, de proceso y de despliegue, más la de Casos de Uso
que es la que da cohesión a todas.

41
 13.6. PROCESO ITERATIVO E INCREMENTAL

El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy

parecido al equilibrio de la forma y la función en el desarrollo del producto, lo
cual se consigue con el tiempo. Para esto, la estrategia que se propone en RUP
es tener un proceso iterativo e incremental en donde el trabajo se divide en partes
más pequeñas o mini proyectos. Permitiendo que el equilibrio entre Casos de
Uso y arquitectura se vaya logrando durante cada mini proyecto, así durante todo
el proceso de desarrollo. Cada mini proyecto se puede ver como una iteración
(un recorrido más o menos completo a lo largo de todos los flujos de trabajo
fundamentales) del cual se obtiene un incremento que produce un crecimiento
en el producto.

Una iteración puede realizarse por medio de una cascada como se muestra en
la Figura 5. Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño,
Implementación y Pruebas), también existe una planificación de la iteración, un
análisis de la iteración y algunas actividades específicas de la iteración. Al
finalizar se realiza una integración de los resultados con lo obtenido de las
iteraciones anteriores.

Ilustración 6. Una iteración RUP

El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada

iteración aborda una parte de la funcionalidad total, pasando por todos los
flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se
analiza cuando termina. Se puede determinar si han aparecido nuevos
requisitos o han cambiado los existentes, afectando a las iteraciones siguientes.
Durante la planificación de los detalles de la siguiente iteración, el equipo
también examina cómo afectarán los riesgos que aún quedan al trabajo en
curso. Toda la retroalimentación de la iteración pasada permite reajustar los

42
objetivos para las siguientes iteraciones. Se continúa con esta dinámica hasta
que se haya finalizado por completo con la versión actual del producto.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones en número variable según el proyecto y en las que se hace un mayor
o menor hincapié en los distintas actividades

Las primeras iteraciones las fases de Inicio y Elaboración se enfocan hacia la

comprensión del problema y la tecnología, la delimitación del ámbito del
proyecto, la eliminación de los riesgos críticos, y al establecimiento de una
baseline de la arquitectura.

Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en

actividades modelado del negocio y de requisitos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline

de la arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo
de negocios (refinamiento), análisis, diseño y una parte de implementación
orientado a la baseline de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por

medio de una serie de iteraciones.

Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y

diseño y se procede a su implementación y pruebas. Se realiza una pequeña
cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la
implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto

preparado para su entrega a la comunidad de usuarios.

En cada fase participan todas las disciplinas, pero dependiendo de la fase el

esfuerzo dedicado a una disciplina varía.

13.7. OTRAS PRÁCTICAS

RUP identifica 6 best practices con las que define una forma efectiva de trabajar
para los equipos de desarrollo de software.

13.7.1. Gestión de requisitos

RUP brinda una guía para encontrar, organizar, documentar, y seguir los
cambios de los requisitos funcionales y restricciones. Utiliza una notación de
Caso de Uso y escenarios para representar los requisitos.

43
 13.7.2. Desarrollo de software iterativo

Desarrollo del producto mediante iteraciones con hitos bien definidos, en las
cuales se repiten las actividades pero con distinto énfasis, según la fase del
proyecto.

13.7.3. Desarrollo basado en componentes

La creación de sistemas intensivos en software requiere dividir el sistema en

componentes con interfaces bien definidas, que posteriormente serán
ensamblados para generar el sistema. Esta característica en un proceso de
desarrollo permite que el sistema se vaya creando a medida que se obtienen o
se desarrollan sus componentes.

13.7.4. Modelado visual (usandoUML)

UML es un lenguaje para visualizar, especificar, construir y documentar el

software. Utilizar herramientas de modelado visual facilita la gestión de dichos
modelos, permitiendo ocultar o exponer detalles cuando sea necesario. El
modelado visual también ayuda a mantener la consistencia. En resumen, el
modelado visual ayuda a mejorar la capacidad del equipo para gestionar
la complejidad del software.

13.7.5. Verificación continúa de la calidad

Es importante que la calidad se evalúe en varios puntos durante el proceso de

desarrollo, especialmente al final de cada iteración. En esta verificación las
pruebas juegan un papel fundamental y se integran a lo largo de todo el proceso.

13.7.6. Gestión de los cambios

El cambio es un factor de riesgo crítico en los proyectos de software. El software

cambia no sólo debido a acciones de mantenimiento posteriores a la entrega del
producto, sino que durante el proceso de desarrollo, especialmente importantes
por su posible impacto son los cambios en los requisitos. Por otra parte, otro
gran desafío que debe abordarse es la construcción de software con la
participación de múltiples desarrolladores, trabajando a la vez en una release,
y quizás en distintas plataformas. La ausencia de disciplina rápidamente
conduciría al caos. La Gestión de Cambios y de Configuración es la disciplina de
RUP encargada de este aspecto.

44
 13.7.7. Estructura del proceso

El proceso puede ser descrito en dos dimensiones o ejes:

Eje horizontal: Representa el tiempo y es considerado el eje de los aspectos

dinámicos del proceso. Indica las características del ciclo de vida del proceso
expresado en términos de fases, iteraciones e hitos. Se puede observar en la
Figura 6 que RUP consta de cuatro fases: Inicio, Elaboración, Construcción y
Transición. Como se mencionó anteriormente cada fase se subdivide a la vez en
iteraciones.

Eje vertical: Representa los aspectos estáticos del proceso. Describe el proceso
en términos de componentes de proceso, disciplinas, flujos de trabajo, actividades,
artefactos y roles.

Ilustración 7Estructura de RUP

13.7.8. Estructura Dinámica del proceso. Fases e

iteraciones

RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un

producto. Cada ciclo concluye con una generación del producto para los clientes.
Cada ciclo consta de cuatro fases: Inicio, Elaboración, Construcción y Transición.
Cada fase se subdivide a la vez en iteraciones, el número de iteraciones en cada
fase es variable.

Cada fase se concluye con un hito bien definido, un punto en el tiempo en el cual
se deben tomar ciertas decisiones críticas y alcanzar las metas clave antes de
pasar a la siguiente fase, ese hito principal de cada fase se compone de hitos

45
menores que podrían ser los criterios aplicables a cada iteración. Los hitos para
cada una de las fases son: Inicio - Lifecycle Objectives, Elaboración - Lifecycle
Architecture, Construcción - Initial Operational Capability, Transición - Product
Release. Las fases y sus respectivos hitos se ilustran en la Figura 7.

Ilustración 8. Fases e hitos en RUP

La duración y esfuerzo dedicado en cada fase es variable dependiendo de las

características del proyecto. Sin embargo, la Figura 8 ilustra porcentajes frecuentes
al respecto. Consecuente con el esfuerzo señalado, la Figura 9 ilustra una
distribución típica de recursos humanos necesarios a lo largo del proyecto.

Ilustración 9. Distribuciones típicas de esfuerzo y tiempo

46
Ilustración 10. Distribución típica de recursos humanos

Inicio

Durante la fase de inicio se define el modelo del negocio y el alcance del proyecto.
Se identifican todos los actores y Casos de Uso, y se diseñan los Casos de Uso
más esenciales (aproximadamente el 20% del modelo completo). Se desarrolla, un
plan de negocio para determinar que recursos deben ser asignados al proyecto.

Los objetivos de esta fase son:

Establecer el ámbito del proyecto y sus límites.

Encontrar los Casos de Uso críticos del sistema, los escenarios básicos que
definen la funcionalidad.
Mostrar al menos una arquitectura candidata para los escenarios principales.
Estimar el coste en recursos y tiempo de todo el proyecto.
Estimar los riesgos, las fuentes de incertidumbre.

Los resultados de la fase de inicio deben ser:

Un documento de visión: Una visión general de los requerimientos del

proyecto, características clave y restricciones principales.
Modelo inicial de Casos de Uso (10-20% completado). Un glosario inicial:
Terminología clave del dominio.
El caso de negocio.
Lista de riesgos y plan de contingencia.
Plan del proyecto, mostrando fases e iteraciones. Modelo de negocio, si es
necesario
Prototipos exploratorios para probar conceptos o la arquitectura candidata.

47
Al terminar la fase de inicio se deben comprobar los criterios de evaluación para
continuar:
Todos los interesados en el proyecto coinciden en la definición del ámbito del
sistema y las estimaciones de agenda.
Entendimiento de los requisitos, como evidencia de la fidelidad de los Casos
de Uso principales.
Las estimaciones de tiempo, coste y riesgo son creíbles.
Comprensión total de cualquier prototipo de la arquitectura desarrollado. Los gastos
hasta el momento se asemejan a los planeados.
Si el proyecto no pasa estos criterios hay que plantearse abandonarlo o repensarlo
profundamente. Elaboración

El propósito de la fase de elaboración es analizar el dominio del problema,

establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar
los mayores riesgos.

En esta fase se construye un prototipo de la arquitectura, que debe evolucionar en

iteraciones sucesivas hasta convertirse en el sistema final. Este prototipo debe
contener los Casos de Uso críticos identificados en la fase de inicio. También debe
demostrarse que se han evitado los riesgos más graves.

Los objetivos de esta fase son:

Definir, validar y cimentar la arquitectura. Completar la visión.
Crear un plan fiable para la fase de construcción. Este plan puede evolucionar en
sucesivas iteraciones. Debe incluir los costes si procede.
Demostrar que la arquitectura propuesta soportará la visión con un coste razonable
y en un tiempo razonable.

Al terminar deben obtenerse los siguientes resultados:

Un modelo de Casos de Uso completa al menos hasta el 80%: todos los casos
y actores identificados, la mayoría de los casos desarrollados.
Requisitos adicionales que capturan los requisitos no funcionales y cualquier
requisito no asociado con un Caso de Uso específico.
Descripción de la arquitectura software. Un prototipo ejecutable de la arquitectura.
Lista de riesgos y caso de negocio revisados. Plan de desarrollo para el proyecto.
Un caso de desarrollo actualizado que especifica el proceso a seguir. Un manual de
usuario preliminar (opcional).

En esta fase se debe tratar de abarcar todo el proyecto con la profundidad

mínima. Sólo se profundiza en los puntos críticos de la arquitectura o riesgos
importantes.
En la fase de elaboración se actualizan todos los productos de la fase de inicio. Los
criterios de evaluación de esta fase son los siguientes:

48
La visión del producto es estable. La arquitectura es estable.
Se ha demostrado mediante la ejecución del prototipo que los principales
elementos de riesgo han sido abordados y resueltos.
El plan para la fase de construcción es detallado y preciso. Las estimaciones son
creíbles. Todos los interesados coinciden en que la visión actual será alcanzada si
se siguen los planes actuales en el contexto de la arquitectura actual.
Los gastos hasta ahora son aceptables, comparados con los previstos.

Si no se superan los criterios de evaluación quizá sea necesario abandonar

el proyecto o replanteárselo considerablemente.

Construcción

La finalidad principal de esta fase es alcanzar la capacidad operacional del producto

de forma incremental a través de las sucesivas iteraciones. Durante esta fase todos
los componentes, características y requisitos deben ser implementados, integrados
y probados en su totalidad, obteniendo una versión aceptable del producto.

Los objetivos concretos incluyen:

Minimizar los costes de desarrollo mediante la optimización de recursos y evitando
el tener que rehacer un trabajo o incluso desecharlo.
Conseguir una calidad adecuada tan rápido como sea práctico.
Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan
rápido como sea práctico.

Los resultados de la fase de construcción deben ser:

Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e Implementación)
Arquitectura íntegra (mantenida y mínimamente actualizada)
Riesgos Presentados Mitigados
Plan del Proyecto para la fase de Transición. Manual Inicial de Usuario (con
suficiente detalle) Prototipo Operacional – beta
Caso del Negocio Actualizado

Los criterios de evaluación de esta fase son los siguientes:

El producto es estable y maduro como para ser entregado a la comunidad de
usuario para ser probado.
Todos los usuarios expertos están listos para la transición en la comunidad de
usuarios.
Son aceptables los gastos actuales versus los gastos planeados.

Transición
La finalidad de la fase de transición es poner el producto en manos de los usuarios
finales, para lo que se requiere desarrollar nuevas versiones actualizadas del

49
producto, completar la documentación, entrenar al usuario en el manejo del
producto, y en general tareas relacionadas con el ajuste, configuración, instalación
y facilidad de uso del producto.

Algunas de las cosas que puede incluir esta fase:

Prueba de la versión Beta para validar el nuevo sistema frente a las
expectativas de los usuarios
Funcionamiento paralelo con los sistemas legados que están siendo sustituidos
por nuestro proyecto.
Conversión de las bases de datos operacionales. Entrenamiento de los usuarios y
técnicos de mantenimiento.
Traspaso del producto a los equipos de marketing, distribución y venta.

Los principales objetivos de esta fase son:

Conseguir que el usuario se valga por sí mismo.
Un producto final que cumpla los requisitos esperados, que funcione y
satisfaga suficientemente al usuario.

Los resultados de la fase de transición son: Prototipo Operacional

Documentos Legales
Caso del Negocio Completo
Línea de Base del Producto completa y corregida que incluye todos los modelos del
sistema
Descripción de la Arquitectura completa y corregida
Las iteraciones de esta fase irán dirigidas normalmente a conseguir una nueva
versión.
Los criterios de evaluación de esta fase son los siguientes: El usuario se encuentra
satisfecho.
Son aceptables los gastos actuales versus los gastos planificados.
Estructura Estática del proceso. Roles, actividades, artefactos y flujos de trabajo

Un proceso de desarrollo de software define quién hace qué, cómo y cuándo. RUP
define cuatro elementos los roles, que responden a la pregunta ¿Quién?, las
actividades que responden a la pregunta ¿Cómo?, los productos, que responden a
la pregunta ¿Qué? y los flujos de trabajo de las disciplinas que responde a la
pregunta ¿Cuándo? (ver Figura 10 y 11).

50
Ilustración 11. Relación entre roles, actividades, artefactos

Ilustración 12. Detalle de un workflow mediante roles, actividades y artefactos

Roles

Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo

de individuos trabajando juntos como un equipo. Una persona puede desempeñar
diversos roles, así como un mismo rol puede ser representado por varias personas.

Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de

actividades como el ser el dueño de un conjunto de artefactos.

13.8. UML

(Unifed Modeling Languaje) El lenguaje para modelamiento unificado (UML), es un

lenguaje para la especificación, visualización, construcción y documentación de los
artefactos de un proceso de sistema intensivo. Fue originalmente concebido por la

51
Corporación Rational Software y tres de los más prominentes métodologistas en la
industria de la tecnología y sistemas de información: Grady Booch, James
Rumbaugh, y Ivar Jacobson ("The Three Amigos"). El lenguaje ha ganado un
significante soporte de la industria de varias organizaciones vía el consorcio de
socios de UML y ha sido presentado al Object Management Group (OMG) y
aprobado por éste como un estándar (noviembre 17 de 1997).

13.9. ESTEREOTIPO UML

Los estereotipos son el mecanismo de extensibilidad incorporado más utilizado

dentro de UML. Un estereotipo representa una distinción de uso. Puede ser aplicado
a cualquier elemento de modelado, incluyendo clases, paquetes, relaciones de
herencia, etc. Por ejemplo, una clase con estereotipo \'actor\' es una clase usada
como un agente externo en el modelado de negocio. Una clase patrón es modelada
como una clase con estereotipo parametrizado, lo que significa que puede contener
parámetros.

52
 14. FACTIBILIDAD

En general los análisis de factibilidad o los estudios de factibilidad, se completan

durante la fase de diseño de sistemas, normalmente durante la consideración de la
evaluación de las diferentes alternativas de solución propuestas. Para la
elaboración del nuevo sistema se realizaron los estudios de factibilidad
mencionados a continuación:

14.1. FACTIBILIDAD TÉCNICA

- TECNO PC SYSTEM actualmente cuenta con la disponibilidad de los equipos

necesarios que permiten la elaboración e implantación de un nuevo sistema.

- El personal que trabajará con el sistema de inventario propuesto posee la

experiencia técnica requerida para diseñar, implementar, operar y mantener el dicho
sistema, es decir, el personal está apto para manejar el mismo.

- El software que será implementado cumple con los requerimientos para la

elaboración del sistema propuesto.

14.2. FACTIBILIDAD ECONÓMICA

- El tiempo establecido para la elaboración del Sistema está dentro del estimado por
los usuarios y no se presentan costos adicionales.

- Los materiales y equipos a utilizarse para el desarrollo del sistema no representan

una carga económica adicional para La empresa TECNO PC SYSTEM ya que la
misma cuenta con los recursos necesarios para su implementación.

14.3. FACTIBILIDAD OPERACIONAL

- Al momento de ser concluido el proceso de elaboración del sistema de Gestión de

Compras, Inventario y Ventas, el mismo será implantado para luego ser utilizado en
el control de entradas y salidas de mercancía de La empresa TECNO PC SYSTEM.

53
 15. PLANIFICACIÓN DEL PROYECTO

El proyecto propuesto se desarrollará para la empresa TECNO PC SYSTEM de

propiedad del ingeniero desarrollador del mismo según lo contemplado en el
cronograma propuesto, así mismo el ingeniero asumirá los costos del proyecto y
utilizará herramientas open sourse (código abierto) para garantizar la factibilidad
del proyecto mencionado.

15.1. LENGUAJE DE PROGRAMACIÓN Y BASES DE DATOS.

La aplicación web – móvil a desarrollar se implementará con lenguajes de

programación PHP, HTML5 y CCS3, utilizando herramientas de software libre y
bases de datos libres y un software de inventario y ventas de código abierto llamado
Inventio Lite el cual se describe a continuación.

7Inventio Lite: Sistema de Inventario y Ventas Open Source

Inventio Lite es un Sistema de Inventario y ventas para tu tienda, controla ventas,

clientes, proveedores, inventario, abastecimientos, cortes de caja y más, el sistema
está desarrollado en PHP, MySQL y Bootstrap 3.

El sistema Inventio Lite tiene las siguientes características:

 de Productos
 Módulo de Ventas
 Módulo de Cortes de Caja
 Módulo de Clientes
 Módulo de Proveedores
 Módulo de Categorías
 Módulo de Inventario
 Sistema Multiusuario
 Generación de reportes por rango de fecha
 Impresión de reportes en Word

7
Inventio Lite es un Sistema de Inventario y ventas para tu tienda, controla ventas, clientes,
proveedores, inventario, abastecimientos, cortes de caja y más, el sistema está desarrollado en
PHP, MySQL y Bootstrap 3. http://evilnapsis.com/2015/07/11/inventio-lite-sistema-de-inventario-y-
ventas/

54
 15.2. CARACTERÍSTICAS

15.2.1. Productos
Gestión de productos que se manejan en el almacén, se puede agregar imágenes,
descripción, precio de entrada, de salida y el mínimo de inventario.
También se puede organizar productos por categorías y también se puede activar y
desactivar los productos.

15.2.2. Vender
En la sección de vender se buscan los productos, se añaden cantidades y se
procesan las ventas.
Se puede ingresar el efectivo recibido y obtener una alerta con el cambio que se le
devolverá al cliente, también se pueden ver las ventas, asignarlas a un cliente e
imprimirla.

15.2.3. Clientes
Gestión de directorio de clientes, añade información sobre ellos, dirección, email y
teléfono.
También se puede asociar una venta a un cliente en el módulo de ventas y se
muestra en el reporte de ventas del cliente asociado.

15.2.4. Proveedores
Gestión del directorio de proveedores, añade información sobre ellos, dirección,
email y teléfono.
También se puede asociar abastecimientos de inventario a un proveedor y se
muestra en el reporte del abastecimiento.

15.2.5. Inventario
En el inventario se puede ver la disponibilidad de productos, dar de alta o ver el
historial, también podemos descargar un archivo word con toda la información del
inventario.

15.2.6. Cortes de Caja

Administra ventas en un módulo de cortes de caja que se puede abrir y cerrar en el
momento que sea necesario y así registrar las operaciones que se efectúen durante
el turno de los cajeros.
Se puede exportar en formato word los datos referentes a un corte de caja.

55
 15.2.7. Usuarios
Se puede tener control del acceso al sistema mediante el sistema de usuarios, con
2 niveles, 1 para administradores y para usuarios normales, también se puede
activar y desactivar los usuarios cuando quieras o no que accedan al sistema.
15.2.8. Reportes en Word
Se Puede descargar versiones imprimibles de lista de clientes, productos,
inventario, ventas.

56
 16. CONCRECIONES

16.1. CASOS DE PRUEBA

Los casos de prueba sirven para determinar lo que se va a probar y definir las
condiciones o variables bajo las cuáles se deben ejecutar las pruebas, de este modo
se puede asegurar que el sistema funciona correctamente.

16.2. ESTIMACION COCOMO

RESULTADOS

Desarrollo de software (Elaboración y Construcción) Perfil del personal

Esfuerzo = 13,5 meses-persona

Horario = 8,7 Meses
Costo = $ 5,401 total equivalente Tamaño = 4000
SLOC Adquisición fase de distribución

Esfuerzo
Horario El personal Costo
Fase (Meses-
(Meses) promedio (Dólares)
persona)
Comienzo 0,8 1.1 0,7 $ 324
Elaboración 3.2 3.2 1.0 $ 1.296
Construcción 10.3 5.4 1.9 $ 4.105
Transición dieciséis 1.1 15 $ 648

Software Esfuerzo Distribución de RUP / MBASE (meses-persona)

Fase / Actividad Comienzo Elaboración Construcción Transición

administración 0,1 0,4 1.0 0,2
Medio Ambiente / CM 0,1 0,3 0,5 0,1
requisitos 0,3 0,6 0,8 0,1

57
Diseño 0,2 1.2 dieciséis 0,1
Implementación 0,1 0,4 3.5 0,3
Evaluación 0,1 0,3 2.5 0,4
Despliegue 0.0 0,1 0,3 0,5

Mantenimiento.

Mantenimiento Anual Esfuerzo = 0.0 meses-persona

Costo de mantenimiento anual = $ 0
Total de mantenimiento de Costo = $ 0

16.3. ITERACION 1

Se hizo el diagnóstico del proceso de Actualización del sistema de gestión de

compras, inventario y ventas para la empresa TECNO PC SYSTEM.

Se realizó de manera interna en la empresa un diagnóstico del sistema que se

manejaba para mantener un control de inventario, encontrando los siguientes
resultados:

No se maneja ningún sistema o programa que haga una relación directa entre
compres, inventario y ventas.

Se encontró que se manejaba en Excel y por separado en un Excel los precios de

compra y venta de los productos, en otro Excel las compras y ventas totales diarias
y sin ninguna relación con los productos vendidos, las facturas de venta también se
manejan en un Excel aparte, y en folders de oficina se archivan las facturas de
compra de proveedores. Lo que se mencionó anteriormente no tiene ninguna
relación entre si y no da ningún aporte real de ventas totales, compras e inventario
actualizado, mucho menos se puede proyectar reportes.

58
 16.3.1. Modelo relacional

En la siguiente imagen se puede ver las tablas realizadas y su relación con las
demás, de esta manera se conoce cómo la base de datos trabaja de la mano con
la aplicación.

Ilustración 13. Modelo relacional.

Fuente: Elaboración propia

59
 16.3.2. Casos de uso

Aquí en los casos de uso se describen las funciones de cada actor del sistema

Ilustración 14. Casos de Uso

Fuente: Elaboración propia

60
 16.3.3. Proceso Centrado en la Arquitectura

Aquí se ilustra el progreso y desarrollo del proyecto

Ilustración 15. Proceso centrado en la arquitectura

Fuente: Elaboración propia

61
 16.3.4. Diagrama de actividad

El diagrama de actividad permite ver el paso a paso de la aplicación.

Ilustración 16. Diagrama de actividad

Fuente: Elaboración propia

62
 16.3.5. Cronograma

Este cronograma se puede ver las actividades a realizarse en cada etapa del
proyecto.

Ilustración 17. Cronograma de Actividad

ACTIVIDAD DICIEMBRE ENERO FEBRERO MARZO ABRIL MAYO JUNIO

INVESTIGACION PRELIMINAR
ACLARACION DE LA SOLICITUD
ESTUDIO DE FACTIBILIDAD
APROBACION DE LA SOLICITUD
DETERMINACION DE REQUERIMIENTOS
RECOPILACION DE INFORMACION
ANALISIS DE INFORMACION
DISEÑO DEL SISTEMA
DISEÑO DE LA BASE DE DATOS
ELABORACION DE FORMULARIOS
DESARROLLO DEL SOFTWARE
CODIFICACION DEL SISTEMA
PRUEBA DEL SISTEMA
PRUEBA DEL SISTEMA
IMPLEMENTACION Y EVALUACION
IMPLEMENTACION DEL SISTEMA
ENTREGA FINAL
DOCUMENTACION
MANUAL OPERATIVO
MANUAL DE USUARIO

Fuente: Elaboración propia

63
 16.3.6. Modelo iterativo incremental:

El modelo iterativo se puede ver que se hizo en cada iteración de desarrollo del
proyecto realizado, se desarrolla una iteración se prueba y se continua con la
siguiente.

Ilustración 18. Modelo Iterativo Incremental

Fuente: Elaboración Propia

64
 16.3.7. Excel de compras y ventas

Aquí se puede ver lo mencionado en el documento, un Excel de ventas y compras

totales que no relaciona productos ni reporte alguno.

Ilustración 19. Excel de compras y ventas

Fuente: Elaboración propia

65
 16.3.8. Excel de precios de productos

En la imagen a continuación se puede ver que los productos están separados de

las ventas, no hay nada que lo relacione con ventas.

Ilustración 20. Excel de productos

Fuente: Elaboración propia

66
 16.3.9. Factura de venta

De igual manera se encontró que la factura era en Excel y de un modo manual

para realizarla donde había que cambiar el número de cada factura el cliente y el o
los productos vendidos y los totales

Ilustración 21. Factura de venta

Fuente: Elaboración propia

67
 16.3.10. Clasificación ABC

Se realizó un análisis interno en la empresa TECNO PC SYSTEM según las facturas

de venta del año 2015 para de esta manera clasificar los productos según la
metodología ABC dando el siguiente resultado:
Se encontró que el producto más vendido y que se clasifico como A fue el sello
printer 30, sello printy 4911.

El producto regularmente vendido clasificado como B fue el sello printer 20, tinta
para sellos, huellero, almohadilla merletto, sello bolsillo 1035 y el sello de bolsillo
9411, y se determinó que los productos menos vendidos fueron sello de madera,
sello automático pointer, automático grande, fechador manual, fechador automático,
fechador multi.

Requerimientos

Personal involucrado
Nombre Christian Ocampo
Rol Propietario
Categoría profesional Sistemas
Responsabilidades Gerencia y Administración
Información de contacto tecnopcsystem@gmail.com
Aprobación Aprobado

Nombre Mildreth Rodríguez

Rol Auxiliar Administrativo
Categoría profesional Técnico
Responsabilidades Administración
Información de contacto tecnopcsystem@gmail.com
Aprobación Aprobado

16.3.11. Perspectiva del producto

Producto independiente para mejorar el rendimiento de la empresa en sentido de

mantener información de inventario y ventas actualizado en tiempo real para de esta
manera generar un ambiente laboral más eficiente y cómodo

68
 16.3.12. Funcionalidad del producto

Los requerimientos se definen con el fin de conocer el qué debe hacer el sistema.
Éste proceso se realizó por medio de una entrevista al personal involucrado de la
empresa y posteriormente se registraron en un formato donde se especifica el
requerimiento, se define la versión, tipo de requerimiento, estado y responsable.

1. Registro de Proveedor:
El sistema debe:
• Pedir datos personales del proveedor como:-Nombre-Nit-Dirección-
Número de teléfono, correo
• Almacenar los datos del proveedor
• Asignar un código al proveedor

2. Registro de la empresa
El sistema debe:
• Solicitar datos de la empresa:-Nombre.-Dirección.-Número telefónico.-
Nombre del responsable de la empresa y correo.
• Almacenar los datos de la empresa

3. Registro de entrada de la mercancía

El sistema debe:
• Solicitar datos de la mercancía-Nombre-Código-Cantidad-Valor unitario
• Estipular el valor de venta de la mercancía con una utilidad porcentual de
acuerdo al producto

4. Registro de salida de mercancía

El sistema debe:
• Registrar cantidad de mercancía distribuida a la empresa
• Descontar del inventario la mercancía que sale

5. Devoluciones
El sistema debe:
• Registrar las devoluciones
• Incluir nuevamente la mercancía en el inventario

6. Producción de informe
El sistema debe:
Originar un informe de compra de proveedores y ventas
Originar un informe estadístico de productos más vendidos
El sistema debe enviar al correo electrónico de la empresa los informes generados

69
El sistema debe generar notificaciones al correo cuando el stock de un producto
se encuentre en baja existencia y notificar al distribuidor cuando éste se encuentre
agotado.
El sistema debe permitir clasificar la mercancía según la metodología ABC
El sistema debe proveer una interfaz amigable al usuario, que cumpla con el atributo
de calidad USABILIDAD.
El sistema deberá cumplir con diseño responsivo de tal forma que pueda ser
accedido desde distintos dispositivos móviles a través de Internet.

16.3.13. Características de los usuarios

Tipo de usuario Administrador

Formación Ingeniero En Sistemas
Habilidades Conocimiento y manejo de aplicaciones
Actividades Ingreso de nuevos usuarios al sistema revisión y
actualización de la información del mismo manejo de
inventario y estadísticas de ventas “Informes”

Tipo de usuario Usuario

Formación Básico en sistemas
Habilidades Conocimiento y manejo de aplicaciones
Actividades Revisión y actualización de la información del mismo manejo
de inventario, ventas y estadísticas de ventas “Informes”

16.3.14. Restricciones

Ingreso al sistema con usuario y contraseña, registro de administrador o usuario,

depende de conexión a internet, el usuario puede realizar cualquier tarea menos
registrar nuevos usuarios, solo el administrador puede registrar usuarios o
administradores nuevos.

Se cumplió con lo propuesto en el análisis, diseño, registro y login del sistema donde
el usuario que desea ingresar debe poner su información de acceso para ingresar
si esta no es correcta el sistema no dejara continuar sino hasta que se realice el
login correctamente se realizaron las pruebas correspondientes dando el resultado
esperado y de igual manera se implementó y desplego, en este momento está
funcionando correctamente.

70
 16.3.15. Requerimiento No. 1

UNIVERSIDAD CATOLICA DE PEREIRA

Captura y descripción de requerimientos

Proyecto: Desarrollo del sistema de gestión de compras,

inventario y ventas para la Empresa Tecno Pc System
Diseño e implementación del Sistema de gestión de
compras, inventario y ventas.
Información del requerimiento
Requerimiento Nro. 1 Versión: 1.0 ID RQ-1
Fecha de creación 09/03/2016
Nombre del requerimiento Login
Descripción Estado Fecha:
Aprobado
Login debe solicitar el usuario y la contraseña Rechazado
para el ingreso al sistema y validar la
información del usuario Modificado
En ejecución
Finalizado

Tipos del requerimiento Funcional X No funcional

Responsable

71
 16.3.16. Caso de prueba 1. Login de usuario

Área
Datos /
Caso de Funcional / Funcionalidad / Resultado
Id Descripción Fecha Acciones de
Prueba Sub Característica Esperado/Fallido
Entrada
proceso
determinar se requiere
que el usuario de usuario
inicie sesión registrado
inicio de de manera inicio de login con usuario con
1 sesión correcta 10-feb sesión y contraseña contraseña esperado

Ilustración del login de usuario

De aquí en adelante se puede ver la aplicación ya en función e implementada

terminada y funcionando actualmente. En esta primera imagen se puede ver el login
del sistema.

Ilustración 22. Login

Fuente: Elaboración Propia

72
Ilustración del ingreso al sistema pantalla de inicio donde se puede ver
notificaciones de los productos, esta es la entrada al sistema se puede de igual
manera tener acceso al menú de las distintas funciones mencionadas.

Ilustración 23. Pantalla de inicio

Fuente: Elaboración propia

16.4. ITERACION 2

Análisis y diseño de la base de datos:

En esta iteración se trabajó en todos los aspectos del cronograma y el modelo

iterativo incremental, para realizar el desarrollo de las tablas correspondientes para
la base de datos, la cual se implementó y se hicieron las pruebas respectivas dando
los resultados esperados, según los requerimientos, casos de prueba e ilustraciones
a continuación:

73
 16.4.1. Requerimiento 11

Generación y pruebas de la base de datos integración con el sistema

UNIVERSIDAD CATOLICA DE PEREIRA

Captura y descripción de requerimientos
Proyecto: Desarrollo del sistema de gestión de compras,
inventario y ventas para la Empresa Tecno Pc System
Diseño e implementación del Sistema de gestión de
compras, inventario y ventas.
Información del requerimiento
Requerimiento Nro. 11 Versión: 1.0 ID RQ-1
Fecha de creación 09/03/2016
Nombre del requerimiento Base de datos
Descripción Estado Fecha:
Aprobado
Generación y pruebas de la base de datos Rechazado
integración con el sistema Modificado
En ejecución
Finalizado

Tipos del requerimiento Funcional X No funcional

Responsable

16.4.2. Caso de prueba 2. Base de datos

Área
Caso Datos /
Funcional Funcionalidad / Resultado
Id de Descripción Fecha Acciones de
/ Sub Característica Esperado/Fallido
Prueba Entrada
proceso
conectar la
base de datos
a las
funciones del
sistema para
que gestione
determinar las y relacione la
tablas información
necesarias para de clientes,
el correcto proveedores,
funcionamiento conectar el producto
base de de la base de base de sistema a la ventas,
2 datos datos 10-feb datos base de dtos reportes esperado

74
A continuación se puede ver la base de datos como tal ya funcionando en un host
pago por el propietario de la empresa Tecno Pc System

Ilustración 24. Base de datos

Fuente: Elaboración propia

16.5. ITERACION 3

Se anexó a la aplicación el desarrollo de las siguientes funciones con el fin de que

generara los reportes al correo cuando un producto se encuentra en baja existencia.
Se desarrolló la factura de venta generando el nombre del cliente, el nombre del
vendedor, producto, descuento, subtotal, IVA y total.

También se arregló el código en los rangos de fecha de los reportes el cual tenía un
error ya que solo dejaba sacar el reporte por un solo día y no por un rango de fechas
diferentes.

Se desarrolló él envió de reportes al correo del propietario de la empresa TECNO

PC SYSTEM.

Se desarrolló la generación de reporte estadístico de productos más vendidos lo

cual genera un reporte por todos o cada uno de los productos indicando cuantos
entraron y salieron en total, es indispensable para generar anualmente una nueva
clasificación ABC, lo cual permite saber los productos más vendidos, los regular

75
mente vendidos y los poco o nada vendidos, esto permite que se tomen decisiones
respecto a los productos que se pueden eliminar definitivamente del inventario y
que productos nuevos se pueden agregar a este siempre buscando mejorar la
calidad del servicio y de los productos de la empresa.

Y se utilizó el sistema de login, el sistema de registro de ingreso y edición de

usuarios, el sistema de ingreso y edición de proveedores, el sistema de ingreso y
edición de clientes, el sistema de ingreso de categorías, el sistema de ingreso y
edición de productos, el sistema de vender y el sistema se ventas en el cual
podemos ver una lista de ventas totales y hacer las devoluciones, el sistema del
sistema de reporte de ventas el cual nos da las ventas totales, el sistema de reportes
de inventario el cual muestra cada una de las entradas y salidas de todos o cada
uno de los productos.

Todo lo anterior fue implementado y probado respectivamente con el fin de

garantizar la calidad y funcionamiento de la aplicación.

16.5.1. Requerimiento 2.

UNIVERSIDAD CATOLICA DE PEREIRA

Captura y descripción de requerimientos
Proyecto: Desarrollo del sistema de gestión de compras,
inventario y ventas para la Empresa Tecno Pc System
Diseño e implementación del Sistema de gestión de
compras, inventario y ventas.
Información del requerimiento
Requerimiento Nro. 2 Versión: 1.0 ID RQ-1
Fecha de creación 09/03/2016
Nombre del requerimiento Registro usuarios
Descripción Estado Fecha:
Aprobado
Debe permitir el registro de usuarios o Rechazado
administradores, debe solicitar nombre, Modificado
apellido, nombre de usuario, correo y En ejecución
contraseña, también determinar si es Finalizado
administrador o usuario

Tipos del requerimiento Funcional X No funcional

Responsable

76
 16.5.2. Requerimiento 3

UNIVERSIDAD CATOLICA DE PEREIRA

Captura y descripción de requerimientos
Proyecto: Desarrollo del sistema de gestión de compras,
inventario y ventas para la Empresa Tecno Pc System
Diseño e implementación del Sistema de gestión de
compras, inventario y ventas.
Información del requerimiento
Requerimiento Nro. 3 Versión: 1.0 ID RQ-1
Fecha de creación 09/03/2016
Nombre del requerimiento Registro Proveedor
Descripción Estado Fecha:
Aprobado
Debe permitir el registro del proveedor, debe Rechazado
solicitar nombre, apellido, dirección, correo y Modificado
teléfono, también si es administrador En ejecución
Finalizado

Tipos del requerimiento Funcional X No funcional

Responsable

16.5.3. Requerimiento 4

UNIVERSIDAD CATOLICA DE PEREIRA

Captura y descripción de requerimientos
Proyecto: Desarrollo del sistema de gestión de compras,
inventario y ventas para la Empresa Tecno Pc System
Diseño e implementación del Sistema de gestión de
compras, inventario y ventas.
Información del requerimiento
Requerimiento Nro. 4 Versión: 1.0 ID RQ-1
Fecha de creación 09/03/2016
Nombre del requerimiento Registro de Productos
Descripción Estado Fecha:
Aprobado
Debe permitir el registro del producto, debe Rechazado
solicitar nombre, categoría, descripción, precio Modificado
de entrada, precio de salida, unidad del En ejecución
Finalizado

77
producto, presentación del producto, mínima
en inventario, inventario inicial

Tipos del requerimiento Funcional X No funcional

Responsable

16.5.4. Requerimiento 5

UNIVERSIDAD CATOLICA DE PEREIRA

Captura y descripción de requerimientos
Proyecto: Desarrollo del sistema de gestión de compras,
inventario y ventas para la Empresa Tecno Pc System
Diseño e implementación del Sistema de gestión de
compras, inventario y ventas.
Información del requerimiento
Requerimiento Nro. 5 Versión: 1.0 ID RQ-1
Fecha de creación 09/03/2016
Nombre del requerimiento Registro categoría
Descripción Estado Fecha:
Aprobado
Debe permitir el registro de la categoría, Rechazado
nombre. Modificado
En ejecución
Finalizado

Tipos del requerimiento Funcional X No funcional

Responsable

78
 16.5.5. Requerimiento 6

UNIVERSIDAD CATOLICA DE PEREIRA

Captura y descripción de requerimientos
Proyecto: Desarrollo del sistema de gestión de compras,
inventario y ventas para la Empresa Tecno Pc System
Diseño e implementación del Sistema de gestión de
compras, inventario y ventas.
Información del requerimiento
Requerimiento Nro. 6 Versión: 1.0 ID RQ-1
Fecha de creación 09/03/2016
Nombre del requerimiento Registro Clientes
Descripción Estado Fecha:
Aprobado
Debe permitir el registro del cliente, debe Rechazado
solicitar nombre, apellido, dirección, correo y Modificado
teléfono En ejecución
Finalizado

Tipos del requerimiento Funcional X No funcional

Responsable

16.5.6. Requerimiento 7

UNIVERSIDAD CATOLICA DE PEREIRA

Captura y descripción de requerimientos
Proyecto: Desarrollo del sistema de gestión de compras,
inventario y ventas para la Empresa Tecno Pc System
Diseño e implementación del Sistema de gestión de
compras, inventario y ventas.
Información del requerimiento
Requerimiento Nro. 7 Versión: 1.0 ID RQ-1
Fecha de creación 09/03/2016
Nombre del requerimiento Venta
Descripción Estado Fecha:
Aprobado
Debe realizar venta de uno o más productos Rechazado
solicitando el producto, imprimiendo Modificado
información de la venta con No. de factura, En ejecución
productos y valores, información del vendedor, Finalizado

79
información del cliente, subtotal, descuento,
IVA, total.

Tipos del requerimiento Funcional X No funcional

Responsable

16.5.7. Requerimiento 8

UNIVERSIDAD CATOLICA DE PEREIRA

Captura y descripción de requerimientos
Proyecto: Desarrollo del sistema de gestión de compras,
inventario y ventas para la Empresa Tecno Pc System
Diseño e implementación del Sistema de gestión de compras,
inventario y ventas.
Información del requerimiento
Requerimiento 8 Versión: 1.0 ID RQ-1
Nro.
Fecha de creación 09/03/2016
Nombre del requerimiento Registro devoluciones
Descripción Estado Fecha:
Aprobado
Debe permitir el reintegro de un Rechazado
producto en el inventario por concepto Modificado
de devolución En ejecución
Finalizado

Tipos del Funcional X No funcional

requerimiento
Responsable

80
 16.5.8. Requerimiento 9

UNIVERSIDAD CATOLICA DE PEREIRA

Captura y descripción de requerimientos
Proyecto: Desarrollo del sistema de gestión de compras,
inventario y ventas para la Empresa Tecno Pc System
Diseño e implementación del Sistema de gestión de
compras, inventario y ventas.
Información del requerimiento
Requerimiento Nro. 9 Versión: 1.0 ID RQ-1
Fecha de creación 09/03/2016
Nombre del requerimiento Generar informes
Descripción Estado Fecha:
Aprobado
Debe permitir la generación de informes de Rechazado
compra de mercancía de proveedores y ventas, Modificado
originar informe estadístico de productos más En ejecución
vendidos, y envío de informes al correo de la Finalizado
empresa

Tipos del requerimiento Funcional X No funcional

Responsable

16.5.9. Requerimiento 10

UNIVERSIDAD CATOLICA DE PEREIRA

Captura y descripción de requerimientos
Proyecto: Desarrollo del sistema de gestión de compras,
inventario y ventas para la Empresa Tecno Pc System
Diseño e implementación del Sistema de gestión de
compras, inventario y ventas.
Información del requerimiento
Requerimiento Nro. 10 Versión: 1.0 ID RQ-1
Fecha de creación 09/03/2016
Nombre del requerimiento Reportes
Descripción Estado Fecha:
Aprobado
Debe generar un reporte y enviarlo al correo de Rechazado
la empresa y al distribuidor Modificado
En ejecución

81
 Finalizado

Tipos del requerimiento Funcional X No funcional

Responsable

Ilustración agregar usuarios página de usuarios donde se puede ver los usuarios
registrados solo administrador

Ilustración 25. Lista de usuarios

Fuente: Elaboración propia

Ilustración donde se puede agregar un nuevo usuario, editarlo y determinar si es

usuario o administrador.

16.5.10. Caso de prueba 3. Registrar en el sistema

16.5.11. Caso de prueba 4. Editar usuarios

Área
Datos /
Caso de Funcional / Funcionalidad / Resultado
Id Descripción Fecha Acciones de
Prueba Sub Característica Esperado/Fallido
Entrada
proceso
registrar en el requiere
agregar sistema un nuevo crear nuevo nombre,
3 usuario usuario solo el 11-feb usuarios usuario apellido, esperado

82
 administrador nombre de
puede agregar usuario, e-mail,
usuarios contraseña y se
determina si es
administrador o
usuario
requiere
nombre,
solo el apellido,
administrador nombre de
puede editar y usuario, e-mail,
cambiar datos y contraseña y se
contraseñas de editar determina si es
editar los usuarios o información de administrador o
4 usuarios desactivarlos 12-feb usuarios usuarios usuario esperado

Ilustración 26. Agregar usuario

Fuente: Elaboración propia

83
Ilustración donde se puede editar o desactivar un usuario

Ilustración 27. Editar usuario

Fuente: Elaboración propia

Ilustración donde se puede ver el directorio de clientes y eliminamos clientes

16.5.12. Caso de prueba 5. Registrar cliente

16.5.13. Caso de prueba 6. Editar cliente

Área Datos /
Caso de Funcionalidad / Resultado
Id Descripción Fecha Funcional / Acciones de
Prueba Característica Esperado/Fallido
Sub proceso Entrada
requiere
nombre,
registrar en el apellido,
agregar sistema un crear nuevo dirección, e-
5 cliente nuevo cliente 11-feb clientes cliente mail, teléfono esperado
requiere
nombre,
editar y cambiar editar apellido,
editar datos de los información de dirección, e-
6 clientes clientes 12-feb clientes clientes mail, teléfono esperado

84
Ilustración 28. Editar o eliminar clientes

Fuente: Elaboración propia

Ilustración donde se puede registrar un cliente nuevo

Ilustración 29. Registro de cliente

Fuente: Elaboración propia

85
Ilustración donde se puede editar un cliente

Ilustración 30. Edición cliente

Fuente: Elaboración propia

Ilustración donde se puede ver, registrar y eliminar proveedores

16.5.14. Caso de prueba 7. Registrar nuevo proveedor

16.5.15. Caso de prueba 8. Editar proveedor

Datos /
Caso de Área Funcional Funcionalidad / Resultado
Id Descripción Fecha Acciones de
Prueba / Sub proceso Característica Esperado/Fallido
Entrada
Ver lista
proveedores
registrar en el requiere
sistema un nombre,
nuevo apellido,
proveedor o dirección,
agregar eliminar crear nuevo e-mail,
7 proveedor existente 15-feb proveedores proveedor teléfono esperado
requiere
nombre,
editar en el apellido,
sistema un dirección,
editar proveedor editar proveedor e-mail,
8 proveedor existente 16-feb proveedores existente teléfono esperado

86
Ilustración 31. Directorio proveedores

Fuente: Elaboración propia

Ilustración donde se puede agregar un nuevo proveedor
Ilustración 32. Agregar proveedor

Fuente: Elaboración propia

87
Ilustración donde se puede editar proveedores

Ilustración 33. Editar proveedor

Fuente: Elaboración Propia

Ilustración donde se puede ver las categorías y eliminarlas

16.5.16. Caso de prueba 9. Registrar categoría

16.5.17. Caso de prueba 10. Editar categoría

Área
Datos /
Caso de Funcional / Funcionalidad / Resultado
Id Descripción Fecha Acciones
Prueba Sub Característica Esperado/Fallido
de Entrada
proceso
registrar en el
sistema la requiere de
agregar categoría del nombre de
9 categoría producto 3-mar categorías crear categoría la categoría esperado
editar en el
sistema la requiere de
editar categoría del nombre de
10 categoría producto 4-mar categorías crear categoría la categoría esperado

88
Ilustración 34. Categorías

Fuente: Elaboración Propia

Ilustración donde se puede agregar una nueva categoría

Ilustración 35. Nueva categoría

Fuente: Elaboración Propia

89
Página donde se puede editar categoría

Ilustración 36. Editar categoría

Fuente: Elaboración Propia

Ilustración donde se puede ver y eliminar productos

16.5.18. Caso de prueba 11. Registrar producto

16.5.19. Caso de prueba 12. Editar producto

Área
Datos /
Caso de Funcional Funcionalidad Resultado
Id Descripción Fecha Acciones de
Prueba / Sub / Característica Esperado/Fallido
Entrada
proceso
requiere de
código de
barras,
nombre,
seleccionar la
categoría, e-
mail del
proveedor,
precio de
entrada, precio
registrar en de salida,
el sistema un unidad de
agregar nuevo medida,
11 producto producto 8-mar productos crear producto presentación, esperado

90
 existencia
mínima en
inventario,
existencia
inicial
requiere de
código de
barras,
nombre,
seleccionar la
categoría, e-
mail del
proveedor,
precio de
entrada, precio
de salida,
unidad de
medida,
presentación,
existencia
editar en el mínima en
sistema un inventario,
editar producto 12- existencia
12 producto existente mar productos editar producto inicial esperado

Ilustración 37. Lista de productos

Fuente: Elaboración propia

91
Ilustración donde se puede ingresar un producto nuevo

Ilustración 38. Nuevo producto

Fuente: Elaboración propia

Ilustración donde se puede editar un producto

Ilustración 39. Editar producto

Fuente: Elaboración propia

92
Ilustración donde se puede ver el inventario

16.5.20. Caso de prueba 13. Generar inventario

Área
Funcionalidad Datos /
Caso de Funcional / Resultado
Id Descripción Fecha / Acciones de
Prueba Sub Esperado/Fallido
Característica Entrada
proceso
podemos ver
un listado con
lo mencionado
anteriormente
y además
podemos ver
un historial de
cada producto
donde nos
muestra la
cantidad de
listado del entradas,
inventario productos, y
genera una donde muestra salidas con
lista con el la cantidad reporte
inventario 22- disponible de ordenado por
13 inventario existente mar inventario cada producto fechas esperado

Ilustración 40. Inventario

Fuente: Elaboración propia

93
Ilustración donde se puede ver el historial global de un producto

Ilustración 41. Historial global producto

Fuente: Elaboración propia

Ilustración donde se puede buscar el producto por código a reabastecer introducir

la cantidad y agregar al inventario

16.5.21. Casos de prueba 14. Reabastecimiento

16.5.22. Caso de prueba 15. Reporte reabastecimiento

Área
Funcionalidad Datos / Resultado
Caso de Fech Funcion
Id Descripción / Acciones de Esperado/Falli
Prueba a al / Sub
Característica Entrada do
proceso
debe actualizar
y agregar la
cantidad dada
muestra el del producto al
campo donde sistema y
buscamos por el sistema debe actualizar la
id o por código poder base de datos
el producto el reabastecer el con los
cual queremos 26- inventari producto productos
14 Reabastecer reabastecer mar o buscado gestionados esperado

94
 genera un genera un
reporte de genera reporte reporte de
reabastecimien de reabastecimien
Reabastecimie tos ordenado 26- inventari reabastecimien tos ordenado
15 ntos por fecha mar o tos por fecha esperado

Ilustración 42 reabastecer

Fuente: elaboración propia

95
Ilustración donde se puede ver los reabastecimientos realizados ordenados por
fecha

Ilustración 43. Reabastecimientos

Fuente: Elaboración propia

Ilustración donde se puede realizar una venta buscamos el producto y agregamos

la cantidad

16.5.23. Casos de prueba 16. Venta

16.5.24. Caso de prueba 17. Factura de venta

Área
Caso Datos /
Funcional Funcionalidad / Resultado
Id de Descripción Fecha Acciones de
/ Sub Característica Esperado/Fallido
Prueba Entrada
proceso
requiere de la
información
de productos
en el
inventario,
realizar la generar la venta información
venta de uno de uno o más del cliente,
o más productos del informe total
16 venta productos 5-abr vender stock de la venta esperado

96
 requiere de la
información
de productos
en el
inventario,
información
del cliente,
información
finalizar la del cliente,
venta de uno vendedor,
o más producto,
productos e finalizar la venta descuento,
imprimir la de uno o más subtotal, IVA
factura respectiva productos del y total de la
17 de venta factura 5-abr vender stock venta esperado

Ilustración 44. Realizar venta

Fuente: Elaboración propia

97
Ilustración donde se puede agregar más productos a la venta seleccionar el cliente
y determinar totales

Ilustración 45. Agregar otro producto o finalizar venta

Fuente: Elaboración propia

Ilustración donde se puede imprimir la factura de venta

Ilustración 46. Factura

Fuente: Elaboración propia

98
Ilustración donde se puede ver el mensaje de producto con muy pocas existencias
y el mensaje donde confirma que se ha enviado una notificación al correo del
proveedor y del administrador

16.5.25. Caso de prueba 18. Reporte producto bajo

Área
Funcionalidad Datos /
Caso de Funcional Resultado
Id Descripción Fecha / Acciones
Prueba / Sub Esperado/Fallido
Característica de Entrada
proceso
requiere de
tomar la
información
del
producto
que al
generar momento
automáticamente de la venta
un reporte al genere un
correo del reporte de
reporte administrador y generar baja
automático del proveedor de reporte existencia e
de stock un producto en automático de en el
18 bajo baja existencia 6-abr productos stock inventario esperado

Ilustración 47. Producto bajo en inventario

Fuente: Elaboración propia

99
Ilustración del correo con el mensaje de producto con poca existencia recibido

Ilustración 48. E-mail producto bajo en inventario

Fuente: Elaboración propia

Ilustración donde se puede ver la lista de ventas totales ordenadas por fecha donde
se puede cancelar una venta, eliminarla y hacer la devolución del producto en el
inventario

16.5.26. Caso de prueba 19. Reporte ventas totales

Área
Funcionalidad Datos /
Caso de Funcional Resultado
Id Descripción Fecha / Acciones
Prueba / Sub Esperado/Fallido
Característica de Entrada
proceso
reporte de
ventas
totales
donde
podemos
ver cada
venta
discriminada
en su
factura y
genera una eliminar la
lista de ventas venta para
reporte de ventas totales para hacer
lista de ordenado por ordenado por la
19 ventas fecha de venta 13-abr ventas fecha de venta devolución esperado

100
 del producto
al inventario

Ilustración 49 reporte de ventas totales

Fuente: Elaboración propia

Ilustración donde se puede ver el reporte de ventas totales en el rango de fechas

seleccionado, esto permite saber cuánto se vendió en el día, en el mes o en el año

16.5.27. Caso de prueba 20. Reporte ventas por fechas

16.5.28. Caso de prueba 21. Reporte entradas y salidas

16.5.29. Caso de prueba 22. Reporte más vendidos

16.5.30. Caso de prueba 23. Envió de reportes

101
 Área
Funcionalidad Datos /
Caso de Funcional Resultado
Id Descripción Fecha / Acciones de
Prueba / Sub Esperado/Fallido
Característica Entrada
proceso
el sistema
debe generar
el sistema debe el reporte de
generar el ventas global
reporte de reporte de según lo
ventas ventas en el solicitado en
ordenado por rango el rango de
fechas seleccionado fechas por el
20 Ventas seleccionadas 18-abr reportes de fechas usuario esperado
el sistema
debe generar
el reporte de
entradas y
salidas de los
el sistema debe productos
generar el totales o de un
reporte de producto en
entradas y específico
salidas de según lo
reporte de productos en el solicitado en
entradas y rango el rango de
salida de seleccionado fechas por el
21 Inventario productos 20-abr reportes de fechas usuario esperado
el sistema
debe generar
el reporte de
salidas de los
el sistema debe productos o
generar el de un
reporte de producto en
entradas y específico
salidas de según lo
reporte productos en el solicitado en
movimiento estadístico de rango el rango de
de productos seleccionado fechas por el
22 productos más vendidos 26-abr reportes de fechas usuario esperado
el sistema
debe enviar el
reporte
seleccionado
al correo del
administrador
para este
envió de el sistema debe poder realizar
reportes al enviar el las
correo del reporte estadísticas
23 Reportes administrador 30-abr reportes seleccionado requeridos esperado

102
Ilustración 50. Ventas totales por fecha

Fuente: Elaboración propia

Ilustración donde se puede ver el reporte por rango de fecha de uno o todos los
productos discriminados por registro de operación si es entrada o salida y la fecha
de cada uno

Ilustración 51. Reporte por fecha de entradas y salidas

Fuente: Elaboración propia

103
Ilustración donde se puede ver el reporte estadístico de producto más vendido y
movimientos de uno o más productos en sus salidas y entradas totales

Ilustración 52. Productos más vendidos

Fuente: Elaboración propia

Ilustración donde se puede enviar el reporte seleccionado al correo del propietario

de la empresa

Ilustración 53. Envío de reportes

Fuente: Elaboración propia

104
 16.6. ITERACION 4

16.6.1. Maquetación y diseño

Para la maquetación y diseño visual de la aplicación se utilizó e implementó los

lenguajes de programación PHP, HTML5 y CCS3, utilizando herramientas de
software libre y bases de datos libres y un software de inventario y ventas de código
abierto llamado Inventio Lite el cual relacionamos a continuación.

Inventio Lite: Sistema de Inventario y Ventas Open Source

Inventio Lite es un Sistema de Inventario y ventas para tu tienda, controla ventas,

clientes, proveedores, inventario, abastecimientos, cortes de caja y más, el sistema
está desarrollado en PHP, MySQL y Bootstrap 3

Ilustración del diseño visual de la aplicación totalmente responsivo

Ilustración 54. Maquetación final 1

Fuente: Elaboración propia

105
Ilustración 55. Maquetación final 2

Fuente: Elaboración propia

106
Ilustración 56. Maquetación final 3

Fuente: Elaboración propia

Como se puede ver en las anteriores ilustraciones el diseño es muy cómodo e

intuitivo de fácil usabilidad adaptable, y permite que el usuario aprenda rápidamente
su funcionamiento.
En los pasos anteriores se vio reflejado en los casos de prueba y en las ilustraciones
el correcto funcionamiento e integración de la base de datos al sistema y su
implementación, actualmente funciona según los resultados esperados.

La aplicación está desplegada y funcionando perfectamente en un host pago por el

propietario de la empresa TECNO PC SYSTEM, con dominio tecnopcsystem.com y
subdominio para el sistema de compras, inventario y ventas
inventario.tecnopcsystem.com

107
 17. CONCLUSIONES

 Esta investigación brinda la oportunidad de ampliar el conocimiento adquirido

y poner en práctica lo aprendido a lo largo de la carrera, bien sea para el
estudio de la profesión o cualquier otra que se presente en la vida profesional.

 En síntesis con el fin de planear la capacidad e implantar un cronograma de

producción, se hace necesario inspeccionar cuanta materia prima, cuantas
piezas y cuantos sub ensambles se procesan en un momento dado, es allí
cuando el inventario resulta importante, ya que brinda una capacidad de
predicción y permite mantener el equilibrio entre lo que se necesita y lo que
se procesa. Es por esto que la gestión de este no es un tema que no genere
beneficios para cualquier empresa.

 Bajo este marco se hace claro que el objetivo de la gestión del inventario es
lograr un equilibrio entre la calidad de servicio brindado a los clientes y la
inversión económica necesaria para ello, esto se ve traducido en una
inversión inmovilizada que supone unos recursos financieros .

 Se ha logrado observar en el desarrollo de esta investigación que, a pesar

de que una empresa opere varios años en el giro del negocio y se esté
manteniendo en el mercado, siempre se podrán encontrar aspectos por
mejorar. Podemos constatar que, con el apoyo de la teoría enseñada durante
los años en la universidad, es posible detectar situaciones y aspectos
generadores de dificultades, así como también se pueden detectar
oportunidades para crecer y plantear estrategias que permitan sacarle
provecho a estas.

 Las propuestas que se han planteado permiten mejorar algunos puntos

débiles que se han encontrado durante el levantamiento de información. Pero
estas requieren del compromiso del personal no solo del nivel operativo sino
que también, del nivel administrativo, ya que sin esta responsabilidad no se
podrán mantener estas mejoras con el paso del tiempo.

108
 18. RECOMENDACIONES

A continuación se hacen algunas recomendaciones que ayudarán a mejorar los

aspectos de gestión del inventario y gestión del almacén:

 Llevar un registro exacto de la demanda, y análisis de su variabilidad, con el

fin de conservar los niveles de existencia de productos apropiados en el
almacén.

 Realizar auditorías internas a fin de detectar a tiempo, inconvenientes y

nuevos focos problemáticos en los distintos departamentos, para poder
establecer medidas correctivas a tiempo.

 Mantener y renovar anualmente la clasificación ABC del inventario, con el

propósito de hacer reformas en las variaciones que pueda experimentar la
demanda de acuerdo a los productos a los cuales este modelo es aplicado.

 Establecer políticas de control del inventario con respecto a la clasificación

propuesta, de tal forma que estas permitan tomar medidas de cuándo y
cuánto pedir de cada artículo clasificado en el inventario.

 Por último se recomienda que las unidades pertenecientes a la zona de

artículos clasificados como tipo A, requieren del grado de rigor más alto
posible en cuanto a control. Ya que estas corresponden a una parte
importante del valor total del inventario.

19. ANEXOS

 Manual de usuario del sistema de gestión de compras, inventario y ventas

para la empresa TECNO PC SYSTEM.

 Análisis ABC Tecno Pc System

109
 20. BIBLIOGRAFÍA

Arias, F. G. (2012). El Proyecto de Investigacion 6a edicion. Caracas: Episteme.

Ballou, R. H. (1991). Logistica Empresarial. Diaz de Santos.
Catalinas, E. Q. (2007). Mantenimiento de portales de la informacion. Madrid:
Thomson.
Diaz, Z. (2006). DESWeb. merida.
Dr. Salvador Mercado, H. (2004). Mercado Tecnia Programada 2da edicion.
Mexico: Limusa.
Durango, A. (2015). Diseño de Software 2da edicion. IT campus academy.
Evertt E Adam, R. J. (1989). Administración de la producción y las operaciones.
Pearsons.
F, M. (2006). Martos F .
Falgueras, B. C. (2003). Ingenieria del Software. Barcelona: UOC.
Flores. (2004). Inventarios.
Foster, G. (2007). Contabilidad de costos. Mexico: Pearson.
Gaither, M. (2003). American Educational History Revisited. New York: Teachers
College.
García, C. A. (2004). García.
Gómez, D. l. (2006). De la Fuente y Gómez (2006).
Gomez, F. S. (2005). Gestion Direccion y Estrategia de Producto. Madrid: Esic.
Gutierrez, A. F. (2007). Gestion de Stoks. España: Fundacion Confemental.
Heizer, J. y. (2004). Principles of Operations Management. Pearsons.
Herrera, A. H. (2007). Que es un Archivo. Ediciones Trea.
Ivar Jacobson, G. B. (2000). El proceso unificado de desarrollo de software.
Pearson.
Kanban, A. (2007). Sistemas Kanban.

110
Krajewski, R. (2000). Administracion de operaciones estrategias y analisis. Mexico:
Pearson.
Martínez Robles, A. Y. (2005). Control de inventario con análisis de la demanda,
para la empresa "Sport B". Lima.
Mercado. (2004). Mercado.
Mónica Míguez Pérez, . I. (2006). Comunicacion y Comportamiento del
Consumidor 2da edicion. Ideaspropias.
Monks. (1997). Jellyella Taylor & Monks.
Müller. (2007). Müller.
Müller, C. (2004). Organic and Pervasive Computing ARCS. Augsburg: Springer.
MUTHER, R. (1981). Distribucion en Planta. Hispano Europea.
Navascués, C. y. (2001). Cos y Navascués.
Negron, D. F. (2009). Administracion de Operaciones. Mexico D.F: Sengage.
Palich, L. E. (2010). Administración de pequeñas empresas. Cengage Learning.
Peñaloza, S. d. (2008). Guia para la Elaboracion Formal de Reportes de
Investigacion. Caracas: Universidad Catolica Andres Bello.
Purificacion Aguilera, M. M. (2012). Ofimatica y Proceso de la Informacion.
EDITEX.
Ramirez, W. (2007). Manual del Marketing Politico. No: Lulu.com.
Render, S. (2006). Inventario Jit. Hanna.
Sabater. (2004). Sabater.
Sabater, J. P. (2004). GESTIÓN DE STOCKS DE DEMANDA INDEPENDIENTE.
Valencia: Universidad Politecnica.
Sommerville, I. (2005). Ingenieria del Software 7a edicion. Madrid: Pearson.
Tejero, A. (2000). Logística Integral. Madrid: ESIC.
Tejero, J. J. (2008). Almacenes. Madrid: ESIC.
Viveros, M. L. (2007). Fundamentos de Legislacion Laboral. ITM.

111
Winder, R. (1995). Desarrollo de software con C++. Madrid: Edisiones Diaz de
Santos.

112