UNIVERSIDAD NACIONAL

UNIVERSIDAD NACIONAL JORGE BASADRE GROHOMANN Facultad de Ingeniería Escuela Académico Profesional de Ingeniería en Informática y Sistemas Informe de Prácticas Pre Profesionales “IMPLEMENTACIÓN DE UN SISTEMA INTEGRAL DE CONTROL DE INVENTARIO APLICANDO LA METODOLOGÍA RUP PARA LA EMPRESA MUNDO YAOS S.R.L.” Institución Empresa Mundo Yaos S.R.L. Presentado por: Henry Victor Montesinos Chata Para optar: Grado Académico Bachiller en Ciencias con Mención en Informática y Sistemas Tacna, 17 de Marzo del 2011 Dedicado a Dios y a mi familia, quienes estuvieron cuando más los necesité Henry 1 ÍNDICE INTRODUCCIÓN ...................................................................................................... 9 I. GENERALIDADES .............................................................................................. 10 1.1 GENERALIDADES DE LA EMPRESA .......................................................... 10 1.1.1 RAZÓN SOCIAL...................................................................................... 10 1.1.2 UBICACIÓN ............................................................................................ 10 1.1.3 BREVE DESCRIPCIÓN ........................................................................... 10 1.1.4 VISIÓN..................................................................................................... 10 1.1.5 MISIÓN .................................................................................................... 11 1.1.6 OBJETIVO ............................................................................................... 11 1.1.7 ORGANIGRAMA .................................................................................... 11 1.2 OBJETIVOS DE LAS PRÁCTICAS ................................................................ 13 1.2.1 OBJETIVO GENERAL ............................................................................ 13 1.2.2 OBJETIVOS ESPECÍFICOS .................................................................... 13 1.3 OBJETIVOS DEL PROYECTO ...................................................................... 13 1.3.1 OBJETIVO GENERAL ............................................................................ 13 1.3.2 OBJETIVOS ESPECÍFICOS .................................................................... 14 1.4 DESCRIPCIÓN DEL ÁREA DE DESEMPEÑO ............................................. 14 1.4.1 NOMBRE DEL ÁREA DE DESEMPEÑO ............................................... 14 1.4.2 DESCRIPCIÓN DEL ÁREA DE TRABAJO ............................................ 14 1.4.3 FUNCIONES DEL ÁREA DE TRABAJO ................................................ 14 1.5 ACTIVIDADES REALIZADAS DURANTE LAS PRÁCTICAS .................... 15 2 II. MARCO TEÓRICO ............................................................................................ 16 2.1 ¿QUE ES UN SISTEMA? ................................................................................ 16 2.2 INGENIERÍA DE SOFTWARE ....................................................................... 16 2.3 ANÁLISIS Y DISEÑO DE SISTEMAS ........................................................... 17 2.3.1 ANÁLISIS DE SISTEMAS....................................................................... 17 2.3.2 DISEÑO DE SISTEMAS .......................................................................... 17 2.4 ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS ........................................ 18 2.5 DEFINICIÓN DE BASE DE DATOS .............................................................. 19 2.6 METODOLOGÍA RUP (RATIONAL UNIFIED PROCESS)........................... 19 2.7.2 DEFINICIÓN ............................................................................................ 19 2.7 CARACTERÍSTICAS DE UML (LENGUAJES UNIFICADO DE MODELADO) ............................................................................................................ 20 2.7.1 CARACTERÍSTICAS PRINCIPALES ..................................................... 21 2.7.2 ESTRUCTURA ESTÁTICA ..................................................................... 23 III. MATERIALES Y MÉTODOS UTILIZADOS EN LAS PRÁCTICAS PREPROFESIONALES ................................................................................................... 34 3.1 MÉTODOS PARA LA RECOLECCIÓN DE INFORMACIÓN ....................... 34 3.2 HARDWARE Y SOFTWARE ......................................................................... 34 3.2.1 HARDWARE ........................................................................................... 34 3.2.2 SOFTWARE ............................................................................................. 35 3.2.2.1 SISTEMA OPERATIVO ....................................................................... 35 3.2.2.2 HERRAMIENTAS PARA LA PLANIFICACIÓN ................................ 36 3.2.2.3 HERRAMIENTAS PARA EL ANÁLISIS ............................................. 36 3.2.2.4 HERRAMIENTAS PARA EL DESARROLLO ..................................... 36 3.3 FORMULACIÓN DEL PROBLEMA .............................................................. 36 3.3.1 PLANTEAMIENTO DEL PROBLEMA ................................................... 36 3 3.3.1.1 DEFINICIÓN DE PROBLEMA PRINCIPAL ....................................... 36 3.3.1.2 JUSTIFICACIÓN DEL PROYECTO .................................................... 38 3.3.1.3 ESTUDIO DE FACTIBILIDAD ............................................................ 39 3.3.1.4 ESTIMACIÓN DE LOS RECURSOS PRELIMINARES REQUERIDOS 46 3.3.1.5 DESCRIPCIÓN DE LA ASIGNACIÓN DE RECURSOS ..................... 47 3.3.1.6 OBTENCIÓN DE LA INFORMACIÓN PRELIMINAR Y REQUERIMIENTOS .......................................................................................... 47 3.4 METODOLOGÍA RUP PARA EL DESARROLLO DEL SISTEMA............... 49 3.4.1 PLAN DE DESARROLLO DE SOFTWARE ........................................... 49 3.4.1.1 ASPECTOS GENERALES DEL PROYECTO ...................................... 49 3.4.1.2 ORGANIZACIÓN DEL PROYECTO ................................................... 50 3.4.1.3 GESTIÓN DE PROYECTO .................................................................. 52 3.4.2 REQUISITOS ........................................................................................... 53 3.4.3.1 VISIÓN ................................................................................................. 53 3.4.3 MODELO DE CASOS DE USO ............................................................... 57 3.4.4 ESPECIFICACIONES DE CASOS DE USO ............................................ 57 3.5 ANÁLISIS Y DISEÑO .................................................................................... 57 3.5.1 MODELO DE ANÁLISIS/DISEÑO.......................................................... 57 3.5.1.1 DIAGRAMA DE CLASES.................................................................... 57 3.5.2 DISEÑO DE LA BASE DE DATOS ......................................................... 58 3.5.3 MODELO DE IMPLEMENTACIÓN........................................................ 58 3.5.3.1 DIAGRAMA GLOBAL DE PAQUETES .............................................. 58 3.5.3.2 DIAGRAMA DE COMPONENTES...................................................... 58 3.5.3.3 DIAGRAMA DE DESPLIEGUE........................................................... 58 3.5.3.4 DIAGRAMA DE ACTIVIDADES ........................................................ 58 3.5.3.5 DIAGRAMA DE ESTADOS ................................................................. 58 4 IV. RESULTADOS DE LAS PRÁCTICAS REALIZADAS ................................... 59 4.1 IMPLEMENTACIÓN ...................................................................................... 59 4.1.1 5.1 PROTOTIPOS DE INTERFAZ DE USUARIO......................................... 59 CONCLUSIONES ........................................................................................... 65 5.1.1 CONCLUSIONES DE LAS PRÁCTICAS PRE PROFESIONALES ........ 65 5.1.2 CONCLUSIONES DEL PROYECTO....................................................... 65 5.2 RECOMENDACIONES .................................................................................. 66 5.2.1 5.2.2 RECOMENDACIONES DE LAS PRÁCTICAS PRE PROFESIONALES 66 RECOMENDACIONES DEL PROYECTO ................................................. 66 VI. BIBLIOGRAFÍA ................................................................................................ 67 VII. ANEXOS............................................................................................................ 69 7.1 ANEXO 1: ESTRUCTURA DEL DESGLOSE DEL TRABAJO (EDT) .......... 69 7.2 ANEXO 2: ESTIMACIÓN DE TIEMPOS ESPERADOS ................................ 70 7.3 ANEXO 3: DIAGRAMA DE GANTT ............................................................. 71 7.4 ANEXO 4: MODELOS DE CASOS DE USO.................................................. 72 7.5 ANEXO 5: ESPECIFICACIONES DE CASOS DE USO................................. 73 7.6 ANEXO 6: DIAGRAMA DE CLASES ............................................................ 76 7.7 ANEXO 7: DISEÑO DE LA BASE DE DATOS ............................................. 77 7.8 ANEXO 8: DICCIONARIO DE DATOS ......................................................... 78 7.9 ANEXO 9: DIAGRAMA GLOBAL DE PAQUETES ...................................... 87 7.10 ANEXO 10: DIAGRAMA DE COMPONENTES ............................................ 88 7.11 ANEXO 11: DIAGRAMA DE DESPLIEGUE ................................................. 89 7.12 ANEXO 12: DIAGRAMA DE ACTIVIDADES .............................................. 90 7.13 ANEXO 13: DIAGRAMA DE ESTADOS ....................................................... 92 5 ÍNDICE DE FIGURAS FIGURA 01: ORGANIGRAMA DE EMPRESA MUNDO YAOS S.R.L. ......... 12 FIGURA 02: FASES, ITERACIONES Y DISCIPLINAS .................................. 22 FIGURA 03: ROLES, ACTIVIDADES Y ARTEFACTOS ................................ 25 FIGURA 04: INTERFAZ PRINCIPAL DEL SISTEMA .................................... 59 FIGURA 05: MENÚ ARCHIVO ....................................................................... 60 FIGURA 06: OPCIONES MENÚ VER ............................................................. 61 FIGURA 07: MENÚ HERRAMIENTAS ........................................................... 61 FIGURA 08: OPCIONES DE COMPRA ........................................................... 62 FIGURA 09: OPCIÓN DE PRODUCTOS ......................................................... 62 FIGURA 10: OPCIÓN DE VENTAS................................................................. 63 FIGURA 11: FORMULARIO DE LOGOTIPO ................................................. 63 FIGURA 12: FORMULARIO DIAGNÓSTICO DE PROBLEMAS .................. 64 FIGURA 13: DIAGRAMA DE DESGLOSE ..................................................... 69 FIGURA 14: ESTIMACIÓN DE TIEMPOS ESPERADOS ............................... 70 FIGURA 15: DIAGRAMA GANTT .................................................................. 71 FIGURA 16: CASO DE USO REGISTRAR VENTAS .................................... 722 FIGURA 17: CASO DE USO REGISTRAR COMPRAS ................................ 722 FIGURA 18: CASO DE USO EMITIR REPORTES SOLICITADOS.............. 722 FIGURA 19: DIAGRAMA DE CLASES......................................................... 766 FIGURA 20: DISEÑO DE LA BASE DE DATOS .......................................... 777 FIGURA 21: DIAGRAMA DE PAQUETES. .................................................... 87 6 FIGURA 22: DIAGRAMA DE COMPONENTES............................................. 80 FIGURA 23: DIAGRAMA DE DESPLIEGUE.................................................. 88 FIGURA 24: DIAGRAMA DE ACTIVIDADES – REGISTRAR VENTAS. ..... 90 FIGURA 25: DIAGRAMA DE ACTIVIDADES – REGISTRAR COMPRAS . . 91 FIGURA 26: DIAGRAMA DE ACTIVIDADES – EMITIR REPORTES. ......... 91 FIGURA 27: DIAGRAMA DE ESTADOS – REGISTRAR VENTAS. ............. 92 FIGURA 28: DIAGRAMA DE ESTADOS – REGISTRAR COMPRAS. .......... 93 FIGURA 21: DIAGRAMA DE ESTADOS – EMITIR REPORTES. ................. 93 7 ÍNDICE DE TABLAS TABLA 01: PRINCIPALES PRODUCTOS EN RUP ...................................... 266 TABLA 02: CARACTERÍSTICAS DEL EQUIPO .......................................... 355 TABLA 03: DISPOSITIVOS EXTERNOS ...................................................... 355 TABLA 04: ROLES Y RESPONSABILIDADES .............................................. 52 TABLA 05: DEFINICIÓN DELPROBLEMA ................................................... 54 TABLA 06: POSICIÓN DELPRODUCTO ........................................................ 55 TABLA 07: RESUMEN DE USUARIOS .......................................................... 56 TABLA 08: CU-001 .......................................................................................... 73 TABLA 09: CU-002 .......................................................................................... 74 TABLA 10: CU-003 .......................................................................................... 75 8 INTRODUCCIÓN El control de mercadería de una empresa es un factor muy importante para el desarrollo de la misma ya que se ha visto que a causa de este mal control no se tiene un óptimo manejo de los productos que ingresan y salen de la empresa y a la vez, no permite realizar los pedidos o requerimientos de manera oportuna a los proveedores. Hoy en día las empresas que quieren surgir tienen que pensar en ofrecer cada vez un mejor servicio a sus clientes y obtener buenos productos consiguiendo proveedores confiables y con garantía comprobada, por ello es que es indispensable tener de manera oportuna y concisa, la información actualizada de los productos que se tienen en tiempo real, para que esta manera la empresa pueda tomar buenas decisiones y ser más competitivo en el mercado. 9 I. GENERALIDADES 1.1 GENERALIDADES DE LA EMPRESA 1.1.1 RAZÓN SOCIAL Empresa MUNDO YAOS S.R.L. 1.1.2 UBICACIÓN Av. San Martín 872, 2do Piso 1.1.3 BREVE DESCRIPCIÓN MUNDO YAOS S.R.L. es una empresa dedicada en brindar equipos diversos de tecnología de punta y software actualizado, la cual actualmente está asociada con una de las mejores marcas como HP, a la vez ofrece servicios de garantía y mantenimiento de los mismos equipos de la empresa y del público en general. 1.1.4 VISIÓN Ser la una empresa líder en el sur del Perú ofreciendo los mejores equipos de tecnología y dando los mejores servicios de garantía y mantenimiento de hardware y software. 10 1.1.5 MISIÓN Brindar a la población de Tacna soluciones tecnológicas con productos de hardware y software de buena calidad y adecuados a sus requerimientos. 1.1.6 OBJETIVO Contar con la mejor tecnología de punta con la finalidad de aumentar la competitividad en el mercado dando un mejor servicio a la población de Tacna. 1.1.7 ORGANIGRAMA 11 Figura 01: Organigrama de Empresa Mundo Yaos S.R.L. Fuente: Propia 12 1.2 OBJETIVOS DE LAS PRÁCTICAS 1.2.1 OBJETIVO GENERAL  Aplicar los conocimientos adquiridos en los años de formación en la universidad, mostrando así la capacidad para la resolución de problemas reales que se presenten en la empresa MUNDO YAOS S.R.L. 1.2.2 OBJETIVOS ESPECÍFICOS  Obtener mayor experiencia profesional relacionado a la carrera estudiada.  Brindar con eficiencia y responsabilidad las tareas encomendadas por la empresa. 1.3 OBJETIVOS DEL PROYECTO 1.3.1 OBJETIVO GENERAL  Implantar un Sistema Integral de Inventario para un mejor control de mercadería de la empresa. 13 1.3.2 OBJETIVOS ESPECÍFICOS  Optimizar el control en los procesos diarios de reportes de inventario para una mejor toma de decisiones. 1.4 DESCRIPCIÓN DEL ÁREA DE DESEMPEÑO 1.4.1 NOMBRE DEL ÁREA DE DESEMPEÑO Área de Informática y Soporte Técnico 1.4.2 DESCRIPCIÓN DEL ÁREA DE TRABAJO El Área de Informática y Soporte Técnico se encarga de administrar el sistema administrativo de la empresa como también de controlar el manejo de las cámaras IP instalados en los puntos estratégicos de la empresa y a la vez ofrecer mantenimiento y reparación de los equipos tecnológicos que brinda la empresa y del público en general. 1.4.3 FUNCIONES DEL ÁREA DE TRABAJO  Administrar el buen funcionamiento de las conexiones de red con el servidor y sistema administrativo de la empresa.  Administrar la activación de las cámaras IP que se encuentran instaladas en puntos estratégicos de la empresa. 14  Instalación de software y hardware de los equipos informáticos de la empresa y del público en general.  Proporcionar garantía de los equipos y ofrecer mantenimiento y reparación de los equipos tecnológicos que brinda la empresa a sus clientes. 1.5 ACTIVIDADES REALIZADAS DURANTE LAS PRÁCTICAS  Mantenimiento preventivo y correctivo de los equipos tecnológicos como laptops, desktops, computadoras de escritorio, impresoras, etc.  Reparación, ensamblaje y mantenimiento de equipos de cómputo para el público en general.  Administrar el servidor y sistema administrativo de la empresa.  Instalación de software y hardware actualizado de los equipos informáticos en la empresa.  Control de las conexiones de las cámaras IP y de las redes LAN de la empresa.  Asesoramiento del funcionamiento y manejo de los equipos tecnológicos para los clientes de la empresa.  Instalación y capacitación para el manejo del sistema Integral de Inventario para el control de mercadería de la empresa MUNDO YAOS S.R.L. 15 II. MARCO TEÓRICO 2.1 ¿QUE ES UN SISTEMA? Un sistema basado en computadora es “Un conjunto o disposición de elementos organizados para realizar un objetivo predefinido procesando Según Roger Pressman información”. 1 “Un sistema es un conjunto de componentes que interaccionan entre sí para lograr un objetivo común”. 2 Según James Senn Un sistema aislado no intercambia ni materia ni energía con el medio ambiente. 3 2.2 INGENIERÍA DE SOFTWARE Es una disciplina o área de la informática o ciencias de la computación, que ofrece métodos y técnicas para desarrollar y mantener software de calidad que resuelven software de todo tipo, hoy en día es cada vez más frecuente la 1 Pressman Roger, “Ingeniería de Software: Un enfoque práctico”, 5ta Edición, Mc Graw-Hill/Interamericana, España, pp.166 2 Senn, James A., “Análisis y diseño de sistemas de información”,2002, Segunda Edición, Mc Graw Hill, Cap. I: Introducción al desarrollo de sistemas de información, pp.15 3 Published in Computer Networks and ISBN systems http://www7.scu.edu.au/1853/com1853.htm 16 consideración de la ingeniería de software como una nueva área de la ingeniería. 4 2.3 ANÁLISIS Y DISEÑO DE SISTEMAS 2.3.1 ANÁLISIS DE SISTEMAS Según Senn James, análisis de sistemas “es el proceso de clasificación e interpretación de hechos, diagnóstico de problemas y empleo de la información para recomendar mejoras al sistema. Este es el trabajo del analista de sistemas” 5 2.3.2 DISEÑO DE SISTEMAS El diseño de sistemas se define el proceso de aplicar ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o un sistema, con suficientes detalles como para permitir su interpretación y realización física. 6 4 Pressman Roger, “Ingeniería de Software: Un enfoque práctico”, 2002, 5ta Edición, Mc GrawHill/Interamericana, España, Cáp.14: Ingeniería de Sistemas, pp.166 5 Senn, James A., “Análisis y diseño de sistemas de información”,2002, Segunda Edición, Mc Graw Hill, Cap. I: Introducción al desarrollo de sistemas de información, pp.20 6 Senn, James A., “Análisis y diseño de sistemas de información”,2002, Segunda Edición, Mc Graw Hill, Cap. I: Introducción al desarrollo de sistemas de información, pp.25 17 Etapas del diseño de sistemas:  El diseño de los datos: Transforma el modelo de dominio de la información, creado durante el análisis en las estructuras de datos necesarios para implementar el Software.  El diseño arquitectónico: Define la relación entre cada uno de los elementos estructurales del programa.  El diseño de la interfaz: Describe como se comunica el software consigo mismo, con los sistemas que operan junto con él y con los operadores y usuarios que lo emplean. 2.4 ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS Análisis Orientado a Objetos, es un método de análisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema. Diseño Orientado a Objetos es un método de diseño que abarca el proceso de descomposición orientado a objetos y una notación para describir los 18 modelos lógicos y físicos, así como los modelos estático y dinámico del sistema que se diseña. 7 2.5 DEFINICIÓN DE BASE DE DATOS Una base de datos es una colección de información organizada de forma que un programa de ordenador pueda seleccionar rápidamente los fragmentos de datos que necesite. Una base de datos es un sistema de archivos electrónico. Los procedimientos de actualización y recuperación comunes y bien determinados, habrán de ser capaces de conservar la integridad, seguridad y confidencialidad del conjunto de datos”. 8 2.6 METODOLOGÍA RUP (RATIONAL UNIFIED PROCESS) 2.7.2 DEFINICIÓN El Proceso Unificado de Rational es un proceso de ingeniería del software. Proporciona un acercamiento disciplinado a la asignación de tareas y responsabilidades en una organización de desarrollo. Su propósito es asegurar la producción de software de alta calidad que se 7 G. Booch, “Análisis y Diseño Orientado a Objetos con Aplicaciones”, 1996, 2ª Edición, Addison-Wesley/ Diaz Santos, pp. 49. 8 Castaño, Adoración de Miguel, Piattini Velthuis, Mario Gerardo; “Concepción y diseño de base de datos”, pp.46 19 ajuste a las necesidades de sus usuarios finales con unos costos y calendario predecibles. 9 En definitiva el RUP es una metodología de desarrollo de software que intenta integrar todos los aspectos a tener en cuenta durante todo el ciclo de vida del software, con el objetivo de hacer abarcables tanto pequeños como grandes proyectos de software. 10 2.7 CARACTERÍSTICAS DE UML (LENGUAJES UNIFICADO DE MODELADO) UML es un lenguaje de modelado, no un método ni una metodología. 11 UML es un lenguaje para:  Visualizar  Especificar  Construir  Documentar 9 Philipe Kruchten, “Proceso Unificado Rational: Una introducción”, 2001, Adisson Wesley, pp.86 Ivar Jacobson, Grady Booch, James Rumbaugh, “El proceso unificado de desarrollo de software” 11 G. Booch, J. Rumbaugh, I. Jacobson. 1999 “El Lenguaje Unificado de Modelado”. Adisson-Wesley, pp. 96,102 10 20 2.7.1 CARACTERÍSTICAS PRINCIPALES  GUIADO/MANEJADO POR CASOS DE USO La razón de ser de un sistema software es servir a usuarios ya sean humanos u otros sistemas; un caso de uso es una facilidad que el software debe proveer a sus usuarios. Los casos de uso reemplazan la antigua especificación funcional tradicional y constituyen la guía fundamental establecida para las actividades a realizar durante todo el proceso de desarrollo incluyendo el diseño, la implementación y las pruebas del sistema.  CENTRADO EN ARQUITECTURA La arquitectura involucra los elementos más significativos del sistema y está influenciada entre otros por software, plataformas sistemas operativos, manejadores de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados y requerimientos no funcionales. Es como una radiografía del sistema que estamos desarrollando, lo suficientemente completa como para que todos los implicados en el desarrollo tengan una idea clara de qué es lo que están construyendo, pero lo 21 suficientemente simple como para que si quitamos algo, una parte importante del sistema quede sin especificar. Figura 02: Fases, iteraciones y disciplinas Fuente: Según Roger Pressman  ITERATIVO E INCREMENTAL Para hacer más manejable un dividirlo en ciclos. Para cada proyecto se recomienda ciclo se establecen fases de referencia, cada una de las cuales debe ser considerada como un Mini proyecto cuyo núcleo fundamental está constituido por una o más iteraciones de las actividades principales básicas de cualquier proceso de desarrollo. 22 ADEMÁS DE ESTAS CARACTERÍSTICAS PRINCIPALES SEGÚN GONZÁLEZ GUSTAVO A CABE DESTACAR LAS SIGUIENTES: 12  DESARROLLO BASADO EN COMPONENTES La creación de sistemas intensivos en software requiere dividir el sistema en componentes con interfaces que posteriormente ensamblados serán sistema. Esta característica en un proceso permite que bien definidas, para generar el de desarrollo el sistema se vaya creando a medida que se obtienen o que se desarrollen y maduran sus componentes. 2.7.2 ESTRUCTURA ESTÁTICA La estructura estática del proceso unificado se define en base a cuatro elementos, que son: los roles (antes workers), que responde a la pregunta ¿quién?, las actividades (activities), que responden a la pregunta ¿cómo?, los productos (artefactos), que responden a la pregunta ¿qué?, y los flujos de trabajo (workflows), que responden a la pregunta ¿cuándo? La definición de estos términos es:  ROLES 12 Ramírez González, Laboratorio III de Electrónica, Anotaciones RUP, 2001. 23 Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Una persona puede desempeñar diversos roles, así como un mismo rol puede ser representado por varias personas. Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades como el ser el ‘dueño’ de un conjunto de artefactos.  ACTIVIDADES Una actividad de un trabajador en concreto es una unidad de trabajo que una persona que desempeñe ese rol puede ser solicitado a que realice. Las actividades tienen un objetivo concreto, normalmente expresado en términos de crear o actualizar algún producto.  PRODUCTO Un producto o artefacto es un trozo de información que es producido, modificado o usado por un proceso. Los productos son los resultados tangibles del proyecto, las cosas que va creando y usando hasta obtener el producto final. 24 Figura 03: Roles, actividades y artefactos Fuente: Según Roger Pressman  FLUJOS DE TRABAJO La mera enumeración de define un proceso, roles, actividades y artefactos no necesitamos definir actividades realizadas por los diferentes roles, relación entre la secuencia de así como la los mismos, que nos producen unos resultados observables. El RUP define varios flujos de trabajo distintos, entre los que distingue entre dos grupos, los de proceso, y los de apoyo. Las distintas iteraciones a realizar consistirá en la ejecución de estos flujos de trabajo con una mayor o menos intensidad dependiendo de la fase e iteración en la que nos encontremos, como ya vimos un poco más arriba y que aclaramos en la Figura 02. 25 2.7.3 FASES Como ya se ha visto en el apartado anterior, el RUP se divide en cuatro fases, las cuales pasaremos a ver con más detalle. 13 Flujo Productos Administración Plan de desarrollo Caso de negocio del Proyecto Lista de riesgos Modelo de Casos de Uso Visión Requisitos Especificación Adicional Glosario Modelo de diseño Análisis y Documentación de Diseño la arquitectura SW Modelo de Implementación implementación Plan de test Test Despliegue Inicio I Elaboración Construcción Transición R R R I R R R I R I R I R I R I I R I I R I R Plan de despliegue R I Tabla 01: Principales productos en RUP Fuente: Propia a. INICIO Antes de iniciar un proyecto es conveniente plantearse algunas cuestiones: ¿Cuál es el objetivo? ¿Es factible? ¿Lo 13 “Ciclo de Vida del Proceso Unificado racional”, Una tabla resumen de los flujos, trabajadores y productos. 26 construimos o lo compramos? ¿Cuánto va a costar? La fase de inicio trata de responder a estas preguntas y a otras más. Sin embargo no pretendemos una estimación precisa o la captura de todos los requisitos. Más bien se trata de explorar el problema lo justo para decidir si vamos a continuar o a dejarlo. Generalmente no debe durar mucho más de una semana. Según Philipe kruchten, los objetivos son: 14  Establecer el ámbito del proyecto y sus límites.  Encontrar los casos de uso críticos del sistema, los escenarios básicos que definen la funcionalidad.  Mostrar al menos una arquitectura candidata para los escenarios principales.  Estimar el coste en recursos y tiempo de todo el proyecto.  Estimar los riesgos, las fuentes de incertidumbre. Los síntomas de que no se ha entendido la fase de inicio: 14  Dura más de unas pocas semanas.  Se intentan definir todos los requisitos. Philipe Kruchten, “Proceso Unificado Rational”, 2001, Adisson Wesley, pp.86 27  Se espera que las estimaciones o los planes sean muy precisos.  Definir la arquitectura completamente, en lugar de refinarla en la fase de elaboración.  No se definen el caso de negocio o la visión.  Los nombres de la mayoría de los casos de uso o actores no se han definido. Al terminar la fase de inicio se deben comprobar los criterios de evaluación para continuar:  Todos los interesados en el proyecto coinciden en la definición del ámbito del sistema y las estimaciones de agenda.  Entendimiento los requisitos, evidenciado por la fidelidad de los casos de uso principales.  Las estimaciones de tiempo, coste y riesgo son creíbles.  Comprensión total de cualquier prototipo de la arquitectura desarrollado.  Los gastos hasta el momento se asemejan a los planeados. Si el proyecto no pasa estos criterios hay que plantearse abandonarlo o repensarlo profundamente 28 b. ELABORACIÓN El propósito de la fase de elaboración es analizar el del problema, establecer dominio los cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los mayores riesgos. Cuando termina esta fase se llega al punto de no retorno del proyecto: a partir de ese momento pasamos de las relativamente ligeras y de poco riesgo dos primeras fases, a afrontar la fase de construcción, costosa y arriesgada. Es por esto que la fase de elaboración es de gran importancia. 15 Los objetivos de esta fase son:  Definir, validar y cimentar la arquitectura.  Completar la visión.  Crear un plan fiable para la fase de construcción. Este plan puede evolucionar en sucesivas iteraciones. Debe incluir los costes si procede.  Demostrar que la arquitectura propuesta soportará la visión con un coste razonable y en un tiempo razonable. 15 Philipe Kruchten, “Proceso Unificado Rational”, 2001, Adisson Wesley, pp.96 29 Al terminar deben obtenerse los siguientes productos:  Un modelo de casos de uso completa al menos hasta el 80%: todos los casos y actores identificados, la mayoría de los casos desarrollados.  Requisitos adicionales.  Descripción de la arquitectura software.  Un prototipo ejecutable de la arquitectura.  Lista de riesgos y caso de negocio revisados.  Plan de desarrollo para el proyecto.  Un caso de desarrollo actualizado que especifica el proceso a seguir.  c. Posiblemente un manual de usuario preliminar. CONSTRUCCIÓN La finalidad principal de esta fase es alcanzar la capacidad operacional del producto de forma incremental las a través de sucesivas iteraciones. Durante esta fase todas los componentes, características y requisitos, que no lo hayan sido hecho hasta ahora, han de ser implementados, integrados 30 y testeados, obteniéndose una versión del producto que se pueda poner en manos de los usuarios. El énfasis en esta fase se pone controlar las operaciones realizadas, administrando los recursos eficientemente, de tal forma que se optimicen los costes, los calendarios y la calidad. Los objetivos concretos según Philipe Kruchten, son: 16  Minimizar los costes de desarrollo mediante la optimización de recursos y evitando el tener que rehacer un trabajo o incluso desecharlo.  Conseguir una calidad adecuada tan rápido como sea práctico.  Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan rápido como sea práctico. Los productos de la fase de construcción deben ser:  Modelos Completos (Casos de Uso, Análisis,, Diseño, Despliegue e Implementación)  16 Arquitectura íntegra (mantenida y mínimamente actualizada) Philipe Kruchten, “Proceso Unificado Rational”, 2001, Adisson Wesley, pp.186 31 d.  Riesgos Presentados Mitigados  Plan del Proyecto para la fase de Transición  Manual Inicial de Usuario (con suficiente detalle)  Prototipo Operacional – beta  Caso del Negocio Actualizado TRANSICIÓN La finalidad de la fase de transición es poner el producto en manos de los usuarios finales, para lo requerirá desarrollar nuevas que versiones típicamente actualizadas se del producto, completar la documentación, entrenar al usuario en el manejo del producto, y en general tareas relacionadas con el ajuste, configuración, instalación y usabilidad del producto. Se citan algunas de las cosas que según Philipe Kruchten, puede incluir esta fase: 17  Testeo de la versión Beta para validar el nuevo sistema frente a las expectativas de los usuarios.  Funcionamiento paralelo con los sistemas legados que están siendo sustituidos por nuestro proyecto.  17 Conversión de las bases de datos operacionales. Philipe Kruchten, “Proceso Unificado Rational”, 2001, Adisson Wesley, pp.150 32  Entrenamiento de los usuarios y técnicos de mantenimiento.  Traspaso del producto a los equipos de marketing, distribución y venta. Los principales objetivos de esta fase son:  Conseguir que el usuario se valga por sí mismo.  Un producto final que cumpla los requisitos esperados, funcione y que satisfaga suficientemente al usuario. Los productos de la fase de transición son:  Prototipo Operacional  Documentos Legales  Caso del Negocio Completo  Línea de Base del Producto completa y corregida que incluye todos los modelos del sistema  Descripción de la Arquitectura completa y corregida 33 III. MATERIALES Y MÉTODOS UTILIZADOS EN LAS PRÁCTICAS PRE-PROFESIONALES 3.1 MÉTODOS PARA LA RECOLECCIÓN DE INFORMACIÓN Se obtuvo información mediante encuestas y entrevistas realizadas al personal de la empresa y algunos clientes para conocer las necesidades principales para un óptimo proceso en atención al cliente. Se utilizó la herramienta de internet y libros informáticos y contables con respecto a la facturación y el control de entrada y salida de mercadería. 3.2 HARDWARE Y SOFTWARE 3.2.1 HARDWARE Características del equipo Placa Madre Intel Desktop Board DG41RQ Procesador Intel Core 2 Duo de 2.66 GHz E6750 Memoria RAM 2 GB Disco Duro 320 GB Quemadora Lectora DVD LG S-ATA 48X/42X COMBO 34 Tarjeta de Video Intel(R) Q35 Express Chipset Family (384 MB) Tarjeta de Red Tarjeta de Red Intel(R) 82566DM Gigabit Network Connection Tabla 02: Características del equipo Fuente: Propia Dispositivos Externos Teclado HP Multimedia Mouse Hp Óptico Monitor LCD 17" Impresora HP Deskjet F2480 Multifuncional Tabla 03: Dispositivos externos Fuente: Propia 3.2.2 SOFTWARE 3.2.2.1 SISTEMA OPERATIVO El sistema se desarrollo en la plataforma Windows 7 Ultimate Copyright @ 2009 Microsoft Corporation Reservados todos los derechos 35 3.2.2.2 HERRAMIENTAS PARA LA PLANIFICACIÓN Microsoft Project 2007 Microsoft Office Project 2007 (12.0.4518.1014) Copyright 2006 Microsoft Corporation Reservados todos los derechos 3.2.2.3 HERRAMIENTAS PARA EL ANÁLISIS Rational Rose Enterprise Edition Release Versión 7.0 3.2.2.4 HERRAMIENTAS PARA EL DESARROLLO Microsoft SQL Server 2005 – 9.00.1399.06 (Intel X86) Copyright (c) 1988 – 2005 Microsoft Corporation Developer Edition on Windows NT 5.1 Erwin Data Modeler Versión 7.1 Microsoft Visual Studio 2008 Versión 9.0.21022.8.RTM (c) 2007 Microsoft Corporation 3.3 FORMULACIÓN DEL PROBLEMA 3.3.1 PLANTEAMIENTO DEL PROBLEMA 3.3.1.1 DEFINICIÓN DE PROBLEMA PRINCIPAL 36 Actualmente la empresa MUNDO YAOS S.R.L. cuenta con un servidor que tiene instalado un sistema de inventario que incluye de facturación y de asistencia, la cual se encuentra defectuoso e inutilizable por ello sólo es utilizado el sistema de asistencia. Al no contar con un sistema óptimo para el control de los productos que ingresan y salen a diario, tampoco se pueden obtener reportes en tiempo real de manera oportuna, clara y concisa. El manejo que se realiza para dicho control mediante el programa Microsoft Office Excel no es muy óptimo en este caso, ya que es más tedioso en el momento de requerir reportes o información de algún producto o de toda la tienda en tiempo real, debido a que la empresa cuenta con dos tiendas de ventas, por ello se necesita un buen sistema integral de inventario para que de esta manera se pueda realizar la toma de decisiones de forma oportuna y sea más eficiente y rápida la solicitud de mercadería con los proveedores. Además es necesario añadir un sistema de facturación que irá de la mano para el control de inventario, con la cual se podrá 37 proporcionar una mejor atención a los clientes, más eficiente y rápida. 3.3.1.2 JUSTIFICACIÓN DEL PROYECTO Para toda empresa que busca progresar y crecer en un mercado competitivo, busca maximizar las ganancias y minimizar los costos y a la vez tomar buenas decisiones que enfoquen una buena atención al cliente y tener el control total del negocio. Automatizar el ingreso y salida de los productos de la empresa y la facturación para una mejor atención al cliente y causar a la vez una buena apariencia a la empresa, la cual precisamente trata de tecnología de punta y es muy importante para el desarrollo de la empresa, no puede faltar un sistema integral de inventario que ayude a controlar los flujos de entrada y salida, a la vez las pérdidas o ganancias que se puedan generar en los flujos de trabajo diario Principalmente el sistema ayudará a tener una correcta toma de decisiones para buscar el desarrollo de la empresa. 38 3.3.1.3 ESTUDIO DE FACTIBILIDAD “Las investigaciones preliminares examinan la factibilidad de un proyecto, la posibilidad de que un sistema sea de utilidad para la organización. Se estudian tres pruebas de factibilidad, todas ella importantes: técnica, económica y operacional. ” Según James Senn. a. FACTIBILIDAD TÉCNICA 1. ¿EXISTE O SE PUEDE ADQUIRIR LA TECNOLOGÍA NECESARIA PARA REALIZAR LO QUE SE PIDE? La empresa Mundo Yaos S.R.L. cuenta con suficiente tecnología como para poder desarrollar el sistema, precisamente porque se dedica a compra y venta de tecnología de punta. 2. ¿EL EQUIPO PROPUESTO TIENE LA CAPACIDAD TÉCNICA PARA SOPORTAR TODOS LOS DATOS REQUERIDOS PARA USAR EL NUEVO SISTEMA? Sí, ya que los equipos cuentan con los requisitos mínimos para que funcione de manera óptima el Sistema Integral de Inventario. 39 3. ¿EL SISTEMA PROPUESTO OFRECERÁ RESPUESTAS ADECUADAS A LAS PETICIONES, SIN IMPORTAR EL NÚMERO Y UBICACIÓN DE LOS USUARIOS? Sí, teniendo en cuenta que el equipo tiene gran capacidad técnica y además el sistema estará instalado en un servidor, con el que se cuenta una óptima conexión con los equipos de las dos tiendas. 4. SI SE DESARROLLA EL SISTEMA, ¿PUEDE CRECER CON FACILIDAD? Sí, ya que el sistema está desarrollado con un programa que está orientado a objetos, además se podrá añadir reportes y consultas que sean necesarias en el futuro, también código está claramente documentado para un mayor entendimiento. 5. ¿EXISTEN GARANTÍAS TÉCNICAS DE EXACTITUD, CONFIABILIDAD, FACILIDAD DE ACCESO Y SEGURIDAD DE LOS DATOS? Sí, será controlado mediante un servidor y con una copia de seguridad de la data las cuales sólo el administrador tendrá los privilegios de controlar toda la información clasificada de 40 la empresa, en cuanto a los usuarios tendrán ciertas limitaciones en el sistema, pero lo suficiente para un fácil acceso y confiable. Por lo tanto existe factibilidad técnica. b. FACTIBILIDAD ECONÓMICA 1. EL COSTO DE LLEVAR A CABO LA INVESTIGACIÓN COMPLETA DE SISTEMAS La investigación del sistema no tendrá costo alguno ya que será realizado por mi persona para fines netamente académicos. 2. EL COSTO DEL HARDWARE Y SOFTWARE PARA LA APLICACIÓN La empresa cuenta con un pequeño presupuesto para la licencia de software que sea necesaria, con respecto al hardware la empresa ya contaba con el equipo necesario y disponible. 41 3. BENEFICIOS EN LA FORMA DE REDUCCIÓN DE COSTOS O DE MENOS ERRORES COSTOSOS El sistema será muy beneficioso para la empresa, la cual optimizará el rendimiento de los procesos y a la larga cubrirá los gastos debido al sistema. 4. EL COSTO SI NADA SUCEDE.(ES DECIR, SI EL PROYECTO NO SE LLEVA A CABO) El costo prácticamente será nulo ya que es realizado por mi persona con fines académicos y antes de comprar la licencia el sistema sería probado. Por lo tanto existe factibilidad económica. c. FACTIBILIDAD OPERATIVA 1. ¿EXISTE APOYO SUFICIENTE PARA EL PROYECTO POR PARTE DE LA ADMINISTRACIÓN?, ¿Y POR PARTE DE LOS USUARIOS? Sí, existe total apoyo por parte de la empresa y de los usuarios, precisamente por el motivo de obtener reportes e información en tiempo real. 42 2. ¿LOS MÉTODOS QUE ACTUALMENTE SE EMPLEAN EN LA EMPRESA, SON ACEPTADOS POR LOS USUARIOS? Actualmente existe un sistema rústico, la cual no es utilizada, por lo tanto solo utilizan el programa Microsoft Excel para realizar algunos cálculos, por todo ello los usuarios no están conformes. 3. ¿LOS USUARIOS HAN PARTICIPADO EN LA PLANEACIÓN Y DESARROLLO DEL PROYECTO? Sí, los usuarios me proporcionaron toda la información disponible para realizar el análisis y diseño del negocio, además de una pequeña encuesta para la aceptación del sistema. 4. ¿EL SISTEMA PROPUESTO CAUSARÁ PREJUICIOS? No, ya que anteriormente se realizarán pruebas del sistema para una mejor aceptación de parte de los usuarios. 43 5. ¿PRODUCIRÁ RESULTADOS POBRES EN ALGÚN ASPECTO O ÁREA? No, ya que las dos tiendas tienen los mismos funcionamientos, precisamente en los que se enfocará el sistema. 6. ¿SE PERDERÁ EL CONTROL EN ALGUNA ÁREA? No, ya que cada tienda en las cuales estarán instaladas el sistema se conectará mediante un servidor, en donde habrá un mejor control. 7. ¿SE PERDERÁ LA FACILIDAD DE ACCESO A LA INFORMACIÓN? No, además se contará con una contraseña para cada usuario, de tal manera que cada uno será responsable de los actos que se realicen en el sistema, pero con acceso muy fácil. 44 8. ¿LA PRODUCTIVIDAD DE LOS EMPLEADOS SERÁ MENOR DESPUÉS QUE ANTES DE LA IMPLANTACIÓN? No, al contrario será mayor ya que habrá un mejor y rápido servicio con el público, proveedores y con la administración de la empresa. 9. ¿LOS CLIENTES SE VERÁN AFECTADOS EN FORMA POCO FAVORABLE? No, los clientes serán unos de los más beneficiados debido a que habrá una atención más rápida y con información de stock de los productos de manera más precisa. 10. ¿EL SISTEMA REDUCIRÁ LA PRODUCTIVIDAD DE OTRAS ÁREAS? No, de ninguna manera ya que ayudará a que las tiendas puedan comparar la información de las compras, ventas y de los productos que tienen en stock para la administración y así una mejor toma de decisiones. Por lo tanto existe factibilidad operativa. 45 Por lo tanto se concluye que el Sistema Integral de Inventario es factible para la empresa. 3.3.1.4 ESTIMACIÓN DE LOS RECURSOS PRELIMINARES REQUERIDOS a. RECURSOS HUMANOS  1 Analista  1 programador b. RECURSOS DE SOFTWARE  Microsoft Windows 7 Ultimate  Microsoft Office Word 2007  Microsoft Office Excel 2007  Microsoft Office Project 2007  Microsoft SQL Server 2005 Management Edition  Microsoft Visual Studio 2008  IBM Rational Rose Enterprise  Erwin Data Modeler Versión 7.1 c. RECURSOS HARDWARE (Véase 3.2.1) 46 d. OTROS RECURSOS  400 unidades de papel bond A4  Tinta para recargar cartucho HP 22 3.3.1.5 DESCRIPCIÓN DE LA ASIGNACIÓN DE RECURSOS Nuestro proyecto requiere de una serie de recursos humanos, recursos de software y recursos de hardware, las cuales serán debidamente asignadas a las tareas o actividades que involucra el modelo del proceso de software. 3.3.1.6 OBTENCIÓN DE LA INFORMACIÓN PRELIMINAR Y REQUERIMIENTOS Se realizaron encuestas al personal de la empresa y también se tuvieron reuniones con el jefe de Informática y Soporte Técnico y con la jefa de Ventas, para analizar y determinar los requerimientos o requisitos de necesita el sistema para la empresa, viendo las necesidades de la empresa para consigo misma y para sus clientes. En conclusión los requerimientos que se llegaron como acuerdo son los siguientes: 47 El sistema contendrá la información de cada producto como requisito mínimo: Nombre, Número de Serie, Modelo, Marca, Tipo de Producto, Cantidad de Stock, Descripción del producto, etc. Con respecto a los reportes y consultas solicitados por la empresa serán:  Stock de producto según tipo de producto y marca.  Los productos más vendidos según tipo y marca.  Los productos menos vendidos según tipo y marca. Las consultas realizadas mediante el sistema:  Cantidad de productos comprados por tipo y marca de manera diaria y mensual.  Listado de productos vendidos de manera diaria y mensual.  Lista de productos en stock por tipo y modelo. 48 3.4 METODOLOGÍA RUP PARA EL DESARROLLO DEL SISTEMA 3.4.1 PLAN DE DESARROLLO DE SOFTWARE 3.4.1.1 ASPECTOS GENERALES DEL PROYECTO A. PROPÓSITO, ALCANCE Y OBJETIVOS El propósito de este proyecto de desarrollo de software es realizar un sistema integral que permita automatizar de manera óptima y rápida el registro de entradas y salidas de los productos así como los reportes en tiempo real. El alcance del proyecto estará dirigido para las dos tiendas de ventas de la empresa, ya que es allí en donde se enfoca el problema principal de la empresa. B. SUPOSICIONES Y RESTRICCIONES Todos los datos se manejarán con total discreción, especialmente los modelos de los productos y los proveedores, ya que la empresa cuenta con productos novedosos y con proveedores con las que se tienen convenios y porque existe una alta competencia en este rubro. 49 3.4.1.2 ORGANIZACIÓN DEL PROYECTO A. PARTICIPANTES DEL PROYECTO El proyecto propuesto es elaborado únicamente por mi persona, desempeñando los cargos de jefe de proyecto, analista, diseñador y programador. B. INTERFACES EXTERNAS El área de Informática y Soporte Técnico esta enlazada principalmente con el área de Ventas y ésta tiene como cabeza a la Administración y Gerencia de la empresa, ellos son quienes nos proporcionarán los requisitos del sistema, conjuntamente con el área de Ventas. C. ROLES Y RESPONSABILIDADES A continuación se describen las principales responsabilidades de cada uno de los cargos de acuerdo con la metodología RUP, la cual desempeñaré siendo el único participante del proyecto. CARGO RESPONSABILIDAD Jefe del Proyecto El jefe del proyecto asigna los recursos, 50 gestiona las prioridades, coordina las interacciones con los usuarios y mantiene al equipo del proyecto enfocado en los objetivos. Además se encargará de supervisar el estabelecimiento de la arquitectura planificación del y sistema, control del proyecto. Analista Se encargará de capturar, especificar y organizar de forma clara los requisitos. Diseñador Se encargará en la elaboración de las pruebas funcionales y el modelo de datos. Construcción de prototipos de interfaces de usuario. Programador Se encarga de la codificación, elaboración de las pruebas funcionales, modelo de datos y en 51 las validaciones con el usuario. Elabora modelos de implementación y despliegue. Tabla 04: Roles y responsabilidades Fuente: Propia 3.4.1.3 GESTIÓN DE PROYECTO A. PLAN DEL PROYECTO  CONSTRUCCIÓN DEL DESGLOSE DEL TRABAJO Según la metodología RUP, el desarrollo se lleva a cabo en base a fases (inicio, elaboración, construcción y transición) con una o más iteraciones en cada una de ellas. Para este proyecto debido al poco tiempo establecido, se llevo a cabo las fases de inicio, elaboración y construcción a lo largo de una sola iteración. (Véase anexo 1)  ESTIMACIÓN DE LOS TIEMPOS ESPERADOS (Véase anexo 2)  DIAGRAMA DE GANTT (Véase anexo 3) 52 3.4.2 REQUISITOS 3.4.3.1 VISIÓN A. POSICIONAMIENTO  OPORTUNIDAD DE NEGOCIO Este sistema permitirá automatizar de forma más efectiva las entradas y salidas de toda la mercadería de la empresa, la cual supondrá un acceso rápido y sencillo a la información de stock de los productos, también mejorará en el servicio al cliente con un mejor presentación en la facturación y con los datos accedidos nos permitirá obtener los reportes deseados de los productos para la toma de decisiones en la Gerencia.  SENTENCIA QUE DEFINE EL PROBLEMA El problema de: No contar con óptimo sistema de control, que no permite tener los reportes de stock de los productos de manera oportuna. 53 concisa y Afecta a: Gerencia, Administración y al área de Ventas. El impacto asociado es: Al buen servicio de nuestros clientes y a las relaciones de nuestros proveedores y empresas asociadas. Una solución adecuada Crear un sistema integral sería: de inventario que agilice los reportes requeridos y un servicio rápido y eficaz para la facturación. Tabla 05: Definición del problema Fuente: Propia  SENTENCIA QUE DEFINE LA POSICIÓN DEL PRODUCTO Para Asistentes de Ventas Quienes Realizan el registro de entradas y salidas de 54 mercadería y la facturación en la compra y venta de productos. El producto Es una herramienta de software Que Almacena la información necesaria para la elaboración de los reportes y consultas. Desfasa Al sistema no óptimo con la que cuentan. Nuestro producto Permite realizar el registro de los productos mediante una interfaz amigable y sencilla que además proporciona una acceso rápido y actualizado a la información desde la base de datos. Tabla 06: Posición del producto Fuente: Propia 55 B. DESCRIPCIÓN DE USUARIOS  RESUMEN DE LOS USUARIOS NOMBRE DESCRIPCIÓN Jefe de Ventas Encargada de registrar los ingresos y salidas de los productos y emitir los reportes estadísticos para la Gerencia y Administración. Asistentes de Ventas Se encarga de registrar los ingresos y salidas de los productos mediante el sistema de facturación. Jefe Ventas Corporativas Realiza las consultas y reportes necesarios de los productos. Jefe de Informática y Se encargará de dar soporte al Soporte Técnico sistema en caso falle o si se solicite de requerimiento. Tabla 07: Resumen de usuarios Fuente: Propia 56 algún C. DESCRIPCIÓN GLOBAL DEL PRODUCTO El sistema integral de inventario permitirá que el usuario pueda registrar con gran facilidad cada uno de los productos que ingresan y salen de la empresa, mediante la compra y venta que se realicen, el cual permitirá un mejor control de toda la mercadería a través de un sistema de facturación. Con esto se permitirá tener los reportes estadísticos, consulta de productos y listados de stock de los productos, con la finalidad de poder realizar una correcta toma de decisiones. 3.4.3 MODELO DE CASOS DE USO (Véase Anexo 4) 3.4.4 ESPECIFICACIONES DE CASOS DE USO (Véase Anexo 5) 3.5 ANÁLISIS Y DISEÑO 3.5.1 MODELO DE ANÁLISIS/DISEÑO 3.5.1.1 DIAGRAMA DE CLASES (Véase anexo 6) 57 3.5.2 DISEÑO DE LA BASE DE DATOS (Véase anexo 7) 3.5.3 MODELO DE IMPLEMENTACIÓN 3.5.3.1 DIAGRAMA GLOBAL DE PAQUETES (Véase anexo 8) 3.5.3.2 DIAGRAMA DE COMPONENTES (Véase anexo 9) 3.5.3.3 DIAGRAMA DE DESPLIEGUE (Véase anexo 10) 3.5.3.4 DIAGRAMA DE ACTIVIDADES (Véase anexo 12) 3.5.3.5 DIAGRAMA DE ESTADOS (Véase anexo 13) 58 IV. RESULTADOS DE LAS PRÁCTICAS REALIZADAS 4.1 IMPLEMENTACIÓN 4.1.1 PROTOTIPOS DE INTERFAZ DE USUARIO Figura 04: Interfaz principal del sistema Fuente: Propia  Prototipo de la interfaz principal del sistema, en la cual se pueden apreciar las opciones y las diferentes herramientas, principalmente las ventas y compras de un producto. 59 Figura 05: Menú Archivo Fuente: Propia  Se observa las sub opciones que contiene la opción Archivo del menú principal.  A continuación también se mostrarán las sub opciones de las demás opciones del menú principal y del menú herramientas. 60 Figura 06: Opciones Menú Ver Fuente: Propia Figura 07: Menú Herramientas Fuente: Propia 61 Figura 08: Opciones de compra Fuente: Propia Figura 09: Opción de Productos Fuente: Propia 62 Figura 10: Opción de Ventas Fuente: Propia Figura 11: Formulario de Logotipo Fuente: Propia 63 Figura 12: Formulario Diagnóstico de Problemas Fuente: Propia  Tenemos una opción extra el cual nos permitirá mostrar un diagnóstico de problemas acerca de la conexión del sistema con el servidor, un tema principal para anticipar cualquier inconveniente para la facturación o emisión de reportes. 64 V. CONCLUSIONES Y RECOMENDACIONES 5.1 CONCLUSIONES 5.1.1 CONCLUSIONES DE LAS PRÁCTICAS PRE PROFESIONALES  Mientras se desarrollo las prácticas se aplicó lo aprendido en la Universidad durante la formación académica para brindar soluciones a problemas reales.  Se consiguió obtener experiencia con respecto al campo profesional y conseguir así un mejor desenvolvimiento en la misma empresa o ya sea en cualquier otra empresa.  Se cumplieron todas las tareas encomendadas por la empresa con mucha eficiencia y responsabilidad. 5.1.2 CONCLUSIONES DEL PROYECTO  Se desarrollo satisfactoriamente el sistema integral de inventario para un mejor control de mercadería de la empresa, incluyendo un sistema de facturación que ayude a una mejor y rápida atención al cliente.  Se logró tener un mejor proceso en lo reportes diarios en tiempo real, para una mejor toma de decisiones. 65 5.2 RECOMENDACIONES 5.2.1 RECOMENDACIONES DE LAS PRÁCTICAS PRE PROFESIONALES  Se recomienda que la Universidad tenga convenios con empresas para que puedan mandar a sus egresados a realizar prácticas preprofesionales y así obtener más experiencia en el campo laboral.  Recibir clases de especialización para el área en donde se encuentre haciendo las prácticas para que de esta manera puedan realizar sus funciones con eficiencia y responsabilidad. 5.2.2 RECOMENDACIONES DEL PROYECTO  Se recomienda que todos los trabajadores de la empresa manipulen y conozcan de forma detallada cada función del sistema, para que haya un buen servicio hacia los clientes y hacia la Administración y Gerencia.  Estar siempre actualizado con los conocimientos de los productos de tecnología de punta e indicar los reportes si en caso haya un cambio radical y dar conocimiento a la Administración y Gerencia para una correcta toma de decisiones. 66 VI. BIBLIOGRAFÍA [1] Jacobson, Ivar, Booch, Gray, Rumbaugh James; “El proceso unificado de desarrollo de software”; 2000; Primera Edición; Editorial Addison Wesley; España pp. 1-12 [2] Pressman Roger, “Ingeniería de Software: Un enfoque práctico”; 2002; 5ta Edición; Mc Graw-Hill/Interamericana; España; pp. 21, 25, 166, 132, 234-325, 524-526, 499 [3] Senn, James A.; “Análisis y diseño de sistemas de información”; 2002; Segunda Edición; Mc Graw Hill; México; Cap. I: Introducción al desarrollo de sistemas de información, pp. 25 [4] Castaño, Adoración de Miguel, Piattini Velthuis, Mario Gerardo; “Concepción y diseño de base de datos”; 1993; Editorial RA-MA; Madrid-España; pp. 46 [5] Ramírez González, Laboratorio III de Electrónica, Anotaciones RUP, 2001 [6] Kruchten, Philipe; “Proceso Unificado Rational: Una introducción”; 2001; Tercer Edición; Editorial Adisson Wesley; Boston-USA; pp. 86 [7] López Rodríguez, César; “Ejemplo de desarrollo de software utilizando la metodología RUP”; Universidad Politécnica de Valencia. Disponible en: http://www.disc.upv.es/asignaturas/facultad/lsi/ejemplorup.html. [8] Kroll Per; Kruchten, Philippe; “The Rational Unified Process Made Easy: A Practitioner`s guide to the RUP”; 2003; Primera Edición; Editorial AddisonWesley, Boston, USA. [9] Modelado de Sistemas con UML; Disponible en: Es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-modelado-sistemasuml.pdf [10] Schmuller, Joseph; “Aprendiendo UML en 24 horas”; 2001; Primera Edición; Editorial Pearson Educación Latinoamérica; México. 67 [11] Korth, Henry F., Silberschatz, Abraham; “Fundamentos de Base de Datos”; 1993; Segunda Edición; Editorial Mc Graw Hill; México. [12] Sommerville, Ian; Ingeniería de software; 2002; 6ta Edición; Editorial Pearson Educación; México; Pág.5-6 [13] Bertino Elisa y Martino Lorenzo; “Sistemas de Bases de Datos Orientadas a Objetos”; 1995; Segunda Edición; Editorial Díaz de Santos, España. [14] Kroenke, David; “Procesamiento de Bases de Datos: Fundamentos, Diseño e Implementación”; 2003; Octava Edición; Editorial Pearson Educación; México. [15] Fowler, Martin; “UML Distilled: A Brief Guide to the Standard Object Modeling Language”; 2004; Tercera Edición; Editorial Addison - Wesley; Boston. 68 VII. ANEXOS 7.1 ANEXO 1: ESTRUCTURA DEL DESGLOSE DEL TRABAJO (EDT) Figura 13: Diagrama de desglose Fuente: Propia 69 7.2 ANEXO 2: ESTIMACIÓN DE TIEMPOS ESPERADOS Figura 14: Estimación de tiempos esperados Fuente: Propia 70 7.3 ANEXO 3: DIAGRAMA DE GANTT Figura 15: Diagrama Gantt Fuente: Propia 71 7.4 ANEXO 4: MODELOS DE CASOS DE USO Registrar Salida de Mercadería Registrar Ventas Cliente Vendedor Emitir Comprobante de Pago Figura 16: Caso de Uso Registrar Ventas Fuente: Propia Registrar Ingreso de Mercadería Vendedor Proveedor Registrar Compras Recibir Comprobante de Pago Figura 17: Caso de Uso Registrar Compras Fuente: Propia Vendedor Emitir Reportes Solicitados Admnistrador Figura 18: Caso de Uso Emitir Reportes Solicitados Fuente: Propia 72 7.5 ANEXO 5: ESPECIFICACIONES DE CASOS DE USO CU-001 Registrar Ventas Actores - Vendedor (Asistente de Ventas) - Cliente Descripción Flujo de Eventos Flujo Básico Flujo Alternativo El caso de uso inicia cuando el cliente desea realizar una compra y por ende el asistente imprime el comprobante de pago mediante el sistema y registra la salida de mercadería. 1. El asistente ingresa al sistema con su nombre de usuario y código. 2. El asistente ingresa los datos del cliente y datos del producto. 3. Si los datos ingresados no existen, entonces se registrarán automáticamente. 4. Se da click en aceptar dando la conformidad al comprobante. 5. Se manda a imprimir el comprobante de pago. 2. Si ya existe los datos del cliente se va al paso 4. Precondiciones Verificar que el sistema este abierto y con la conexión óptima al servidor. Pos condiciones Las facturas estarán impresas de manera correlativa. Requerimiento especial Tener el sistema abierto y que los productos ya estén debidamente registrados. Tabla 08: CU-001 Fuente: Propia 73 CU-002 Registrar Compras Actores - Vendedor (Asistente de Ventas) - Proveedor Descripción Flujo de Eventos El caso de uso inicia cuando el cliente desea realizar una compra y por ende el asistente imprime el comprobante de pago mediante el sistema y registra la salida de mercadería. Flujo Básico 1. El asistente ingresa al sistema con su nombre de usuario y código. 2. El asistente ingresa los datos del producto. 3. Si los datos ingresados no existen, entonces se registrarán automáticamente. 4. Se da click en aceptar dando la conformidad del producto ingresado. 5. Se sale del sistema. Flujo Alternativo 2. Si ya existe los datos del producto se va al paso 4. Precondiciones Verificar que el sistema este abierto y bien conectado al servidor. Pos condiciones Los registros se realizan de manera correlativa. Requerimiento especial Tener el sistema abierto y que los productos sean registrados correctamente. Tabla 09: CU-002 Fuente: Propia 74 CU-003 Emitir reportes solicitados Actores - Vendedor (Asistente de Ventas) - Administrador Descripción Flujo de Eventos Flujo Básico El caso de uso inicia cuando la administración o gerencia desea solicitar un reporte y por ende el asistente imprime el reporte o consulta solicitada. 1. El administrador solicita reportes al asistente de ventas. 2. El asistente ingresa al sistema con su nombre de usuario y código. 3. El asistente ingresa a la opción de reportes. 4. El asistente imprime los reportes solicitados por la administración o gerencia. 5. La administración junto con gerencia realiza la toma decisiones. Flujo Alternativo Precondiciones Actualizar la información ingresada para emitir reportes correctos. Pos condiciones Requerimiento especial Tabla 10: CU-003 Fuente: Propia 75 Figura 19: Diagrama de clases Fuente: Propia 76 (from Use Case View) Producto Impresora Jefe de Ventas Jefe de Ventas Coorporativas Asistente de Ventas Desktop Vendedor Laptop Cliente (from Use Case View) Proveedor (from Use Case View) Otros Factura Tipo de Comprobante Boleta 7.6 ANEXO 6: DIAGRAMA DE CLASES TypeOfDocument IDTypeOfDocument TypeOfProduct Supplier IDSupplier AssociatedMark Mark IDTypeOfProduct IDAssociatedMark IDMark Deleted Name fkMark (FK) fkTypeOfProduct (FK) Deleted Name 77 Figura 20: Diseño de la Base de Datos Fuente: Propia Address Cellphone Deleted Fax Email Name Telephone Product Client IDClient Address Cellphone Deleted Email Fax Name Telephone fkTypeOfDocument (FK) IDProduct Deleted Name Stock fkMark (FK) fkTypeOfProduct (FK) Shop Serie Sale IDSerie IDSale Date LastMinorNumber MainNumber fkTypeOfVoucher (FK) Date DocumentNumber fkClient (FK) fkTypeOfVoucher (FK) fkSerie (FK) IDShop Date DocumentNumber fkSupplier (FK) fkTypeOfVoucher (FK) SaleDetail IDSaleDetail IDSale (FK) ShopDetail IDShopDetail IDShop (FK) AccountPayable IDAccountPayable Quantity SubtotalPrice UnitPrice fkProduct (FK) Quantity SubtotalCost UnitCost fkProduct (FK) Amortization Amount Residue fkShop (FK) TypeOfVoucher IDTypeOfVoucher Name AccountReceivable IDAccountReceivable Amortization Amount Residue fkSale (FK) 7.7 ANEXO 7: DISEÑO DE LA BASE DE DATOS Name 7.8 ANEXO 8: DICCIONARIO DE DATOS Entidad Supplier (Proveedor): Atributo Dominio Descripción IDSupplier Cadena de caracteres = [A … Z / a … z / 0-9/ ], Código que se obtiene considera válidos las letras mayúsculas, cuando se registra un minúsculas y números = 8 caracteres nuevo proveedor. Address Cadena de caracteres = [A … Z / a … z / 0-9/ ], Dirección del considera válidos las letras mayúsculas, proveedor minúsculas y números = 50 caracteres registrado. Cellphone Cadena de caracteres = [A … Z / a … z / 0-9/ ], Número de celular del considera válidos las letras mayúsculas, proveedor. minúsculas y números = 30 caracteres Permite eliminar un proveedor del sistema pero no de la base de datos. Deleted Booleano Fax Cadena de caracteres = [A … Z / a … z / 0-9/ ], Número de fax del considera válidos las letras mayúsculas, proveedor. minúsculas y números = 30 caracteres Email Cadena de caracteres = [A … Z / a … z / 0-9/ ], Dirección electrónica considera válidos las letras mayúsculas, del minúsculas y números = 50 caracteres proveedor. Name Cadena de caracteres = [A … Z / a … z / 0-9/ ], Nombre o razón social considera válidos las letras mayúsculas, del proveedor. minúsculas y números = 50 caracteres Telephone Cadena de caracteres = [A … Z / a … z / 0-9/ ], Número fijo del considera válidos las letras mayúsculas, proveedor. minúsculas y números = 30 caracteres 78 Entidad Shop (Tienda): Atributo Dominio Descripción IDShop Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Código que se obtiene cuando se registra una nueva tienda. Date Fecha = *formato: dd/mm/aaaa* Fecha de registro de la nueva tienda. DocumentNumber Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres fkSupplier Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave foránea que viene de la tabla Proveedor. FkTypeOf Voucher Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave foránea que viene de la tabla Tipo de Comprobante. Entidad Product (Producto): Atributo IDProduct Deleted Dominio Descripción Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Código que se registra cuando se ingresa un nuevo producto. Booleano Permite eliminar un producto del sistema pero no de la base de datos. 79 Name Stock Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 50 caracteres Cadena de caracteres = [0-9], se considera válidos los números enteros Nombre que identifica el producto. Cantidad disponible del producto en el negocio. fkMark Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave foránea que viene de la tabla Marca. FkTypeOf Product Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave foránea que viene de la tabla Tipo de Producto. Entidad Sale (Venta): Atributo Dominio Descripción IDSale Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Código que se registra al realizar una nueva venta. Date Fecha = *formato: dd/mm/aaaa* Fecha de registro de la nueva venta. Document Number Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres fkClient Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave foránea que viene de la tabla Cliente. fkTypeOf Voucher Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave foránea que viene de la tabla Tipo de Comprobante. fkSerie Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave foránea que viene de la tabla Serie. 80 Entidad Client (Cliente): Atributo Dominio Descripción IDClient Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Código que se registra cuando se ingresa un nuevo cliente. Address Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 50 caracteres Dirección de domicilio o domicilio fiscal del cliente. Cellphone Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 30 caracteres Número de celular del cliente. Deleted Booleano Permite eliminar un cliente del sistema pero no de la base de datos. Fax Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 30 caracteres Número de fax del cliente. Email Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 50 caracteres Dirección electrónica del cliente. Name Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 50 caracteres Nombre o razón social del cliente. Telephone Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 30 caracteres Número fijo del cliente. fkTypeOf Document Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave foránea que viene de la tabla Tipo de Documento. 81 Entidad Mark (Mark): Atributo Dominio Descripción Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Código que se registra cuando se ingresa una nueva marca. Deleted Booleano Permite eliminar una marca del sistema pero no de la base de datos. Name Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 50 caracteres Nombre de la marca registrada. IDMark Entidad AccountPayable (Cuenta por pagar): Atributo Dominio Descripción IDAccount Payable Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Código que se registra cuando se ingresa una compra al crédito. Amortization Cadena de caracteres = [0-9/ ], considera válidos los número decimales Cantidad parcial por la cancelación de la compra al crédito. Amount Cadena de caracteres = [0-9/ ], considera válidos los número decimales Cantidad del precio de la compra. Residue Cadena de caracteres = [0-9/ ], considera válidos los número decimales Diferencia del precio de compra con las amortizaciones pagadas. fkShop Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave foránea que viene de la tabla Tienda. 82 Entidad AccountReceivable (Cuenta por cobrar): Atributo Dominio Descripción IDAccount Receivable Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Código que se registra cuando se ingresa una venta al crédito. Amortization Cadena de caracteres = [0-9/ ], considera válidos los número decimales Cantidad parcial por la cancelación de la venta al crédito. Amount Cadena de caracteres = [0-9/ ], considera válidos los número decimales Cantidad del precio de la venta. Residue Cadena de caracteres = [0-9/ ], considera válidos los número decimales Diferencia del precio de venta con las amortizaciones pagadas. fkSale Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave foránea que viene de la tabla Venta. Entidad Serie (Serie): Atributo Dominio Descripción IDSerie Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Código que se registra cuando se ingresa una nueva serie del producto. Date Fecha = *formato: dd/mm/aaaa* Fecha del registro de la nueva serie. LastMinor Number Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 30 caracteres Main Number Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 30 caracteres 83 fkTypeOf Voucher Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave foránea que viene de la tabla Tipo de Comprobante. Entidad TypeOfVoucher (Tipo de Comprobante): Atributo Dominio Descripción IDTypeOf Voucher Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Código que se representa al tipo de comprobante de pago. Name Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 50 caracteres Nombre del comprobante de pago. Entidad TypeOfProduct (Tipo de Producto): Atributo Dominio Descripción Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Código que se registra cuando se ingresa un nuevo tipo de producto. Deleted Booleano Permite eliminar un tipo de producto del sistema pero no de la base de datos. Name Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 50 caracteres Nombre del tipo de producto. IDTypeOf Product 84 Entidad TypeOfDocument (Tipo de Documento): Atributo IDTypeOf Document Name Dominio Descripción Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Código que se registra cuando se ingresa un nuevo tipo de documento. Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 50 caracteres Nombre del tipo de documento. Entidad ShopDetail (Detalle de Tienda): Atributo Dominio Descripción IDShop Detail Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Código que representa el detalle de tienda. IDShop Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave que viene de la tabla Tienda. Quantity Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Cantidad que representa el número de productos. Subtotal Cost Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Indica el valor de venta o compra realizada. UnitCost Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Costo unitario del producto. fkProduct Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave foránea que viene de la tabla Producto. 85 Entidad SaleDetail (Detalle de Venta): Atributo Dominio Descripción IDSale Detail Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Código que representa el detalle de la venta. IDSale Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave foránea que viene de la tabla Venta. Quantity Cadena de caracteres = [0-9/ ], considera válidos los número decimales Cantidad que representa el número de productos. Subtotal Price Cadena de caracteres = [0-9/ ], considera válidos los número decimales Indica el valor de venta o compra realizada. UnitPrice Cadena de caracteres = [0-9/ ], considera válidos los número decimales Costo unitario del producto. fkProduct Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave foránea que viene de la tabla Producto. Entidad AssociatedMark (Marca Asociada): Atributo Dominio Descripción Cadena de caracteres = [A … Z / a … z / 0-9/ ], IDAssociatedMark considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Código que representa la marca asociada. fkMark Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave foránea que viene de tabla Marca. fkTypeOf Product Cadena de caracteres = [A … Z / a … z / 0-9/ ], considera válidos las letras mayúsculas, minúsculas y números = 8 caracteres Clave foránea que viene de tabla Tipo de Producto. Tabla 11: Diccionario de datos Fuente: Propia 86 7.9 ANEXO 9: DIAGRAMA GLOBAL DE PAQUETES Sub Sistema Integral de Inventario Sub Sistema de Facturación Figura 21: Diagrama de Paquetes Fuente: Propia 87 7.10 ANEXO 10: DIAGRAMA DE COMPONENTES Apicación Sistema de Inventario Login.frm Control y Análisis Negocio. vb Acceso a Base de Datos Datos.vb Figura 22: Diagrama de Componentes Fuente: Propia 88 7.11 ANEXO 11: DIAGRAMA DE DESPLIEGUE Pc Cliente/Servidor Impresora TCP/IP TCP/IP TCP/IP Pc Cliente (Tienda 02) Pc Cliente (Tienda 01) Figura 23: Diagrama de Despliegue Fuente: Propia 89 7.12 ANEXO 12: DIAGRAMA DE ACTIVIDADES Ingresa al sistema con nombre de usuario y código Verifica usuario y código Solicita datos del cliente Otorga sus datos Verifica si ya está registrado Registra los datos como nuevo cliente Existe No Si Se almacena la venta en la base de datos Emite el comprobante de pago Recibe comprobante de pago Figura 24: Diagrama de Actividades – Registras Ventas Fuente: Propia 90 Ingresa el sistema con nombre de usuario y código Verifica usuario y código Otorga sus datos al asistente Solicita datos el proveedor Verifica si ya está registrado Registra los datos como nuevo proveedor Se encuentra en el sistema Si No Se almacena la compra en la base de datos Nos otorga comprobante de pago Se da la coformidad del producto Figura 25: Diagrama de Actividades – Registrar Compras Fuente: Propia Ingresa al sistema con nombre de usuario y código Solicita reportes Verifica datos del asistente Registra reporte para la toma de decisiones Busca los reportes solicitados Emite reportes solicitados Figura 26: Diagrama de Actividades – Emitir Reportes Fuente: Propia 91 7.13 ANEXO 13: DIAGRAMA DE ESTADOS Esperando la Compra Se entrega el producto Respuesta Sale el producto Se termina la compra Pago en efectivo Autorización de pago Pago con tarjeta Esperando el pago Figura 27: Diagrama de Estados – Registrar Ventas Fuente: Propia 92 Se entrega el producto Esperando la Compra Sale el producto Se termina la compra Respuesta Pago en efectivo Esperando el pago Autorización de pago Pago con tarjeta Figura 28: Diagrama de Estados – Registrar Compras Fuente: Propia Selección del tipo de producto Se filtra Se filtra Selección del producto Selección del periodo Se manda el reporte Se manda el reporte Esperando autorización Respuesta Figura 29: Diagrama de Estados – Emitir Reportes Fuente: Propia 93