Uladech Biblioteca Virtual Invetnatrio

UNIVERSIDAD LOS ÁNGELES DE CHIMBOTE
FACULTAD DE INGENIERÍA
ESCUELA PROFESIONAL DE INGENIERÍA DE
SISTEMAS
Sistema Informático De Control De Inventario De Materias

Primas Utilizando Arquitectura Cliente/Servidor Para La
Empresa Productos Kerry’s SRL
Presentado por:
Bachiller JESÚS ANTONIO CÁRDENAS OSCATA

Bachiller ROGER SANCA BALBÍN
Asesor:
Ingeniero WILLIAM VÁSQUEZ VARGAS
Tesis Para Optar El Título De Ingeniero De Sistemas
CHIMBOTE – PERÚ
2007
Sistema Informático de Control de Inventario de Materias Primas
UNIVERSIDAD LOS ÁNGELES DE CHIMBOTE

FACULTAD DE INGENIERÍA
ESCUELA PROFESIONAL DE INGENIERÍA DE
SISTEMAS
Sistema Informático De Control De Inventario De Materias

Primas Utilizando Arquitectura Cliente/Servidor Para La
Empresa Productos Kerry’s S.R.L.
JURADO CALIFICADOR
Ing. William Vásquez Vargas Ing. Bogar Mantilla Gordillo

Presidente Secretario
Ing. Oscar Ascón Valdivieso

Vocal
CHIMBOTE – PERÚ
2007
2
DEDICATORIA
Este trabajo va dedicado a mis padres

por el apoyo constante a lo largo de
mi carrera y de mi formación personal.
Ingº Jesús Antonio Cárdenas Oscata.
La vida nos enseña en el camino lo

que es más importante para nosotros,
es por ello que dedico este trabajo a
mis padres por su invalorable apoyo a
lo largo de mi carrera.
Ingº Roger Sanca Balbín.
3
AGRADECIMIENTO
A la Universidad Los Ángeles de

Chimbote por brindarnos la oportunidad
de obtener nuestro título, y al Ing°.
William Vásquez Vargas, por la
capacitación, comprensión y apoyo
incesante durante la elaboración de este
trabajo.
Jesús Cárdenas – Roger Sanca.
4
PRESENTACIÓN
SEÑORES MIEMBROS DEL JURADO
Nos presentamos ante ustedes con la finalidad de cumplir con lo dispuesto en el

reglamento de grados y títulos de la Universidad “Los Ángeles de Chimbote”, escuela
profesional de Ingeniería de Sistemas, ponemos a su disposición el presente trabajo
de tesis titulado “Sistema Informático De Control De Inventario De Materias Primas
Utilizando Arquitectura Cliente/Servidor Para La Empresa Productos Kerry’s S.R.L.”
con el propósito de obtener el título de Ingeniero de Sistemas.
Consideramos oportuno agradecer de manera anticipada las apreciaciones y

sugerencias que merezca el presente trabajo por constituirse en un aporte en pro de
nuestra formación profesional.
Chimbote, Setiembre 2007.
5
RESUMEN
SISTEMA INFORMÁTICO DE CONTROL DE INVENTARIO DE MATERIAS PRIMAS

UTILIZANDO ARQUITECTURA CLIENTE/SERVIDOR PARA LA EMPRESA
PRODUCTOS KERRY’S S.R.L.
El presente Trabajo muestra el análisis y desarrollo del prototipo de un sistema

informático para el Control de Inventario de Materias Primas en la empresa Productos
Kerry’s S.R.L., el cual permitirá tener un mejor control de los movimientos de los
artículos de Materia Prima tanto en ingresos y salidas en Almacén. Para efectos de su
desarrollo se ha hecho uso de los flujos de trabajo como el Análisis de
Requerimientos, Modelado del Negocio y Análisis UML utilizando el Power Designer,
para el desarrollo de la aplicación se utilizó el lenguaje de Programación Microsoft
Visual Basic 6.0 y Microsoft SQL Server 2000 como administrador de Base de Datos.
Capítulo I.- Describe la realidad problemática de la empresa, Antecedentes,

Justificación, así como los Objetivos trazados y formulación de la Hipótesis.
Capítulo II.- Para el mejor entendimiento y comprensión se ha adicionado algunos

conceptos básicos referentes a:
- Conceptos básicos de Almacén y su función e importancia de tener controlado.
- Conceptos de Requerimientos, Análisis y Desarrollo de Sistema utilizado en el
presente trabajo (UML Lenguaje Unificado de Modelado, Microsoft Visual Basic
6.0, Power Designer y SQL Server 2000).
Capítulo III.- Este capítulo abarca todo lo concerniente al requerimiento, análisis,

modelado del negocio, diagramas de caso de uso, diagramas de secuencia,
diagramas de clases, modelo entidad-relación, generación de los scripts y diseño de
pantallas del sistema.
Capítulo IV.- En este capítulo se realiza la contrastación de la Hipótesis y se acota las

conclusiones y recomendaciones pertinentes.
6
ABSTRACT
COMPUTER SYSTEM CONTROL OF INVENTORY OF RAW MATERIALS USED

ARCHITECTURE CLIENT / SERVER FOR THE COMPANY'S PRODUCTOS
KERRY’S S.R.L.
The present Work shows to the analysis and development of the prototype of a
computer science system for the Control of Inventory of Raw materials in the company
Productos Kerry's limited liability company., who will allow to as much have a better
control of the movements of articles of Raw material in income and exits in Warehouse.
For effects of its development use has become of the job streams like the Analysis of
Requirements, Modeled of the Business and Analysis UML using the Power Designer,
for the development of the application the Visual programming language 6,0 Microsoft
BASIC and Microsoft SQL Server 2000 was used as database administrator
Chapter I.- It describes the problematic reality of the company, Antecedents,

Justification, as well as the Objectives drawn up and formulation of the Hypothesis.
Chapter II.- For the best understanding and understanding one has added some
referring basic concepts a:
- Basic Concepts of Warehouse and their function and importance of having

controlled.
- Concepts of Requirements, Analysis and Development of System used in the
present work (UML Language Unified of Modeled, Microsoft Visual BASIC 6,0,
Power Designer and SQL Server 2000).
Chapter III.- This chapter includes all concerning the requirement, the analysis,
modeled of the business, diagrams of case of use, diagrams of sequence, diagrams of
classes, model organization-relation, generation of scripts and design of screens of the
system.
Chapter IV.- In this chapter the contrast of the Hypothesis is made and it limits the
pertinent conclusions and recommendations.
7
INDICE CONTENIDOS
Pág.
DEDICATORIA.............................................................................................................. I
AGRADECIMIENTO..................................................................................................... II
PRESENTACIÓN ........................................................................................................ III
RESUMEN ..................................................................................................................IV
ABSTRACT ..................................................................................................................V
ÍNDICE DE CONTENIDOS .........................................................................................VI
ÍNDICE DE CUADROS ...............................................................................................VI
ÍNDICE DE GRÁFICOS .............................................................................................VII
CAPÍTULO I: PLAN DE INVESTIGACIÓN

1.1 Introducción ......................................................................................................... 02
1.1.1 Antecedentes del problema................................................................... 03
1.1.2 Realidad problemática .......................................................................... 04
1.1.3 Justificación .......................................................................................... 04
1.1.4 Aspecto tecnológico .............................................................................. 05
1.1.5 Aspecto económico ............................................................................... 05
1.1.6 Aspecto operativo ................................................................................. 05
1.2 Formulación ........................................................................................................ 06
1.3 Objetivos ............................................................................................................. 06
1.3.1 Objetivo general .................................................................................... 06
1.3.2 Objetivos específico .............................................................................. 06
1.4 Hipótesis ............................................................................................................. 06
1.4.1 Variables ............................................................................................... 07
CAPÍTULO II: FUNDAMENTO TEÓRICO

2.1 Almacén .............................................................................................................. 09
2.1.1 Conceptos de almacén ......................................................................... 09
2.1.2 Función de los almacenes..................................................................... 09
2.1.3 Función de las existencias .................................................................... 09
2.1.4 Equipos de almacén.............................................................................. 10
8
2.1.5 Función de recepción ............................................................................ 10

2.1.5.1 Importancia ............................................................................. 10
2.1.5.2 Proceso .................................................................................. 10
2.1.6 Técnicas de Almacenamiento de Materiales ......................................... 11
2.1.7 Inventario Físico .................................................................................... 11
2.1.8 Costo de almacenamiento..................................................................... 12
2.1.8.1 Costo directo de almacenamiento ........................................... 13
2.1.8.2 Costo directo de manutención ................................................ 14
2.1.8.3 Costos indirectos de almacenaje ............................................ 14
2.1.9 Operaciones en almacenaje .................................................................. 14
2.1.9.1 Operaciones de entrada ..................................................................... 14
2.1.9.2 Operaciones de salida........................................................................ 15
2.1.9.2.1 Extracción ........................................................................... 15
2.1.9.2.2 Entrada Salida ..................................................................... 16
2.1.9.3 Operaciones de Control ..................................................................... 16
2.1.10 Los Stocks .......................................................................................... 17
2.1.10.1 Clasificación de Stocks ......................................................... 17
2.1.10.1.1 Según la Duración de vida del producto tenemos ... 17
2.2 Información ......................................................................................................... 18
2.3 Sistema ............................................................................................................... 18
2.4 Sistema de información ....................................................................................... 19
2.5 Lenguaje Unificado de Modelo UML .................................................................... 19
2.5.1 Bloques básicos de construcción de UML ............................................. 19
25.1.1 Elementos ............................................................................................. 21
2.5.1.2 Relaciones ............................................................................................ 23
2.5.1.3 Diagramas ............................................................................................. 24
2.5.1.3.1 Diagrama de Clases y Diagrama de Objetos ............ 27
2.5.1.3.2 Diagrama de Componentes y de Despliegue ............ 30
2.5.1.3.3 Diagrama de Casos de Uso ...................................... 32
2.5.1.3.4 Diagrama de Secuencia y de Colaboración .............. 34
2.5.1.3.5 Diagrama de Estados y Diagrama de Actividades .... 37
2.5.2 Cómo utilizar UML................................................................................. 40
2.6 Microsoft Visual Basic ......................................................................................... 44
2.6.1 Características generales...................................................................... 44
2.6.2.- Ventajas e inconvenientes ................................................................... 46
2.7.- SQL SERVER 2000 .......................................................................................... 48
9
2.8.- Power Designer................................................................................................. 50

2.8.1.- Beneficios De PowerDesigner............................................................ 50
2.9.- Programación Orientada a Objeto ..................................................................... 52
2.9.1.- Introducción ....................................................................................... 52
2.9.2.- Origen ................................................................................................ 53
2.9.3.- Conceptos Fundamentales ................................................................ 55
2.9.4.- Características de la POO ................................................................. 56
CAPÍTULO III: RESULTADOS
3.1.- Descripción de la Organización ......................................................................... 59

3.1.1.- Reseña Histórica................................................................................. 59
3.1.2.- Eficiencia horizontal ............................................................................ 60
3.1.3.- Controles al mínimo ............................................................................ 60
3.1.4.- Capacitación y limpieza ...................................................................... 61
3.1.5.- Misión .................................................................................................. 62
3.1.6.- Visión .................................................................................................. 62
3.1.7.- Canales De Venta ............................................................................... 62
3.1.8.- Datos De La Empresa. ........................................................................ 62
3.1.9.- Estructura Organizacional ................................................................... 63
3.2.- Modelo De Base De Datos ................................................................................. 65
3.2.1.- Fase Inicial.......................................................................................... 65
3.2.2.- Modelado Del Negocio ........................................................................ 65
3.2.2.1.- Regla Del Negocio ................................................................ 65
3.2.2.2.- Modelo de Procesos de Negocio .......................................... 66
3.2.3.- Identificación De Los Actores Y Entidades De La Organización .......... 67
3.2.4.- Modelo De Casos De Uso General ..................................................... 68
3.2.4.1.- Especificaciones de casos de Uso General .......................... 69
3.2.5.- Caso De Uso Entrega De Materiales .................................................. 71
3.2.6.- Caso De Uso Ingreso De Materiales ................................................... 72
3.2.7.- Caso De Uso Realizar Proceso ERI .................................................... 73
3.2.8.- Diagrama de secuencias..................................................................... 74
3.2.8.1.- Diagrama de secuencia General........................................... 74
3.2.8.2.- Diagrama de Secuencia Ingreso de Materiales..................... 75
10
3.2.8.3.- Diagrama de secuencia Entrega de Materiales ..................... 76

3.2.8.4.- Diagrama de secuencia de exactitud de registros de inventario
............................................................................................................ 77
3.3.- Diseño de interfase del sistema......................................................................... 78
3.3.1.- Ventana de acceso ............................................................................. 78
3.3.2.- Menú principal .................................................................................... 78
3.3.3.- Menú Movimientos .............................................................................. 79
3.3.4.- Menú Mantenimiento........................................................................... 79
3.3.5.- Menú Consultas .................................................................................. 80
3.3.6.- Menú Reportes ................................................................................... 80
3.3.7.- Menú Herramienta .............................................................................. 81
3.3.8.- Ventana de registro de Ingresos de Materia Prima ............................. 81
3.3.9.- Guía de ingreso por compra ............................................................... 82
3.3.10.- Ventana de registro de Egresos de Materia Prima ............................ 82
3.3.11.- Guía de egreso por compra .............................................................. 83
3.3.12.- Listado para el registro de Inventario Físico ...................................... 83
3.3.13.- Ventana de Registro de Exactitud de Inventarios .............................. 84
3.3.14.- Reporte de Registro de Exactitud de Inventarios .............................. 85
3.3.15.- Registro de Proveedor ...................................................................... 85
3.3.16.- Matriz Producto Proveedor................................................................ 86
3.3.17.- Ventana de Clasificación de Producto............................................... 86
3.3.18.- Ventana de relación Área y Productos .............................................. 87
3.3.19.- Consulta de Stock de Productos ....................................................... 87
3.3.20.- Consulta de Precios de Productos por Proveedor ............................. 88
3.4.- Reportes ........................................................................................................... 89
3.4.1.- Reporte de los Movimientos realizados en el Almacén ....................... 89
3.4.2.- Reporte General de los Movimientos realizados en el Almacén. ......... 89
3.4.3.- Cierre de Inventario ............................................................................ 90
3.5.- Diagrama de Clases .......................................................................................... 91
3.6.- Diagrama Entidad Relación ............................................................................... 92
3.7.- Diagrama de Componentes............................................................................... 93
3.8.- Diagrama de Despliegue ................................................................................... 94
3.9.- Script Para La Generación Del Modelo De Datos .............................................. 95
CAPÍTULO IV: DISCUSIÓN

Contrastación De La Hipótesis ................................................................................. 105
11
Conclusión de la discusión ....................................................................................... 105
CONCLUSIONES .................................................................................................... 106

RECOMENDACIONES ............................................................................................ 107
REFERENCIAS BIBLIOGRÁFICAS ......................................................................... 108
ANEXOS .................................................................................................................. 110
12
ÍNDICE DE TABLAS
Pág.
Tabla 2.1: Elementos de construcción en UML .......................................................... 23

Tabla 2.2: Elementos de relación en UML .................................................................. 24
Tabla 2.3: Diagramas de UML .................................................................................... 27
Tabla 2.4: Multiplicidad en Diagramas de Clases ....................................................... 28
Tabla 2.5: Tipos de mensaje en diagramas de interacción ......................................... 37
Tabla 3.1: Identificación de Actores y Entidades ....................................................... 67
Tabla.3.2 Especificaciones de casos de Uso General – Entrega de materiales.......... 69
Tabla 3.3. Especificaciones de casos de Uso General – Entrega de materiales ......... 69
Tabla 3.4 Especificaciones de casos de Uso General – Entrega de materiales.......... 69
Tabla 3.7 Especificaciones de casos de Uso General – Entrega de materiales ......... 70
Tabla A1: Cronograma de Trabajo .......................................................................... 112
Tabla A2: Presupuesto ............................................................................................. 114
Tabla A3: Cuadro de Beneficio Costo ............................................................ 115
Tabla A4: Arquitectura Preliminar del Sistema ........................................................ 116
13
ÍNDICE DE GRÁFICOS
Pág.
Figura 2.1: Diagrama de Clases ................................................................................. 23

Figura 2.2: Relación de dependencia en Diagramas de Clase ................................... 29
Figura 2.3: Auto-agregación ....................................................................................... 30
Figura 2.4: Diagrama de Componentes ...................................................................... 31
Figura 2.5: Diagrama de Despliegue .......................................................................... 31
Figura 2.6: Diagrama de Casos de Uso nivel 1 .......................................................... 32
Figura 2.7: Diagrama Casos de Uso nivel 2 A ............................................................ 33
Figura 2.8: Diagrama Casos de Uso nivel 2 B ............................................................ 33
Figura 2.9: Diagrama Casos de Uso nivel 1 detallado ................................................ 34
Figura 2.10: Diagrama de Secuencia ......................................................................... 35
Figura 2.11: Diagrama de Colaboración ..................................................................... 37
Figura 2.12: Máquina de Estados, estados simples.................................................... 38
Figura 2.13: Máquina de Estados, estados compuestos ............................................ 39
Figura 2.14: Diagrama de Actividades ........................................................................ 40
Figura 3.1: Estructura Organizacional ........................................................................ 64
Figura 3.2: Modelo de Procesos de Negocio ............................................................. 66
Figura 3.3: Modelo De Casos De Uso General........................................................... 68
Figura 3.4: Caso De Uso Entrega De Materiales ....................................................... 71
Figura 3.5 Caso De Uso Ingreso De Materiales ........................................................ 72
Figura 3.6 Caso De Uso Realizar Proceso ERI ......................................................... 73
Figura 3.7: Diagrama de secuencia General ............................................................. 74
Figura3.8: Diagrama de Secuencia Ingreso de Materiales ........................................ 75
Figura 3.9: Diagrama de secuencia Entrega de Materiales ....................................... 76
Figura 3.10: Diagrama de secuencia de exactitud de registros de inventario ............. 77
Figura 3.11: Ventana de acceso ................................................................................. 78
Figura 3.12: Menú principal ....................................................................................... 78
Figura 3.13: Menú Movimientos ................................................................................ 79
Figura 3.14: Menú Mantenimiento ............................................................................. 79
Figura 3.15: Menú Consultas .................................................................................... 80
Figura 3.16: Menú Reportes ...................................................................................... 81
14
Figura 3.17: Menú Herramienta ................................................................................. 81

Figura 3.18: Ventana de registro de Ingresos de Materia Prima ................................ 81
Figura 3.19: Guía de ingreso por compra .................................................................. 82
Figura 3.20: Ventana de registro de Egresos de Materia Prima ................................. 82
Figura 3.21: Guía de egreso por compra ................................................................... 83
Figura 3.22: Listado para el registro de Inventario Físico .......................................... 83
Figura 3.23: Ventana de Registro de Exactitud de Inventarios .................................. 84
Figura 3.24: Reporte de Registro de Exactitud de Inventarios .................................... 85
Figura 3.25: Registro de Proveedor ........................................................................... 85
Figura 3.26: Matriz Producto Proveedor .................................................................... 86
Figura 3.27: Ventana de Clasificación de Producto ................................................... 86
Figura 3.28: Ventana de relación Área y Productos................................................... 87
Figura 3.29: Consulta de Stock de Productos............................................................ 87
Figura 3.30: Consulta de Precios de Productos por Proveedor ................................. 88
Figura 3.31: Reporte de los Movimientos realizados en el Almacén .......................... 89
Figura 3.32: Reporte General de los Movimientos realizados en el Almacén ............ 89
Figura 3.33: Cierre de Inventario ............................................................................... 90
Figura 3.34: Diagrama de Clases .............................................................................. 91
Figura 3.35: Diagrama Entidad Relación ................................................................... 92
Figura 3.36: Diagrama de Componentes ................................................................... 93
Figura 3.37: Diagrama de Despliegue ....................................................................... 94
15
CAPÍTULO I
PLAN DE INVESTIGACIÓN
16
1.1.- INTRODUCCIÓN
La empresa Productos Kerry’s S.R.L. debido a su crecimiento tiene como finalidad

ordenar sus procesos y en adelante optimizarlos para así reducir el costo de
producción y ofrecer productos de calidad.
Actualmente las empresas necesitan controlar sus procesos para ello necesitan
apoyarse de un sistema informático que le permita realizar controles y así obtener la
información fiable y tomar decisiones correctas.
El sistema ha desarrollar servirá como herramienta donde realizarán los registros de

los movimientos en el almacén y realizar consultas de información de una manera
práctica, sencilla de obtener reportes y realizar consulta detallada de los movimientos
realizados en el almacén. Y también poder realizar verificación de la exactitud de
registros de inventarios.
El sistema tendrá diversas opciones que permitan obtener la información necesaria

mediante consultas y reportes accediendo a la Base de Datos de la Empresa
Productos Kerry’s S.R.L. ya que esta información apoyará a la toma de decisiones.
17
1.1.1.- ANTECEDENTES DEL PROBLEMA
Existen empresas que cada vez están mejorando sus procesos y estableciendo
controles con apoyo de las tecnologías de la información, todo esto surge para ser
cada vez más competitivos y contar con la información más rápido para evaluar y
tomar decisiones.
Actualmente en el mercado existen diferentes paquetes de software y

versiones para el control de Inventarios.
En productos KERRY’S S.R.L. se evaluaron los diferentes software que existen

en el mercado pero ninguno se adecuaba a la realidad del negocio, así que se
consideró desarrollar un software a medida que pueda controlar los inventarios.
La motivación para desarrollar este proyecto surgió de los problemas

detectados dentro de la Empresa Productos KERRY’S S.R.L., la cual ha tenido
momentos difíciles para controlar los stocks de insumos en su almacén central debido
al desabastecimiento repentino de sus inventarios por no estimar las compras
efectivas de acuerdo a lo solicitado en la producción. A través de la mejora de
procedimientos operativos, la empresa había mejorado notoriamente, pero se
necesitaba contar con una herramienta de software a medida que pueda afianzar y de
esta manera controlar de manera eficiente las existencias de insumos.
Teniendo en cuenta esta situación, la compañía requería de la implementación

de políticas de inventarios, con el fin de no solo mejorar los niveles de producto
almacenado de la empresa, sino disminuir los altos costos, que hoy en día representan
para la empresa, el mantener producto almacenado.
18
1.1.2.- REALIDAD PROBLEMÁTICA
Productos KERRY’S S.R.L. Viene desempeñando sus actividades en la ciudad

de Lima, elaborando productos alimenticios de panificación, para ello cuenta con una
planta de producción que le ayuda a cumplir sus objetivos organizacionales. Las
principales dificultades en el desarrollo de sus actividades radican en que se tiene un
inadecuado control de sus inventarios de materias prima, llevándose estos de manera
manual carente de un sistema informático.
Almacén de materias primas, área encargada del control de los inventarios,

que tiene como objetivo acopiar y abastecer de los mismos a la producción, que se
encuentra en continuo proceso, ya que requiere de materia prima disponible para la
elaboración de sus productos, la falta de alguno de los insumos paralizaría el proceso
de la producción ocasionando pérdidas económicas. Las ordenes de compra de los
insumos se realizan de forma empírica basado en la experiencia que tiene el
encargado para poder abastecer la demanda de la producción, además de no contar
con información actual de sus stock disponible que son conformado por más de 1000
items, todo ello se da porque no cuentan con un sistema informático donde puedan
realizar registros fehacientes de los ingresos y salidas de los insumos.
El área de administración como responsable del control de los inventarios, no

puede cumplir sus funciones por falta de un sistema informático que responda a las
necesidades actuales y estar a la vanguardia de las tecnologías de información.
1.1.3.- JUSTIFICACIÓN
De acuerdo a la competitividad creciente y desarrollo en tecnología de

procesos y de gestión el Sistema propuesto cumple con todos los requerimientos y
necesidades de los usuarios finales, ya que se presenta como una herramienta
innovadora capaz de controlar los inventarios con registros fehacientes y de mejorar el
desempeño de sus actividades, ya que contará con los aspectos técnicos como
19
seguridad, interfaz gráfica amigable, multiusuario que proporciona información clara,

concisa y veraz.
1.1.4.- ASPECTO TECNOLÓGICO.
Brindará a la empresa Productos Kerry’s S.R.L. un soporte de información

adecuado para el desarrollo de su proceso de control de sus existencias mediante un
modelo tecnológico de alto nivel.
El desarrollo de un sistema informático robusto y confiable, amigable y con

arquitectura Cliente Servidor, permitirá acelerar los tiempos de procesamiento y,
además que será de soporte en la toma de decisiones e implementación de nuevas
estrategias maximizando el uso de los recursos y reduciendo los costos operativos.
1.1.5.- ASPECTO ECONOMICO.
Permitirá reducir el costo / hora del recurso humano, debido a la reducción del
tiempo en los procesos de control de los insumos mediante un sistema de información
rápido y confiable.
Proporcionará a la empresa Productos Kerry’s S.R.L. aumentar sus utilidades,

tomando decisiones correctas al efectuar compras oportunas y abastecer a la
producción sin paralizarla.
1.1.6.- ASPECTO OPERATIVO
Permitirá registrar los movimientos de ingresos y salidas de materia prima de

una manera sencilla y práctica con la finalidad de que se pueda acceder en cualquier
momento a dicha información, obtener reportes y realizar consultas en el menor
tiempo posible.
Permitirá reducir los errores de cálculos y obtener datos confiables.

20
1.2.- FORMULACIÓN
¿Cómo el desarrollo del Sistema informático de control de inventario de

materias primas va a ayudar a la gestión administrativa?
1.3.- OBJETIVOS.
1.3.1.- Objetivo General.

Desarrollar un Sistema Informático de Control de inventario de Materias
Primas para ayudar a la gestión administrativa en la Empresa Productos
Kerry’s S.R.L.
1.3.2.- Objetivos Específico.

 Levantar información del área en estudio
 Elaborar los diferentes diagramas involucrados utilizando como
herramienta el Lenguaje Unificado de Modelado en el desarrollo del
Sistema Informático.
 Diseñar y diagramar el Modelo Relacional de la Base de Datos.
 Desarrollar un Sistema Informático que integre las herramientas
Visual Basic 6.0, Crystal Reports y Microsoft SQL Server 2000.
1.4.- HIPÓTESIS
El desarrollo de un Sistema informático permite mejorar y controlar de manera

adecuada el almacén de materias primas en la Empresa Productos Kerry’s S.R.L.
21
1.4.1.- VARIABLES
Variable Independiente
Desarrollo de un sistema informático
Indicadores
 Funcionalidad
 Capacidad de Respuesta
Variable Dependiente
Mejor Control del almacén de materias primas
Indicadores
 Intercambio de información
 Facilidad de operar
 Comprensibilidad
Variable Interviniente
Metodología Objetos
22
CAPÍTULO II
FUNDAMENTO TEÓRICO
23
2.1.- ALMACÉN
2.1.1.- Conceptos Básicos
Son aquellos lugares donde se guardan los diferentes tipos de

mercancía.
La formulación de una política de inventario para un departamento de

almacén depende de la información respecto a tiempos de adelantes,
disponibilidades de materiales, tendencias en los precios y materiales de
compras, es la fuente mejor de esta información.
Esta función controla físicamente y mantiene todos los artículos

inventariados, se deben establecer resguardo físicos adecuados para proteger
los artículos de algún daño de uso innecesario debido a procedimientos de
rotación de inventarios defectuosos de rotación de inventarios defectuosos y a
robos. Los registros de deben mantener, lo cual facilitan la localización
inmediata de los artículos.
2.1.2.- Función de los Almacenes:
1. Mantienen las materias primas a cubierto de incendios, robos y

deterioros.
2. Permitir a las personas autorizadas el acceso a las materias
almacenadas.
3. Mantienen en constante información al departamento de compras,
sobre las existencias reales de materia prima.
4. Lleva en forma minuciosa controles sobre las materias primas (entradas
y salidas).
5. Vigila que no se agoten los materiales (máximos – mínimos).
2.1.3.- Función de las Existencias:
Garantizar el abastecimiento e inválida los efectos de:
1. Retraso en el abastecimiento de materiales.

2. Abastecimiento parcial
24
3. Compra o producción en totales económicos.

4. Rapidez y eficacia en atención a las necesidades.
2.1.4.- Equipos de Almacén
Estrategias y cajas o casilleros:
Puede aumentar mucho la eficiencia total y la flexibilidad de los

procedimientos que emplea el almacenamiento mediante el uso de un
equipo adecuado. En algunas compañías, el departamento de
conservación constituye las estanterías, los casilleros, compartimiento,
entre otros, que se hacen con madera ordinaria y contra enchapadas.
Sin embargo, las estanterías de acero se han hecho ya, de uso general
que las de madera y pueden comprarse a los fabricantes especializados
del ramo en una gran variedad de modelos y tamaños.
2.1.5.-Función de Recepción:
La función de recepción, ya sea de una unidad de la compañía o

de un transportador común, es la misma. Si el material se recibe de
cualquier otra fuente u otro departamento de la compañía, las
actividades de construcción, el procedimiento será el mismo.
2.1.5.1.- Importancia:
La recepción adecuada de materiales y de otros artículos

es de vital importancia, ya que una gran parte de las empresas
tienen como resultado de su experiencia centralizada la
recepción total bajo un departamento único, las excepciones
principales son aquellos grandes empresas con plantas
múltiples. La recepción esta estrechamente ligada a la compra,
ya que probablemente el 70% de los casos, el departamento
bajo la responsabilidad del departamento de compra.
2.1.5.2.- Proceso
1. Al recibir un envió: Se le someterá a verificación para

comprobar si esta en orden y en buenas condiciones, si el
25
recipiente esta dañado o no se recibió el numero de

paquetes requeridos. Se debe hacer la salvedad
correspondiente inmediatamente y no se podrá dar recibo de
conformidad por el envió, esto es esencial sin tomar en
cuenta si el transporte es aéreo, marítimo o terrestre, como
se podría exigir para dar fuerza a cualquier reclamo
resultante sobre envíos ocultos.
2. De Manera Similar: El material que recibe una instalación de
la compañía también debe ser sometido a una inspección
preliminar, antes de introducirles en el área de
almacenamiento, en el caso de que en la inspección inicial
se detecte materiales de calidad inferiores o en malas
condiciones se le debe rechazar.
2.1.6.- Técnicas de Almacenamiento de Materiales
El almacenamiento de materiales depende de la dimensión y

características de los materiales. Estos pueden exigir una simple
estantería hasta sistemas complicados, que involucran grandes
inversiones y complejas tecnologías. La elección del sistema de
almacenamiento de materiales depende de los siguientes factores:
1. Espacio disponible para el almacenamiento de los materiales.

2. Tipos de materiales que serán almacenados.
3. Tipos de materiales que serán almacenados.
4. Numero de artículos guardados.
5. Velocidad de atención necesaria.
6. Tipo de embalaje.
2.1.7.- Inventario Físico
Se da el nombre de inventario de mercancía a la verificación o

confirmación de la existencia de los materiales o bienes patrimoniales
de la empresa. En realidad, el inventario es una estadística física o
conteo de los materiales existentes, para confrontarla con la existencia
anotadas en los ficheros de existencias o en el banco de datos sobre
materiales.
26
Algunas empresas le dan el nombre de inventario físico porque

se trata de una estadística física o palpable de aquellos que hay en
existencias en la empresa y para diferenciarlos de la existencia
registradas.
El inventario físico se efectúa periódicamente, casi siempre en el

cierre del periodo fiscal de la empresa, para efecto de balance contable.
En esa ocasión, el inventario se hace en toda la empresa; en la bodega,
el las secciones, en el deposito, entre otras. El inventario físico es
importante por las siguientes razones:
1. Permite verificar las diferencias entre los registros de existencias

y las existencias físicas (cantidad real en existencia).
2. Permite verificar las diferencias entre las existencias físicas
contables, en valores monetarios.
3. Proporciona la aproximación del valor total de las existencias
(contables), para efectos de balances, cuando el inventario se
realiza próximo al cierre del ejercicio fiscal.
La necesidad del inventario físico se fundamenta en dos razones:
1. El inventario físico cumple con las exigencias fiscales, pues deben

ser transcrito en el libro de inventario, conforme la legislación.
2. El inventario físico satisface la necesidad contable, para verificar, en
realidad, la existencia del material y la aproximación del consumo
real.
2.1.8.- Costos de almacenamiento.

Los costos de almacenamiento, de mantenimiento o de posesión del
Stock, incluyen todos los costos directamente relacionados con la titularidad de
los inventarios tales como:
 Costos Financieros de las existencias

 Gastos del Almacén
 Seguros
27
 Deterioros, pérdidas y degradación de mercancía.
Dependen de la actividad de almacenaje, este gestionado por la

empresa o no, o de que la mercadería este almacenada en régimen de
deposito por parte del proveedor o de que sean propiedad del fabricante.
Para dejar constancia de esta complejidad, se incluye seguidamente

una relación pormenorizado de los Costos de almacenamiento, mantenimiento
o posesión de los stocks en el caso más general posible. No obstante, más
adelante se expondrá un método simplificado para calcular estos costos (la
tasa anual "ad valorem") que se utiliza con mucha frecuencia.
La clasificación de los costos de almacenamiento que seguidamente se

incluye los clasifica por actividad (almacenaje y manutención), por
imputabilidad (fija y variable) y por origen directo e indirecto.
2.1.8.1.- Costos Directos De Almacenaje
Costos Fijos
 Personal
 Vigilancia y Seguridad
 Cargas Fiscales
 Mantenimiento del Almacén
 Reparaciones del Almacén
 Alquileres
 Amortización del Almacén
 Amortización de estanterías y otros equipos de
almacenaje
 Gastos financieros de inmovilización
Costos Variables
 Energía
 Agua
 Mantenimiento de Estanterías
28
 Materiales de reposición
 Reparaciones ( relacionadas con almacenaje )
 Deterioros, pérdidas y degradación de mercancías.
 Gastos Financieros de Stock.
2.1.8.2.- Costos Directos De Manutención
Costos Fijos
 Personal
 Seguros
 Amortización de equipos de manutención
 Amortización de equipos informáticos
 Gastos financieros del inmovilizado
Costos Variables
 Energía
 Mantenimiento de equipo de manutención
 Mantenimiento de equipo informático
 Reparaciones de equipos de manutención
 Comunicaciones.
2.1.8.3.- Costos Indirectos De Almacenaje

 De administración y estructura
 De formación y entrenamiento del personal
2.1.9.- Operaciones En El Almacén
2.1.9.1.- Operaciones de entrada.
Lo primero que hay que hacer cuando entran productos es

identificar el origen y destino para comprobar que no es un error.
Seguidamente se identifica el envío para descargarlo por la zona
adecuada.
Ahora ya esta todo preparado para descargar la mercancía. Se

avisa al personal cual será la ubicación de destino, “la playa” de
29
descarga, el área de devoluciones, zona de preparación de envíos, o el

área de cuarentena, como por ejemplo, las cámaras frigoríficas en los
almacenes de naranjas.
Durante la descarga hay que hacer una comprobación o

recepción externa del género (lo que esté dañado externamente tiene
que ser devuelto, pudiendo descargarlo o no, según el acuerdo
establecido).
Una vez finalizada esta fase se firma la documentación del

transportista dándole las copias correspondientes. A partir de este
momento el transportista puede abandonar la instalación.
Seguidamente se comprueba la carga (cantidad y calidad) y se

separan las mercancías aceptadas, devueltas y las pendientes de algún
control. Las aceptadas (normalmente con una etiqueta verde) tienen
que ser almacenadas, por lo que hay que buscarle la ubicación más
idónea para su peso forma y dimensión.
Finalmente debemos introducir la información sobre la actividad

realizada en el sistema informático con las características que se hayan
podido dar (incidencias o errores).
2.1.9.2.- Operaciones de salida.
Igual que en el apartado anterior, analizaremos las diferentes

fases de las operaciones de salida del almacén:
2.1.9.2.1.- Extracción.
La extracción de mercancías para finalmente enviarlas al

cliente se puede hacer de dos maneras
- Extraer los productos en las unidades logísticas

especializadas.
- Extraer unidades sueltas (picking). Suele ser más

habitual mientras más nos acercamos al consumidor o
30
usuario. Es decir, el producto suele entrar en pocos

envíos de mucha cantidad, y sale en muchos de poca.
2.1.9.2.2.- Entrada Salida
Por último e igual como ocurre en la entrada del género,

toda actividad tiene que ser introducida en el sistema
informático. Ahora sólo nos quedará embalar, pesar, etiquetar y
expedir.
2.1.9.3.- Operaciones de control.
Recuentos físicos: el inventario.
El inventario es la lista dónde se inscriben y describen,

articulo por artículo, todos los bienes que pertenecen a una
persona o están en una casa. Hablando en términos contables,
es la relación y valoración de los bienes, derechos y obligaciones
de una empresa, que expresa la estructura de su patrimonio en
un momento dado. Podemos hablar de dos casos de inventarios:
- contable: estado de cuentas que permiten conocer,

durante todo el periodo de explotación, las existencias en
stock.
- extracontable: recuento en el almacén de las

existencias realmente mantenidas en stock.
El procedimiento casi siempre es el mismo:
- Preparación de una orden para cada ubicación.
- Programación de ordenes de recuento y también de

colocación / extracción.
- Incorporación de los resultados al sistema informático.
Entre todos nombramos tres tipos de inventarios:
31
• Completo (normalmente una vez al año)
• Rotativo. Consiste en verificar cada vez unos productos.
• Permanente. Consiste en contar las existencias cada

vez que se da una operación sobre una ubicación.
2.1.10.- Los Stocks.
No podríamos hablar completamente de almacén si no intentáramos

descubrir su esencia, los artículos almacenados, por lo que los siguientes
apartados los dedicaremos única y exclusivamente a esta parte.
Los stocks los podemos definir como los artículos en espera de su

utilización posterior.
La posesión de estos, es la manera que tienen las empresas para garantizar el

buen funcionamiento de su actividad, no solo a la hora de servir a un cliente
sino también para poder tener materias primas con las que fabricar.
Esta necesidad de tener existencias en el almacén, es para disponer del

producto en la cantidad necesaria, en el momento oportuno, con una seguridad
de calidad y un precio más económico
Una pequeña reducción del porcentaje de los stocks significará un gran

aumento de los beneficios
2.1.10.1.- Clasificación de stocks.
2.1.10.1.1.- Según la duración de vida del producto tenemos:
• Los perecederos Ejemplo: alimentos como el pescado

y la carne
• Los no perecederos. Ejemplo: artículos de bisutería,

muebles...
32
• Los que tienen fecha de caducidad marcada.

Ejemplo: lácteos, huevos...
2.2.- Información
En sentido general, la información es un conjunto organizado de datos,

que constituyen un mensaje sobre un determinado ente o fenómeno. De esta
manera, si por ejemplo organizamos datos sobre un país (número de
habitantes, densidad de población, nombre del presidente, etc.) y escribimos
por ejemplo, el capítulo de un libro, podemos decir que ese capítulo constituye
información sobre ese país. Cuando tenemos que resolver un determinado
problema o tenemos que tomar una decisión, empleamos diversas fuentes de
información (como podría ser el capítulo mencionado de este imaginario libro),
y construimos lo que en general se denomina conocimiento o información
organizada que permite la resolución de problemas o la toma de decisiones.
Existe una relación indisoluble entre los datos, la información, el

conocimiento, el pensamiento y el lenguaje, por lo que una mejor comprensión
de los conceptos sobre información redundará en un aumento del
conocimiento, ampliando así las posibilidades del pensamiento humano, que
también emplea el lenguaje -oral, escrito, gesticular, etc.-, y un sistema de
señales y símbolos interrelacionados, siendo así el activo principal de las
empresas y organizaciones, llegando a suponer en la mayoría de los casos su
ventaja competitiva.
2.3.- Sistema
Un sistema es un conjunto de elementos interrelacionados e
interactuantes entre sí. El concepto tiene dos usos muy diferenciados, que se
refieren respectivamente a los sistemas de conceptos y a los objetos reales
más o menos complejos y dotados de organización.
33
2.4.- Sistema de Información
Un sistema de información se define como un conjunto de

procedimientos interrelacionados que forman un todo, es decir, obtiene,
procesa, almacena y distribuye información para apoyar la toma de decisiones
y el control en una organización. Igualmente apoya la coordinación, análisis de
problemas, visualización de aspectos complejos, entre otros aspectos. Los
elementos interactúan entre si con el fin de apoyar las actividades de las
empresas, negocios u organizaciones.
Un sistema de información contiene información de sus procesos y su entorno.
Como actividades básicas producen la información que se necesita: entrada,
procesamiento y salida. La retroalimentación consiste en entradas devueltas
para ser evaluadas y perfeccionadas. Proporciona la información necesaria a la
organización o empresa, donde y cuando se necesita. Tipos: Transaccionales,
de apoyo a las decisiones y estratégicos.
2.5.- El Lenguaje Unificado De Modelado, UML
El UML es un lenguaje de modelado cuyo vocabulario y sintaxis están ideados para la

representación conceptual y física de un sistema. Sus modelos son precisos, no
ambiguos, completos y pueden ser trasladados directamente a una gran variedad de
lenguajes de programación, como Java, C++ o Visual Basic, pero también a tablas de
bases de datos relacionales y orientadas a objetos. Es posible generar código a partir
de un modelo UML (ingeniería directa) y también puede construirse un modelo a partir
de la implementación (ingeniería inversa), aunque en las dos situaciones debe
intervenir un mayor o menor grado de supervisión por parte del programador, en
función de lo buenas que sean las herramientas empleadas.
2.5.1.- Bloques básicos de construcción de UML
Los bloques básicos de construcción de UML son tres, los elementos, las relaciones y
los diagramas.
34
 Los elementos son abstracciones que actúan como unidades básicas de

construcción. Hay cuatro tipos, los estructurales, los de comportamiento, los de
agrupación y los de notación. En cuanto a los elementos estructurales son las
partes estáticas de los modelos y representan aspectos conceptuales o
materiales. Los elementos de comportamiento son las partes dinámicas de los
modelos y representan comportamientos en el tiempo y en el espacio. Los
elementos de agrupación son las partes organizativas de UML, establecen las
divisiones en que se puede fraccionar un modelo. Sólo hay un elemento de
agrupación, el paquete, que se emplea para organizar otros elementos en
grupos. Los elementos de notación son las partes explicativas de UML,
comentarios que pueden describir textualmente cualquier aspecto de un
modelo. Sólo hay un elemento de notación principal, la nota.
 Las relaciones son abstracciones que actúan como unión entre los distintos
elementos. Hay cuatro tipos, la dependencia, la asociación, la generalización y
la realización.
 Los diagramas son la disposición de un conjunto de elementos, que

representan el sistema modelado desde diferentes perspectivas. UML tiene
nueve diagramas fundamentales, agrupados en dos grandes grupos, uno para
modelar la estructura estática del sistema y otro para modelar el
comportamiento dinámico. Los diagramas estáticos son: el de clases, de
objetos, de componentes y de despliegue. Los diagramas de
comportamiento son: el de Casos de Uso, de secuencia, de colaboración, de
estados y de actividades.
35
2.5.1.1.- Elementos
Describe un conjunto de
objetos que comparten los
E Clase mismos atributos,
L métodos, relaciones y
E semántica. Las clases
M implementan una o más
E interfaces.
N Se trata de una clase, en
T la que existe procesos o
O hilos de ejecución
S Clase activa concurrentes con otros
elementos. Las líneas del
E contorno son más gruesas
S que en la clase “normal”
T Agrupación de métodos u
R operaciones que
U especifican un servicio de
C una clase o componente,
T describiendo su
U Interfaz comportamiento, completo
R o parcial, externamente
A visible. UML permite
L emplear un círculo para
E representar las interfaces,
S aunque lo más normal es
emplear la clase con el
nombre en cursiva.
36
Define una interacción

entre elementos que
Colaboración cooperan para
proporcionar un
comportamiento mayor
que la suma de los
comportamientos de sus
elementos.
Describe un conjunto de
secuencias de acciones
que un sistema ejecuta,
Caso de uso para producir un resultado
observable de interés. Se
emplea para estructurar
los aspectos de
comportamiento de un
modelo.
Parte física y por tanto
reemplazable de un
modelo, que agrupa un
Componente conjunto de interfaces,
archivos de código fuente,
clases, colaboraciones y
proporciona la
implementación de dichos
elementos.
Elemento físico que existe
Nodo en tiempo de ejecución y
representa un recurso
computacional con
capacidad de procesar.
37
Comprende un conjunto de
mensajes que se
Interacción intercambian entre un
Elementos conjunto de objetos, para
de cumplir un objetivo
comportamiento especifico.
Especifica la secuencia de
Máquinas estados por los que pasa
de un objeto o una
estados interacción, en respuesta a
eventos.
Se emplea para organizar
Elementos otros elementos en grupos.
de Paquete
agrupación
Partes explicativa de UML,
Elementos que puede describir
de Nota textualmente cualquier
notación aspecto del modelo
Tabla 2.6: Elementos de construcción en UML
2.5.1.2.- Relaciones
Es una relación entre dos elementos, tal

Dependencia que un cambio en uno puede afectar al
otro.
Es una relación estructural que resume un
Asociación conjunto de enlaces que son conexiones
entre objetos.
Es una relación en la que el elemento
Generalización generalizado puede ser substituido por
cualquiera de los elementos hijos, ya que
38
comparten su estructura y
comportamiento.
Es una relación que implica que la parte
Realización realizante cumple con una serie de
especificaciones propuestas por la clase
realizada (interfaces).
Tabla 2.7: Elementos de relación en UML
2.5.1.3.- Diagramas
Muestra un conjunto de clases,

interfaces y colaboraciones, así
Clases como sus relaciones, cubriendo
M la vista de diseño estática del
O sistema.
D Análogo al diagrama de clases,
E muestra un conjunto de objetos
L y sus relaciones, pero a modo
A Objetos de vista instantánea de
N instancias de una clase en el
tiempo.
Muestra la organización y
E dependencias de un conjunto
S Componentes de componentes. Cubren la
T vista de implementación
R estática de un sistema. Un
U componente es un módulo de
C código, de modo que los
T diagramas de componentes son
U los análogos físicos a los
R diagramas de clases.
39
A Muestra la configuración del

hardware del sistema, los
nodos de proceso y los
Despliegue componentes empleados por
éstos. Cubren la vista de
despliegue estática de una
arquitectura.
Muestra un conjunto de casos
de uso, los actores implicados y
sus relaciones. Son diagramas
M Casos de fundamentales en el modelado
O Uso y organización del sistema.
D Son diagramas de interacción,
E muestran un conjunto de
L objetos y sus relaciones, así
A como los mensajes que se
N Secuencia intercambian entre ellos.
40
Cubren la vista dinámica del

sistema. El diagrama de
secuencia resalta la ordenación
temporal de los mensajes,
mientras que el de colaboración
C resalta la organización
O Colaboración estructural de los objetos,
M ambos siendo equivalentes o
P isomorfos. En el diagrama de
O colaboración de la figura de la
R izquierda, se puede ver que los
T elementos gráficos no son
A cajas rectangulares, como
M cabría esperar, y en su lugar
I encontramos sus versiones
E adornadas. Estas versiones
N tienen como finalidad
T evidenciar un rol específico del
O objeto siendo modelado. En la
figura encontramos de
izquierda a derecha y de arriba
abajo un Actor, una Interfaz, un
Control (modela un
comportamiento) y una
Instancia (modela un objeto de
dato).
Muestra una máquina de
estados, con sus estados,
transiciones, eventos y
Estados actividades. Cubren la vista
dinámica de un sistema.
Modelan comportamientos
reactivos en base a eventos.
41
Tipo especial de diagrama de

estados que muestra el flujo de
actividades dentro de un
sistema.
Actividades
Tabla 2.8: Diagramas de UML
2.5.1.3.1.- Diagrama de Clases y Diagrama de Objetos
Los diagramas de clases muestran un resumen del sistema en términos de sus clases
y las relaciones entre ellas. Son diagramas estáticos que muestran qué es lo que
interactúa, pero no cómo interactúa o qué pasa cuando ocurre la interacción.
El siguiente diagrama modela los pedidos de un cliente a una tienda de venta por
catálogo. La clase principal es “Pedido”, asociada a un cliente, una forma de pago y un
conjunto de artículos.
La clase “Pago” es abstracta, en UML los nombres de clases abstractas se

representan en Itálica. Las clases abstractas actúan a modo de interfaz,
proporcionando únicamente un listado de métodos a ser “realizados” por las clases
que las implementan o realizan. “Pago” es una superclase especializada, y a la vez
realizada, por sus formas más comunes “Credito” y “Efectivo”. Un “Pedido” tiene una
única forma de pago, expresada por su multiplicidad, 1, mientras que una forma de
pago puede estar presente en uno o más pedidos, como sugiere su multiplicidad, 1..*.
En cuanto a las asociaciones, observamos que algunas vienen representadas como

una flecha navegable, cuya orientación expresa el sentido en que se consultan los
datos. Las asociaciones sin flecha son bi-direccionales. Las agregaciones expresan
“conjunto de”; la relación entre “Pedido” y “Articulo” es de conjunto. Un pedido es una
agregación de una o más líneas de pedido, donde cada una hace alusión a un artículo
concreto, así mismo una línea de pedido puede estar presente en varios pedidos y un
artículo puede no haber sido solicitado nunca.
42
Figura 2.15: Diagrama de Clases
En cuanto a la multiplicidad, la siguiente tabla resume las más comunes. Hay que
tener en cuenta que la multiplicidad se expresa “en el lado opuesto” de la relación y es
el número de posibles instancias de una clase asociadas con una única instancia de la
clase en el otro extremo.
Multiplicidad Significado
1 Una única instancia
N/* N instancias
0..N / 0..* Entre ninguna y N instancias
1..N / 1..* Entre una y N instancias
0..1 Ninguna o una instancia
N..M Entre N y M instancias
Tabla 2.9: Multiplicidad en Diagramas de Clases
43
El siguiente diagrama muestra una dependencia existente entre las clases “Pedido” y
“Fecha”. Cualquier cambio en la clase dependida, “Fecha”, afectará la clase
dependiente, “Pedida”.
Así mismo se puede observar que las clases vienen representadas por cajas en las
que hay tres separaciones, o compartimentos. El primero se emplea siempre para
indicar el nombre de la clase, el segundo para mostrar los atributos y el tercero para
los métodos. Tanto los atributos como los métodos vienen precedidos por un símbolo
de acceso, que normalmente suele ser un “+” para el acceso público, un “-” para el
acceso privado, (sólo por otros métodos de la clase) y un “#” para el acceso protegido
(sólo por clases hija), aunque la herramienta empleada en la elaboración del tutorial
traduce estos elementos en iconos.
Los atributos tienen un tipo que puede mostrarse a continuación de su nombre

separado por “:”. De igual manera, los métodos pueden devolver un elemento de un
tipo determinado y recibir parámetros, expresados entre paréntesis mediante el
nombre del parámetro y el tipo, separados por “:”. Para el caso de múltiples
parámetros, se separan por comas (p1:t1, p2:t2 ... pn:tn). Los parámetros que tienen
un valor por defecto se expresan mediante un “=” y el valor, a continuación del tipo
(p1:t1=v1) y si un parámetro en la posición “i” de la lista de parámetros tiene valor por
defecto, todos los parámetros que le sigan, es decir que ocupen posiciones sucesivas
a “i” en la lista, deberán tener también un valor por defecto.
Los atributos y métodos estáticos (de clase) se representan mediante un subrayado

(en el caso de los métodos se puede emplear el estereotipo <<static>>, los
estereotipos se ven más adelante).
Figura 2.16: Relación de dependencia en Diagramas de Clase
El siguiente diagrama muestra una auto-relación de agregación. Un “Departamento”

puede estar compuesto a su vez por más sub-departamentos, o ninguno, con la
44
restricción de que el mínimo número de personas en los sub-departamentos debe ser

dos. Las restricciones son condiciones que deben ser cumplidas siempre, se expresan
entre llaves “{condición }”.
Figura 2.17: Auto-agregación
Los diagramas de objetos son análogos a los de clases, con la particularidad de que
en lugar de encontrar clases, encontramos instancias de éstas. Son útiles para
explicar partes pequeñas del modelo en las que hay relaciones complejas.
2.5.1.3.2.- Diagrama de Componentes y Diagrama de Despliegue
Los componentes son módulos de código, así que los diagramas de componentes
vienen a ser los análogos físicos a los diagramas de clases. Muestran como está
organizado un conjunto de componentes y las dependencias que existen entre ellos.
45
Figura 2.18: Diagrama de Componentes
Los diagramas de despliegue sirven para modelar la configuración hardware del

sistema, mostrando qué nodos lo componen.
Figura 2.19: Diagrama de Despliegue
46
2.5.1.3.3.- Diagrama de Casos de Uso
Los diagramas de Casos de Uso describen lo que hace un sistema desde el punto de
vista de un observador externo, enfatizando el qué más que el cómo. Plantean
escenarios, es decir, lo que pasa cuando alguien interactúa con el sistema,
proporcionando un resumen para una tarea u objetivo. El siguiente Caso de Uso
describe como Carlos va a desayunar (este es su objetivo), para lo que se plantea el
escenario de preparar su café y el pan tostado
Figura 2.20: Diagrama de Casos de Uso nivel 1
En los Casos de Uso, los Actores son papeles que determinadas personas u objetos
desempeñan. Se representan mediante un “hombre de palitos”, de modo que en el
ejemplo, Carlos es un Actor. Los Casos de Uso se representan por medio de óvalos y
las líneas que unen Actores con Casos de Uso representan una asociación de
comunicación.
Por su puesto, un Caso de Uso puede ser descrito en mayor profundidad. Por ejemplo
si tomamos por separado “Preparar pan” y “Preparar cafe”, podemos bajar un nivel de
descripción y llegar a los siguientes Casos de Uso.
47
Figura 2.21: Diagrama Casos de Uso nivel 2 A
“Carlos tuesta el pan en la tostadora, después lo unta con mantequilla y mermelada de

fresa y se lo come, posiblemente mojándolo en un café.”
Figura 2.22: Diagrama Casos de Uso nivel 2 B
“Carlos calienta leche, añade café y azúcar al gusto y se lo bebe.”
Los Casos de Uso suelen venir delimitados por fronteras o límites, que definen una
separación entre lo que es realmente la funcionalidad del sistema y los actores que la
usan o colaboran en su desempeño. En las figuras, esta separación viene
representada por medio de la caja que encapsula los óvalos.
Los Casos de Uso son acompañados por una explicación textual que clarifica las
posibles cadencias del lenguaje meramente gráfico. De esta manera, combinando
Casos de Uso y explicación textual, se puede obtener escenarios no ambiguos, que
resultan ideales en la captura de requisitos de usuario, dada su sencillez de
comprensión incluso por quien no está familiarizado con UML. Los Casos de Uso se
emplean también en la preparación de escenarios de pruebas con que verificar el
software una vez ha sido construido.
48
El siguiente Caso de Uso es equivalente al primero, “Desayuno”, sólo que en él se ha

condensado la máxima cantidad posible de información. En él se muestra un nuevo
elemento que hasta ahora no se había mostrado, el “estereotipo”, que viene entre
sendos símbolos angulados “<<” y “>>” y concreta un paso más allá el tipo de relación
existente entre dos Casos de Uso. Encontramos dos estereotipos <<include>> y
<<extend>>. El primero indica que el Caso de Uso “Tostar pan” requiere de “Usar
tostadora” para poder ser llevado a cabo. Esta es una forma muy adecuada de sacar
factor común entre Casos de Uso, o incluso de fraccionar Casos de Uso muy grandes.
El segundo indica que el Caso de Uso “Untar pan” es una variación de “Untar”.
Observamos también que “Comer pan” y “Beber cafe” son una generalización de
“Alimentarse”.
Figura 2.23: Diagrama Casos de Uso nivel 1 detallado
“Carlos va a desayunar. Para ello debe hacer dos actividades distintas, pero
relacionadas. La primera consiste en tostar pan, para lo cual necesita emplear una
tostadora. Una vez tostado el pan, lo unta de mantequilla y mermelada de fresa (untar
pan no es muy distinto de untar otro tipo de alimentos). La segunda consiste en
preparar el café, par lo cual necesita calentar leche y añadir café y azuzar. Terminadas
ambas actividades, Carlos puede proceder a alimentarse, comiendo el pan tostado y
bebiendo el café. El orden en que realice las actividades da igual y también da igual si
se realizan a la vez.”
49
2.5.1.3.4.- Diagrama de Secuencia y Diagrama de Colaboración
Los diagramas de secuencia describen como los objetos del sistema colaboran. Se
trata de un diagrama de interacción que detalla como las operaciones se llevan a
cabo, qué mensajes son enviados y cuando, organizado todo en torno al tiempo. El
tiempo avanza “hacia abajo” en el diagrama. Los objetos involucrados en la operación
se listan de izquierda a derecha de acuerdo a su orden de participación dentro de la
secuencia de mensajes.
Figura 2.24: Diagrama de Secuencia
Las líneas verticales o “líneas de la vida” representan el tiempo de vida del objeto. La
vida del objeto “carlos” no termina en este diagrama, sin embargo la del objeto “tosty”
sí y esto viene representado mediante el aspa al final de su línea de la vida.
Los rectángulos verticales son barras de activación y representan la duración de la

ejecución del mensaje. El mensaje “Encender”, posiblemente implementado mediante
la introducción del enchufe en una toma de pared, tiene una duración escasa y similar
a la de “Apagar”. No ocurre lo mismo con la llamada al método “tostar()”, que dura
desde la pulsación del botón de tostar hasta que el pan es retirado de la bandeja y
además interviene la emisión de un aviso cuando el pan está lo suficientemente
caliente, a fin de evitar que se queme.
50
Como se puede observar, la acción tostar viene condicionada por la presencia de pan
en la bandeja de la tostadora. En UML los corchetes “[]” expresan condición y si están
precedidos de un asterisco indican interacción mientras se cumpla la condición.
Los mensajes que son intercambiados entre los objetos de un diagrama de secuencia
pueden ser síncronos o asíncronos. Los mensajes asíncronos son aquellos tal que el
emisor puede enviar nuevos mensajes mientras el original está siendo procesado. El
mensaje asíncrono ocurre en el tiempo de manera independiente a otros mensajes.
Los mensajes síncronos son todo lo contrario, el emisor debe esperar a que termine el
tiempo de proceso del mensaje antes de que pueda emitir nuevos mensajes. UML
emplea los siguientes convenios para representar el tipo de mensaje.
Símbolo Significado
Mensaje simple que

puede
ser síncrono o
asíncrono.
Mensaje simple de
vuelta
(opcional).
Mensaje síncrono.
51
Mensaje asíncrono.
Tabla 2.10: Tipos de mensaje en diagramas de interacción
Los diagramas de colaboración son otro tipo de diagramas de interacción, que

contiene la misma información que los de secuencia, sólo que se centran en las
responsabilidades de cada objeto, en lugar de en el tiempo en que los mensajes son
enviados. Cada mensaje de un diagrama de colaboración tiene un número de
secuencia. El primer nivel de la secuencia es 1, y los mensajes que son enviados
durante la misma llamada a un método se numeran 1.1, 1.2 y así sucesivamente para
tantos niveles como sea necesario.
Figura 2.25: Diagrama de Colaboración
2.5.1.3.5.- Diagrama de Estados y Diagrama de Actividades
Los diagramas de estados muestran los posibles estados en que puede encontrarse
un objeto y las transiciones que pueden causar un cambio de estado. El estado de un
objeto depende de la actividad que esté llevando a cabo o de alguna condición.
Las transiciones son las líneas que unen los diferentes estados. En ellas se representa
la condición que provoca el cambio, seguida de la acción oportuna separada por “/”.
En un estado en que el objeto esta pendiente de algún tipo de validación que dependa
52
de un proceso en curso, no es necesario evento externo alguno para que se produzca

la transición, ya que ésta ocurrirá cuando termine el proceso, en función del resultado
de éste. En estos casos es conveniente, por claridad, incluir la condición que de la que
depende la transición (entre corchetes).
Los estados inicial, a partir del que se “entra” en la máquina de estados, y final, que
indica que la máquina de estados termina, no tienen otro significado adicional, son
elementos ornamentales y se representan mediante un circulo negro y un circulo negro
resaltado respectivamente.
Los estados de un diagrama de estados pueden anidarse, de forma que los estados
relacionados pueden ser agrupados en un estado compuesto. Esto puede ser
necesario cuando una actividad involucra sub-actividades asíncronas o concurrentes.
Figura 2.26: Máquina de Estados, estados simples
53
Figura 2.27: Máquina de Estados, estados compuestos
Los diagramas de actividades son básicamente diagramas de flujo adornados, que

guardan mucha similitud con los diagramas de estados. Mientras que los diagramas de
estados centran su atención en el proceso que está llevando a cabo un objeto, los
diagramas de actividades muestran como las actividades fluyen y las dependencias
entre ellas.
Los diagramas de actividades pueden dividirse en “calles” que determinan qué objeto
es responsable de qué actividad. Las actividades vienen unidas por transiciones, que
pueden separarse en ramas en función del resultado de una condición expresada
entre corchetes. Cada rama muestra la condición que debe ser satisfecha para que el
flujo opte por ese camino. Igualmente, las transiciones se pueden bifurcarse en dos o
más actividades paralelas.
54
Figura 2.28: Diagrama de Actividades
2.5.2.- Cómo utilizar UML
UML es simplemente un lenguaje de modelado. Define un conjunto de elementos y

relaciones entre ellos, que se emplean en la definición de modelos. UML es
típicamente usado como parte de un proceso de desarrollo, con la ayuda de una
herramienta CASE (Computer Aided Software Engineering), para definir
requerimientos, interacciones y elementos del software que se está desarrollando.
UML es independiente de cualquier proceso particular, no está ligado a ningún ciclo de
vida de desarrollo del software concreto, no obstante se obtienen mayores beneficios
si se selecciona un proceso que esté dirigido por Casos de Uso, se centre en la
arquitectura y sea incremental.
55
La arquitectura de un sistema es el conjunto de decisiones significativas que se toma

en torno a su organización, la selección de elementos estructurales, la definición de las
interfaces entre estos elementos, su comportamiento, su división en subsistemas, qué
elementos son estáticos y cuales dinámicos. La arquitectura también incluye el uso
que se le va a dar al sistema, la funcionalidad, el rendimiento, la capacidad de
adaptación, la reutilización, la capacidad de ser comprendido, las restricciones
económicas, las temporales, los compromisos entre alternativas y los aspectos
estéticos.
Un proceso incremental es aquél que consiste en sucesivas ampliaciones y mejoras

de la arquitectura, a partir de una línea básica. Cada incremento resuelve los
problemas encontrados en la versión anterior minimizando incrementalmente los
riesgos más significativos para el éxito del proyecto.
Lo primero que se debe hacer para comenzar a desarrollar un proyecto con UML, es
seleccionar una metodología de desarrollo que defina la naturaleza concreta del
proceso a seguir. El modelo a definir en base al proceso elegido, se divide en realidad
en varios tipos de modelo o vistas, cada una centrada en un aspecto o punto de vista
del sistema. En general, independientemente del proceso que se emplee, se puede
encontrar las siguientes vistas:
 Vista de Casos de Uso: Engloba los Casos de Uso que describen el

comportamiento del sistema como lo verían los usuarios finales, los analistas y
demás componentes del equipo de desarrollo. No especifica la organización
del sistema. Con UML los aspectos estáticos de esta vista se pueden
concretar con los diagramas de Casos de Uso; los aspectos dinámicos con
los diagramas de iteración (secuencia y colaboración), diagramas de estados y
de actividades.
 Vista de Diseño: Engloba las clases e interfaces que conforman el vocabulario

del problema y su solución. Da soporte a los requisitos funcionales del sistema,
es decir los servicios que proporciona a los usuarios finales. Con UML los
aspectos estáticos de esta vista se pueden concretar con los diagramas de
clases y de objetos; los aspectos dinámicos con los diagramas de iteración
(secuencia y colaboración), diagramas de estados y de actividades.
56
 Vista de Procesos: Engloba los hilos y procesos que forman los mecanismos
de sincronización y concurrencia del sistema. Da soporte al funcionamiento,
capacidad de crecimiento y rendimiento del sistema. Con UML los aspectos
estáticos de esta vista se pueden concretar con los diagramas de clases, de
clases activas y de objetos; los aspectos dinámicos con los diagramas de
iteración (secuencia y colaboración), diagramas de estados y de actividades.
 Vista de Despliegue: Engloba los nodos que forman la topología hardware

sobre el que se ejecuta el sistema. Da soporte a la distribución, entrega e
instalación de las partes que conforman el sistema físico. Con UML los
aspectos estáticos de esta vista se pueden concretar con los diagramas
despliegue; los aspectos dinámicos con los diagramas de iteración
(secuencia y colaboración), diagramas de estados y de actividades.
 Vista de Implementación: Engloba los componentes y archivos empleados

para hacer posible el sistema físico. Da soporte a la gestión de configuraciones
de las distintas versiones del sistema, a partir de componentes y archivos. Con
UML los aspectos estáticos de esta vista se pueden concretar con los
diagramas de componentes; los aspectos dinámicos con los diagramas de
iteración (secuencia y colaboración), diagramas de estados y de actividades.
Un ejemplo de proceso para la construcción de un programa, podría ser similar al
siguiente, teniendo en cuenta que el proceso descrito deja muchas cosas por ampliar y
puede no adaptarse a las necesidades particulares de un grupo de trabajo
determinado. Se proporciona meramente como un ejemplo de cómo se puede encajar
UML como soporte para el desarrollo de un proyecto:
1. Iniciar y mantener reuniones con los usuarios finales del programa, para
comprender sus necesidades, el contexto en que lo usarán y todos los detalles
necesarios para comprender el ámbito del problema a resolver. Esta
información será empleada para capturar las actividades y procesos
involucrados y susceptibles de ser incorporados en el programa, a un nivel alto,
y proporcionará la base para construir la vista de Casos de Uso.
57
2. Construir la vista de Casos de Uso definiendo exactamente la funcionalidad

que se va a incorporar en el programa, desde el punto de vista de sus usuarios.
El modelo resultante es realmente un mapeo de la información obtenida en el
paso anterior, en el que cada nuevo Caso de Uso realiza un aspecto de la
funcionalidad planteada. Refinar, en conjunto con los usuarios finales, todos los
diagramas de Casos de Uso, incluyendo requisitos y restricciones, para llegar a
un acuerdo común en lo que el programa hará y no hará. En este punto puede
ser conveniente diseñar escenarios de prueba que ayuden a verificar si el
programa finalizado cumple con las expectativas del contrato.
3. Partiendo del modelo de Casos de Uso se comienza a estructurar los requisitos

en una arquitectura llamada “línea base”. Se definen clases y relaciones entre
ellas, los primeros diagramas de secuencia y colaboración, definiendo los
comportamientos de cada clase, también las interfaces entre los diferentes
elementos de la arquitectura. Se construye aquí la vista de diseño y la vista de
procesos. Construir diagramas de clases más elaborados y refinar los
comportamientos del sistema.
4. A medida que crece el modelo se puede fraccionar en componentes software y

paquetes. Aparecen nuevos requisitos que deben ser integrados. Se define la
vista de despliegue, que define la arquitectura física del sistema, y la vista de
implementación.
5. Construir el sistema, repartiendo las tareas entre el equipo de programación.
6. Buscar errores de programación, o incluso de diseño, corregirlos e ir sacando

sucesivas versiones del programa hasta llegar a una versión que cumpla con
todos los requisitos especificados en el contrato con los usuarios.
7. Documentar y entregar el programa a los usuarios finales.
58
 2.6.- Microsoft Visual Basic
Visual Basic es un lenguaje de programación desarrollado por Alan

Cooper para Microsoft. El lenguaje de programación es un dialecto de BASIC,
con importantes añadidos. Su primera versión fue presentada en 1991 con la
intención de simplificar la programación utilizando un ambiente de desarrollo
completamente gráfico que facilitara la creación de interfaces gráficas y en
cierta medida también la programación misma. Visual Basic fue discontinuado
por Microsoft hace ya varios años. Muchos programadores estan migrando a
Real Basic o hacia Delphi que es un entorno de desarrollo mas avanzado y
mucho mas actual (ultima edicion en 2007 y con planes anunciados hasta el
2009). Microsoft propone abandonar el desarrollo en Win32 y pasar al Visual
Basic.NET que presenta serias incompatibilidades con el codigo Visual Basic
existente.
2.6.1.- Características generales

Es un lenguaje de fácil aprendizaje pensado tanto para programadores
principiantes como expertos, guiado por eventos, y centrado en un motor de
formularios que facilita el rápido desarrollo de aplicaciones gráficas. Su sintaxis,
derivada del antiguo BASIC, ha sido ampliada con el tiempo al agregarse las
características típicas de los lenguajes estructurados modernos. Se ha
agregado una implementación limitada de la programación orientada a objetos
(los propios formularios y controles son objetos), aunque sí admite el
polimorfismo mediante el uso de los Interfaces, no admite la herencia. No
requiere de manejo de punteros y posee un manejo muy sencillo de cadenas
de caracteres. Posee varias bibliotecas para manejo de bases de datos,
pudiendo conectar con cualquier base de datos a través de ODBC (Informix,
DBase, Access, MySQL, SQL Server, PostgreSQL ,etc) a través de ADO.
Es utilizado principalmente para aplicaciones de gestión de empresas, debido a
la rapidez con la que puede hacerse un programa que utilice una base de datos
sencilla, además de la abundancia de programadores en este lenguaje.
El compilador de Microsoft genera ejecutables que requieren una DLL para que
funcionen, en algunos casos llamada MSVBVMxy.DLL (acrónimo de "MicroSoft
Visual Basic Virtual Machine x.y", siendo x.y la versión) y en otros
VBRUNXXX.DLL ("Visual Basic Runtime X.XX"), que provee todas las
59
funciones implementadas en el lenguaje. Además existen un gran número de

bibliotecas (DLL) que facilitan el acceso a muchas funciones del sistema
operativo y la integración con otras aplicaciones. Sin embargo esto sólo es una
limitación en sistemas obsoletos, ya que las bibliotecas necesarias para
ejecutar programas en Visual Basic vienen de serie en todas las versiones de
Windows desde Windows 2000.
Derivados
Su derivado VBScript es el lenguaje predeterminado para Active Server Pages
(ASP).
Además, una extensión propia del lenguaje llamada Visual Basic for
Applications (VBA) permite codificar módulos (a veces llamados macros) para
las aplicaciones de Microsoft Office.
Especialmente a partir de la versión 6 del lenguaje, se permite la interacción y
generación de objetos remotos que puedan ser invocados desde páginas de
scripts (concretamente las ASP, aunque no es imposible hacer un enlace
empleando JSP), alojándolos en servidores de web.
Visual Basic.NET, parte de .NET, es un lenguaje prácticamente equivalente en
funcionalidades a C# (por ejemplo, no admite pseudo-punteros), añadiendo
capacidades de POO como herencia, polimorfismo...
Versiones
Las versiones de Visual Basic para Windows son muy conocidas, pero existe
una versión de Microsoft Visual Basic 1.0 para MS-DOS (ediciones Profesional
y Estándar) menos difundida y que data de 1992. Era un entorno que, aunque
en modo texto, incluía un diseñador de formularios en el que se podían
arrastrar y soltar distintos controles.
La última versión sólo para 16 bits, la 3.0, incluía ya una detallada biblioteca de
componentes para toda clase de usos. Durante la transición de Windows 3.11 a
Windows 95, apareció la versión 4.0, que podía generar programas de 16 y 32
bits a partir de un mismo código fuente, a costa de un gran aumento en el
tamaño de los archivos "runtime" necesarios. Además, se sustituyen los
controles VBX por los nuevos OCX. Con la versión 5.0, se implementó por
primera vez la posibilidad de compilar a código nativo, obteniendo una mejora
de rendimiento considerable. Tanto esta como la posterior 6.0 soportaban
características propias de los lenguajes orientados a objetos, aunque
careciendo de algunos ítems importantes como la herencia, el polimorfismo y la
sobrecarga. La version 6.0 continua utilizándose masivamente.
60
Las versiones actuales de Visual Basic se basan en la plataforma .NET, la

versión 7 del lenguaje fue implementada por Microsoft en el programa Visual
Basic .NET mientras que la versión 8 fue implementada el programa Visual
Basic 2005. Ambas versiones tienen muchas de las características del lenguaje
original tienen numerosas diferencias que los hacen incompatibles. En muchos
casos para portar un código escrito en Visual Basic 6 a Visual Basic .Net se
hace necesario reescribir parte del código. La nueva versión del lenguaje es
mayormente equivalente a C# aunque presenta algunas diferencias. Por eso
hay un debate sobre la validez de esta nueva versión del lenguaje y sus
ventajas y desventajas sobre C#.
2.6.2.- Ventajas e inconvenientes

Ventajas
La facilidad del lenguaje permite crear aplicaciones para
Windows en muy poco tiempo. En otras palabras, permite un desarrollo
eficaz y menor inversión en tiempo que con otros lenguajes.
Permite generar librerías dinámicas (DLL) ActiveX de forma nativa y
Win32 (no ActiveX, sin interfaz COM) mediante una reconfiguración de
su enlazador en el proceso de compilación.
Permite la utilización de formularios (Forms) tanto a partir de recursos
(como en otros lenguajes) como utilizando un IDE para diseñarlos.
Posibilidad de desarrollar y ejecutar aplicaciones de Visual Basic 6.0 en
Windows Vista sin realizar cambios en la mayoria de los casos pero no
se logra aprovechar al máximo las caracteristicas de este sistema como
permite hacerlo Visual Basic 2005 o el proximo Visual Basic 9 de Visual
Studio Orcas (Noviembre 2007).
Inconvenientes
Es software propietario por parte de Microsoft, por tanto nadie
que no sea del equipo de desarrollo de esta compañía decide la
evolución del lenguaje.
En Visual Basic 6.0 y anteriores sólo existe un compilador e IDE,
llamado igual que el lenguaje.
No existe forma alguna de exportar el código a otras plataformas fuera
de Windows.
61
Los ejecutables generados son relativamente lentos en Visual Basic 6.0

y anteriores al ser codigo pseudo-interpretado.
Por defecto permite la programación sin declaración de variables. (que
puede ser sencillamente corregida escribiendo la frase Option Explicit
en el encabezado de cada formulario, en cuyo caso será menester
declarar todas las variables a utilizar, lo que a la postre genera código
más puro).
Su sintaxis no es case sensitive (no distinge entre minusculas y
mayúsculas como C++ por ejemplo)
NO permite programación a bajo nivel ni incrustrar secciones de código
en ASM.
Sólo permite el uso de funciones de librerías dinámicas (DLL) stdcall.
Fuerte dependencia de librerías y componentes en las versiones 6.0 y
anteriores, lo que dificultaba la distribución de los desarrollos entre
maquinas.
Algunas funciones están indocumentadas.
La escasa implementación de POO en Visual Basic 6.0 y anteriores no
permite sacar el máximo provecho de este modelo de programación.
NO soporta tratamiento de procesos como parte del lenguaje.
El manejo de errores que tiene mediante la orden on error no sigue los
patrones estructurados.
NO incluye operadores de desplazamiento de bits como parte del
lenguaje.
NO permite el manejo de memoria dinámica, punteros, etc. como parte
del lenguaje.
NO avisa de ciertos errores o advertencias (se puede configurar el
compilador para generar ejecutables sin los controladores de
desbordamiento de enteros o las comprobaciones de límites en matrices
entre otros, dejando así más de la mano del programador la tarea de
controlar dichos errores)
El tratamiento de mensajes de Windows es básico e indirecto.
La gran gama de controles incorporados son, sin embargo en algunos
casos, muy generales, lo que lleva a tener que reprogramar nuevos
controles para una necesidad concreta de la aplicación. Esto cambia
radicalmente en Visual Basic .NET donde es posible reprogramar y
mejorar o reutilizar los controles existentes.
62
Los controles personalizados no mejoran la potencia de la API de

Windows, y en determinados casos acudir a ésta será el único modo de
conseguir el control personalizado deseado.
Su periodo de Soporte Tecnico lo determina Microsoft. En el caso de
Visual Basic 6.0 su Soporte Extendido dura hasta el 04 de Abril de
2008.
2.7.- SQL SERVER 2000

En la actualidad, las compañías demandan una clase diferente de
solución de base de datos. El rendimiento, la escalabilidad y la confiabilidad
son esenciales y la anticipación al mercado es crítica. Aparte de estas
cualidades empresariales fundamentales, SQL Server 2000 proporciona
agilidad a sus operaciones de análisis y administración de datos al permitir a su
organización adaptarse rápida y fácilmente para obtener ventaja competitiva en
un entorno de cambios constantes. Desde una perspectiva de administración
de datos y análisis, resulta crítico transformar los datos sin procesar en
inteligencia empresarial y aprovechar las oportunidades que presenta el Web.
SQL Server 2000 es un paquete completo de base de datos y análisis de datos
que abre las puertas al rápido desarrollo de una nueva generación de
aplicaciones comerciales de nivel empresarial, que pueden proporcionar a su
compañía una ventaja competitiva crítica. SQL Server 2000 ha obtenido
importantes galardones en pruebas de referencia por su escalabilidad y
velocidad. Es un producto de base de datos totalmente habilitado para Web
que proporciona una compatibilidad fundamental con el Lenguaje de marcado
extensible (XML, Extensible Markup Language) y la capacidad para realizar
consultas en Internet y por encima del servidor de seguridad.
Totalmente habilitado para Web

SQL Server 2000 proporciona completas capacidades de programación
de bases de datos basadas en estándares Web. La perfecta compatibilidad con
el lenguaje XML y los estándares de Internet le proporcionan la capacidad para
almacenar y recuperar fácilmente datos en formato XML con procedimientos
almacenados integrados. También puede utilizar datagramas de actualización
de XML para insertar, actualizar y eliminar datos con facilidad.
63
Acceso fácil a los datos a través de Web Con SQL Server 2000, puede utilizar
HTTP para enviar consultas a la base de datos, realizar búsquedas de texto en
documentos almacenados en la base de datos y ejecutar consultas a través del
Web con el lenguaje natural.
Análisis basado en Web eficaz y flexible. Las capacidades de Analysis

Services de SQL Server 2000 se extienden a Internet. Puede tener acceso a
los datos del cubo y manipularlos por medio de un explorador Web.
Alta escalabilidad y confiabilidad
Con SQL Server 2000 obtendrá una escalabilidad y confiabilidad
incomparables. Las capacidades de ampliación de SQL Server satisfacen las
necesidades de las exigentes aplicaciones empresariales y de comercio
electrónico.
Escalado de ampliación. SQL Server 2000 aprovecha los sistemas de
multiproceso simétrico (SMP, Symmetrical Multiprocessor). SQL Server
Enterprise Edition puede utilizar hasta 32 procesadores y 64 GB de RAM.
Escalado de distribución. El escalado distribuye la base de datos y la carga de
datos entre servidores.
Disponibilidad. SQL Server 2000 consigue la máxima disponibilidad gracias a
los clústeres de conmutación por error mejorados, el trasvase de registros y las
nuevas estrategias de copia de seguridad.
Mayor anticipación al mercado
SQL Server 2000 es la estructura de administración y análisis de datos
de Microsoft® Windows Server System™. SQL Server 2000 incluye
herramientas que aceleran el desarrollo desde el concepto inicial a la entrega
final.
Servicios de análisis integrados y extensibles. Con SQL Server 2000,
puede generar soluciones de análisis de extremo a extremo con herramientas
integradas para crear valor con los datos. Además, puede llevar a cabo
automáticamente procesos empresariales basados en los resultados del
análisis y recuperar de manera flexible conjuntos de resultados personalizados
de los cálculos más complejos.
Rápido desarrollo, depuración y transformación de los datos. SQL Server
2000 presenta la capacidad para optimizar y depurar consultas de manera
interactiva, mover y transformar rápidamente datos provenientes de cualquier
origen y definir y utilizar funciones como si estuvieran integradas en Transact-
64
SQL. Puede diseñar y codificar visualmente aplicaciones de base de datos con

cualquier herramienta de Visual Studio.
Administración y optimización simplificadas. Con SQL Server 2000, resulta
sencillo administrar bases de datos de forma centralizada junto a todos los
recursos empresariales. Permanezca en línea mientras mueve y copia
fácilmente bases de datos entre equipos o instancias.
2.8.- Power Designer
La Herramienta Líder en Modelamiento Empresarial
PowerDesigner es un único conjunto de herramientas de modelamiento

que combina distintas técnicas estándar de modelamiento: modelamiento de
aplicación a través de UML, técnicas de Modelamiento de Procesos
Empresariales y técnicas tradicionales de modelamiento de base de datos.
La última versión, PowerDesigner 12.0, ofrece características para los

más exigentes modeladores de base de datos, tales como el soporte a las más
recientes versiones de base de datos, herramientas de análisis de base de
datos más poderosas y notación IDEF 1/X.
Para aquellos que buscan una herramienta estándar de modelamiento

para administración de meta-datos a nivel empresarial, PowerDesigner 12.0
ofrece innovaciones en Modelamiento de Procesos Empresariales, incluyendo
soporte de simulación y procesamiento ejecutable de procesos de negocio,
mayor integración con los ciclos de desarrollo de lenguaje como C# y VB.Net y
técnicas más poderosas de generación inter-modelos, encadenamiento y
sincronización.
2.8.1.- Beneficios De PowerDesigner
 PowerDesigner es la Elección Segura – El compromiso de

PowerDesigner con el modelamiento de datos, UML y de negocio,
además de estar comprobado en el mercado, lo hace la elección
segura para todos los requerimientos de modelamiento.
PowerDesigner es el estándar en muchas organizaciones a nivel
mundial.
65
 PowerDesigner Mejora la Productividad Individual – El enfoque

orientado a modelos de PowerDesigner incorpora una serie de
generadores DDL y de código personalizables, y capacidades de
ingeniería reversa y sincronización de código, que reduce
significativamente los esfuerzos de creación, mantenimiento y
reingeniería manual de código.
 PowerDesigner Brinda Facilidad de Uso Gráfica – La interfaz

gráfica altamente personalizable de PowerDesigner hace que las
tareas comunes sean muy fáciles y le da el poder a los usuarios
avanzados de tener acceso rápido a todas las funciones.
 PowerDesigner Alinea el Negocio con el Área de Tecnología –

PowerDesigner facilita el alineamiento del negocio con el área de
tecnología a través de técnicas de colaboración en grupo, y
tecnologías "Link and Synch" entre todos los modelos de
Requerimientos, Negocios, UML y Datos.
 PowerDesigner Mejora la Productividad en Grupo –

PowerDesigner da a todos los modeladores un ambiente ideal para
compartir recursos a través de un repositorio de meta-datos único,
completo y seguro para todos los tipos de modelos.
 PowerDesigner Documenta los Sistemas Existentes –

PowerDesigner adopta una mayor colaboración a nivel empresarial
a través de generación de reportes flexible y basada en asistentes,
o RTF / HTML multi-modelo.
 PowerDesigner Brinda Soporte Abierto – PowerDesigner permite

el entendimiento de sistemas heterogéneos con el soporte a los
principales estándares de lenguajes de desarrollo, XML, base de
datos y procesos, con una sola herramienta e infraestructura.
 PowerDesigner es Altamente Personalizable – PowerDesigner

puede ser fácilmente "programado" para asegurar los estándares y
prácticas corporativas o legales, a través del soporte a "scripts" VB,
una interfaz COM completamente programable, un meta-modelo
personalizable y un API totalmente documentado.
66
 PowerDesigner Reduce el Impacto del Cambio – PowerDesigner

reduce significativamente el costo y tiempo al implementar cualquier
cambio a través de una vista exacta, bi-direccional y multi-modelo
para análisis de impacto que integra todos los modelos de
requerimientos, análisis, base de datos y aplicación.
2.9.- Programación Orientada A Objetos
La Programación Orientada a Objetos (POO u OOP según sus siglas en inglés)

es un paradigma de programación que usa objetos y sus interacciones para
diseñar aplicaciones y programas de computadora. Está basado en varias
técnicas, incluyendo herencia, modularidad, polimorfismo, y encapsulamiento.
Su uso se popularizó a principios de la década de 1990. Actualmente son
muchos los lenguajes de programación que soportan la orientación a objetos.
2.9.1.- Introducción
Los objetos son entidades que combinan estado, comportamiento e

identidad:
 El estado está compuesto de datos, serán uno o vários atributos a los

que se habrán asignado unos valores concretos (datos).
 El comportamiento está definido por los procedimientos o métodos con
que puede operar dicho objeto, es decir, que operaciones se pueden
realizar con él.
 La identidad es una propiedad de un objeto que lo diferencia del resto,
dicho con otras palabras, es su identificador (concepto análogo al de
identificador de una variable o una constante).
La programación orientada a objetos expresa un programa como un

conjunto de estos objetos, que colaboran entre ellos para realizar tareas.
Esto permite hacer los programas y módulos más fáciles de escribir,
mantener y reutilizar.
De esta forma, un objeto contiene toda la información que permite definirlo

e identificarlo frente a otros objetos pertenecientes a otras clases e incluso
67
frente a objetos de una misma clase, al poder tener valores bien

diferenciados en sus atributos. A su vez, los objetos disponen de
mecanismos de interacción llamados métodos que favorecen la
comunicación entre ellos. Esta comunicación favorece a su vez el cambio
de estado en los propios objetos. Esta característica lleva a tratarlos como
unidades indivisibles, en las que no se separan ni deben separarse el
estado y el comportamiento.
Los métodos (comportamiento) y atributos (estado) están estrechamente

relacionados por la propiedad de conjunto. Esta propiedad destaca que una
clase requiere de métodos para poder tratar los atributos con los que
cuenta. El programador debe pensar indistintamente en ambos conceptos,
sin separar ni darle mayor importancia a ninguno de ellos, hacerlo podría
producir el hábito erróneo de crear clases contenedoras de información por
un lado y clases con métodos que manejen a las primeras por el otro. De
esta manera se estaría realizando una programación estructurada
camuflada en un lenguaje de programación orientado a objetos.
Esto difiere de la programación estructurada tradicional, en la que los datos

y los procedimientos están separados y sin relación, ya que lo único que se
busca es el procesamiento de unos datos de entrada para obtener otros de
salida. La programación estructurada anima al programador a pensar sobre
todo en términos de procedimientos o funciones, y en segundo lugar en las
estructuras de datos que esos procedimientos manejan. En la
programación estructurada sólo se escriben funciones que procesan datos.
Los programadores que emplean éste nuevo paradigma, en cambio,
primero definen objetos para luego enviarles mensajes solicitándoles que
realicen sus métodos por sí mismos.
2.9.2.- Origen
Los conceptos de la programación orientada a objetos tienen origen en

Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-
Johan Dahl y Kristen Nygaard del Centro de Cómputo Noruego en Oslo. Al
parecer, en este centro, trabajaban en simulaciones de naves, y fueron
confundidos por la explosión combinatoria de cómo las diversas cualidades
de diversas naves podían afectar unas a las otras. La idea ocurrió para
68
agrupar los diversos tipos de naves en diversas clases de objetos, siendo

responsable cada clase de objetos de definir sus propios datos y
comportamiento. Fueron refinados más tarde en Smalltalk, que fue
desarrollado en Simula en Xerox PARC (y cuya primera versión fue escrita
sobre Basic) pero diseñado para ser un sistema completamente dinámico
en el cual los objetos se podrían crear y modificar "en marcha" en lugar de
tener un sistema basado en programas estáticos.
La programación orientada a objetos tomó posición como el estilo de

programación dominante a mediados de los años ochenta, en gran parte
debido a la influencia de C++, una extensión del lenguaje de programación
C. Su dominación fue consolidada gracias al auge de las Interfaces gráficas
de usuario, para las cuales la programación orientada a objetos está
particularmente bien adaptada. En este caso, se habla también de
programación dirigida por eventos.
Las características de orientación a objetos fueron agregadas a muchos

lenguajes existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp,
Pascal, entre otros. La adición de estas características a los lenguajes que
no fueron diseñados inicialmente para ellas condujo a menudo a problemas
de compatibilidad y a la capacidad de mantenimiento del código. Los
lenguajes orientados a objetos "puros", por otra parte, carecían de las
características de las cuales muchos programadores habían venido a
depender. Para saltar este obstáculo, se hicieron muchas tentativas para
crear nuevos lenguajes basados en métodos orientados a objetos, pero
permitiendo algunas características imperativas de maneras "seguras". El
Eiffel de Bertrand Meyer fue un temprano y moderadamente acertado
lenguaje con esos objetivos pero ahora ha sido esencialmente reemplazado
por Java, en gran parte debido a la aparición de Internet, y a la
implementación de la máquina virtual de Java en la mayoría de
navegadores. PHP en su versión 5 se ha ido modificando y soporta una
orientación completa a objetos, cumpliendo todas las características
propias de la orientación a objetos.
69
2.9.3.- Conceptos fundamentales
La programación orientada a objetos es una nueva forma de programar que

trata de encontrar una solución a estos problemas. Introduce nuevos
conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre
ellos destacan los siguientes:
 Objeto: entidad provista de un conjunto de propiedades o atributos

(datos) y de comportamiento o funcionalidad (métodos). Corresponden
a los objetos reales del mundo que nos rodea, o a objetos internos del
sistema (del programa). Es una instancia a una clase.---
 Clase: definiciones de las propiedades y comportamiento de un tipo de
objeto concreto. La instanciación es la lectura de estas definiciones y la
creación de un objeto a partir de ellas.
 Método: algoritmo asociado a un objeto (o a una clase de objetos), cuya
ejecución se desencadena tras la recepción de un "mensaje". Desde el
punto de vista del comportamiento, es lo que el objeto puede hacer. Un
método puede producir un cambio en las propiedades del objeto, o la
generación de un "evento" con un nuevo mensaje para otro objeto del
sistema.
 Evento: un suceso en el sistema (tal como una interacción del usuario
con la máquina, o un mensaje enviado por un objeto). El sistema
maneja el evento enviando el mensaje adecuado al objeto pertinente.
También se puede definir como evento, a la reacción que puede
desencadenar un objeto, es decir la acción que genera.
 Mensaje: una comunicación dirigida a un objeto, que le ordena que
ejecute uno de sus métodos con ciertos parámetros asociados al evento
que lo generó.
 Propiedad o atributo: contenedor de un tipo de datos asociados a un
objeto (o a una clase de objetos), que hace los datos visibles desde
fuera del objeto y esto se define como sus características
predeterminadas, y cuyo valor puede ser alterado por la ejecución de
algún método.
 Estado interno: es una propiedad invisible de los objetos, que puede
ser únicamente accedida y alterada por un método del objeto, y que se
utiliza para indicar distintas situaciones posibles para el objeto (o clase
de objetos).
70
 Componentes de un objeto:atributos, identidad, relaciones y métodos.

 Representación de un objeto: un objeto se representa por medio de
una tabla o entidad que esté compuesta por sus atributos y funciones
correspondientes.
En comparación con un lenguaje imperativo, una "variable", no es más que

un contenedor interno del atributo del objeto o de un estado interno, así
como la "función" es un procedimiento interno del método del objeto.
2.9.4.- Características de la POO
Hay un cierto desacuerdo sobre exactamente qué características de un

método de programación o lenguaje le definen como "orientado a objetos",
pero hay un consenso general en que las características siguientes son las
más importantes (para más información, seguir los enlaces respectivos):
o Abstracción: Cada objeto en el sistema sirve como modelo de un

"agente" abstracto que puede realizar trabajo, informar y cambiar su
estado, y "comunicarse" con otros objetos en el sistema sin revelar
cómo se implementan estas características. Los procesos, las funciones
o los métodos pueden también ser abstraídos y cuando lo están, una
variedad de técnicas son requeridas para ampliar una abstracción.
o Encapsulamiento: Significa reunir a todos los elementos que pueden
considerarse pertenecientes a una misma entidad, al mismo nivel de
abstracción. Esto permite aumentar la cohesión de los componentes del
sistema. Algunos autores confunden este concepto con el principio de
ocultación, principalmente porque se suelen emplear conjuntamente.
o Principio de ocultación: Cada objeto está aislado del exterior, es un
módulo natural, y cada tipo de objeto expone una interfaz a otros
objetos que especifica cómo pueden interactuar con los objetos de la
clase. El aislamiento protege a las propiedades de un objeto contra su
modificación por quien no tenga derecho a acceder a ellas, solamente
los propios métodos internos del objeto pueden acceder a su estado.
Esto asegura que otros objetos no pueden cambiar el estado interno de
un objeto de maneras inesperadas, eliminando efectos secundarios e
interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo
un acceso directo a los datos internos del objeto de una manera
71
controlada y limitando el grado de abstracción. La aplicación entera se

reduce a un agregado o rompecabezas de objetos.
o Polimorfismo: comportamientos diferentes, asociados a objetos
distintos, pueden compartir el mismo nombre, al llamarlos por ese
nombre se utilizará el comportamiento correspondiente al objeto que se
esté usando. O dicho de otro modo, las referencias y las colecciones de
objetos pueden contener objetos de diferentes tipos, y la invocación de
un comportamiento en una referencia producirá el comportamiento
correcto para el tipo real del objeto referenciado. Cuando esto ocurre en
"tiempo de ejecución", esta última característica se llama asignación
tardía o asignación dinámica. Algunos lenguajes proporcionan medios
más estáticos (en "tiempo de compilación") de polimorfismo, tales como
las plantillas y la sobrecarga de operadores de C++.
o Herencia: las clases no están aisladas, sino que se relacionan entre sí,
formando una jerarquía de clasificación. Los objetos heredan las
propiedades y el comportamiento de todas las clases a las que
pertenecen. La herencia organiza y facilita el polimorfismo y el
encapsulamiento permitiendo a los objetos ser definidos y creados
como tipos especializados de objetos preexistentes. Estos pueden
compartir (y extender) su comportamiento sin tener que reimplementar
su comportamiento. Esto suele hacerse habitualmente agrupando los
objetos en clases y estas en árboles o enrejados que reflejan un
comportamiento común. Cuando un objeto hereda de más de una clase
se dice que hay herencia múltiple; esta característica no está soportada
por algunos lenguajes (como Java).
72
CAPÍTULO III
RESULTADOS
73
3.1.- Descripción de la Organización.-

3.1.1.- Reseña Histórica.-
La Empresa se dedica a la fabricación y Venta de Kekes y pasteles,
desde hace mas 19 años, inicio sus actividades en un local ubicado en Jr.
Virrey Abascal 201 - San Isidro bajo la razón social de Abascal S.R.L., desde
1998 comenzaron a trabajar productos con marcas con la intención de lograr
una mayor fidelización de sus clientes, logrando resultados y ocasionando la
apertura de nuevos locales para satisfacer la demanda de Ventas.
En marzo del 2003 se muda al actual local Av. Angamos Este 2402,
pero bajo la razón social de Productos Kerry’s S.R.L.; con este nuevo local se
logra incrementar las ventas por una mayor capacidad de producción y mejora
en la presentación de productos. En Agosto de éste año se apertura un local
para oficinas administrativas en José Neyra 295 - Surquillo, esto con la
finalidad de aumentar la capacidad de producción en local de Angamos y
brindar instalaciones adecuadas para el área de Ventas y Administración
Kerry’s, la marca emblemática de esta organización, surge

precisamente como un fonema de la frase “qué rico”, la misma que ha
terminado por imponerse entre sus similares y está sólidamente posicionada en
el mercado nacional y ahora se piensa en la exportación. En 1988 la empresa
que nació inicialmente bajo la batuta de los hermanos Congrains, producía
kekes y pasteles. “Desde mis tiempos de estudiante anhelé siempre tener un
producto propio en el mercado. Previamente hicimos un estudio de mercado
para saber qué debíamos fabricar. Como quiera que había experiencia familiar
en el horneado de kekes, no lo pensamos dos veces para hacer lo mismo a
escala comercial. Así, empezamos a trabajar con tres marcas: Kerry’s, Jaranito
y Gustozzi (de gusto)”.
Pero, no se crea que faltaron otros experimentos. Así tenemos que

Congrains comenzó en el mundo de los negocios editando libros. No obstante,
las circunstancias no fueron propicias para continuar en ese rubro y se pasó a
los kekes, ámbito que está dando muchas satisfacciones a los directivos y los
cien trabajadores que emplea en épocas de campaña.
Quizás las ventajas competitivas de los productos Kerry’s estribe tanto

en los buenos insumos que se utilizan, el “secreto” para darle consistencia y
74
sabor a los kekes y otras golosinas que se fabrican, así como en el envasado
moderno, práctico e higiénico que se utiliza. La marca Jaranito abarca
productos más ligados a nuestras tradiciones en materia de productos que
deleitan el paladar.
Gustozzi está más en la línea italiana que conjuga la exquisitez de las

mezclas de insumos con una depurada y decorativa presentación, amén del
sabor agradable.
Pero, como en toda organización, debe existir un motor impulsor para

posicionarse en un mercado siempre exigente y competitivo. Y Kerry’s no podía
ser una excepción. Desde el principio se pensó en grande, en una cobertura
masiva, con una visión de crecimiento y competitividad.
3.1.2.- Eficiencia horizontal

Se asumió procesos de ventas y marketing a nivel de minoristas, en
forma horizontal con vendedores emprendedores habiendo logrado mantener
4.500 puntos de venta en toda la capital, especialmente en bodegas,
cafeterías, kioscos e incluso vendedores ambulantes. Con el mismo ahinco se
trabaja con los supermercados Wong y Metro y también con otros clientes
mayoristas a través de una fuerza de ventas que cada vez se empina más para
imponerse entre la competencia.
Aspecto importante es la línea de ventas en las ciudades del interior del

país a través de distribuidores especiales. En Lima también tiene dos tiendas
propias que siempre están llenas de ávidos clientes que saben lo que es
bueno.
3.1.3.- Controles al mínimo

Uno de los secretos del auge de esta empresa es el meticuloso control
de calidad que se dispensa en cada fase de la fabricación. En el departamento
de Desarrollo e Investigación se pone especial cuidado en mantener las
buenas formas de manufactura de los productos y siempre están atentos para
contar con maquinarias de última generación.
75
Los hornos, batidoras, mezcladoras, etc., proceden de fábricas y

marcas acreditadas. “Estamos en vísperas de adquirir equipos de la más alta
tecnología para seguir creciendo a la medida de los proyectos que tiene la
empresa.
Y, por supuesto, el factor humano es el que merece primera atención.

Los ejecutivos y técnicos se capacitan y viajan con frecuencia a ferias
internacionales donde pueden evaluar in situ el equipamiento y el desarrollo
tecnológico de la industria mundial de golosinas y productos colaterales.
Sabemos que el área de producción cuida especialmente que los

productos tengan la mayor duración posible en el mercado, lo que constituye
otra ventaja competitiva porque permite mejores ingresos y menos volúmenes
de sobrantes. “El envase especial que utilizamos nos permite lograr una mayor
durabilidad de los productos. Por eso decimos que tecnológicamente tenemos
un liderazgo ganado a pulso. Las buenas prácticas de manufactura se refleja a
diario en los pedidos y en el reconocimiento de los controles que ejercemos en
todo lo que producimos”, incluso los propios clientes, como por ejemplo Wong,
envían sus inspectores para certificar lo que adquieren en Kerry’s.
3.1.4.- Capacitación y limpieza

Como ya se anotó, existe entre el personal una notoria aptitud para el
trabajo. Su capacitación y el monitoreo del mismo se ha institucionalizado en la
empresa.
“Sabemos que en materia de productos alimenticios, la higiene, el

cuidado y el envase para una buena presentación son elementos estratégicos
para ganar y posicionarse en el mercado”, afirma el gerente de la entidad.
Visitando las instalaciones de la fábrica se puede corroborar lo dicho.

Los trabajadores se entregan con natural predisposición a sus tareas y cuidar
al mínimo cada detalle.
76
3.1.5.- Misión
Constituir una Organización innovadora, eficiente y competitiva, que
elabore y/o distribuya productos alimenticios verdaderamente "Ricos"
compartiendo y desarrollando la pasión por la calidad y el servicio
3.1.6.- Visión
Ser una empresa líder en el rubro de alimentos, con marcas de gran
valor y productos exitosos de larga duración en mercados diversificados del
Perú y Latinoamérica, respaldada por una sólida organización que este a la
vanguardia en recursos humanos, comercialización, tecnología, rentabilidad y
efectividad.
3.1.7.- Canales De Venta
Horizontales: Atienden a bodegas y minoristas en Lima metropolitana, a cargo

de 2 supervisores y 13 vendedores, c/u con carro para reparto
Mayoristas: Atienden a Mayoristas de los principales mercados de Lima, a
cargo de 1 supervisores y 3 vendedores, c/u con carro para reparto y con el
apoyo de 1 impulsadora c/
Distribuidores: Atienden a Distribuidores de Lima (8) y Provincias (25), a
cargo de 1 supervisor y 1 vendedora de oficina. Actualmente despachamos a
casi todas las provincias importantes del territorio nacional
Autoservicio: Se atiende -por ahora- a Wong y Metro, a cargo de 1 vendedor
que cuenta con carro propio
Tiendas: Actualmente tenemos 2 Tiendas (San Isidro y Minka), a cargo de 1
Jefe de Tiendas y con 2 vendedoras por cada Tienda
Institucional: Es un canal que recien se apertura, actualmente hay 2 clientes:
Sodexho y Nuevo Continente, esta cargo de 2 vendedores, cuya función básica
es trabajar con la campaña Navideña
77
3.1.8.- Datos De La Empresa.
Teléfonos : 448-1130, 271-9521, 271-4773, 273-2533. Tienda

San Isidro: 221-7683
Domicilio fiscal : Av. Angamos Este 2402 - Surquillo
Oficinas : José Neyra 295 - Surquillo
Tiendas : Virrey Toledo 165 - San Isidro
Local Nº 237 Av. 2 Pabellón 04 C.C. Minka
Jr. Juan Fuentes 180 – Surquillo
Página Web : www.productoskerrys.com
3.1.9.- Estructura Organizacional

Es representado a través de organigrama donde se observa la
Estructura organizacional de la empresa PRODUCTOS KERRY’S
78
ESTRUCTURA ORGANIZACIONAL DE LA EMPRESA PRODUCTOS KERRY’S
Figura. 3.1 GERENCIA
SUB GERENCIA
AREA DE PRODUCCION AREA DE ASEGURAMIENTO AREA DE AREA DE ADMINISTRACION

DE LA CALIDAD COMERCIALIZACION
ASISTENTE DE INVESTIGACIÓN Y MANTENIMIENTO Y LIMPIEZA ASISTENTE DE CALIDAD ASISTENTE DE VENTAS SOPORTE INFORMATICO
DESARROLLO
SUPERVISORES PRODUCCIÓN ASISTENTE DE PASTELERÍA AUXILIARES DE VENTAS SEGURIDAD
OPERARIOS DOSIMETRIA OPERARIOS PASTELERÍA SUPERVISORES VENTA HORIZONTAL LIMPIEZA
OPERARIOS BATIDOS VENDEDORES ASISTENTE CONTABLE

HORIZONTALES
OPERARIOS HORNOS SUPERVISORES VENTA MAYORISTA AUXILIAR CONTABLE
OPERARIOS PASTAS VENDEDORES MAYORISTAS AUXILIAR DE TESORERIA
OPERARIOS ACABADOS IMPULSADORAS ASISTENTE DE RECURSOS

HUMANOS
SUPERVISORES DE DISTRIBUIDORES ASISTENTE DE LOGISTICA
SUPERVISOR CONOS ALMACENERO DE MATERIAS

PRIMAS
VEDEDORES DE AUTOSERVICIOS DESPACHADOR DE

PRODUCTOS TERMINADOS
MERCADERISTA TRANSPORTE
TIENDAS
79
3.2.- Modelo De Base De Datos
3.2.1.- Fase Inicial

Está comprendido por el modelado de negocio, casos de usos y de
requerimiento los cuales detallamos a continuación:
3.2.2.- Modelado Del Negocio

Los pasos para el modelado del negocio son los siguientes:
3.2.2.1.- Regla Del Negocio
 La orden de requerimientos debe ser registrada por el área de
producción
 El encargado de logística debe cerciorarse que exista stock
disponible de los productos para atender los requerimientos de
producción.
 El proceso de compra se efectúa cuando los requerimientos son
superiores al stock disponible en el almacén.
 El encargado del almacén registra la salida de materiales y
entrega al área de producción.
 El encargado del almacén tiene que cerciorarse que los
productos que se detallan en la factura estén reflejados en la
orden de compra realizada por logística y realiza el ingreso en el
sistema.
 El encargado de almacén se encarga de hacer el levantamiento
físico de los inventarios de los productos para que sea validado y
proporcionar a la administración para posteriormente validar la
exactitud de registro de inventario.
80
3.2.2.2.- Modelo de Procesos de Negocio
Base de Datos
Producción Logistica1 Almacen Materia Prima Proveedor Administración
Consultar Stock de Materiales
Recepcionar Guia de Requerimientos

Generar informes
Registra Stock Fisico
Registrar Orden de Requerimientos

Genera Informes de Exactitud de Registros de Inventario
Consultar Stock de Materiales y Requerimiento
Recepcionar Informes
Entregar Stock Fisico de Materiales

Solicitar Requerimientos de Materiales
Existencia de Materiales
Registrar salidas de Materiales

[NO] [SI]
Recepcionar Guia de Compra
Solictar se atienda la Solicitud de Requerimiento

Evaluar y tomar Decisiones
La verificacion del
Luego de haber Producto se realiza si el
seleccionado al producto esta en buena
Realizar Proceso de Compra Proveedor, se realizara calidad y si los Recepcionar Materiales
el requerimiento de materiales concuerden
compra con la guia de compra
[SI] Verificar Compra de Materiales

Genera Guia de Compra
[NO]
Entregar Materiales
Solicitar Materiales Entregar Los Materiales requeridos

Devolución de Materiales
Registrar el Ingreso de Materiales por Compras

Recepcionar Materiales
Informar Ingreso de los Materiales
Figura 3.2: Modelo de Procesos de Negocio

81
3.2.3.- Identificación De Los Actores Y Entidades De La Organización
Con la información obtenida se identificaron los actores y

entidades involucradas en el tratamiento de información de los bienes
patrimoniales.
IDENTIFICACION DE ACTORES Y ENTIDADES

ELEMENTOS DESCRIPCION
Producción
Logística
Actores Almacén
Proveedor
Administrador
Documento de Ingreso
Entidades Catalogo de Productos
Catalogo de Proveedores
Areas
Tabla 3.1: Identificación de Actores y Entidades
82
3.2.4.- Modelo De Casos De Uso General
Entregar Materiales.
Registrar solicitud
almacen
Solicita Atender Solicitud
Consultar Requerimientos
Realizar Proceso de Exactitud de Inventario
Produccion
Registrar Ingreso de Materiales

Logistica
Solicitar Requerimiento
Administrador
Realiza Proceso de Compra
Proveedor
Figura 3.3: Modelo De Casos De Uso General
83
3.2.4.1.- Especificaciones de casos de Uso General
Caso de Uso: Registrar solicitud

Descripción: Se ingresa a la BD la solicitud de requerimientos
 Consultar productos
lujo de eventos:  Registrar cantidad
 Generar guía de requerimientos
Tabla.3.2 Especificaciones de casos de Uso General – Entrega de materiales
Caso de Uso: Solicitar Requerimiento

Se realiza el requerimiento de los productos para la
Descripción:
producción
 Entrega de guía de requerimientos
Flujo de eventos:
 Solicitar requerimientos
Tabla 3.3. Especificaciones de casos de Uso General – Entrega de materiales
Caso de Uso: Consultar requerimientos

Descripción: Se realiza la consulta de los productos solicitados
Flujo de eventos:  Consultar requerimientos
Tabla 3.4 Especificaciones de casos de Uso General – Entrega de materiales
Caso de Uso: Solicita atender solicitud

En este caso de uso se solicita al encargado de almacén que
Descripción:
atienda los requerimientos.
Flujo de eventos:  Entregar Guía
Caso de Uso: Realizar proceso de compra

Descripción: Proceso logístico
84
Caso de Uso: Registrar Ingreso de Materiales

En este caso de uso el encargado de almacén verifica que los
Descripción: materiales entregados sean igual a los materiales solicitados
en la guía de compra.
 Recepcionar Productos
Flujo de eventos:
 Crear guía de ingreso.
Caso de Uso: Entregar Materiales

Descripción: En este caso se registra la entrega de materiales
 Buscar producto
Flujo de eventos:  Registrar cantidad
 Crear guía de salida
Caso de Uso: Realizar Proceso de Exactitud de Inventarios

En este caso se solicita que se realice un inventario físico de
Descripción: los materiales y luego registrar en el sistema para así verificar
las variaciones en porcentaje.
 Buscar producto
Flujo de eventos:  Registrar cantidad
 Generar Reporte de ERI.
85
3.2.5.- Caso De Uso Entrega De Materiales
Registrar Salida de Materiales
almacen
Verificar los Materiales
Produccion
Devolución de Materiales
Anular guia de Salida
Figura 3.4: Caso De Uso Entrega De Materiales
86
3.2.6.- Caso De Uso Ingreso De Materiales
almacen
verificar Materiales de Compra
Proveedor
Registrar Ingreso de Materiales

Devolver Materiales
Figura 3.5 Caso De Uso Ingreso De Materiales
87
3.2.7.- Caso De Uso Realizar Proceso ERI
Generar Reporte de evaluacion de ERI
Generar listado de Stock de Materiales clasificado
Administrador Generar listado de materiales clasificado
Registrar inventario fisico de Materiales
Entregar Listado de Materiales
almacen
Figura 3.6 Caso De Uso Realizar Proceso ERI
88
3.2.8.- Diagrama de secuencias

3.2.8.1.- Diagrama de secuencia General
Sistema:Class_13
Produccion Logistica almacen Administrador Proveedor
Registra solicitud de requerimiento
Solicita requerimiento de Materiales
Consulta Requerimiento de Materiales
Consulta Existencia de Materiales
Si Existe Solicitar se Atienda los requerimientos
Realizar Proceso de Compra
Consulta Stock de Materiales
Si Existe realiza registro de salida de Materiales
Entrega los materiales requeridos
Generar guia de Compra
Entrega guia de Compra
Entrega Materiales de Compra
Verifica Materiales de Compra
Si Materiales Ok Registra Ingreso
Genera reporte Stock de Materiales Clasificado
Solicita realizar inventario Fisico
Realiza Inventario Fisico
Entrega stock Fisico de Materia Prima
Registra Stock Fisico de Materiales
Genera reporte de Exactitud de Registro de Inventarios
Toma Decisiones
Figura 3.7: Diagrama de secuencia General
89
3.2.8.2.- Diagrama de Secuencia Ingreso de Materiales
Sistema:Class_13
Logistica almacen Proveedor
Consulta Requerimiento de Materiales
Realiza Proceso de Compra
Generar Guia de Compra
Entrega Materiales de Compra
Verifica Materiales
Si, Materiales ok, registra ingreso
Figura3.8: Diagrama de Secuencia Ingreso de Materiales
90
3.2.8.3.- Diagrama de secuencia Entrega de Materiales
Sistema:Class_13
almacen Produccion
Consulta Stock de Materiales
Si Existe realiza registro de salida de Materiales
Entrega los materiales requeridos
Verificar Entrega de Materiales
Figura 3.9: Diagrama de secuencia Entrega de Materiales
91
3.2.8.4.- Diagrama de secuencia de exactitud de registros de inventario
Sistema:Class_13
Administrador almacen
Genera reporte Stock de Materiales Clasificado
Solicita realizar inventario Fisico
Realizar Inventario Fisico
Entrega stock Fisico de Materia Prima
Registra Stock Fisico de Materiales
Genera reporte de Exactitud de Registro de Inventarios
Tomar Decisiones
Figura 3.10: Diagrama de secuencia de exactitud de registros de inventario
92
3.3.- Diseño de interfase del sistema
3.3.1.- Ventana de acceso
Figura 3.11: Ventana de acceso
3.3.2.- Menú principal
Figura 3.12: Menú principal
93
3.3.3.- Menú Movimientos
Figura 3.13: Menú Movimientos
3.3.4.- Menú Mantenimiento
Figura 3.14: Menú Mantenimiento
94
3.3.5.- Menú Consultas
Figura 3.15: Menú Consultas
3.3.6.- Menú Reportes
Figura 3.16: Menú Reportes
95
3.3.7.- Menú Herramienta
Figura 3.17: Menú Herramienta
3.3.8.- Ventana de registro de Ingresos de Materia Prima
Figura 3.18: Ventana de registro de Ingresos de Materia Prima
96
3.3.9.- Guía de ingreso por compra.
Figura 3.19: Guía de ingreso por compra.
3.3.10.- Ventana de registro de Egresos de Materia Prima
Figura 3.20: Ventana de registro de Egresos de Materia Prima
97
3.3.11.- Guía de egreso por compra.
Figura 3.21: Guía de egreso por compra.
3.3.12.- Listado para el registro de Inventario Físico.
Figura 3.22: Listado para el registro de Inventario Físico.
98
3.3.13.- Ventana de Registro de Exactitud de Inventarios.
Figura 3.23: Ventana de Registro de Exactitud de Inventarios.
99
3.3.14.- Reporte de Registro de Exactitud de Inventarios.
Figura 3.24: Reporte de Registro de Exactitud de Inventarios.
3.3.15.- Registro de Proveedor
Figura 3.25: Registro de Proveedor
100
3.3.16.- Matriz Producto Proveedor.
Figura 3.26: Matriz Producto Proveedor.
3.3.17.- Ventana de Clasificación de Producto.
Figura 3.27: Ventana de Clasificación de Producto.
101
3.3.18.- Ventana de relación Área y Productos.
Figura 3.28: Ventana de relación Área y Productos.
3.3.19.- Consulta de Stock de Productos
Figura 3.29: Consulta de Stock de Productos
102
3.3.20.- Consulta de Precios de Productos por Proveedor
Figura 3.30: Consulta de Precios de Productos por Proveedor
103
3.4.- Reportes
3.4.1.- Reporte de los Movimientos realizados en el Almacén
Figura 3.31: Reporte de los Movimientos realizados en el Almacén
3.4.2.- Reporte General de los Movimientos realizados en el Almacén.
Figura 3.32: Reporte General de los Movimientos realizados en el Almacén.
104
3.4.3.- Cierre de Inventario
Figura 3.33: Cierre de Inventario
105
3.5.- Diagrama de Clases
Figura 3.34: Diagrama de Clases
106
3.6.- Diagrama Entidad Relación

Almacen
T_DOCUMENTO
cod_almacen char(2) <pk> not null
COD_DOC VARCHAR(2) <pk> not null
descripcion varchar(30) null
DESCRIPCION VARCHAR(30) null
Alm_Almacen_pk <pk> PER_TURNO
T_DOCUMENTO_PK <pk>
COD_TURNO VARCHAR(1) <pk> not null
DESCRIPCION VARCHAR(15) null
PER_TURNO_PK <pk>
ALM_MOVIMIENTOS_DETALLE
R_4
cod_tipo_movimiento char(1) <pk,fk1> not null
id char(10) <pk,fk1> not null R_5 R_9 R_8
alm_eri cod_almacen char(2) <pk,fk1> not null
alm_movimiento
nro char(3) <pk> not null
ID_ERI INT <pk> not null cod_movimiento char(2) <pk> not null
Alm_cod_almacen char(2) <fk3> null
FECHA_INICIAL datetime null descripcion varchar(50) null
cod_producto char(9) <fk2> null
FECHA_FINAL datetime null tipo char(1) null
cantidad decimal null
ESTADO_ACTUALIZACION bit null ALM_MOVIMIENTOS abreviatura varchar(11) null
precio decimal null
TIPO char(1) null sit char(1) null
precio_convertido decimal null COD_TIPO_MOVIMIENTO char(1) <pk> not null
ALM_ERI_PK <pk> codmon char(2) <fk4> null ALM_MOVIMIENTO_pk <pk>
id char(10) <pk> not null
sit_precio char(1) null cod_almacen char(2) <pk,fk2> not null
guia char(10) null cod_movimiento char(2) <fk3> null
codi_almacen char(10) null fecha_sistema datetime null
fecha datetime null R_6
R_12 R_1 cod_turno char(1) <fk5> null AREAS
ALM_MOVIMIENTOS_DETALLE_FK1 <ak> cod_personal char(8) null
ALM_MOVIMIENTOS_DETALLE_PK <pk> responsable varchar(50) null COD_AREA VARCHAR(2) <pk> not null
ALM_ERI_DETALLE observacion varchar(300) null NOM_AREA VARCHAR(40) null
ID_ERI int <pk,fk1> not null cod_area varchar(2) <fk4> null AREAS_PK <pk>
R_7
COD_PRODUCTO char(9) <pk,fk2> not null estado char(1) null
SALDO decimal null cod_doc varchar(2) <fk6> null
R_14
INGRESO decimal null cod_proveedor varchar(3) <fk1> null
STOCK decimal null nro_doc varchar(50) null
FISICO decimal null T_MONEDA fecha_registro datetime null
hora_registro char(20) null
ALM_ERI_DETALLE_pk <pk> CODMON char(2) <pk> not null usuario_registro varchar(50) null
DESCRIPCION varchar(10) null fecha_anula datetime null
SIGNO varchar(3) null hora_anula char(20) null
T_MONEDA_PK <pk> usuario_anula varchar(50) null
total decimal null
Subtipo_producto R_3 T_PAGO
subtotal decimal null
cod_subtipo_producto char(5) <pk> not null igv decimal null COD_PAGO VARCHAR(2) <pk> not null
plan_subdiv varchar(6) null NOM_PAGO VARCHAR(20) null
ALM_MOVIMIENTOS_PK <pk>
descripcion varchar(30) null
T_PAGO_PK <pk>
SUBTIPO_PRODUCTO_pk <pk> R_2
R_13
Proveedores
cod_proveedor varchar(3) <pk> not null
razonsocial varchar(100) null
abreviatura varchar(50) null R_10
R_11 ruc varchar(11) null
Producto
direccion varchar(60) null
cod_producto char(9) <pk> not null R16
telefono1 varchar(20) null
cod_subtipo_producto char(5) <fk> null telefono2 varchar(20) null
cod_tipo_medida char(3) null R15 Producto_Proveedor telefono3 varchar(20) null
descripcion varchar(150) null cod_producto char(9) <fk1> null fax varchar(10) null
abreviatura varchar(150) null cod_proveedor varchar(3) <fk2> null cod_pago varchar(2) <fk> null
stock_maximo decimal9(18,4) null plazo numeric5(3,0) null
punto_pedido decimal9(18,4) null contacto varchar(50) null
lote_compra decimal9(18,4) null pag_web varchar(30) null
tipo_clasificacion char(1) null email varchar(30) null
PRODUCTO_PK <pk> cargo varchar(50) null
PROVEEDORES_PK <ak>
Figura 3.35: Diagrama Entidad Relación
107
3.7.- Diagrama de Componentes
Figura 3.36: Diagrama de Componentes
108
3.8.- Diagrama de Despliegue
Figura 3.37: Diagrama de Despliegue
109
3.9.- Script Para La Generación Del Modelo De Datos

CREATE TABLE [dbo].[Producto] (
[cod_producto] [char] (9) AS NOT NULL ,
[cod_subtipo_producto] [char] (5) AS NOT NULL ,
[cod_tipo_medida] [char] (3) AS NULL ,
[descripcion] [varchar] (150) AS NULL ,
[cod_familia] [char] (2) AS NULL ,
[relacion_familia] [char] (2) AS NULL ,
[sit_reporte_estadistico] [char] (1) AS NULL ,
[cant_bandeja] [decimal](18, 0) NULL ,
[abreviatura] [varchar] (150) AS NULL ,
[porciones_pt] [decimal](18, 4) NULL ,
[subproducto] [char] (1) AS NULL ,
[orden] [decimal](18, 0) NULL ,
[Area] [varchar] (50) AS NULL ,
[tipo_compra] [varchar] (2) AS NULL ,
[sujeto_verificacion] [char] (2) AS NULL ,
[porc_merma] [decimal](18, 4) NULL ,
[dia_duracion] [decimal](18, 4) NULL ,
[ctd_proyectada] [decimal](18, 4) NULL ,
[stock_maximo] [decimal](18, 4) NULL ,
[cod_pt] [char] (9) AS NULL ,
[cod_area] [varchar] (2) AS NULL ,
[cod_pt_origen] [char] (2) AS NULL ,
[punto_pedido] [decimal](18, 4) NULL ,
[lote_compra] [decimal](18, 4) NULL ,
[PT_RELACION] [char] (9) AS NULL ,
[situacion] [char] (1) AS NULL ,
[especificacion] [varchar] (500) AS NULL ,
[reporte] [char] (1) AS NULL ,
[rel_formula] [char] (5) AS NULL ,
[sit_rel_formula] [char] (1) AS NULL ,
[sit_prod_proceso] [char] (1) AS NULL ,
[Alias] [varchar] (50) AS NULL ,
[tipo_clasificacion] [char] (1) AS NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Producto] WITH NOCHECK ADD

CONSTRAINT [PK_Producto] PRIMARY KEY CLUSTERED
(
[cod_producto]
) ON [PRIMARY]
GO
110
CREATE TABLE [dbo].[Subtipo_producto] (

[cod_subtipo_producto] [char] (5) AS NOT NULL ,
[plan_subdiv] [varchar] (6) AS NOT NULL ,
[descripcion] [varchar] (30) AS NOT NULL ,
[alm_mp] [char] (1) AS NULL ,
[alm_pp] [char] (1) AS NULL ,
[alm_pt] [char] (1) AS NULL ,
[orden] [decimal](18, 0) NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Subtipo_producto] WITH NOCHECK ADD

CONSTRAINT [PK_Subtipo_productos] PRIMARY KEY CLUSTERED
(
[cod_subtipo_producto]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Pod_Proveedores] (

[cod_proveedor] [varchar] (3) AS NOT NULL ,
[precio] [money] NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Pod_Proveedores] WITH NOCHECK ADD

CONSTRAINT [PK_Pod_Proveedores] PRIMARY KEY CLUSTERED
(
[cod_producto],
[cod_proveedor]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Pod_Proveedores] ADD

CONSTRAINT [DF_Pod_Proveedores_precio] DEFAULT (0) FOR [precio]
GO
ALTER TABLE [dbo].[Pod_Proveedores] ADD

CONSTRAINT [FK_Pod_Proveedores_Producto] FOREIGN KEY
(
[cod_producto]
) REFERENCES [dbo].[Producto] (
[cod_producto]
) ON DELETE CASCADE ON UPDATE CASCADE
GO
CREATE TABLE [dbo].[proveedores] (

[cod_proveedor] [varchar] (3) AS NOT NULL ,
[razonsocial] [varchar] (100) AS NULL ,
[abreviatura] [varchar] (50) AS NULL ,
111
[ruc] [varchar] (11) AS NULL ,

[direccion] [varchar] (60) AS NULL ,
[telefono1] [varchar] (20) AS NULL ,
[fax] [varchar] (10) AS NULL ,
[cod_pago] [varchar] (2) AS NULL ,
[plazo] [numeric](3, 0) NULL ,
[rubro] [numeric](2, 0) NULL ,
[sit] [numeric](2, 0) NULL ,
[contacto] [varchar] (50) AS NULL ,
[pag_web] [varchar] (30) AS NULL ,
[e_mail] [varchar] (30) AS NULL ,
[cargo] [varchar] (50) AS NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[proveedores] WITH NOCHECK ADD

CONSTRAINT [PK_proveedores] PRIMARY KEY CLUSTERED
(
[cod_proveedor]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[proveedores] ADD

CONSTRAINT [FK_proveedores_t_pago] FOREIGN KEY
(
[cod_pago]
) REFERENCES [dbo].[t_pago] (
[cod_pago]
) ON DELETE CASCADE ON UPDATE CASCADE
GO
CREATE TABLE [dbo].[t_pago] (

[cod_pago] [varchar] (2) AS NOT NULL ,
[nom_pago] [varchar] (20) AS NULL ,
[t_pago] [varchar] (2) AS NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[t_pago] WITH NOCHECK ADD

CONSTRAINT [PK__t_pago__24927208] PRIMARY KEY CLUSTERED
(
[cod_pago]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[per_Turno] (

[cod_turno] [varchar] (1) AS NOT NULL ,
[descripcion] [varchar] (15) AS NOT NULL
) ON [PRIMARY]
112
GO
ALTER TABLE [dbo].[per_Turno] WITH NOCHECK ADD

CONSTRAINT [PK_Turno] PRIMARY KEY CLUSTERED
(
[cod_turno]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[areas] (

[cod_area] [varchar] (2) AS NOT NULL ,
[nom_area] [varchar] (40) AS NULL ,
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[areas] WITH NOCHECK ADD

CONSTRAINT [PK_areas] PRIMARY KEY CLUSTERED
(
[cod_area]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[t_documento] (

[cod_doc] [varchar] (2) AS NOT NULL ,
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[t_documento] WITH NOCHECK ADD

CONSTRAINT [PK_t_documento] PRIMARY KEY CLUSTERED
(
[cod_doc]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Almacen] (

[cod_almacen] [char] (2) AS NOT NULL ,
[descripcion] [varchar] (30) AS NOT NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Almacen] WITH NOCHECK ADD

CONSTRAINT [PK_Almacen] PRIMARY KEY CLUSTERED
(
[cod_almacen]
) ON [PRIMARY]
GO
113
CREATE TABLE [dbo].[ALM_MOVIMIENTOS] (

[cod_tipo_movimiento] [char] (1) AS NOT NULL ,
[id] [char] (10) AS NOT NULL ,
[fecha_sistema] [datetime] NULL ,
[cod_turno] [char] (1) AS NULL ,
[cod_personal] [char] (8) AS NULL ,
[responsable] [varchar] (50) AS NULL ,
[observacion] [varchar] (300) AS NULL ,
[cod_area] [varchar] (2) AS NULL ,
[estado] [char] (1) AS NULL ,
[cod_proveedor] [varchar] (6) AS NULL ,
[cod_doc] [varchar] (2) AS NULL ,
[nro_doc] [varchar] (50) AS NULL ,
[fecha_registro] [datetime] NULL ,
[hora_registro] [char] (20) AS NULL ,
[usuario_registro] [varchar] (50) AS NULL ,
[fecha_anula] [datetime] NULL ,
[hora_anula] [char] (20) AS NULL ,
[usuario_anula] [varchar] (50) AS NULL ,
[fecha_devolucion_prestamo] [datetime] NULL ,
[total] [decimal](18, 4) NULL ,
[subtotal] [decimal](18, 4) NULL ,
[igv] [decimal](18, 4) NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[ALM_MOVIMIENTOS] WITH NOCHECK ADD

CONSTRAINT [PK_ALM_MOVIMIENTOS] PRIMARY KEY CLUSTERED
(
[id],
[cod_tipo_movimiento],
[cod_almacen]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[ALM_MOVIMIENTOS_DETALLE] (

[cod_tipo_movimiento] [char] (1) AS NOT NULL ,
[id] [char] (10) AS NOT NULL ,
[nro] [char] (3) AS NOT NULL ,
[cod_producto] [char] (9) AS NULL ,
[cantidad] [decimal](18, 4) NULL ,
[precio] [decimal](18, 4) NULL ,
[precio_convertido] [decimal](18, 4) NULL ,
[cod_mon] [char] (2) AS NULL ,
114
[sit_precio] [char] (1) AS NULL ,

[guia] [char] (10) AS NULL ,
[codi_almacen] [char] (10) AS NULL ,
[fecha] [datetime] NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[ALM_MOVIMIENTOS_DETALLE] WITH NOCHECK ADD

CONSTRAINT [PK_ALM_MOVIMIENTO_DETALLE] PRIMARY KEY
CLUSTERED
(
[cod_tipo_movimiento],
[id],
[cod_almacen],
[nro]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[t_moneda] (

[codmon] [varchar] (2) AS NOT NULL ,
[signo] [varchar] (3) AS NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[t_moneda] WITH NOCHECK ADD

CONSTRAINT [PK__t_moneda__22AA2996] PRIMARY KEY CLUSTERED
(
[codmon]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[ALM_ERI] (

[id_eri] [int] NOT NULL ,
[fecha_inicial] [datetime] NULL ,
[fecha_final] [datetime] NULL ,
[estado_actualizacion] [bit] NULL ,
[tipo] [char] (1) AS NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[ALM_ERI] WITH NOCHECK ADD

CONSTRAINT [PK_ALM_ERI] PRIMARY KEY CLUSTERED
(
[id_eri]
) ON [PRIMARY]
GO
115
CREATE TABLE [dbo].[alm_eri_Detalle] (

[id_eri] [int] NOT NULL ,
[saldo] [decimal](18, 4) NULL ,
[ingreso] [decimal](18, 4) NULL ,
[stock] [decimal](18, 4) NULL ,
[fisico] [decimal](18, 4) NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[alm_eri_Detalle] WITH NOCHECK ADD

CONSTRAINT [PK_alm_eri_Detalle] PRIMARY KEY CLUSTERED
(
[id_eri],
[cod_producto]
) ON [PRIMARY]
GO
116
Procedimientos Almacenados Para Listar
CREATE PROCEDURE mpsp_Listar_stock @valor varchar(2)

AS
SELECT TOP 100 PERCENT dbo.ALM_MOVIMIENTOS_DETALLE.cod_producto,
dbo.Producto.descripcion, SUM(CASE WHEN
ALM_MOVIMIENTOS_DETALLE.cod_tipo_movimiento = 'I'
OR ALM_MOVIMIENTOS_DETALLE.cod_tipo_movimiento = 'A' THEN cantidad ELSE
cantidad * - 1 END) AS STOCK
FROM dbo.ALM_MOVIMIENTOS_DETALLE INNER JOIN
dbo.ALM_MOVIMIENTOS
ON dbo.ALM_MOVIMIENTOS_DETALLE.id = dbo.ALM_MOVIMIENTOS.id AND
dbo.ALM_MOVIMIENTOS_DETALLE.cod_tipo_movimiento =
dbo.ALM_MOVIMIENTOS.cod_tipo_movimiento
AND dbo.ALM_MOVIMIENTOS_DETALLE.cod_almacen =
dbo.ALM_MOVIMIENTOS.cod_almacen INNER JOIN
dbo.Producto ON dbo.ALM_MOVIMIENTOS_DETALLE.cod_producto =
dbo.Producto.cod_producto
WHERE (dbo.ALM_MOVIMIENTOS.estado = '0') AND
(dbo.ALM_MOVIMIENTOS.cod_almacen = @valor)
GROUP BY dbo.ALM_MOVIMIENTOS_DETALLE.cod_producto,
dbo.Producto.descripcion
ORDER BY dbo.ALM_MOVIMIENTOS_DETALLE.cod_producto
GO
CREATE PROCEDURE mpsp_Listar_precio_x_proveedor @valor varchar(2)

AS
SELECT TOP 100 PERCENT dbo.ALM_MOVIMIENTOS.fecha_sistema,
dbo.ALM_MOVIMIENTOS_DETALLE.cantidad, dbo.t_moneda.signo,
dbo.ALM_MOVIMIENTOS_DETALLE.precio,
dbo.ALM_MOVIMIENTOS_DETALLE.precio_convertido,
dbo.ALM_MOVIMIENTOS.nro_doc, dbo.proveedores.cod_proveedor,
dbo.ALM_MOVIMIENTOS_DETALLE.cod_producto,
dbo.ALM_MOVIMIENTOS.id, dbo.ALM_MOVIMIENTOS.cod_doc,
dbo.Producto.descripcion,
dbo.t_documento.descripcion AS Expr1,
dbo.proveedores.razonsocial,dbo.ALM_MOVIMIENTOS.movimiento_cxp
FROM dbo.ALM_MOVIMIENTOS INNER JOIN dbo.ALM_MOVIMIENTOS_DETALLE
ON
dbo.ALM_MOVIMIENTOS.id = dbo.ALM_MOVIMIENTOS_DETALLE.id AND
dbo.ALM_MOVIMIENTOS.cod_tipo_movimiento
= dbo.ALM_MOVIMIENTOS_DETALLE.cod_tipo_movimiento AND
dbo.ALM_MOVIMIENTOS.cod_almacen =
dbo.ALM_MOVIMIENTOS_DETALLE.cod_almacen INNER JOIN dbo.proveedores ON
dbo.ALM_MOVIMIENTOS.cod_proveedor
= dbo.proveedores.cod_proveedor INNER JOIN dbo.Producto ON
dbo.ALM_MOVIMIENTOS_DETALLE.cod_producto =
dbo.Producto.cod_producto INNER JOIN dbo.t_moneda ON
dbo.ALM_MOVIMIENTOS_DETALLE.cod_mon = dbo.t_moneda.codmon
INNER JOIN dbo.t_documento ON dbo.ALM_MOVIMIENTOS.cod_doc =
dbo.t_documento.cod_doc WHERE
117
(dbo.ALM_MOVIMIENTOS.cod_tipo_movimiento = 'i') AND

(dbo.ALM_MOVIMIENTOS.cod_almacen = @VALOR) AND
(dbo.ALM_MOVIMIENTOS.estado = '0' OR dbo.ALM_MOVIMIENTOS.estado = '1')
GROUP BY dbo.ALM_MOVIMIENTOS.fecha_sistema,
dbo.ALM_MOVIMIENTOS.cod_tipo_movimiento,
dbo.ALM_MOVIMIENTOS_DETALLE.cantidad, dbo.t_moneda.signo,
dbo.ALM_MOVIMIENTOS_DETALLE.precio,
dbo.ALM_MOVIMIENTOS_DETALLE.precio_convertido,
dbo.ALM_MOVIMIENTOS.nro_doc, dbo.proveedores.cod_proveedor,
dbo.ALM_MOVIMIENTOS.id, dbo.ALM_MOVIMIENTOS.cod_doc ,
dbo.Producto.descripcion, dbo.t_documento.descripcion,
dbo.proveedores.razonsocial,dbo.ALM_MOVIMIENTOS.movimiento_cxp ORDER BY
dbo.ALM_MOVIMIENTOS.fecha_sistema DESC
CREATE PROCEDURE mpsp_Listar_los_registros_ERI @valor varchar(2)

AS
SELECT dbo.alm_eri_Detalle.cod_producto, dbo.alm_eri_Detalle.saldo,
dbo.alm_eri_Detalle.ingreso, dbo.alm_eri_Detalle.stock, dbo.alm_eri_Detalle.fisico,
dbo.Producto.descripcion , dbo.Producto.cod_subtipo_producto,
dbo.Subtipo_producto.plan_subdiv
FROM dbo.alm_eri_Detalle INNER JOIN dbo.Producto ON
dbo.alm_eri_Detalle.cod_producto =
dbo.Producto.cod_producto INNER JOIN dbo.Subtipo_producto ON
dbo.Producto.cod_subtipo_producto =
dbo.Subtipo_producto.cod_subtipo_producto
WHERE (dbo.alm_eri_Detalle.id_eri = @valor)
GROUP BY dbo.alm_eri_Detalle.cod_producto, dbo.alm_eri_Detalle.saldo,
dbo.alm_eri_Detalle.ingreso,
dbo.alm_eri_Detalle.stock, dbo.alm_eri_Detalle.fisico, dbo.Producto.descripcion,
dbo.Producto.cod_subtipo_producto,
dbo.alm_eri_Detalle.id_eri, dbo.Subtipo_producto.plan_subdiv
118
CAPÍTULO IV
DISCUSIÓN
119
4.1 Contrastación De La Hipótesis
En el presente capitulo trataremos la discusión y prueba de la hipótesis

planteada, es decir, se demostrara que la hipótesis da solución al problema,
para ello nos basaremos en los resultados obtenidos luego de haber realizado
el análisis y diseño del sistema informático.
La hipótesis:
El desarrollo de un Sistema informático permite mejorar y controlar de
manera adecuada el almacén de materias primas en la Empresa Productos
Kerry’s S.R.L.
Variable Independiente
Desarrollo de un sistema informático
Variable Dependiente
Mejor Control del almacén de materias primas
4.1.1.- Conclusión De La Discusión

Se concluye que la hipótesis “El desarrollo de un Sistema
informático permite mejorar y controlar de manera adecuada el almacén
de materias primas en la Empresa Productos Kerry’s S.R.L.” ha
quedado demostrado por sí su validez de acuerdo a los resultados
obtenidos. (Ver Anexo 06).
120
CONCLUSIONES
- Se definió el modelo de negocio, los diversos diagramas UML y el modelo

entidad/relación mediante la herramienta Power Designer.
- Con el modelo entidad/relación se pudo generar la documentación y los scripts

para la generación de la Base de Datos, tablas, store procedure y funciones, lo
cual nos facilitará un posible mantenimiento o modificación del sistema.
- El desarrollar el sistema en una arquitectura cliente/servidor permitió tener la

información centralizada y de fácil uso, acceso al usuario, contando con una
seguridad en el control de los usuarios, evitando de esta manera una mala
manipulación en la información.
- Con el desarrollo del sistema se reducirá los tiempos de generación de

reportes, lo cual aligera la carga de trabajo de los usuarios, permitiendo que
estos realicen otras funciones u otras tareas.
121
RECOMENDACIONES
- Para solucionar la problemática analizada, se recomienda Implementar este

Sistema en el menor tiempo posible.
- Para el análisis, diseño y desarrollo de un sistema de información se

recomienda utilizar la herramienta Power designer, lo cual proyectará un mejor
entendimiento de los requerimientos al investigador.
- Se recomienda implementar el sistema y permitir brindar al usuario final

información de uso y dar a conocer las bondades y ventajas de este sistema.
- Se debe integrar el sistema a los demás procesos de la empresa para que la

información pueda ser más rica y así explotar en reportes que puedan permitir
tomar decisiones acertadas.
- Se recomienda mejorar los procesos de producción y controlar los productos

necesarios para elaborar los productos terminados a través de un sistema de
Formulaciones.
122
REFERENCIAS BIBLIOGRAFICAS
[ANA91] Análisis y diseño de sistemas

Kendall y Kendall
Derechos Reservados © 1991 2ª Edición
Prentice-Hall Hispanoaméricana S.A.
[ELL99] El lenguaje Unificado de Modelamiento

Booch Grady y Otros
Addisson Wesley España
[EST99] Estadística elemental. Lo esencial

Jonson, Robert.
Kuby Patricia
Internacional Thomson Editores, S.A. de C.V.
[ING93] Ingeniería del Software. Un enfoque Práctico

Roger S. Pressman
Mc Graw-Hill
[JAC99] The Unified Software Development Process

JACOBSON y Otros
Addison-Wesley, Massachusetts, United States of America.
Direcciones Electrónicas
[ALM01] Conceptos de Almacén

http://www.monografias.com/trabajos12/alma/alma.shtml
[WIK01] Conceptos de Información
123
http://es.wikipedia.org/wiki/Informaci%C3%B3n
[WIK02] Conceptos de Sistema

http://es.wikipedia.org/wiki/sistem
[WIK03] Conceptos de Sistema de Información

http://es.wikipedia.org/wiki/Sistema_de_informaci%C3%B3n
[CON01] Proceso de Desarrollo RUP

www.conganat.org/Seis/inforsalud04/2004_Inforsalud_TutorialUML-UP.doc
[FAQ01] Información acerca de la Herramienta Visual Basic.

http://www.faq-mac.com/microsoft/?p=326
[SQL01] SQL SERVER 2000

www.zonagratuita.com/microsoft/asp/sql_server.htm
[PWD01] Power Designer

http://www.mtbase.com/productos/modelamientometadatos/powerdesig
ner
124
ANEXOS
125
GENERALIDADES
1. TIPO DE INVESTIGACIÓN
 De acuerdo al fin que se persigue : Aplicada

 De acuerdo del diseño de la investigación : Experimental
2. DURACIÓN DE EJECUCIÓN DEL PROYECTO
Para el curso de titulación : 12 SEMANAS

 Inicio : 22/04/2007
 Fin : 22/09/2007
3. INSTITUCIÓN EN DONDE SE EJECUTARÁ EL PROYECTO
3.1. LOCALIDAD
 Departamento : Lima
 Provincia : Lima
 Distrito : Surquillo
3.2. EMPRESA
Productos Kerry’s S.R.L.
Calle José Neyra 295
126
4. CRONOGRAMA DE TRABAJO
Abril Mayo Junio Julio Agosto Septiembre
4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Elaboración del Plan de
Proyecto de
1 Investigación
Recopilación del Material

2 Bibliográfico
Análisis del Sistema de
Control de los Derechos
3 Mineros
Diseño de la interfaz y
de la base de datos,
4 Duración del Sistema
5 Desarrollo del Sistema
Documentación del
6 Sistema
Tabla A1: Cronograma de Trabajo
127
5. RECURSOS
5.1. Personal
 Bachiller Cárdenas Oscata Jesús Antonio
 Bachiller Sanca Balbín Roger
5.2. Bienes
5.2.1. Equipos :
 Computadoras
 Impresora
5.2.2. Software :
 Microsoft Word
 Power Designer
 Visual Basic
 SQL Server
 Crystal Reports
5.2.3. Materiales :
 Tinta de impresora
 Libros
 Papel Bond 80 gr.
 Lapiceros
 Discos compactos
5.3. Servicios
 Energía eléctrica
 Teléfono fijo y móvil
 Cabina Internet
 Servicios de imprenta
 Servicios de fotocopiado
128
6. PRESUPUESTO
Descripción Cantidad Precio Total (S/.)

Personal 0.00
Bienes
 Equipos 1430.00
o Computadoras 02 615.00
o Impresoras 01 200.00
 Software 0.00
o Visual Basic 02 0.00
o SQL Server 2000 01 0.00
o Crystal Reports 01 0.00
Materiales 232.50
 Tinta de impresora 02 30.00
 Libros 02 60.00
 Papel Bond 80 gr. (Millar) 01 30.00
 Lapiceros 05 1.50
 Discos compactos 10 1.50
Servicios 436.00
 Energía eléctrica (Mensual) 04 4.00
 Teléfono fijo y móvil (Tarjetas) 02 30.00
 Movilidad 01 120.00
 Cabina Internet (Horas) 60 1.50
 Servicios de empastado 04 25.00
 Servicios de fotocopiado 500 0.10
TOTAL DE PRESUPUESTO 2,098.50
Tabla A2: Presupuesto
129
7. FINANCIAMIENTO
El Financiamiento del proyecto será con Recursos Propios del grupo de investigación.
8. Cuadro de Beneficio Costo
Hardware Cantidad Costo (S/.) Subtotal (S/.)

Servidor Base de Datos 1* 0,00 0,00
Servidor de Archivo 1* 0,00 0,00
Computadoras Personales 2* 0,00 0,00
Subtotal (S/.) 0,00
Software Cantidad Costo (S/.) Subtotal (S/.)

SQL Server 2000 1* 0,00 0,00
Visual Studio .Net 2005 2* 0,00 0,00
Crystal Reports XI 2* 0,00 0,00
Power Designer 1* 0,00 0,00
Subtotal (S/.) 0,00
Personal Cantidad Costo (S/.) Subtotal (S/.)

Analista 1 5000,00 5000,00
Programador 2 3500,00 7000,00
Ténico Redes 1 0,00 0,00
Subtotal (S/.) 12.000,00
Total (S/.) 12.000,00
* La empresa ya cuenta con estos Hardware y Licencias de los Software
Tabla A3: Cuadro de Beneficio Costo
130
ARQUITECTURA PRELIMINAR DEL SISTEMA

Se describió como arquitectura preliminar basada en los requerimientos
mínimos en hardware y software como se muestra en la tabla N° x
ARQUITECTURA PRELIMINAR DEL SISTEMA

COMPONENTE TIPO IMPLEMENTACION
HARDWARE CLIENTE 1. Procesador Pentium IV de

1.8Ghz.
2. Memoria de 256 Mb Ram
SERVIDOR 3. Procesador
Disco Duro de 40 Gb IV de
Pentium
3.6 Mhz
 Memoria de 1 Gb Ram
 Disco Duro 120 Gb.
Software CLIENTE  Windows Xp.
SERVIDOR  Windows 2000 Server

 Sql Server 2000
Tabla A4: Arquitectura Preliminar del Sistema
131

Uladech Biblioteca Virtual Invetnatrio

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Uladech Biblioteca Virtual Invetnatrio

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDAD LOS ÁNGELES DE CHIMBOTE

Sistema Informático De Control De Inventario De Materias

Bachiller JESÚS ANTONIO CÁRDENAS OSCATA

Ingeniero WILLIAM VÁSQUEZ VARGAS

Tesis Para Optar El Título De Ingeniero De Sistemas

UNIVERSIDAD LOS ÁNGELES DE CHIMBOTE

Sistema Informático De Control De Inventario De Materias

Ing. William Vásquez Vargas Ing. Bogar Mantilla Gordillo

Ing. Oscar Ascón Valdivieso

Este trabajo va dedicado a mis padres

Ingº Jesús Antonio Cárdenas Oscata.

La vida nos enseña en el camino lo

Ingº Roger Sanca Balbín.

A la Universidad Los Ángeles de

Jesús Cárdenas – Roger Sanca.

SEÑORES MIEMBROS DEL JURADO

Nos presentamos ante ustedes con la finalidad de cumplir con lo dispuesto en el

Consideramos oportuno agradecer de manera anticipada las apreciaciones y

Chimbote, Setiembre 2007.

SISTEMA INFORMÁTICO DE CONTROL DE INVENTARIO DE MATERIAS PRIMAS

El presente Trabajo muestra el análisis y desarrollo del prototipo de un sistema

Capítulo I.- Describe la realidad problemática de la empresa, Antecedentes,

Capítulo II.- Para el mejor entendimiento y comprensión se ha adicionado algunos

Capítulo III.- Este capítulo abarca todo lo concerniente al requerimiento, análisis,

Capítulo IV.- En este capítulo se realiza la contrastación de la Hipótesis y se acota las

COMPUTER SYSTEM CONTROL OF INVENTORY OF RAW MATERIALS USED

Chapter I.- It describes the problematic reality of the company, Antecedents,

- Basic Concepts of Warehouse and their function and importance of having

CAPÍTULO I: PLAN DE INVESTIGACIÓN

CAPÍTULO II: FUNDAMENTO TEÓRICO

2.1.5 Función de recepción ............................................................................ 10

2.8.- Power Designer................................................................................................. 50

CAPÍTULO III: RESULTADOS

3.1.- Descripción de la Organización ......................................................................... 59

3.2.8.3.- Diagrama de secuencia Entrega de Materiales ..................... 76

CAPÍTULO IV: DISCUSIÓN

Conclusión de la discusión ....................................................................................... 105

CONCLUSIONES .................................................................................................... 106

Tabla 2.1: Elementos de construcción en UML .......................................................... 23

Figura 2.1: Diagrama de Clases ................................................................................. 23

Figura 3.17: Menú Herramienta ................................................................................. 81

La empresa Productos Kerry’s S.R.L. debido a su crecimiento tiene como finalidad

El sistema ha desarrollar servirá como herramienta donde realizarán los registros de

El sistema tendrá diversas opciones que permitan obtener la información necesaria

1.1.1.- ANTECEDENTES DEL PROBLEMA

Actualmente en el mercado existen diferentes paquetes de software y

En productos KERRY’S S.R.L. se evaluaron los diferentes software que existen

La motivación para desarrollar este proyecto surgió de los problemas

Teniendo en cuenta esta situación, la compañía requería de la implementación

1.1.2.- REALIDAD PROBLEMÁTICA

Productos KERRY’S S.R.L. Viene desempeñando sus actividades en la ciudad

Almacén de materias primas, área encargada del control de los inventarios,

El área de administración como responsable del control de los inventarios, no

De acuerdo a la competitividad creciente y desarrollo en tecnología de

seguridad, interfaz gráfica amigable, multiusuario que proporciona información clara,

1.1.4.- ASPECTO TECNOLÓGICO.

Brindará a la empresa Productos Kerry’s S.R.L. un soporte de información

El desarrollo de un sistema informático robusto y confiable, amigable y con

1.1.5.- ASPECTO ECONOMICO.

Proporcionará a la empresa Productos Kerry’s S.R.L. aumentar sus utilidades,

1.1.6.- ASPECTO OPERATIVO

Permitirá registrar los movimientos de ingresos y salidas de materia prima de

Permitirá reducir los errores de cálculos y obtener datos confiables.

¿Cómo el desarrollo del Sistema informático de control de inventario de