1095

UNIVERSIDAD MAYOR DE SAN ANDRES FACULTAD DE CIENCIAS PURAS Y NATURALES CARRERA DE INFORMATICA

PROYECTO DE GRADO “APLICACIÓN ESTOCASTICA AL SISTEMA DE INVENTARIOS DE VANGUARD LTDA. PARA LA TOMA DE DECISIONES” PARA OPTAR AL TITULO DE LICENCIATURA EN INFORMATICA MENCION: INGENIERIA DE SISTEMAS INFORMATICOS Postulante:

Ramiro Machaca Honorio

Tutor:

Lic. Mario Loayza Molina (M.Sc.)

Revisor:

Lic. Germán Huanca Ticona LA PAZ – BOLIVIA 2008

DEDICATORIA A mi madre Francisca y a mi familia que nunca dejaron de alentarme. A mi padre, mis hermanos Rolando y Víctor que ya no están pero que siempre confiaron en mi.

AGRADECIMIENTOS Mis más sinceros agradecimientos a: Lic. Hernán Sánchez Salazar Gerente General de Vanguard Ltda. por su constante colaboración para el desarrollo del proyecto. Lic. Germán Huanca Ticona, como docente revisor que me brindo la disponobilidad de su tiempo y su comprensión. Lic. Mario Loayza , docente tutor de Taller II, por su orientación y consejos brindados para el desarrollo del presente proyecto. Lic. Julio Velásquez , por el gran apoyo que me brindo con su experiencia y disponibilidad de su tiempo. Mis grandes amigos Galo, Marco, y muchos que no los menciono que siempre me impulsaron a continuar con mis propósitos. Mi familia, que en las buenas y en las malas no dejaron de apoyarme.

RESUMEN

El crecimiento inminente del auto transporte hizo que el comercio de auto partes se incremente vertiginosamente, implicando de esta manera la apertura de muchas empresas con respecto al rubro. Vanguard Ltda., empresa líder en repuestos es una de ellas que se dedica exclusivamente a la importación, distribución y comercialización de artículos automotrices, cuyo objetivo es satisfacer la demanda parcial del mercado. La gran masa de información que se genera obliga a la empresa a tomar ciertas decisiones para mantener sus almacenes con el stock necesario y tener información oportuna. El presente proyecto es justamente la alternativa y herramienta que permite cubrir estas necesidades; con la aplicación de promedios móviles (Proceso Estocástico) se reduce la incertidumbre que se tenia para decidir la cantidad necesaria de un articulo que se debe adquirir para mantener un equilibrio en su sistema de inventario; se administra de mejor manera la información, se registran todas las transacciones para tener un mejor control y seguimiento de un articulo, se emiten reportes que permiten visualizar el comportamiento del sistema. Para realizar el análisis y diseño del sistema se utilizo el Proceso Unificado Racional y como lenguaje de modelado se hizo uso de UML (Lenguaje Unificado de Modelado); para la programación se utilizo el lenguaje de programación orientada a objetos con la herramienta Visual Studio.NET 2005 y Sql Server 2005 bajo la plataforma Windows XP SP2.

INDICE GENERAL 1

INTRODUCCIÓN

1

1.2

ANTECEDENTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.3

PLANTEAMIENTO DEL PROBLEMA

............

3

1.4

OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.4.1 Objetivo General

..........................

4

1.4.2 Objetivos Específicos. . . . . . . . . . . . . . . . . . . . . . . .

4

JUSTIFICACIÓN

..............................

5

1.5.1 Justificación Técnica. . . . . . . . . . . . . . . . . . . . . . . .

5

1.5.2 Justificación Económica

..................

5

........................

6

1.5

1.5.3 Justificación Social.

2

1.6

ALCANCES Y APORTES . . . . . . . . . . . . . . . . . . . . . . . .

6

1.7

METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.8

TECNICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

1.9

HERRAMIENTAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

MARCO CONCEPTUAL

8

2.1

EL PROCESO UNIFICADO (P.U.) . . . . . . . . . . . . . . . . .

8

2.1.1 Modelo de Casos de Uso

....................

10

2.1.2 Modelo de análisis

.........................

10

2.1.3 Modelo de diseño

.........................

10

2.1.4 Modelo de despliegue

......................

10

2.1.5 Modelo de implementación . . . . . . . . . . . . . . . . . . .

11

2.1.6 Modelo de prueba

..........................

11

FASES DENTRO DE UN CICLO . . . . . . . . . . . . . . . . . . .

11

2.2.1 Fase de inicio

..............................

11

2.2.2 Fase de elaboración . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.2.3 Fase de construcción . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.2.4 Fase de transición . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.3

LENGUAJE UNIFICADO DE MODELADO (U.M.L.) . . .

12

2.4

CORRESPONDENCIA DE UN MODELO ORIENTADO

2.2

A OBJETOS A UN MODELO RELACIONAL . . . . . . . . .

13

2.5

EL MODELO DE DATOS RELACIONAL . . . . . . . . . . . .

14

2.6

SISTEMA DE BASE DE DATOS (BD) . . . . . . . . . . . . . . .

14

2.7

SISTEMA DE GESTIÓN DE BASES DE DATOS (SGBD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.8

SEGURIDAD DE BASE DE DATOS . . . . . . . . . . . . . . . .

15

2.9

INVENTARIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.9.1 Control de Inventario

.......................

16

2.10

FACTURACION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.11

PROCESOS ESTOCÁSTICOS . . . . . . . . . . . . . . . . . . . . .

16

2.11.1 Promedios móviles. . . . . . . . . . . . . . . . . . . . . . . . . .

18

EL MODELO COCOMO . . . . . . . . . . . . . . . . . . . . . . . . .

19

2.12 3

ANALISIS INSTITUCIONAL

21

3.1

EVALUACIÓN DE LA SITUACIÓN ACTUAL . . . . . . . .

21

3.1.1 Organización Institucional . . . . . . . . . . . . . . . . . . . .

21

3.1.2 Organigrama institucional

....................

21

PROCESO ORGANIZACIONAL . . . . . . . . . . . . . . . . . . . .

23

3.2.1 Procesos y flujo de información actual

..........

23

.......................

28

3.2.3 Determinación de requerimiento . . . . . . . . . . . . . . .

28

ANÁLISIS DE FACTIBILIDAD . . . . . . . . . . . . . . . . . . . .

29

3.3.1 Factibilidad Económica

.....................

29

3.3.2 Ventajas del sistema de información . . . . . . . . . . . .

30

3.2

3.2.2 Análisis de problemas 3.3

3.3.3 Modelo COCOMO: las bases para el empleo

4

de COCOMO II . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.3.4 Factibilidad Técnica . . . . . . . . . . . . . . . . . . . . . . . . .

32

3.3.5 Factibilidad Operacional . . . . . . . . . . . . . . . . . . . . . .

32

DISEÑO LOGICO Y FISICO

34

4.1

DISEÑO LÓGICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

4.1.1 Diagrama de Casos de Uso

....................

34

4.1.2 Diagrama de Casos de Uso General . . . . . . . . . . . . . .

34

4.1.3 Diagrama parcial y documento de descripción

de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

4.1.4 Diagramas de Clase (Modelo conceptual) . . . . . . . . . .

42

4.1.5 Diagramas de Clase (Modelado estructural) . . . . . . . . .

44

4.1.6 Diagrama de interacción . . . . . . . . . . . . . . . . . . . . . . . . .

47

4.1.7 Diagramas de Secuencia . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.1.8 Correspondencia del Modelo OOA a un Modelo Relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.9

Tablas de sistema

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.1.10 Modelo Estocástico 4.2

49

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

DISEÑO FÍSICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.2.1 Diagrama Modular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.2.2 Diseño de Interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . 57 4.2.3 Entradas y Salidas 4.2.4 Implementación

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.2.4.1 Arquitectura Física 4.2.4.2 Programación 5

6

7

. . . . . . . . . . . . . . . . . . . . . . . 62

. . . . . . . . . . . . . . . . . . . . . . . . . . . 63

EVALUACION DEL SISTEMA APESIV

64

5.1

MODELO DEL SISTEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2

CALIDAD DEL SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . .

65

5.3

MÉTRICAS DE CALIDAD . . . . . . . . . . . . . . . . . . . . . . . . . .

65

5.4

FUNCIONALIDAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

5.5

CONFIABILIDAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

5.6

PRUEBA DE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

5.7

LA MANTENIBILIDAD . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

5.8

SEGURIDAD DEL SISTEMA . . . . . . . . . . . . . . . . . . . . . . . . .

70

5.9

ASPECTOS PREVENTIVOS . . . . . . . . . . . . . . . . . . . . . . . . .

70

CONCLUSIONES Y RECOMENDACIONES

72

6.1

CONCLUSIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.2

RECOMENDACIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

REFERENCIA BIBLIOGRAFICA

74

ANEXOS

75

INDICE DE TABLAS Tabla 3.3.1 Costo de Investigación y Construcción del Sistema Tabla 3.3.3. Matriz de Coeficientes COCOMO

. . . . . . . . . . . 30

. . . . . . . . . . . . . . . . . . . . . . . 31

Tabla 3.3.4 Equipo Computacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Tabla 4.1.10 Datos históricos, Bujías. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Tabla 4.1.11 Datos históricos, Retenes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Tabla 4.1.12 Datos históricos , hojas de corcho. . . . . . . . . . . . . . . . . . . . . . . . . .

55

Tabla 5.4.1 Número de entradas de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Tabla 5.4.2 Número de Salida de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Tabla 5.4.3 Consultas Externas

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Tabla 5.4.4 Número de Archivos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Tabla 5.4.5 Número de Interfases externas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Tabla 5.4.6 Valor de ajuste de Complejidad de Punto de Función . . . . . . . . . . . 67 Tabla 5.4.7 Escala de Punto de Función

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

INDICE DE FIGURAS

Figura 2.1 Proceso de desarrollo de software

......................

Figura 2.2 El proceso de nacimiento hasta su muerte

8

................

8

......................

9

............................

9

Figura 2.5 Representación del proceso estocástico . . . . . . . . . . . . . . . . . . . . . .

17

Figura 2.3 Un ciclo con sus fases e iteraciones Figura 2.4 Los cinco flujos de trabajo

Figura 2.6 Notación utilizada en los modelos de predicción de series de tiempo 18 Figura 3.1.1 Organigrama Institucional Figura 3.2.1.a Venta al contado

............................

22

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Figura 3.2.1.b Traspasos entre almacenes

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Figura 3.2.1.c Pedido de Mercadería . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Figura 3.2.1.d Venta al Crédito

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Figura 4.1 Diagrama de caso de uso general . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Figura: 4.2.a: Diagrama parcial de casos de uso Informe a Gerencia

. . . . . 35

Figura: 4.2.b: Diagrama parcial de casos de uso Pedido de Artículos

. . . . . 36

Figura: 4.2.c: Diagrama parcial de casos de uso Facturación

. . . . . . . . . . . 37

Figura: 4.2.d: Diagrama parcial de casos de uso Asignación

. . . . . . . . . . . 38

Figura: 4.2.e: Diagrama parcial de casos de uso Compra Local

. . . . . . . . . . . 39

Figura: 4.2.f: Diagrama parcial de casos de uso Inventario . . . . . . . . . . . . . . . . . 40 Figura: 4.2.g: Diagrama parcial de casos de uso Ingreso de Mercadería

. . . . . 41

Figura 4.3 Diagramas de clase con la agregación de asociación

. . . . . . . . . . . 45

Figura 4.4 Diagrama de clase con la agregación y operaciones

. . . . . . . . . . . 46

Figura 4.5 Diagrama de secuencia: informes

. . . . . . . . . . . . . . . . . . . . . . . 47

Figura 4.6 Diagrama de secuencia: facturación

. . . . . . . . . . . . . . . . . . . . . . . 48

Figura 4.7 Diagrama de secuencia: Ingreso de Mercadería . . . . . . . . . . . . . . . . . 48 Figura 4.8 Diagrama de secuencia: Pedido de artículos faltantes. . . . . . . . . . . . 49 Figura 4.9 Correspondencia de UML a un modelo Relacional

. . . . . . . . . . . 49

Figura 4.10 Grafica de datos históricos y pronóstico, Bujías. . . . . . . . . . . . . . . . 53 Figura 4.11 Grafica de datos históricos y pronóstico, Retenes. . . . . . . . . . . . . . . 54 Figura 4.12 Grafica de datos históricos y pronóstico, hojas de Corcho. . . . . . . . 56 Figura 4.13 Interfase de inicio para el acceso al sistema. . . . . . . . . . . . . . . . . . . 58 Figura 4.14 Interfase, Solicitud de Clave de Acceso. . . . . . . . . . . . . . . . . . . . . . 59 Figura 4.15 Grafico de Pronostico de Ventas . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Figura 4.16 Ventana de Facturación. Figura 5.1 Modelo del Sistema

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

1.- INTRODUCCIÓN Vanguard Ltda., es una entidad privada dentro del rubro de la comercialización, dedicada exclusivamente a la importación, distribución y venta de artículos automotrices para todo tipo de vehículos, con el objeto de satisfacer la demanda parcial del mercado que viene dándose con un crecimiento inminente del transporte urbano, superando a nivel local mas de cien mil vehículos, lo que conmina a la empresa a tomar ciertas decisiones para tratar de mantener sus almacenes con la mercadería respectiva, tratando también de evitar la existencia de mercadería en sobre stock y obsolescencia, más concretamente, para mantener un equilibrio dentro de su sistema de inventario. En Vanguard Ltda. Se tiene un departamento de importaciones que esta encargado del control de existencia de artículos, para ello se tiene un registro de inventario que se considera anualmente y que permite a la empresa la adquisición de artículos faltantes para completar el stock. Todo este trabajo se lo realiza sin considerar aspectos técnicos ni científicos lo que ocasiona en algunos casos problemas para la empresa. En ese sentido se pretende desarrollar un sistema de información de inventario y facturación para la empresa Vanguard Ltda. Que le permita reducir la incertidumbre de la adquisición de artículos de partes de vehículos, coadyuvando a la toma de decisiones para no tener faltantes de artículos ni un sobre stock de las mismas. El sistema contemplara una base de datos que registrara todas las ventas y compras de la empresa, así mismo los clientes con los cuales tiene relación y los proveedores. Para todo ello se empleara y considerara todos los conocimientos de manejo de la información, las metodologías que se emplean y sirven de base para el desarrollo de sistemas y las facilidades que estas brindan para aplicarlas.

1.2.- ANTECEDENTES La empresa Vanguard Ltda.. se creó en la década de los setenta quedando constituida la sociedad por los esposos y actuales propietarios Lic. Hernán Sánchez Salazar y Sra. Delia Archondo de Sánchez. La empresa queda ubicada en la calle Héroes del Acre Nro.1454 en la zona de San Pedro. La principal actividad de la empresa es la importación y comercialización de partes de vehículos en la ciudad de La Paz. Se mantiene un contacto con proveedores de Europa y Norte América, se maneja partes originales de vehículos de todo tipo, de la misma forma se tiene clientes mayoristas y pequeños distribuidos en toda Bolivia. En Vanguard Ltda.. se desarrollan diferentes procesos administrativos uno de ellos es el que se desempeña en el departamento de importaciones el inventario de los artículos de comercialización para el cual se realiza un estudio de los problemas que se presentan en los procesos, las relaciones que existen con otras instituciones y los requerimientos que se tiene para solucionar estos problemas. Se toma como referencia algunos estudios que se hicieron en empresas, como el proyecto realizados en la carrera de Informática, por ejemplo, se pudo observar en el proyecto “Sistemas de Seguimiento Clínico a Pacientes y Control de Inventarios” (Lic. Fernando Salazar y Lic. Adrián Quisberth), en el que se usan simplemente rangos de un mínimo y un máximo para el abastecimiento de los productos farmacéuticos. Otro proyecto desarrollado es el “ Sistema de Control de Inventario Proactivo King Tropical & Marine Ltda..” la comercialización de peces de coral , aplicando una metodología RUP y desarrollado en lenguaje PHP, MySQL [CAST, 2000]

También se reviso una tesis donde se emplea modelos estadísticos, tal el caso de la tesis “Predicción y Simulación Estocástica de Series Temporales” (Lic. Cuarite Ajno Lucy), que aporta una nutrida teoría sobre los procesos estocásticos, pero aplicado a Series Temporales para el estudio de predicciones de los fenómenos naturales en el que genera sus propias variables aleatoriamente para ser tomados en cuenta en las predicciones. Todos estos trabajos anteriormente mencionados consideran dentro de su desarrollo una forma de reducir la incertidumbre para tomar decisiones. 1.3.- PLANTEAMIENTO DEL PROBLEMA Actualmente en Vanguard Ltda., el proceso de control de inventarios se encuentra a cargo de la unidad de importaciones vinculado muy estrechamente con la unidad de sistemas, almacenes y contabilidad, realizando las tareas de hacer los pedidos, mantener los almacenes de las diferentes sucursales con el stock necesario, deducir si un artículo que se pide se va o no a vender en su totalidad en el tiempo futuro, y muchas otras tareas al respecto en forma manual. Se tiene gran cantidad de información histórica almacenada por gestión sobre las importaciones y ventas, lo que no es aprovechado en su integridad. Las decisiones que se toman para hacer las importaciones, están basados solamente en informaciones globales (Ejm. Tomando en cuenta las ventas por año), además, por la gran cantidad de productos que se maneja, se obvia con facilidad muchos artículos que luego vienen faltando en el almacén, o por el contrario, se pide en demasía un articulo creando un sobre stock de mercadería. Esto y muchos son los problemas que surgen, como a continuación se detalla: 1.- Desinformación en la unidad de importaciones para hacer los pedidos necesarios. 2.- Falta de aplicación de políticas de descuentos para la venta de los diferentes artículos. 3.- Incertidumbre en la toma de decisiones. 4.- Información no disponible de los clientes mayoristas. 5.- Falta de control al seguimiento del movimiento de una mercadería. 6.- Reducción de ingresos con pérdida de utilidad. 7.- Generación de mercadería obsoleta por acumulación.

8.- Excesivo pedido de mercadería, por falta de información adecuada. 9.- Venta de artículos por debajo del precio de costos por los descuentos altos. 10.- Desconfianza hacia el personal de almacenes y ventas por el nivel ejecutivo. 11.- Retrasos en los pedidos de mercadería por el volumen de información de los artículos. 12.- La no existencia de un sistema de inventario con apoyo científico para la toma de decisiones para hacer los pedidos necesarios manteniendo un equilibrio. 13.- Perdida de clientes generando ventas perdidas por no tener la mercadería. Por lo anteriormente mencionado se considera que la raíz del problema en la empresa Vanguard Ltda.. es el no contar con un sistema de inventario con apoyo científico para la toma de decisiones para hacer los pedidos necesarios manteniendo un equilibrio. (Ver anexo A, Árbol de Problemas). 1.4.- OBJETIVOS 1.4.1 •

OBJETIVO GENERAL. Diseñar e implementar una aplicación estocástica al Sistema de inventario de Vanguard Ltda.. para la toma de decisiones que permita mejorar y agilizar los procesos de comercialización de productos y el control de estos en la empresa.

1.4.2 •

OBJETIVOS ESPECIFICOS. Diseñar un modulo de control de inventario donde se registre los artículos existentes en la central, sucursales de la empresa y otorgar un informe detallado de los mismos.

•

Diseñar un modulo de control de personal que coadyuve en la asignación de personal a las sucursales dependientes y permita registrar a los proveedores y clientes de la empresa.

•

Desarrollar un modulo de seguimiento de Transacciones donde se contemple las operaciones de comercialización, transferencias de los artículos que la empresa maneja.

•

Aplicar modelos estocásticos para minimizar la incertidumbre en la toma de dediciones para la adquisición de artículos.

•

Aplicar una metodología de análisis y diseño orientado a objetos.

1.5.- JUSTIFICACIÓN. 1.5.1. - Justificación Técnica El empleo en la empresa de las nuevas tecnologías como la computadora es de gran importancia por que permitirán acelerar los trabajos administrativos. Por otro lado se empleara métodos y herramientas que se aplicaran en el estudio y análisis del sistema como: la metodología orientada a objetos para el análisis y diseño de sistemas, el modelo estadístico para el inventario. 1.5.2.- Justificación Económica.El hecho de que el presente trabajo se perfile a reducir o hacer mas predecible la incertidumbre, evitando la acumulación innecesaria de mercadería, manteniendo un equilibrio en el sistema de inventario, permitirá un uso mas adecuado de los recursos financieros, lo que justifica razonablemente el factor económico, reduciendo además el esfuerzo horas/hombre. Por otra parte, las políticas de liquidación para la mercadería en obsolescencia existente actualmente, permitirá que estos no se acumulen ocupando espacios físicos.

1.5.3.- Justificación Social.Desde el punto de vista social, el proyecto se justifica, ya que los usuarios finales (los clientes), se irán mucho mas satisfechos, vale decir que se podrá satisfacer de mejor manera a la demanda del mercado. Por otra parte, el trabajo a realizarse no solo podrá ser utilizado por el comercio automotriz, puede ser ampliado a otros sectores que de una u otra forma trabajen con similares parámetros a la que esta en estudio. Además, la aplicación escasa de los modelos estadísticos ampliara su uso para otros estudios que lo requieran 1.6.- ALCANCES Y APORTES La columna vertebral de lo que se pretende realizar esta orientado a definir procedimientos estocásticos, que permitan establecer resultados que den la garantía necesaria para tomar decisiones reduciendo la incertidumbre del usuario. La conclusión del proyecto brindara una herramienta útil y práctica para llevar a cabo un sistema de inventario, brindando facilidades para realizar pedidos de mercadería, selección de mercadería a liquidar en base a políticas preestablecidas buscando siempre un equilibrio dentro del sistema. 1.7.- METODOLOGIA Para llevar acabo el desarrollo del sistema informático, se empleara la metodología científica debido a que todas las etapas del trabajo se realizaran de manera sistemática, rigurosa y programada, en las etapas de planteamiento del problema, análisis y diseño del sistema orientado a objetos y la aplicación de un modelo estocástico.

1.8.- TECNICAS Las técnicas que se emplean para poder afrontar el problema son: •

Entrevista, individuales que se desarrollan para la obtención de información acerca de los requerimientos para mejorar el inventario de tratamiento de información y automatizar las mismas.

•

Lluvia de ideas, esta la realizamos en conjunto en una charla para ver los problemas que se presentan y lo que ellos consideran que se pueda realizar para la solución de las mismas.

•

Revisión bibliográfica, esta es la mas empleada y que se llevara acabo durante todo el desarrollo del proyecto hasta su conclusión.

•

Observación, se efectúa durante las visitas a la empresa para observar detalles importantes del accionar y desenvolvimiento de los procesos administrativos.

1.9.- HERRAMIENTAS Las herramientas que se emplean para el desarrollo del software son: •

Para la codificación del sistema se emplea el lenguaje Visual Net.

•

El sistema gestor de base de datos empleado será SQL Server.

•

Rational Rose para poder elaborar los diagramas de UML

2 ANALISIS Y DISEÑO ORIENTADO A OBJETOS Y MODELOS ESTOCASTICOS 2.- Marco Conceptual En relación al marco conceptual cabe recordar que es el sustento teórico del proyecto, por lo que se hace referencia a todas las definiciones y conceptos empleados para el desarrollo del sistema. 2.1.- El Proceso Unificado (P.U.) El proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema de software (Véase la figura 2.1)

Requisitos del Usuario

Proceso de desarrollo de software

Sistema Software

Figura 2.1 Proceso de desarrollo de software [Jaco & Rumb & Booc, 1999]. El proceso unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema (Véase la figura 2.2). Cada versión concluye con una versión del producto para los clientes.

Nacimiento

Muerte

Los ciclos concluyen con una versión Figura 2.2 El proceso de nacimiento hasta su muerte [Jaco & Rumb & Booc, 1999].

Cada ciclo consta de cuatro fases: inicio (o fase de comienzo), elaboración, construcción y transición. Cada fase se subdivide a la vez en iteraciones. Como se muestra a continuación. (Véase la figura 2.3).

Tiempo Inicio Iteración

Elaboración Iteración

…

Construcción

…

…

…

…

Transición …

Iteración

Iteración

Figura 2.3 Un ciclo con sus fases e iteraciones [Jaco & Rumb & Booc, 1999]. Cada ciclo produce una nueva versión del sistema, y cada versión es un producto preparado para su entrega. Cada ciclo se desarrolla a lo largo del tiempo. Este tiempo, a su vez se divide en cuatro fases, como se muestra en la figura 2.4.

Fases Flujos de trabajo Fundamentales

Inicio

Elaboración

Iter Iter

…

Construcción

Transición

Requisitos Análisis Diseño Implementación Prueba …

…

…

…

…

Iter

Iter

Iteraciones Figura 2.4 Los cinco flujos de trabajo [Jaco & Rumb & Booc, 1999].

Lo mas empleado en el proceso unificado es el modelado. La construcción de un sistema es por tanto un proceso de construcción de modelos. Utilizando distintos modelos para describir todas las perspectivas diferentes del sistema. La elección de los modelos para un sistema es una de las decisiones más importantes del equipo de desarrollo. A continuación se describe brevemente los modelos principales del proceso unificado: 2.1.1.- Modelo de Casos de Uso Este modelo permite que los desarrolladores de software y los clientes lleguen a un acuerdo sobre los requisitos que debe cumplir el sistema, este contiene actores, casos de uso y relaciones. 2.1.2.- Modelo de análisis Ayuda a refinar los requisitos (casos de uso) con más detalle y nos permite refinar sobre los aspectos internos del sistema. 2.1.3.- Modelo de diseño Es un modelo de objetos que describe la realización física de los casos de uso centrándose en como los requisitos funcionales y no funcionales, tienen impacto en el sistema a considerar. Además el modelo de diseño sirve de abstracción de la implementación del sistema y es, de ese modo, utilizado como una entrada fundamental de las actividades de implementación. 2.1.4.- Modelo de despliegue Define la arquitectura física del sistema por medio de nodos interconectados. Estos nodos son elementos hardware sobre los cuales pueden ejecutarse los elementos software. Con frecuencia conocemos como será la arquitectura física del sistema antes de comenzar su desarrollo. Por tanto, podemos modelar los nodos y las conexiones del modelo de despliegues tan pronto como comience el flujo de trabajo de los requisitos.

2.1.5.- Modelo de implementación Es un modelo que se encarga de representar el sistema en términos de código fuente y ejecutable, modelo de implementación describe también como se organizan los componentes de acuerdo con los mecanismos de estructuración y modularización disponibles en el entorno de implementación y en el lenguaje o lenguajes de programación utilizados y como dependen los componentes unos de otros. 2.1.6.- Modelo de prueba Se encarga de las pruebas que se llevan a cabo al sistema una vez implementado, nos permite poder saber si cumple con los casos de uso y con los objetivos que fue creado. 2.2.- Fases dentro de un ciclo Cada ciclo se desarrolla a lo largo del tiempo a su vez se divide en cuatro fases como se vio en la figura 2.4 2.2.1.- Fase de inicio El objetivo es desarrollar el análisis de la empresa o negocio hasta el punto necesario para justificar la puesta en marcha del proyecto. Primero se debe delimitar el alcance, el ámbito del sistema propuesto. Debemos diferenciar que es lo que va cubrir el proyecto, que debe cubrir la arquitectura. Delimitar las estimaciones de costo, tiempo, etc. 2.2.2.- Fase de elaboración En esta fase se recopila la mayor parte de los requisitos que aun queden pendientes, formulando los requisitos funcionales como casos de uso. Se establece también una arquitectura base para guiar el trabajo durante las fases de construcción y transición. Lo que se pretende comprender es, que es lo que se va construir y como, además de buscar la tecnología a emplear.

2.2.3.- Fase de construcción En esta fase se desarrolla un producto de software a partir de una línea base de arquitectura ejecutable y trabajando a través de una serie de iteraciones e incrementos, se desarrolla un producto software listo para su operación inicial en el entorno del usuario a menudo llamado versión beta. Esta termina con una demostración al usuario y haciendo pruebas del sistema con el fin de confirmar que se han construido correctamente los casos de uso. Las pruebas del sistema deben ser continuas hasta que estas funcionen. 2.2.4.- Fase de transición En esta fase se cumplen con todos los requisitos establecidos en las fases anteriores, hasta la satisfacción de todos los usuarios. También se gestiona todos los aspectos relativos a la operación en el entorno del usuario, incluyendo la corrección de fallas o deficiencias remitidas por los usuarios de la versión beta o por los encargados de las pruebas de aceptación. Los desarrolladores corrigen los problemas reportados e incorporan mejoramiento para la nueva versión. La fase de transición involucra actividades tales como la fabricación, el entrenamiento a los usuarios, provee asistencia de ayuda en línea y subsana fallas. 2.3.- Lenguaje Unificado de Modelado (U.M.L.) Este lenguaje es el sucesor de la oleada de métodos de análisis y diseño orientado a objetos (OOA&D) que surgió a fines de 1980 y principios de1990.[Fowl & Kend, 1999]. Como todo lenguaje este proporciona un vocabulario y las reglas para combinar palabras de ese vocabulario con el objetivo de posibilitar la comunicación. Un lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la representación conceptual y física de un sistema. Un lenguaje de modelado como UML es por tanto un lenguaje estándar para la elaboración del software.

El vocabulario y las reglas de un lenguaje como UML indican como crear y leer modelos bien formados, pero no dicen que modelos se deben crear ni cuando se debería crear. Esta es la tarea del proceso de desarrollo de software. Un proceso bien definido guiara a sus usuarios a decidir que producto producir, que actividades y que personal se emplea para crearlos y gestionarlos, y como usar esos productos para medir y controlar el proyecto de forma global. El UML es un lenguaje de modelado para visualizar, especificar, construir y documentar. En el proyecto actual se han utilizado bloques de construcción, elementos, relaciones y diagramas. 2.4.- Correspondencia de un modelo orientado a objetos a un modelo relacional El hacer corresponder una visión del mundo orientado a objetos con una visión relacional es conceptualmente directo. Como observa Rumbaugh, “la correspondencia entre un modelo de objetos y un modelo de base de datos relacional es simple, excepto para el manejo de la generalización”. Rumbaugh continúa ofreciendo algunas reglas para la correspondencia de clases y asociaciones (incluyendo relaciones de agregación) a tablas: [Booc, 1996]. •

Cada clase se corresponde con una o más tablas.

•

Cada asociación de mucho a muchos corresponde con una tabla distinta.

•

Cada asociación uno a muchos se corresponde con una tabla distinta o puede insertarse como una clave ajena.

Además sugiere una de las tres alternativas para corresponder las jerarquías de clase, subclase a tablas. •

La superclase y cada subclase se corresponde con una tabla.

•

Los atributos de la superclase se repiten en cada tabla (y cada subclase se corresponde con una tabla distinta).

•

Elevar todos los atributos de las subclases hacia el nivel de la superclase (y tener una tabla para toda la jerarquía superclase / subclase).

En el presente proyecto se esta haciendo uso de estas reglas de Rumbaugh ya que con el Proceso Unificado se llego a un modelo O.O. y como es de conocimiento el gestor de base de datos SQL tiene un manejo del modelo relacional por lo que se necesita utilizar las reglas de correspondencia para poder llegar a (SGBD) SQL Server que es un sistema administrador de Bases de Datos Relacional. 2.5.- El modelo de datos relacional Consiste en una colección de tablas, a cada una de las cuales se asigna un nombre único. Una fila de una tabla representa una relación entre un conjunto de valores. Puesto que una tabla es una colección de dichas relaciones, hay una estrecha correspondencia entre el concepto matemático de relación del cual toma su nombre el modelo de datos relacional. [Korth, 1993]. 2.6.- Sistema de Base de Datos (BD) Bases de datos es una gran colección de información organizada y enlazada al sistema, a la que se accede por medio del software. A su vez esta colección de archivos pertenece lógicamente al mismo sistema. El uso de las bases de datos permite almacenar gran cantidad de información además de las siguientes ventajas: •

Permite tener un mejor control sobre la información que se almacena.

•

Gran velocidad sobre la consulta de información.

•

Respaldo de información, dando una mayor seguridad de la misma.

•

Flexibilidad en el traslado de la información.

•

Manejo de reportes inmediatos, obteniendo el número de copias necesarias en corto tiempo.

•

Eliminar la duplicidad de datos. Se disminuye el manejo de datos erróneos.

2.7.- Sistema de gestión de bases de datos (SGBD) Un SGBD proporciona la flexibilidad en almacenamiento, recuperación de datos y

producción de información. De todas maneras el uso de un SGBD no elimina la necesidad de programas de software especializados. 2.8.- Seguridad de base de datos El método más flexible y extendido de proteger una base de datos se llama seguridad por usuario. Esta forma de seguridad es similar a los métodos usados en la mayoría de los sistemas. 2.9.- Inventario La base de toda empresa comercial es la venta y la compra de bienes o servicios; de aquí la importancia del inventario por parte de la misma. Este manejo permitirá a la empresa mantener el control oportunamente, así como también conocer al final del periodo contable un estado confiable de la situación económica de la empresa. El inventario constituye las partidas del activo corriente que están listas para la venta, es decir, toda aquella mercancía que posee una empresa en el almacén valorada al costo de adquisición, para la venta o actividades productivas. De los sistemas de inventario que se conocen (Sistema perpetuo y Sistema periódico), el mas recomendable usar es el Sistema Perpetuo a través de uno de los métodos de evaluación. El Sistema de Inventario Perpetuo: con este sistema el negocio mantiene un registro continuo para cada artículo del inventario. Los registros muestran por lo tanto el inventario disponible todo el tiempo. Los registros perpetuos son útiles para preparar los estados financieros mensuales, trimestrales o provisionalmente. El negocio puede determinar el costo de inventario final y el costo de las mercancías vendidas directamente de las cuentas sin tener que contabilizar el inventario. El sistema perpetuo ofrece un alto grado de control, por que los registros de inventario están siempre actualizados. El conocimiento de la cantidad disponible ayuda a proteger el inventario.

2.9.1.- Control de Inventario El control interno sobre los inventarios es importante, ya que los inventarios son el aparato circulatorio de una empresa de comercialización. Las compañías exitosas tienen gran cuidado de proteger sus inventarios. Los electos de un buen control interno

sobre los

inventarios incluyen: •

Conteo físico de los inventarios por lo menos una vez al año, no importando cual sistema se utilice.

•

Mantenimiento eficiente de compras, recepción y procedimientos de embarque.

•

Permitir el acceso al inventario solamente al personal que no tiene acceso a los registros contables.

•

Mantener registros de inventarios perpetuos para las mercancías de alto costo unitario.

•

Mantener suficiente inventario disponible para prevenir situaciones de déficit, lo cual conduce a perdidas en ventas.

•

No mantener un inventario almacenado demasiado tiempo, evitando con eso el gasto de tener dinero restringido en artículos innecesarios.

2.10.- Facturación Es un documento tributario de compra y venta que registra la transacción comercial obligatoria y aceptada por ley. Este comprobante acredita la venta de mercaderías o la prestación de servicios. La facturación tiene por finalidad acreditar la transferencia de bienes, la entrega en uso o la prestación de servicios cuando la operación se realice con sujetos del Impuesto General a las Ventas que tengan derechos al crédito fiscal. Asimismo cuando el comprador o usuario lo solicite a fin de sustentar gastos y costos para efecto tributario y en el caso de operaciones de exportación. 2.10.- Procesos estocásticos. La teoría de los procesos estocásticos se lo define generalmente como la parte dinámica de la teoría de las probabilidades en la que se estudia un conjunto de variables aleatorias (llamado un proceso estocástico) desde el punto de vista de su interdependencia y su

comportamiento limite. Se observa un proceso estocástico siempre que se examina un proceso que se desarrolla en el tiempo de manera controlada por leyes probabilísticas. Por tanto definimos un proceso estocástico como una familia de variables aleatorias: {z (t,w), t

T yw

S}

Donde T se denomina conjunto índice y S es el espacio muestral asociado a un experimento aleatorio. T generalmente representa el tiempo, pero puede tener distintas naturalezas. [Parz,1972 ]

Figura 2.5 Representación del proceso estocástico [Marq, 1994] Por la naturaleza del tiempo y del espacio, los procesos estocásticos pueden ser: 1

Procesos estocásticos discretos en el tiempo y en el espacio

2

Procesos estocásticos discretos en el tiempo y continuos en el espacio

3

Procesos estocásticos continuos en el tiempo y discretos en el espacio.

4

Procesos estocásticos continuos en el tiempo y en el espacio.

En el transcurso del desarrollo del proyecto, nos limitaremos al uso del caso numero 1. Dentro de los procesos estocásticos se hallan los Procesos Normales, Procesos de WienerLevy, Procesos puntuales, Procesos Markovianos, Procesos no Normales, Series de Tiempo. En el proyecto utilizamos Métodos de Atenuación, PROMEDIOS MOVILES que es parte de Series de Tiempo.

2.10.1.- Promedios móviles. Un modelo se convierte en una manera de experimentar con la realidad sin tener que invertir en una unidad operativa a escala natural. Este tipo de modelo también se lo conoce como modelo de simulación. Un modelo de Predicción (Makr & Whee, 1998) consiste en los procedimientos utilizados para desarrollar un pronóstico. Existen muchos modelos pero en cuanto a modelos cuantitativos existen solo dos tipos bien definidos: Las Series de Tiempo y los Métodos Causales. La notación que se utiliza se muestra en el siguiente cuadro: VALORES DE PREDICCION Valores observados

X1 X2 X3........Xt-2 Xt-1 Xt

Ft+1 Ft+2 Ft+3………Ft+m

Periodo i

1 2 3……t-2

t+1 t+2 t+3 ……….t+m

Valores estimados

F1 F2 F3……Ft-2 Ft-1 Ft

Valores de Error

e1 e2 e3 ……et-2 et-1 et

t-1 t

Presente Valor real=patrón + aleatoriedad

Figura 2.6 Notación utilizada en los modelos de predicción de series de tiempo. [Tirs, 2001] El símbolo X identifica los valores históricos observados, y para indicar los valores de predicción se utiliza la letra Ft+1 donde el subíndice (t+1) indica el valor pronosticado del periodo t+1. Debido a que el mundo de los negocios no es determinístico, la aleatoriedad siempre está presente, lo cual significa que siempre existe una diferencia o desviación entre los valores reales observados y los valores de predicción, denotada como sigue: Et = Xt - Ft Donde el subíndice t indica que en el periodo i hay un error que esta examinándose. Debido a que la exactitud pasada y futura son tan importantes, es necesario conocer las medidas más usuales del error de predicción. a) Error Promedio

b) Error Promedio Absoluto (MAD: Mean absolute deviation) c) Promedio del error al cuadrado (MSD: Mean square deviation) d) Error absoluto medio porcentual (MAPE:Mean absolute percent error)

En este caso, la formula general para los promedios móviles simples es:

En esta fórmula Ft es la predicción para el presente periodo, donde los valores X, t-1, t-2 …t-n representan los valores observados de los periodos pasados hasta n. Para Ft+1, la formula es:

Lo que nos interesa a nosotros es el valor de la ultima predicción, en este caso seria la predicción para Ft+1. Bajo que margen de error se encuentra este valor? Para el cálculo del margen de error, usamos la siguiente fórmula:

IC, es el intervalo de confianza al 95% de confiabilidad, Ft+1 es la última predicción, el valor 1.96 es obtenido de la tabla normal con el 95% de confiabilidad, la raíz cuadrada es del promedio de la suma de los errores al cuadrado. 2.11.- El Modelo COCOMO Barry Boehm, en su libro sobre economía de la ingeniería de software, introduce una jerarquía de modelos de estimación de software con el nombre de COCOMO, por su nombre en ingles (Constructive, Cost, Model) modelo constructivo de costos. La jerarquía de modelos de Boehm esta constituida por lo siguiente:

•

Modelo I: El modelo COCOMO básico calcula el esfuerzo y el costo del desarrollo de software en función del tamaño del programa, expresado en las líneas estimadas de código (LDC).

•

Modelo II: El modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en función del tamaño del programa y de un conjunto de conductores de costos que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto. El presente proyecto empleara este modelo.

•

Modelo III: El modelo COCOMO avanzado incorpora todas las características de la versión intermedia y lleva a cabo una evaluación del impacto de los conductores de costos en cada caso (análisis, diseño, etc.), del proceso de ingeniería de software.

Los modelos COCOMO están definidos para tres tipos de proyectos de software que son: 1.-Modo orgánico: Proyectos de software relativamente pequeños y sencillos en los que Trabajan pequeños equipos, con buena experiencia en la aplicación, sobre un conjunto de requisitos poco rígidos (por ejemplo, un programa de análisis termal desarrollado para un grupo calórico). 2.-Modo semiacoplado: Proyectos de software intermedios (en tamaño y complejidad) en los que, equipos con variados niveles de experiencia, deben satisfacer requisitos poco o medio rígidos (p. ej.: un sistema de procesamiento de transacciones con requisitos fijos para un hardware de terminal o un software de gestión de base de datos). 3.-Modo empotrado: Proyectos de software que deben ser desarrollados en un conjunto de

hardware,

software

y

restricciones

operativas

muy

restringido.

3 ANALISIS INSTITUCIONAL DE LA EMPRESA VANGUARD Ltda. 3.1.- Evaluación de la Situación Actual En esta parte se describirá las actividades que se llevan acabo en la empresa, los procesos que se desenvuelven, así como sus actores. La empresa Vanguard Ltda.. Se dedica a la importación y comercialización de partes de vehículos en la ciudad de La Paz. La empresa mantiene relaciones con empresas del rubro que atienden los pedidos como ser las empresas Faderpa Ltda., Toyosan y otros. Con quienes intercambia información y tiene una participación activa en diferentes actividades de transacciones comerciales. Estas actividades de la Vanguard Ltda. Con las empresa anteriormente mencionadas más las producidas dentro de la empresa como la comercialización e inventario, generan procesos (que mas adelante serán objeto de análisis) que son realizados en la mayoría de los casos en forma manual lo que determina una demora en la documentación, presentación de informes, atención al público, desfases en la toma de desiciones y las actividades de escritorio en general. El objetivo de la empresa es la comercialización, importación, distribución y venta de artículos automotrices para todo tipo de vehiculo buscando satisfacer a un mercado amplio y variado en cuando a sus exigencias. 3.1.1.- Organización Institucional En esta parte se realiza el estudio de los roles y funciones del personal que trabaja en la institución, la forma de organización, para lo cual nos ayudará el organigrama que tiene en la institución figura: 3.1.1, el que será detallado posteriormente. 3.1.2.- Organigrama institucional El organigrama institucional es como sigue:

DIAGRAMA ORGANIZACIONAL DE LA EMPRESA VANGUARD Ltda. Gerencia General

Gerencia Administrativa

Contabilidad

Caja

Gerencia Comercial

Creditos

Encargado de Sucursal

Vendedor 1

Vendedor 2

Figura 3.1.1 Organigrama Institucional Fuente: Vanguard Ltda.

Departamento de Importaciones

Jefe de Ventas

Vendedor A

Vendedor B

A continuación se realizara una breve descripción de los componentes más sobresalientes que están representados en el organigrama (figura: 3.1.1). •

Gerencia General: Esta encargada de tomar las decisiones en la empresa, generalmente esta realiza los contactos con las empresas proveedoras de los productos para la empresa, este puesto es ocupado por el propietario de la Empresa.

•

Gerencia administrativa: Esta dirigida por un profesional titulado en administración de empresa este vela por el buen manejo de la institución, generalmente es quien contrata al personal, y vela por el buen funcionamiento de la empresa, trabajando en forma directa con la gerencia de la institución.

•

Gerencia Comercial: Es la que se ocupa de la comercialización de los productos de la empresa realizando marketing para ello, mantiene contactos estrechos con los clientes ya sean mayoristas o al detalle, cuenta con un grupo de vendedores que realizan el trabajo operativo.

•

Departamento de importaciones: Este departamento es la encargada de realizar todos los pedidos de los productos faltantes en la empresa, este mantiene contactos con los proveedores y se encarga de la distribución de los productos a los distintos almacenes de la empresa distribuida en la ciudad de La Paz.

3.2.- Proceso Organizacional En esta parte se descubrirá el flujo de la información y los procesos existentes dentro de la empresa y con algunas instituciones externas. 3.2.1.- Procesos y flujo de información actual Como anteriormente se menciono, el flujo de la información y los procesos que se realizan dentro la empresa en su mayoría son manuales, eventualmente en algunas ocasiones se emplea la computadora, para realizar algunos documentos.

A continuación se realiza un flujograma de algunos procesos que se realiza en la institución. Procedimiento: Venta al Contado.

Clientes

Vendedor

Almacén

Caja

Inicio

Solicita Producto

Revisar Documento

No

Existe Artic.

SI

Producto

Producto Factura

Fin

Figura 3.2.1.a Venta al contado Fuente: Elaboración propia

Factura Producto

Procedimiento: Traspasos entre Almacenes Almacén destino Y

Encargado de ventas sucursal Y

Encargado de ventas sucursal X

Almacén X

Inicio

Revisar documento

Hacer Pedido

No

Confirmar

Si

Existen. Ingresar los Productos

Recepcion nota de traspaso

Actualizar Kardex

Emitir nota de Ingreso

Emitir nota de traspaso

Actualizar kardex

Fin

Figura 3.2.1.b Traspasos entre almacenes Fuente: Elaboración propia

Enviar los Productos

Procedimiento: Pedido de Mercadería Encargado de Importaciones

Gerencia Comercial

Contabilidad

Gerencia General

Inicio

Solicita movimiento de mercadería de artículos con poco stock

Imprime solicitud de movimiento de ventas

Verifica Solicitud

Analiza Documentación Existen Recurso Verifica Solicitud Elabora Solicitud de compra

No

necesario por demenda?

Inicia compra del proveedor

Si

No

Fin

Figura 3.2.1.c Pedido de Mercadería Fuente: Elaboración propia

si

Autoriza Solicitud de compra

Cliente

Vendedor

Procedimiento: Ventas al Crédito Encargado de Créditos

Almacén

Caja

Revisa Docum del cliente

Inicio

Solicitud de credito

Revisa Documento

reg. clie

Si

No No Confirma Exist.Art

Producto Factura

Producto

Reg. Cliente y evaluación de monto

Si

No

Si Aceptar Credito?

Fin

Figura 3.2.1.d Venta al Crédito Fuente: Elaboración propia

Factura Producto

3.2.2.- Análisis de problemas Luego de realizar las entrevistas correspondientes con el directorio de la empresa y los correspondientes jefes de área y la observación en el desenvolvimiento de los procesos se identifico los siguientes conflictos. 1.- Desinformación en la unidad de importaciones para hacer los pedidos necesarios. 2.- Falta de aplicación de políticas de descuentos para la venta de los diferentes artículos. 3.- Incertidumbre en la toma de dediciones. 4.- Información no disponible de los clientes mayoristas. 5.- Falta de control al seguimiento del movimiento de una mercadería. 6.- Reducción de ingresos con pérdida de utilidad. 7.- Generación de mercadería obsoleta por acumulación. 8.- Excesivo pedido de mercadería, por falta de información adecuada. 9.- Venta de artículos por debajo del precio de costos por los descuentos altos. 10.- Desconfianza hacia el personal de almacenes y ventas por el nivel ejecutivo. 11.- Retrasos en los pedidos de mercadería por el volumen de información de los artículos. 12.- La no existencia de un sistema de inventario con apoyo científico para la toma de decisiones para hacer los pedidos necesarios manteniendo un equilibrio. 13.- Perdida de clientes generando ventas pérdidas por no tener la mercadería. 3.2.3.- Determinación de requerimiento A continuación se señalan los requerimientos que no están satisfechos y los problemas que los clientes y trabajadores encuentran en la actualidad y que el nuevo sistema va a solucionar: Otorgar una información más certera para la toma de las decisiones. Aplicar las políticas que maneja la empresa para una mejor administración de ella. Una información adecuada y oportuna de parte del departamento de importaciones para la adquisición de los productos. Evitar con el sistema el sobre stock para reducir las perdidas producidas por ello.

Evitar los retrasos de los pedidos que ocasiona la pérdida de clientes por la falta de los productos. Mejorar el sistema de inventario automatizando todos los trabajos relacionados con este. 3.3.- Análisis de Factibilidad Existen técnicas excelentes para la comparación de los costos y los beneficios del sistema propuesto. Al estimar se toma en cuenta no solo el procedimiento técnico a utilizar en el proyecto, sino también los recursos, costo y planificación. El tamaño del proyecto es otro factor importante que puede afectar la precisión de las estimaciones. A medida que el tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del software. Para ser considerado como factible un proyecto debe pasar por lo menos las siguientes tres pruebas, de lo contrario el proyecto no es factible. 3.3.1.-Factibilidad Económica Para poder realizar este análisis lo que se realiza en principio es determinar el costo de investigación y construcción del nuevo sistema (Tabla 3.3.1), para lo cual el punto de partida es determinar el costo del software que constituye un porcentaje del costo total de los sistemas basados en computadoras. A diferencia de tiempos anteriores hoy en día el software se constituye en el elemento más caro en los sistemas informáticos. El tiempo que se contabiliza es de 8 meses aproximadamente, este tiempo es corroborado por el modelo COCOMO posteriormente, si suponemos una jornada de 8 horas diarias de trabajo. En esta tabla 3.3.1 se muestra la relación de tiempo y costo del sistema:

Tabla 3.3.1 Costo de Investigación y Construcción del Sistema TIEMPO COSTO COSTO COSTO Aprox. TOTAL Por TOTAL Nº ($US) Por día Hora Horas/ de DESCRIPCION ($US) ($US) Hombre Per. Estudio y análisis del sistema actual 1 280 1,78 14,2 500 Análisis y diseño del nuevo sistema *1 504 1,8 14,3 900 Programación del sistema *1 672 1,78 14,2 1200 TOTALES 3 1456 1,78** 42,7 2600 * COCOMO ** Promedio Nota: Costo total = Tiempo Total * Costo Entre otros costos menores se tiene: 800 $US Por lo tanto el costo total del sistema es: Costo de inventario y Construcción del sistema

2600 $US

Otros costos TOTAL

800 $US 3400 $US

3.3.2.-Ventajas del sistema de información Lo que se realiza es detallar los beneficios que el nuevo sistema puede brindar a la empresa en su labor de servir mejor al público, a la administración de la empresa. Para ello se considera los beneficios tangibles e intangibles que puedan existir. Los beneficios en las tareas de mantenimiento de registros son: Aumento de la capacidad para el mantenimiento de registros en términos de espacio y costo. Mantenimiento de registros más completo y sistemático. Estandarización del mantenimiento de registro. Aumento de la cantidad de datos que se pueden guardar por registro. Posibilidad de recoger y guardar automáticamente datos de los registros: ventas, compras, etc. Mejora de la seguridad en el almacenamiento de registros. Mejora en la portabilidad de los registros. Los beneficios en las tareas de búsqueda de registros son:

Obtención de los registros mas rápido. Mejores posibilidades de actualizar registros en la base de datos. Mejores posibilidades de mantener un detalle sobre los accesos a los registros y por quien. Los beneficios en las tareas de cálculo e impresión son: Mejora en la exactitud de las tareas de cálculo. Reducción en el cálculo e impresión. Incremento en la velocidad de cálculos aritméticos e impresiones. 3.3.3.- Modelo COCOMO: las bases para el empleo de COCOMO II es el costo de esfuerzo de desarrollo de software estimado luego de determinar la arquitectura del sistema. Tabla 3.3.3. Matriz de Coeficientes COCOMO Nivel

Básico

Intermedio

Modo

ai

bi

ai

bi

Orgánico

2.4

1.05

3.2

1.05

Semiencajado

3.0

1.12

3.0

1.12

Empotrado

3.6

1.2

2.8

1.2

Como se puede observar (Tabla 3.3.3), se tiene la matriz de coeficientes COCOMO, para los diferentes modos y niveles, se tiene los diferentes estándares de complejidad de esfuerzo del personal como en el caso del básico que varia de 2.4 a 3.6 según la complejidad del proyecto. A continuación realizamos una aplicación de este modelo COCOMO II en el proyecto. Exponente bi = 1.05 este puede variar hasta un máximo 1.2 El Coste es : Km = 2.4 * Sk1.05 = 2.4 * (1.3) k 1.05 = 3.1 ≈ 3 personas / mes Donde Sk representa el tamaño expresado en miles de código, para el caso particular se determina 1.300 líneas aproximadamente. El tiempo de desarrollo se da por:

td = 2.5 Km0.28 = 2.5 * (3) m 0.28 td = 3.4 ≈

meses.

Donde Km se obtiene de la operación anterior y td es el tiempo de desarrollo en meses. El exponente 0.28 puede variar hasta 0.91 bajo el supuesto que una persona haga el trabajo de dos, entonces tenemos lo siguiente: td * 2 = 3 meses * 2 = 6

meses.

El cual es el tiempo requerido para el desarrollo del software del sistema. 3.3.4.- Factibilidad Técnica En la empresa adquirirá una computadora, que cuente con los requerimientos necesarios para el funcionamiento del sistema, o se adecuara uno que ya existe, por lo que no surgirán problemas mayores en la instalación del sistema informático. La empresa desea cambios en su campo, es decir contar con una tecnología que le permita mejorar la atención al público (clientes), que interactúan con el sistema, por tanto la empresa está en total aceptación de la utilización del equipo computacional y el sistema que se desarrolla. El equipo computacional será descrito mas adelante. (Tabla 3.3.4) 3.3.5.- Factibilidad Operacional En la institución existe el personal capacitado para realizar tareas técnicas de computación, por lo que no existirán mayores problemas al respecto. Sin embargo es necesario enseñar el manejo de la información a los encargados del área al cual va dirigido el sistema (departamento de importaciones y ventas), Esta capacitación se realizara oportunamente.

Tabla 3.3.4 Equipo Computacional CANT. 1 1 1 1 1 1 1 1 1

DETALLE Disco duro 80 GB. Memoria 256 DDR II Tarjeta madre AsRock Microprocesador 3.0 GB. original Lector de DVD Tarjeta de fax módem Floppy Case combo m/t/p cortapicos TOTAL Fuente: Elaboración propia

IMP .$US 50 18 75 110 25 7 8 45 2 598 $us

4.- DISEÑO LOGICO Y FISICO 4.1.- Diseño Lógico El diseño lógico utiliza un modelo gráfico, donde se formula las especificaciones funcionales para los módulos de software. A continuación se muestra los diagramas que se utiliza en el análisis y diseño. 4.1.1.- Diagrama de Casos de Uso El diagrama de caso de uso, ilustra gráficamente las fronteras del sistema con el resto del universo, nos permite identificar en forma clara y concisa cada uno de los flujos de datos y los actores. En la Figura 4.1 se realiza el diagrama de caso de uso general del sistema. 4.1.2.- Diagrama de Casos de Uso General

Caso de Uso: General

Importaciones

Transacciones

Impuestos

Cliente

Proveedor Control de Personal

Personal

Control de Inventario

Gerencia

Sucursal

Figura 4.1 Diagrama de caso de uso general Fuente: Elaboración propia 4.1.3.- Diagrama parcial y Documento de descripción de casos de uso A continuación mostramos la interacción entre el usuario y el sistema con los diagramas de casos de uso parcial y la descripción de los mismos para describir cada uno

de los casos de uso, en este documento se detalla el nombre del caso uso, los actores del caso de uso, una descripción del desenvolvimiento y el proceder de los actores en el caso de uso, el flujo principal con los eventos del actor y el sistema, la precondición del sistema, la poscondición y por ultimo la presunción en sistema. Documento de Descripción de Casos de Uso: DOCUMENTO DE DESCRIPCIÓN DE CASOS DE USO CU-1 a) Nombres:

Información de las actividades en la empresa

b) Actores:

Gerencia

c) Descripción

Un informe detallado de cómo se esta desenvolviendo las transacciones comerciales en general en la empresa además de la adquisición de los artículos. Eventos Actor Eventos de Sistema

d) Flujo Principal

1. Ingreso al modulo de asignaciones de artículos, como de llevan acabo las ventas de los distintos artículos.

1. Presenta la opción de listado de asignaciones, la venta de artículos por fechas.

e) Precondición

2. Reporte de importaciones de 2. Se abre el modulo de artículos. compras de artículos. 3. Solicitud de impresión de informes 3. Opción de poder imprimir los de lo pedido. informes deseados. -Que el sistema tenga los datos actualizados de los distintos módulos

f) Post Condición

-Se tiene el informe impreso

g) Presunción

- La Base de datos de proyectos esta disponible. Caso de Uso: Informe a Gerencia

Registro Artículos Registro de Personal Usa Usa

Usa Informes

Registro de Factura

Usa

Gerencia

Usa Registro de Import acion Registro de Ventas

Figura: 4.2.a: Diagrama parcial de casos de uso Informe a Gerencia

Fuente: Elaboración propia

DOCUMENTO DE DESCRIPCIÓN DE CASOS DE USO CU-2 a) Nombres:

Pedido de Artículos.

b) Actores:

Importaciones, gerencia, proveedor.

c) Descripción

Lo que se hace es verificar la existencia de los artículos para determinar que artículos faltan para completar el stock. Eventos Actor Eventos de Sistema

d) Flujo Principal

1. Revisa los artículos cuya existencia en saldo sea el mínimo. 2.Detalle de los artículos faltantes

1. Ingresa a registro de productos para verificar la existencia.

e) Precondición

2. Lista de los artículos e impresión de ellos en base a la frecuencia de venta de estos, en formato pedido. 3.El usuario escoge terminar 3. Cierre u opción salir del modulo. -Tener actualizados los módulos de venta considerando las sucursales.

f) Post Condición

-Tener la información impresa del pedido de los artículos faltantes.

g) Presunción

La Base de datos de proyectos esta disponible.

Caso de Uso: Pedido de Artículos Faltantes

Verifica y selecciona existencia de articulos

Listado de artículos con existencia minima

Importaciones

Gerencia

Calculo de pronostico de demanda

Informe de pedido de mercadería

Proveedor

Figura: 4.2.b: Diagrama parcial de casos de uso Pedido de Artículos

Fuente: Elaboración propia

DOCUMENTO DE DESCRIPCIÓN DE CASOS DE USO CU-3 a) Nombres:

Facturación.

b) Actores:

Agente de Ventas, cliente

c) Descripción

Se realiza la transacción del articulo solicitado por el cliente, ya sea este una venta al crédito o efectivo y dando de baja la cantidad solicitada del o los artículos. Eventos Actor Eventos de Sistema

d) Flujo Principal

1. El agente de ventas pregunta al cliente la modalidad de venta (crédito o efectivo). 2. De acuerdo a la calificación, el agente de ventas termina el proceso o atiende solicitud del cliente.

e) Precondición f) Post Condición g) Presunción

1. Si es en efectivo continua la atención, si es crédito solicita el código del cliente y devuelve información de calificación. 2. Pide el código de vendedor, y pasa a detalle pidiendo el código del producto o su número de fábrica, devolviendo información del precio y existencia. 3. Solicita información del cliente e imprime la factura, registrando toda la información de la transacción.

3. Con la conformidad del cliente, el agente de ventas decide emitir factura. 4. Se entrega una copia de factura al cliente más los productos. -Tener actualizados los datos de clientes con acceso a crédito, y tener la existencia necesaria de productos. - Se tiene impreso la factura con copias, para el cliente y para documentación de la empresa. La Base de datos de proyectos esta disponible. Caso de Uso: Facturación Verifica existencia de saldo del articulos solicitado

Toma los datos del cliente para registrarlo

Registra el codigo del vendedor

Agente de Venta

Registra los datos de los articulos vendidos

Cliente

Emite Factura

Figura: 4.2.c: Diagrama parcial de casos de uso Facturación

Fuente: Elaboración propia

DOCUMENTO DE DESCRIPCIÓN DE CASOS DE USO CU-4 a) Nombres:

Asignación de Artículos.

b) Actores:

Sucursal, Almacenes.

c) Descripción

Se realiza los traspasos correspondientes entre almacenes de la oficina central y sucursal. Eventos Actor Eventos de Sistema

d) Flujo Principal

f) Post Condición

1. El almacén origen ingresa al 1. El sistema le solicita escoger el modulo de asignación de artículos. almacén destino. 2. Almacén origen determina 2. Pide ingresar el código del artículos y cantidades a enviar. artículo y la cantidad. 3. Solicita imprimir la nota de 3. Muestra la opción de imprimir la envió para enviarlo una copia junto nota, actualizando los saldos de los con la mercadería al almacén artículos que salen y registrando el destino. movimiento. -Tener una nota de solicitud de artículos del almacén destino y las cantidades necesarias del artículo a enviar. -Se tiene impreso la nota de envió y nota de ingreso del almacén destino.

g) Presunción

La Base de datos de proyectos esta disponible.

e) Precondición

Caso de Uso: Asignación de Artículos a sucursal Verifica existencia de saldo de artículos solicitado

Determina artículos y cantidades a enviar

Registra el código del despachante

Encargado De Sucursal

Registra los datos de los articulos a enviar

Almacen solicitante

Emite una nota de traspaso

Figura: 4.2.d: Diagrama parcial de casos de uso Asignación

Fuente: Elaboración propia

DOCUMENTO DE DESCRIPCIÓN DE CASOS DE USO CU-5 a) Nombres:

Compra

b) Actores:

Gerencia, Importaciones, Proveedor

c) Descripción d) Flujo Principal

Importaciones elabora un listado de compra de proveedores locales para abastecer el stock de artículos faltantes por la necesidad inmediata. Eventos Actor Eventos de Sistema

e) Precondición

1. El encargado de importaciones 1. El sistema emite un listado de busca artículos faltantes. los artículos faltantes. 2. Realiza una selección y 2. Emite un listado de los clasificación de artículos de artículos requeridos requerimiento inmediato. determinando el costo estimado. 3. Envía la orden de compra a 3. Registra los datos de la orden gerencia para su aprobación. de compra. -Tener actualizado la información de los proveedores locales.

f) Post Condición

-Evitar pérdidas de clientes dando más confianza a los mismos.

g) Presunción

La Base de datos de proyectos esta disponible.

Caso de Uso: Compra de Artículos Faltantes a nivel local Verifica y selecciona existencia de articulos

Elabora un listado de articulos mas relevantes con existencia minima

Importaciones

Gerencia

Realiza el calculo de pronostico de demanda para determinar cantidades

Genera un listado informe de pedido de mercaderia

Figura: 4.2.e: Diagrama parcial de casos de uso Compra Local

Fuente: Elaboración propia

Proveedor Local

DOCUMENTO DE DESCRIPCIÓN DE CASOS DE USO CU-6 a) Nombres:

Inventario

b) Actores:

Gerencia, Encargado de Almacén

c) Descripción

A solicitud de gerencia, se pide un inventario de artículos existentes para informe a la renta o por control interno. Eventos Actor Eventos de Sistema

d) Flujo Principal

1. El encargado de almacén entra al modulo de inventario. 2. Escoge una de las opciones mostradas por el sistema.

e) Precondición f) Post Condición g) Presunción

1. Da la opción de escoger por rango en forma continua, o en forma aleatoria. 2. Pide ingresar el ítem inicial y el ítem final y muestra una lista con la descripción y saldos. Genera un informe. 3. Finaliza proceso.

3. Compara con la existencia física y elabora un informe para remitir a gerencia. -Tener actualizado la información en todos los módulos correspondientes. -Se tiene un informe real de los saldos de artículos para actualizar la información en la base de datos. La Base de datos de proyectos esta disponible.

Caso de Uso: Inventario Solicita informe de inventario general

Solicita informe de inventario por grupo y aleatorio Elabora un listado de articululos y saldos

Encargado de Almacen

Compara con la existencia física

Gerencia

Emite informe de Inventario

Figura: 4.2.f: Diagrama parcial de casos de uso Inventario

Fuente: Elaboración propia

DOCUMENTO DE DESCRIPCIÓN DE CASOS DE USO CU-7 a) Nombres:

Ingreso de Mercadería

b) Actores:

Importaciones, contabilidad.

c) Descripción

Una vez llegado los productos por importación, el encargado de importaciones registra, verifica la cantidad y estado para luego dar su conformidad. Eventos Actor Eventos de Sistema

d) Flujo Principal

1. Importaciones verifica el estado de la mercadería y de acuerdo a ello determina ingresar los productos a almacén. 2. Luego de haber hecho el costeo, remite informe a contabilidad. 3. Entra a opción de ingreso de mercadería y escoge el almacén. e) Precondición f) Post Condición g) Presunción

1. El sistema solicita introducir el factor para hacer el cálculo de precios y costo. Emite un informe. 2. Termina el proceso de costeo.

3. Muestra la opción de Almacén al que desea ingresar los productos. Emite un informe de ingreso por importación. -Tener la carpeta del proceso de importación con el detalle de los productos. -Se tiene impreso y registrado los artículos obtenidos por importación. La Base de datos de proyectos está disponible.

Caso de Uso: Ingreso de mercaderia Verifica el estado de la mercadería

Realiza el costeo para determinar precio y costo

Registra el ingreso de la mercadería a almacén

Importaciones

Elabora nota de remision

Contabilidad

Figura: 4.2.g: Diagrama parcial de casos de uso Ingreso de Mercadería

Fuente: Elaboración propia

DOCUMENTO DE DESCRIPCIÓN DE CASOS DE USO CU-8 a) Nombres:

Impuestos

b) Actores:

Gerencia, Contabilidad.

c) Descripción

Impuestos internos mensualmente exige el reporte de ventas, el sistema genera el mismo bajo el formato requerido. Eventos Actor Eventos de Sistema

d) Flujo Principal

1. Contabilidad ingresa a facturación.

e) Precondición f) Post Condición g) Presunción

1. El sistema solicita la clave de acceso. 2. Escoge la opción Impuestos 2. Pide ingresar el periodo Internos. del cual se requiere el informe de ventas. Muestra un listado de facturas con el número correlativo. 3. Verifica los datos, genera un 3. Pide el nombre del archivo archivo para importarlo al sistema de con el cual se bajara la impuestos. información. Por default “sit_vede.txt” -Tener actualizado la información en todos los módulos correspondientes. -Se tiene un archivo portable para interactuar con el sistema de impuestos Internos. La Base de datos de proyectos está disponible.

4.1.4.- Diagramas de Clase (Modelo conceptual).- Un modelo conceptual explica mejor el flujo de información, tanto en el proceso en el movimiento de importaciones, almacenes y facturación. Para lo cual se realiza en primera instancia la captura de conceptos y atributos. Conceptos y atributos Transferencias

Proveedor

•

Codtrans

•

Codpro

•

Codartc

•

Nombre

•

Codpro

•

Representantelegal

•

Codper

•

Dirección

•

Fechatrans

•

Teléfono

•

Destino

•

Correo

•

Origen

Facturación

Personal

•

Nrofactura

•

Codper

•

Codcli

•

Nombre

•

Fecha

•

Apepat

•

NIT

•

Apemat

•

Descripción

•

Dirección

•

Monto

•

Teléfono

VentaArticulo

•

Cargo

•

Codventa

Articulo

•

Codartic

•

Codartic

•

Codsucur

•

Nombre

•

Codcli

•

Descripción

•

Descripción

•

Cantidad

•

Codsucur

•

tipventa

•

Dirección

•

Monto

•

Teléfono

•

Fecha

•

Encargado

Sucursal

CompraArticulo •

Codcompr

•

Codartic

•

Codartic

•

Fecha

•

Codpro

•

Codpro

•

Nfabrica

•

Cantidad

•

Precio

•

Precio

•

Fechaingreso

•

Monto

•

Cantidad

Artprecios

TipoCliente

Devoluciones

•

Tipcli

•

Nrofactura

•

Teléfono

•

Codarti

•

Garante

•

Codcli

•

RepresentanteLeg

•

Cliente

Cliente

•

Fecha

•

Codcli

•

NIT

•

Nombre

•

Descripción

•

tipcli

•

Monto

•

Dirección

•

Codper

•

NIT

Saldo_Sucursal •

Codsalsur

•

Codarti

•

Codsucur

•

Codpro

•

Cantidad

4.1.5.- Diagramas de Clase (Modelado estructural).- Los diagramas de clases se utilizan para modelar la vista de diseño estática de un sistema. En primera instancia con la captura de conceptos, posteriormente los diagramas de clase con la agregación de asociación figura 4.3 y por ultimo los diagrama de Clases con Agregación de Atributos y operaciones figura 4.4.

Diagramas de clase con la agregación de asociación

Tipo Cliente Tipcli Telefono Garante RepresentanteLeg

Proveedor Codpro Nombre Representantelegal Direccion Telefono Correo

1

Cliente Codcli 1 Nombre Tipcli Direccion 1 NIT 1

Contiene

1

Recibe

* 1 Codartic Codpro Nfabrica Precio Fechaingreso Cantidad *

* CompraArticulo Codcompr Codartic Fecha Codpro Cantidad Precio Monto *

Facturacion Nrofactura Codcli 1 Fecha NIT Descripcion Monto * 1

1

*

1

* Codartic Nombre Descripcion * 1

Sucursal

Ingresa

Codsucur Direccion Telefono Encargado

transferencia

1

1 Asigna

* Codtrans Codartic * Codpro Codper Fechatrans Destino Origen

*

Nrofactura 1 Codarti Codcli 1 Cliente 1 Fecha NIT Descripcion Monto Codper Registra

Otorga

Articulo

Devolucion

*

Adquiere

1 Adquiere

Artprecios

Devuelve

Proporciona

Saldo_sucursal Codsalsur 1 Codarti Codsucur Codpro Cantidad 1

* 1

*

Personal *

Registra

1 Codper Nombre Apepat Apemat * Direccion Telefono Cargo 1

1 Registra 1

Figura 4.3 Diagramas de clase con la agregación de asociación Fuente: Elaboración propia

1

VentaArticulo Codventa Codartic 1 Codsucur Codcli Descripcion Cantidad Tipventa Monto Fecha

Diagramas de clase con la agregación y operaciones

Tipo Cliente Tipcli Telefono Garante RepresentanteLeg

Contiene

CompraArticulo Codcompr Codartic Fecha Codpro Cantidad Precio Monto Adicion() Busqueda()

Codartic 1 Codpro Nfabrica Precio Fechaingreso Cantidad

1

Codartic Nombre Descripcion

*

Codsucur Direccion Telefono Encargado Adicion() Eliminacion() Modificacion()

1

1 Asigna

1

Devolucion Nrofactura Codarti Codcli 1 Cliente Fecha NIT 1 Descripcion 1 Monto Codper

1

Adicion() Eliminacion() Modificacion()

* transferencia Codtrans Codartic * Codpro Codper Fechatrans * Destino Origen Adicion() Eliminacion()

*

1

*

1 Sucursal

Adicion() Eliminacion()

* Articulo

*

Facturacion Nrofactura Codcli Fecha NIT Descripcion 1 Monto

Adicion() Eliminacion()

1

*

1

Artprecios

Adicion() Eliminacion()

*

Recibe

Adquiere

Proporciona

*

1

Adicion() Eliminacion() Modificacion() 1

Devuelve

Saldo_sucursal Codsalsur Codarti Codsucur Codpro Cantidad

1

1

Adicion() Eliminacion() Modificacion()

Adicion() Eliminacion() Modificacion()

Adquiere

1

Ingresa

Adicion() Busqueda() Registra

*

*

Otorga

Proveedor Codpro Nombre Representantelegal Direccion Telefono Correo

Cliente Codcli Nombre Tipcli Direccion NIT

1 Personal *

Registra

1 Codper Nombre Apepat Apemat * Direccion Telefono Cargo 1 Adicion() Eliminacion() Modificacion()

1

Adicion() Eliminacion() Busqueda() Registra

1

Figura 4.4 Diagrama de clase con la agregación y operaciones Fuente: Elaboración propia

1

VentaArticulo Codventa Codartic 1 Codsucur Codcli Descripcion Cantidad Tipventa Monto Fecha

*

4.1.6.- Diagrama de interacción.- Estos diagramas son modelos que describen la manera en que colaboran grupos de objetos para cierto comportamiento. Habitualmente, un diagrama de interacción capta el comportamiento de un solo caso de uso. El diagrama muestra cierto número de objetos y los mensajes que se pasan entre estos objetos dentro del caso de uso; tomaremos en cuenta los diagramas de secuencia. 4.1.7.- Diagramas de Secuencia.- En un diagrama de secuencia, se muestran los eventos generados por actores externos, su orden y los eventos internos del sistema.

Diagrama de Secuencia, Informes Gerencia

Importaciones Articulos()

Pedido de Informe

Personal

Sistema

Compra Articulos() Venta Articulos()

Regarticulos() Elaboracion

Calculo de Compra() Bus_articulo ()

Facturacion()

Inicia el Proceso de informe

Prog_Estocastico() Venta_compra()

Proceso de Reporte

Reg_Rep()

Reg_Rep()

Figura 4.5 Diagrama de secuencia: informes. Fuente: Elaboración propia

Reg_Rep()

Diagrama de Secuencia, facturacion

Personal

Inicia facturacion

Cliente

Sistema

Ventaarticulo() Datoscliente()

Articulo() Elabora Regcliente() Proceso Factura

Facturacion()

Facturacion()

Figura 4.6 Diagrama de secuencia: facturación. Fuente: Elaboración propia

Diagrama de Secuencia, Ingreso de Mercadería

Importaciones

Inicia ingreso

Sistema

Contabilidad

Reg.Articulo() Termina registro

Actualiza Saldo Inicia Proceso

Remite nota

Genera nota de ingreso

Envia nota de remision

Figura 4.7 Diagrama de secuencia: Ingreso de Mercadería. Fuente: Elaboración propia

Diagrama de Secuencia, Pedido de Artículos Faltantes Importaciones

Sistema

Gerencia

Proveedor

Articulos() Inicio de Pedido

con saldo mínimo Prog.Estocastico () Prediccion de Demanda

Elaboracion

Elabora Lista Pedido Imprime NotaPedido Solicitud de Aprobacion Solicitud Aprobada con modificacion

Confirmacion y envio

Realiza pedido a proveedor

Figura 4.8 Diagrama de secuencia: Pedido de artículos faltantes. Fuente: Elaboración propia 4.1.8.- Correspondencia del modelo OOA aun modelo relacional 1

Adquiere

*

Personal

CompraArticulo

1

Personal

N Adquiere

CompraArticulo

Figura 4.9 Correspondencia de UML a un modelo Relacional De acuerdo a lo expuesto en el capitulo dos sobre la correspondencia de un modelo orientado a objetos a un modelo relacional fig. 4.9, se muestra a continuación el modelo relacional ver anexo B(omitiendo los atributos para favorecer la legibilidad del diagrama),

al que se ha llegado, que muestra la Base de Datos del Sistema de “Vanguard Lta.”, y el conjunto de tablas correspondientes: 4.1.9.- Tablas de sistema Tabla Transferencias in_tranferencia Tabla Facturación in_Facturacion Tabla VentaArticulo in_VentaArticulo Tabla Proveedor in_Proveedor Tabla Personal in_Personal Tabla Artículo in_Articulo Tabla Sucursal in_Sucursal Tabla CompraArticulo in_CompraArticulo Tabla TipoCliente in_TipoCliente <Tipcli, Teléfono, Garante, RepresentanteLeg>

Tabla Cliente in_Cliente Tabla Artprecios in_Artprecios Tabla Devoluciones in_Devoluciones Tabla Saldo_Sucursal in_Saldo_Sucursal 4.1.10.- Modelo Estocástico Para este cometido lo que se realiza es considerar un acontecimiento real de ventas de artículos de partes de automóviles que sucede en la empresa para ello se muestran tres casos de ventas reales de tres artículos diferentes. La tabla que se considera de venta de artículos de bujías de automóviles 14mm J-8, largo rosca 3/8 con empaquetadura (para llave de 13/16). Tabla 4.1.10 Datos históricos, Bujías Periodos de Tiempo Bujías Trimestre (2004-2007) Ventas Reales 1 139 2 289 3 82 4 127 5 162 6 87 7 38 8 265 9 94 10 154 11 175 12 16 13 0 14 78 15 100 16 60 Total bujías vendidas = 1866

Para el cálculo de esta parte se desarrollo un programa basados en los criterios estocásticos, que corresponden a las series de tiempo aplicando el método de atenuación de promedios movibles. Esta implementación consiste en aplicar las distintas formulas o modelos que permiten alcanzar el objetivo; a continuación se muestra las formulas implementadas para dicho programa: En este caso, la formula general para los promedios móviles simples es:

En esta fórmula Ft es la predicción para el presente periodo, donde los valores X, t1, t-2 …t-n representan los valores observados de los periodos pasados hasta n. Para Ft+1, la formula es:

Lo que interesa es el valor de la ultima predicción, en este caso seria la predicción para el trimestre 17, que es: F17= 79,333 , redondeado a 79. Bajo que margen de error se encuentra este valor? Para el cálculo del margen de error, se emplea la siguiente fórmula:

IC, es el intervalo de confianza al 95% de confiabilidad, Ft+1 es la última predicción, el valor 1.96 es obtenido de la tabla normal con el 95% de confiabilidad, la raíz cuadrada es del promedio de la suma de los errores al cuadrado. En nuestro ejemplo, los valores límite del Intervalo de Confianza seria: Valor superior = 79.333 + 1.96*75,987 = 228.266 Valor inferior = 79.333 - 1.96*75,987 = -69.5889 Gráficamente, se vería de la siguiente manera.

GRAFICA DE PROMEDIOS MOVIBLES 300

VENTAS

200

100

0

-100 2

4

6

8 10 TRIMESTRES

12

14

16

Ventas Reales Pronostico de ventas Pronostico para el trimestre 17

Figura 4.10 Grafica de datos históricos y pronóstico, Bujías Fuente: Elaboración propia Resultados: Ft+1 = F17 = 79.333

Pronostico de ventas para el trimestre 17

MAD = 55.82 Error promedio absoluto (Mean absolute deviation) MSD = 5774.06 Promedio del error al cuadrado (Mean square deviation) IC

= -69.5989 a 228.266

(Ver tabla de matriz de datos en anexo C)

La tabla 4.1.11 considera la venta de artículos de Retenes tipo O´ring de 1/16 de grosor. Tabla 4.1.11 Datos históricos Periodos de Tiempo Retenes Trimestre (2004-2007) Ventas Reales 1 104 2 420 3 234 4 835 5 353 6 791 7 680 8 927 9 637 10 552 11 439 12 238 13 464 Total Retenes vendidas = 6674 Realizando los cálculos correspondientes, se obtiene la grafica de la figura 4.11 GRAFICA DE PROMEDIOS MOVIBLES 1000

VENTAS

750

500

250

0

1

2

3

4

5

6

7 8 9 TRIMESTRES

10 11 12 13 14

Ventas Reales Pronostico de ventas Pronostico para el trimestre 14

Figura 4.11 Grafica de datos históricos y pronóstico, Retenes

Resultados: Ft+1 = F14 = 380.333

Pronostico de ventas para el trimestre 14

MAD = 236.6 Error promedio absoluto (Mean absolute deviation) MSD = 79379.5 Promedio del error al cuadrado (Mean square deviation) IC

= -171.874 a 932.541

La tabla 4.1.12 considera la venta de artículos de Hojas de Corcho de 1/16 pulgadas de grosor, 24 x 36 pulgadas de tamaño. Tabla 4.1.12 Datos históricos Periodos de Tiempo Hojas de corcho Trimestre (2004-2007) Ventas Reales 1 28.5 2 13.35 3 25.25 4 33 5 14 6 35 7 39.5 8 26 9 3 10 2 11 21 12 25 13 6.5 Total H. de C. vendidas = 272.1

Realizando los cálculos correspondientes, se obtiene la grafica de la figura 4.12

GRAFICA DE PROMEDIOS MOVIBLES 50 40

VENTAS

30 20 10 0 -10 -20 1

2

3

4

5

6

7 8 9 TRIMESTRES

10

11

12

13

14

Ventas Reales Pronostico de ventas Pronostico para el trimestre 14

Figura 4.12 Grafica de datos históricos y pronóstico, Hojas de Corcho Resultados: Ft+1 = F17 = 79.333

Pronostico de ventas para el trimestre 17

MAD = 55.82 Error promedio absoluto (Mean absolute deviation) MSD = 5774.06 Promedio del error al cuadrado (Mean square deviation) IC

= -69.5989 a 228.266

4.2.- Diseño Físico 4.2.1.- Diagrama Modular.- Para una mejor apreciación se realiza el diagrama modular donde se observa en los diagrama HIPO (Ver Anexo D) el diseño modular del sistema, la aplicación y el accionar de las distintas alternativas en el sistema. Seguimiento de Transacciones.- Este módulo esta encargado de la parte de los movimientos comerciales, transferencias, venta y compra de los artículos de la institución así como la facturación. Control de personal.- En este módulo predomina el trabajo de control al accionar del personal de la institución, cuenta con un registro de personal, la distribución de cargos en las distintas sucursales de la empresa y los informes que generan cada uno de los registros. Control de Inventario.- Los bienes de la empresa están registrados en el registro de artículos con el que cuenta este modulo, todo el detalle de los bienes de la institución, del cual se realiza un control generalmente a mediados y finales de cada gestión. Modelo Estocástico.- Si bien el modelo estocástico no es considerado otro modulo, es un modelo que tiene participación en el modulo de inventario que cuenta el sistema, realizando una labor de calculo de pronostico en base al movimiento de los artículos de la empresa y cuyo resultado repercute en emitir información que permita una toma de decisión para la adquisición de nueva mercadería.

4.2.2.- Diseño de Interfaz de Usuario.- En esta parte del diseño, se muestra la representación de las interfaces del sistema con el usuario una vez puesto en marcha.

Figura 4.13 Interfase de inicio para el acceso al sistema

Figura 4.14 Interfase Solicitud de clave de acceso

Figura 4.15 Grafica de pronostico de Ventas.

Figura 4.16 Ventana de Facturación

4.2.3.- Entradas y Salidas La interfaz gráfica facilitara la interacción con el usuario mediante: ventanas, menús, opciones de ayuda y otros. El sistema interactuara con personas ligadas a la institución, los formatos de entrada y salida fueron diseñados de manera que guarden similitud con los formularios que se manipulaba, de forma que exista una coincidencia en los campos a llenar. Igualmente los menús y submenús tienen un estándar similar a Windows. El manual de usuario brindara una explicación completa acerca de las características del sistema. 4.2.4.- Implementación Dado que el sistema será desarrollado en Visual Net se requiere el siguiente hardware y software: El microprocesador de 1.6GHz o superior. Monitor SVGA de 800x600 o de resolución superior compatible con Microsoft Windows. 256 MB de RAM para Windows XP o superior. Microsoft Windows XP o posterior. Espacio en disco duro de 3 Gigas. Visual Net es un lenguaje de programación de propósito general, con una gran potencia en toda su estructura, su implementación en el sistema operativo Windows y sus herramientas visuales, han hecho de este lenguaje sea un líder indiscutible en lo que ha desarrollo de aplicaciones se refiere. Desarrollando bastante la gestión de base de datos a muy alto nivel, pudiendo gestionar bases de datos de tipo Access, Oracle, Paradox, dBASE, Foxpro y SQL. Este paso de gigante ha hecho de Visual Net uno de los lenguajes favoritos por los desarrolladores de aplicaciones de base de datos, en especial el hecho que Visual Net implemente el lenguaje SQL, uno de los más potentes y sencillos lenguajes de base de datos. 4.2.4.1.-Arquitectura Física El presente sistema de información computarizado, se acogerá a las siguientes pautas, para desarrollar una interfaz comprensible para el usuario.

•

El sistema pedirá entradas y producirá salidas en forma consistente.

•

Existirá un mecanismo de ayuda conveniente.

•

Proporcionara alternativas por omisión para las entradas estándar.

•

Solicitara información con una secuencia lógica.

•

Si el sistema esta realizando un proceso largo, desplegara un mensaje al usuario para que no crea que se detuvo.

4.2.4.2.-Programación La programación comienza cuando termina la actividad de diseño. Esta fase involucra la escritura de instrucciones en algún lenguaje de programación, para implantar lo que el analista ha especificado y el diseñador ha organizado en módulos. Durante la programación se contempla los siguientes problemas: Productividad: Esto es escribir mas software, mas rápidamente. Eficiencia: Es de gran importancia en muchos sistemas en tiempo real. La meta eficiencia usualmente entre en conflicto con otras metas discutidas, si se emplea mucho tiempo en la construcción de un sistema eficiente, es probable que sea menos mantenible y menos transportable, y que tenga mas errores residuales sutiles, además de que tal vez reduzca la productividad de la persona que escribió el programa. Portabilidad: Actualmente no existe un lenguaje universalmente portátil. Además del lenguaje de programación debemos preocuparnos por el estilo de programación, si la portabilidad es un factor importante. Mantenibilidad: Los sistemas viven durante mucho tiempo, por lo tanto el software debe mantenerse.

5 EVALUACION DEL SISTEMA Para la evaluación del sistema se contempla los datos obtenidos con el modelo COCOMO en el capítulo tercero donde se menciona sobre el análisis de factibilidad económica, donde se presenta la tabla 3.3.1 de Costo de Investigación y construcción del sistema, además se refiere a las ventajas del sistema de información. También se hace referencia a la matriz de coeficientes COCOMO para poder determinar el tiempo promedio de desarrollo del sistema, la factibilidad técnica y operacional. 5.1.- Modelo del Sistema La aplicación estocástica al Sistema de Inventarios para la toma de decisiones está conformado de subsistemas conectados en serie y paralelo como se muestra en la figura siguiente:

G11 Comercialización G1

Datos de Transacciones

Datos de Inventario

G13

Registro Transaccional G3

Transferencia G2

U(t) Datos de Personal

G9

G10

G12

Personal G4

Y(t) Reportes Administrativos G6

Cliente/Proveedor G5

Artículos G7

Facturacion Transferencias

G11

Clientes con creditos Lista articulos Gral. Reporte Inventario G8

Figura 5.1 Modelo del Sistema G9 = G1+G2

G10 = G4 + G5

G13 = G9 * G3

G12 = G10 * G6 Así

Por tanto Gt es la ecuación lineal.

Gt = G13 + G12 + G11

G11 = G7 * G8

5.2.-Calidad del Software La calidad del software se define como: Concordancia con los requisitos y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente [Press, 97]. La calidad del software consiste en aquellos procedimientos, técnicas e instrumentos aplicados por entes capacitados para garantizar que un producto cumpla o supere un nivel mínimo aceptable para su comercialización, si es que así se lo ha planeado, lo que hasta el momento no se tiene estándares del software, no es lo mismo que las pruebas del sistema, estos son implícitos al momento de hacer las pruebas de integración final del sistema. 5.3.- Métricas de calidad Las métricas de calidad de software proporcionan una manera de medir la calidad, descubrir y corregir errores potenciales que llevarían al fracaso inminente de cualquier sistema. Las medidas de software se pueden clasificar de dos maneras: medidas directas y medidas indirectas o Las medidas Directas del proceso de la ingeniería de software incluyen en el costo y esfuerzo aplicado. o Las medidas Indirectas del proceso de la ingeniería de software incluye la funcionalidad, complejidad, eficiencia, fiabilidad y facilidad de mantenimiento. 5.4. Funcionalidad •

Punto de función El punto de función es una métrica orientada a la función. Es una medida indirecta del software y del proceso por el cual se desarrolla. Se centra en la funcionalidad o utilidad del programa. Los puntos de función se calculan llenando la tabla 5.4.1 para el cálculo se determinan cinco características de dominios de información:

o Número de entradas de usuario. Se cuenta cada entrada de usuario que proporciona al software diferentes datos orientados a la aplicación. Las entradas deben ser restringidas.

o Número de salidas de usuarios. La salida se refiere a informes, pantallas, mensajes de error etc. o Número de peticiones de usuario. Una petición esta definida como una entrada interactiva que resulta de la generación de algún tipo de respuesta en forma de salida interactiva. o Número de archivos. Se cuenta cada archivo lógico maestro. o Número de interfases externas. Se cuenta todas las interfases legibles por el ordenador que son utilizados para transmitir información a otro sistema. Tabla 5.4.1 Número de entradas de usuario Pantalla para entrada de datos 7 Consulta seguida por una actualización

4

Aplicación de control de entrada de usuario

1

Total entradas

12

Complejidad

8

Tabla 5.4.2 Número de Salida de usuarios Salida de datos por pantalla

8

Reportes impresos

9

Datos automáticos o transacciones de otras aplicaciones

1

Total de Salidas

18

Complejidad

7 Tabla 5.4.3 Consultas Externas

Pantalla de ayuda de entrada y salida

1

Menú de selección en pantalla de entrada y salida

8

Consulta seguida por una actualización de entrada

2

Total de consultas

11

Complejidad

5

Tabla 5.4.4 Número de Archivos Tablas o archivos mantenidos por el usuario

10

Archivos lógicos internos generados o mantenidos por la aplicación

1

Archivos asequibles al usuario a través de llaves o parámetros.

1

Total Archivos

12

Complejidad

7 Tabla 5.4.5 Número de Interfases externas

Disco

1

CD - ROM

1

Backup (copia de seguridad)

1

Impresora

1

Total archivos

4

Complejidad

6

Cuenta Total = 96 + 56 + 55 + 84 + 24 = 315 Tabla 5.4.6 Valor de ajuste de Complejidad de Punto de Función Características del Sistemas

Significado

Valor

El sistema requiere copia de seguridad y recuperación fiable

Esencial

5

¿Se requiere comunicación de datos?

Significativo

4

El rendimiento es critico

Incidental

1

El sistema será ejecutado en el entorno de trabajo

Esencial

5

La entrada de datos es interactiva

Significativo

4

Son complejas las entradas, salidas o peticiones

Moderado

2

Se actualizan archivos de forma interactiva

Moderada

2

Es complejo el procesamiento interno

Medio

3

El software ha sido diseñado para ser reutilizable

Medio

3

Están incluidas en el diseño la conversión y la instalación

Medio

3

Se ha diseñado la aplicación para facilitar los cambios y para

Esencial

5

ser fácilmente utilizado por el usuario.

Con los valores de ponderación de la tabla 5.4.6 tenemos los valores de ajuste de complejidad, que determina los de ∑Fi = 37. El valor 315 es la sumatoria de los resultados parciales que son los productos de las cuentas por el peso asignado (Simple, medio y complejo), y para realizar el análisis utilizamos el peso medio. Luego remplazamos los datos en la relación de Punto de Función y se obtiene el siguiente resultado: PF = 315 * [0.81 + (0.01 * 37)] = 371.7 ≈ 372 El Punto de Función obtenido supone 372 líneas de código referentes al tamaño del sistema. Haciendo un análisis con la escala de Punto de Función Tabla 5.4.7 se concluye que el sistema tiene la funcionalidad óptima. Tabla 5.4.7 Escala de Punto de Función Escala

Observación

PF > 300

Optima

200 > PF > 300

Buena

100 > PF > 200

Suficiente

PF < 100

Deficiente

Calculando el ajuste tenemos: El valor promedio de Fi(promedio calculado) = 37 Valor máximo de Fi(máximo) = 55 La cuenta total del factor de ponderaciones 315 Remplazando estos valores en la ecuación PF(máximo) = 315 * [0.81 + (0.01 * 55)] = 428 Sacando el promedio de estos dos resultados tenemos: Prom = 372 / 428 = 0.87 Entonces Funcionalidad = 0.87 * 100 = 87% Por lo tanto se tiene un 87% de Funcionalidad.

5.5.- Confiabilidad Según teorema la confiabilidad esta dado bajo los componentes del modelo del sistema donde a cada módulo se le denomina Ri(t) La confiabilidad esta dada por: R(t) La confiabilidad de los componentes: R1(t),R2(t),……………..,Rn(t) Donde: R(t) = P ( T > t) Donde T es el tiempo para fallar el sistema. Si tres módulos funcionan independientemente están conectados en serie y la i – esima componente tiene la confiabilidad. Confiabilidad del sistema completo: R(t) = R1(t) * R2(t) * R3(t) → R(t) = Min (R1(t),R2(t),R3(t)) R(t) = exp –w1t * exp –w2t * exp –w3t = e –(w1+w2+w3)t La función de densidad de probabilidad de tiempo esta dado por: F(t) = (w1 + w2 + w3)e –(w1 + w2 + w3)t Función de distribución Donde w es un parámetro de medición W = 0.01 La confiabilidad del sistema esta dado por: R(T) = e -0.01t Para un funcionamiento de 10 horas o después de 10 horas la probabilidad de que el sistema no falle esta dado por: e -0.01(10) = e -0.1 = 0.905 Entonces se tiene un 90% de probabilidad de que el sistema no falle. 5.6.- Prueba de Software Una estrategia de prueba de software integra las técnicas de casos de prueba en una serie de pasos que dan como resultado una correcta construcción del software. o Prueba de unidad. Esta prueba se realizo a cada uno de los módulos, ya que permite que cada módulo este libre de errores. o Prueba de integración. Una vez que sea integrado todos sus componentes se realizo la verificación para que el sistema funcione sin ningún problema.

o Prueba de validación. Esta prueba es muy importante ya que se realizo la validación para verificar si el sistema satisface los requerimientos del usuario. o Prueba del sistema. Esta prueba del sistema se realizo en el lugar de actual funcionamiento. 5.7.- La mantenibilidad Se centra en el cambio que va asociado a la corrección de errores, adaptaciones y a los cambios debido a las mejoras por los requisitos cambiantes del cliente. Corrección. Incluso cuando el sistema tiene garantías de calidad, es probable que se descubra defectos en el software. Por lo tanto el mantenimiento correctivo modifica el software para corregir los errores. Adaptación. Una vez instalado el software no dura de forma permanente ya que puede que cambie su entorno original, entonces es necesario realizar el mantenimiento adaptativo para que el software se pueda adecuar a los cambios de su entorno externo. Mejora. A medida que se va utilizando el software, se va descubriendo los beneficios que producen. 5.8- Seguridad del sistema La institución debe estar organizada de tal modo que facilite y favorezca la gestión de la seguridad informática. Y esto debe cumplirse con absoluto hermetismo. Es vital contar con personal sobre el que se pueda depositar confianza. 5.9.- Aspectos preventivos Este apartado aborda los aspectos asociados al componente lógico del sistema: programas y datos. Para ello, se distingue entre las medidas para restringir y controlar el acceso y empleo de dichos recursos, los procedimientos para asegurar la fiabilidad del software (tanto operativo como de gestión) y los criterios a considerar para garantizar la integridad de la información. •

Control de acceso: Sistema de identificación, como el equipo esta designado particularmente para el empleo de los vendedores este equipo tiene un código de

acceso desde el momento del inicio y para poder ingresar al sistema solo se lo puede realizar ingresando la clave de acceso que solo lo saben la Gerencia e importaciones. •

Software de base: Control de cambios y versiones, control de uso de programas de utilidad.

6.- CONCLUSIONES Y RECOMENDACIONES 6.1

Conclusiones. Se ha logrado cumplir con los objetivos planteados durante la primera fase de desarrollo del sistema. •

El Desarrollo y construcción del sistema de inventarios con la aplicación de los procesos estocástico para la empresa Vanguard Ltda. ha concluido satisfactoriamente, cumpliendo con los requerimientos de la empresa.

•

Se logro dar mayor seguridad a la toma de decisiones con la aplicación de

los

procesos

estocásticos,

reduciendo

de

sobremanera

la

incertidumbre y haciendo mas oportuna el pedido de artículos faltantes en la empresa. •

Se logro tener un mejor control y seguimiento de los artículos en la empresa, evitando la perdida de los mismos.

•

Existe una mayor rapidez en la emisión de los informes por que todos los datos que se emplean para la misma están debidamente registrados en la base de datos.

•

Los formatos de entrada y salida fueron diseñados de manera que guardan similitud con los formularios que se manipulan, de forma que se tiene una coincidencia en los campos a llenar.

6.2

Recomendaciones.

•

Expandir el proyecto anexando a un modulo de contabilidad para tener un mejor control de costos y beneficios de la empresa.

•

Mejorar el modelo del proceso estocástico con otro modelo de más precisión, ya que a futuro se tendrá más datos históricos.

•

Dado que las características de comercializar un producto de un rubro a otro son muy similares, el software con algunas modificaciones puede ser genérico.

•

Por la tendencia del comercio electrónico, seria bueno ir en esa dirección para incrementar las ventas de los productos desarrollando un portal Web dedicado a ello.

7.-

REFERENCIA BIBLIOGRAFICA

[Booc, 1996] Booch, G., 1996: Análisis y Diseño Orientado a Objetos con Aplicaciones, 2da. Edición, 638 pp., Addison Wesley/ Díaz De Santos, México. [Fowl & Kend, 1999] Fowler, M. & Kendall, S., 1999: UML Gota a Gota 1ra. Edición, 1pp , Addison Wesley, Mexico. [Jaco & Rumb & Booc, 1999] Jacobson, I. & Rumbaugh, J. & Booch, G., 1999: The Unified Modeling Languaje User Guide, 1ra. Edición, 482 pp, Addison-Wesley, United Stated of America. [Jaco & Rumb & Booc, 1999] Jacobson, I. & Rumbaugh, J. & Booch, G., 1999: The Unified Software Development Process, 1ra. Edición, 512 pp, Addison-Wesley, United Stated of America. [Korth, 1993] Korth, H., 1993: Fundamentos de Bases de Datos, 2da. Edicion, 739 pp, MacGraw Hill, México. [Murr, 1990] Murria R. Spiegel, 1990: Estadística, McGraw-Hill.Mexico [Senn, 1994] Senn Jmes: “Analisis y Diseño de Sistemas de Informacion” Georgia State Universiti. Mexico Mc.Graw Hill 2da. Edición 1994 [Par,1971]

Emmanuel Parzen: “Procesos Estocásticos” Paraninfo, Magallanes Madrid . M.1971

[Cast,2000] Maria Nilsa, Castro Huanca “Sistemas de control de Inventario Proactivo King Tropical & Marine Ltda.” Proyecto de Grado 2000 [Cam, 2001] Tirso Campos Santillan: “Problemario de Pronósticos para la toma de decisiones” Thomson 2001. [Marq, 1994] Raul Marquiegui Navarro: “Procesos Estocásticos” Tomo I, F.C.P.N. Carrera de Estadistica 1994.

ANEXO A ARBOL DE PROBLEMAS

GENERACION DE MERCADERIA OBSOLETA POR ACUMULACION

DESCONFIANZA HACIA EL PERSONAL DE ALMACENES Y VENTAS POR EL NIVEL EJECUTIVO

DESEQUILIBRIO ADMINISTRATIVO CONTABLE

DESINFORMACION EN LA UNIDAD DE IMPORTACIONES PARA HACER LOS PEDIDOS NECESARIOS.

Y

REDUCCION DE INGRESOS CON PERDIDA DE UTILIDADES

VENTA DE ARTICULOS POR DEBAJO DEL PRECIO DE COSTO POR LOS DESCUENTOS ALTOS

PERDIDA DE CLIENTES GENERANDO VENTAS PERDIDAS POR NO TENER LA MERCADERIA

NO EXISTE UN SISTEMA DE INVENTARIOS NI POLITICAS CON APOYO CIENTIFICO PARA LA TOMA DE DECISIONES PARA HACER LOS PEDIDOS NECESARIOS MANTENIENDO UN EQUILIBRIO.

RETRASOS EN LOS PEDIDOS DE MERCADERIA POR EL VOLUMEN DE INFORMACION DE LOS ARTICULOS.

POCA INFORMACION CON LAS FUENTES DE INFORMACION AFIN.

EXECIVO PEDIDO DE MERCADERIA, POR FALTA DE INFORMACION ADECUADA

FALTA DE POLITICAS DE DESCUENTOS PARA LA VENTA DE LOS DIFERENTES ARTICULOS

iNCERTIDUMBRE EN TOMA DE DECISIONES .

INFORMACION DISPONIBLE DE CLIENTES MAYORITARIOS.

LA

NO LOS

FALTA DE CONTROL AL SEGUIMIENTO DEL MOVIMIENTO DE UNA MERCADERIA

ARBOL DE OBJETIVOS

APLICACIÓN ESTOCÁSTICA AL SISTEMA DE INVENTARIO DE VANGUARD LTDA. PARA LA TOMA DE DECISIONES

AUTOMATIZAR LAS TRANSACCIONES COMERCIALES QUE LA EMPRESA

VENTA DE ARTÍCULOS A SU PRECIO JUSTO EVITANDO DESCUENTOS ALTOS

PEDIDOS MERCADERIA OPORTUNOS O DEBIDO TIEMPO

MAYOR CONTROL SEGUIMIENTO MOVIMIENTO DE MERCADERÍA.

AL DEL UNA

DE A

SU

REALIZAR UN MODULO PARA EL CONTROL DE PERSONAL DE LA EMPRESA Y LOS PROVEEDORES Y CLIENTES CON LOS QUE CUENTA

REGISTRAR AL PERSONAL EN CADA TRANSACCIÓN DE MERCADERÍA GANANDO LA CONFIANZA DEL NIVEL EJECUTIVO

I FORMACIÓN DISPONIBLE DE LOS CLIENTES QUE TIENEN CRÉDITO.

AUMENTO DE CLIENTES EVITANDO VENTAS PERDIDAS POR TENER LA MERCADERÍA NECESARIA

AUTOMATIZAR LA REALIZACION DEL INVENTARIO DE LOS ARTICULOS CON LOS CUALES SE COMERCIALIZA EN LA EMPRESA

MANTENER ABASTECIMIENTO MERCADERÍA ALMACENES CON STOCK NECESARIO

EL DE EN EL

MEJORAR EL CONTROL DE LA MERCADERIA EVITANDO PERDIDAS DE LAS MISMAS

IMPORTAR LAS CANTIDADES ADECUADAS DE MERCADERÍA, PARA EL ABASTECIMIENTO DE LOS ALMACENES

MATRIZ DE PLANIFICACIÓN DEL PROYECTO (M.P.P.) TITULO DEL PROYECTO: “APLICACIÓN ESTOCÁSTICA AL SISTEMA DE INVENTARIOS DE VANGUARD Ltda. PARA LA TOMA DE DECISIONES” RESUMEN NARRATIVO

INDICADORES VERIFICABLES OBJETIVAMENTE

MEDIOS VERIFICABLES

SUPUESTOS

- La aplicación de los procesos Estocásticos , apoyando a la toma de decisiones con el sistema de inventarios dando mayor seguridad en la toma de decisiones haciendo mas certero lo impredecible.

- Existen varias empresas, instituciones, organizaciones que se dedican a la comercialización de diferentes artículos que pueden hacer uso de lo que se pretende realizar.

Predisposición de la empresa y de las unidades involucradas y la información de fuentes externas como el Organismo Operativo de Transito y otros afines al proyecto.

1.- Informe emitido por la empresa Vanguard Ltda..en poder del proyectista.

1.-Se utiliza la información adecuada.

FIN DEL PROGRAMA(OBJETIVO FINAL) Fin: Optimizar las tareas, procesos de las unidades involucradas, incrementando las utilidades y satisfaciendo con mas cobertura la demanda del mercado automotriz.

PROPÓSITO (OBJETIVO GENERAL)

Diseñar e implementar una aplicación estocástica al Sistema de inventario de Vanguard Ltda.. para la toma de desiciones

1.- Se reduce la incertidumbre en 90% para brindar información del adecuada para la adquisición de artículos. 2.- La emisión de informes mas creíbles y concretos de las operaciones de la empresa 3.- Se reduce el tiempo en 90% de realización de información de saldos de artículos en las sucursales.

2.-Informe detallado de cada articulo y las transacciones en el archivo de la empresa

2.- No existe interrupción en la dotación de energía eléctrica. 3.- Soporte de actualización y mantenimiento ante fallas.

1.- listado de resultados de la prueba del módulo de control de inventario almacenado en el archivo de la empresa 2.- Documentación del sistema conteniendo los resultados de la prueba del módulo de Control de personal 3.- Listado de resultados de la prueba de caja negra del modulo de Transacciones.

1.- Datos correctos en la base de datos del inventario. 2.- Datos correctos en la base de datos del personal. 3.- Datos correctos de las transacciones de la empresa. 4.- No existen modificaciones en los formularios.

- Registro de documentos - Documentos de proyectos realizados. - Registro de perfiles corregidos. - Material Bibliográfico respecto al tema. - Registro de los autores del proyecto y asesores. -Registros en medios magnéticos. - Cuestionario a los usuarios directos que operan el sistema. - Registros de pruebas a los usuarios directos.

El personal de las diferentes unidades involucradas proporciona información necesaria para el desarrollo del sistema.

PRODUCTOS: OBJETIVOS ESPECÍFICOS

* Modulo de control de inventario de la empresa. *Modulo de control de personal de la empresa.

1.- Prueba de caja negra del módulo de Control de Inventario 2.- Prueba de caja negra del modulo control de personal

*Modulo de seguimiento de Transacciones de la empresa

3.- Prueba de caja negra del Modulo de Transacciones de la empresa.

INSUMOS (ACTIVIDADES) 1. Análisis de problemas y objetivos. 2. Desarrollar y estructurar el perfil del Proyecto de Grado. 3. Estudio y análisis de los Procesos Estocásticos. 4. Estudio y análisis de los Sistemas de Inventarios (Investigación de Operaciones) 5. Diseño lógico del Sistema de Inventarios para su automatización. 6. Desarrollo de Software del Sistema de Inventarios. 7. Pruebas del Sistema de Inventarios con datos históricos. 8. Implementación del Sistema de Inventarios. 9. Documentación del Sistema (manuales, diccionario de datos, etc.).

1. 50 hrs/hombre 2. 200 hrs/hombre 3. 40 hrs/hombre 4. 40 hrs/hombre 5. 200 hrs/hombre 6. 200 hrs/hombre 7. 30 hrs/hombre 8. 10 hrs/hombre 9. 40 hrs/hombre La ejecución de las actividades requiere los siguientes suministros: - Material de escritorio - Material de impresión - Fotocopias - Textos, otros..

Resultados del Análisis de Factibilidad. Factibilidad técnica Factibilidad económica.

ANEXO B Modelo relacional de APESIV

1

1 Contiene

TipoCliente Proveedor N

1

Cliente

1 1

1 Recibe

Saldo_sucursal

Adquiere Proporciona

1 Otorga

N

Registra

1

CompraArticulo

N

Entrega

Facturación

Da

1

Devolución N

1

1 Registra

Otorga

1

N

1

Artprecios

N

1

1

N

1

VentaArticulo

Ingresa N

Adquiere

N

1

Registra

Otorga

Articulo Registra

Sucursal 1

1 Da

N

Transferencia

N Registra

N

1

1

1

Personal N

1 1

ANEXO C Tabla 4.1.10.b. Matriz de Datos para promedios móviles. Error absoluto

Pronosticos trimestre 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

de ventas ventas 139 289 82 127 170,00 162 166,00 87 123,67 38 125,33 265 95,67 94 130,00 154 132,33 175 171,00 16 141,00 0 115,00 78 63,67 100 31,33 60 59,33 79,33 Totales F(17) 79,33 MAD MSD

Error absoluto

al cuadrado

43,00 4,00 36,67 87,33 169,33 36,00 21,67 4,00 125,00 115,00 14,33 68,67 0,67

1849,00 16,00 1344,47 7627,05 28673,66 1296,00 469,46 16,00 15625,00 13225,00 205,43 4715,16 0,44

725,67

75062,68

55,82 5774,05

MAD Error Promedio Absoluto (Mean absolute deviation) MSD Promedio del error al cuadrado (Mean square deviation) IC

Intervalo de Confianza

ANEXO D Aplicación Estocástica al Sistema de Inventario de “Vanguard Ltda.” Para la toma de decisiones “APESIV”

APESIV

Seguimiento De Transacciones

Control de Personal

Control de Inventario

Comercialización

Personal

Artículos

Transferencia

Cliente/Proveedor

Informes

Informes

Informes

Diseño Modular APESIV Fuente: Elaboración propia

Módulo de Transacciones Seguimiento de Transacciones Comercialización

Transferencias

Informes

Registro de Ventas

Traspasos

Ventas

Registro de Compras

Facturación

Compras

Devoluciones

Devoluciones Impuestos Facturación Transferencias Módulo de Transacciones Fuente: Elaboración propia

Módulo Control de Personal

Control de Personal Personal

Cliente/Proveedor

Informes

Registro de Personal

Registro Clientes

Personal

Registro de Sucursal

Registro de Proveedores

Sucursal Clientes Proveedores Función del Personal Clientes con Crédito

Módulo Control de Personal Fuente: Elaboración propia

Módulo Control de Inventario Control de Inventario

Artículos

Informes

Registro de Artículos

Lista Artículos General

Registro Precio Artículos

Articulo Sucursal

Articulo Central

Módulo Control de Inventario Fuente: Elaboración propia