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

1.5 JUSTIFICACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

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

1.5.2 Justificación Económica . . . . . . . . . . . . . . . . . . 5

1.5.3 Justificación Social. . . . . . . . . . . . . . . . . . . . . . . . . 6

1.6 ALCANCES Y APORTES . . . . . . . . . . . . . . . . . . . . . . . . 6

1.7 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.8 TECNICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.9 HERRAMIENTAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 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

2.2 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

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

2.12 EL MODELO COCOMO . . . . . . . . . . . . . . . . . . . . . . . . . 19

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

3.2 PROCESO ORGANIZACIONAL . . . . . . . . . . . . . . . . . . . . 23

3.2.1 Procesos y flujo de información actual . . . . . . . . . . 23

3.2.2 Análisis de problemas . . . . . . . . . . . . . . . . . . . . . . . 28

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

3.3 ANÁLISIS DE FACTIBILIDAD . . . . . . . . . . . . . . . . . . . . 29

3.3.1 Factibilidad Económica . . . . . . . . . . . . . . . . . . . . . 29

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

3.3.3 Modelo COCOMO: las bases para el empleo

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

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

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

4 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.1.9 Tablas de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.1.10 Modelo Estocástico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.2.4 Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.2.4.1 Arquitectura Física . . . . . . . . . . . . . . . . . . . . . . . 62

4.2.4.2 Programación . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5 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

6 CONCLUSIONES Y RECOMENDACIONES 72

6.1 CONCLUSIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.2 RECOMENDACIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7 REFERENCIA BIBLIOGRAFICA 74

ANEXOS 75

INDICE DE TABLAS

Tabla 3.3.1 Costo de Investigación y Construcción del Sistema . . . . . . . . . . . 30

Tabla 3.3.3. Matriz de Coeficientes COCOMO . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 8

Figura 2.2 El proceso de nacimiento hasta su muerte . . . . . . . . . . . . . . . . 8

Figura 2.3 Un ciclo con sus fases e iteraciones . . . . . . . . . . . . . . . . . . . . . . 9

Figura 2.4 Los cinco flujos de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

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

Figura 2.6 Notación utilizada en los modelos de predicción de series de tiempo 18

Figura 3.1.1 Organigrama Institucional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Figura 3.2.1.a Venta al contado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Figura 5.1 Modelo del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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)

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.

Requisitos del Sistema

Usuario Software Proceso de desarrollo de software

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).

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.

Tiempo

Inicio Elaboración Construcción Transición

Iteración Iteración … … … … … … Iteración Iteración

Fases Flujos de trabajo Fundamentales Requisitos Análisis Diseño Implementación Prueba

Iteraciones

Inicio Elaboración Construcción Transición Iter Iter … … … … … … Iter Iter

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 y w � 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 Wiener-

Levy, 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

Periodo i 1 2 3……t-2 t-1 t

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

Valores de Error e1 e2 e3 ……et-2 et-1 et

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

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

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

Gerencia Comercial

Departamento deImportaciones

Contabilidad Creditos

Vendedor 2

Encargado deSucursal

Vendedor 1

Jefe de Ventas

Vendedor BVendedor ACaja

Figura 3.1.1 Organigrama Institucional

Fuente: Vanguard Ltda.

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

Factura Producto Producto

Existe Artic.

Revisar Documento

Fin

Factura

Solicita Producto

Producto

Inicio

SI

No

Figura 3.2.1.a Venta al contado

Fuente: Elaboración propia

Procedimiento: Traspasos entre Almacenes

Almacén destino Y Encargado de

ventas sucursal Y Encargado de ventas

sucursal X Almacén X

Enviar los Productos

Actualizar kardex

Emitir nota de traspaso

Confirmar Existen.

Revisar documento

Fin

Emitir nota de Ingreso

Actualizar Kardex

Recepcion nota de traspaso

Hacer Pedido

Inicio

Ingresar los Productos

Si No

Figura 3.2.1.b Traspasos entre almacenes


Procedimiento: Pedido de Mercadería

Encargado de Importaciones

Gerencia Comercial Contabilidad Gerencia General

compra

No

Autoriza Solicitud deExisten

Recurso

Verifica Solicitud

necesario por demenda?

Verifica Solicitud

Imprime solicitud de movimiento de ventas

Fin

Inicia compra del proveedor

Elabora Solicitud de compra

Analiza Documentación

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

Inicio

No

Si

si

Figura 3.2.1.c Pedido de Mercadería


Procedimiento: Ventas al Crédito Cliente Vendedor Encargado de Créditos Almacén Caja

No

Si

Confirma Exist.Art

Inicio

Revisa Documento

Revisa Docum del cliente

� reg. clie

Aceptar Credito?

Producto Factura Producto

Producto

Factura

Fin

Solicitud de credito

Reg. Cliente y evaluación de monto

No

No

Si

Si

Figura 3.2.1.d Venta al Crédito


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

DESCRIPCION

Nº de

Per.

TIEMPO TOTAL Horas/

Hombre

COSTO Por

Hora ($US)

COSTO Aprox. Por día ($US)

COSTO TOTAL

($US)

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 800 $US

TOTAL 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

Básico Intermedio Nivel

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. DETALLE IMP .$US 1 Disco duro 80 GB. 50 1 Memoria 256 DDR II 18 1 Tarjeta madre AsRock 75 1 Microprocesador 3.0 GB. original 110 1 Lector de DVD 25 1 Tarjeta de fax módem 7 1 Floppy 8 1 Case combo m/t/p 45 1 cortapicos 2 TOTAL 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

Control de Inventario

Control de Personal

Sucursal

Importaciones

Gerencia

Transacciones Cliente

Proveedor

Personal

Impuestos

Figura 4.1 Diagrama de caso de uso general


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

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.

2. Reporte de importaciones de artículos.

2. Se abre el modulo de compras de artículos.

d) Flujo Principal

3. Solicitud de impresión de informes de lo pedido.

3. Opción de poder imprimir los informes deseados.

e) Precondición -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 deVentas

Registro deFactura

RegistroArtículos

Registro de Importacion

Informes

Gerencia

Registro dePersonal

Usa

UsaUsa

Usa

Usa

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



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

1. Revisa los artículos cuya existencia en saldo sea el mínimo.

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

2.Detalle de los artículos faltantes

2. Lista de los artículos e impresión de ellos en base a la frecuencia de venta de estos, en formato pedido.

d) Flujo Principal

3.El usuario escoge terminar 3. Cierre u opción salir del modulo. e) Precondición -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

Calculo de pronostico de demanda

Verifica y selecciona existencia de articulos

Informe de pedido de mercadería

Listado de artículos con existencia minima

Gerencia

Importaciones

Proveedor

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



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

1. El agente de ventas pregunta al cliente la modalidad de venta (crédito o efectivo).

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. De acuerdo a la calificación, el agente de ventas termina el proceso o atiende solicitud del cliente.

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.

d) Flujo Principal

3. Con la conformidad del cliente, el agente de ventas decide emitir factura.

3. Solicita información del cliente e imprime la factura, registrando toda la información de la transacción.

4. Se entrega una copia de factura al cliente más los productos.

e) Precondición -Tener actualizados los datos de clientes con acceso a crédito, y tener la existencia necesaria de productos.

f) Post Condición - Se tiene impreso la factura con copias, para el cliente y para documentación de la empresa.


Caso de Uso: Facturación

Verifica existencia de saldo del articulos solicitado

Registra el codigo del vendedor

Registra los datos de los articulos vendidos

Toma los datos del cliente para registrarlo

Emite Factura

Agente deVenta Cliente

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



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

1. El almacén origen ingresa al modulo de asignación de artículos.

1. El sistema le solicita escoger el almacén destino.

2. Almacén origen determina artículos y cantidades a enviar.

2. Pide ingresar el código del artículo y la cantidad.

d) Flujo Principal

3. Solicita imprimir la nota de envió para enviarlo una copia junto con la mercadería al almacén destino.

3. Muestra la opción de imprimir la nota, actualizando los saldos de los artículos que salen y registrando el movimiento.

e) Precondición -Tener una nota de solicitud de artículos del almacén destino y las cantidades necesarias del artículo a enviar.

f) Post Condición -Se tiene impreso la nota de envió y nota de ingreso del almacén destino.


EncargadoDe Sucursal

Caso de Uso: Asignación de Artículos a sucursal

Verifica existencia de saldo de artículos solicitado

Registra el código del despachante

Registra los datos de los articulos a enviar

Determina artículos y cantidades a enviar

Emite una nota de traspaso

Almacen solicitante

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



a) Nombres: Compra

b) Actores: Gerencia, Importaciones, Proveedor

c) Descripción 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

1. El encargado de importaciones busca artículos faltantes.

1. El sistema emite un listado de los artículos faltantes.

2. Realiza una selección y clasificación de artículos de requerimiento inmediato.

2. Emite un listado de los artículos requeridos determinando el costo estimado.

d) Flujo Principal

3. Envía la orden de compra a gerencia para su aprobación.

3. Registra los datos de la orden de compra.

e) Precondición -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.


Caso de Uso: Compra de Artículos Faltantesa nivel local

Realiza el calculo de pronostico de demanda

para determinar cantidades

Verifica y selecciona existencia de articulos

Genera un listado informe de pedido de mercaderia

Elabora un listado de articulos mas relevantes con existencia minima

Gerencia

Importaciones

Proveedor Local

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



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

1. El encargado de almacén entra al modulo de inventario.

1. Da la opción de escoger por rango en forma continua, o en forma aleatoria.

2. Escoge una de las opciones mostradas por el sistema.

2. Pide ingresar el ítem inicial y el ítem final y muestra una lista con la descripción y saldos. Genera un informe.

d) Flujo Principal

3. Compara con la existencia física y elabora un informe para remitir a gerencia.

3. Finaliza proceso.

e) Precondición -Tener actualizado la información en todos los módulos correspondientes.

f) Post Condición -Se tiene un informe real de los saldos de artículos para actualizar la información en la base de datos.


Caso de Uso: Inventario

Solicita informe de inventario general

Elabora un listado de articululos y saldos

Compara con la existencia física

Solicita informe de inventario por grupo y

aleatorio

Emite informe de Inventario

GerenciaEncargado de Almacen

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



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

1. Importaciones verifica el estado de la mercadería y de acuerdo a ello determina ingresar los productos a almacén.

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

2. Luego de haber hecho el costeo, remite informe a contabilidad.

2. Termina el proceso de costeo.

d) Flujo Principal

3. Entra a opción de ingreso de mercadería y escoge el almacén.

3. Muestra la opción de Almacén al que desea ingresar los productos. Emite un informe de ingreso por importación.

e) Precondición -Tener la carpeta del proceso de importación con el detalle de los productos.

f) Post Condición -Se tiene impreso y registrado los artículos obtenidos por importación.

g) Presunción La Base de datos de proyectos está disponible.

Caso de Uso: Ingreso de mercaderia

Verifica el estado de la mercadería

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

Elabora nota de remision

Realiza el costeo para determinar precio y costo

ContabilidadImportaciones

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



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

1. Contabilidad ingresa a facturación. 1. El sistema solicita la clave de acceso.

2. Escoge la opción Impuestos Internos.

2. Pide ingresar el periodo del cual se requiere el informe de ventas. Muestra un listado de facturas con el número correlativo.

d) Flujo Principal

3. Verifica los datos, genera un archivo para importarlo al sistema de impuestos.

3. Pide el nombre del archivo con el cual se bajara la información. Por default “sit_vede.txt”

e) Precondición -Tener actualizado la información en todos los módulos correspondientes.

f) Post Condición -Se tiene un archivo portable para interactuar con el sistema de impuestos Internos.

g) Presunción 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

• Codtrans

• Codartc

• Codpro

• Codper

• Fechatrans

• Destino

• Origen

Proveedor

• Codpro

• Nombre

• Representantelegal

• Dirección

• Teléfono

• Correo

Facturación

• Nrofactura

• Codcli

• Fecha

• NIT

• Descripción

• Monto

VentaArticulo

• Codventa

• Codartic

• Codsucur

• Codcli

• Descripción

• Cantidad

• tipventa

• Monto

• Fecha

Personal

• Codper

• Nombre

• Apepat

• Apemat

• Dirección

• Teléfono

• Cargo

Articulo

• Codartic

• Nombre

• Descripción

Sucursal

• Codsucur

• Dirección

• Teléfono

• Encargado

CompraArticulo

• Codcompr

• Codartic

• Fecha

• Codpro

• Cantidad

• Precio

• Monto

Artprecios

• Codartic

• Codpro

• Nfabrica

• Precio

• Fechaingreso

• Cantidad

TipoCliente

• Tipcli

• Teléfono

• Garante

• RepresentanteLeg

Cliente

• Codcli

• Nombre

• tipcli

• Dirección

• NIT

Devoluciones

• Nrofactura

• Codarti

• Codcli

• Cliente

• Fecha

• NIT

• Descripción

• Monto

• Codper

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

Asigna

Oto

rga

Adq

uier

e

Contiene

1

1

1

1*

1

1 1

*

1

1

1

1

1

111*

1

*

1

*

*

1

*

1

1

*

1*

*

1

*1

1

*

*

*

1 1

Tipo Cliente

TipcliTelefonoGaranteRepresentanteLeg

Saldo_sucursalCodsalsurCodartiCodsucurCodproCantidad

ArtpreciosCodarticCodproNfabricaPrecioFechaingresoCantidad

ProveedorCodproNombreRepresentantelegalDireccionTelefonoCorreo

Personal

CodperNombreApepatApematDireccionTelefonoCargo

DevolucionNrofacturaCodartiCodcliClienteFechaNITDescripcionMontoCodper

Articulo

CodarticNombreDescripcion

transferenciaCodtransCodarticCodproCodperFechatransDestinoOrigen

VentaArticuloCodventaCodarticCodsucurCodcliDescripcionCantidadTipventaMontoFechaSucursal

CodsucurDireccionTelefonoEncargado

CompraArticuloCodcomprCodarticFechaCodproCantidadPrecioMonto

FacturacionNrofacturaCodcliFechaNITDescripcionMonto

ClienteCodcliNombreTipcliDireccionNIT

*

*

Prop

orci

ona

Recibe

Adq

uier

e

Dev

uelv

e

Registra

Registra

Ingresa

Registra

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


Diagramas de clase con la agregación y operaciones

Asigna

Oto

rga

Adq

uier

e

Contiene

1

1

1

1*

1

1 1

*

1

1

1

1

1

111*

1

*

1

*

*

1

*1

1

*

1*

*1

*1

1

*

*

*

1 1

Tipo Cliente

TipcliTelefonoGaranteRepresentanteLeg

Saldo_sucursalCodsalsurCodartiCodsucurCodproCantidad

ArtpreciosCodarticCodproNfabricaPrecioFechaingresoCantidad

ProveedorCodproNombreRepresentantelegalDireccionTelefonoCorreo

Personal

CodperNombreApepatApematDireccionTelefonoCargo

DevolucionNrofacturaCodartiCodcliClienteFechaNITDescripcionMontoCodper

Articulo

CodarticNombreDescripcion

transferenciaCodtransCodarticCodproCodperFechatransDestinoOrigen

VentaArticuloCodventaCodarticCodsucurCodcliDescripcionCantidadTipventaMontoFecha

Sucursal

CodsucurDireccionTelefonoEncargado

CompraArticuloCodcomprCodarticFechaCodproCantidadPrecioMonto

FacturacionNrofacturaCodcliFechaNITDescripcionMonto

ClienteCodcliNombreTipcliDireccionNIT

*

*

Prop

orci

ona

Recibe

Adq

uier

e

Dev

uelv

e

Registra

Registra

Ingresa

Registra

Adicion()Eliminacion()Modificacion()




Adicion()Eliminacion()Busqueda()

Adicion()Eliminacion()


Adicion()Busqueda()


Adicion()Eliminacion()

Adicion()Busqueda()

Adicion()Eliminacion() Adicion()

Eliminacion()

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


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.

Inicia el Proceso de

informe

Elaboracion

Pedido de Informe

Venta_compra()

Prog_Estocastico()

Facturacion()

Diagrama de Secuencia, Informes

Gerencia Importaciones SistemaPersonal

Articulos()Compra

Articulos()Venta

Articulos()

Bus_articulo ()

Calculo de Compra()

Regarticulos()

Proceso de Reporte

Reg_Rep()Reg_Rep() Reg_Rep()

Figura 4.5 Diagrama de secuencia: informes.


Facturacion() Facturacion()ProcesoFactura

Elabora

Inicia facturacion

Diagrama de Secuencia, facturacion

Personal SistemaCliente

Ventaarticulo()

Datoscliente()

Articulo()

Regcliente()

Figura 4.6 Diagrama de secuencia: facturación.


Envia nota de remisionRemite nota

IniciaProceso

Inicia ingreso

Diagrama de Secuencia, Ingreso de Mercadería

Importaciones ContabilidadSistema

Reg.Articulo()Termina registro

Actualiza Saldo

Genera nota de ingreso

Figura 4.7 Diagrama de secuencia: Ingreso de Mercadería.


Confirmacion y envio

Elaboracion

Inicio de Pedido

Solicitud Aprobada con modificacion

Solicitud de Aprobacion

Diagrama de Secuencia, Pedido de Artículos Faltantes

Importaciones Sistema ProveedorGerencia

Articulos()

con saldo mínimo

Elabora Lista Pedido

Prediccion de Demanda

Prog.Estocastico()

Imprime NotaPedido

Realiza pedido a proveedor

Figura 4.8 Diagrama de secuencia: Pedido de artículos faltantes.


4.1.8.- Correspondencia del modelo OOA aun modelo relacional

N1

*1 Adquiere

CompraArticulo

CompraArticulo

Personal

Personal Adquiere

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 <Codartc, Codpro, Codper, Fechatrans, Destino, Origen>

Tabla Facturación

in_Facturacion <Nrofactura, Codcli, Fecha, NIT, Descripción, Monto>

Tabla VentaArticulo

in_VentaArticulo <Codventa, Codartic, Codsucur, Codcli, Descripción, Cantidad,

tipventa, Monto, Fecha>

Tabla Proveedor

in_Proveedor <Codpro, Nombre, Representantelegal, Dirección, Teléfono, Correo>

Tabla Personal

in_Personal <Codper, Nombre, Apepat, Apemat, Dirección, Teléfono, Cargo>

Tabla Artículo

in_Articulo <Codartic, Fechaingreso, Descripción, Cantidad>

Tabla Sucursal

in_Sucursal <Codsucur, Dirección, Teléfono, Encargado>

Tabla CompraArticulo

in_CompraArticulo <Codcompr, Codartic, Fecha, Codpro, Cantidad, Preciounitario,

Monto>

Tabla TipoCliente

in_TipoCliente <Tipcli, Teléfono, Garante, RepresentanteLeg>

Tabla Cliente

in_Cliente <Codcli, Nombre, tipcli, Dirección, NIT>

Tabla Artprecios

in_Artprecios <Codartic, Codpro, Nfabrica, precio, Fechaingreso, cantidad >

Tabla Devoluciones

in_Devoluciones <Nrofactura, Codarti, Codcli, Cliente, Fecha, NIT, Descripción,

Monto, Codper>

Tabla Saldo_Sucursal

in_Saldo_Sucursal <Codsalsur, Codarti, Codsucur, Codpro, Cantidad>

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, t-

1, 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.

TRIMESTRES

VEN

TAS

161412108642

300

200

100

0

-100

GRAFICA DE PROMEDIOS MOVIBLES

Ventas Reales

Pronostico de ventas

Pronostico para el trimestre 17 Figura 4.10 Grafica de datos históricos y pronóstico, Bujías


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

TRIMESTRES

VEN

TAS

1413121110987654321

1000

750

500

250

0


Ventas Reales


Pronostico para el trimestre 14 Figura 4.11 Grafica de datos históricos y pronóstico, Retenes




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

TRIMESTRES

VEN

TAS

1413121110987654321

50

40

30

20

10

0

-10

-20


Ventas Reales


Pronostico para el trimestre 14 Figura 4.12 Grafica de datos históricos y pronóstico, Hojas de Corcho




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 G9Comercialización

G1

TransferenciaG2

PersonalG4

Cliente/ProveedorG5

ArtículosG7

Registro TransaccionalG3

Reportes AdministrativosG6

Reporte InventarioG8

G13

G10 G12

G11

U(t)

Datos de Transacciones

Datos de Personal

Datos de Inventario

FacturacionTransferencias

Clientes con creditos

Lista articulos Gral.

Y(t)

Figura 5.1 Modelo del Sistema

G9 = G1+G2 G10 = G4 + G5 G11 = G7 * G8

G13 = G9 * G3 G12 = G10 * G6

Así Gt = G13 + G12 + G11

Por tanto Gt es la ecuación lineal.

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

ser fácilmente utilizado por el usuario.

Esencial 5

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

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

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

PERDIDA DE CLIENTES GENERANDO VENTAS PERDIDAS POR NO TENER LA MERCADERIA

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

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

DESEQUILIBRIO ADMINISTRATIVO Y CONTABLE

GENERACION DE MERCADERIA OBSOLETA POR ACUMULACION

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

INFORMACION NO DISPONIBLE DE LOS CLIENTES MAYORITARIOS.

FALTA DE CONTROL AL SEGUIMIENTO DELMOVIMIENTO DE UNAMERCADERIA

EXECIVO PEDIDO DE MERCADERIA, POR FALTA DE INFORMACION ADECUADA

iNCERTIDUMBRE EN LA TOMA DE DECISIONES .

REDUCCION DE INGRESOS CON PERDIDA DE UTILIDADES

POCA INFORMACION CON LAS FUENTES DE INFORMACION AFIN.

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

ARBOL DE OBJETIVOS

APLICACIÓN ESTOCÁSTICA AL SISTEMA DE INVENTARIO DE

VANGUARD LTDA. PARA LA TOMA DE DECISIONES

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

PEDIDOS DE MERCADERIA OPORTUNOS O A SU DEBIDO TIEMPO

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

MEJORAR EL CONTROL DE LA MERCADERIA EVITANDO PERDIDAS DE LAS MISMAS

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

AUTOMATIZAR LAS TRANSACCIONES COMERCIALES QUE LA EMPRESA

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

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

MANTENER EL ABASTECIMIENTO DE MERCADERÍA EN ALMACENES CON EL STOCK NECESARIO

MAYOR CONTROL AL SEGUIMIENTO DEL MOVIMIENTO DE UNA MERCADERÍA.

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

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

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.

- 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.

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.

1.- Informe emitido por la empresa Vanguard Ltda..en poder del proyectista. 2.-Informe detallado de cada articulo y las transacciones en el archivo de la empresa

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

PRODUCTOS: OBJETIVOS ESPECÍFICOS

* Modulo de control de inventario de la empresa. *Modulo de control de personal de la empresa. *Modulo de seguimiento de Transacciones 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 3.- Prueba de caja negra del Modulo de Transacciones de

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.

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..

- 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. Resultados del Análisis de Factibilidad. Factibilidad técnica Factibilidad económica.

la empresa.

ANEXO B Modelo relacional de APESIV

1

N

1

N

1

N

Registra

1

N

Da

N

1

N

1

1

N

Ingresa

1

1

Otorga

1

N

1

N

1

N

1

1

1

1

1Registra

N

1

1

1

1

1

11

N

N

Registra

Registra Otorga

Registra

Da

Adquiere

Recibe

Contiene

Otorga

Entrega

Adquiere

Proporciona

Saldo_sucursal

TipoCliente Cliente

Facturación

Personal

Devolución

Transferencia

Articulo

VentaArticulo

Artprecios

Sucursal

CompraArticulo

Proveedor

ANEXO C

Tabla 4.1.10.b. Matriz de Datos para promedios móviles.

Pronosticos Error

absoluto

trimestre ventas de ventas Error

absoluto al cuadrado 1 139 2 289 3 82 4 127 170,00 43,00 1849,00 5 162 166,00 4,00 16,00 6 87 123,67 36,67 1344,47 7 38 125,33 87,33 7627,05 8 265 95,67 169,33 28673,66 9 94 130,00 36,00 1296,00

10 154 132,33 21,67 469,46 11 175 171,00 4,00 16,00 12 16 141,00 125,00 15625,00 13 0 115,00 115,00 13225,00 14 78 63,67 14,33 205,43 15 100 31,33 68,67 4715,16 16 60 59,33 0,67 0,44 17 79,33

Totales 725,67 75062,68 F(17) 79,33 MAD 55,82 MSD 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”

Informes Informes

Informes

Artículos

Transferencia Cliente/Proveedor

Personal Comercialización


Control de Personal

Seguimiento De Transacciones

APESIV

Diseño Modular APESIV Fuente: Elaboración propia

Módulo de Transacciones

Devoluciones

Transferencias

Facturación

Impuestos

Devoluciones

Compras

Ventas

Registro de Compras Facturación

Traspasos Registro de Ventas

Informes Transferencias Comercialización

Seguimiento de Transacciones

Módulo de Transacciones Fuente: Elaboración propia

Módulo Control de Personal

Clientes con Crédito

Función del Personal

Registro de Sucursal

Proveedores

Clientes

Sucursal

Personal

Registro de Proveedores

Registro Clientes Registro de Personal

Informes Cliente/Proveedor Personal

Control de Personal

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

Módulo Control de Inventario

Registro Precio Artículos

Articulo Central

Articulo Sucursal

Lista Artículos General Registro de Artículos

Informes Artículos


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

1095

Documents

Transcript of 1095