ARGENTINA COMPRAS, VENTAS, ROE 1. TRIGO 2 COMPRAS Y VENTAS EL 19/9 (Miles de Toneladas) 3.
SISTEMA DE GESTIÓN DE COMPRAS, INVENTARIO Y VENTAS …
125
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
Transcript of SISTEMA DE GESTIÓN DE COMPRAS, INVENTARIO Y VENTAS …
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 (usando UML) ................................................... 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
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.
2
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
3
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.
4
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.
5
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.
6
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:
7
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.
8
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
9
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
10
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.
11
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
1Inventoria software para inventarios http://www.nchsoftware.com/inventory/es/index.html 2Kardex Tauro http://inventarios-kardex-tauro.sysmaya.net/ 3 Samba Software Contable http://www.sambaerp.com/
12
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
13
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
14
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.
15
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)
16
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
17
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
18
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.
19
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:
20
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
21
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
22
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.
23
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.
24
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.
25
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.
26
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
27
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.
28
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.
29
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)
30
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.
31
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.
32
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.
33
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.
34
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)
35
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.
36
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
37
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
38
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
39
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
40
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
41
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.
42
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
43
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.
44
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 (usando UML) 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.
45
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
46
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
47
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.
48
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:
49
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
50
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).
51
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
52
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.
53
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.
54
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/
55
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.
56
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.
57
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) Esfuerzo = 13,5 meses-persona Horario = 8,7 Meses Costo = $ 5,401 total equivalente Tamaño = 4000 SLOC Adquisición fase de distribución
Fase Esfuerzo (Meses-persona)
Horario (Meses)
El personal promedio
Costo (Dólares)
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
Perfil del personal
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
58
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.
59
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
60
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
61
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
62
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
63
16.3.5. Cronograma Este cronograma se puede ver las actividades a realizarse en cada etapa del proyecto. Ilustración 17. Cronograma de Actividad
Fuente: Elaboración propia
ACTIVIDAD
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
JUNIODICIEMBRE ENERO FEBRERO MARZO ABRIL MAYO
64
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
65
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
66
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
67
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
68
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 [email protected]
Aprobación Aprobado
Nombre Mildreth Rodríguez
Rol Auxiliar Administrativo
Categoría profesional Técnico
Responsabilidades Administración
Información de contacto [email protected]
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
69
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
70
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.
71
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:
Login debe solicitar el usuario y la contraseña para el ingreso al sistema y validar la información del usuario
Aprobado
Rechazado
Modificado
En ejecución
Finalizado
Tipos del requerimiento Funcional X No funcional
Responsable
72
16.3.16. Caso de prueba 1. Login de usuario
Id Caso de Prueba
Descripción Fecha
Área Funcional / Sub proceso
Funcionalidad / Característica
Datos / Acciones de Entrada
Resultado Esperado/Fallido
1 inicio de sesión
determinar que el usuario inicie sesión de manera correcta 10-feb
inicio de sesión
login con usuario y contraseña
se requiere de usuario registrado con 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
73
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:
74
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:
Generación y pruebas de la base de datos integración con el sistema
Aprobado
Rechazado
Modificado
En ejecución
Finalizado
Tipos del requerimiento Funcional X No funcional
Responsable
16.4.2. Caso de prueba 2. Base de datos
Id Caso de Prueba
Descripción Fecha
Área Funcional / Sub proceso
Funcionalidad / Característica
Datos / Acciones de Entrada
Resultado Esperado/Fallido
2 base de datos
determinar las tablas necesarias para el correcto funcionamiento de la base de datos 10-feb
base de datos
conectar el sistema a la base de dtos
conectar la base de datos a las funciones del sistema para que gestione y relacione la información de clientes, proveedores, producto ventas, reportes esperado
75
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
76
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:
Debe permitir el registro de usuarios o administradores, debe solicitar nombre, apellido, nombre de usuario, correo y contraseña, también determinar si es administrador o usuario
Aprobado
Rechazado
Modificado
En ejecución
Finalizado
Tipos del requerimiento Funcional X No funcional
Responsable
77
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:
Debe permitir el registro del proveedor, debe solicitar nombre, apellido, dirección, correo y teléfono, también si es administrador
Aprobado
Rechazado
Modificado
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:
Debe permitir el registro del producto, debe solicitar nombre, categoría, descripción, precio de entrada, precio de salida, unidad del
Aprobado
Rechazado
Modificado
En ejecución
Finalizado
78
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:
Debe permitir el registro de la categoría, nombre.
Aprobado
Rechazado
Modificado
En ejecución
Finalizado
Tipos del requerimiento Funcional X No funcional
Responsable
79
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:
Debe permitir el registro del cliente, debe solicitar nombre, apellido, dirección, correo y teléfono
Aprobado
Rechazado
Modificado
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:
Debe realizar venta de uno o más productos solicitando el producto, imprimiendo información de la venta con No. de factura, productos y valores, información del vendedor,
Aprobado
Rechazado
Modificado
En ejecución
Finalizado
80
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 Nro.
8 Versión: 1.0 ID RQ-1
Fecha de creación 09/03/2016
Nombre del requerimiento Registro devoluciones
Descripción Estado Fecha:
Debe permitir el reintegro de un producto en el inventario por concepto de devolución
Aprobado
Rechazado
Modificado
En ejecución
Finalizado
Tipos del requerimiento
Funcional X No funcional
Responsable
81
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:
Debe permitir la generación de informes de compra de mercancía de proveedores y ventas, originar informe estadístico de productos más vendidos, y envío de informes al correo de la empresa
Aprobado
Rechazado
Modificado
En ejecución
Finalizado
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:
Debe generar un reporte y enviarlo al correo de la empresa y al distribuidor
Aprobado
Rechazado
Modificado
En ejecución
82
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
Id Caso de Prueba
Descripción Fecha
Área Funcional / Sub proceso
Funcionalidad / Característica
Datos / Acciones de Entrada
Resultado Esperado/Fallido
3 agregar usuario
registrar en el sistema un nuevo usuario solo el 11-feb usuarios
crear nuevo usuario
requiere nombre, apellido, esperado
83
administrador puede agregar usuarios
nombre de usuario, e-mail, contraseña y se determina si es administrador o usuario
4 editar usuarios
solo el administrador puede editar y cambiar datos y contraseñas de los usuarios o desactivarlos 12-feb usuarios
editar información de usuarios
requiere nombre, apellido, nombre de usuario, e-mail, contraseña y se determina si es administrador o usuario esperado
Ilustración 26. Agregar usuario
Fuente: Elaboración propia
84
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
Id Caso de Prueba
Descripción Fecha Área Funcional / Sub proceso
Funcionalidad / Característica
Datos / Acciones de Entrada
Resultado Esperado/Fallido
5 agregar cliente
registrar en el sistema un nuevo cliente 11-feb clientes
crear nuevo cliente
requiere nombre, apellido, dirección, e-mail, teléfono esperado
6 editar clientes
editar y cambiar datos de los clientes 12-feb clientes
editar información de clientes
requiere nombre, apellido, dirección, e-mail, teléfono esperado
85
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
86
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
Id Caso de Prueba
Descripción Fecha Área Funcional / Sub proceso
Funcionalidad / Característica
Datos / Acciones de Entrada
Resultado Esperado/Fallido
7 agregar proveedor
Ver lista proveedores registrar en el sistema un nuevo proveedor o eliminar existente 15-feb proveedores
crear nuevo proveedor
requiere nombre, apellido, dirección, e-mail, teléfono esperado
8 editar proveedor
editar en el sistema un proveedor existente 16-feb proveedores
editar proveedor existente
requiere nombre, apellido, dirección, e-mail, teléfono esperado
87
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
88
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
Id Caso de Prueba
Descripción Fecha
Área Funcional / Sub proceso
Funcionalidad / Característica
Datos / Acciones de Entrada
Resultado Esperado/Fallido
9 agregar categoría
registrar en el sistema la categoría del producto 3-mar categorías crear categoría
requiere de nombre de la categoría esperado
10 editar categoría
editar en el sistema la categoría del producto 4-mar categorías crear categoría
requiere de nombre de la categoría esperado
89
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
90
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
Id Caso de Prueba
Descripción Fecha
Área Funcional / Sub proceso
Funcionalidad / Característica
Datos / Acciones de Entrada
Resultado Esperado/Fallido
11 agregar producto
registrar en el sistema un nuevo producto 8-mar productos crear producto
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, esperado
91
existencia mínima en inventario, existencia inicial
12 editar producto
editar en el sistema un producto existente
12-mar productos editar producto
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 mínima en inventario, existencia inicial esperado
Ilustración 37. Lista de productos
Fuente: Elaboración propia
92
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
93
Ilustración donde se puede ver el inventario
16.5.20. Caso de prueba 13. Generar inventario
Id Caso de Prueba
Descripción Fecha
Área Funcional / Sub proceso
Funcionalidad / Característica
Datos / Acciones de Entrada
Resultado Esperado/Fallido
13 inventario
genera una lista con el inventario existente
22-mar inventario
listado del inventario donde muestra la cantidad disponible de cada producto
podemos ver un listado con lo mencionado anteriormente y además podemos ver un historial de cada producto donde nos muestra la cantidad de entradas, productos, y salidas con reporte ordenado por fechas esperado
Ilustración 40. Inventario
Fuente: Elaboración propia
94
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
Id Caso de Prueba
Descripción Fecha
Área Funcional / Sub proceso
Funcionalidad / Característica
Datos / Acciones de Entrada
Resultado Esperado/Fallido
14 Reabastecer
muestra el campo donde buscamos por id o por código el producto el cual queremos reabastecer
26-mar
inventario
el sistema debe poder reabastecer el producto buscado
debe actualizar y agregar la cantidad dada del producto al sistema y actualizar la base de datos con los productos gestionados esperado
95
15 Reabastecimientos
genera un reporte de reabastecimientos ordenado por fecha
26-mar
inventario
genera reporte de reabastecimientos
genera un reporte de reabastecimientos ordenado por fecha esperado
Ilustración 42 reabastecer
Fuente: elaboración propia
96
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
Id Caso de Prueba
Descripción Fecha
Área Funcional / Sub proceso
Funcionalidad / Característica
Datos / Acciones de Entrada
Resultado Esperado/Fallido
16 venta
realizar la venta de uno o más productos 5-abr vender
generar la venta de uno o más productos del stock
requiere de la información de productos en el inventario, información del cliente, informe total de la venta esperado
97
17 factura de venta
finalizar la venta de uno o más productos e imprimir la respectiva factura 5-abr vender
finalizar la venta de uno o más productos del stock
requiere de la información de productos en el inventario, información del cliente, información del cliente, vendedor, producto, descuento, subtotal, IVA y total de la venta esperado
Ilustración 44. Realizar venta
Fuente: Elaboración propia
98
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
99
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
Id Caso de Prueba
Descripción Fecha
Área Funcional / Sub proceso
Funcionalidad / Característica
Datos / Acciones de Entrada
Resultado Esperado/Fallido
18
reporte automático de stock bajo
generar automáticamente un reporte al correo del administrador y del proveedor de un producto en baja existencia 6-abr productos
generar reporte automático de stock
requiere de tomar la información del producto que al momento de la venta genere un reporte de baja existencia e en el inventario esperado
Ilustración 47. Producto bajo en inventario
Fuente: Elaboración propia
100
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
Id Caso de Prueba
Descripción Fecha
Área Funcional / Sub proceso
Funcionalidad / Característica
Datos / Acciones de Entrada
Resultado Esperado/Fallido
19 lista de ventas
reporte de ventas ordenado por fecha de venta 13-abr ventas
genera una lista de ventas totales ordenado por fecha de venta
reporte de ventas totales donde podemos ver cada venta discriminada en su factura y eliminar la venta para para hacer la devolución esperado
101
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
102
Id Caso de Prueba
Descripción Fecha
Área Funcional / Sub proceso
Funcionalidad / Característica
Datos / Acciones de Entrada
Resultado Esperado/Fallido
20 Ventas
reporte de ventas ordenado por fechas seleccionadas 18-abr reportes
el sistema debe generar el reporte de ventas en el rango seleccionado de fechas
el sistema debe generar el reporte de ventas global según lo solicitado en el rango de fechas por el usuario esperado
21 Inventario
reporte de entradas y salida de productos 20-abr reportes
el sistema debe generar el reporte de entradas y salidas de productos en el rango seleccionado de fechas
el sistema debe generar el reporte de entradas y salidas de los productos totales o de un producto en específico según lo solicitado en el rango de fechas por el usuario esperado
22
movimiento de productos
reporte estadístico de productos más vendidos 26-abr reportes
el sistema debe generar el reporte de entradas y salidas de productos en el rango seleccionado de fechas
el sistema debe generar el reporte de salidas de los productos o de un producto en específico según lo solicitado en el rango de fechas por el usuario esperado
23 Reportes
envió de reportes al correo del administrador 30-abr reportes
el sistema debe enviar el reporte seleccionado
el sistema debe enviar el reporte seleccionado al correo del administrador para este poder realizar las estadísticas requeridos esperado
103
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
104
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
105
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
106
Ilustración 55. Maquetación final 2
Fuente: Elaboración propia
107
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
108
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.
109
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
110
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.
111
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.
112
Winder, R. (1995). Desarrollo de software con C++. Madrid: Edisiones Diaz de
Santos.
![Ficha resumen información contable 2014 [1 cara] V4...1/04 Inventario a 01/09 Inventario Final (CV) Efectivo Medio (AN) Compras (PU) Ventas Autoconsumo familiar y pagos en especie](https://static.fdocuments.ec/doc/165x107/5f0667c97e708231d417d4db/ficha-resumen-informacin-contable-2014-1-cara-v4-104-inventario-a-0109.jpg)
