Documentacion TFG Luis Alfredo Padilla Falon Julio PDF

UNIVERSIDAD PRIVADA CUMBRE
FACULTAD DE CIENCIAS Y TECNOLOGÍA

INGENIERIA DE SISTEMAS
SISTEMA DE INFORMACION PARA LA GESTION DE

INVENTARIO DE LA EMPRESA TIGRE SA. PARA LA SUCURSAL
EN LA CIUDAD DE COBIJA - PANDO.
AUTOR
LUIS ALFREDO PADILLA FALON
TRABAJO DE GRADO
PRESENTADO COMO REQUISITO PARCIAL
PARA OBTENER EL GRADO DE LICENCIATURA EN
INGENIERÍA DE SISTEMAS
TUTOR: Ing. Amílkar Cruz Herbas
Santa Cruz de la Sierra – Bolivia

2018
Dedicatoria.
Dedicada a ti mi Dios por darme cada día una nueva oportunidad de poder
continuar con tus planes que tienes para mi vida. Gracias Dios.
Lleno de a amor, regocijo y esperanza dedico este proyecto a mis padres.
Pedro Padilla Ovando y Rufina Falon. Quienes fueron mi apoyo en todo momento,
gracias por su confianza y apoyo.
Es para mí una gran satisfacción poder dedicarles a ellos que con mucho esfuerzo,
esmero y trabajo me lo he ganado.
Agradecimiento.
Mi agradecimiento se dirige a quien ha forjado mi camino y me ha dirigido por el

sendero correcto, a Dios, el que en todo momento está conmigo ayudándome a
aprender de mis errores. Eres quien ha guiado mi camino en la vida.
Te doy las gracias padre celestial.
Mi agradecimiento a mis Padres por darme la vida y apoyo en todo momento, gracias por
su ayuda, comprensión y colaboración.
A la Universidad, por impartirnos conocimientos y sobre todo valores y principios como

personas y profesionales para que juntos podamos tener un futuro y un país mejor.
Y en especial a nuestro Director de Carrera Ing. Amílkar Cruz Herbas

quien nos apoyó constantemente en el transcurso del trabajo de investigación y nos supo
dirigir en nuestro trabajo, quien con sus sabios consejos supo orientarnos para que nuestro
trabajo de investigación se lo realice de la mejor manera.
A los Docentes, por su tiempo y dedicación en impartirnos el conocimiento para ser

mejores personas aportando nuestros conocimientos y habilidades a la sociedad cada
momento de nuestra vida diaria.
Un agradecimiento cordial a la Empresa Tigre Plasmar por haberme permitido desarrollar

mi trabajo de investigación y darme todas las facilidades en cuanto a la información
requerida para realizar la investigación.
Luis Alfredo Padilla Falon
I
RESUMEN
TITULO Sistema de información para la gestión de inventario para la sucursal

en la Ciudad de Cobija del Departamento de Pando para la empresa
“Tigre SA.” de la Ciudad de Santa Cruz de la Sierra.
AREA DE
INVESTIGACION Desarrollo de software, análisis de arquitectura de software.
TIPO DE ESTUDIO Descriptivo Explicativo
La investigación propuesta busca, mediante la aplicación de la teoría

ELEMENTOS DE y los conceptos básicos del Proceso Unificado de Desarrollo de
CONTENIDO Software implementar las nuevas tecnologías el proceso de gestión de
datos para obtener la información requerida por la empresa, encontrar
explicaciones a situaciones internas (información de clientes,
información de personal, etc.) y del entorno (información de ingresos
y salidas de productos, gestión de inventario, etc.) que afectan a la
empresa. Esto permitirá al personal de almacén de la empresa
contrastar diferentes conceptos de inventario en una realidad
concreta.
CONTENIDO
La necesidad de control de inventario de productos nace y crece a

medida que se tiene una diversidad productos, a razón de llevar un
ANTECEDENTES control de ingresos y salidas se ve la manera de poder facilitar el
trabajo de control de los productos es que nace el requerimiento. Los
gustos y necesidades de los clientes, más la forma de adquirir los
productos, han ido cambiando con el tiempo, así como también la
II
forma de ofertas de productos por parte de las empresas, por tal razón
se debe agilizar el proceso de oferta productos y poder a su vez tener
un control rápido para no tener dificultades cuando los productos se
terminan, y se tenga la facilidad de tener reportes de acuerdo a las
necesidades de las empresas.
Los problemas dentro de la sucursal de la empresa se deben a que el
PLANTEAMIENTO registro de cada ingreso y salida se demora en generación de
DEL comprobantes y no se tiene la información adecuada y rápida cuando
PROBLEMA se lo requiere como ser: la entrega de mercadería a los clientes, así
como toda información en los productos de la empresa se realiza de
forma manual. Por lo tanto, se debe automatizar los procesos de
administración de información.
Desarrollar un sistema de información para la gestión de inventario
OBJETIVO GENERAL para la sucursal en la Ciudad de Cobija del Departamento de Pando
para la empresa “Tigre SA.” de la Ciudad de Santa Cruz de la Sierra.
Con la herramienta de gestión de inventarios y gestión de ingresos y
JUSTIFICACIÓN salidas permiten encontrar soluciones concretas a problemas de
gestión de automatización en los resultados de la empresa y se facilita
a tener una información ordenada que al momento de hacer consultas
se tiene datos claros y precisos.
La estructura del presente estudio es la siguiente:
CONTENIDO Capítulo I Introducción.
Capítulo II, Marco Teórico.
Capítulo III, Materiales y métodos
Capítulo IV, Modelo de análisis.
Capítulo V, Modelo estructural.
Capítulo VI, Modelo de implementación
Capítulo VII, Modelo de pruebas
Finalmente, las conclusiones y recomendaciones.
III
INDICE GENERAL
1. INTRODUCCIÓN ......................................................................................................... 1
1.1 ANTECEDENTES ....................................................................................................... 1
1.1.1 ANTECEDENTES DE LA EMPRESA .................................................................... 1

1.1.2 ANTECEDENTES DEL OBJETO DE ESTUDIO ................................................... 3
1.2 DEFINICIÓN DEL PROBLEMA ............................................................................... 3
1.2.1 FORMULACIÓN DEL PROBLEMA....................................................................... 3

1.2.2 DESCRIPCIÓN DEL PROBLEMA .......................................................................... 3
1.3 PROPUESTA ............................................................................................................... 4
1.4 OBJETIVOS ................................................................................................................ 4
1.4.1 OBJETIVO GENERAL ............................................................................................. 4

1.4.2 OBJETIVOS ESPECÍFICOS .................................................................................... 4
1.5 DELIMITACION ......................................................................................................... 5
1.5.1 DELIMITACION ESPACIAL .................................................................................. 5

1.5.2 DELIMITACION DE CONTENIDO ........................................................................ 5
1.5.2.1 ACTIVIDADES QUE NO SE TOMARAN EN CUENTA .................................. 6
1.5.3 DELIMITACIÓN TEMPORAL ................................................................................ 6
1.6 JUSTIFICACIÓN ........................................................................................................ 6
1.6.1 JUSTIFICACIÓN TEÓRICA .................................................................................... 6

1.6.2 JUSTIFICACIÓN ACADÉMICA ............................................................................. 6
1.6.3 JUSTIFICACIÓN PRÁCTICA ................................................................................. 7
1.7 DISEÑO METODOLÓGICO ...................................................................................... 8
1.7.1 TIPO DE INVESTIGACIÓN .................................................................................... 8

1.7.1.1 INVESTIGACIÓN CUANTITATIVA .................................................................. 8
1.7.2 METODOLOGÍA ...................................................................................................... 8
1.7.3 RECOPILACION DE INFORMACIÓN................................................................... 9
IV
1.8 PLANIFICACIÓN ....................................................................................................... 9
1.8.1 PLAN DE PROYECTO............................................................................................. 9

1.8.3 RECURSOS ............................................................................................................. 16
1.8.3.1 EQUIPO DE DESARROLLO ............................................................................. 16
1.8.3.2 EQUIPO DE IMPLEMENTACIÓN .................................................................... 16
2 MARCO TEÓRICO ...................................................................................................... 18
2.1 UML (LENGUAJE UNIFICADO DE MODELADO) ............................................ 18
2.1.1 VENTAJAS DE LA UNIFICACIÓN ..................................................................... 18
2.1.2 OBJETIVOS EN EL DISEÑO DE UML ............................................................... 18
2.1.3 ¿POR QUÉ MODELAMOS? ................................................................................. 19
2.1.4 UTILIDAD DEL MODELADO ............................................................................. 19
2.1.5 DIAGRAMA DE CASOS DE USO ....................................................................... 20
2.1.6 DIAGRAMA DE CLASES..................................................................................... 20
2.1.7 DIAGRAMA DE SECUENCIA ............................................................................. 20
2.1.8 DIAGRAMA DE COLABORACIÓN .................................................................... 21
2.1.9 DIAGRAMA DE ESTADOS ................................................................................. 21
2.1.10 DIAGRAMA DE ACTIVIDADES....................................................................... 22
2.1.11 DIAGRAMA DE PAQUETES ............................................................................. 22
2.1.12 DIAGRAMAS DE COMPONENTES.................................................................. 23
2.1.13 DIAGRAMA DE DESPLIEGUE ......................................................................... 23
2.2. PROCESO UNIFICADO DE DESARROLLO (PUD) ............................................ 23
2.2.1 EL PROCESO UNIFICADO TIENE DOS DIMENSIONES ................................ 24
2.2.2 EL PROCESO UNIFICADO ES DIRIGIDO POR CASOS DE USO ................... 24
2.2.3 EL PROCESO UNIFICADO ESTÁ CENTRADO EN LA ARQUITECTURA ... 25
V
2.2.4 ITERATIVO INCREMENTAL .............................................................................. 26
2.3 TECNOLOGÍA Y ARQUITECTURA....................................................................... 27
2.3.1 ARQUITECTURA 3 CAPAS. ................................................................................ 27
2.3.1.1 VENTAJAS.......................................................................................................... 27
2.3.1.2 BENEFICIOS DE LA ARQUITECTURA EN 3 CAPAS ................................... 27
2.3.1.3 INTERFAZ DE PROGRAMACIÓN DE APLICACIONES API

(APPLICATION PROGRAMMING INTERFACE) ......................................................... 28
2.3.1.4 CAPA DE PRESENTACIÓN, VISTA ................................................................ 28
2.3.1.5 CAPA DE NEGOCIO, CONTROLADORES ..................................................... 29
2.3.1.6 CAPA DE DATOS, MODELO ........................................................................... 29
2.3.2. TECNOLOGÍA .NET ........................................................................................... 30
2.3.2.1. EL FRAMEWORK .NET ................................................................................. 31
2.3.2.2. ADO.NET ........................................................................................................... 32
2.3.2.3 C# .NET ............................................................................................................. 35
2.3.4 ENTERPRISE ARCHITECT ................................................................................ 35
2.3.5 REPORT VIEWER ............................................................................................... 37
2.3.6 GESTIÓN DE BASE DE DATOS ......................................................................... 38
2.3.6.1 EL LENGUAJE DDL .......................................................................................... 38
2.3.6.2 EL LENGUAJE DML.......................................................................................... 39
2.3.6.3 SQL .................................................................................................................... 40
2.3.6.4. SGBD .................................................................................................................. 41
2.3.7 MICROSOFT SQL SERVER ............................................................................... 43
2.3.7.1 CARACTERÍSTICAS ......................................................................................... 43
2.3.7.2 PROGRAMACIÓN ............................................................................................. 44
VI
2.3.7.3 TIPOS DE DATOS .............................................................................................. 44
2.3.7.4 PROCEDIMIENTOS ALMACENADOS ........................................................... 45
2.3.8 MICROSOFT VISUAL ESTUDIO ....................................................................... 45
2.3.8.1 VISUAL STUDIO 2013 .................................................................................... 46
2.3.9 START UML ........................................................................................................ 47
3 MATERIALES Y MÉTODOS ..................................................................................... 49
3.1.1 DESCRIPCIÓN DE LOS PROCESOS DE NEGOCIO .......................................... 49

3.1.2 IDENTIFICACIÓN DE LOS USUARIOS QUE REALIZAN EL PROCESO ...... 50
3.2 DIAGRAMA DE ACTIVIDAD ................................................................................. 51
3.2.1 DIAGRAMA DE ACTIVIDAD 1 INGRESO ........................................................ 51
3.2.2 DIAGRAMA DE ACTIVIDAD 2 SALIDA ..............................................................

........................................................................................................................ 52
3.2.3 DIAGRAMA DE ACTIVIDAD 3 GESTION DE PRODUCTO ...............................

........................................................................................................................ 53
3.3 DIAGRAMA DEL MODELO DE DOMINIO .......................................................... 54

3.4 REQUERIMIENTOS DE SOFTWARE .................................................................... 55
3.4.1 REQUISITOS FUNCIONALES ............................................................................. 55
3.4.2 REQUISITOS NO FUNCIONALES ...................................................................... 57
3.5 LISTADO DE CASOS DE USO ............................................................................... 59
3.5.1 DEFINICIÓN DE ACTORES Y SUS FUNCIONES ............................................. 60
3.6 DIAGRAMA DE CLASES........................................................................................ 62
4 MODELO DE ANÁLISIS ............................................................................................ 64
4.1 ANÁLISIS DE LA ARQUITECTURA ..................................................................... 64
4.1.1 IDENTIFICACIÓN DE LOS PAQUETES ............................................................ 64
4.2 ESPECIFICACIONES DE LOS CASOS DE USO ................................................... 65
VII
4.2.1 DESCRIPCIÓN DEL CASO DE USO GESTIONAR CLIENTE ......................... 65
4.2.2 DIAGRAMA DE COLABORACIÓN GESTIONAR CLIENTE .......................... 66
4.3.1 DESCRIPCIÓN DEL CASO DE USO GESTIONAR PROVEEDOR .................. 66
4.3.2 DIAGRAMA DE COLABORACIÓN GESTIONAR PROVEEDOR ................... 67
4.4.1 DESCRIPCIÓN DEL CASO DE USO GESTIONAR PRODUCTO .................... 67
4.4.2 DIAGRAMA DE COLABORACIÓN GESTIONAR PRODUCTO ..................... 68
4.5.1 DESCRIPCIÓN DEL CASO DE USO GESTIONAR INGRESO MERCADERÍA .

........................................................................................................................ 69
4.5.2 DIAGRAMA DE COLABORACIÓN GESTIONAR INGRESO MERCADERÍA ..

........................................................................................................................ 70
4.6.1 DESCRIPCIÓN DE CASO DE USO GESTIÓN DE USUARIO .......................... 70
4.6.2 DIAGRAMA DE COLABORACIÓN DE GESTIÓN DE USUARIO .................. 71
4.7.1 DESCRIPCIÓN DE CASOS DE USO: GESTIÓN DE SALIDA .......................... 72
4.7.2 DIAGRAMA DE COLABORACIÓN: GESTIÓN DE SALIDA .......................... 73
4.8.1 DESCRIPCIÓN DE CASOS DE USO: GESTIÓN DE PRIVILEGIOS ................ 73
4.8.2 DIAGRAMA DE COLABORACIÓN DE CASOS DE USO: GESTIÓN DE

PRIVILEGIOS ................................................................................................................... 74
4.9.1 DESCRIPCIÓN DE CASOS DE USO: GESTIÓN DE CATEGORÍA ................. 74

CATEGORÍA ..................................................................................................................... 75
4.10.1 DESCRIPCIÓN DE CASOS DE USO: GESTIÓN DE REPORTE CLIENTE ... 76

REPORTE CLIENTE ......................................................................................................... 77
4.11.1 DESCRIPCIÓN DE CASOS DE USO: GESTIÓN DE REPORTE PROVEEDOR

........................................................................................................................ 77
VIII
REPORTE PROVEEDOR ................................................................................................. 78
4.12.1 DESCRIPCIÓN DE CASOS DE USO: GESTIÓN DE REPORTE PRODUCTOS

........................................................................................................................ 78

REPORTE PRODUCTOS.................................................................................................. 79
4.13.1 DESCRIPCIÓN DE CASOS DE USO: GESTIÓN DE REPORTE DIARIO,

MENSUAL, ANUAL Y ENTRE FECHAS DE INGRESO SALIDA. ............................ 79

REPORTE DIARIO, MENSUAL, ANUAL Y ENTRE FECHAS. ................................... 80
4.14.1 DESCRIPCIÓN DE CASOS DE USO: GESTIÓN DE PERSONA .................... 80
5 MODELO ESTRUCTURAL ........................................................................................ 83
5.1 MODELO DE DISEÑO ............................................................................................. 83
5.1.1 MODELO RELACIONAL ...................................................................................... 83

5.1.3 MODELO FÍSICO DE LA BASE DE DATOS ...................................................... 84
5.2 DIAGRAMAS E INTERFAZ DE LOS CASO DE USO ........................................... 88
6 MODELO DE IMPLEMENTACION ........................................................................ 109
6.1. MODELO DE COMPONENTES ........................................................................... 109
6.1.1 ARQUITECTURA DEL SISTEMA ..................................................................... 109
6.2 DIAGRAMA DE DESPLIEGUE ............................................................................. 113
7 MODELO DE PRUEBA............................................................................................. 115
7.1 CONCEPTO DE PRUEBA DE SOFTWARE ......................................................... 115

7.2 DISEÑO DE CASOS DE PRUEBA ........................................................................ 116
7.2.1 PRUEBA DE CASO DE USO DEL SISTEMA ................................................... 116
7.3 DESCRIPCION DE CASO DE USO DE PRUEBA DEL SISTEMA ..................... 117
7.3.1.1 CASO DE USO: GESTIONAR INGRESO DE MERCADERIA ..................... 119
IX
7.3.1.2 FLUJO DE EVENTOS ...................................................................................... 121
7.4 DESCRIPCION DE CASO DE USO DE PRUEBA DEL SISTEMA ..................... 123
7.4.1.1 CASO DE USO: GESTIONAR SALIDA DE MERCADERIA........................ 124
7.4.1.2 FLUJO DE EVENTOS ...................................................................................... 126
CONCLUSIONES ......................................................................................................... 128
RECOMENDACIONES ................................................................................................ 129
BIBLIOGRAFIA............................................................................................................ 130
ANEXOS........................................................................................................................ 132
X
INDICE DE FIGURAS
Figura #1.- Gestor Base de Datos .......................................................................................... 7
Figura #2.- Visual Studio ....................................................................................................... 7
Figura #3.- Plan de desarrollo. Elaboración propia en Ms. Proyect. ................................... 14
Figura #4.- Arquitectura 3 capas ......................................................................................... 28
Figura #5.- Detalle del funcionamiento de la programación en 3 capas.............................. 30
Figura #6.- Funcionalidad de la plataforma .NET ............................................................... 31
Figura #7.- Diagramador UML Enterprise Architect .......................................................... 35
Figura #8.- ReportViewer .................................................................................................... 37
Figura #9.- Microsoft SQL Server ....................................................................................... 43
Figura#10.- Visual Estudio 2013 ......................................................................................... 46
Figura #11.- Diagrama de actividad de ingreso de mercadería ........................................... 51
Figura #12.- Diagrama de actividad de salida de mercadería .............................................. 52
Figura #13.- Diagrama de actividad de Gestión de Productos ............................................ 53
Figura #14.- Diagrama del modelo de dominio ................................................................... 54
Figura #15.- Definición de Actores y sus funciones........................................................... 60
Figura #16.- Diagrama de Casos de Uso General ................................................................ 61
Figura#17 Diagrama de clases ............................................................................................. 62
Figura #18.- Análisis de la arquitectura – Diagrama de Paquetes ....................................... 64
Figura #19.- Diagrama de colaboración Gestionar Cliente ................................................. 66
Figura #20.- Diagrama de colaboración gestionar Proveedor ............................................. 67
Figura #21.- Diagrama de colaboración gestionar Producto ............................................... 68
Figura #22.- Diagrama de colaboración Gestionar ingreso mercadería .............................. 70
Figura #23.- Diagrama de colaboración gestionar usuario .................................................. 71
XI
Figura #24.- Diagrama de colaboración: Gestión de salida ................................................. 73
Figura #25.- Diagrama de colaboración de casos de uso: Gestión de Privilegios ............... 74
Figura #26.- Diagrama de colaboración de casos de uso: Gestión de Categoría ................. 75
Figura #27.- Diagrama de colaboración de casos de uso: Gestión de reporte cliente ......... 77
Figura #28.- Diagrama de colaboración de casos de uso: Gestión de reporte proveedor .... 78
Figura #29.- Diagrama de colaboración de casos de uso: Gestión de reporte productos .... 79
Figura #30.- Diagrama de colaboración de casos de uso: Gestión de reporte diario,

mensual, anual y entre fechas. .............................................................................................. 80
Figura #31.- Diagrama de colaboración de casos de uso: Gestión de Persona .................... 81
Figura #32.- Modelo relacional ........................................................................................... 83
Figura #33 Diagrama de secuencia Gestionar Cliente ......................................................... 88
Figura # 34 Interfaz gráfica gestionar cliente. ..................................................................... 89
Figura #35 Diagrama de secuencia Gestionar Proveedor .................................................... 90
Figura #36 Interfaz grafica gestionar Proveedor ................................................................. 91
Figura #37 Diagrama de secuencia Gestionar Producto ...................................................... 92
Figura #38 Interfaz gráfica gestionar producto.................................................................... 93
Figura #39 Diagrama de secuencia Gestionar Usuario ........................................................ 94
Figura #40 Interfaz grafica gestionar usuario ...................................................................... 95
Figura #41 Diagrama de secuencia Gestionar Privilegio..................................................... 95
Figura #42 Interfaz grafica Gestionar Privilegio ................................................................. 96
Figura #43Diagrama de secuencia Gestionar Ingresos ........................................................ 97
Figura #44 Interfaz de gestion de ingresos .......................................................................... 98
Figura #45 Diagrama de secuencia Gestionar Salida .......................................................... 99
Figura #46 Interfaz gestion de salida ................................................................................. 100
XII
Figura #47 Diagrama de secuencia Gestionar Categoría ................................................... 101
Figura #48 Interfaz gestion de categoria ........................................................................... 101
Figura #49 Diagrama de secuencia Gestionar Reporte Cliente ......................................... 102
Figura #50 Interfaz reporte Cliente.................................................................................... 102
Figura #51 Diagrama de secuencia Gestionar Reporte Proveedor .................................... 103
Figura #52 Interfaz reporte proveedor ............................................................................... 103
Figura #53 Diagrama de secuencia Gestionar Reporte Producto ...................................... 104
Figura #54 Interfaz reporte productos ............................................................................... 104
Figura #55 Gestionar Reportes de Ingresos y Salidas ....................................................... 105
Figura #56 Interfaz de reporte de ingreso de mercadería .................................................. 105
Figura #57 Gestionar Persona ............................................................................................ 106
Figura #58 Gestionar Persona ............................................................................................ 107
Figura #59.- Arquitectura del sistema ............................................................................... 109
Figura #60 Modelo de Componentes Cliente .................................................................... 110
Figura #61 Modelo de Componentes Proveedor ............................................................... 110
Figura #62 Modelo de Componentes Producto ................................................................. 111
Figura # 63 Modelo de Componentes Categoría ............................................................... 111
Figura # 64 Modelo de Componentes Categoría ............................................................... 112
Figura #65 Diagrama de despliegue .................................................................................. 113
Figura #66 Login de acceso al sistema .............................................................................. 116
Figura #67 Menu Principal del sistema ............................................................................. 117
Figura #68 Ingreso de mercaderia listado .......................................................................... 118
Figura #69 Ingreso de mercaderia registro ........................................................................ 118
Figura #70 Listado de salida de mercaderia listado........................................................... 123
XIII
Figura #71 Registrar salida de mercaderia registro. .......................................................... 124
Figura #72 Reporte de clientes de la empresa ................................................................... 132
Figura # 73 Reporte de Proveedores de la empresa ........................................................... 132
Figura #74 Grafico de salida de mercaderia. ..................................................................... 133
Figura #75 Grafico de salida de mercaderia por fechas. ................................................... 133
Figura #76 Comprobante de trabajo dirigido por la empresa. ........................................... 134
XIV
Índice de Cuadros
1. Tabla.- Distribución de tiempos e iteraciones. ........................................................ 9
2. Tabla. - Hitos de las fases de desarrollo ................................................................ 11
3. Tabla. - Cronograma general Proyecto. ................................................................ 13
4. Tabla. - Descripción de los Procesos de Negocio ................................................. 50
5. Tabla. - Listado de Requisitos Funcionales .......................................................... 56
6. Tabla. - listado requisitos No Funcionales ............................................................ 58
7. Tabla. - Listado de casos de uso............................................................................. 59
8. Tabla.- Descripción del Caso de Uso Gestionar Cliente ........................................ 65
9. Tabla. - Descripción del caso de uso gestionar proveedor ..................................... 67
10. Tabla.- Diagrama de colaboración gestionar Proveedor ........................................ 68
11. Tabla.- Descripción del Caso de Uso Gestionar ingreso mercadería ..................... 69
12. Tabla. - Descripción de caso de uso gestión de Usuario ........................................ 71
13. Tabla.- Descripción de casos de uso: Gestión de salida ......................................... 72
14. Tabla.- Descripción de casos de uso: Gestión de Privilegios ................................. 74
15. Tabla.- Descripción de casos de uso: Gestión de Categoría .................................. 75
16. Tabla.- Descripción de casos de uso: Gestión de reporte cliente ........................... 76
17. Tabla.- Descripción de casos de uso: Gestión de reporte proveedor ..................... 77
18. Tabla.- Descripción de casos de uso: Gestión de reporte productos ...................... 78
19. Tabla. - Descripción de casos de uso: Gestión de reporte diario, mensual, anual y
entre fechas de ingreso salida. .............................................................................................. 80
20. Tabla.- Caso de uso: Gestionar ingreso de mercaderia. ....................................... 120
21. Tabla.- Flujo de Evento ingreso de mercadaderia ................................................ 122
22. Tabla.- Caso de uso: Gestionar ingreso de mercaderia. ....................................... 125
23. Tabla. - Flujo de Evento ingreso de mercadería .................................................. 127

Capítulo I
INTRODUCCION
CAPÍTULO I INTRODUCCIÓN
1. INTRODUCCIÓN
1.1 ANTECEDENTES
1.1.1 ANTECEDENTES DE LA EMPRESA
La empresa Tigre SA. Es una multinacional Brasileña, líder en los diversos mercados en los
que actúa, Tigre es sinónimo de pionerismo e innovación. La marca ofrece productos que
atienden los mercados prediales, de infraestructura, de riego e industrial. El grupo está
presente en aproximadamente 40 países, posee siete mil funcionarios, 9 plantas en Brasil y
13 en el exterior. Además de tubos y conexiones, también forman parte del portafolio las
marcas Claris Soluções em Esquadrias, Tigre Herramientas para Pintura, tuberías de PEAD
(Polietileno de Alta Densidad) para saneamiento y drenaje.
La empresa Tigre SA. Es una empresa sólida en el mercado nacional con una planta de
producción en, Santa Cruz de la Sierra, y también cuenta con 2 sucursales en la Ciudad de
la Paz y la Ciudad del Alto, en la fabricación de tubos y conexiones en las líneas eléctricas
y drenaje.
Tigre pone a las personas en primer lugar. Y eso resume prácticamente todo: la formación
de los profesionales, que corresponden a miles por año, el relacionamiento estrecho y fiel
son los aliados de negocios y el profundo conocimiento de las necesidades y deseos de los
consumidores. Esas son las fuentes para la perpetuidad del negocio, con la creación de
soluciones innovadoras para la construcción de un mundo mejor, de modo permanente.
1
Ya son 75 años de historia en los que Tigre SA. Es la multinacional brasileña líder en su
mercado de actuación, conocida en soluciones innovadoras que hacen la diferencia en las
construcciones y reformas de millones. Considera que el lugar donde las personas viven
puede ser siempre mejor y, por ello, trabaja para que el desagüe tratados sean accesibles a
todos. La empresa es la más conocida y respetada en el sector de la construcción, la
industria, es la más amiga del comerciante, referencia en calidad e innovación.
Propósito
Crear soluciones innovadoras para el mundo de la construcción.
Visión
Estamos seguros de que el lugar donde las personas viven puede ser siempre mejor.
Confianza
Productos referencia en el mercado de la construcción, con calidad insuperable y soluciones

completas, garantizando tranquilidad en todo tipo de obra.
Relacionamiento
La marca aliada de todos nuestros públicos (clientes, revendedores, profesionales de la obra

y colaboradores), reconocida por construir relaciones próximas y verdaderas.
Sostenibilidad
Entendiendo su papel en el mundo y en la sociedad, a través del desarrollo y promoción de

acciones sostenibles y de responsabilidad social.
Uno de los principales valores del Grupo Tigre es la inquebrantable creencia en las
personas, en su capacidad de relacionarse y de llevar a cabo de un equipo que, muchas
veces, se reconoce como una verdadera familia.
2
1.1.2 ANTECEDENTES DEL OBJETO DE ESTUDIO
Se llevara a cabo en la sucursal de distribución de la Empresa Tigre SA. En la ciudad de

Cobija del departamento de Pando, actualmente manejan sus datos en planillas Excel, guías
de salida, notas de entrega, notas de recepción, toda esta información generada diariamente
es almacenada en Cóndor por fechas, es moroso y pérdida de tiempo al realizar una
búsqueda de información, quitando la productividad del personal ante un requerimiento por
la empresa o el cliente.
La información generada en documentos en papel corre el riesgo de pérdida por factores

humanos o también verse afectada por factores climáticos como ser la lluvia.
Debido a la ampliación de su mercado la empresa se vio en la necesidad de llevar el control

de inventarios, ingresos y salidas de mercadería en dicha sucursal por el cual se ve en la
necesidad de obtener un sistema de información que realice un control de inventario, de
ingresos y salidas y poder tener un informe a través de reportes por día, mes, año y entre
periodos de fechas.
1.2. DEFINICIÓN DEL PROBLEMA
1.2.1. FORMULACIÓN DEL PROBLEMA
¿Cuáles son los factores que le imposibilitan a la empresa “TIGRE SA.” tener un mayor
control preciso de su inventario?
1.2.2. DESCRIPCIÓN DEL PROBLEMA
✓ Demora en la verificación de cantidades de ingreso y salida de los productos.-

Al momento de realizar un reporte, consultar el total de ingreso y salidas no se
puede tener una información rápida.
✓ No tener una guía de entregas digitales.- Eso hace que no se tenga la información
cuando se quiere verificar la salida de algún cliente en una determinada fecha.
3
✓ Falta de control de conformidad que el cliente recibe la mercadería en buen

estado.- Al no tener un sistema de información que realice el control no se puede
consultar de manera fácil y rápida la verificación de la cantidad y el estado en que
se entrega la mercadería al cliente.
✓ No tener datos oportunos y claros.- para que la empresa pueda tomar las medidas
correspondientes en sus ingresos y salidas de mercadería en su nueva sucursal en la
zona franca de Cobija.
1.3 PROPUESTA
Se propone el desarrollo de un sistema de información para la gestión de inventario que

dará solución a la necesidad en la nueva sucursal de la empresa donde se requiere tener la
información adecuada y oportuna en el momento adecuado, de los ingresos y salidas de
mercadería.
1.4. OBJETIVOS
1.4.1. OBJETIVO GENERAL
Desarrollar un sistema de información de inventario y control de mercadería para la gestión

de ingresos y salidas de la sucursal en la ciudad de cobija de la empresa Tigre SA.
1.4.2. OBJETIVOS ESPECÍFICOS

✓ Analizar el ingreso y procesamiento de la información de planificación empresarial.
✓ Diseñar un modelo que se adapte a los requerimientos de información de la
empresa.
✓ Documentar los modelos de análisis, diseño e implementación según PUD.
✓ Desarrollar el sistema con arquitectura 3 capas mediante los requerimientos
obtenidos en la empresa a través de datos obtenidos en las reuniones y consultas de
la empresa Tigre SA. Con el encargado del área de sistemas.
✓ Realizar pruebas del sistema de información, para llegar a la aplicación terminada
mediante la corrección de errores detectados y así poder garantizar la información
que se genere.
4
✓ Implementar el sistema con toda la capacidad operacional del producto en la nueva

sucursal de la empresa Tigre SA. En la Ciudad de Cobija.
1.5. DELIMITACION
1.5.1. DELIMITACION ESPACIAL
El lugar para la implementación es la sucursal de la zona franca de Cobija, el lugar para

hacer pruebas se las realizara en empresa Tigre SA. Se encuentra ubicada en la ciudad de
Santa Cruz Parque Industrial Pi 22, tigre.com.bo, (591) (33) 3147210 - 3147272, el
desarrollo del presente sistema se lo desarrollará en domicilio particular, se visitará la
empresa en la oficina central en la ciudad de Santa Cruz para tomar datos de los procesos y
actividades, se coordinará con el ingeniero de sistemas Antonio Fernando García Rivera,
todos los procedimientos se coordinará con él.
Una vez completado el sistema solicitado, se realizará la implementación en la ciudad de

cobija zona franca.
1.5.2. DELIMITACION DE CONTENIDO
De las actividades de almacén, ingresos y salidas de mercadería se desarrollará e

implementará las siguientes:
✓ Gestión y seguimiento de los productos que ingresan a la sucursal.
✓ Se desarrollarán las actividades de gestión y seguimiento de productos, ingresos,
salidas y movimientos.
✓ Gestión de clientes, que se obtendrá datos principales de contacto.
✓ Con el software en funcionamiento se tendrá datos de la cantidad de ingreso y salida

de mercadería en el día, mes, año, entre fechas, stock de los artículos, los
movimientos del producto, y así poder consultar cuales son los productos que más
salen, así tener datos estadísticos y tomar previsiones futuras.
✓ Todas las actividades a tomar en cuenta esta en el acta de conformidad anexada.
5
1.5.2.1. ACTIVIDADES QUE NO SE TOMARAN EN CUENTA
No se tomará en cuenta la facturación, consultas web de productos, porque el sistema a

implementar es un sistema de control de ingreso y salida de la mercadería que un cliente
solicita, el desarrollo principal del proyecto estará basado en lo que se tiene firmado en el
acta de conformidad anexada.
1.5.3. DELIMITACIÓN TEMPORAL
El Proyecto tiene una estimación de duración de 6 meses, se comienza el 18 de diciembre

de 2017 con el desarrollo del Modelo de Negocio, y se pretende entregar el software en
funcionamiento el 15 de junio de 2018.
1.6. JUSTIFICACIÓN
1.6.1. JUSTIFICACIÓN TEÓRICA
El proyecto permitirá automatizar los ingresos y salidas de mercadería de la Empresa Tigre

SA., en especial en la nueva sucursal de la zona franca de Cobija, contribuyendo así al
mejoramiento de la imagen de la empresa y otras áreas brindando información confiable y
precisa y así realizar una mejor gestión en las nuevas instalaciones.
Este sistema también podrá ser adaptado a cualquier empresa que requiera el sistema de
inventario y stock, de esta manera se convierte en un producto que puede ser
comercializado en un futuro dentro del área de gestión e inventario de ingresos y salida de
mercadería.
1.6.2. JUSTIFICACIÓN ACADÉMICA
El desarrollo de este software este guiado por PUD (Proceso unificado de Desarrollo),
UML (Lenguaje Unificado de Modelado), que son estándares para poder tener un software
de calidad y confiabilidad.
El desarrollo de este software y la documentación servirá de guía de estudio para futuras

consultas, y de referencia en desarrollo de similares proyectos.
6
1.6.3. JUSTIFICACIÓN PRÁCTICA
Para el desarrollo del presente proyecto se utilizara las herramientas confiables y

reconocidas internacionalmente.
El gestor de base de datos Microsoft SQL Server 2014, que es confiable y seguro de fácil
manejo.
El lenguaje de programación C# de Microsoft Visual Studio 2013 que cumple las normas
estándar de desarrollo y tiene todas las herramientas necesarias para el desarrollo de manera
práctica y ordenada.
Figura #1.- Gestor Base de Datos
Figura #2.- Visual Studio
7
1.7. DISEÑO METODOLÓGICO
1.7.1. TIPO DE INVESTIGACIÓN
1.7.1.1. INVESTIGACIÓN CUANTITATIVA
La investigación cuantitativa se basa en el estudio y análisis de la realidad a través de

diferentes procedimientos basados en la medición. Permite un mayor nivel de control e
inferencia que otros tipos de investigación, siendo posible realizar experimentos y obtener
explicaciones contrastadas a partir de hipótesis. Los resultados de estas investigaciones se
basan en la estadística y son generalizables.
Por ejemplo, las investigaciones en matemáticas puras, es normal no preocuparse por la

facilidad con la que se pueden aplicar las conclusiones obtenidas.
La toma de requisitos se las obtendrá con entrevistas a las personas encargadas de la

empresa y así tener información clara y precisa de la solución a ofertar.
Para la documentación y desarrollo se tomará en cuenta las normas de desarrollo, notación

UML y metodología PUD.
1.7.2. METODOLOGÍA
El desarrollo del presente proyecto utilizara la metodología de Proceso Unificado de

Desarrollo de Software.
Mediante la aplicación de esta metodología se da a conocimiento la siguiente proposición

para la estructura del documento final, la misma que es el resultado de n iteraciones:
En el Modelo de requerimientos se desarrollarán los requerimientos funcionales y no

funcionales, casos de uso y modelo de dominio del sistema.
En el Modelo de Análisis se desarrollará el modelo análisis de la arquitectura y diagramas

de colaboración del sistema.
En el Modelo de Diseño del sistema se desarrollarán los Diagramas de despliegue, diseño

físico de la base de datos y diagramas de clases de diseño.
En el Modelo de Implementación se desarrollará el modelo de despliegue de componentes.
8
En el modelo de pruebas se realizarán Pruebas del Sistema para obtener la aplicación

terminada del mismo.
El ciclo de vida del proyecto constará de dos iteraciones en la fase de Inicio, tres iteraciones
en la fase de Elaboración, dos iteraciones en la fase de construcción y dos iteraciones en la
fase de Transición del sistema.
1.7.3. RECOPILACION DE INFORMACIÓN
Los datos de las actividades y procesos a cubrir se las realizara a través de entrevistas con
la persona encargada de sistemas Antonio García Cel. 76696757.
Se utilizará el internet como guía para búsqueda de conceptos y otra información que se
requiere.
Entrevistas a las personas encargadas de la gestión de inventario de la empresa, para así

tomar los procedimientos que realizan en las actividades diarias con esto se logra que el
sistema se adapte a sus necesidades.
1.8. PLANIFICACIÓN
1.8.1. PLAN DE PROYECTO

✓ Plan de las fases
El desarrollo se llevará a cabo en base a fases con una o más iteraciones en cada una de
ellas. La siguiente tabla muestra la distribución de tiempos y el número de iteraciones de
cada fase (para las fases de Construcción y Transición es sólo una aproximación muy
preliminar)
FASE N° ITERACIONES DURACION
FASE DE INICIO 1 4 SEMANAS
FASE ELABORACION 2 7 SEMANAS
FASE CONSTRUCCION 2 4 SEMANAS
FASE TRANCISION 2 3 SEMANAS

1. Tabla.- Distribución de tiempos e iteraciones.
9
ESCRIPCION HITO
FASES N° ACTIVIDADES
INTERACIONES
En esta fase se desarrollará los requisitos del

software desde la perspectiva del usuario, los
cuales serán establecidos en el artefacto
Visión. Los principales casos de uso serán
FASE INICIO 1 identificados y se hará un refinamiento del
Plan de Desarrollo del Proyecto. La
aceptación del cliente/usuario del artefacto
Visión y el Plan de Desarrollo marcan el
final de esta fase.
En esta fase se analizan los requisitos y se

desarrolla un prototipo de arquitectura Al
final de esta fase, todos los casos de uso
FASE correspondientes a requisitos que serán
2
ELABORACION implementados en Análisis/Diseño). La
revisión y aceptación del prototipo de la
arquitectura del sistema marca el final de esta
fase.
Durante la fase de construcción se terminan

de analizar y diseñar todos los casos de uso,
refinando el Modelo de Análisis/Diseño. El
producto se construye en base a 2 iteraciones,
FASE
2 cada una con pruebas y se valida con el
CONTRUCCION
cliente/usuario. Se comienza la elaboración
de material de apoyo al usuario. El hito que
marca el fin de esta fase es la versión beta,
con toda la capacidad operacional del
10
producto, lista para ser entregada a los

usuarios para pruebas beta.
En esta fase se preparará el sistema para

distribución, asegurando una implantación y
cambio del sistema previo a una aplicación
terminada de manera adecuada, incluyendo el
FASE entrenamiento de los usuarios. El hito que marca
2
TRANSICION el fin de esta fase incluye, la entrega de toda la
documentación del proyecto con los manuales de
instalación y todo el material de apoyo al usuario,
la finalización del entrenamiento de los usuarios,
el empaquetamiento soporte temporal.
2. Tabla. - Hitos de las fases de desarrollo
✓ Cronograma del proyecto
A continuación, se tiene un cronograma general del proyecto en el cual a un principio no se

tenía el desglose completo de las tareas a efectuarse, el cronograma fue actualizado y
reajustado a los tiempos previstos a medida que las tareas se fueron identificando.
11
ID NOMBRE TAREA DURACION
1 FASE DE INICIO 21 Días
2 Iteración I1: Dominio de Información plan Proyecto 21
3 Modelo de Negocio 5
4 Modelo de Requisitos 7
5 Gestión de Proyecto 8
6 FASE DE ELABORACION 70 Días
7 Iteración E1: 40
10 Modelo de Diseño 20
12 Iteración E2: 30
16 Modelo de Implementación 3
17 Modelo Pruebas 3
19 FASE DE CONSTRUCCION 20 Días
20 Iteración C1: 10
12
23 Modelo Pruebas 2
24 Iteración C2: 10
27 Modelo Pruebas 2
28 FASE DE TRANSICION 16 Días
29 Iteración T1: 8
32 Modelo Pruebas 2
34 Iteración T2: 8
3. Tabla. - Cronograma general Proyecto.
13
✓ Cronograma por Fechas
El proyecto comenzará el 18 de dijembre del 2017 y se estima que llegará hasta obtener una
versión Beta el 04-05-2018 del producto, el proyecto concluirá alrededor del 15/06/2018 de
acuerdo a la fecha de entrega y a los nuevos requerimientos e iteraciones.
Ver diagrama de Gant pag. 15
Figura #3.- Plan de desarrollo. Elaboración propia en Ms. Proyect.
14
1.8.3. RECURSOS
Los recursos que se utilizaran para el desarrollo del sistema son las siguientes herramientas:
1.8.3.1 Equipo de desarrollo

Para el desarrollo se utilizó un equipo con las siguientes características:
Procesador : Core i5
RAM : 8 Gb
Disco duro : 1 Tb
Monitor : 17”
Software que se utilizaran:
Sistema Operativo: Windows 10 64 Bits.
Microsoft office, SQL Server 2014, Microsoft Visual Studio 2013 en leguaje de
programación C#, Enterprice Architect, COCOMOII, Star UML.
1.8.3.2 Equipo de implementación
La empresa tiene servidores para el software a implementar, lo que se necesita un equipo

cliente desde el cual se ingresaran o registraran datos.
Para la implementación se requiere un equipo con las siguientes características:

Procesador : Dual Core
RAM : 2 Gb
Disco duro : 250 Gb
Monitor : 19”
Impresoras.
Software que se utilizaran:
Sistema Operativo: Windows 7 o superior, 32 o 64 Bits.
Adobe Reader, Microsoft Office, SQL Server.
16
Capítulo II
MARCO TEÓRICO
CAPITULO II MARCO TEÓRICO
2 MARCO TEÓRICO
1
2.1 UML (LENGUAJE UNIFICADO DE MODELADO)
Es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que
comprende el desarrollo de software. UML entrega una forma de modelar cosas
conceptuales como lo son procesos de negocio y funciones de sistema, además de cosas
concretas como lo son escribir clases en un lenguaje determinado, esquemas de base de
datos y componentes de software reusables.
UML es comparable a los planos usados en otros campos y consiste en diferentes tipos de
diagramas. En general, los diagramas UML describen los límites, la estructura y el
comportamiento del sistema y los objetos que contiene.
2.1.1 VENTAJAS DE LA UNIFICACIÓN
✓ Reunir los puntos fuertes de cada método.
✓ Idear nuevas mejoras.
✓ Proporcionar estabilidad al mercado.
✓ Proyectos basados en un lenguaje maduro.
✓ Aparición de potentes herramientas.
✓ Eliminar confusión en los usuarios.
2.1.2 OBJETIVOS EN EL DISEÑO DE UML
Modelar sistemas, desde los requisitos hasta los artefactos ejecutables, utilizando técnicas
Orientadas a Objetos.
Cubrir las cuestiones relacionadas con el tamaño propio de los sistemas complejos y
críticos. Encontrar equilibrio entre expresividad y simplicidad.
1
(Larman, 2 EDICION)
18
2.1.3 ¿POR QUÉ MODELAMOS?
Construimos modelos para comprender mejor el sistema que estamos desarrollando.
Cuatro utilidades de los modelos:
✓ Visualizar cómo es o queremos que sea el sistema.
✓ Especificar la estructura y comportamiento del sistema.
✓ Proporcionan plantillas que guían la construcción del sistema.
✓ Documentan las decisiones.
✓ Equivalen a los planos de un edificio.
Una empresa software con éxito es aquella que produce de manera consistente software de
calidad que satisface las necesidades de los usuarios.
El modelado es la parte esencial de todas las actividades que conducen a la producción de

software de calidad.
Un modelo es una simplificación de la realidad.
2.1.4 UTILIDAD DEL MODELADO
Se facilita la comunicación entre el equipo al existir un lenguaje común.
Se dispone de documentación que trasciende al proyecto.
✓ Permite especificar todas las decisiones de análisis, diseño e implementación,

construyéndose modelos precisos, no ambiguos y completos.
✓ UML puede conectarse a lenguajes de programación:
✓ Ingeniería directa e inversa.
✓ Permite documentar todos los artefactos de un proceso de desarrollo (requisitos,

arquitectura, pruebas, versiones).
19
2.1.5 DIAGRAMA DE CASOS DE USO
✓ Captura los requisitos de un sistema. Los casos de uso son un medio de

comunicación con los usuarios y otros interesados acerca de lo que se piensa hacer
del sistema.
✓ Nombre y Descripción: Se nombra como una frase verbal y se le da una

descripción textual informal.
✓ Requisitos: Los requisitos definen los requisitos funcionales formales que un caso
de uso debe proveer al usuario final.
✓ Restricciones: Una restricción es una condición o restricción bajo la cual opera un

caso de uso y que incluye pre, y post condiciones y condiciones invariantes.
✓ Escenarios: Un escenario es una descripción formal del flujo de eventos que

ocurren durante la ejecución de una instancia de casos de uso.
✓ Diagramas de escenarios: Información adicional.
2.1.6 DIAGRAMA DE CLASES
Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el
sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenido.
Elementos
✓ Clase: Atributos, métodos y visibilidad (public+, private-, protected#).
✓ Relaciones: Herencia, composición, agregación, asociación y Uso.
2.1.7 DIAGRAMA DE SECUENCIA
Es una forma de diagrama de interacción que muestra los objetos como líneas de vida a lo
largo de la página y con sus interacciones en el tiempo representadas como mensajes
dibujados como flechas desde la línea de vida origen hasta la línea de vida destino.
Los diagramas de secuencia son buenos para mostrar qué objetos se comunican con qué
otros objetos y qué mensajes disparan esas comunicaciones. Los diagramas de secuencia no
están pensados para mostrar lógicas de procedimientos complejos.
20
2.1.8 DIAGRAMA DE COLABORACIÓN
Inicialmente llamado un diagrama de colaboración, es un diagrama de interacción que

muestra información similar a los diagramas de secuencia, pero su foco principal es en la
relación de objetos.
En los diagramas de comunicaciones, los objetos como se muestran con conectores de

asociación entre ellos. Los mensajes se agregan a las asociaciones y se muestran como
flechas cortas apuntando en la dirección del flujo del mensaje. La secuencia de los
mensajes se muestra a través de un esquema enumerado.
2.1.9 DIAGRAMA DE ESTADOS
Modela el comportamiento de un solo objeto, especificando la secuencia de eventos que un

objeto atraviesa durante su tiempo de vida en respuesta a los eventos.
Un diagrama de estados, en ocasiones conocido como diagrama de máquina de estados, es

un tipo de diagrama de comportamiento en el Lenguaje Unificado de Modelado (UML). Se
especializa en mostrar transiciones entre diversos objetos.
Una máquina de estados es todo lo que pueda tener diferentes estados. En muchos casos,
cuando hablamos de estados, hablamos de los diferentes estados de un objeto. Los
diagramas complejos pueden tener muchos estados diferentes. Para entender mejor objetos
difíciles, en ocasiones tiene sentido entender todos los diferentes estados posibles de un
objeto y cómo llega el objeto a ese estado. Los estados son las diferentes combinaciones de
información que puede contener un objeto y no cómo se comportan.
Cada diagrama de estado generalmente empieza con un círculo oscuro que indica el estado
inicial y termina con un círculo con un contorno blanco que denota el estado final. Sin
embargo, a pesar de tener puntos de inicio y finalización definidos, se debe recordar que los
diagramas de estado no necesariamente son la mejor herramienta para plasmar un
desarrollo general de eventos. En lugar de ello, se especializan en ilustrar tipos específicos
de comportamiento en particular, cambios de un estado a otro.
21
2.1.10 DIAGRAMA DE ACTIVIDADES
Se usa para mostrar la secuencia de actividades. Los diagramas de actividades muestran el

flujo de trabajo desde el punto de inicio hasta el punto final detallando muchas de las rutas
de decisiones que existen en el progreso de eventos contenidos en la actividad. Estos
también pueden usarse para detallar situaciones donde el proceso paralelo puede ocurrir en
la ejecución de algunas actividades. Los Diagramas de Actividades son útiles para el
Modelado de Negocios donde se usan para detallar el proceso involucrado en las
actividades de negocio.
2.1.11 DIAGRAMA DE PAQUETES
Se usan para reflejar la organización de paquetes y sus elementos. Cuando se usan para
representaciones, los diagramas de paquete de los elementos de clase se usan para proveer
una visualización de los espacios de nombres. Los usos más comunes para los diagramas de
paquete son para organizar diagramas de casos de uso y diagramas de clase, a pesar de que
el uso de los diagramas de paquete no es limitado a estos elementos UML.
Combinación de Paquetes: Cuando un conector «merge» se usa en un paquete, la fuente de

la combinación importa los contenidos importados y anidados del destino. Si existe un
elemento dentro del origen y el destino, las definiciones del elemento origen se expandirán
para incluir las definiciones del elemento contenidas en el destino. Todos los elementos
agregados o actualizados por una combinación se notan por una relación de generalización
desde el origen hasta el destino.
Importación de paquetes: El conector «import» indica que los elementos dentro del paquete
destino, que en este ejemplo es una sola clase, se importarán al paquete origen. El espacio
de nombre del paquete origen ganará acceso a la Clase/s de Destino; el espacio de nombre
del destino no está afectado.
Conectores Anidados: El conector anidado entre el paquete destino y los paquetes de origen
reflejan lo que muestran los contenidos del paquete.
22
2.1.12 DIAGRAMAS DE COMPONENTES
Ilustran las piezas del software, controladores embebidos, etc. que conformarán un sistema.
Un diagrama de Componentes tiene un nivel más alto de abstracción que un diagrama de
clase, usualmente un componente se implementa por una o más clases (u objetos) en tiempo
de ejecución. Estos son bloques de construcción, como eventualmente un componente
puede comprender una gran porción de un sistema.
Elementos
• Representación de componentes
• Interfaces requeridas (Conector de Ensamble)
• Componentes con puertos
2.1.13 DIAGRAMA DE DESPLIEGUE
Un Diagrama de Despliegue modela la arquitectura en tiempo de ejecución de un sistema.

Esto muestra la configuración de los elementos de hardware (nodos) y muestra cómo los
elementos y artefactos del software se trazan en esos nodos.
2.2. PROCESO UNIFICADO DE DESARROLLO (PUD) 2
Es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de
uso, centrado en la arquitectura y por ser iterativo e incremental
El Proceso Unificado, es una metodología de desarrollo de software que está basado en

componentes e interfaces bien definidas, para diferentes áreas de aplicación, diferentes
tipos de organizaciones, diferentes niveles de competencia y diferentes tamaños de
proyectos.
2
(Jacobson & Booch, 2000)
23
Provee un enfoque disciplinado en la asignación de tareas y responsabilidades dentro de

una organización de desarrollo. Su meta es asegurar la producción de software de muy alta
calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y
presupuesto predecible.
2.2.1 EL PROCESO UNIFICADO TIENE DOS DIMENSIONES
✓ Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida
del proceso a lo largo de su desenvolvimiento
✓ Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una
manera lógica de acuerdo a su naturaleza.
La segunda dimensión representa el aspecto estático del proceso: cómo es descrito en

términos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos
y roles.
El Proceso Unificado, usa el Lenguaje de Modelado Unificado (UML) en la preparación de

todos los planos del sistema. De hecho, UML es una parte integral del Proceso Unificado,
fueron desarrollados a la par.
Los aspectos distintivos del Proceso Unificado están capturados en tres conceptos clave:
dirigido por casos de uso (use-case driven), centrado en la arquitectura (architecture-
centric), iterativo e incremental. Esto es lo que hace único al Proceso Unificado.
2.2.2 EL PROCESO UNIFICADO ES DIRIGIDO POR CASOS DE USO
Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un
sistema exitoso se debe conocer qué es lo que quieren y necesitan los usuarios.
El término usuario se refiere no solamente a los usuarios humanos, sino a otros sistemas.
En este contexto, el término usuario representa algo o alguien que interactúa con el sistema
por desarrollar.
Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un

resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los
casos de uso juntos constituyen el modelo de casos de uso el cual describe la
24
funcionalidad completa del sistema. Sin embargo, los casos de uso no son solamente una
herramienta para especificar los requerimientos del sistema, también dirigen su diseño,
implementación y pruebas, esto es, dirigen el proceso de desarrollo.
Aún y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son
desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la
arquitectura del sistema y la arquitectura del sistema influencia la elección de los casos de
uso. Por lo tanto, la arquitectura del sistema y los casos de uso maduran conforme avanza el
ciclo de vida.
2.2.3 EL PROCESO UNIFICADO ESTÁ CENTRADO EN LA ARQUITECTURA
El papel del arquitecto de sistemas es similar en naturaleza al papel que el arquitecto

desempeña en la construcción de edificios. El edificio se mira desde diferentes puntos de
vista: estructura, servicios, plomería, electricidad, etc. Similarmente, la arquitectura en un
sistema de software es descrita como diferentes vistas del sistema que está siendo
construido.
El concepto de arquitectura de software involucra los aspectos estáticos y dinámicos más

significativos del sistema. La arquitectura surge de las necesidades de la empresa, tal y
como las interpretan los usuarios y otros stakeholders, y tal y como están reflejadas en los
casos de uso. La arquitectura es la vista del diseño completo con las características más
importantes hechas más visibles y dejando los detalles de lado. Ya que lo importante
depende en parte del criterio, el cual a su vez viene con la experiencia, el valor de la
arquitectura depende del personal asignado a esta tarea. Sin embargo, el proceso ayuda al
arquitecto a enfocarse en las metas correctas, tales como claridad (understandability),
flexibilidad en los cambios futuros (resilience) y reusó.
25
2.2.4 ITERATIVO INCREMENTAL
Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software

creado en respuesta a las debilidades del modelo tradicional de cascada.
Básicamente este modelo de desarrollo, que no es más que un conjunto de tareas agrupadas
en pequeñas etapas repetitivas (iteraciones), es uno de los más utilizados en los últimos
tiempos ya que, como se relaciona con novedosas estrategias de desarrollo de software y
una programación extrema, es empleado en metodologías diversas.
El modelo consta de diversas etapas de desarrollo en cada incremento, las cuales inician
con el análisis y finalizan con la instauración y aprobación del sistema.
Se planifica un proyecto en distintos bloques temporales que se le denominan iteración. En

una iteración se repite un determinado proceso de trabajo que brinda un resultado más
completo para un producto final, de forma que quien lo utilice reciba beneficios de este
proyecto de manera creciente.
Para llegar a lograr esto, cada requerimiento debe tener un completo desarrollo en una
única iteración que debe de incluir pruebas y una documentación para que el equipo pueda
cumplir con todos los objetivos que sean necesarios y esté listo para ser dado al cliente. Así
se evita tener arriesgadas actividades en el proyecto finalizado.
Lo que se busca es que en cada iteración los componentes logren evolucionar el producto
dependiendo de los completados de las iteraciones antecesoras, agregando más opciones de
requisitos y logrando así un mejoramiento mucho más completo.
Una manera muy primordial para dirigir al proceso iterativo incremental es la de priorizar
los objetivos y requerimientos en función del valor que ofrece el cliente.
26
2.3. TECNOLOGÍA Y ARQUITECTURA
2.3.1. ARQUITECTURA 3 CAPAS.3
Definición: Es un estilo de programación, su objetivo primordial es la separación de la

capa de presentación, capa de negocio y la capa de datos.
2.3.1.1 VENTAJAS
Es el desarrollo se puede llevar a cabo en varios niveles y en caso de que sobrevenga algún
cambio.
En el diseño de sistemas informáticos actuales se suele usar las arquitecturas multilineal o

Programación por capas.
Además, permite distribuir el trabajo de creación de una aplicación por niveles; cada grupo
de trabajo está totalmente abstraído del resto de niveles, de forma que basta con conocer la
API que existe entre niveles.
2.3.1.2 BENEFICIOS DE LA ARQUITECTURA EN 3 CAPAS
Las principales ventajas de arquitectura en 3 capas detrás de su uso son las siguientes:
Brinda la posibilidad de trabajar por separado en mejoras y actualizaciones, ya que

permiten hacer modificaciones en cada una de las fases sin afectar demasiado el
funcionamiento de las demás. Es un sistema más flexible.
El sistema lógico (intermediario) se vuelve una capa de seguridad extra para proteger los
datos del sistema, debido a que la comunicación con el usuario se vuelve indirecta.
En la fase de pruebas resulta más sencillo identificar las fallas de programación.
Reduce considerablemente los requisitos de hardware, ya que el procesamiento de datos se

realiza externamente.
3
(http://arquitecturaencapas.blogspot.com/2011/08/arquitectura-3-capas-programacion-por.html, 2011)
27
2.3.1.3 INTERFAZ DE PROGRAMACIÓN DE APLICACIONES API

(Application Programming Interface)
Es el conjunto de funciones y procedimientos o métodos que ofrece cierta biblioteca para

ser utilizado por otro software como una capa de abstracción.
Figura #4.- Arquitectura 3 capas
2.3.1.4 Capa de Presentación, Vista
El objetivo principal de esta capa es hacer independiente la aplicación del medio de

visualización, de tal forma que se pueda programar una capa de presentación para salida
28
hacia un formulario. Sin necesidad de hacer ningún cambio en las capas de negocio o de
datos.
En particular, la programación desktop se hará a través de un sistema o Framework de

plantillas: un refinamiento más de la capa de presentación que independiza al diseñador
gráfico del programador dedicado a controlar el flujo de navegación en el formulario que
está trabajando.
2.3.1.5 Capa de Negocio, Controladores
En esta capa se ubicará el código específico de control de la aplicación.
Esta capa sustenta la lógica de negocio. Sus clases tienen dos objetivos fundamentales
interrelacionados: por un lado realizar los cálculos, transformaciones y controles inherentes
a la cobertura de los requisitos exigidos a la aplicación y por otro lado servir las
necesidades básicas de datos de la capa de presentación a través de mensajes a las clases de
la capa de datos. No debe haber ningún código de visualización de información o de
consulta de datos en la capa de negocio.
2.3.1.6 Capa de Datos, Modelo
La capa de datos es la que encuentra en el nivel más bajo de la arquitectura y su único fin es
proporcionar el acceso a los datos para servir las peticiones de la capa de negocio. Su
objetivo fundamental es hacer independiente la aplicación de los sistemas de
almacenamiento de datos, bien sean SGBD, ficheros planos, sistemas jerárquicos, etc.
Es absolutamente necesario contar aquí con un Framework de acceso a datos: un

refinamiento de la capa de datos que independiza las consultas de datos del sistema de
almacenamiento. Por ejemplo, en la capa de datos podríamos tener consultas SQL que se
ejecuten contra cualquier SGBDR sin cambiar nada en el código de las clases de la capa de
datos.
29
Figura #5.- Detalle del funcionamiento de la programación en 3 capas
2.3.2. TECNOLOGÍA .NET 4
.NET es una infraestructura para desarrollar aplicaciones Windows y Web dentro de los
entornos Microsoft a través de un conjunto de herramientas, de alto nivel. Cambia el rumbo
inicial de Microsoft, ya que las aplicaciones de ser centradas en el cliente ahora son
centradas en el servidor, es decir, que a través de .Net se puede integrar aplicaciones.
Microsoft entonces, diseñó un FRAMEWORK, que es el corazón de .NET y es el resultado

de la unión de dos proyectos uno relacionado con el desarrollo de aplicaciones Web y de
aplicaciones distribuidas, mientras que el segundo proyecto, conocido como NGWS (Next
Generation Windows Services- Siguiente Generación de Servicios Windows), es la
creación de una plataforma para el desarrollo del software como servicio. El producto
resultante de ambos proyectos mejora el despliegue y ejecución de las aplicaciones, e
4
(https://es.slideshare.net/copper64/tecnologia-net-26007260, 2013)
30
introduce el concepto de los SERVICIOS WEB, que permiten el desarrollo de aplicaciones

débilmente acopladas basadas en componentes.
Figura #6.- Funcionalidad de la plataforma .NET
5
2.3.2.1. EL FRAMEWORK .NET
Es un entorno de trabajo, es una estructura conceptual y tecnológica de asistencia definida,

con módulos concretos de software, que puede servir de base para la organización y
desarrollo de software, incluye soporte de programas, bibliotecas, y un lenguaje
interpretado, entre otras herramientas, para así ayudar a desarrollar y unir los diferentes
componentes de un proyecto.
En el desarrollo de software, es un entorno de trabajo, es una estructura conceptual y

tecnológica de asistencia definida, normalmente, con artefactos o módulos concretos de
software, que puede servir de base para la organización y desarrollo de software.
5
(Microsoft, https://msdn.microsoft.com/es-es/library/e80y5yhx(v=vs.110).aspx, 2015)
31
Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado,

entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes de
un proyecto.
Representa una arquitectura de software que modela las relaciones generales de las
entidades del dominio, y provee una estructura y una especial metodología de trabajo, la
cual extiende o utiliza las aplicaciones del dominio.
El Microsoft .NET Framework, es un componente de software que puede ser o es incluido

en los sistemas operativos Microsoft Windows. Provee soluciones pre-codificadas para
requerimientos comunes de los programas y gestiona la ejecución de programas escritos
específicamente para este Framework.
Las soluciones pre-codificadas que forman la biblioteca .NET, cubren un gran rango de
necesidades de la programación de programas.
El Framework incluye soluciones en áreas como: la interfaz de usuario, acceso a datos,

conectividad a bases de datos, criptografía, desarrollo de aplicaciones web, algoritmos
numéricos y comunicación de redes.
✓ .Net tiene un modelo de programación totalmente orientado a objetos en todas sus

herramientas de Visual Studio.Net
✓ Posee una plataforma de desarrollo llamada Framework.
✓ En sus herramientas de Visual Studio posee un lenguaje llamado C#, que reemplaza
a Java.
2.3.2.2. ADO.NET6
ADO.NET es un conjunto de componentes del software que pueden ser usados por los
programadores para acceder a datos y a servicios de datos. Es parte de la biblioteca de
clases base que están incluidas en el Microsoft .NET Framework. Es comúnmente usado
por los programadores para acceder y para modificar los datos almacenados en un Sistema
6
(https://msdn.microsoft.com/es-es/library/e80y5yhx(v=vs.110).aspx, 2015)
32
Gestor de Bases de Datos Relacionales, aunque también puede ser usado para acceder a
datos en fuentes no relacionales. ADO.NET es a veces considerado como una evolución de
la tecnología ActiveX Data Objects (ADO), pero fue cambiado tan extensivamente que
puede ser concebido como un producto enteramente nuevo.
✓ Arquitectura
ADO.NET consiste en dos partes primarias:
➢ Data provider
Estas clases proporcionan el acceso a una fuente de datos, como Microsoft SQL Server y
Oracle. Cada fuente de datos tiene su propio conjunto de objetos del proveedor, pero cada
uno tiene un conjunto común de clases de utilidad:
• Connection: Proporciona una conexión usada para comunicarse con la fuente de

datos. También actúa como Abstract Factory para los objetos command.
• Command: Usado para realizar alguna acción en la fuente de datos, como lectura,
actualización, o borrado de datos relacionales.
• Parameter: Describe un simple parámetro para un command. Un ejemplo común es

un parámetro para ser usado en un procedimiento almacenado.
• DataAdapter: "Puente" utilizado para transferir data entre una fuente de datos y un
objeto DataSet (ver abajo).
• DataReader: Es una clase usada para procesar eficientemente una lista grande de
resultados, un registro a la vez.
➢ DataSets
Los objetos DataSets, son un grupo de clases que describen una simple base de
datos relacional en memoria, fueron la estrella del show en el lanzamiento inicial
(1.0) del Microsoft .NET Framework. Las clases forman una jerarquía de
contención:
33
• Un objeto DataSet representa un esquema (o una base de datos entera o un

subconjunto de una). Puede contener las tablas y las relaciones entre esas tablas.
• Un objeto DataTable representa una sola tabla en la base de datos. Tiene un
nombre, filas, y columnas.
• Un objeto DataView "se sienta sobre" un DataTable y ordena los datos (como una
cláusula "order by" de SQL) y, si se activa un filtro, filtra los registros (como una
cláusula "where" del SQL). Para facilitar estas operaciones se usa un índice en
memoria. Todas las DataTables tienen un filtro por defecto, mientras que pueden
ser definidos cualquier número de DataViews adicionales, reduciendo la interacción
con la base de datos subyacente y mejorando así el desempeño.
• Un DataColumn representa una columna de la tabla, incluyendo su nombre y tipo.
• Un objeto DataRow representa una sola fila en la tabla, y permite leer y actualizar
los valores en esa fila, así como la recuperación de cualquier fila que esté
relacionada con ella a través de una relación de clave primaria - clave extranjera.
• Un DataRowView representa una sola fila de un DataView, la diferencia entre un
DataRow y el DataRowView es importante cuando se está interactuando sobre un
resultset.
• Un DataRelation es una relación entre las tablas, tales como una relación de clave
primaria - clave ajena. Esto es útil para permitir la funcionalidad del DataRow de
recuperar filas relacionadas.
• Un Constraint describe una propiedad de la base de datos que se debe cumplir,
como que los valores en una columna de clave primaria deben ser únicos. A medida
que los datos son modificados cualquier violación que se presente causará
excepciones.
• Un DataSet es llenado desde una base de datos por un DataAdapter cuyas
propiedades Connection y Command que han sido iniciados.
Sin embargo, un DataSet puede guardar su contenido a XML (opcionalmente con un
esquema XSD), o llenarse a sí mismo desde un XML, haciendo esto
excepcionalmente útil para los servicios web, computación distribuida, y aplicaciones
ocasionalmente conectadas desconectados.
34
7
2.3.2.3. C# .NET
C# (pronunciado si Sharp en inglés) es un lenguaje de programación orientado a objetos

desarrollado y estandarizado por Microsoft como parte de su plataforma .NET, que después
fue aprobado como un estándar por la ECMA (ECMA-334) e ISO (ISO/IEC 23270). C# es
uno de los lenguajes de programación diseñados para la infraestructura de lenguaje común.
Su sintaxis básica deriva de C/C++ y utiliza el modelo de objetos de la plataforma .NET,

similar al de Java, aunque incluye mejoras derivadas de otros lenguajes.
El lenguaje C# forma parte de una plataforma .NET, que es una interfaz de programación
de aplicaciones. C# es un lenguaje independiente que originariamente se creó para producir
programas sobre esta plataforma .NET. Ya existe un compilador implementado que provee
el marco Mono - DotGNU, el cual genera programas para distintas plataformas como
Windows, Unix, Android, iOS, Windows Phone, Mac OS y GNU/Linux.
8
2.3.4 ENTERPRISE ARCHITECT
Figura #7.- Diagramador UML Enterprise Architect

Es una herramienta de modelado y diseño visual basada en UML. La plataforma admite: el
diseño y la construcción de sistemas de software; modelar procesos comerciales; y
modelado de dominios basados en la industria. Las empresas y organizaciones lo usan no
solo para modelar la arquitectura de sus sistemas, sino también para procesar la
implementación de estos modelos en todo el ciclo de vida de desarrollo de aplicaciones.
7
(https://es.wikipedia.org/wiki/C_Sharp, 2013)
8
(http://www.sparxsystems.com.ar/products/ea.html, 2016)
35
El modelado de sistemas utilizando UML proporciona una base para modelar todos los
aspectos de la arquitectura de la organización, junto con la capacidad de proporcionar una
base para diseñar e implementar nuevos sistemas o cambiar los sistemas existentes. Los
aspectos que pueden cubrirse con este tipo de modelado abarcan desde el diseño de
arquitecturas organizacionales o de sistemas, reingeniería de procesos comerciales, análisis
de negocios y arquitecturas orientadas a servicios y modelado web, hasta el diseño de
aplicaciones y bases de datos y reingeniería, y desarrollo de sistemas integrados. Junto con
el modelado de sistemas, Enterprise Architect cubre los aspectos centrales del ciclo de vida
de desarrollo de aplicaciones, desde la gestión de requisitos. a través de fases de diseño,
construcción, pruebas y mantenimiento, con soporte para trazabilidad, gestión de proyectos
y control de cambios de estos procesos, así como instalaciones para el desarrollo impulsado
por modelos de código de aplicación utilizando una plataforma interna de desarrollo
integrado.
La base de usuarios va desde programadores y analistas de negocios hasta arquitectos

empresariales, en organizaciones que van desde pequeñas empresas desarrolladoras,
corporaciones multinacionales y organizaciones gubernamentales hasta organismos
internacionales de normalización de la industria
36
9
2.3.5 REPORT VIEWER
Figura #8.- ReportViewer
ReportViewer es un control libremente redistribuible que permite incrustar informes en

aplicaciones desarrolladas usando .NET Framework. Los informes están diseñados con la
simplicidad de arrastrar y soltar utilizando Report Designer.
El control ReportViewer ofrece los siguientes beneficios:
Procesa datos de manera eficiente. El motor de generación de informes incorporado en

ReportViewer puede realizar operaciones como filtradas, clasificación, agrupación y
agregación.
Admite una variedad de formas para presentar datos. Puede presentar datos como listas,
tablas, tablas y matrices (también conocidas como tablas cruzadas).
Agrega atractivo visual. Puede especificar fuentes, colores, estilos de bordes, imágenes de
fondo, etc. para que su informe sea visualmente atractivo.
Habilita la interactividad en los informes. Puede tener secciones plegables, mapa de

documentos, marcadores, clasificación interactiva, etc. en su informe.
Admite formateo condicional. Puede incrustar expresiones en el informe para cambiar el

estilo de visualización de forma dinámica en función de los valores de datos.
Admite la impresión y la vista previa de impresión.
9
(https://msdn.microsoft.com/es-es/library/ms252067.aspx, 2013)
37
Admite exportación a formatos Excel, Word y PDF. (Exportación de Word en Visual

Studio 2010 y versiones posteriores).
El control puede procesar y generar informes de forma independiente utilizando un motor

incorporado ('modo local') o puede mostrar informes que se procesan y representan en un
servidor de informes ('modo remoto').
2.3.6 GESTIÓN DE BASE DE DATOS10
2.3.6.1 EL LENGUAJE DDL
Un lenguaje de definición de datos (Data Definition Language, DDL por sus siglas en
inglés) es un lenguaje proporcionado por el sistema de gestión de base de datos que permite
a los programadores de la misma llevar a cabo las tareas de definición de las estructuras que
almacenarán los datos, así como de los procedimientos o funciones que permitan
consultarlos.
Un Data Definition Language o Lenguaje de descripción de datos (DDL) es un lenguaje

de programación para definir estructuras de datos. El término DDL fue introducido por
primera vez en relación con el modelo de base de datos CODASYL, donde el esquema de
la base de datos ha sido escrito en un lenguaje de descripción de datos que describe los
registros, los campos, y "conjuntos" que conforman el usuario modelo de datos. Más tarde
fue usado para referirse a un subconjunto de SQL, pero ahora se utiliza en un sentido
genérico para referirse a cualquier lenguaje formal para describir datos o estructuras de
información, como los esquemas XML.
Lenguaje de Definición de Datos (DDL)
El Lenguaje de definición de datos (DDL) es un subconjunto de SQL. Se trata de un

lenguaje que sirve para describir los datos y sus relaciones en una base de datos. Puede
10
(https://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_bases_de_datos, 2016)
38
desear generar DDL, SQL y estadísticas para objetos de bases de datos con los fines
siguientes:
Conservar una imagen del aspecto de la base de datos.
Configurar un sistema de prueba en el que la base de datos actúa como sistema de

producción, pero no contiene datos.
La generación de DDL crea un conjunto de sentencias que le permite reconstruir todo lo

referente a una base de datos salvo su contenido. Puede generar el DDL para reconstruir
totalmente la base de datos, o elegir reconstruir solamente determinados aspectos de ella,
tales como sus estadísticas actuales. Puede también limitar las sentencias generadas para
que sólo se reconstruya un segmento de la base de datos, por ejemplo, las estadísticas
correspondientes a un subconjunto de tablas.
2.3.6.2 EL LENGUAJE DML
Lenguaje de Manipulación de Datos
Lenguaje de Manipulación de Datos (Data Manipulation Language, DML) es un idioma

proporcionado por los sistemas gestores de bases de datos que permite a los usuarios de la
misma llevar a cabo las tareas de consulta o modificación de los datos contenidos en las
Bases de Datos del Sistema Gestor de Bases de Datos. El lenguaje de manipulación de
datos más popular hoy día es SQL, usado para recuperar y manipular datos en una base de
datos relacional. Otros ejemplos de DML son los usados por bases de datos IMS/DL1,
CODASYL u otras.
Elementos del lenguaje de manipulación de datos, Select, Insert, Delete y Update.
39
Clasificación de los DML
Se clasifican en dos grandes grupos:
Lenguajes de consulta procedimentales
Lenguajes procedimentales. En este tipo de lenguaje el usuario da instrucciones al sistema

para que realice una serie de procedimientos u operaciones en la base de datos para calcular
un resultado final.
Lenguajes de consulta no procedimentales
En los lenguajes no procedimentales el usuario describe la información deseada sin un

procedimiento específico para obtener esa información.
11
2.3.6.3 SQL
La sigla que se conoce como SQL corresponde a la expresión inglesa Structured Query
Language (entendida en español como Lenguaje de Consulta Estructurado), la cual
identifica a un tipo de lenguaje vinculado con la gestión de bases de datos de carácter
relacional que permite la especificación de distintas clases de operaciones entre éstas.
Gracias a la utilización del álgebra y de cálculos relacionales, el SQL brinda la posibilidad
de realizar consultas con el objetivo de recuperar información de las bases de datos de
manera sencilla.
En esencia, el SQL es un lenguaje declarativo de alto nivel ya que, al manejar conjuntos de

registros y no registros individuales, ofrece una elevada productividad en la codificación y
en la orientación a objetos. Una sentencia de SQL puede resultar equivalente a más de un
programa que emplee un lenguaje de bajo nivel.
Características generales de SQL
SQL es un lenguaje de acceso a bases de datos que explota la flexibilidad y potencia de los
sistemas relacionales y permite así gran variedad de operaciones.
11
(https://en.wikipedia.org/wiki/Microsoft_SQL_Server, 2014)
40
Es un lenguaje declarativo de "alto nivel" o "de no procedimiento" que, gracias a su fuerte

base teórica y su orientación al manejo de conjuntos de registros y no a registros
individuales permite una alta productividad en codificación y la orientación a objetos. De
esta forma, una sola sentencia puede equivaler a uno o más programas que se utilizarían en
un lenguaje de bajo nivel orientado a registros. SQL también tiene las siguientes
características:
Lenguaje de definición de datos: El LDD de SQL proporciona comandos para la

definición de esquemas de relación, borrado de relaciones y modificaciones de los
esquemas de relación.
Lenguaje interactivo de manipulación de datos: El LMD de SQL incluye lenguajes de

consultas basado tanto en álgebra relacional como en cálculo relacional de tuplas.
Integridad: El LDD de SQL incluye comandos para especificar las restricciones de

integridad que deben cumplir los datos almacenados en la base de datos.
Definición de vistas: El LDD incluye comandos para definir las vistas.
Control de transacciones: SQL tiene comandos para especificar el comienzo y el final de

una transacción.
SQL incorporado y dinámico: Esto quiere decir que se pueden incorporar instrucciones
de SQL en lenguajes de programación como: C++, C, Java, PHP, Cobol, Pascal y Fortran.
Autorización: El LDD incluye comandos para especificar los derechos de acceso a las
relaciones y a las vistas.
2.3.6.4. SGBD12
Un Sistema Gestor de Base de Datos (SGBD) es un conjunto de programas que permiten el

almacenamiento, modificación y extracción de la información en una base de datos, además
de proporcionar herramientas para añadir, borrar, modificar y analizar los datos. Los
12
(https://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_bases_de_datos, 2016)
41
usuarios pueden acceder a la información usando herramientas específicas de consulta y de

generación de informes.
Estos sistemas también proporcionan métodos para mantener la integridad de los datos,
para administrar el acceso de usuarios a los datos y para recuperar la información si el
sistema se corrompe.
Generalmente se accede a los datos mediante lenguajes de consulta, lenguajes de alto nivel
que simplifican la tarea de construir las aplicaciones. También simplifican las consultas y la
presentación de la información. Un SGBD permite controlar el acceso a los datos, asegurar
su integridad, gestionar el acceso concurrente a ellos, recuperar los datos tras un fallo del
sistema y hacer copias de seguridad.
1. Definición de los datos: El SGBD ha de poder definir todos los objetos de la base de
datos partiendo de definiciones en versión fuente para convertirlas en la versión objeto.
2. Manipulación de los datos: El SGBD responde a las solicitudes del usuario para
realizar operaciones de supresión, actualización, extracción, entre otras gestiones. El
manejo de los datos ha de realizarse de forma rápida, según las peticiones realizadas por los
usuarios, y permitir la modificación del esquema de la base de datos gracias a su
independencia.
3. Seguridad e integridad de los datos: Además de registrar el uso de las bases de datos,
ante cualquier petición, también aplicará las medidas de seguridad e integridad de los datos
(adopta medidas garantizar su validez) previamente definidas. Un SGBD debe garantizar su
seguridad frente a ataques o simplemente impedir su acceso a usuarios no autorizados por
cualquier razón.
4. Recuperación y restauración de los datos: La recuperación y restauración de los datos

ante un posible fallo es otra de las principales funciones de un SGBD. Su aplicación se
realizará a través de un Plan de recuperación y restauración de los datos que sirva de
respaldo.
42
13
2.3.7 MICROSOFT SQL SERVER
Figura #9.- Microsoft SQL Server

Microsoft SQL Server es un sistema de manejo de bases de datos del modelo relacional,
desarrollado por la empresa Microsoft.
El lenguaje de desarrollo utilizado (por línea de comandos o mediante la interfaz gráfica de

Management Studio) es Transact-SQL (TSQL), una implementación del estándar ANSI del
lenguaje SQL, utilizado para manipular y recuperar datos (DML), crear tablas y definir
relaciones entre ellas (DDL).
2.3.7.1 Características
✓ Soporte de transacciones.
✓ Soporta procedimientos almacenados.
✓ Incluye también un entorno gráfico de administración, que permite el uso de

comandos DDL y DML gráficamente.
✓ Permite trabajar en modo cliente-servidor, donde la información y datos se alojan en

el servidor y los terminales o clientes de la red sólo acceden a la información.
Además permite administrar información de otros servidores de datos.
13
(https://en.wikipedia.org/wiki/Microsoft_SQL_Server, 2014)
43
2.3.7.2 Programación
Es el principal medio de interacción con el Servidor, el cual permite realizar las

operaciones claves en SQL Server, incluyendo la creación y modificación de esquemas de
base de datos, inserción y modificación de datos en la base de datos, así como la
administración del servidor como tal. Esto se realiza mediante el envío de sentencias en T-
SQL y declaraciones que son procesadas por el servidor y los resultados (o errores)
regresan a la aplicación cliente.
2.3.7.3 Tipos de datos
Para cada columna en una tabla y a cada variable o parámetro, se define un tipo de datos
que sean almacenados en él, entre ellos:
✓ Números: Números enteros y no enteros en distintos tamaños, y en diferentes

niveles de precisión; y auto incremento opcional.
✓ Textos: Cadenas de distintas longitudes, y distintas capacidades de apoyar distintas

lenguas.
✓ Fechas: Fechas en distintos niveles de precisión, desde días completos hasta

fracciones menores de un segundo, que apoyan fechas a partir del principio del siglo
20 o del calendario gregoriano, y la capacidad de diferenciar entre distintos usos de
horarios.
✓ XML: Datos textuales (cadenas) que representan conjuntos estándares de datos

(estándar SGML).
✓ Datos binarios: Datos almacenados como datos binarios (bits y bytes), que
posibilitan el almacenamiento de archivos gráficos, etc.
✓ Geography: Representación estándar de información geográfica, tales como

estados, zonas geográficas, localidades; y los cálculos como distancias.
✓ Geometry: Representación estándar de puntas, líneas, superficies en el plano; y las

relaciones entre ellas.
44
✓ Hierarchid: Representación estándar de información jerárquica como lista de

materiales, relaciones de subordinación entre empleados, etc.
2.3.7.4 PROCEDIMIENTOS ALMACENADOS
Los procedimientos son scripts de comandos de TSQL, que pueden ser ejecutados con
distintos parámetros. Los procedimientos almacenados pueden facilitar en gran medida la
administración de la base de datos y la visualización de información sobre dicha base de
datos y sus usuarios. Los procedimientos almacenados son una colección precompilada de
instrucciones SQL e instrucciones de control de flujo opcionales almacenadas bajo un solo
nombre y procesadas como una unidad. Los procedimientos almacenados se guardan en
una base de datos; se pueden ejecutar desde una aplicación y permiten variables declaradas
por el usuario, ejecución condicional y otras funciones eficaces de programación. Los
procedimientos almacenados pueden contener flujo de programas, lógica y consultas a la
base de datos.
2.3.8 MICROSOFT VISUAL ESTUDIO 14
Microsoft Visual Studio es un entorno de desarrollo integrado (IDE, por sus siglas en
inglés) para sistemas operativos Windows. Soporta múltiples lenguajes de programación,
tales como C++, C#, Visual Basic .NET, F#, Java, Python, Ruby y PHP, al igual que
entornos de desarrollo web, como ASP.NET MVC, Django, etc., a lo cual hay que sumarle
las nuevas capacidades online bajo Windows Azure en forma del editor Mónaco.
Visual Studio permite a los desarrolladores crear sitios y aplicaciones web, así como
servicios web en cualquier entorno que soporte la plataforma .NET (a partir de la versión
.NET 2002). Así, se pueden crear aplicaciones que se comuniquen entre estaciones de
trabajo, páginas web, dispositivos móviles, dispositivos embebidos.
14
(https://msdn.microsoft.com/es-es/library/e80y5yhx(v=vs.110).aspx, Visual Studio, 2015)
45
15
2.3.8.1 VISUAL STUDIO 2013
Figura#10.- Visual Estudio 2013

Fue la primera revisión de Visual Studio en incluir una versión "Community", que
básicamente ofrece las mismas capacidades que la versión "Professional" pero limitando su
uso a empresas de pequeño tamaño, desarrolladores de software libre y estudiantes. La gran
ventaja de esta versión de Visual Studio es que es gratuita.
Permite trabajar con los frameworks:
.NET Framework 2.0
.NET Framework 3.0
.NET Framework 3.5
.NET Framework 4.0
.NET Framework 4.5
.NET Framework 4.5.1
.NET Framework 4.5.2
15
(https://es.wikipedia.org/wiki/Microsoft_Visual_Studio, 2013)
46
16
2.3.9 Start UML
Lenguaje Unificado de Modelado. UML es un popular lenguaje de modelado de sistemas.

Se trata de un lenguaje gráfico para construir, documentar, visualizar y especificar un
sistema de software Entre otras palabras, UML se utiliza para definir un sistema de
software.
Posee la riqueza suficiente como para crear un modelo del sistema, pudiendo modelar los
procesos de negocios, funciones, esquemas de bases de datos, expresiones de lenguajes de
programación. starUML es una herramienta de código abierto UML, esta licenciado bajo
una versión modificada de la gnu glp. Después de ser abandonado por algún tiempo el
proyecto tuvo un último avivamiento para pasar de Delphi para java, sin embargo, la
comunidad sigue siendo activo StarUML soporta la mayoría de los tipos de diagramas
especificados en UML es en la actualidad faltan diagramas de objetos, paquetes, el
momento y descripción de la interacción.
16
(http://staruml.io/, 2016)
47
Capítulo III
MATERIALES Y METODOS
CAPITULO III MATERIALES Y MÉTODOS
3 MATERIALES Y MÉTODOS
DETERMINACION DEL DOMINIO DEL PROBLEMA
El sistema cubrirá la necesidad de controlar los ingresos y salidas de mercadería, para saber
qué productos son los que más salen y así poder tomar realizar ofertas o diferentes
promociones para los productos que menos salen para mejorar las ventas de estos
productos.
Con el sistema de control se podrá saber determinar los stocks de los productos para poder
hacer pedidos antes de que se agoten los productos.
El sistema cubrirá las necesidades principales teniendo reportes de stock, productos que
más salen, reporte entre fechas, mes, año. Además, se podrá tener un inventario de manera
rápida y precisa con eso evitando la pérdida de tiempo en contar cada producto para tener
un reporte.
3.1.1 DESCRIPCIÓN DE LOS PROCESOS DE NEGOCIO
ID Nombre del Proceso Rol en el proceso

-Se registran los ingresos de mercadería que llega
de la fábrica a la sucursal.
- Se realiza actualización el stock de los nuevos
productos que llegan a la sucursal.
P01 Gestionar Ingresos
- Se genera la recepción de mercadería.
Se realiza el proceso de almacenaje y
actualización de inventario en las planillas Excel y
planillas impresas.
- Se realiza el registro de salidas.
- Se realiza actualización el stock.
P02 Gestionar Salidas - Se realiza la entrega de mercadería al cliente, y
se genera su orden de entrega.
Se genera las notas de salida de manera manual
49
para tener un respaldo de entrega, y se actualiza

las planillas Excel y actualización de inventario.
Se guarda la nota de salida en Cóndor como
respaldo.
Consiste en la gestión de productos nuevos por la
creación de una nueva línea de producto, creación
P03 Gestión de Productos
de nuevo ítem en la planilla Excel para tener el
control de ese nuevo producto.
4. Tabla. - Descripción de los Procesos de Negocio
3.1.2 IDENTIFICACIÓN DE LOS USUARIOS QUE REALIZAN EL PROCESO
Nombre Descripción
Administrador Es el encargado del control total del sistema sin restricciones.
Gestión de usuario y accesos al sistema.
Mantenimiento del sistema ante algún percance que se presente o

mal ingreso de datos.
Encargado de Es el encargado del control ingreso y salida de mercadería de la

almacén nueva sucursal.
Registra y controla el stock de productos nuevo y los existentes,

encargado de los ingresos y salidas de los productos de almacén.
Realiza los pedidos de suministro de productos que se están

agotando el stock.
50
3.2. DIAGRAMA DE ACTIVIDAD
3.2.1. DIAGRAMA DE ACTIVIDAD 1 INGRESO
act Diagrama de Activ idad ingreso
Encargado de almacen Cobija Encargado de Almacen SCZ Jefe Produccion - SCZ
Realiza la solicitud de Realiza la v erificacion de

suministro de mercaderia los productos solicitados Recibe el requerimiento
mediante un Email y y pasa la solicitud a de solicitud de mercaderia
Inicio Actividad llamada telefonica produccion de la sucursal de Cobija
Una v ez que se tiene la cantidad

Recibe la cantidad solicitada se entrega al
solicitada de desde encargado de almacen con una
produccion nota de entrega de produccion
Se realiza el env io de la
Recibe la mercaderia y
v erifica con su solicitud mercaderia solicitada a la
que realizo con la nota de sucursal con nota de
env io desde SCZ env io
Se firma la nota de
recepcion de conformidad
de mercaderia
Final Actividad
Figura #11.- Diagrama de actividad de ingreso de mercadería
51
3.2.2. DIAGRAMA DE ACTIVIDAD 2 SALIDA
act Diagrama de Activ idad salida
Cliente Encargado de Almacen - Cobij a
El cliente solicita la
mercaderia que desea Recibe la solicitud, y
adquirir prepara el pedido que el
Inicio Actividad cliente requiere
Se da la nota de entrega para

que firme su recepcion y Se genere su orden de
conformidad de mercaderia entrega de mercaderia
que solicito
Una v ez firmada la nota de

recepcion y conformidad se Recibe la nota de entrega
entrega al encargado de firmada
almacen
Recibe su copia de entrega

de mercaderia y se retira Entrega su copia de
con su mercaderia entrega de mercaderia
Final Actividad
Figura #12.- Diagrama de actividad de salida de mercadería
52
3.2.3. DIAGRAMA DE ACTIVIDAD 3 GESTION DE PRODUCTO
act Diagrama de Activ idad Producto
Encargado de Almacen Encargado de almacen
Gestionar datos de Encargado de almacen

productos realiza el conteo de los
Inicio Actividad productos
Almacena las planillas en Una v ez realizado el conteo se

condor guarda los datos en planillas
En caso de que haya poco en En caso llegue nuev o

Stock se realiza pedido producto de acomoda en
el lugar correspondiente
Final Actividad
Figura #13.- Diagrama de actividad de Gestión de Productos
53
3.3 DIAGRAMA DEL MODELO DE DOMINIO
Figura #14.- Diagrama del modelo de dominio
54
3.4 REQUERIMIENTOS DE SOFTWARE

3.4.1 Requisitos Funcionales
Un requisito funcional define una función del sistema de software o sus componentes. Una
función es descrita como un conjunto de entradas, comportamientos y salidas. Los
requisitos funcionales pueden ser: cálculos, detalles técnicos, manipulación de datos y otras
funcionalidades específicas que se supone, un sistema debe cumplir. Los requisitos de
comportamiento para cada requisito funcional se muestran en los casos de uso. Son
complementados por los requisitos no funcionales, que se enfocan en cambio en el diseño o
la implementación.
Como se define en la ingeniería de requisitos, los requisitos funcionales establecen los

comportamientos del sistema.
Listado de Requisitos Funcionales
Nivel de
Código Requerimiento Descripción
Atención
El sistema deberá tener la opción de

RF1 Registro de clientes mantenimiento clientes, permitirá registrar, Critico
modificar y eliminar un cliente del sistema.

Registro de mantenimiento proveedor, permitirá
RF2 Critico
proveedor registrar, modificar y eliminar un proveedor
del sistema.

Registro de mantenimiento producto, permitirá registrar,
RF3 Critico
productos modificar y eliminar un producto del
sistema.
Registro de El sistema permitirá manejar distintas

RF4 Normal
categorías categorías de productos.
55
Registro de El sistema de información debe permitir el

RF5 Normal
inventario control de inventario.
El sistema debe permitir registrar los datos

RF6 Registro de ingreso Importante
del ingreso de la mercadería para almacén.

RF7 Registro de salida Importante
de salida de mercadería de almacén.

RF8 Registro de usuarios Importante
de los usuarios que trabajan en la empresa.
Registra los Privilegios de los Usuarios del

RF9 Registrar Privilegios Normal
Sistema
El sistema permitirá realizar el reporte en el

Reporte de ingreso -
RF10 sistema ingreso/salida por día, mes, año y Importante
salida
entre fechas.
Generar Reportes
RF11 El sistema debe generar informe de clientes. Importante
clientes.
Generar Reportes
RF12 El sistema debe generar informe de clientes. Importante
proveedores.
Generar Reportes El sistema debe generar informe de stock de

RF13 Importante
productos. productos.
El sistema debe registrar una persona, que

RF14 Registro de Persona importante
esa persona luego es un cliente o proveedor
Registrar Detalle El sistema debe registrar un detalle salida de

RF15 Importante
Salida productos.
5. Tabla. - Listado de Requisitos Funcionales
56
3.4.2 Requisitos No Funcionales
Un requisito no funcional o atributo de calidad es, en la ingeniería de sistemas y la

ingeniería de software, un requisito que sabe bien y especifica criterios que pueden usarse
para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que
éstos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos
que no describen información a guardar, ni funciones a realizar, sino características de
funcionamiento, por eso suelen denominarse Atributos de calidad de un sistema.
Nivel de
Código Requerimiento Descripción
Atención
Cambio de estilos y El sistema debería permitir el

RNF1 Normal
colores del sistema cambio de colores del sistema
Los reportes deben llevar el

Logotipo de la
RNF2 logotipo de la empresa en el Importante
empresa en reportes
encabezado
El sistema debe funcionar en

Funcionamiento en
RNF3 sistema operativo Windows 7 en Normal
Windows 7
adelante.
El sistema debe funcionar sobre

Funcionamiento en
RNF4 plataforma de servidor Windows Importante
Windows Server
Server 2008R2
Motor de base de La base de datos debe estar en

RNF5 Importante
Datos SQL SERVER SQL SERVER
La programación debe realizarse

Lenguaje de en Visual Studio 2013 en lenguaje
RNF6 Normal
Programación de programación C# con el
Framework de desarrollo.NET
57
La seguridad de acceso a la base

Control de Acceso y de datos debe ser restringida solo
RNF7 Importante
Seguridad para el personal autorizado un
administrador.
Se debe utilizar para el desarrollo

Estándares de
RNF8 la arquitectura en 3 capas, Normal
arquitectura
Presentación, Negocio y Datos.
Ante un mal manejo del sistema

Mensajes y
RNF9 nos mostrara un mensaje con el Importante
advertencias
error que se cometió.
6. Tabla. - listado requisitos No Funcionales
58
3.5 LISTADO DE CASOS DE USO
Código Caso de Uso Descripción Importancia Referencia

Se registrar, actualizar, eliminar
CU01 Gestionar Cliente Alta RF1
los datos de los clientes.
Se registra a la persona, que luego
CU02 Gestionar Persona esa persona se convierte en Alto RF14
usuario, cliente o proveedor
CU03 Gestionar Proveedor Alta RF2
los datos de los proveedores.
CU04 Gestionar Productos Alta RF3
los datos de los productos
Registra los datos de los usuarios
CU05 Gestionar Usuarios Alta RF8
que trabajan en la empresa
Se gestiona los inventarios de
CU06 Gestionar Inventario Alta RF5
ingreso
Gestionar ingreso de Registra los ingresos de los
CU07 Alta RF6
mercadería productos de almacén.
Gestionar salida de Registra las salidas de los
CU08 Alta RF7
mercadería productos de almacén.
Gestión Detalle Registra los detalles de salidas de
CU09 Alto RF15
salida los productos de almacén.
Gestionar Privilegios Registra los Privilegios del
CU10 Alta RF9
de usuario Usuario
Gestionar Categorías Registra las categorías de
CU11 Alta RF4
de productos productos
Gestionar reporte Permite generar reporte de los
CU12 Alta RF1
cliente clientes
Gestionar reporte Permite generar reporte de los
CU13 Alta RF12
Proveedor proveedores.
Gestionar reporte Realiza un reporte de los
CU14 Alta RF13
productos productos.
Realiza un reporte de las
Generar Reporte
CU15 transacciones diarias, mensuales, Alta RF10
ingreso - salida.
anuales y entre las fechas.
7. Tabla. - Listado de casos de uso
59
3.5.1. Definición de Actores y sus funciones
uc Actores
Es la Persona encargada del manejo de todas las

transacciones del Sistema, Administración de Usuarios,
Administrador Mantenimiento del Sistema, Backup, Registrar
Cliente,Proveedor,Productos, etc.
Es el encargado de recibir las nuevas solicitudes deingreso,

salida de mercaderia, registros, modificacion de datos de
clientes, proveedores, productos.
Encargado Almacen
Figura #15.- Definición de Actores y sus funciones
60
3.5.2. Diagrama de Casos de Uso General

uc Diagrama Casos de Uso
Gestion Ingreso
Mercaderia Gestion Prov eedor Reporte Prov eedor
«include»
«extend»
«include» Reporte Producto

«extend»
«extend»
Inv entario «include»
«include» Gestion Producto
Gestion Categoria
Gestion de Reporte «include»
ingreso - salida. «include» Gestionar Persona
Detalle Salida
«include»
«include»
Gestion Cliente
«include»
«extend»
Gestionar Usuario
«extend»
«include» Reporte Cliente
Gestion Salida «include»

Mercaderia
Gestionar Priv ilegios
Administrador
Encargado
Almacen
Figura #16.- Diagrama de Casos de Uso General
61
3.6 DIAGRAMA DE CLASES

class Modelo de clases
* *
Inv entario
Salida
- idinventario: int
- id_salida: int
detallesalida - idingreso: int
- id_cliente: int
- idproducto: int
- idusuario: int
Priv ilegios - iddetallesalida: int - stockinicial: int
- fecha: int - idsalida: int - preciocompra: double
- id_usuario: int - id_privilegio: int - inventario: int - preciosalida: double
- tipocomprob.: char - nombre: char - cantidad: int
- numerocomprob.: char
- preciosalida: double + Registrar() : void
- iva: double + Registrar() : void - descuento: double + Buscar() : void
+ Modificar() : void
+ Anular() : void
+ Registrar() : void + Eliminar() : void
* + Mostrar() : void
+ Modificar() : void + Buscar() : void
1
+ Eliminar() : void + Mostrar() : void Ingreso *
+ Buscar() : void
+ Mostrar() : void * - idingreso: int
- idusuario: int
* * - idproveedor: int
1 - fecha
- tipocomprob..: char
Usuarios - numerocompro..: char
1
- iva: int
- id_usuario: int - estado: char
- idpersona: int *
- direccion: char
- usuario: char 1 - observaciones: char
- contraseña: char
- Privilegio: int + Registrar() : void
+ Modificar() : void
+ Registrar() : void + Anular() : void
+ Modificar() : void + Buscar() : void 1
+ Eliminar() : void + Mostrar() : void
+ Buscar() : void Productos
+ Mostrar() : void 1 * *
- idproducto: int Categorias
1 - nombre: char
- descripcion: char - id_categoria: int
1 - Proveedor: int - nombre: char
1 - categoria: int - descripcion: char
1
Cliente - stockminimo: int
Persona + Registrar() : void
Prov eedor - usuario: int * 1
- id_cliente: int + Modificar() : void
- idpersona: int
- idpersona: int - id_proveedor: int + Eliminar() : void
- nombre: char + Registrar() : void
- contacto: char - idpersona: int + Modificar() : void + Buscar() : void
- documento: char
- ciudad: char - razonsocial: char + Eliminar() : void
- numdocumento: char + Eliminar() : void
- razonsocial: char - direccion: char - contacto: char + Buscar() : void
- telefono: char - ciudad: char + Eliminar() : void
+ Registrar() : void - Celular: char - rubro: char
+ Modificar() : void - Email: char - productos: char 1 *
+ Eliminar() : void
+ Buscar() : void + Registrar() : void + Registrar() : void
+ Mostrar() : void + Modificar() : void + Modificar() : void
1 1 + Eliminar() : void
+ Eliminar() : void
+ Buscar() : void 1 1 + Buscar() : void
+ Mostrar() : void + Mostrar() : void
Figura#17 Diagrama de clases
62
MODELO DE
ANÁLISIS IV
CAPITULO IV MATERIALES Y MÉTODOS
4 MODELO DE ANÁLISIS
4.1 ANÁLISIS DE LA ARQUITECTURA
4.1.1. Identificación de los paquetes
Figura #18.- Análisis de la arquitectura – Diagrama de Paquetes
64
4.2. Especificaciones de los Casos de Uso
4.2.1 Descripción del Caso de Uso Gestionar Cliente
Caso de Uso: Gestionar Cliente

Actor Encargado de Almacén
Activación Es activado por el encargado de almacén, la cual registra los
datos del cliente.
Propósito: Registrar los datos de los clientes de la empresa
Pre Condición: Registrar, que el registro no exista.
Modificar, que el cliente este registrado
Eliminación: que el registro no tenga ninguna relación.
Flujo principal del El encargado de almacén es el encargado de registrar los datos
evento del actor de los clientes, modificar y eliminar los datos.
El sistema guarda los datos de los clientes, modifica, elimina y
busca los datos de los clientes.
Flujo principal de El sistema guarda, modifica y elimina los datos del cliente, así
evento del sistema también muestra los datos de registro del cliente.
Variaciones y Tiene relación <<include>> con Gestionar reporte, Gestionar
extensiones salida.
Post condición Imprimir reporte cliente
Excepciones
8. Tabla.- Descripción del Caso de Uso Gestionar Cliente
65
4.2.2 Diagrama de colaboración Gestionar Cliente
1 : MostrarClientes() 2 : nmostrarclientes() 3 : dmostrarcliente()
5 : ninsertar() 6 : dinsertar()
4 : Cliente()
9 : deditar()
8 : neditar()
7 : Buscarcliente()
12 : deliminar()
10 : Buscarcliente() 11 : neliminar()
: Encargado Almacen
Cliente NCliente DCliente
Figura #19.- Diagrama de colaboración Gestionar Cliente
4.3.1 Descripción del caso de uso gestionar proveedor
Caso de Uso: Gestionar Proveedor

Actor Encargado de almacén
Activación Es activado por el encargado de almacén, la cual registra los datos del
cliente.
Propósito: Registrar los datos de los proveedores de la empresa
Registrar, que el registro no exista.
Pre Condición: Modificar, que el cliente este registrado
El encargado de almacén es el encargado de registrar los datos de los
Flujo principal de proveedores, modificar y eliminar los datos.
eventos del actor El sistema guarda los datos de los proveedores, modifica, elimina y
busca los datos de los clientes.
Flujo principal de
El sistema guarda, modifica y elimina los datos del proveedor. Así
eventos del
también muestra los datos del proveedor que se registro
sistema
66
Variaciones y Tiene relación <<include>> con Gestionar reporte, Gestionar ingreso y

extensiones gestionar producto.
Post Condición: Imprimir Reporte Proveedor
Excepciones:
9. Tabla. - Descripción del caso de uso gestionar proveedor
4.3.2 Diagrama de colaboración gestionar Proveedor
1 : mostrarproveedor() 3 : dmostrar()
2 : nmostrar()
5 : ninsertar() 6 : dinsertar()
4 : Proveedor()
7 : Buscar() 8 : neditar() 9 : deditar()
10 : Buscar() 11 : neliminar() 12 : deliminar()
: Encargado de Almacen Proveedor NProveedor DProveedor
Figura #20.- Diagrama de colaboración gestionar Proveedor
4.4.1 Descripción del caso de uso gestionar Producto
Caso de Uso: Gestionar Producto

Activación Es activado por el encargado de almacén, la cual registra los datos del
producto.
Propósito: Registrar los datos de los Productos de la empresa
Pre Condición: Modificar, que el producto este registrado
67
El encargado de almacén es el encargado de registrar los datos de los

Flujo principal de productos, modificar y eliminar los datos.
eventos del actor El sistema guarda los datos de los productos, modifica, elimina y
busca los datos de los productos.
Flujo principal de
El sistema guarda, modifica y elimina los datos del producto. Así
eventos del
también muestra los datos del producto que se registró.
sistema
Variaciones y Tiene relación <<include>> con Gestionar proveedor, Gestionar
extensiones ingreso y gestionar salida.
Post Condición: Imprimir reporte productos
Excepciones:
10. Tabla.- Diagrama de colaboración gestionar Proveedor
4.4.2 Diagrama de colaboración gestionar Producto
1 : MostrarProducto() 2 : nmostrar.cs() 3 : dmostrar.cs()
4 : Producto() 5 : ninsertar.cs() 6 : dinsertar.cs()
7 : Buscar()
8 : neditar.cs() 9 : deditar.cs()
10 : Buscar() 11 : neliminar.cs() 12 : deliminar.cs()
: Encargado de Almacen
Producto NProducto DProducto
Figura #21.- Diagrama de colaboración gestionar Producto
68
4.5.1 Descripción del Caso de Uso Gestionar ingreso mercadería
Caso de Uso: Gestionar ingreso

Activación Es activado por el encargado de almacén, la cual registra los datos de
ingreso de mercadería.
Propósito: Registrar el ingreso de mercadería.
Pre Condición: Modificar, que el ingreso este registrado
El encargado de almacén es el encargado de registrar los datos de
Flujo principal
ingreso de mercadería, modificar y eliminar los datos.
del evento del
El sistema guarda los datos del ingreso, modifica, elimina y busca los
actor
datos de los ingresos.
Flujo principal de El sistema guarda, modifica y elimina los datos de ingreso de
evento del sistema mercadería, así también muestra los datos de registro de ingreso de la
mercadería.
Variaciones y Tiene relación <<include>> con Gestionar proveedor, Gestionar
extensiones salida, Gestionar producto.
Post Condición: Entregar recibo de recepción de mercadería.
Excepciones:
11. Tabla.- Descripción del Caso de Uso Gestionar ingreso mercadería
69
4.5.2 Diagrama de colaboración Gestionar ingreso mercadería
1 : MostrarIngreso() 2 : nmostrar()
3 : dmostrar()
4 : RegistrarIngreso() 13 : ningreso() 14 : dingreso()
15 : Buscar() 16 : neditar()
17 : deditar()
18 : Buscar() 19 : nanular() 20 : danular()
NIngreso DIngreso
: Encargado de Almacen Ingreso
5 : nmostrar() 6 : dmostrar()
8 : devolver ID()
7 : devolver ID()
NProveedor DProveedor
12 : devolver ID() 11 : devolver ID()

NProducto DProducto
Figura #22.- Diagrama de colaboración Gestionar ingreso mercadería

4.6.1 Descripción de caso de uso gestión de Usuario
Caso de Uso: Gestionar usuario

Actor Administrador
Activación Es activado por el administrador, la cual registra los datos del usuario.
Propósito: Registrar datos del usuario.
70
El administrador es el encargado de registrar los datos del nuevo

Flujo principal
usuario, así como la modificación y eliminación de datos.
del evento del
El sistema guarda los datos del usuario, modifica, elimina y busca los
actor
datos de los ingresos.
Flujo principal de El sistema guarda, modifica y elimina los datos del usuario, así
evento del sistema también muestra los datos de registro del usuario.
Variaciones y
extensiones
Post Condición:
Excepciones:
12. Tabla. - Descripción de caso de uso gestión de Usuario
4.6.2 Diagrama de colaboración de gestión de usuario
1 : Mostrar usuarios() 2 : nmostrar_usuario.cs() 3 : dmostrar_usuario.cs()
4 : Registrar_Usuario()
9 : nregistrar.cs() 10 : dregistrar.cs()
11 : Buscar() 12 : nmodificar.cs() 13 : dmodificar.cs()
15 : neliminar() 16 : deliminar()
14 : Buscar()
: Administrador USUARIO NUSUARIO DUSUARIO
5 : nbuscar_privilegio.cs()
8 : nmostrar_lista.cs()
6 : dmostrar_privilegio.cs()
NPRIVILEGIO 7 : dmostrar_lista.cs() DPRIVILEGIO
Figura #23.- Diagrama de colaboración gestionar usuario
71
4.7.1 Descripción de casos de uso: Gestión de salida
Caso de Uso: Gestionar Salida

Activación Es activado por el encargado de almacén, la cual registra los datos de
salida de la mercadería.
Propósito: Registrar salida.
El encargado de almacén es el encargado de registrar los datos de la
Flujo principal
salida de mercadería, así como la modificación y eliminación de datos.
del evento del
El sistema guarda los datos del usuario, modifica, elimina y busca los
actor
datos de la salida.
Flujo principal de El sistema guarda, modifica y elimina los datos de salida de la
evento del sistema mercadería, así también muestra los datos de registro de la salida de la
mercadería.
Variaciones y Ej Tiene relación <<include>> con Gestionar Cliente, Gestionar
extensiones producto y Gestionar inventario.
Post condición Entregar recibo de salida de mercadería.
Excepciones
13. Tabla.- Descripción de casos de uso: Gestión de salida
72
4.7.2 Diagrama de colaboración: Gestión de salida
1 : MostrarSalida() 2 : nmostrar() 3 : dmostrar()
4 : RegistrarSalida() 13 : ningresar() 14 : dingresar()
15 : Buscar() 16 : neditar() 17 : deditar()
18 : Buscar() 19 : neliminar() 20 : dliminar()
NSalida
: ENCARGADO DE ALMACEN Salida DSalida
5 : dmostrar() 6 : dmostrar()
8 : devolver ID() 7 : devolver ID()

NCliente DCliente
12 : devolver ID()
11 : devolver ID()
NProducto DProducto
Figura #24.- Diagrama de colaboración: Gestión de salida
4.8.1 Descripción de casos de uso: Gestión de Privilegios
Caso de Uso: Gestionar Privilegios

Actor Administrador
Activación Es activado por el administrador, la cual asigna permisos al usuario.
Propósito: Asignación de privilegios de acceso.
Asignación, que el registro exista.
Pre Condición: Modificar, que el privilegio de acceso al sistema.
El administrador del sistema es el encargado de asignación de

Flujo principal del
privilegios de acceso al sistema así como la modificación y
evento del actor
eliminación de datos.
73
El sistema guarda los datos del usuario, modifica, elimina y busca

los datos de los privilegios de acceso.
Flujo principal de El sistema guarda, los privilegios asignados a los usuarios.

evento del sistema
Variaciones y Tiene relación <<include>> con Gestionar usuario.
extensiones
Post condición
Excepciones
14. Tabla.- Descripción de casos de uso: Gestión de Privilegios
4.8.2 Diagrama de colaboración de casos de uso: Gestión de Privilegios
1 : Mostrar Privilegios() 2 : nmostrar.cs() 3 : dmostrar.cs()
6 : dregistrar.cs()
4 : Registrar() 5 : nregistrar.cs()
7 : Modificar() 8 : nmodificar.cs() 9 : dmodificar.cs()
10 : Eliminar() 11 : neliminar.cs() 12 : deliminar.cs()
NPrivilegios DPrivilegios
: Administrador Privilegios
Figura #25.- Diagrama de colaboración de casos de uso: Gestión de Privilegios

4.9.1 Descripción de casos de uso: Gestión de Categoría
Caso de Uso: Gestionar Categoría

Activación Es activado por el encargado de almacén, la cual registra la categoría
de productos.
Propósito: Registrar Categoría.
74

El encargado de almacén es el encargado de registrar la nueva
Flujo principal
categoría así como la modificación y eliminación de datos.
del evento del
El sistema guarda los datos de la nueva categoría, modifica, elimina y
actor
busca los datos de la categoría.
Flujo principal de El sistema guarda, modifica y elimina los datos de la categoría, así
evento del sistema también muestra los datos de registro de la categoría.
Variaciones y Ej Tiene relación <<include>> con Gestionar producto.

extensiones
Post Condición:
Excepciones:
15. Tabla.- Descripción de casos de uso: Gestión de Categoría
4.9.2 Diagrama de colaboración de casos de uso: Gestión de Categoría
1 : MostrarCategoria() 2 : nmostrar.cs() 3 : dmostrar.cs()
4 : RegistrarCategoria() 5 : ningreso.cs() 6 : dingreso.cs()
8 : neditar.cs() 9 : deditar.cs()
7 : Buscar()
10 : Buscar() 11 : neliminar.cs() 12 : deliminar.cs()
: Encargado de Almacen Categoria NCategoria NCategoria
Figura #26.- Diagrama de colaboración de casos de uso: Gestión de Categoría
75
4.10.1 Descripción de casos de uso: Gestión de reporte cliente
Caso de Uso: Gestionar reporte cliente

Activación Es activado por el encargado de almacén, ingresa los parámetros de
búsqueda para obtener el reporte.
Propósito: Reporte cliente.
Generar reporte.
Pre Condición: Modificar, método de búsqueda.
Exportar datos o imprimir.
Flujo principal El encargado de almacén o administrador puede generar reportes para

del evento del fines que sean necesarios.
actor El sistema brindara información de acuerdo a parámetros de búsqueda.
Flujo principal de El sistema genera el informe de acuerdo a los parámetros de búsqueda.

evento del sistema
Variaciones y Ej Tiene relación <<include>> con Gestionar Cliente, Gestionar Tipo
extensiones de Venta y Gestionar Servicio de Alquiler.
Post condición Genera un reporte de los clientes, exportar o imprimir.
Excepciones
16. Tabla.- Descripción de casos de uso: Gestión de reporte cliente
76
4.10.2 Diagrama de colaboración de casos de uso: Gestión de reporte cliente
1 : Buscar Cliente() 2 : nbuscarcliente_parametro()

3 : nbuscar_cliente_paramentro()
5 : muestra_cliente_segun_parametros() NCliente 4 : muestra_resultado_busqueda() DCliente

: Encargado Almacen Cliente
Figura #27.- Diagrama de colaboración de casos de uso: Gestión de reporte cliente
4.11.1 Descripción de casos de uso: Gestión de reporte proveedor
Caso de Uso: Gestionar reporte proveedor

Activación Es activado por el encargado de almacén, el cual necesita
obtener reporte de los proveedores.
Propósito: Registrar reporte proveedor.
Pre Condición: Generar, reporte, de acuerdo a parámetros de búsqueda.
El encargado de almacén es el encargado decide obtener un
Flujo principal del evento reporte de los proveedores
del actor El sistema brinda un reporte el cual se puede imprimir o
exportar.
Flujo principal de evento El sistema genera el informe de acuerdo a los parámetros de
del sistema búsqueda.
Variaciones y extensiones Ej Tiene relación <<include>> con Gestionar proveedor.
Post Condición: Genera reporte de proveedores.

Excepciones:
17. Tabla.- Descripción de casos de uso: Gestión de reporte proveedor
77
4.11.2 Diagrama de colaboración de casos de uso: Gestión de reporte proveedor
1 : Buscar Proveedor() 2 : nbuscar_proveedor_parametro() 3 : dbuscar_proveedor_parametro()
NProveedor DProveedor
: Encargado Almacen Proveedor
5 : muestra_proveedor_segunparametro() 4 : mostrar_resultado()
Figura #28.- Diagrama de colaboración de casos de uso: Gestión de reporte proveedor
4.12.1 Descripción de casos de uso: Gestión de reporte productos
Caso de Uso: Gestionar reporte productos

Activación Es activado por el encargado de almacén el cual desea
obtener reporte de los productos.
Propósito: Generar reporte de productos.
Seleccionar parámetros de búsqueda, para obtener reporte de
Pre Condición:
productos y stock.
Flujo principal del evento De acuerdo a los filtros de búsqueda se obtiene un reporte, y
del actor esos se puede exportar o imprimir.
Flujo principal de evento El sistema genera el informe de acuerdo a los parámetros de
del sistema búsqueda.
Variaciones y extensiones Ej Tiene relación <<include>> con Gestionar productos.
Post Condición: Imprimir reporte de productos

Excepciones:
18. Tabla.- Descripción de casos de uso: Gestión de reporte productos
78
4.12.2 Diagrama de colaboración de casos de uso: Gestión de reporte productos
1 : Buscar_Producto() 2 : nbuscarproducto_parametro()
3 : dbuscarproducto_paramentro()
NProductos DProductos
: Encargado Alamcen Productos 4 : mostrar_resultado()
5 : mostrarproducto_segunparametro()
Figura #29.- Diagrama de colaboración de casos de uso: Gestión de reporte productos
4.13.1 Descripción de casos de uso: Gestión de reporte diario, mensual, anual y entre
fechas de ingreso salida.
Caso de Uso: Gestionar reporte diario, mensual, anual y entre fechas

Activación Es activado por el encargado de almacén, el cual desea obtener
desea obtener reporte de un periodo.
Propósito: Obtener reporte diario, mensual, anual y entre fechas.
Seleccionar el periodo del que se desea obtener el reporte,
Pre Condición:
diario, mensual anual y entre fechas.
El encargado de almacén Selecciona sus métodos de búsqueda y
Flujo principal del
el sistemas le brinda reportes claros de acuerdo a la solicitud,
evento del actor
estos reportes se puede imprimir o exportar.
Flujo principal de El sistema genera el informe de acuerdo a los parámetros de
evento del sistema búsqueda.
Variaciones y Tiene relación <<include>> con Gestionar ingreso, Gestionar
extensiones salida.
79
Post condición Imprimir reporte del parámetro seleccionado

Excepciones
19. Tabla. - Descripción de casos de uso: Gestión de reporte diario, mensual, anual y
entre fechas de ingreso salida.
4.13.2 Diagrama de colaboración de casos de uso: Gestión de reporte diario, mensual,

anual y entre fechas.
1 : Reporte_Salida() 2 : nsalida() 3 : dsalida()
NSalida DSalida
: Encargado Almacen Reporte Salida
5 : muestrasalida_segunparametro() 4 : muestra_resultado()
Figura #30.- Diagrama de colaboración de casos de uso: Gestión de reporte diario,

mensual, anual y entre fechas.
4.14.1 Descripción de casos de uso: Gestión de Persona
Caso de Uso: Gestionar Persona

Activación Es activado por el encargado de almacén, el cual desea registrar
una nueva persona que luego se le asignara como cliente,
usuario o proveedor
Obtener datos de contacto de una nueva persona que esta puede
Propósito:
ser, cliente, proveedor o usuario del sistema.
Realizar una búsqueda, para verificar que la persona no se
Pre Condición:
encuentre registrada.
80
El encargado de almacén Selecciona el formulario de registro de

Flujo principal del
una nueva persona, y llena los campos con datos requeridos para
evento del actor
el registro de la nueva persona.
Flujo principal de El sistema realiza el registro de la nueva persona, que esa
evento del sistema persona luego puede ser, cliente, proveedor o usuario del
sistema.
Variaciones y Tiene relación <<include>> con Gestionar Usuario, Cliente y
extensiones Proveedor
Post condición
Excepciones
4.14.2 Diagrama de colaboración de casos de uso: Gestión de Persona
1 : MostrarPersona() 2 : nmostrar() 3 : dmostrar()
4 : Registrar() 5 : ningreso.cs() 6 : dingreso.cs()
7 : Buscar() 8 : nmodificar.cs() 9 : dmodificar.cs()
12 : deliminar.cs()
10 : Eliminar() 11 : neliminar.cs()
DPersona
: Encargado de Almacen Persona NPersona
Figura #31.- Diagrama de colaboración de casos de uso: Gestión de Persona
81
MODELO DE DISEÑO V
CAPÍTULO V MODELO DE DISEÑO
5 MODELO ESTRUCTURAL
5.1 MODELO DE DISEÑO
5.1.1 MODELO RELACIONAL
Figura #32.- Modelo relacional

5.1.3 MODELO FÍSICO DE LA BASE DE DATOS

Tabla Cliente
Atributos Tipo Tamaño Nulls Observaciones
Idcliente Int Identity No pk
Idpersona Int No fk
Contacto Varchar 150 Si
Ciudad Varchar 150 Si
Razonsocial Varchar 100 No
Codigo Varchar 34 No
Tabla Proveedor
Idproveedor Int Identity No pk
Idpersona Int No Fk
Razonsocial Varchar 100
Contacto Varchar 150
Ciudad Varchar 50
Rubro Varchar 50
Productos Varchar 50
Código Varchar 34 No
Tabla Producto
Idproducto Int Identity No pk
Nombre Varchar 250 No
Descripcion Varchar 250 No
Proveedor Int No Fk
84
Categoria Int No Fk
Stockminimo Int No
Usuario Int No Fk
Código Varchar 34 no
Tabla Categoría
Idcategoria Int Identity No pk
Descripcion Varchar 250
Codigo Varchar 34 no
Tabla Usuario
Idusuario Int Identity No pk
Idpersona Int No fk
Usuario Varchar 25 No
Contraseña Varchar 25 No
Privilegio Int No Fk
Código Varcchar 34 no
Tabla Ingreso
Idingreso Int Identity No pk
Idusuario Int No Fk
Idproveedor Int No Fk
Fecha Date No
Tipo_comprobante Varchar 20 No
Numerocomprobante Varchar 25
Iva Decimal 18.2 No
85
Estado Varchar 25 No
Dirección Varchar 150
Observación Varchar 250
Tabla inventario
Idinventario Int No pk
Idingreso Int Identity No Fk
Idproducto Int No Fk
Stockinicial Int No
Stock_actual Int No
Preciocompra Money No
Precio venta Money no
Tabla Salida
Idsalida Int Identity No pk
Idcliente Int No Fk
Idusuario Int No Fk
Fecha Date No
Tipocomprobante Varchar 20 No
Numerocomprobante Varchar 25
Iva Decimal 18.2 No
Código Varchar 34 no
Tabla detallesalida
Iddetallesalida Int No pk
Idsalida Int Identity No Fk
Idinventario Int No Fk
86
Cantidad Int No
Preciosalida Money No
Descuento Money No
Tabla Privilegio
IdPrivilegio Int No pk
Tabla Persona
IdPersona Int No pk
Documento varcchar 25 No
Numdocumento Varchar 25 No
Dirección Varchar 250 No
Teléfono Varchar 25 No
Celular Varchar 25 No
Email Varchar 250 No
87
5.2 DIAGRAMAS E INTERFAZ DE LOS CASO DE USO

5.2.1.1 Diagrama de secuencia del caso de uso Gestionar Cliente
<<control>>
<<boundary>> NCliente <<entity>>
Cliente DCliente
1 : Mostrar_clientes()
2 : nmostrar_clientes.cs()
3 : dmonstrar_clientes.cs()
4 : Registrar_cliente()
5 : nregistrar_cliente.cs()
6 : dregistrar_cliente.cs()
7 : Modificar_cliente()
8 : nmodificar_cliente.cs()
9 : dmodificar_cliente.cs()
10 : Eliminar_cliente()
11 : neliminar_cliente.cs()
12 : deliminar_cliente.cs()
Figura #33 Diagrama de secuencia Gestionar Cliente
88
5.2.1.2 Interfaz gráfica del caso de uso Gestionar Cliente
Figura # 34 Interfaz gráfica gestionar cliente.
89
5.2.2.1 Diagrama de Secuencia del caso de uso Gestionar Proveedor
<<boundary>> <<control>> <<entity>>

Proveedor NProveedor DProveedor
: Encargado Almacen
1 : Mostrar_proveedor()
2 : nmostrar_proveedor.cs()
3 : dmostrar_proveedor.cs()
4 : Registrar_proveedor()
5 : nregistrar_proveedor.cs()
6 : dregistrar_proveedor.cs()
7 : Modificar_proveedor()
8 : nmodificar_proveedor.cs()
9 : dmodificar_proveedor.cs()
10 : Eliminar_proveedor()
11 : nmodificar_proveedor.cs()
12 : dmodificar_proveedor.cs()
Figura #35 Diagrama de secuencia Gestionar Proveedor
90
5.2.2.2 Interfaz gráfica del caso de uso Gestionar Proveedor
Figura #36 Interfaz grafica gestionar Proveedor
91
5.2.3.1 Diagrama de Secuencia del caso de uso Gestionar Producto

Producto NProducto DProducto
: Encargado Almacen
1 : Mostrar_productos()
2 : nmostrar_productos()
3 : dmostrar_productos()
4 : Registrar_producto()
5 : nregistrar_producto.cs()
6 : dregistrar_producto.cs()
7 : Modificar_producto()
8 : nmodificar_producto.cs()
9 : dmodificar_producto.cs()
10 : Eliminar_producto()
11 : neliminar_producto()
12 : neliminar_producto()
Figura #37 Diagrama de secuencia Gestionar Producto
92
5.2.3.2 Interfaz gráfica del caso de uso Gestionar Producto
Figura #38 Interfaz gráfica gestionar producto
93
5.2.4.1 Diagrama de Secuencia del caso de uso Gestionar Usuario
<<boundary>> <<control>> <<entity>> <<entity>> <<control>>

Usuario NUsuario.cs DUsuario.cs nprivilegio dprivilegio
: Adm-Sistema
1 : Mostrar_Usuario()
2 : nmostrar.cs()
3 : dmostrar.cs()
4 : Registrar()
5 : nmostrar_privilegio.cs()
6 : dmostrar_privilegio.cs()
7 : mostrar_privilegio.cs()
8 : nregistrar.cs()
9 : dregistrar.cs()
10 : Modificar()
11 : NEditar.cs()
12 : Eliminar() 13 : DEditar.cs()
14 : NEliminar.cs()
15 : DEliminar.cs()
Figura #39 Diagrama de secuencia Gestionar Usuario
94
5.2.4.2 Interfaz gráfica del caso de uso Gestionar Usuario
Figura #40 Interfaz grafica gestionar usuario

5.2.5.1 Diagrama de Secuencia del caso de uso Gestionar Privilegios
<<control>>
<<boundary>> NPrivilegios
Privilegios <<entity>>
DPrivilegios
: Administrador
1 : Mostrar()
2 : nmostrar.cs()
3 : dmostrar.cs()
4 : Registrar()
5 : nregistrar.cs()
6 : Modificar() 7 : dregistrar.cs()
8 : NEditar()
9 : Eliminar()
10 : DEditar()
11 : NEliminar()
12 : DEliminar()
Figura #41 Diagrama de secuencia Gestionar Privilegio
95
5.2.4.2 Interfaz gráfica del caso de uso Gestionar Privilegio
Figura #42 Interfaz grafica Gestionar Privilegio
96
5.2.6.1 Diagrama de Secuencia del caso de uso Gestionar Ingreso
<<boundary>> <<control>> <<entity>> <<control>> <<entity>> <<control>> <<entity>>

Ingreso NIngreso DIngreso NProveedor DProveedor NProducto DProducto
1 : MostrarIngreso()
2 : nmostrar()
3 : dmostrar()
4 : RegistrarIngreso()
5 : nmostrar()
6 : dmostrar()
7 : devolver ID()
8 : devolver ID()
9 : nmostrar()
10 : dmostrar()
11 : devolver ID()
12 : devolver ID()
13 : ningreso()
14 : dingreso()
15 : Buscar()
16 : neditar()
17 : deditar()
18 : Buscar()
19 : nanular()
20 : danular()
Figura #43Diagrama de secuencia Gestionar Ingresos
97
5.2.6.2 Interfaz gráfica del caso de uso Gestionar Ingreso
Figura #44 Interfaz de gestion de ingresos
98
5.2.7.1 Diagrama de Secuencia del caso de uso Gestionar Salida
<<boundary>> <<control>> <<entity>> <<control>> <<entity>> <<control>> <<entity>>

Salida NSalida DSalida NCliente DCliente NProducto DProducto
: ENCARGADO DE ALMACEN
1 : MostrarSalida()
2 : nmostrar()
3 : dmostrar()
4 : RegistrarSalida()
5 : dmostrar()
6 : dmostrar()
7 : devolver ID()
8 : devolver ID()
9 : nmostrar()
10 : dmostrar()
11 : devolver ID()
12 : devolver ID()
13 : ningresar()
14 : dingresar()
15 : Buscar()
16 : neditar()
17 : deditar()
18 : Buscar()
19 : neliminar()
20 : dliminar()
Figura #45 Diagrama de secuencia Gestionar Salida
99
5.2.7.2 Interfaz gráfica del caso de uso Gestionar Salidas
Figura #46 Interfaz gestion de salida
100
5.2.8.1 Diagrama de Secuencia del caso de uso Gestionar Categoría

Categoria NCategoria DCategoria
: Encargado Almacen
1 : Mostrar()
2 : nmostrar.cs()
3 : dmostrar.cs()
4 : Registrar()
5 : nregistrar.cs()
6 : dregistrar.cs()
7 : Modificar()
8 : nmodificar.cs()
9 : dmodificar.cs()
10 : Eliminar()
11 : neliminar.cs()
12 : deliminar.cs()
Figura #47 Diagrama de secuencia Gestionar Categoría

5.2.8.2 Interfaz gráfica del caso de uso Gestionar Categoría
Figura #48 Interfaz gestion de categoria
101
5.2.9.1 Diagrama de Secuencia del caso de uso Gestionar Reporte Cliente

Cliente NCliente DCliente
: Encargado Almacen
1 : Buscar Cliente()
2 : nbuscarcliente_parametro()
3 : nbuscar_cliente_paramentro()
4 : muestra_resultado_busqueda()
5 : muestra_cliente_segun_parametros()
Figura #49 Diagrama de secuencia Gestionar Reporte Cliente
5.2.9.2 Interfaz gráfica del caso de uso Gestionar Reporte Cliente
Figura #50 Interfaz reporte Cliente
102
5.2.10.1 Diagrama de Secuencia del caso de uso Gestionar Reporte Proveedor
<<boundary>> <<control>>
Proveedor NProveedor <<entity>>
DProveedor
: Encargado Almacen 1 : Buscar Proveedor()
2 : nbuscar_proveedor_parametro()
3 : dbuscar_proveedor_parametro()
4 : mostrar_resultado()
5 : muestra_proveedor_segunparametro()
Figura #51 Diagrama de secuencia Gestionar Reporte Proveedor

5.2.10.2 Interfaz gráfica del caso de uso Gestionar Reporte Proveedor
Figura #52 Interfaz reporte proveedor
103
5.2.11.1 Diagrama de Secuencia del caso de uso Gestionar Reporte Producto

Productos NProductos DProductos
: Encargado Alamcen 1 : Buscar_Producto()
2 : nbuscarproducto_parametro()
3 : dbuscarproducto_paramentro()
4 : mostrar_resultado()
5 : mostrarproducto_segunparametro()
Figura #53 Diagrama de secuencia Gestionar Reporte Producto

5.2.11.2 Interfaz gráfica del caso de uso Gestionar Reporte Producto
Figura #54 Interfaz reporte productos
104
5.2.12.1 Diagrama de Secuencia del caso de uso Gestionar Reporte de Ingresos y Salidas.
<<boundary>> <<entity>>
Reporte Salida <<control>>
NSalida DSalida
: Encargado Almacen 1 : Reporte_Salida()
2 : nsalida()
3 : dsalida()
4 : muestra_resultado()
5 : muestrasalida_segunparametro()
Figura #55 Gestionar Reportes de Ingresos y Salidas

5.2.12.2 Interfaz gráfica del caso de uso Gestionar Reporte de Ingresos y Salidas.
Figura #56 Interfaz de reporte de ingreso de mercadería
105
5.2.13.1Diagrama de Secuencia Gestionar Persona

Persona NPersona DPersona
: Encargado de Almacen1 : MostrarPersona()
2 : nmostrar()
3 : dmostrar()
4 : Registrar()
5 : ningreso.cs()
6 : dingreso.cs()
7 : Buscar()
8 : nmodificar.cs()
9 : dmodificar.cs()
10 : Eliminar()
11 : neliminar.cs()
12 : deliminar.cs()
Figura #57 Gestionar Persona
106
5.2.13.2Diagrama de Secuencia Gestionar Persona
Figura #58 Gestionar Persona
107
MODELO DE
IMPLEMENTACION VI
CAPÍTULO VI IMPLEMENTACIÓN
6 MODELO DE IMPLEMENTACION
6.1. MODELO DE COMPONENTES
6.1.1 ARQUITECTURA DEL SISTEMA
Figura #59.- Arquitectura del sistema
109
CAPÍTULO VI IMPLEMENTACIÓN
6.1.1 Modelo de Componentes Cliente
cmp M odelo Componentes Cliente
Capa Presentaci on
«executabl e»
SistVentas.exe
«fi l e»
«fi l e»
ReporteCliente
Cliente
Capa Negoci o
«fi l e»
NCliente
Capa Datos
«tabl e»
Cliente
Figura #60 Modelo de Componentes Cliente

6.1.2 Modelo de Componentes Proveedor
cmp Modelo Componentes Prov eedor
Capa Presentacion
«executable»
SistVentas.exe
«file» «file»
Prov eedor ReporteProv eedor
Capa Negocio
«file»
NProv eedor
Capa Datos
«table»
Prov eedor
Figura #61 Modelo de Componentes Proveedor
110
CAPÍTULO VI MODELO DE IMPLEMENTACIÓN
6.1.3 Modelo de Componentes Producto

cmp Modelo Componentes Producto
Capa Presentaci on
«executabl e»
SistVentas.exe
«fi l e» «fi l e»
Producto ReporteProducto
Capa Negoci o
«fi l e»
NProducto
Capa Datos
«tabl e»
Producto
Figura #62 Modelo de Componentes Producto

6.14 Modelo de Componentes Categoría
cmp Modelo Componentes Categoria
Capa Presentaci on
«executabl e»
SistVentas.exe
«fi l e» «fi l e»
Categoria ReporteCategoria
Capa Negoci o
«fi l e»
NCategoria
Capa Datos
«tabl e»
Categoria
Figura # 63 Modelo de Componentes Categoría
111
6.1.5 Modelo de Componentes Categoría
cmp Modelo Componentes Usuario
Capa Presentacion
«executable»
SistVentas.exe
«file» «file»
ReporteUsuario
Usuario
Capa Negocio
«file»
NUsuario
Capa Datos
«table»
Usuario
Figura # 64 Modelo de Componentes Categoría
112
6.2 DIAGRAMA DE DESPLIEGUE
deployment Diagrama de Despliegue
«device» SO: Windows Server 2012

Serv idor RAM: 8 GB.
CPU: Intel Xeon
HDD: 1 TB
«device»
Sw ith
tcp-ip tcp-ip
«device» «device»
Encargado Adm_Sistema SO : WIN7 32
tcp-ip
Almacen o 64 BITS
Procesador : Dual Core
RAM : 2 Gb
Disco duro : 250 Gb
Monitor : 19”
usb
SO : WIN7 32 o
64 BITS
Procesador : Dual Core «device» «device»
RAM : 2 Gb Impresora_Red Impresora_Admin
Disco duro : 250 Gb
Monitor : 19”
Figura #65 Diagrama de despliegue
113
MODELO DE PRUEBA VII
CAPÍTULO VII MODELO DE PRUEBAS
7 MODELO DE PRUEBA
7.1 Concepto de prueba de software
Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software.
Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier
momento de dicho proceso de desarrollo. Existen distintos modelos de desarrollo de software,
así como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento en
las actividades de desarrollo.
La prueba es una técnica de ejecución de un programa con la intención de mostrar un error no

descubierto hasta ese momento.
✓ Pruebas estáticas
Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación.
Puede referirse a la revisión de documentos, ya que no se hace una ejecución de código. Esto se
debe a que se pueden realizar "pruebas de escritorio" con el objetivo de seguir los flujos de la
aplicación.
✓ Pruebas dinámicas
Todas aquellas pruebas que para su ejecución requieren la ejecución de la aplicación.
Las pruebas dinámicas permiten el uso de técnicas de caja negra y caja blanca con mayor
amplitud. Debido a la naturaleza dinámica de la ejecución de pruebas es posible medir con
mayor precisión el comportamiento de la aplicación desarrollada.
a) Pruebas de caja Blanca o pruebas estructurales
Este tipo de prueba se centra en los detalles procedimentales del software, por lo que su diseño
está fuertemente ligado al código fuente. El ingeniero de pruebas escoge distintos valores de
entrada para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de
que se devuelven los valores de salida adecuados.
115
b) Pruebas de caja Negra
Se denomina Caja Negra a aquel elemento que es estudiado desde el punto de vista de las
entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento
interno. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio
que le rodea, entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por tanto,
de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en
cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.
7.2 Diseño de Casos de Prueba
7.2.1 Prueba de caso de uso del sistema
A continuación de muestra capturas del sistema, donde se aplicará la técnica de prueba de la caja
negra donde se aprecia las interfaces para su prueba
Figura #66 Login de acceso al sistema
116
Menu Principal del Sistema
Figura #67 Menu Principal del sistema
7.3 Descripcion de caso de uso de prueba del sistema
7.3.1 Caso de Gestionar Ingreso de mercadería

Caso de prueba : Gestionar ingreso de mercadería
Actores : Encargado de almacén
Tipo : Primario
Resumen : El encargado de almacén de la sucursal en la ciudad de Cobija,

registra la solicitud de suministro de mercadería a la fábrica que se encuentra en la ciudad de
Santa Cruz.
117
Interfaz 1.- Caso de Uso listado de Ingreso de Mercadería.
Figura #68 Ingreso de mercaderia listado

Interfaz 2.- Caso de Uso Registrar Ingreso de Mercadería.
Figura #69 Ingreso de mercaderia registro
118
7.3.1.1 Caso de uso: Gestionar ingreso de mercaderia
Para probar y evaluar la funcionalidad del caso de uso “Gestionar ingreso de mercaderia”, se
describe un escenario del caso de prueba, a continuacion se establece el siguiente escenario
particular.
Caso de Prueba Ingreso de Mercaderia
Entrada Idingreso=”5”
Idusuario=”1”
Idproveedor=”5”
Fecha=”02/01/2018”
Tipo_comprobante=”Boleta”
Numerocomprobante=”020118”
Iva=”16”
Estado=”Recibido en buen estado”
Direccion=”Santa Cruz”
Obseracion=”Se recibio la mercaderia en

buen estado”
Resultado • El idingreso de mercaderia es

autoincrementado.
• El idusuario es una llave foranea

de la tabla usuario donde se herada
el nombre de usuario que hace el
registro.
• El idproveedor es una llave foranea

de la tabla proveedor donde se
herada el nombre de proveedor al
119
que se le compra el producto.
• La fecha, es la fecha en que se hace

la compra de la mercaderia.
• El campo tipo_Comprobante es
con que tipo de comprobante se
hace la adquisicion de la mercaderia.
• El campo numerocomprobante es
numero de orden con que se hace la
compra.
• El campo iva es el valor de impuesto

para toda compra.
• El campo estado, indica el estado

en que se esta recibiendo la
mercaderia que esta ingresando.
• El campo direccion, es el lugar de

donde se hace la compra de la
mercaderia.
• El campo observacion, es opcional

por si se tiene alguna o comentario
que agregar de la mercaderia.
20. Tabla.- Caso de uso: Gestionar ingreso de mercaderia.
120
7.3.1.2 Flujo de eventos
FLUJO DE LOS EVENTOS INGRESO DE MERCADERIA

Acción del Actor Respuesta del Sistema
1 El encargado de almacén luego de haberse
ingresado con su usuario y contraseña, abre
el menú principal del sistema, y en el menú
selecciona ingresos.
2 El sistema carga el formulario de registro

de ingreso de mercadería al sistema, donde
aparecen dos opciones.
a) Listado
b) Mantenimiento
LISTADO
3 En el menú listado muestra los datos de la
interfaz 1, con las opciones.
4 El sistema permite realizar las siguientes

operaciones a través de:
Botón Buscar, que nos da la opción de
buscar un ingreso por fechas.
Botón Anular, nos permite anular un
ingreso.
Botón Imprimir, nos permite obtener un
reporte de nuestros ingresos de mercadería a
almacén.
5 Para hacer una búsqueda, se selecciona las

fechas Inicio y Fin.
6 El sistema muestra los ingresos

registrados en el periodo seleccionado de
búsqueda (Fechas).
7 Para obtener un reporte de ingresos
tenemos el Botón Imprimir.
8. El sistema genera el reporte solicitado, y
estos se puede imprimir, exportar a PDF,
Word o Excel.
121
MANTENIMIENTO
interfaz 2, con las opciones.
10 Al iniciar este menú, nos muestra los

botones deshabilitados.
11 El dar clic sobre el botón, Nuevo se

habilitan todas las opciones de registro de
un nuevo registro.
12 El sistema activa todos los controles

necesarios para realizar un registro nuevo.
Se selecciona un proveedor desde el botón
+ que se abre un nuevo formulario, donde
se busca el proveedor a ingresar.
Se selecciona un producto desde el botón +
que abre un nuevo formulario, donde se
busca el producto a ingresar.
Se llena todos los datos de registro y se
carga en el GriedView en el cual se puede
revisar y corregir datos antes de guardar.
13 Se Presiona en el botón Guardar.

14 Se guarda los datos del registro, se
muestra un mensaje de datos Guardados.
15 Si se desea cancelar el registro se

presionar el Botón Cancelar. 16 El sistema Cancela toda la operación y
deshabilita todos los controles.
Y está listo para un nuevo registro de
21. Tabla.- Flujo de Evento ingreso de mercadaderia
122
7.4 Descripcion de caso de uso de prueba del sistema
7.4.1 Caso de Gestionar Salida de Mercadería

Caso de prueba : Gestionar Salida de mercadería
Actores : Encargado de almacén
Tipo : Primario
Resumen : El encargado de almacén de la sucursal en la ciudad de Cobija,

registra la salida de mercadería de la sucursal hacia el cliente.
Interfaz 1.- Caso de Uso listado de Salida de Mercadería.
Figura #70 Listado de salida de mercaderia listado
123
Interfaz 2.- Caso de Uso Registrar Ingreso de Mercadería.
Figura #71 Registrar salida de mercaderia registro.
7.4.1.1 Caso de uso: Gestionar salida de mercaderia
Para probar y evaluar la funcionalidad del caso de uso “Gestionar salida de mercaderia”, se
describe un escenario del caso de prueba, a continuacion se establece el siguiente escenario
particular.
Caso de Prueba Salida de Mercaderia
Entrada Idsalida=”5”
Idusuario=”1”
Idcliente=”5”
Fecha=”02/01/2018”
124
Tipo_comprobante=”Boleta”
Numerocomprobante=”020118”
Iva=”16”
Estado=”Recibido en buen estado”
Codigo=”SALI-5”
Resultado • El idingreso de mercaderia es autoincrementado.
• El idusuario es una llave foranea de la tabla usuario

donde se herada el nombre de usuario que hace el
registro.
• El idproveedor es una llave foranea de la tabla

proveedor donde se herada el nombre de proveedor
al que se le compra el producto.
• La fecha, es la fecha en que se hace la compra de la

mercaderia.
• El campo tipo_Comprobante es con que tipo de

comprobante se hace la adquisicion de la mercaderia.
• El campo numerocomprobante es numero de orden

con que se hace la compra.
• El campo iva es el valor de impuesto para toda

compra.
• El campo estado, indica el estado en que se esta

recibiendo la mercaderia que esta ingresando.
• El campo codigo, se genera automaticamente.
22. Tabla.- Caso de uso: Gestionar ingreso de mercaderia.
125
7.4.1.2 Flujo de eventos
FLUJO DE LOS EVENTOS SALIDA DE MERCADERIA

Acción del Actor Respuesta del Sistema
1 El encargado de almacén luego de haberse
ingresado con su usuario y contraseña, abre
el menú principal del sistema, y en el menú
selecciona salidas
2 El sistema carga el formulario de registro

de salida de mercadería al sistema, donde
aparecen dos opciones.
a) Listado
b) Mantenimiento
LISTADO
interfaz 1, con las diferentes opciones.
4 El sistema permite realizar las siguientes

operaciones a través de:
Botón Buscar, que nos da la opción de
buscar un ingreso por fechas.
Botón Anular, nos permite anular un
ingreso.
Botón Imprimir, nos permite obtener un
reporte de nuestros ingresos de mercadería a
almacén.
5 Para hacer una búsqueda, se selecciona las

fechas Inicio y Fin.
6 El sistema muestra los ingresos
registrados en el periodo seleccionado de
búsqueda (Fechas).
126
7 Para obtener un reporte de ingresos 8. El sistema genera el reporte solicitado, y

tenemos el Botón Imprimir. estos se puede imprimir, exportar a PDF,
Word o Excel.
MANTENIMIENTO
interfaz 2, con las opciones. 10 Al iniciar este menú, nos muestra los
botones deshabilitados.
11 El dar clic sobre el botón, Nuevo se

habilitan todas las opciones de registro de
12 El sistema activa todos los controles
un nuevo registro.
necesarios para realizar un registro nuevo.
Se selecciona un proveedor desde el botón
+ que se abre un nuevo formulario, donde
se busca el proveedor a ingresar.
Se selecciona un producto desde el botón +

que abre un nuevo formulario, donde se
busca el producto a ingresar.
Se llena todos los datos de registro y se
carga en el GriedView en el cual se puede
revisar y corregir datos antes de guardar.
13 Se Presiona en el botón Guardar.

14 Se guarda los datos del registro, se
muestra un mensaje de datos Guardados.
15 Si se desea cancelar el registro se 16 El sistema Cancela toda la operación y

presionar el Botón Cancelar. deshabilita todos los controles.
Y está listo para un nuevo registro de
23. Tabla. - Flujo de Evento ingreso de mercadería
127
CONCLUSIONES
✓ Se realizó el análisis de ingresos y procesamiento de información, con ello se logró tener

una información confiable y de fácil acceso cuando se lo requiere
✓ Se diseñó un modelo que se adaptó a los requerimientos de información de la empresa,
para lograr hacer consultas oportunas y de fácil operación.
✓ Se obtuvo un modelo de requerimientos del sistema de información, en el cual se realizó
las pruebas correspondientes hasta lograr obtener un sistema confiable y seguro.
✓ Se documentó los modelos de análisis, diseño e implementación según (Proceso
Unificado de Desarrollo.
✓ Se Realizó pruebas del sistema de información, para llegar a la aplicación terminada
mediante la corrección de errores detectados y así poder garantizar la información que se
genere.
✓ Se implementó el sistema con toda la capacidad operacional del producto con
arquitectura tres capas.
128
RECOMENDACIONES
• Capacitación al personal que manejara el sistema, explicando todos los procedimientos y

datos a ingresar al sistema de información.
• Se recomienda usar servicio en la nube para realizar Backups diarios del sistemas para así
ante cualquier percance ajenos a las operaciones diarios se tenga respaldo.
• Se recomienda hacer Backups diarios del sistemas para así ante cualquier percance ajenos
a las operaciones diarios se tenga respaldo.
• Se recomienda utilizar un UPS, en el equipo donde estará instalado el sistema, para así
ante un corte de energía se disponga de un tiempo para guardar la información y evitar la
pérdida de datos.
• El sistema cuenta con la disponibilidad de futuras actualización y la implementación de

nuevos módulos que se requiera.
129
BIBLIOGRAFIA
Libros
 El-Proceso-Unificado-de-Desarrollo-de-Software-Jacobson-Booch-Rumbaugh
 Metodología de la Investigación - Sampieri (6ta edición).
 UML y Patrones (2da Edición) Larman.
 Estimación por Puntos de Función Bernardo Díaz http://www.fukl.edu
 Analisis-y-diseno-de-sistemas-informaticos-UTP Universidad tecnológica del Perú.
 ADO, M. (2015). https://msdn.microsoft.com/es-es/library/e80y5yhx(v=vs.110).aspx.
 Arenas, M. (2011). http://arquitecturaencapas.blogspot.com/2011/08/arquitectura-3-

capas-programacion-por.html.
 C#, M. (2013). https://es.wikipedia.org/wiki/C_Sharp.
 Jacobson, & Booch. (2000). Jacobson, Booch, Rumbaugh.
 Larman. (2 EDICION). UML Y PATRONES. En G. LARMAN.
 Microsoft. (2015). https://es.wikipedia.org/wiki/ASP.NET.
 Microsoft. (2015). https://msdn.microsoft.com/es-es/library/e80y5yhx(v=vs.110).aspx.
 reportviewer, m. (2013). https://msdn.microsoft.com/es-es/library/ms252067.aspx.
 Server, w. S. (2014). Obtenido de https://en.wikipedia.org/wiki/Microsoft_SQL_Server
 slideshare. (2013). https://es.slideshare.net/copper64/tecnologia-net-26007260.
 sparxsystems. (2016). http://www.sparxsystems.com.ar/products/ea.html.
 SQL, w. (2015). wikipedia. Obtenido de https://es.wikipedia.org/wiki/SQL
 StartUML. (2016). Obtenido de http://staruml.io/
 wikipedia. (2013). Obtenido de https://es.wikipedia.org/wiki/Microsoft_Visual_Studio
130
 wikipedia. (mayo de 2016). Obtenido de
https://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_bases_de_datos
 wikipedia. (mayo de 2016).

https://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_bases_de_datos.
Sitios Web
 https://www.osmosislatina.com/lenguajes/uml/basico.htm
 https://msdn.microsoft.com/es-es/library/bb972214.aspx
 http://www.sparxsystems.com.ar/download/ayuda/index.html?activitydiagram.htm
 https://msdn.microsoft.com/es-es/library/bb972214.aspx
 https://users.dcc.uchile.cl/~psalinas/uml/modelo.html
 http://www.pmoinformatica.com/2015/05/requerimientos-no-funcionales-ejemplos.html
131
ANEXOS
Figura #72 Reporte de clientes de la empresa
Figura # 73 Reporte de Proveedores de la empresa
132
Figura #74 Grafico de salida de mercaderia.
Figura #75 Grafico de salida de mercaderia por fechas.
133
Figura #76 Comprobante de trabajo dirigido por la empresa.
134
135
136

Documentacion TFG Luis Alfredo Padilla Falon Julio PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Documentacion TFG Luis Alfredo Padilla Falon Julio PDF

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDAD PRIVADA CUMBRE

FACULTAD DE CIENCIAS Y TECNOLOGÍA

SISTEMA DE INFORMACION PARA LA GESTION DE

TUTOR: Ing. Amílkar Cruz Herbas

Santa Cruz de la Sierra – Bolivia

Lleno de a amor, regocijo y esperanza dedico este proyecto a mis padres.

Mi agradecimiento se dirige a quien ha forjado mi camino y me ha dirigido por el

A la Universidad, por impartirnos conocimientos y sobre todo valores y principios como

Y en especial a nuestro Director de Carrera Ing. Amílkar Cruz Herbas

A los Docentes, por su tiempo y dedicación en impartirnos el conocimiento para ser

Un agradecimiento cordial a la Empresa Tigre Plasmar por haberme permitido desarrollar

Luis Alfredo Padilla Falon

TITULO Sistema de información para la gestión de inventario para la sucursal

TIPO DE ESTUDIO Descriptivo Explicativo

La investigación propuesta busca, mediante la aplicación de la teoría

La necesidad de control de inventario de productos nace y crece a

1.1 ANTECEDENTES ....................................................................................................... 1

1.1.1 ANTECEDENTES DE LA EMPRESA .................................................................... 1

1.2 DEFINICIÓN DEL PROBLEMA ............................................................................... 3

1.2.1 FORMULACIÓN DEL PROBLEMA....................................................................... 3

1.3 PROPUESTA ............................................................................................................... 4

1.4 OBJETIVOS ................................................................................................................ 4

1.4.1 OBJETIVO GENERAL ............................................................................................. 4

1.5 DELIMITACION ......................................................................................................... 5

1.5.1 DELIMITACION ESPACIAL .................................................................................. 5

1.5.2.1 ACTIVIDADES QUE NO SE TOMARAN EN CUENTA .................................. 6

1.5.3 DELIMITACIÓN TEMPORAL ................................................................................ 6

1.6 JUSTIFICACIÓN ........................................................................................................ 6

1.6.1 JUSTIFICACIÓN TEÓRICA .................................................................................... 6

1.7 DISEÑO METODOLÓGICO ...................................................................................... 8

1.7.1 TIPO DE INVESTIGACIÓN .................................................................................... 8

1.8.1 PLAN DE PROYECTO............................................................................................. 9

1.8.3.1 EQUIPO DE DESARROLLO ............................................................................. 16

1.8.3.2 EQUIPO DE IMPLEMENTACIÓN .................................................................... 16

2 MARCO TEÓRICO ...................................................................................................... 18

2.1 UML (LENGUAJE UNIFICADO DE MODELADO) ............................................ 18

2.1.1 VENTAJAS DE LA UNIFICACIÓN ..................................................................... 18

2.1.2 OBJETIVOS EN EL DISEÑO DE UML ............................................................... 18

2.1.3 ¿POR QUÉ MODELAMOS? ................................................................................. 19

2.1.4 UTILIDAD DEL MODELADO ............................................................................. 19

2.1.5 DIAGRAMA DE CASOS DE USO ....................................................................... 20

2.1.6 DIAGRAMA DE CLASES..................................................................................... 20

2.1.7 DIAGRAMA DE SECUENCIA ............................................................................. 20

2.1.8 DIAGRAMA DE COLABORACIÓN .................................................................... 21

2.1.9 DIAGRAMA DE ESTADOS ................................................................................. 21

2.1.10 DIAGRAMA DE ACTIVIDADES....................................................................... 22

2.1.11 DIAGRAMA DE PAQUETES ............................................................................. 22

2.1.12 DIAGRAMAS DE COMPONENTES.................................................................. 23

2.1.13 DIAGRAMA DE DESPLIEGUE ......................................................................... 23

2.2. PROCESO UNIFICADO DE DESARROLLO (PUD) ............................................ 23

2.2.1 EL PROCESO UNIFICADO TIENE DOS DIMENSIONES ................................ 24

2.2.2 EL PROCESO UNIFICADO ES DIRIGIDO POR CASOS DE USO ................... 24

2.2.3 EL PROCESO UNIFICADO ESTÁ CENTRADO EN LA ARQUITECTURA ... 25

2.3 TECNOLOGÍA Y ARQUITECTURA....................................................................... 27

2.3.1 ARQUITECTURA 3 CAPAS. ................................................................................ 27

2.3.1.2 BENEFICIOS DE LA ARQUITECTURA EN 3 CAPAS ................................... 27

2.3.1.3 INTERFAZ DE PROGRAMACIÓN DE APLICACIONES API

2.3.1.4 CAPA DE PRESENTACIÓN, VISTA ................................................................ 28

2.3.1.5 CAPA DE NEGOCIO, CONTROLADORES ..................................................... 29

2.3.1.6 CAPA DE DATOS, MODELO ........................................................................... 29

2.3.2. TECNOLOGÍA .NET ........................................................................................... 30

2.3.2.1. EL FRAMEWORK .NET ................................................................................. 31

2.3.2.2. ADO.NET ........................................................................................................... 32