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)
Requisitos del Proceso de Sistema

Usuario desarrollo de Software
software
Figura 2.1 Proceso de desarrollo de software [Jaco & Rumb & Booc, 1999].
El proceso unificado se repite a lo largo de una serie de ciclos que constituyen la vida
de un sistema (Véase la figura 2.2). Cada versión concluye con una versión del producto para
los clientes.
Nacimiento Muerte
Los ciclos concluyen con una versión
Figura 2.2 El proceso de nacimiento hasta su muerte [Jaco & Rumb & Booc, 1999].
Cada ciclo consta de cuatro fases: inicio (o fase de comienzo), elaboración,
construcción y transición. Cada fase se subdivide a la vez en iteraciones. Como se muestra a
continuación. (Véase la figura 2.3).
Tiempo
Inicio Elaboración Construcción Transición
Iteración Iteración … … … … … … Iteración Iteración
Figura 2.3 Un ciclo con sus fases e iteraciones [Jaco & Rumb & Booc, 1999].
Cada ciclo produce una nueva versión del sistema, y cada versión es un producto
preparado para su entrega.
Cada ciclo se desarrolla a lo largo del tiempo. Este tiempo, a su vez se divide en cuatro
fases, como se muestra en la figura 2.4.
Fases
Flujos de trabajo Inicio Elaboración Construcción Transición
Fundamentales
Requisitos
Análisis
Diseño
Implementación
Prueba
Iter Iter … … … … … … Iter Iter
Iteraciones
Figura 2.4 Los cinco flujos de trabajo [Jaco & Rumb & Booc, 1999].
Lo mas empleado en el proceso unificado es el modelado. La construcción de un
sistema es por tanto un proceso de construcción de modelos. Utilizando distintos modelos para
describir todas las perspectivas diferentes del sistema. La elección de los modelos para un
sistema es una de las decisiones más importantes del equipo de desarrollo.
A continuación se describe brevemente los modelos principales del proceso unificado:
2.1.1.- Modelo de Casos de Uso

Este modelo permite que los desarrolladores de software y los clientes lleguen
a un acuerdo sobre los requisitos que debe cumplir el sistema, este contiene actores,
casos de uso y relaciones.
2.1.2.- Modelo de análisis

Ayuda a refinar los requisitos (casos de uso) con más detalle y nos permite
refinar sobre los aspectos internos del sistema.
2.1.3.- Modelo de diseño

Es un modelo de objetos que describe la realización física de los casos de uso
centrándose en como los requisitos funcionales y no funcionales, tienen impacto en el
sistema a considerar. Además el modelo de diseño sirve de abstracción de la
implementación del sistema y es, de ese modo, utilizado como una entrada
fundamental de las actividades de implementación.
2.1.4.- Modelo de despliegue

Define la arquitectura física del sistema por medio de nodos interconectados.
Estos nodos son elementos hardware sobre los cuales pueden ejecutarse los elementos
software. Con frecuencia conocemos como será la arquitectura física del sistema antes
de comenzar su desarrollo. Por tanto, podemos modelar los nodos y las conexiones del
modelo de despliegues tan pronto como comience el flujo de trabajo de los requisitos.
2.1.5.- Modelo de implementación
Es un modelo que se encarga de representar el sistema en términos de código
fuente y ejecutable, modelo de implementación describe también como se organizan
los componentes de acuerdo con los mecanismos de estructuración y modularización
disponibles en el entorno de implementación y en el lenguaje o lenguajes de
programación utilizados y como dependen los componentes unos de otros.
2.1.6.- Modelo de prueba

Se encarga de las pruebas que se llevan a cabo al sistema una vez
implementado, nos permite poder saber si cumple con los casos de uso y con los
objetivos que fue creado.
2.2.- Fases dentro de un ciclo

Cada ciclo se desarrolla a lo largo del tiempo a su vez se divide en cuatro fases
como se vio en la figura 2.4
2.2.1.- Fase de inicio

El objetivo es desarrollar el análisis de la empresa o negocio hasta el punto
necesario para justificar la puesta en marcha del proyecto. Primero se debe delimitar el
alcance, el ámbito del sistema propuesto. Debemos diferenciar que es lo que va cubrir
el proyecto, que debe cubrir la arquitectura. Delimitar las estimaciones de costo,
tiempo, etc.
2.2.2.- Fase de elaboración

En esta fase se recopila la mayor parte de los requisitos que aun queden
pendientes, formulando los requisitos funcionales como casos de uso.
Se establece también una arquitectura base para guiar el trabajo durante las
fases de construcción y transición. Lo que se pretende comprender es, que es lo que se
va construir y como, además de buscar la tecnología a emplear.
2.2.3.- Fase de construcción
En esta fase se desarrolla un producto de software a partir de una línea base de
arquitectura ejecutable y trabajando a través de una serie de iteraciones e incrementos,
se desarrolla un producto software listo para su operación inicial en el entorno del
usuario a menudo llamado versión beta.
Esta termina con una demostración al usuario y haciendo pruebas del sistema
con el fin de confirmar que se han construido correctamente los casos de uso.
Las pruebas del sistema deben ser continuas hasta que estas funcionen.
2.2.4.- Fase de transición

En esta fase se cumplen con todos los requisitos establecidos en las fases
anteriores, hasta la satisfacción de todos los usuarios. También se gestiona todos los
aspectos relativos a la operación en el entorno del usuario, incluyendo la corrección de
fallas o deficiencias remitidas por los usuarios de la versión beta o por los encargados
de las pruebas de aceptación. Los desarrolladores corrigen los problemas reportados e
incorporan mejoramiento para la nueva versión. La fase de transición involucra
actividades tales como la fabricación, el entrenamiento a los usuarios, provee asistencia
de ayuda en línea y subsana fallas.
2.3.- Lenguaje Unificado de Modelado (U.M.L.)

Este lenguaje es el sucesor de la oleada de métodos de análisis y diseño orientado a
objetos (OOA&D) que surgió a fines de 1980 y principios de1990.[Fowl & Kend, 1999].
Como todo lenguaje este proporciona un vocabulario y las reglas para combinar
palabras de ese vocabulario con el objetivo de posibilitar la comunicación. Un lenguaje de
modelado es un lenguaje cuyo vocabulario y reglas se centran en la representación conceptual
y física de un sistema. Un lenguaje de modelado como UML es por tanto un lenguaje estándar
para la elaboración del software.
El vocabulario y las reglas de un lenguaje como UML indican como crear y leer
modelos bien formados, pero no dicen que modelos se deben crear ni cuando se debería crear.
Esta es la tarea del proceso de desarrollo de software. Un proceso bien definido guiara a sus
usuarios a decidir que producto producir, que actividades y que personal se emplea para
crearlos y gestionarlos, y como usar esos productos para medir y controlar el proyecto de
forma global.
El UML es un lenguaje de modelado para visualizar, especificar, construir y

documentar. En el proyecto actual se han utilizado bloques de construcción, elementos,
relaciones y diagramas.
2.4.- Correspondencia de un modelo orientado a objetos a un modelo relacional

El hacer corresponder una visión del mundo orientado a objetos con una visión
relacional es conceptualmente directo. Como observa Rumbaugh, “la correspondencia entre un
modelo de objetos y un modelo de base de datos relacional es simple, excepto para el manejo
de la generalización”. Rumbaugh continúa ofreciendo algunas reglas para la correspondencia
de clases y asociaciones (incluyendo relaciones de agregación) a tablas: [Booc, 1996].
• Cada clase se corresponde con una o más tablas.

• Cada asociación de mucho a muchos corresponde con una tabla distinta.
• Cada asociación uno a muchos se corresponde con una tabla distinta o puede
insertarse como una clave ajena.
Además sugiere una de las tres alternativas para corresponder las jerarquías de clase,
subclase a tablas.
• La superclase y cada subclase se corresponde con una tabla.

• Los atributos de la superclase se repiten en cada tabla (y cada subclase se
corresponde con una tabla distinta).
• Elevar todos los atributos de las subclases hacia el nivel de la superclase (y
tener una tabla para toda la jerarquía superclase / subclase).
En el presente proyecto se esta haciendo uso de estas reglas de Rumbaugh ya que con
el Proceso Unificado se llego a un modelo O.O. y como es de conocimiento el gestor de base
de datos SQL tiene un manejo del modelo relacional por lo que se necesita utilizar las reglas
de correspondencia para poder llegar a (SGBD) SQL Server que es un sistema administrador
de Bases de Datos Relacional.
2.5.- El modelo de datos relacional

Consiste en una colección de tablas, a cada una de las cuales se asigna un nombre
único. Una fila de una tabla representa una relación entre un conjunto de valores. Puesto que
una tabla es una colección de dichas relaciones, hay una estrecha correspondencia entre el
concepto matemático de relación del cual toma su nombre el modelo de datos relacional.
[Korth, 1993].
2.6.- Sistema de Base de Datos (BD)

Bases de datos es una gran colección de información organizada y enlazada al sistema,
a la que se accede por medio del software. A su vez esta colección de archivos pertenece
lógicamente al mismo sistema. El uso de las bases de datos permite almacenar gran cantidad
de información además de las siguientes ventajas:
• Permite tener un mejor control sobre la información que se almacena.

• Gran velocidad sobre la consulta de información.
• Respaldo de información, dando una mayor seguridad de la misma.
• Flexibilidad en el traslado de la información.
• Manejo de reportes inmediatos, obteniendo el número de copias necesarias en corto
tiempo.
• Eliminar la duplicidad de datos. Se disminuye el manejo de datos erróneos.
2.7.- Sistema de gestión de bases de datos (SGBD)

Un SGBD proporciona la flexibilidad en almacenamiento, recuperación de datos y
producción de información. De todas maneras el uso de un SGBD no elimina la necesidad de
programas de software especializados.
2.8.- Seguridad de base de datos

El método más flexible y extendido de proteger una base de datos se llama seguridad
por usuario. Esta forma de seguridad es similar a los métodos usados en la mayoría de los
sistemas.
2.9.- Inventario
La base de toda empresa comercial es la venta y la compra de bienes o servicios; de
aquí la importancia del inventario por parte de la misma. Este manejo permitirá a la empresa
mantener el control oportunamente, así como también conocer al final del periodo contable un
estado confiable de la situación económica de la empresa.
El inventario constituye las partidas del activo corriente que están listas para la venta,
es decir, toda aquella mercancía que posee una empresa en el almacén valorada al costo de
adquisición, para la venta o actividades productivas.
De los sistemas de inventario que se conocen (Sistema perpetuo y Sistema periódico),

el mas recomendable usar es el Sistema Perpetuo a través de uno de los métodos de
evaluación.
El Sistema de Inventario Perpetuo: con este sistema el negocio mantiene un registro

continuo para cada artículo del inventario. Los registros muestran por lo tanto el inventario
disponible todo el tiempo. Los registros perpetuos son útiles para preparar los estados
financieros mensuales, trimestrales o provisionalmente. El negocio puede determinar el costo
de inventario final y el costo de las mercancías vendidas directamente de las cuentas sin tener
que contabilizar el inventario. El sistema perpetuo ofrece un alto grado de control, por que los
registros de inventario están siempre actualizados. El conocimiento de la cantidad disponible
ayuda a proteger el inventario.
2.9.1.- Control de Inventario
El control interno sobre los inventarios es importante, ya que los inventarios son el
aparato circulatorio de una empresa de comercialización. Las compañías exitosas tienen gran
cuidado de proteger sus inventarios. Los electos de un buen control interno sobre los
inventarios incluyen:
• Conteo físico de los inventarios por lo menos una vez al año, no importando cual
sistema se utilice.
• Mantenimiento eficiente de compras, recepción y procedimientos de embarque.
• Permitir el acceso al inventario solamente al personal que no tiene acceso a los
registros contables.
• Mantener registros de inventarios perpetuos para las mercancías de alto costo unitario.
• Mantener suficiente inventario disponible para prevenir situaciones de déficit, lo cual
conduce a perdidas en ventas.
• No mantener un inventario almacenado demasiado tiempo, evitando con eso el gasto
de tener dinero restringido en artículos innecesarios.
2.10.- Facturación
Es un documento tributario de compra y venta que registra la transacción comercial
obligatoria y aceptada por ley. Este comprobante acredita la venta de mercaderías o la
prestación de servicios. La facturación tiene por finalidad acreditar la transferencia de bienes,
la entrega en uso o la prestación de servicios cuando la operación se realice con sujetos del
Impuesto General a las Ventas que tengan derechos al crédito fiscal. Asimismo cuando el
comprador o usuario lo solicite a fin de sustentar gastos y costos para efecto tributario y en el
caso de operaciones de exportación.
2.10.- Procesos estocásticos.

La teoría de los procesos estocásticos se lo define generalmente como la parte
dinámica de la teoría de las probabilidades en la que se estudia un conjunto de variables
aleatorias (llamado un proceso estocástico) desde el punto de vista de su interdependencia y su
comportamiento limite. Se observa un proceso estocástico siempre que se examina un proceso
que se desarrolla en el tiempo de manera controlada por leyes probabilísticas.
Por tanto definimos un proceso estocástico como una familia de variables aleatorias:
{z (t,w), t T yw S}
Donde T se denomina conjunto índice y S es el espacio muestral asociado a un experimento
aleatorio. T generalmente representa el tiempo, pero puede tener distintas naturalezas.
[Parz,1972 ]
Figura 2.5 Representación del proceso estocástico [Marq, 1994]

Por la naturaleza del tiempo y del espacio, los procesos estocásticos pueden ser:
1 Procesos estocásticos discretos en el tiempo y en el espacio
2 Procesos estocásticos discretos en el tiempo y continuos en el espacio
3 Procesos estocásticos continuos en el tiempo y discretos en el espacio.
4 Procesos estocásticos continuos en el tiempo y en el espacio.
En el transcurso del desarrollo del proyecto, nos limitaremos al uso del caso numero 1.
Dentro de los procesos estocásticos se hallan los Procesos Normales, Procesos de 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 Ft+1 Ft+2 Ft+3………Ft+m

Periodo i 1 2 3……t-2 t-1 t
t+1 t+2 t+3 ……….t+m
Valores estimados F1 F2 F3……Ft-2 Ft-1 Ft
Valores de Error e1 e2 e3 ……et-2 et-1 et
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 Gerencia Departamento de

Administrativa Comercial Importaciones
Contabilidad Creditos Encargado de Jefe de Ventas

Sucursal
Caja Vendedor 1 Vendedor 2 Vendedor A Vendedor B
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
Inicio
Solicita Revisar
Producto Documento
No
SI Factura
Existe Producto
Producto
Artic.
Producto
Factura
Fin
Figura 3.2.1.a Venta al contado

Fuente: Elaboración propia
Procedimiento: Traspasos entre Almacenes
Almacén destino Y Encargado de Encargado de ventas Almacén X

ventas sucursal Y sucursal X
Inicio
Hacer Pedido Revisar

documento
Si
No Confirmar Enviar los
Existen. Productos
Recepcion nota
Ingresar los de traspaso
Productos
Emitir nota de
Actualizar traspaso
Kardex
Actualizar kardex
Emitir nota de
Ingreso
Fin
Figura 3.2.1.b Traspasos entre almacenes

Procedimiento: Pedido de Mercadería
Encargado de Gerencia Comercial Contabilidad Gerencia General

Importaciones
Inicio
Solicita movimiento
de mercadería de Imprime solicitud
de movimiento de Verifica Solicitud
artículos con poco
stock ventas
Analiza
Documentación si Autoriza
Existen Solicitud de
Recurso compra
Verifica Solicitud
Elabora Solicitud
de compra No
Si
necesario
por
demenda?
No
Inicia compra del
proveedor
Fin
Figura 3.2.1.c Pedido de Mercadería

Procedimiento: Ventas al Crédito
Cliente Vendedor Encargado de Créditos Almacén Caja
Revisa Docum
Inicio del cliente
Solicitud de Revisa Si
credito Documento reg. clie
No
Producto Factura Producto

No Si Reg. Cliente y
Confirma evaluación de
Exist.Art monto
Producto
No Si
Factura Aceptar
Credito?
Fin
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
TIEMPO COSTO COSTO COSTO

Nº TOTAL Por Aprox. TOTAL
DESCRIPCION de Horas/ Hora Por día ($US)
Per. Hombre ($US) ($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
Nivel Básico Intermedio

Modo ai bi ai bi
Orgánico 2.4 1.05 3.2 1.05
Semiencajado 3.0 1.12 3.0 1.12
Empotrado 3.6 1.2 2.8 1.2
Como se puede observar (Tabla 3.3.3), se tiene la matriz de coeficientes COCOMO,

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

meses.
El exponente 0.28 puede variar hasta 0.91 bajo el supuesto que una persona haga el
trabajo de dos, entonces tenemos lo siguiente:
td * 2 = 3 meses * 2 = 6 meses.
El cual es el tiempo requerido para el desarrollo del software del sistema.
3.3.4.- Factibilidad Técnica

En la empresa adquirirá una computadora, que cuente con los requerimientos
necesarios para el funcionamiento del sistema, o se adecuara uno que ya existe, por lo que
no surgirán problemas mayores en la instalación del sistema informático.
La empresa desea cambios en su campo, es decir contar con una tecnología que le
permita mejorar la atención al público (clientes), que interactúan con el sistema, por tanto la
empresa está en total aceptación de la utilización del equipo computacional y el sistema que
se desarrolla. El equipo computacional será descrito mas adelante. (Tabla 3.3.4)
3.3.5.- Factibilidad Operacional

En la institución existe el personal capacitado para realizar tareas técnicas de
computación, por lo que no existirán mayores problemas al respecto. Sin embargo es
necesario enseñar el manejo de la información a los encargados del área al cual va dirigido
el sistema (departamento de importaciones y ventas), Esta capacitación se realizara
oportunamente.
Tabla 3.3.4 Equipo Computacional
CANT. 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
Transacciones Cliente
Importaciones
Impuestos
Proveedor
Control de Personal
Personal
Gerencia
Control de Inventario
Sucursal
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.
d) Flujo Principal Eventos Actor Eventos de Sistema
1. Ingreso al modulo de asignaciones 1. Presenta la opción de listado
de artículos, como de llevan acabo las de asignaciones, la venta de
ventas de los distintos artículos. artículos por fechas.
2. Reporte de importaciones de 2. Se abre el modulo de
artículos. compras de artículos.
3. Solicitud de impresión de informes 3. Opción de poder imprimir los
de lo pedido. informes deseados.
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
Artículos
Registro de
Personal
Usa
Usa
Usa
Registro de
Informes Factura
Usa
Usa
Gerencia
Registro de
Import acion
Registro de
Ventas
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.
1. Revisa los artículos cuya 1. Ingresa a registro de productos para
existencia en saldo sea el verificar la existencia.
mínimo.
2.Detalle de los artículos 2. Lista de los artículos e impresión
faltantes de ellos en base a la frecuencia de
venta de estos, en formato pedido.
3.El usuario escoge terminar 3. Cierre u opción salir del modulo.
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
Verifica y selecciona
existencia de articulos
Listado de artículos con Gerencia

existencia minima
Calculo de pronostico de
Importaciones
demanda
Informe de pedido de
mercadería 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.
1. El agente de ventas pregunta 1. Si es en efectivo continua la
al cliente la modalidad de venta atención, si es crédito solicita el
(crédito o efectivo). código del cliente y devuelve
información de calificación.
2. De acuerdo a la calificación, 2. Pide el código de vendedor, y
el agente de ventas termina el pasa a detalle pidiendo el código del
proceso o atiende solicitud del producto o su número de fábrica,
cliente. devolviendo información del precio
y existencia.
3. Con la conformidad del 3. Solicita información del cliente e
cliente, el agente de ventas imprime la factura, registrando toda
decide emitir factura. 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
Toma los datos del

cliente para registrarlo
Registra el codigo del

vendedor
Registra los datos de los

Agente de articulos vendidos Cliente
Venta
Emite Factura
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.
1. El almacén origen ingresa al 1. El sistema le solicita escoger el
modulo de asignación de artículos. almacén destino.
2. Almacén origen determina 2. Pide ingresar el código del
artículos y cantidades a enviar. artículo y la cantidad.
3. Solicita imprimir la nota de 3. Muestra la opción de imprimir la
envió para enviarlo una copia junto nota, actualizando los saldos de los
con la mercadería al almacén artículos que salen y registrando el
destino. movimiento.
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.
Caso de Uso: Asignación de

Artículos a sucursal
Verifica existencia de saldo

de artículos solicitado
Determina artículos y
cantidades a enviar
Registra el código del

despachante
Registra los datos de los

Encargado Almacen
articulos a enviar
De Sucursal solicitante
Emite una nota de

traspaso
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.
1. El encargado de importaciones 1. El sistema emite un listado de
busca artículos faltantes. los artículos faltantes.
2. Realiza una selección y 2. Emite un listado de los
clasificación de artículos de artículos requeridos
requerimiento inmediato. determinando el costo estimado.
3. Envía la orden de compra a 3. Registra los datos de la orden
gerencia para su aprobación. de compra.
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 Faltantes

a nivel local
Verifica y selecciona
existencia de articulos
Elabora un listado de
articulos mas relevantes Gerencia
con existencia minima
Realiza el calculo de
pronostico de demanda
Importaciones
para determinar
cantidades
Genera un listado informe

de pedido de mercaderia
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.
1. El encargado de almacén entra al 1. Da la opción de escoger
modulo de inventario. por rango en forma continua,
o en forma aleatoria.
2. Escoge una de las opciones 2. Pide ingresar el ítem
mostradas por el sistema. inicial y el ítem final y
muestra una lista con la
descripción y saldos. Genera
un informe.
3. Compara con la existencia física y 3. Finaliza proceso.
elabora un informe para remitir a
gerencia.
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
Solicita informe de
inventario por grupo y
aleatorio
Elabora un listado de
articululos y saldos
Compara con la
Encargado de existencia física Gerencia
Almacen
Emite informe de
Inventario
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.
1. Importaciones verifica el estado 1. El sistema solicita introducir
de la mercadería y de acuerdo a el factor para hacer el cálculo de
ello determina ingresar los precios y costo. Emite un
productos a almacén. informe.
2. Luego de haber hecho el costeo, 2. Termina el proceso de costeo.
remite informe a contabilidad.
3. Entra a opción de ingreso de 3. Muestra la opción de
mercadería y escoge el almacén. 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
Realiza el costeo para

determinar precio y costo
Registra el ingreso de la
mercadería a almacén
Elabora nota de remision Contabilidad

Importaciones
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.
1. Contabilidad ingresa a facturación. 1. El sistema solicita la clave
de acceso.
2. Escoge la opción Impuestos 2. Pide ingresar el periodo
Internos. del cual se requiere el
informe de ventas. Muestra
un listado de facturas con el
número correlativo.
3. Verifica los datos, genera un 3. Pide el nombre del archivo
archivo para importarlo al sistema de con el cual se bajara la
impuestos. información. Por default
“sit_vede.txt”
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 Proveedor
• Codtrans • Codpro
• Codartc • Nombre
• Codpro • Representantelegal
• Codper • Dirección
• Fechatrans • Teléfono
• Destino • Correo
• Origen
Facturación Personal
• Nrofactura • Codper
• Codcli • Nombre
• Fecha • Apepat
• NIT • Apemat
• Descripción • Dirección
• Monto • Teléfono
VentaArticulo • Cargo
• Codventa Articulo
• Codartic • Codartic
• Codsucur • Nombre
• Codcli • Descripción
• Descripción Sucursal
• Cantidad • Codsucur
• tipventa • Dirección
• Monto • Teléfono
• Fecha • Encargado
CompraArticulo
• Codcompr Artprecios
• Codartic • Codartic
• Fecha • Codpro
• Codpro • Nfabrica
• Cantidad • Precio
• Precio • Fechaingreso
• Monto • Cantidad
TipoCliente Devoluciones
• Tipcli • Nrofactura
• Teléfono • Codarti
• Garante • Codcli
• RepresentanteLeg • Cliente
Cliente • Fecha
• Codcli • NIT
• Nombre • Descripción
• tipcli • Monto
• Dirección • Codper
• NIT Saldo_Sucursal
• Codsalsur
• Codarti
• Codsucur
• Codpro
• Cantidad
4.1.5.- Diagramas de Clase (Modelado estructural).- Los diagramas de clases se utilizan

para modelar la vista de diseño estática de un sistema.
En primera instancia con la captura de conceptos, posteriormente los diagramas de

clase con la agregación de asociación figura 4.3 y por ultimo los diagrama de Clases con
Agregación de Atributos y operaciones figura 4.4.
Diagramas de clase con la agregación de asociación
Tipo Cliente Cliente

Codcli
Tipcli 1 Contiene 1 Nombre 1
Telefono
Tipcli
Garante
Direccion
Proveedor RepresentanteLeg
Codpro 1 NIT
1
Nombre
Representantelegal
Direccion Recibe
Telefono
Correo
*
Saldo_sucursal Artprecios 1
Devuelve
Codsalsur Facturacion
1 1 Codartic
Adquiere
Codarti Codpro Nrofactura
Proporciona
Codsucur Nfabrica Codcli

Codpro Precio 1 Fecha
Cantidad Fechaingreso NIT
1 Cantidad Descripcion
* Monto
* * 1
CompraArticulo
Codcompr 1
Codartic Articulo Devolucion
Fecha * 1
1 Nrofactura 1
Codpro VentaArticulo
* * Codartic Codarti
Cantidad Codventa
Nombre Codcli
Precio Codartic
Monto
Descripcion * 1 Cliente 1 1 Codsucur
Fecha
* Codcli
1 Ingresa NIT
Descripcion Descripcion
Monto Cantidad
Tipventa
Otorga
* Codper
Monto
Sucursal transferencia *
Registra Fecha
* Codtrans
Codsucur 1 *
Codartic
Direccion Personal
Telefono 1 * Codpro
Codper 1
Encargado * 1 Codper
Fechatrans Registra Nombre
Destino
Adquiere
1 Apepat Registra
Origen Apemat
Asigna * Direccion 1
Telefono
Cargo
1
Figura 4.3 Diagramas de clase con la agregación de asociación

Diagramas de clase con la agregación y operaciones
Cliente
Codcli
Nombre
Tipo Cliente Tipcli
Proveedor Direccion
Codpro Tipcli 1 Contiene 1 NIT 1
Nombre Telefono
Adicion()
Representantelegal Garante
Eliminacion()
Direccion RepresentanteLeg
Modificacion()
Telefono 1
Adicion() 1
Correo
Eliminacion()
Adicion() Modificacion() Recibe
Eliminacion()
Modificacion() 1
Saldo_sucursal Artprecios
Facturacion
* Codsalsur Codartic
Codarti Nrofactura
1 1 Codpro Codcli
Devuelve
Codsucur
Proporciona
Nfabrica
Codpro Fecha
Precio
Adquiere
Cantidad NIT
Fechaingreso
Descripcion
Adicion() Cantidad 1 Monto
Eliminacion() Adicion()
* Adicion()
Eliminacion() Eliminacion()
CompraArticulo 1 *
Codcompr 1 * 1
Codartic Articulo
Devolucion
Fecha
Codartic Nrofactura
Codpro
Nombre Codarti
Cantidad * 1
Descripcion 1 Codcli
Precio 1
Cliente VentaArticulo
Monto * *
Adicion() Fecha Codventa
Adicion() NIT
Eliminacion() Codartic
Busqueda() * 1 Descripcion 1 1 Codsucur
Modificacion()
* Monto Codcli
1 Ingresa Codper
* Descripcion
Sucursal Adicion() Cantidad
transferencia
Tipventa
Otorga
Busqueda()
Codsucur Codtrans Monto
Direccion Codartic *
Registra Fecha
Telefono * Codpro
Encargado Codper 1 Adicion()
Fechatrans Personal Eliminacion()
Adicion() 1 * 1
Destino Busqueda()
Eliminacion() * 1 Codper
Origen Registra Nombre
Modificacion() *
Adicion()
Adquiere
Apepat Registra
Eliminacion() Apemat
1 Asigna * Direccion 1
Telefono
Cargo
1
Adicion()
Eliminacion()
Modificacion()
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.
Diagrama de Secuencia, Informes
Gerencia Importaciones Personal Sistema
Articulos()
Compra
Pedido de
Articulos()
Informe Venta
Articulos()
Regarticulos()
Elaboracion Calculo de
Compra()
Bus_articulo ()
Inicia el Facturacion()
Proceso de Prog_Estocastico()
informe
Venta_compra()
Proceso de Reg_Rep() Reg_Rep() Reg_Rep()

Reporte
Figura 4.5 Diagrama de secuencia: informes.

Diagrama de Secuencia, facturacion
Personal Cliente Sistema
Ventaarticulo()
Inicia
facturacion Datoscliente()
Articulo()
Elabora
Regcliente()
Proceso Facturacion() Facturacion()

Factura
Figura 4.6 Diagrama de secuencia: facturación.

Diagrama de Secuencia, Ingreso de Mercadería
Importaciones Sistema Contabilidad
Reg.Articulo()
Inicia
Termina registro
ingreso
Actualiza
Saldo
Inicia Genera nota de
Proceso ingreso
Envia nota de remision

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

Diagrama de Secuencia, Pedido de Artículos Faltantes
Importaciones Sistema Gerencia Proveedor
Articulos()
Inicio de
Pedido con saldo mínimo
Prog.Estocastico ()
Prediccion de
Elaboracion Demanda
Elabora
Lista Pedido
Imprime
NotaPedido
Solicitud de Aprobacion
Confirmacion Solicitud Aprobada con modificacion

y envio
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
1 Adquiere *
Personal CompraArticulo
1 N
Adquiere CompraArticulo
Personal
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.
GRAFICA DE PROMEDIOS MOVIBLES
300
200
VENTAS
100
-100
2 4 6 8 10 12 14 16
TRIMESTRES
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
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

1000
750
500
VENTAS
250
1 2 3 4 5 6 7 8 9 10 11 12 13 14
TRIMESTRES
Ventas Reales
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
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

50
40
30
20
VENTAS
10
-10
-20
1 2 3 4 5 6 7 8 9 10 11 12 13 14
TRIMESTRES
Ventas Reales
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:
G13
G11 G9
Comercialización
G1
Registro Transaccional
G3
Transferencia
Datos de
G2
Transacciones
Facturacion
Transferencias
U(t) G10 G12
Personal Y(t)
G4
Datos de Reportes Administrativos
Personal G6
Cliente/Proveedor
Clientes con
G5
Datos de creditos
Inventario Lista articulos
Gral.
G11
Artículos Reporte Inventario
G7 G8
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 Esencial 5
ser fácilmente utilizado por el usuario.
Con los valores de ponderación de la tabla 5.4.6 tenemos los valores de ajuste de
complejidad, que determina los de ∑Fi = 37.
El valor 315 es la sumatoria de los resultados parciales que son los productos de las cuentas
por el peso asignado (Simple, medio y complejo), y para realizar el análisis utilizamos el peso
medio.
Luego remplazamos los datos en la relación de Punto de Función y se obtiene el
siguiente resultado:
PF = 315 * [0.81 + (0.01 * 37)] = 371.7 ≈ 372
El Punto de Función obtenido supone 372 líneas de código referentes al tamaño del
sistema.
Haciendo un análisis con la escala de Punto de Función Tabla 5.4.7 se concluye que el
sistema tiene la funcionalidad óptima.
Tabla 5.4.7 Escala de Punto de Función

Escala Observación
PF > 300 Optima
200 > PF > 300 Buena
100 > PF > 200 Suficiente
PF < 100 Deficiente
Calculando el ajuste tenemos:

El valor promedio de Fi(promedio calculado) = 37
Valor máximo de Fi(máximo) = 55
La cuenta total del factor de ponderaciones 315
Remplazando estos valores en la ecuación
PF(máximo) = 315 * [0.81 + (0.01 * 55)] = 428
Sacando el promedio de estos dos resultados tenemos:
Prom = 372 / 428 = 0.87
Entonces
Funcionalidad = 0.87 * 100 = 87%
Por lo tanto se tiene un 87% de Funcionalidad.
5.5.- Confiabilidad
Según teorema la confiabilidad esta dado bajo los componentes del modelo del sistema
donde a cada módulo se le denomina Ri(t)
La confiabilidad esta dada por: R(t)
La confiabilidad de los componentes: R1(t),R2(t),……………..,Rn(t)
Donde: R(t) = P ( T > t)
Donde T es el tiempo para fallar el sistema.
Si tres módulos funcionan independientemente están conectados en serie y la i – esima
componente tiene la confiabilidad.
Confiabilidad del sistema completo:
R(t) = R1(t) * R2(t) * R3(t) → R(t) = Min (R1(t),R2(t),R3(t))
R(t) = exp –w1t * exp –w2t * exp –w3t = e –(w1+w2+w3)t
La función de densidad de probabilidad de tiempo esta dado por:
F(t) = (w1 + w2 + w3)e –(w1 + w2 + w3)t Función de distribución
Donde w es un parámetro de medición
W = 0.01
La confiabilidad del sistema esta dado por:
R(T) = e -0.01t
Para un funcionamiento de 10 horas o después de 10 horas la probabilidad de que el
sistema no falle esta dado por:
e -0.01(10) = e -0.1 = 0.905
Entonces se tiene un 90% de probabilidad de que el sistema no falle.
5.6.- Prueba de Software

Una estrategia de prueba de software integra las técnicas de casos de prueba en una serie
de pasos que dan como resultado una correcta construcción del software.
o Prueba de unidad. Esta prueba se realizo a cada uno de los módulos, ya que permite
que cada módulo este libre de errores.
o Prueba de integración. Una vez que sea integrado todos sus componentes se realizo la
verificación para que el sistema funcione sin ningún problema.
o Prueba de validación. Esta prueba es muy importante ya que se realizo la validación
para verificar si el sistema satisface los requerimientos del usuario.
o Prueba del sistema. Esta prueba del sistema se realizo en el lugar de actual
funcionamiento.
5.7.- La mantenibilidad
Se centra en el cambio que va asociado a la corrección de errores, adaptaciones y a los
cambios debido a las mejoras por los requisitos cambiantes del cliente.
Corrección. Incluso cuando el sistema tiene garantías de calidad, es probable que se
descubra defectos en el software. Por lo tanto el mantenimiento correctivo modifica el
software para corregir los errores.
Adaptación. Una vez instalado el software no dura de forma permanente ya que puede
que cambie su entorno original, entonces es necesario realizar el mantenimiento adaptativo
para que el software se pueda adecuar a los cambios de su entorno externo.
Mejora. A medida que se va utilizando el software, se va descubriendo los beneficios
que producen.
5.8- Seguridad del sistema

La institución debe estar organizada de tal modo que facilite y favorezca la gestión de
la seguridad informática. Y esto debe cumplirse con absoluto hermetismo.
Es vital contar con personal sobre el que se pueda depositar confianza.
5.9.- Aspectos preventivos

Este apartado aborda los aspectos asociados al componente lógico del sistema: programas
y datos. Para ello, se distingue entre las medidas para restringir y controlar el acceso y empleo
de dichos recursos, los procedimientos para asegurar la fiabilidad del software (tanto operativo
como de gestión) y los criterios a considerar para garantizar la integridad de la información.
• Control de acceso: Sistema de identificación, como el equipo esta designado

particularmente para el empleo de los vendedores este equipo tiene un código de
acceso desde el momento del inicio y para poder ingresar al sistema solo se lo puede
realizar ingresando la clave de acceso que solo lo saben la Gerencia e importaciones.
• Software de base: Control de cambios y versiones, control de uso de programas de
utilidad.
6.- CONCLUSIONES Y RECOMENDACIONES
6.1 Conclusiones.
Se ha logrado cumplir con los objetivos planteados durante la primera fase de

desarrollo del sistema.
• El Desarrollo y construcción del sistema de inventarios con la aplicación

de los procesos estocástico para la empresa Vanguard Ltda. ha
concluido satisfactoriamente, cumpliendo con los requerimientos de la
empresa.
• Se logro dar mayor seguridad a la toma de decisiones con la aplicación

de los procesos estocásticos, reduciendo de sobremanera la
incertidumbre y haciendo mas oportuna el pedido de artículos faltantes
en la empresa.
• Se logro tener un mejor control y seguimiento de los artículos en la

empresa, evitando la perdida de los mismos.
• Existe una mayor rapidez en la emisión de los informes por que todos
los datos que se emplean para la misma están debidamente registrados
en la base de datos.
• Los formatos de entrada y salida fueron diseñados de manera que

guardan similitud con los formularios que se manipulan, de forma que
se tiene una coincidencia en los campos a llenar.
6.2 Recomendaciones.
• Expandir el proyecto anexando a un modulo de contabilidad para tener un

mejor control de costos y beneficios de la empresa.
• Mejorar el modelo del proceso estocástico con otro modelo de más precisión,
ya que a futuro se tendrá más datos históricos.
• Dado que las características de comercializar un producto de un rubro a otro

son muy similares, el software con algunas modificaciones puede ser genérico.
• Por la tendencia del comercio electrónico, seria bueno ir en esa dirección para
incrementar las ventas de los productos desarrollando un portal Web dedicado a
ello.
7.- REFERENCIA BIBLIOGRAFICA
[Booc, 1996] Booch, G., 1996: Análisis y Diseño Orientado a Objetos con Aplicaciones, 2da.
Edición, 638 pp., Addison Wesley/ Díaz De Santos, México.
[Fowl & Kend, 1999] Fowler, M. & Kendall, S., 1999: UML Gota a Gota 1ra. Edición, 1pp ,
Addison Wesley, Mexico.
[Jaco & Rumb & Booc, 1999] Jacobson, I. & Rumbaugh, J. & Booch, G., 1999: The Unified
Modeling Languaje User Guide, 1ra. Edición, 482 pp,
Addison-Wesley, United Stated of America.
[Jaco & Rumb & Booc, 1999] Jacobson, I. & Rumbaugh, J. & Booch, G., 1999: The Unified
Software Development Process, 1ra. Edición, 512 pp,
Addison-Wesley, United Stated of America.
[Korth, 1993] Korth, H., 1993: Fundamentos de Bases de Datos, 2da. Edicion, 739 pp,
MacGraw Hill, México.
[Murr, 1990] Murria R. Spiegel, 1990: Estadística, McGraw-Hill.Mexico
[Senn, 1994] Senn Jmes: “Analisis y Diseño de Sistemas de Informacion”

Georgia State Universiti. Mexico Mc.Graw Hill 2da. Edición 1994
[Par,1971] Emmanuel Parzen: “Procesos Estocásticos”

Paraninfo, Magallanes Madrid . M.1971
[Cast,2000] Maria Nilsa, Castro Huanca “Sistemas de control de Inventario Proactivo King
Tropical & Marine Ltda.” Proyecto de Grado 2000
[Cam, 2001] Tirso Campos Santillan: “Problemario de Pronósticos para la toma

de decisiones” Thomson 2001.
[Marq, 1994] Raul Marquiegui Navarro: “Procesos Estocásticos”

Tomo I, F.C.P.N. Carrera de Estadistica 1994.
ANEXO A
ARBOL DE PROBLEMAS
GENERACION DE DESEQUILIBRIO REDUCCION DE

MERCADERIA OBSOLETA ADMINISTRATIVO Y INGRESOS CON
POR ACUMULACION CONTABLE PERDIDA DE UTILIDADES
DESCONFIANZA HACIA DESINFORMACION EN LA VENTA DE ARTICULOS

EL PERSONAL DE UNIDAD DE POR DEBAJO DEL PERDIDA DE CLIENTES
ALMACENES Y VENTAS IMPORTACIONES PARA PRECIO DE COSTO POR GENERANDO VENTAS
POR EL NIVEL HACER LOS PEDIDOS LOS DESCUENTOS PERDIDAS POR NO
EJECUTIVO NECESARIOS. ALTOS TENER LA MERCADERIA
NO EXISTE UN SISTEMA DE
INVENTARIOS NI POLITICAS CON
APOYO CIENTIFICO PARA LA
TOMA DE DECISIONES PARA
HACER LOS PEDIDOS
NECESARIOS MANTENIENDO UN
EQUILIBRIO.
EXECIVO PEDIDO DE FALTA DE POLITICAS DE FALTA DE CONTROL AL

RETRASOS EN LOS
PEDIDOS DE MERCADERIA, POR FALTA DESCUENTOS PARA LA SEGUIMIENTO DEL
DE INFORMACION VENTA DE LOS MOVIMIENTO DE UNA
MERCADERIA POR EL
ADECUADA DIFERENTES ARTICULOS MERCADERIA
VOLUMEN DE
INFORMACION DE LOS
ARTICULOS.
iNCERTIDUMBRE EN LA INFORMACION NO
POCA INFORMACION CON DISPONIBLE DE LOS
LAS FUENTES DE TOMA DE DECISIONES .
CLIENTES
INFORMACION AFIN. MAYORITARIOS.
ARBOL DE OBJETIVOS
APLICACIÓN ESTOCÁSTICA AL
SISTEMA DE INVENTARIO DE
VANGUARD LTDA. PARA LA TOMA
DE DECISIONES
AUTOMATIZAR LAS REALIZAR UN MODULO PARA AUTOMATIZAR LA

TRANSACCIONES EL CONTROL DE PERSONAL REALIZACION DEL INVENTARIO
COMERCIALES QUE LA DE LA EMPRESA Y LOS DE LOS ARTICULOS CON LOS
EMPRESA PROVEEDORES Y CLIENTES CUALES SE COMERCIALIZA EN
CON LOS QUE CUENTA LA EMPRESA
REGISTRAR AL
PERSONAL EN CADA I FORMACIÓN MANTENER EL MEJORAR EL
VENTA DE ARTÍCULOS A PEDIDOS DE TRANSACCIÓN DE DISPONIBLE DE LOS ABASTECIMIENTO DE CONTROL DE LA
SU PRECIO JUSTO MERCADERIA MERCADERÍA GANANDO CLIENTES QUE TIENEN MERCADERÍA EN MERCADERIA
EVITANDO DESCUENTOS OPORTUNOS O A SU LA CONFIANZA DEL NIVEL CRÉDITO. ALMACENES CON EL EVITANDO PERDIDAS
ALTOS DEBIDO TIEMPO EJECUTIVO STOCK NECESARIO DE LAS MISMAS
AUMENTO DE CLIENTES IMPORTAR LAS

EVITANDO VENTAS CANTIDADES ADECUADAS
MAYOR CONTROL AL PERDIDAS POR TENER LA DE MERCADERÍA, PARA EL
SEGUIMIENTO DEL MERCADERÍA NECESARIA ABASTECIMIENTO DE LOS
MOVIMIENTO DE UNA ALMACENES
MERCADERÍA.
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 - La aplicación de los procesos Estocásticos , apoyando a la toma - Existen varias empresas, instituciones, Predisposición de la empresa y de las unidades
involucradas, incrementando las utilidades y satisfaciendo de decisiones con el sistema de inventarios dando mayor organizaciones que se dedican a la involucradas y la información de fuentes externas
con mas cobertura la demanda del mercado automotriz. seguridad en la toma de decisiones haciendo mas certero lo comercialización de diferentes artículos que como el Organismo Operativo de Transito y otros
impredecible. pueden hacer uso de lo que se pretende realizar. afines al proyecto.
PROPÓSITO (OBJETIVO GENERAL)

1.- Informe emitido por la empresa 1.-Se utiliza la información adecuada.
1.- Se reduce la incertidumbre en 90% para brindar Vanguard Ltda..en poder del proyectista.
Diseñar e implementar una aplicación estocástica al información del adecuada para la adquisición de 2.- No existe interrupción en la dotación de
Sistema de inventario de Vanguard Ltda.. para la artículos. energía eléctrica.
toma de desiciones 2.- La emisión de informes mas creíbles y concretos de las 2.-Informe detallado de cada articulo y las
transacciones en el archivo de la empresa 3.- Soporte de actualización y mantenimiento
operaciones de la empresa ante fallas.
3.- Se reduce el tiempo en 90% de realización de
información de saldos de artículos en las sucursales.
PRODUCTOS: OBJETIVOS ESPECÍFICOS

1.- listado de resultados de la prueba del 1.- Datos correctos en la base de
* Modulo de control de inventario de la empresa. 1.- Prueba de caja negra del módulo de Control de módulo de control de inventario datos del inventario.
Inventario almacenado en el archivo de la empresa 2.- Datos correctos en la base de
*Modulo de control de personal de la empresa. 2.- Prueba de caja negra del modulo control de personal 2.- Documentación del sistema datos del personal.
conteniendo los resultados de la prueba del 3.- Datos correctos de las transacciones
*Modulo de seguimiento de Transacciones de la 3.- Prueba de caja negra del Modulo de Transacciones de módulo de Control de personal de la empresa.
empresa la empresa. 3.- Listado de resultados de la prueba de 4.- No existen modificaciones en
caja negra del modulo de Transacciones. los formularios.
INSUMOS (ACTIVIDADES)
1. Análisis de problemas y objetivos. 1. 50 hrs/hombre - Registro de documentos El personal de las diferentes unidades involucradas
2. Desarrollar y estructurar el perfil del Proyecto de Grado. 2. 200 hrs/hombre - Documentos de proyectos realizados. proporciona información necesaria para el desarrollo
3. Estudio y análisis de los Procesos Estocásticos. 3. 40 hrs/hombre - Registro de perfiles corregidos. del sistema.
4. Estudio y análisis de los Sistemas de Inventarios 4. 40 hrs/hombre - Material Bibliográfico respecto al tema.
(Investigación de Operaciones) 5. 200 hrs/hombre - Registro de los autores del proyecto y asesores. Resultados del Análisis de Factibilidad.
5. Diseño lógico del Sistema de Inventarios para su 6. 200 hrs/hombre -Registros en medios magnéticos.
automatización. 7. 30 hrs/hombre - Cuestionario a los usuarios directos que operan Factibilidad técnica
6. Desarrollo de Software del Sistema de Inventarios. 8. 10 hrs/hombre el sistema. Factibilidad económica.
7. Pruebas del Sistema de Inventarios con datos históricos. 9. 40 hrs/hombre - Registros de pruebas a los usuarios directos.
8. Implementación del Sistema de Inventarios. La ejecución de las actividades requiere los siguientes suministros:
9. Documentación del Sistema (manuales, diccionario de
datos, etc.). - Material de escritorio
- Material de impresión
- Fotocopias
- Textos, otros..
ANEXO B
Modelo relacional de APESIV
1 1 1
Cliente
TipoCliente Contiene
Proveedor
1 1
N 1
Saldo_sucursal Recibe
Adquiere
Proporciona 1 1
1
Otorga Registra Facturación
N
1
CompraArticulo 1 1 N
Artprecios Devolución 1 Da
N
N 1 N 1 N 1
Entrega
Registra VentaArticulo
Otorga
Ingresa
N
Adquiere
1 N
Registra Otorga
Articulo
Registra
Sucursal
1 N
1 N
Da Transferencia Registra
N 1 1
1
Personal
N 1
1
ANEXO C
Tabla 4.1.10.b. Matriz de Datos para promedios móviles.
Error
Pronosticos absoluto
Error
trimestre ventas de ventas 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”
APESIV
Seguimiento Control de Control de

De Transacciones Personal Inventario
Comercialización Personal Artículos
Transferencia Cliente/Proveedor Informes
Informes Informes
Diseño Modular APESIV

Módulo de Transacciones
Seguimiento de
Transacciones
Comercialización Transferencias Informes
Registro de Ventas Traspasos Ventas
Registro de Compras Facturación Compras
Devoluciones Devoluciones
Impuestos
Facturación
Transferencias
Módulo de Transacciones
Módulo Control de Personal
Control de Personal
Personal Cliente/Proveedor Informes
Registro de Personal Registro Clientes Personal
Registro de Sucursal Registro de Proveedores Sucursal
Clientes
Proveedores
Función del Personal
Clientes con Crédito
Módulo Control de Personal

Módulo Control de Inventario
Control de Inventario
Artículos Informes
Registro de Artículos Lista Artículos General
Registro Precio Artículos Articulo Sucursal
Articulo Central
Módulo Control de Inventario


1095

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

1095

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD MAYOR DE SAN ANDRES

FACULTAD DE CIENCIAS PURAS Y NATURALES

Postulante: Ramiro Machaca Honorio

A mi madre Francisca y a mi familia que

Mis más sinceros agradecimientos a:

Lic. Hernán Sánchez Salazar Gerente General de Vanguard Ltda. por su

Lic. Germán Huanca Ticona, como docente revisor que me brindo la

Lic. Mario Loayza , docente tutor de Taller II, por su orientación y

Lic. Julio Velásquez , por el gran apoyo que me brindo con su

Mi familia, que en las buenas y en las malas no dejaron de apoyarme.

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

Figura 2.1 Proceso de desarrollo de software ...................... 8

Vanguard Ltda., es una entidad privada dentro del rubro de la comercialización,

En Vanguard Ltda. Se tiene un departamento de importaciones que esta encargado del

En ese sentido se pretende desarrollar un sistema de información de inventario y

Para todo ello se empleara y considerara todos los conocimientos de manejo de la

La empresa Vanguard Ltda.. se creó en la década de los setenta quedando constituida

La principal actividad de la empresa es la importación y comercialización de partes de

Se mantiene un contacto con proveedores de Europa y Norte América, se maneja

En Vanguard Ltda.. se desarrollan diferentes procesos administrativos uno de ellos es

Se toma como referencia algunos estudios que se hicieron en empresas, como el

Otro proyecto desarrollado es el “ Sistema de Control de Inventario Proactivo King

Todos estos trabajos anteriormente mencionados consideran dentro de su desarrollo

1.3.- PLANTEAMIENTO DEL PROBLEMA

Actualmente en Vanguard Ltda., el proceso de control de inventarios se encuentra a

1.- Desinformación en la unidad de importaciones para hacer los pedidos necesarios.

Por lo anteriormente mencionado se considera que la raíz del problema en la empresa

1.4.1 OBJETIVO GENERAL.

• Diseñar e implementar una aplicación estocástica al Sistema de inventario de

1.4.2 OBJETIVOS ESPECIFICOS.

• Diseñar un modulo de control de inventario donde se registre los artículos

• Diseñar un modulo de control de personal que coadyuve en la asignación de

• Aplicar modelos estocásticos para minimizar la incertidumbre en la toma de

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

1.5.1. - Justificación Técnica

El empleo en la empresa de las nuevas tecnologías como la computadora es de

1.5.2.- Justificación Económica.-

El hecho de que el presente trabajo se perfile a reducir o hacer mas predecible

Por otra parte, las políticas de liquidación para la mercadería en obsolescencia

Desde el punto de vista social, el proyecto se justifica, ya que los usuarios

1.6.- ALCANCES Y APORTES

La columna vertebral de lo que se pretende realizar esta orientado a definir

Para llevar acabo el desarrollo del sistema informático, se empleara la metodología

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

• Observación, se efectúa durante las visitas a la empresa para observar detalles

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

2.1.- El Proceso Unificado (P.U.)

Requisitos del Proceso de Sistema

Los ciclos concluyen con una versión

Inicio Elaboración Construcción Transición

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

A continuación se describe brevemente los modelos principales del proceso unificado:

2.1.1.- Modelo de Casos de Uso

2.1.2.- Modelo de análisis

2.1.3.- Modelo de diseño

2.1.4.- Modelo de despliegue

2.1.6.- Modelo de prueba

2.2.- Fases dentro de un ciclo

2.2.1.- Fase de inicio