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
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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.
Fases Flujos de trabajo Fundamentales Requisitos Análisis Diseño Implementación Prueba
Iteraciones
Inicio Elaboración Construcción Transición Iter Iter … … … … … … Iter Iter
Figura 2.4 Los cinco flujos de trabajo [Jaco & Rumb & Booc, 1999].
Lo mas empleado en el proceso unificado es el modelado. La construcción de un
sistema es por tanto un proceso de construcción de modelos. Utilizando distintos modelos para
describir todas las perspectivas diferentes del sistema. La elección de los modelos para un
sistema es una de las decisiones más importantes del equipo de desarrollo.
A continuación se describe brevemente los modelos principales del proceso unificado:
2.1.1.- Modelo de Casos de Uso
Este modelo permite que los desarrolladores de software y los clientes lleguen
a un acuerdo sobre los requisitos que debe cumplir el sistema, este contiene actores,
casos de uso y relaciones.
2.1.2.- Modelo de análisis
Ayuda a refinar los requisitos (casos de uso) con más detalle y nos permite
refinar sobre los aspectos internos del sistema.
2.1.3.- Modelo de diseño
Es un modelo de objetos que describe la realización física de los casos de uso
centrándose en como los requisitos funcionales y no funcionales, tienen impacto en el
sistema a considerar. Además el modelo de diseño sirve de abstracción de la
implementación del sistema y es, de ese modo, utilizado como una entrada
fundamental de las actividades de implementación.
2.1.4.- Modelo de despliegue
Define la arquitectura física del sistema por medio de nodos interconectados.
Estos nodos son elementos hardware sobre los cuales pueden ejecutarse los elementos
software. Con frecuencia conocemos como será la arquitectura física del sistema antes
de comenzar su desarrollo. Por tanto, podemos modelar los nodos y las conexiones del
modelo de despliegues tan pronto como comience el flujo de trabajo de los requisitos.
2.1.5.- Modelo de implementación
Es un modelo que se encarga de representar el sistema en términos de código
fuente y ejecutable, modelo de implementación describe también como se organizan
los componentes de acuerdo con los mecanismos de estructuración y modularización
disponibles en el entorno de implementación y en el lenguaje o lenguajes de
programación utilizados y como dependen los componentes unos de otros.
2.1.6.- Modelo de prueba
Se encarga de las pruebas que se llevan a cabo al sistema una vez
implementado, nos permite poder saber si cumple con los casos de uso y con los
objetivos que fue creado.
2.2.- Fases dentro de un ciclo
Cada ciclo se desarrolla a lo largo del tiempo a su vez se divide en cuatro fases
como se vio en la figura 2.4
2.2.1.- Fase de inicio
El objetivo es desarrollar el análisis de la empresa o negocio hasta el punto
necesario para justificar la puesta en marcha del proyecto. Primero se debe delimitar el
alcance, el ámbito del sistema propuesto. Debemos diferenciar que es lo que va cubrir
el proyecto, que debe cubrir la arquitectura. Delimitar las estimaciones de costo,
tiempo, etc.
2.2.2.- Fase de elaboración
En esta fase se recopila la mayor parte de los requisitos que aun queden
pendientes, formulando los requisitos funcionales como casos de uso.
Se establece también una arquitectura base para guiar el trabajo durante las
fases de construcción y transición. Lo que se pretende comprender es, que es lo que se
va construir y como, además de buscar la tecnología a emplear.
2.2.3.- Fase de construcción
En esta fase se desarrolla un producto de software a partir de una línea base de
arquitectura ejecutable y trabajando a través de una serie de iteraciones e incrementos,
se desarrolla un producto software listo para su operación inicial en el entorno del
usuario a menudo llamado versión beta.
Esta termina con una demostración al usuario y haciendo pruebas del sistema
con el fin de confirmar que se han construido correctamente los casos de uso.
Las pruebas del sistema deben ser continuas hasta que estas funcionen.
2.2.4.- Fase de transición
En esta fase se cumplen con todos los requisitos establecidos en las fases
anteriores, hasta la satisfacción de todos los usuarios. También se gestiona todos los
aspectos relativos a la operación en el entorno del usuario, incluyendo la corrección de
fallas o deficiencias remitidas por los usuarios de la versión beta o por los encargados
de las pruebas de aceptación. Los desarrolladores corrigen los problemas reportados e
incorporan mejoramiento para la nueva versión. La fase de transición involucra
actividades tales como la fabricación, el entrenamiento a los usuarios, provee asistencia
de ayuda en línea y subsana fallas.
2.3.- Lenguaje Unificado de Modelado (U.M.L.)
Este lenguaje es el sucesor de la oleada de métodos de análisis y diseño orientado a
objetos (OOA&D) que surgió a fines de 1980 y principios de1990.[Fowl & Kend, 1999].
Como todo lenguaje este proporciona un vocabulario y las reglas para combinar
palabras de ese vocabulario con el objetivo de posibilitar la comunicación. Un lenguaje de
modelado es un lenguaje cuyo vocabulario y reglas se centran en la representación conceptual
y física de un sistema. Un lenguaje de modelado como UML es por tanto un lenguaje estándar
para la elaboración del software.
El vocabulario y las reglas de un lenguaje como UML indican como crear y leer
modelos bien formados, pero no dicen que modelos se deben crear ni cuando se debería crear.
Esta es la tarea del proceso de desarrollo de software. Un proceso bien definido guiara a sus
usuarios a decidir que producto producir, que actividades y que personal se emplea para
crearlos y gestionarlos, y como usar esos productos para medir y controlar el proyecto de
forma global.
El UML es un lenguaje de modelado para visualizar, especificar, construir y
documentar. En el proyecto actual se han utilizado bloques de construcción, elementos,
relaciones y diagramas.
2.4.- Correspondencia de un modelo orientado a objetos a un modelo relacional
El hacer corresponder una visión del mundo orientado a objetos con una visión
relacional es conceptualmente directo. Como observa Rumbaugh, “la correspondencia entre un
modelo de objetos y un modelo de base de datos relacional es simple, excepto para el manejo
de la generalización”. Rumbaugh continúa ofreciendo algunas reglas para la correspondencia
de clases y asociaciones (incluyendo relaciones de agregación) a tablas: [Booc, 1996].
• Cada clase se corresponde con una o más tablas.
• Cada asociación de mucho a muchos corresponde con una tabla distinta.
• Cada asociación uno a muchos se corresponde con una tabla distinta o puede
insertarse como una clave ajena.
Además sugiere una de las tres alternativas para corresponder las jerarquías de clase,
subclase a tablas.
• La superclase y cada subclase se corresponde con una tabla.
• Los atributos de la superclase se repiten en cada tabla (y cada subclase se
corresponde con una tabla distinta).
• Elevar todos los atributos de las subclases hacia el nivel de la superclase (y
tener una tabla para toda la jerarquía superclase / subclase).
En el presente proyecto se esta haciendo uso de estas reglas de Rumbaugh ya que con
el Proceso Unificado se llego a un modelo O.O. y como es de conocimiento el gestor de base
de datos SQL tiene un manejo del modelo relacional por lo que se necesita utilizar las reglas
de correspondencia para poder llegar a (SGBD) SQL Server que es un sistema administrador
de Bases de Datos Relacional.
2.5.- El modelo de datos relacional
Consiste en una colección de tablas, a cada una de las cuales se asigna un nombre
único. Una fila de una tabla representa una relación entre un conjunto de valores. Puesto que
una tabla es una colección de dichas relaciones, hay una estrecha correspondencia entre el
concepto matemático de relación del cual toma su nombre el modelo de datos relacional.
[Korth, 1993].
2.6.- Sistema de Base de Datos (BD)
Bases de datos es una gran colección de información organizada y enlazada al sistema,
a la que se accede por medio del software. A su vez esta colección de archivos pertenece
lógicamente al mismo sistema. El uso de las bases de datos permite almacenar gran cantidad
de información además de las siguientes ventajas:
• Permite tener un mejor control sobre la información que se almacena.
• Gran velocidad sobre la consulta de información.
• Respaldo de información, dando una mayor seguridad de la misma.
• Flexibilidad en el traslado de la información.
• Manejo de reportes inmediatos, obteniendo el número de copias necesarias en corto
tiempo.
• Eliminar la duplicidad de datos. Se disminuye el manejo de datos erróneos.
2.7.- Sistema de gestión de bases de datos (SGBD)
Un SGBD proporciona la flexibilidad en almacenamiento, recuperación de datos y
producción de información. De todas maneras el uso de un SGBD no elimina la necesidad de
programas de software especializados.
2.8.- Seguridad de base de datos
El método más flexible y extendido de proteger una base de datos se llama seguridad
por usuario. Esta forma de seguridad es similar a los métodos usados en la mayoría de los
sistemas.
2.9.- Inventario
La base de toda empresa comercial es la venta y la compra de bienes o servicios; de
aquí la importancia del inventario por parte de la misma. Este manejo permitirá a la empresa
mantener el control oportunamente, así como también conocer al final del periodo contable un
estado confiable de la situación económica de la empresa.
El inventario constituye las partidas del activo corriente que están listas para la venta,
es decir, toda aquella mercancía que posee una empresa en el almacén valorada al costo de
adquisición, para la venta o actividades productivas.
De los sistemas de inventario que se conocen (Sistema perpetuo y Sistema periódico),
el mas recomendable usar es el Sistema Perpetuo a través de uno de los métodos de
evaluación.
El Sistema de Inventario Perpetuo: con este sistema el negocio mantiene un registro
continuo para cada artículo del inventario. Los registros muestran por lo tanto el inventario
disponible todo el tiempo. Los registros perpetuos son útiles para preparar los estados
financieros mensuales, trimestrales o provisionalmente. El negocio puede determinar el costo
de inventario final y el costo de las mercancías vendidas directamente de las cuentas sin tener
que contabilizar el inventario. El sistema perpetuo ofrece un alto grado de control, por que los
registros de inventario están siempre actualizados. El conocimiento de la cantidad disponible
ayuda a proteger el inventario.
2.9.1.- Control de Inventario
El control interno sobre los inventarios es importante, ya que los inventarios son el
aparato circulatorio de una empresa de comercialización. Las compañías exitosas tienen gran
cuidado de proteger sus inventarios. Los electos de un buen control interno sobre los
inventarios incluyen:
• Conteo físico de los inventarios por lo menos una vez al año, no importando cual
sistema se utilice.
• Mantenimiento eficiente de compras, recepción y procedimientos de embarque.
• Permitir el acceso al inventario solamente al personal que no tiene acceso a los
registros contables.
• Mantener registros de inventarios perpetuos para las mercancías de alto costo unitario.
• Mantener suficiente inventario disponible para prevenir situaciones de déficit, lo cual
conduce a perdidas en ventas.
• No mantener un inventario almacenado demasiado tiempo, evitando con eso el gasto
de tener dinero restringido en artículos innecesarios.
2.10.- Facturación
Es un documento tributario de compra y venta que registra la transacción comercial
obligatoria y aceptada por ley. Este comprobante acredita la venta de mercaderías o la
prestación de servicios. La facturación tiene por finalidad acreditar la transferencia de bienes,
la entrega en uso o la prestación de servicios cuando la operación se realice con sujetos del
Impuesto General a las Ventas que tengan derechos al crédito fiscal. Asimismo cuando el
comprador o usuario lo solicite a fin de sustentar gastos y costos para efecto tributario y en el
caso de operaciones de exportación.
2.10.- Procesos estocásticos.
La teoría de los procesos estocásticos se lo define generalmente como la parte
dinámica de la teoría de las probabilidades en la que se estudia un conjunto de variables
aleatorias (llamado un proceso estocástico) desde el punto de vista de su interdependencia y su
comportamiento limite. Se observa un proceso estocástico siempre que se examina un proceso
que se desarrolla en el tiempo de manera controlada por leyes probabilísticas.
Por tanto definimos un proceso estocástico como una familia de variables aleatorias:
{z (t,w), t � T y w � S }
Donde T se denomina conjunto índice y S es el espacio muestral asociado a un experimento
aleatorio. T generalmente representa el tiempo, pero puede tener distintas naturalezas.
[Parz,1972 ]
Figura 2.5 Representación del proceso estocástico [Marq, 1994]
Por la naturaleza del tiempo y del espacio, los procesos estocásticos pueden ser:
1 Procesos estocásticos discretos en el tiempo y en el espacio
2 Procesos estocásticos discretos en el tiempo y continuos en el espacio
3 Procesos estocásticos continuos en el tiempo y discretos en el espacio.
4 Procesos estocásticos continuos en el tiempo y en el espacio.
En el transcurso del desarrollo del proyecto, nos limitaremos al uso del caso numero 1.
Dentro de los procesos estocásticos se hallan los Procesos Normales, Procesos de Wiener-
Levy, Procesos puntuales, Procesos Markovianos, Procesos no Normales, Series de Tiempo.
En el proyecto utilizamos Métodos de Atenuación, PROMEDIOS MOVILES que es parte de
Series de Tiempo.
2.10.1.- Promedios móviles.
Un modelo se convierte en una manera de experimentar con la realidad sin tener que
invertir en una unidad operativa a escala natural. Este tipo de modelo también se lo conoce
como modelo de simulación. Un modelo de Predicción (Makr & Whee, 1998) consiste en los
procedimientos utilizados para desarrollar un pronóstico. Existen muchos modelos pero en
cuanto a modelos cuantitativos existen solo dos tipos bien definidos: Las Series de Tiempo y
los Métodos Causales.
La notación que se utiliza se muestra en el siguiente cuadro:
VALORES DE PREDICCION
Valores observados X1 X2 X3........Xt-2 Xt-1 Xt
Periodo i 1 2 3……t-2 t-1 t
Valores estimados F1 F2 F3……Ft-2 Ft-1 Ft
Valores de Error e1 e2 e3 ……et-2 et-1 et
Ft+1 Ft+2 Ft+3………Ft+m
t+1 t+2 t+3 ……….t+m
Presente
Valor real=patrón + aleatoriedad
Figura 2.6 Notación utilizada en los modelos de predicción de series de tiempo. [Tirs, 2001]
El símbolo X identifica los valores históricos observados, y para indicar los valores de
predicción se utiliza la letra Ft+1 donde el subíndice (t+1) indica el valor pronosticado del
periodo t+1.
Debido a que el mundo de los negocios no es determinístico, la aleatoriedad siempre
está presente, lo cual significa que siempre existe una diferencia o desviación entre los valores
reales observados y los valores de predicción, denotada como sigue:
Et = Xt - Ft
Donde el subíndice t indica que en el periodo i hay un error que esta examinándose.
Debido a que la exactitud pasada y futura son tan importantes, es necesario conocer las
medidas más usuales del error de predicción.
a) Error Promedio
b) Error Promedio Absoluto (MAD: Mean absolute deviation)
c) Promedio del error al cuadrado (MSD: Mean square deviation)
d) Error absoluto medio porcentual (MAPE:Mean absolute percent error)
En este caso, la formula general para los promedios móviles simples es:
En esta fórmula Ft es la predicción para el presente periodo, donde los valores X, t-1,
t-2 …t-n representan los valores observados de los periodos pasados hasta n.
Para Ft+1, la formula es:
Lo que nos interesa a nosotros es el valor de la ultima predicción, en este caso seria la
predicción para Ft+1.
Bajo que margen de error se encuentra este valor?
Para el cálculo del margen de error, usamos la siguiente fórmula:
IC, es el intervalo de confianza al 95% de confiabilidad, Ft+1 es la última predicción, el valor
1.96 es obtenido de la tabla normal con el 95% de confiabilidad, la raíz cuadrada es del
promedio de la suma de los errores al cuadrado.
2.11.- El Modelo COCOMO
Barry Boehm, en su libro sobre economía de la ingeniería de software, introduce una
jerarquía de modelos de estimación de software con el nombre de COCOMO, por su nombre
en ingles (Constructive, Cost, Model) modelo constructivo de costos. La jerarquía de modelos
de Boehm esta constituida por lo siguiente:
• Modelo I: El modelo COCOMO básico calcula el esfuerzo y el costo del desarrollo de
software en función del tamaño del programa, expresado en las líneas estimadas de
código (LDC).
• Modelo II: El modelo COCOMO intermedio calcula el esfuerzo del desarrollo de
software en función del tamaño del programa y de un conjunto de conductores de
costos que incluyen la evaluación subjetiva del producto, del hardware, del personal y
de los atributos del proyecto. El presente proyecto empleara este modelo.
• Modelo III: El modelo COCOMO avanzado incorpora todas las características de la
versión intermedia y lleva a cabo una evaluación del impacto de los conductores de
costos en cada caso (análisis, diseño, etc.), del proceso de ingeniería de software.
Los modelos COCOMO están definidos para tres tipos de proyectos de software que son:
1.-Modo orgánico: Proyectos de software relativamente pequeños y sencillos en los que
Trabajan pequeños equipos, con buena experiencia en la aplicación, sobre un conjunto
de requisitos poco rígidos (por ejemplo, un programa de análisis termal desarrollado para
un grupo calórico).
2.-Modo semiacoplado: Proyectos de software intermedios (en tamaño y complejidad) en
los que, equipos con variados niveles de experiencia, deben satisfacer requisitos poco
o medio rígidos (p. ej.: un sistema de procesamiento de transacciones con requisitos
fijos para un hardware de terminal o un software de gestión de base de datos).
3.-Modo empotrado: Proyectos de software que deben ser desarrollados en un conjunto
de hardware, software y restricciones operativas muy restringido.
3 ANALISIS INSTITUCIONAL DE LA EMPRESA VANGUARD Ltda. 3.1.- Evaluación de la Situación Actual
En esta parte se describirá las actividades que se llevan acabo en la empresa, los
procesos que se desenvuelven, así como sus actores.
La empresa Vanguard Ltda.. Se dedica a la importación y comercialización de partes
de vehículos en la ciudad de La Paz.
La empresa mantiene relaciones con empresas del rubro que atienden los pedidos como
ser las empresas Faderpa Ltda., Toyosan y otros. Con quienes intercambia información y tiene
una participación activa en diferentes actividades de transacciones comerciales.
Estas actividades de la Vanguard Ltda. Con las empresa anteriormente mencionadas
más las producidas dentro de la empresa como la comercialización e inventario, generan
procesos (que mas adelante serán objeto de análisis) que son realizados en la mayoría de los
casos en forma manual lo que determina una demora en la documentación, presentación de
informes, atención al público, desfases en la toma de desiciones y las actividades de escritorio
en general.
El objetivo de la empresa es la comercialización, importación, distribución y venta de
artículos automotrices para todo tipo de vehiculo buscando satisfacer a un mercado amplio y
variado en cuando a sus exigencias.
3.1.1.- Organización Institucional
En esta parte se realiza el estudio de los roles y funciones del personal que trabaja en la
institución, la forma de organización, para lo cual nos ayudará el organigrama que tiene en la
institución figura: 3.1.1, el que será detallado posteriormente.
3.1.2.- Organigrama institucional
El organigrama institucional es como sigue:
DIAGRAMA ORGANIZACIONAL DE LA EMPRESA VANGUARD Ltda.
Gerencia General
Gerencia Administrativa
Gerencia Comercial
Departamento deImportaciones
Contabilidad Creditos
Vendedor 2
Encargado deSucursal
Vendedor 1
Jefe de Ventas
Vendedor BVendedor ACaja
Figura 3.1.1 Organigrama Institucional
Fuente: Vanguard Ltda.
A continuación se realizara una breve descripción de los componentes más sobresalientes
que están representados en el organigrama (figura: 3.1.1).
• Gerencia General:
Esta encargada de tomar las decisiones en la empresa, generalmente esta realiza los
contactos con las empresas proveedoras de los productos para la empresa, este puesto es
ocupado por el propietario de la Empresa.
• Gerencia administrativa:
Esta dirigida por un profesional titulado en administración de empresa este vela por el
buen manejo de la institución, generalmente es quien contrata al personal, y vela por el
buen funcionamiento de la empresa, trabajando en forma directa con la gerencia de la
institución.
• Gerencia Comercial:
Es la que se ocupa de la comercialización de los productos de la empresa realizando
marketing para ello, mantiene contactos estrechos con los clientes ya sean mayoristas o al
detalle, cuenta con un grupo de vendedores que realizan el trabajo operativo.
• Departamento de importaciones:
Este departamento es la encargada de realizar todos los pedidos de los productos faltantes
en la empresa, este mantiene contactos con los proveedores y se encarga de la distribución
de los productos a los distintos almacenes de la empresa distribuida en la ciudad de La
Paz.
3.2.- Proceso Organizacional
En esta parte se descubrirá el flujo de la información y los procesos existentes dentro de
la empresa y con algunas instituciones externas.
3.2.1.- Procesos y flujo de información actual
Como anteriormente se menciono, el flujo de la información y los procesos que se
realizan dentro la empresa en su mayoría son manuales, eventualmente en algunas ocasiones
se emplea la computadora, para realizar algunos documentos.
A continuación se realiza un flujograma de algunos procesos que se realiza en la
institución.
Procedimiento: Venta al Contado.
Clientes
Vendedor
Almacén
Caja
Factura Producto Producto
Existe Artic.
Revisar Documento
Fin
Factura
Solicita Producto
Producto
Inicio
SI
No
Figura 3.2.1.a Venta al contado
Fuente: Elaboración propia
Procedimiento: Traspasos entre Almacenes
Almacén destino Y Encargado de
ventas sucursal Y Encargado de ventas
sucursal X Almacén X
Enviar los Productos
Actualizar kardex
Emitir nota de traspaso
Confirmar Existen.
Revisar documento
Fin
Emitir nota de Ingreso
Actualizar Kardex
Recepcion nota de traspaso
Hacer Pedido
Inicio
Ingresar los Productos
Si No
Figura 3.2.1.b Traspasos entre almacenes
Fuente: Elaboración propia
Procedimiento: Pedido de Mercadería
Encargado de Importaciones
Gerencia Comercial Contabilidad Gerencia General
compra
No
Autoriza Solicitud deExisten
Recurso
Verifica Solicitud
necesario por demenda?
Verifica Solicitud
Imprime solicitud de movimiento de ventas
Fin
Inicia compra del proveedor
Elabora Solicitud de compra
Analiza Documentación
Solicita movimiento de mercadería de artículos con poco stock
Inicio
No
Si
si
Figura 3.2.1.c Pedido de Mercadería
Fuente: Elaboración propia
Procedimiento: Ventas al Crédito Cliente Vendedor Encargado de Créditos Almacén Caja
No
Si
Confirma Exist.Art
Inicio
Revisa Documento
Revisa Docum del cliente
� reg. clie
Aceptar Credito?
Producto Factura Producto
Producto
Factura
Fin
Solicitud de credito
Reg. Cliente y evaluación de monto
No
No
Si
Si
Figura 3.2.1.d Venta al Crédito
Fuente: Elaboración propia
3.2.2.- Análisis de problemas
Luego de realizar las entrevistas correspondientes con el directorio de la empresa y
los correspondientes jefes de área y la observación en el desenvolvimiento de los procesos
se identifico los siguientes conflictos.
1.- Desinformación en la unidad de importaciones para hacer los pedidos necesarios.
2.- Falta de aplicación de políticas de descuentos para la venta de los diferentes
artículos.
3.- Incertidumbre en la toma de dediciones.
4.- Información no disponible de los clientes mayoristas.
5.- Falta de control al seguimiento del movimiento de una mercadería.
6.- Reducción de ingresos con pérdida de utilidad.
7.- Generación de mercadería obsoleta por acumulación.
8.- Excesivo pedido de mercadería, por falta de información adecuada.
9.- Venta de artículos por debajo del precio de costos por los descuentos altos.
10.- Desconfianza hacia el personal de almacenes y ventas por el nivel ejecutivo.
11.- Retrasos en los pedidos de mercadería por el volumen de información de los
artículos.
12.- La no existencia de un sistema de inventario con apoyo científico para la toma de
decisiones para hacer los pedidos necesarios manteniendo un equilibrio.
13.- Perdida de clientes generando ventas pérdidas por no tener la mercadería.
3.2.3.- Determinación de requerimiento
A continuación se señalan los requerimientos que no están satisfechos y los
problemas que los clientes y trabajadores encuentran en la actualidad y que el nuevo
sistema va a solucionar:
Otorgar una información más certera para la toma de las decisiones.
Aplicar las políticas que maneja la empresa para una mejor administración de ella.
Una información adecuada y oportuna de parte del departamento de importaciones para
la adquisición de los productos.
Evitar con el sistema el sobre stock para reducir las perdidas producidas por ello.
Evitar los retrasos de los pedidos que ocasiona la pérdida de clientes por la falta de los
productos.
Mejorar el sistema de inventario automatizando todos los trabajos relacionados con
este.
3.3.- Análisis de Factibilidad
Existen técnicas excelentes para la comparación de los costos y los beneficios del
sistema propuesto.
Al estimar se toma en cuenta no solo el procedimiento técnico a utilizar en el
proyecto, sino también los recursos, costo y planificación. El tamaño del proyecto es otro
factor importante que puede afectar la precisión de las estimaciones. A medida que el
tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del
software.
Para ser considerado como factible un proyecto debe pasar por lo menos las
siguientes tres pruebas, de lo contrario el proyecto no es factible.
3.3.1.-Factibilidad Económica
Para poder realizar este análisis lo que se realiza en principio es determinar el costo
de investigación y construcción del nuevo sistema (Tabla 3.3.1), para lo cual el punto de
partida es determinar el costo del software que constituye un porcentaje del costo total de
los sistemas basados en computadoras.
A diferencia de tiempos anteriores hoy en día el software se constituye en el
elemento más caro en los sistemas informáticos. El tiempo que se contabiliza es de 8 meses
aproximadamente, este tiempo es corroborado por el modelo COCOMO posteriormente, si
suponemos una jornada de 8 horas diarias de trabajo.
En esta tabla 3.3.1 se muestra la relación de tiempo y costo del sistema:
Tabla 3.3.1 Costo de Investigación y Construcción del Sistema
DESCRIPCION
Nº de
Per.
TIEMPO TOTAL Horas/
Hombre
COSTO Por
Hora ($US)
COSTO Aprox. Por día ($US)
COSTO TOTAL
($US)
Estudio y análisis del sistema actual 1 280 1,78 14,2 500 Análisis y diseño del nuevo sistema *1 504 1,8 14,3 900 Programación del sistema *1 672 1,78 14,2 1200
TOTALES 3 1456 1,78** 42,7 2600 * COCOMO ** Promedio Nota: Costo total = Tiempo Total * Costo
Entre otros costos menores se tiene: 800 $US
Por lo tanto el costo total del sistema es:
Costo de inventario y Construcción del sistema 2600 $US
Otros costos 800 $US
TOTAL 3400 $US
3.3.2.-Ventajas del sistema de información
Lo que se realiza es detallar los beneficios que el nuevo sistema puede brindar a la
empresa en su labor de servir mejor al público, a la administración de la empresa. Para ello
se considera los beneficios tangibles e intangibles que puedan existir.
Los beneficios en las tareas de mantenimiento de registros son:
Aumento de la capacidad para el mantenimiento de registros en términos de espacio
y costo.
Mantenimiento de registros más completo y sistemático.
Estandarización del mantenimiento de registro.
Aumento de la cantidad de datos que se pueden guardar por registro.
Posibilidad de recoger y guardar automáticamente datos de los registros: ventas,
compras, etc.
Mejora de la seguridad en el almacenamiento de registros.
Mejora en la portabilidad de los registros.
Los beneficios en las tareas de búsqueda de registros son:
Obtención de los registros mas rápido.
Mejores posibilidades de actualizar registros en la base de datos.
Mejores posibilidades de mantener un detalle sobre los accesos a los registros y por
quien.
Los beneficios en las tareas de cálculo e impresión son:
Mejora en la exactitud de las tareas de cálculo.
Reducción en el cálculo e impresión.
Incremento en la velocidad de cálculos aritméticos e impresiones.
3.3.3.- Modelo COCOMO: las bases para el empleo de COCOMO II es el costo de
esfuerzo de desarrollo de software estimado luego de determinar la arquitectura del sistema.
Tabla 3.3.3. Matriz de Coeficientes COCOMO
Básico Intermedio Nivel
Modo ai bi ai bi
Orgánico 2.4 1.05 3.2 1.05
Semiencajado 3.0 1.12 3.0 1.12
Empotrado 3.6 1.2 2.8 1.2
Como se puede observar (Tabla 3.3.3), se tiene la matriz de coeficientes COCOMO,
para los diferentes modos y niveles, se tiene los diferentes estándares de complejidad de
esfuerzo del personal como en el caso del básico que varia de 2.4 a 3.6 según la
complejidad del proyecto.
A continuación realizamos una aplicación de este modelo COCOMO II en el proyecto.
Exponente bi = 1.05 este puede variar hasta un máximo 1.2
El Coste es : Km = 2.4 * Sk1.05 = 2.4 * (1.3) k
1.05 = 3.1 ≈ 3 personas / mes
Donde Sk representa el tamaño expresado en miles de código, para el caso particular se
determina 1.300 líneas aproximadamente.
El tiempo de desarrollo se da por:
td = 2.5 Km0.28 = 2.5 * (3) m 0.28
td = 3.4 ≈ meses.
Donde Km se obtiene de la operación anterior y td es el tiempo de desarrollo en
meses.
El exponente 0.28 puede variar hasta 0.91 bajo el supuesto que una persona haga el
trabajo de dos, entonces tenemos lo siguiente:
td * 2 = 3 meses * 2 = 6 meses.
El cual es el tiempo requerido para el desarrollo del software del sistema.
3.3.4.- Factibilidad Técnica
En la empresa adquirirá una computadora, que cuente con los requerimientos
necesarios para el funcionamiento del sistema, o se adecuara uno que ya existe, por lo que
no surgirán problemas mayores en la instalación del sistema informático.
La empresa desea cambios en su campo, es decir contar con una tecnología que le
permita mejorar la atención al público (clientes), que interactúan con el sistema, por tanto la
empresa está en total aceptación de la utilización del equipo computacional y el sistema que
se desarrolla. El equipo computacional será descrito mas adelante. (Tabla 3.3.4)
3.3.5.- Factibilidad Operacional
En la institución existe el personal capacitado para realizar tareas técnicas de
computación, por lo que no existirán mayores problemas al respecto. Sin embargo es
necesario enseñar el manejo de la información a los encargados del área al cual va dirigido
el sistema (departamento de importaciones y ventas), Esta capacitación se realizara
oportunamente.
Tabla 3.3.4 Equipo Computacional
CANT. DETALLE IMP .$US 1 Disco duro 80 GB. 50 1 Memoria 256 DDR II 18 1 Tarjeta madre AsRock 75 1 Microprocesador 3.0 GB. original 110 1 Lector de DVD 25 1 Tarjeta de fax módem 7 1 Floppy 8 1 Case combo m/t/p 45 1 cortapicos 2 TOTAL 598 $us
Fuente: Elaboración propia
4.- DISEÑO LOGICO Y FISICO
4.1.- Diseño Lógico
El diseño lógico utiliza un modelo gráfico, donde se formula las especificaciones
funcionales para los módulos de software. A continuación se muestra los diagramas que se
utiliza en el análisis y diseño.
4.1.1.- Diagrama de Casos de Uso
El diagrama de caso de uso, ilustra gráficamente las fronteras del sistema con el resto
del universo, nos permite identificar en forma clara y concisa cada uno de los flujos de
datos y los actores.
En la Figura 4.1 se realiza el diagrama de caso de uso general del sistema.
4.1.2.- Diagrama de Casos de Uso General
Caso de Uso: General
Control de Inventario
Control de Personal
Sucursal
Importaciones
Gerencia
Transacciones Cliente
Proveedor
Personal
Impuestos
Figura 4.1 Diagrama de caso de uso general
Fuente: Elaboración propia
4.1.3.- Diagrama parcial y Documento de descripción de casos de uso
A continuación mostramos la interacción entre el usuario y el sistema con los
diagramas de casos de uso parcial y la descripción de los mismos para describir cada uno
de los casos de uso, en este documento se detalla el nombre del caso uso, los actores del
caso de uso, una descripción del desenvolvimiento y el proceder de los actores en el caso de
uso, el flujo principal con los eventos del actor y el sistema, la precondición del sistema, la
poscondición y por ultimo la presunción en sistema.
Documento de Descripción de Casos de Uso:
DOCUMENTO DE DESCRIPCIÓN DE CASOS DE USO CU-1
a) Nombres: Información de las actividades en la empresa
b) Actores: Gerencia
c) Descripción Un informe detallado de cómo se esta desenvolviendo las transacciones comerciales en general en la empresa además de la adquisición de los artículos. Eventos Actor Eventos de Sistema
1. Ingreso al modulo de asignaciones de artículos, como de llevan acabo las ventas de los distintos artículos.
1. Presenta la opción de listado de asignaciones, la venta de artículos por fechas.
2. Reporte de importaciones de artículos.
2. Se abre el modulo de compras de artículos.
d) Flujo Principal
3. Solicitud de impresión de informes de lo pedido.
3. Opción de poder imprimir los informes deseados.
e) Precondición -Que el sistema tenga los datos actualizados de los distintos módulos
f) Post Condición -Se tiene el informe impreso
g) Presunción - La Base de datos de proyectos esta disponible.
Caso de Uso: Informe a Gerencia
Registro deVentas
Registro deFactura
RegistroArtículos
Registro de Importacion
Informes
Gerencia
Registro dePersonal
Usa
UsaUsa
Usa
Usa
Figura: 4.2.a: Diagrama parcial de casos de uso Informe a Gerencia
Fuente: Elaboración propia
DOCUMENTO DE DESCRIPCIÓN DE CASOS DE USO CU-2
a) Nombres: Pedido de Artículos.
b) Actores: Importaciones, gerencia, proveedor.
c) Descripción Lo que se hace es verificar la existencia de los artículos para determinar que artículos faltan para completar el stock. Eventos Actor Eventos de Sistema
1. Revisa los artículos cuya existencia en saldo sea el mínimo.
1. Ingresa a registro de productos para verificar la existencia.
2.Detalle de los artículos faltantes
2. Lista de los artículos e impresión de ellos en base a la frecuencia de venta de estos, en formato pedido.
d) Flujo Principal
3.El usuario escoge terminar 3. Cierre u opción salir del modulo. e) Precondición -Tener actualizados los módulos de venta considerando las sucursales.
f) Post Condición -Tener la información impresa del pedido de los artículos faltantes.
g) Presunción La Base de datos de proyectos esta disponible.
Caso de Uso: Pedido de Artículos Faltantes
Calculo de pronostico de demanda
Verifica y selecciona existencia de articulos
Informe de pedido de mercadería
Listado de artículos con existencia minima
Gerencia
Importaciones
Proveedor
Figura: 4.2.b: Diagrama parcial de casos de uso Pedido de Artículos
Fuente: Elaboración propia
DOCUMENTO DE DESCRIPCIÓN DE CASOS DE USO CU-3
a) Nombres: Facturación.
b) Actores: Agente de Ventas, cliente
c) Descripción Se realiza la transacción del articulo solicitado por el cliente, ya sea este una venta al crédito o efectivo y dando de baja la cantidad solicitada del o los artículos. Eventos Actor Eventos de Sistema
1. El agente de ventas pregunta al cliente la modalidad de venta (crédito o efectivo).
1. Si es en efectivo continua la atención, si es crédito solicita el código del cliente y devuelve información de calificación.
2. De acuerdo a la calificación, el agente de ventas termina el proceso o atiende solicitud del cliente.
2. Pide el código de vendedor, y pasa a detalle pidiendo el código del producto o su número de fábrica, devolviendo información del precio y existencia.
d) Flujo Principal
3. Con la conformidad del cliente, el agente de ventas decide emitir factura.
3. Solicita información del cliente e imprime la factura, registrando toda la información de la transacción.
4. Se entrega una copia de factura al cliente más los productos.
e) Precondición -Tener actualizados los datos de clientes con acceso a crédito, y tener la existencia necesaria de productos.
f) Post Condición - Se tiene impreso la factura con copias, para el cliente y para documentación de la empresa.
g) Presunción La Base de datos de proyectos esta disponible.
Caso de Uso: Facturación
Verifica existencia de saldo del articulos solicitado
Registra el codigo del vendedor
Registra los datos de los articulos vendidos
Toma los datos del cliente para registrarlo
Emite Factura
Agente deVenta Cliente
Figura: 4.2.c: Diagrama parcial de casos de uso Facturación
Fuente: Elaboración propia
DOCUMENTO DE DESCRIPCIÓN DE CASOS DE USO CU-4
a) Nombres: Asignación de Artículos.
b) Actores: Sucursal, Almacenes.
c) Descripción Se realiza los traspasos correspondientes entre almacenes de la oficina central y sucursal. Eventos Actor Eventos de Sistema
1. El almacén origen ingresa al modulo de asignación de artículos.
1. El sistema le solicita escoger el almacén destino.
2. Almacén origen determina artículos y cantidades a enviar.
2. Pide ingresar el código del artículo y la cantidad.
d) Flujo Principal
3. Solicita imprimir la nota de envió para enviarlo una copia junto con la mercadería al almacén destino.
3. Muestra la opción de imprimir la nota, actualizando los saldos de los artículos que salen y registrando el movimiento.
e) Precondición -Tener una nota de solicitud de artículos del almacén destino y las cantidades necesarias del artículo a enviar.
f) Post Condición -Se tiene impreso la nota de envió y nota de ingreso del almacén destino.
g) Presunción La Base de datos de proyectos esta disponible.
EncargadoDe Sucursal
Caso de Uso: Asignación de Artículos a sucursal
Verifica existencia de saldo de artículos solicitado
Registra el código del despachante
Registra los datos de los articulos a enviar
Determina artículos y cantidades a enviar
Emite una nota de traspaso
Almacen solicitante
Figura: 4.2.d: Diagrama parcial de casos de uso Asignación
Fuente: Elaboración propia
DOCUMENTO DE DESCRIPCIÓN DE CASOS DE USO CU-5
a) Nombres: Compra
b) Actores: Gerencia, Importaciones, Proveedor
c) Descripción Importaciones elabora un listado de compra de proveedores locales para abastecer el stock de artículos faltantes por la necesidad inmediata. Eventos Actor Eventos de Sistema
1. El encargado de importaciones busca artículos faltantes.
1. El sistema emite un listado de los artículos faltantes.
2. Realiza una selección y clasificación de artículos de requerimiento inmediato.
2. Emite un listado de los artículos requeridos determinando el costo estimado.
d) Flujo Principal
3. Envía la orden de compra a gerencia para su aprobación.
3. Registra los datos de la orden de compra.
e) Precondición -Tener actualizado la información de los proveedores locales.
f) Post Condición -Evitar pérdidas de clientes dando más confianza a los mismos.
g) Presunción La Base de datos de proyectos esta disponible.
Caso de Uso: Compra de Artículos Faltantesa nivel local
Realiza el calculo de pronostico de demanda
para determinar cantidades
Verifica y selecciona existencia de articulos
Genera un listado informe de pedido de mercaderia
Elabora un listado de articulos mas relevantes con existencia minima
Gerencia
Importaciones
Proveedor Local
Figura: 4.2.e: Diagrama parcial de casos de uso Compra Local
Fuente: Elaboración propia
DOCUMENTO DE DESCRIPCIÓN DE CASOS DE USO CU-6
a) Nombres: Inventario
b) Actores: Gerencia, Encargado de Almacén
c) Descripción A solicitud de gerencia, se pide un inventario de artículos existentes para informe a la renta o por control interno. Eventos Actor Eventos de Sistema
1. El encargado de almacén entra al modulo de inventario.
1. Da la opción de escoger por rango en forma continua, o en forma aleatoria.
2. Escoge una de las opciones mostradas por el sistema.
2. Pide ingresar el ítem inicial y el ítem final y muestra una lista con la descripción y saldos. Genera un informe.
d) Flujo Principal
3. Compara con la existencia física y elabora un informe para remitir a gerencia.
3. Finaliza proceso.
e) Precondición -Tener actualizado la información en todos los módulos correspondientes.
f) Post Condición -Se tiene un informe real de los saldos de artículos para actualizar la información en la base de datos.
g) Presunción La Base de datos de proyectos esta disponible.
Caso de Uso: Inventario
Solicita informe de inventario general
Elabora un listado de articululos y saldos
Compara con la existencia física
Solicita informe de inventario por grupo y
aleatorio
Emite informe de Inventario
GerenciaEncargado de Almacen
Figura: 4.2.f: Diagrama parcial de casos de uso Inventario
Fuente: Elaboración propia
DOCUMENTO DE DESCRIPCIÓN DE CASOS DE USO CU-7
a) Nombres: Ingreso de Mercadería
b) Actores: Importaciones, contabilidad.
c) Descripción Una vez llegado los productos por importación, el encargado de importaciones registra, verifica la cantidad y estado para luego dar su conformidad. Eventos Actor Eventos de Sistema
1. Importaciones verifica el estado de la mercadería y de acuerdo a ello determina ingresar los productos a almacén.
1. El sistema solicita introducir el factor para hacer el cálculo de precios y costo. Emite un informe.
2. Luego de haber hecho el costeo, remite informe a contabilidad.
2. Termina el proceso de costeo.
d) Flujo Principal
3. Entra a opción de ingreso de mercadería y escoge el almacén.
3. Muestra la opción de Almacén al que desea ingresar los productos. Emite un informe de ingreso por importación.
e) Precondición -Tener la carpeta del proceso de importación con el detalle de los productos.
f) Post Condición -Se tiene impreso y registrado los artículos obtenidos por importación.
g) Presunción La Base de datos de proyectos está disponible.
Caso de Uso: Ingreso de mercaderia
Verifica el estado de la mercadería
Registra el ingreso de la mercadería a almacén
Elabora nota de remision
Realiza el costeo para determinar precio y costo
ContabilidadImportaciones
Figura: 4.2.g: Diagrama parcial de casos de uso Ingreso de Mercadería
Fuente: Elaboración propia
DOCUMENTO DE DESCRIPCIÓN DE CASOS DE USO CU-8
a) Nombres: Impuestos
b) Actores: Gerencia, Contabilidad.
c) Descripción Impuestos internos mensualmente exige el reporte de ventas, el sistema genera el mismo bajo el formato requerido. Eventos Actor Eventos de Sistema
1. Contabilidad ingresa a facturación. 1. El sistema solicita la clave de acceso.
2. Escoge la opción Impuestos Internos.
2. Pide ingresar el periodo del cual se requiere el informe de ventas. Muestra un listado de facturas con el número correlativo.
d) Flujo Principal
3. Verifica los datos, genera un archivo para importarlo al sistema de impuestos.
3. Pide el nombre del archivo con el cual se bajara la información. Por default “sit_vede.txt”
e) Precondición -Tener actualizado la información en todos los módulos correspondientes.
f) Post Condición -Se tiene un archivo portable para interactuar con el sistema de impuestos Internos.
g) Presunción La Base de datos de proyectos está disponible.
4.1.4.- Diagramas de Clase (Modelo conceptual).- Un modelo conceptual explica mejor
el flujo de información, tanto en el proceso en el movimiento de importaciones, almacenes
y facturación. Para lo cual se realiza en primera instancia la captura de conceptos y
atributos.
Conceptos y atributos
Transferencias
• Codtrans
• Codartc
• Codpro
• Codper
• Fechatrans
• Destino
• Origen
Proveedor
• Codpro
• Nombre
• Representantelegal
• Dirección
• Teléfono
• Correo
Facturación
• Nrofactura
• Codcli
• Fecha
• NIT
• Descripción
• Monto
VentaArticulo
• Codventa
• Codartic
• Codsucur
• Codcli
• Descripción
• Cantidad
• tipventa
• Monto
• Fecha
Personal
• Codper
• Nombre
• Apepat
• Apemat
• Dirección
• Teléfono
• Cargo
Articulo
• Codartic
• Nombre
• Descripción
Sucursal
• Codsucur
• Dirección
• Teléfono
• Encargado
CompraArticulo
• Codcompr
• Codartic
• Fecha
• Codpro
• Cantidad
• Precio
• Monto
Artprecios
• Codartic
• Codpro
• Nfabrica
• Precio
• Fechaingreso
• Cantidad
TipoCliente
• Tipcli
• Teléfono
• Garante
• RepresentanteLeg
Cliente
• Codcli
• Nombre
• tipcli
• Dirección
• NIT
Devoluciones
• Nrofactura
• Codarti
• Codcli
• Cliente
• Fecha
• NIT
• Descripción
• Monto
• Codper
Saldo_Sucursal
• Codsalsur
• Codarti
• Codsucur
• Codpro
• Cantidad
4.1.5.- Diagramas de Clase (Modelado estructural).- Los diagramas de clases se utilizan
para modelar la vista de diseño estática de un sistema.
En primera instancia con la captura de conceptos, posteriormente los diagramas de
clase con la agregación de asociación figura 4.3 y por ultimo los diagrama de Clases con
Agregación de Atributos y operaciones figura 4.4.
Diagramas de clase con la agregación de asociación
Para un funcionamiento de 10 horas o después de 10 horas la probabilidad de que el
sistema no falle esta dado por:
e -0.01(10) = e -0.1 = 0.905
Entonces se tiene un 90% de probabilidad de que el sistema no falle.
5.6.- Prueba de Software
Una estrategia de prueba de software integra las técnicas de casos de prueba en una serie
de pasos que dan como resultado una correcta construcción del software.
o Prueba de unidad. Esta prueba se realizo a cada uno de los módulos, ya que permite
que cada módulo este libre de errores.
o Prueba de integración. Una vez que sea integrado todos sus componentes se realizo la
verificación para que el sistema funcione sin ningún problema.
o Prueba de validación. Esta prueba es muy importante ya que se realizo la validación
para verificar si el sistema satisface los requerimientos del usuario.
o Prueba del sistema. Esta prueba del sistema se realizo en el lugar de actual
funcionamiento.
5.7.- La mantenibilidad
Se centra en el cambio que va asociado a la corrección de errores, adaptaciones y a los
cambios debido a las mejoras por los requisitos cambiantes del cliente.
Corrección. Incluso cuando el sistema tiene garantías de calidad, es probable que se
descubra defectos en el software. Por lo tanto el mantenimiento correctivo modifica el
software para corregir los errores.
Adaptación. Una vez instalado el software no dura de forma permanente ya que puede
que cambie su entorno original, entonces es necesario realizar el mantenimiento adaptativo
para que el software se pueda adecuar a los cambios de su entorno externo.
Mejora. A medida que se va utilizando el software, se va descubriendo los beneficios
que producen.
5.8- Seguridad del sistema
La institución debe estar organizada de tal modo que facilite y favorezca la gestión de
la seguridad informática. Y esto debe cumplirse con absoluto hermetismo.
Es vital contar con personal sobre el que se pueda depositar confianza.
5.9.- Aspectos preventivos
Este apartado aborda los aspectos asociados al componente lógico del sistema: programas
y datos. Para ello, se distingue entre las medidas para restringir y controlar el acceso y empleo
de dichos recursos, los procedimientos para asegurar la fiabilidad del software (tanto operativo
como de gestión) y los criterios a considerar para garantizar la integridad de la información.
• Control de acceso: Sistema de identificación, como el equipo esta designado
particularmente para el empleo de los vendedores este equipo tiene un código de
acceso desde el momento del inicio y para poder ingresar al sistema solo se lo puede
realizar ingresando la clave de acceso que solo lo saben la Gerencia e importaciones.
• Software de base: Control de cambios y versiones, control de uso de programas de
utilidad.
6.- CONCLUSIONES Y RECOMENDACIONES
6.1 Conclusiones.
Se ha logrado cumplir con los objetivos planteados durante la primera fase de
desarrollo del sistema.
• El Desarrollo y construcción del sistema de inventarios con la aplicación
de los procesos estocástico para la empresa Vanguard Ltda. ha
concluido satisfactoriamente, cumpliendo con los requerimientos de la
empresa.
• Se logro dar mayor seguridad a la toma de decisiones con la aplicación
de los procesos estocásticos, reduciendo de sobremanera la
incertidumbre y haciendo mas oportuna el pedido de artículos faltantes
en la empresa.
• Se logro tener un mejor control y seguimiento de los artículos en la
empresa, evitando la perdida de los mismos.
• Existe una mayor rapidez en la emisión de los informes por que todos
los datos que se emplean para la misma están debidamente registrados
en la base de datos.
• Los formatos de entrada y salida fueron diseñados de manera que
guardan similitud con los formularios que se manipulan, de forma que
se tiene una coincidencia en los campos a llenar.
6.2 Recomendaciones.
• Expandir el proyecto anexando a un modulo de contabilidad para tener un
mejor control de costos y beneficios de la empresa.
• Mejorar el modelo del proceso estocástico con otro modelo de más precisión,
ya que a futuro se tendrá más datos históricos.
• Dado que las características de comercializar un producto de un rubro a otro
son muy similares, el software con algunas modificaciones puede ser genérico.
• Por la tendencia del comercio electrónico, seria bueno ir en esa dirección para
incrementar las ventas de los productos desarrollando un portal Web dedicado a
ello.
7.- REFERENCIA BIBLIOGRAFICA [Booc, 1996] Booch, G., 1996: Análisis y Diseño Orientado a Objetos con Aplicaciones, 2da.
Edición, 638 pp., Addison Wesley/ Díaz De Santos, México.
[Fowl & Kend, 1999] Fowler, M. & Kendall, S., 1999: UML Gota a Gota 1ra. Edición, 1pp ,
Addison Wesley, Mexico.
[Jaco & Rumb & Booc, 1999] Jacobson, I. & Rumbaugh, J. & Booch, G., 1999: The Unified
Modeling Languaje User Guide, 1ra. Edición, 482 pp,
Addison-Wesley, United Stated of America.
[Jaco & Rumb & Booc, 1999] Jacobson, I. & Rumbaugh, J. & Booch, G., 1999: The Unified
Software Development Process, 1ra. Edición, 512 pp,
Addison-Wesley, United Stated of America.
[Korth, 1993] Korth, H., 1993: Fundamentos de Bases de Datos, 2da. Edicion, 739 pp,
MacGraw Hill, México.
[Murr, 1990] Murria R. Spiegel, 1990: Estadística, McGraw-Hill.Mexico
[Senn, 1994] Senn Jmes: “Analisis y Diseño de Sistemas de Informacion” Georgia State Universiti. Mexico Mc.Graw Hill 2da. Edición 1994 [Par,1971] Emmanuel Parzen: “Procesos Estocásticos” Paraninfo, Magallanes Madrid . M.1971 [Cast,2000] Maria Nilsa, Castro Huanca “Sistemas de control de Inventario Proactivo King
Tropical & Marine Ltda.” Proyecto de Grado 2000 [Cam, 2001] Tirso Campos Santillan: “Problemario de Pronósticos para la toma
de decisiones” Thomson 2001. [Marq, 1994] Raul Marquiegui Navarro: “Procesos Estocásticos” Tomo I, F.C.P.N. Carrera de Estadistica 1994.
ANEXO A ARBOL DE PROBLEMAS
NO EXISTE UN SISTEMA DE INVENTARIOS NI POLITICAS CON APOYO CIENTIFICO PARA LA TOMA DE DECISIONES PARA HACER LOS PEDIDOS NECESARIOS MANTENIENDO UN EQUILIBRIO.
FALTA DE POLITICAS DE DESCUENTOS PARA LA VENTA DE LOS DIFERENTES ARTICULOS
PERDIDA DE CLIENTES GENERANDO VENTAS PERDIDAS POR NO TENER LA MERCADERIA
DESCONFIANZA HACIA EL PERSONAL DE ALMACENES Y VENTAS POR EL NIVEL EJECUTIVO
VENTA DE ARTICULOS POR DEBAJO DEL PRECIO DE COSTO POR LOS DESCUENTOS ALTOS
DESEQUILIBRIO ADMINISTRATIVO Y CONTABLE
GENERACION DE MERCADERIA OBSOLETA POR ACUMULACION
RETRASOS EN LOS PEDIDOS DE MERCADERIA POR EL VOLUMEN DE INFORMACION DE LOS ARTICULOS.
INFORMACION NO DISPONIBLE DE LOS CLIENTES MAYORITARIOS.
FALTA DE CONTROL AL SEGUIMIENTO DELMOVIMIENTO DE UNAMERCADERIA
EXECIVO PEDIDO DE MERCADERIA, POR FALTA DE INFORMACION ADECUADA
iNCERTIDUMBRE EN LA TOMA DE DECISIONES .
REDUCCION DE INGRESOS CON PERDIDA DE UTILIDADES
POCA INFORMACION CON LAS FUENTES DE INFORMACION AFIN.
DESINFORMACION EN LA UNIDAD DE IMPORTACIONES PARA HACER LOS PEDIDOS NECESARIOS.
ARBOL DE OBJETIVOS
APLICACIÓN ESTOCÁSTICA AL SISTEMA DE INVENTARIO DE
VANGUARD LTDA. PARA LA TOMA DE DECISIONES
AUTOMATIZAR LA REALIZACION DEL INVENTARIO DE LOS ARTICULOS CON LOS CUALES SE COMERCIALIZA EN LA EMPRESA
PEDIDOS DE MERCADERIA OPORTUNOS O A SU DEBIDO TIEMPO
IFORMACIÓN DISPONIBLE DE LOS CLIENTES QUE TIENEN CRÉDITO.
MEJORAR EL CONTROL DE LA MERCADERIA EVITANDO PERDIDAS DE LAS MISMAS
VENTA DE ARTÍCULOS A SU PRECIO JUSTO EVITANDO DESCUENTOS ALTOS
AUTOMATIZAR LAS TRANSACCIONES COMERCIALES QUE LA EMPRESA
REALIZAR UN MODULO PARA EL CONTROL DE PERSONAL DE LA EMPRESA Y LOS PROVEEDORES Y CLIENTES CON LOS QUE CUENTA
AUMENTO DE CLIENTES EVITANDO VENTAS PERDIDAS POR TENER LA MERCADERÍA NECESARIA
MANTENER EL ABASTECIMIENTO DE MERCADERÍA EN ALMACENES CON EL STOCK NECESARIO
MAYOR CONTROL AL SEGUIMIENTO DEL MOVIMIENTO DE UNA MERCADERÍA.
REGISTRAR AL PERSONAL EN CADA TRANSACCIÓN DE MERCADERÍA GANANDO LA CONFIANZA DEL NIVEL EJECUTIVO
IMPORTAR LAS CANTIDADES ADECUADAS DE MERCADERÍA, PARA EL ABASTECIMIENTO DE LOS ALMACENES
MATRIZ DE PLANIFICACIÓN DEL PROYECTO (M.P.P.) TITULO DEL PROYECTO: “APLICACIÓN ESTOCÁSTICA AL SISTEMA DE INVENTARIOS DE VANGUARD Ltda. PARA LA TOMA DE DECISIONES” RESUMEN NARRATIVO
INDICADORES VERIFICABLES OBJETIVAMENTE
MEDIOS VERIFICABLES
SUPUESTOS
FIN DEL PROGRAMA(OBJETIVO FINAL)
Fin: Optimizar las tareas, procesos de las unidades involucradas, incrementando las utilidades y satisfaciendo con mas cobertura la demanda del mercado automotriz.
- La aplicación de los procesos Estocásticos , apoyando a la toma de decisiones con el sistema de inventarios dando mayor seguridad en la toma de decisiones haciendo mas certero lo impredecible.
- Existen varias empresas, instituciones, organizaciones que se dedican a la comercialización de diferentes artículos que pueden hacer uso de lo que se pretende realizar.
Predisposición de la empresa y de las unidades
involucradas y la información de fuentes externas como el Organismo Operativo de Transito y otros afines al proyecto.
PROPÓSITO (OBJETIVO GENERAL)
Diseñar e implementar una aplicación estocástica al Sistema de inventario de Vanguard Ltda.. para la toma de desiciones
1.- Se reduce la incertidumbre en 90% para brindar información del adecuada para la adquisición de artículos. 2.- La emisión de informes mas creíbles y concretos de las operaciones de la empresa 3.- Se reduce el tiempo en 90% de realización de información de saldos de artículos en las sucursales.
1.- Informe emitido por la empresa Vanguard Ltda..en poder del proyectista. 2.-Informe detallado de cada articulo y las transacciones en el archivo de la empresa
1.-Se utiliza la información adecuada. 2.- No existe interrupción en la dotación de energía eléctrica. 3.- Soporte de actualización y mantenimiento ante fallas.
PRODUCTOS: OBJETIVOS ESPECÍFICOS
* Modulo de control de inventario de la empresa. *Modulo de control de personal de la empresa. *Modulo de seguimiento de Transacciones de la empresa
1.- Prueba de caja negra del módulo de Control de Inventario 2.- Prueba de caja negra del modulo control de personal 3.- Prueba de caja negra del Modulo de Transacciones de
1.- listado de resultados de la prueba del módulo de control de inventario almacenado en el archivo de la empresa 2.- Documentación del sistema conteniendo los resultados de la prueba del módulo de Control de personal 3.- Listado de resultados de la prueba de caja negra del modulo de Transacciones.
1.- Datos correctos en la base de datos del inventario. 2.- Datos correctos en la base de datos del personal. 3.- Datos correctos de las transacciones de la empresa. 4.- No existen modificaciones en los formularios.
INSUMOS (ACTIVIDADES)
1. Análisis de problemas y objetivos. 2. Desarrollar y estructurar el perfil del Proyecto de Grado. 3. Estudio y análisis de los Procesos Estocásticos. 4. Estudio y análisis de los Sistemas de Inventarios (Investigación de Operaciones) 5. Diseño lógico del Sistema de Inventarios para su automatización. 6. Desarrollo de Software del Sistema de Inventarios. 7. Pruebas del Sistema de Inventarios con datos históricos. 8. Implementación del Sistema de Inventarios. 9. Documentación del Sistema (manuales, diccionario de datos, etc.).
1. 50 hrs/hombre 2. 200 hrs/hombre 3. 40 hrs/hombre 4. 40 hrs/hombre 5. 200 hrs/hombre 6. 200 hrs/hombre 7. 30 hrs/hombre 8. 10 hrs/hombre 9. 40 hrs/hombre La ejecución de las actividades requiere los siguientes suministros: - Material de escritorio - Material de impresión - Fotocopias - Textos, otros..
- Registro de documentos - Documentos de proyectos realizados. - Registro de perfiles corregidos. - Material Bibliográfico respecto al tema. - Registro de los autores del proyecto y asesores. -Registros en medios magnéticos. - Cuestionario a los usuarios directos que operan el sistema. - Registros de pruebas a los usuarios directos.
El personal de las diferentes unidades involucradas proporciona información necesaria para el desarrollo del sistema. Resultados del Análisis de Factibilidad. Factibilidad técnica Factibilidad económica.
la empresa.
ANEXO B Modelo relacional de APESIV
1
N
1
N
1
N
Registra
1
N
Da
N
1
N
1
1
N
Ingresa
1
1
Otorga
1
N
1
N
1
N
1
1
1
1
1Registra
N
1
1
1
1
1
11
N
N
Registra
Registra Otorga
Registra
Da
Adquiere
Recibe
Contiene
Otorga
Entrega
Adquiere
Proporciona
Saldo_sucursal
TipoCliente Cliente
Facturación
Personal
Devolución
Transferencia
Articulo
VentaArticulo
Artprecios
Sucursal
CompraArticulo
Proveedor
ANEXO C
Tabla 4.1.10.b. Matriz de Datos para promedios móviles.