Desarrollo de un software para la gestión de cadenas de tiendas de ropa

Trabajo Fin de Grado Escuela de Ingeniería Informática Universidad de Las Palmas de Gran Canaria Desarrollo de un software para la gestión de cadenas de tiendas de ropa Oliver Grisha Lorenzo Felipe Las Palmas de Gran Canaria Diciembre 2013 Trabajo Fin de Grado realizado en la Escuela de Ingeniería Informática de la Universidad de Las Palmas de Gran Canaria, para la consecución del título de Ingeniero Informático. Título: Desarrollo de un software para la gestión de cadenas de tiendas de ropa Alumno: Oliver Grisha Lorenzo Felipe Tutor: Javier Sánchez Pérez Fecha: Diciembre del 2013 A todos los que me han apoyado estos años y han hecho posible la realización de este trabajo. En especial, mi familia. Agradecimientos Antes de continuar con el presente documento me gustaría dar las gracias a todas aquellas personas que han hecho posible y me han apoyado durante y tras la realización de este trabajo. En primer lugar dar las gracias a mi tutor, Javier Sánchez Pérez, por su apoyo y dedicación. Agradezco todos sus consejos y ayudas que han hecho posible este trabajo que ha sido todo un reto para mí. También agradecer a mis compañeros, que siempre han estado ahí para darme fuerzas y atender cualquier duda que me haya podido surgir. A mis padres, y resto de familiares, que en todo momento me han brindado su apoyo incondicional. A todos, muchas gracias. Índice general ÍNDICE GENERAL Prefacio ................................................................................................................................... iii 1 Introducción ...................................................................................................................... 1 1.1 ¿Qué es un ERP? ........................................................................................................ 1 1.2 ¿Qué es un software de gestión? .............................................................................. 3 1.3 ERP VS software de gestión ....................................................................................... 4 1.4 Motivación y objetivos .............................................................................................. 5 1.5 Organización del documento .................................................................................... 6 2 Estado actual del arte ........................................................................................................ 7 2.1 Software libre ............................................................................................................ 7 2.1.1 OPENERP ........................................................................................................... 8 2.1.2 Openbravo ERP .................................................................................................. 9 2.2 Software comercial ................................................................................................. 11 2.2.1 Microsoft Dynamic CRM.................................................................................. 11 2.2.2 SAP ................................................................................................................... 13 2.2.3 Software de gestión comercial Verial ............................................................. 15 2.2.4 OTROS .............................................................................................................. 16 3 Recursos utilizados .......................................................................................................... 17 3.1 Recursos software ................................................................................................... 17 3.1.1 Base de datos .................................................................................................. 17 3.1.2 Plataforma Java ............................................................................................... 18 3.1.3 NetBeans ......................................................................................................... 18 3.1.4 JavaFX Scene Builder ....................................................................................... 19 3.1.5 StarUML ........................................................................................................... 19 3.1.6 Microsoft Word ............................................................................................... 20 3.2 Recursos hardware .................................................................................................. 21 3.2.1 Portátil ............................................................................................................. 21 3.2.2 Escáner de código de barras ........................................................................... 21 3.2.3 Impresora térmica ........................................................................................... 22 3.2.4 Cajón de dinero ............................................................................................... 23 3.2.5 Impresora ........................................................................................................ 24 4 Planificación del trabajo .................................................................................................. 25 1. Introducción 2 Modulares. Los ERP entienden que una empresa es un conjunto de departamentos que se encuentran interrelacionados por la información que comparten y que se genera a partir de sus procesos. Una ventaja de los ERP, tanto económica como técnica es que la funcionalidad se encuentra dividida en módulos, los cuales pueden instalarse de acuerdo con los requerimientos del cliente. Ejemplo: ventas, materiales, finanzas, control de almacén, recursos humanos, etc. Configurables. Los ERP pueden ser configurados mediante desarrollos en el código del software. Por ejemplo, para controlar inventarios, es posible que una empresa necesite manejar la partición de lotes pero otra empresa no. Los ERP más avanzados suelen incorporar herramientas de programación de cuarta generación para el desarrollo rápido de nuevos procesos. Otras características destacables de los sistemas ERP son: - Base de datos centralizada. - Los componentes del ERP interactúan entre sí consolidando las operaciones. - En un sistema ERP los datos se capturan y deben ser consistentes, completos y comunes. - Las empresas que lo implanten suelen tener que modificar alguno de sus procesos para alinearlos con los del sistema ERP. Este proceso se conoce como Reingeniería de Procesos, aunque no siempre es necesario. Los beneficios que puede aportar una herramienta de ERP se resume en la resolución de los problemas contables, mercantil o fiscal de la empresa. Asimismo, puede permitir un mayor control contable, inmovilizado, conciliación bancaria, liquidación de impuestos, etc. Una empresa que no cuente con un sistema ERP, en función de sus necesidades, puede encontrarse con muchas aplicaciones de software cerradas, que no se pueden personalizar, y no se optimizan para su negocio. Diseño de ingeniería para mejorar el producto, seguimiento del cliente desde la aceptación hasta la satisfacción completa, una compleja administración de interdependencias de los recibos de materiales, de los productos estructurados en el mundo real, de los cambios de la ingeniería y de la revisión y la mejora, y la necesidad de elaborar materiales substitutos, etc. La ventaja de tener un ERP es que todo esto, y más, están integrados. Las limitaciones y obstáculos del ERP incluyen: - El éxito depende en las habilidades y la experiencia de la fuerza de trabajo, incluyendo la educación y cómo hacer que el sistema trabaje correctamente. Muchas compañías reducen costos reduciendo entrenamientos. Los propietarios de pequeñas empresas están menos capacitados, lo que significa que el manejo del sistema ERP es operado por personal que no está capacitado para el manejo del mismo. - Cambio de personal, las compañías pueden emplear administradores que no están capacitados para el manejo del sistema ERP de la compañía empleadora, proponiendo cambios en las prácticas de los negocios que no están sincronizados con el sistema. - La instalación del sistema ERP es muy costosa. - Los vendedores del ERP pueden cargar sumas de dinero para la renovación de sus licencias anuales, que no está relacionado con el tamaño del ERP de la compañía o sus ganancias. 1. Introducción 3 - El personal de soporte técnico en ocasiones contesta a las llamadas inapropiadas de la estructura corporativa. - Los ERP son vistos como sistemas muy rígidos, y difíciles de adaptarse al flujo específico de los trabajadores y el proceso de negocios de algunas compañías, este punto se cita como una de las principales causas de falla. - Los sistemas pueden ser difíciles de usarse. - Los sistemas pueden sufrir problemas de "cuello de botella": la ineficiencia en uno de los departamentos o en uno de los empleados puede afectar a otros participantes. - Muchos de los eslabones integrados necesitan exactitud en otras aplicaciones para trabajar efectivamente. Una compañía puede lograr estándares mínimos, y luego de un tiempo los "datos sucios" (datos inexactos o no verificados) reducirán la confiabilidad de algunas aplicaciones. - Una vez que el sistema esté establecido, los costos de los cambios son muy altos (reduciendo la flexibilidad y las estrategias de control). - La mala imagen de unión de la compañía puede causar problemas en su contabilidad, la moral de sus empleados y las líneas de responsabilidad. - La resistencia en compartir la información interna entre departamentos puede reducir la eficiencia del software. - Hay problemas frecuentes de compatibilidad con algunos de los sistemas legales de los socios. - Los sistemas pueden tener excesiva ingeniería respecto a las necesidades reales del consumidor. 1.2 ¿QUÉ ES UN SOFTWARE DE GESTIÓN? Un software de gestión empresarial es un programa que está dedicado a una o unas pocas actividades o procesos en la empresa (a diferencia de los ERP que son integrales). Los beneficios beneficio de dichos programas (o también denominados “suite”) son: - Que son más económicos que los ERP. - Al abarcar menos procesos que los ERP por norma general suelen ser más sencillos. - Intentan abarcar exclusivamente lo que el usuario necesita. Las limitaciones y obstáculos de dichos suites son: - Suelen pecar de sencillez, no abarcando opciones requeridas por sus clientes y quedándose escasos en cuanto a funcionalidad. - Bases de datos descentralizadas o de ficheros independientes (sin motor de base de datos). - Al trabajar una misma empresa con distintos suites (contabilidad, administración, almacenaje, etc.) y estar ambos departamentos relacionados suele haber duplicidad de datos y a consecuencia inconsistencias en el sistema. 1. Introducción 4 1.3 ERP VS SOFTWARE DE GESTIÓN La clasificación de un determinado software de gestión como ERP determina que disponga de una serie de requisitos y funcionalidades que posibiliten su diferenciación. En el mercado del software de hoy en día es habitual que cualquier suite de gestión pretenda un mayor reconocimiento (por lo general irreal, dado que es igualmente necesario un software de gestión normal que un ERP, sólo que para niveles diferentes) por el hecho de ser conocida como ERP en lugar de como software de gestión. Así podemos ver como estrategias de marketing que determinados programas de gestión que llevan en el mercado varios años, cambian bruscamente su denominación a ERP, buscando un nicho de trabajo superior (por lo general acompañado de una mayor remuneración, reconocimiento, etc.) sin incrementar proporcionalmente la funcionalidad. La principal diferencia estriba en la definición. Un ERP es una aplicación que integra en un único sistema todos los procesos de negocio de una empresa. Adicionalmente se pretende que todos los datos estén disponibles todo el tiempo para todo el mundo en la empresa (obviando por el momento permisos sobre disponibilidad, etc.) de una manera centralizada. Esto descarta como ERP aquellos programas basados en múltiples aplicaciones (denominados comúnmente suites) independientes o modulares que duplican la información (aun cuando la enlacen automáticamente) o no la centralizan en una única base de datos. También elimina aquellos programas que se basan en sistemas de base de datos de ficheros independientes (sin motor de base de datos). Por otra parte la definición tradicional nos dice que los ERP están diseñados para modelar y automatizar todos los procesos básicos con el objetivo de integrar información a través de la empresa, eliminando complejas conexiones entre sistemas distintos. Un ERP es una arquitectura de software que facilita el flujo de información entre las funciones de manufactura, logística, finanzas y recursos humanos de una empresa. Así que a la característica de la base de datos centralizada y de que los componentes del ERP interactúen entre sí, consolidando todas las operaciones, se debe añadir que en un sistema ERP los datos se introducen una sola vez, debiendo mantener la consistencia, y ser completos. Como característica colateral se puede añadir que, normalmente, las empresas deben de modificar algunos de sus procesos para alinearlos con los del sistema ERP. Es lo que se conoce como Reingeniería de Procesos. Estas características básica debieran permitir diferenciar básicamente entre una suite de gestión (habitualmente compuesta de programas o módulos de facturación y contabilidad) y un ERP puro que debiera incluir todas aquellas funcionalidades que una empresa pueda necesitar (gestión de proyectos, gestión de campañas, comercio electrónico, producción por fases, trazabilidad, gestión de la calidad, gestión de cajas descentralizadas o centralizadas (TPVs), pasarelas de pago electrónico, gestión de la cadena de abastecimiento, logística, etc.) integradas y enlazadas entre sí. No basta con tener algunas de esas funcionalidades. Realmente es necesario tener todas, aun cuando no siempre las empresas las necesiten en este momento. Pero deben de estar disponibles internamente para suplir las necesidades futuras. 1. Introducción 5 El saber si una empresa necesita o no un ERP o una simple suite de gestión es otro asunto, no obstante la definición y características de un ERP debieran quedar claros. Así por ejemplo la gestión correcta de la cadena de abastecimientos es vital para una empresa que precise de un ERP (una gran parte de los procesos de negocio dependen de la cadena de abastecimiento y su logística asociada), pero puede no serlo tanto para otra que necesite únicamente automatizar una parte de sus procesos de negocio. El que la primera debe de utilizar un ERP es claro, que a la segunda le basta una suite de gestión más simple, puede ser más discutible (en función de las necesidades reales de la empresa tras pasar por una reingeniería de procesos), lo que no es justo ni real, es denominar comercialmente ERP a la suite de gestión utilizada por la segunda empresa. En definitiva, las suites de gestión y los ERP ocupan dos nichos de mercado, claramente distinguibles desde un punto de vista técnico, pero comercial y publicitariamente cruzables desde abajo hacia arriba. Esto último es lo que hace que muchas empresas medianas o grandes, se enfrenten con graves problemas de gestión al implementar un software que creían ERP y que deja fuera de sus necesidades, bien sean actuales o futuras, muchos de los procesos de negocio básicos que la empresa usa o que ha pasado a usar con el devenir del tiempo. 1.4 MOTIVACIÓN Y OBJETIVOS Cada empresa tiene una forma de trabajar única y no hay dos iguales, aunque se dediquen al mismo sector de actividad. Las empresas requieren una solución de gestión de negocio adaptable a su modo de trabajar, sin embargo y como hemos visto con anterioridad, los tipos de software existente en el mercado suelen ofrecer soluciones genéricas, que no abarcan todas las necesidades reales de una empresa de manera sencilla e intuitiva, y por tanto, obligan a la empresa a adaptarse al software, rompiendo de este modo su lógica de negocio, y dificultando así el proceso de implantación. Es por ello, por lo que se decidió el desarrollar un software de gestión a medida para la empresa Galerías Lorens. Dicha empresa se dedica a la venta minorista de productos textiles y cuenta actualmente con varias sucursales en distintas islas canarias (Gran Canaria, Fuerteventura y Tenerife) y de un almacén central en Gran Canaria. Los objetivos de este software a medida son: - Adaptarse a las necesidades empresariales específicas para la empresa Galerías Lorens. - Que el software a desarrollar sea fácil e intuitivo de usar y no contenga instalaciones innecesarias. - Que el software se pueda cambiar y modificar con el tiempo según los cambios requeridos por el negocio. - Que el software agregue valor a la empresa, sugiriendo alternativas útiles y actuando como una fuente útil de asesoramiento e información. Además, en el ámbito académico dicho trabajo me permitirá demostrar todo lo aprendido a lo largo de la carrera de Grado de Ingeniería Informática. Así como la oportunidad de familiarizarme con tecnologías que desconocía hasta el momento. 1. Introducción 6 Unos ejemplos de ellos son: - La utilización de JavaFX para las interfaces gráficas. - El uso de un ORM como Hibernate para las conexiones entre la aplicación y la base de datos. - El uso de código de barras EAN13 en una aplicación Java. - El uso de la impresora en una aplicación. - El manejo de material empresarial como son los cajones de efectivo, impresoras de tickets y los lectores de códigos de barras. 1.5 ORGANIZACIÓN DEL DOCUMENTO Este documento está estructurado de manera que tras dicha breve introducción continúe con el estado actual del arte. El estado actual del arte nos permitirá determinar cómo ha sido tratado el tema hasta ahora y cuáles son las tendencias. El documento continúa con la explicación de los recursos utilizados en dicho trabajo. Los recursos están clasificados en recursos software y hardware, refiriéndonos como recursos hardware a todos aquellos componentes físicos empleados y software a los programas informáticos utilizados. Luego se expondrá la planificación del trabajo, que estará compuesta por la metodología seguida, así como la temporización y el presupuesto calculado para el desarrollo del software. Siguiente a la planificación se procede al desarrollo del trabajo, donde se realiza el modelo del negocio de la empresa Galerías Lorens. El modelo de negocio nos permitirá conocer cómo funciona la empresa, roles existentes, jerarquía, procesos principales, etc. Y así entender las necesidades reales de la misma. Tras el modelo de negocio continúa la lista de características, donde se expondrán todas las necesidades de la empresa y se explicarán los diagramas seguidos para la elaboración del software. Para concluir con dicho apartado, se explicarán las tecnologías utilizadas en la implementación y el proceso de pruebas por el que se ha sometido el software para testear su correcto funcionamiento. Después se citan las conclusiones alcanzadas tras el desarrollo y se lista el trabajo futuro. Es decir, el resto del trabajo que no ha podido ser desarrollado por falta de tiempo o posibles mejoras. Dicho documento concluye con los anexos, que albergan las competencias cubiertas, la legislación vigente, el manual de usuario para su puesta en marcha y guía de uso y finalmente la bibliografía de las páginas y documentos que han servido de base para la redacción de este documento. 2. Estado actual del arte 7 2 ESTADO ACTUAL DEL ARTE A continuación estudiaremos los software de gestión y ERPs más nombrados en la actualidad para entender la situación actual del mercado. Este capítulo es fundamental para explicar las aportaciones que realiza dicho trabajo. Dentro de los diferentes ejemplos de software para administrar de forma eficiente y eficaz una empresa podemos encontrar los software libre y comerciales. 2.1 SOFTWARE LIBRE Software libre se denomina al software que brinda libertad a los usuarios sobre su producto adquirido. Cuatro libertades: a) La libertad de usar el programa, con cualquier propósito. b) Estudiar el funcionamiento del programa, y adaptarlo a las necesidades. c) Distribuir copias, con lo que puede ayudar a otros. d) Mejorar el programa y hacer públicas las mejoras, de modo que toda la comunidad se beneficie. El calificativo «libre» del software libre se refiere a libertad, no a su gratuidad, aunque por lo regular lo es. Ventajas: - Brinda libertad a los usuarios. - Puede ser usado, copiado, estudiado, modificado y redistribuido. - Ahorros multimillonarios en la adquisición de licencias. - Tiende a ser muy eficiente (porque mucha gente lo optimiza, mejora). Desventajas: - El software libre y el software no-comercial son en realidad incompatibles con el software comercial. - El software libre crea riesgos legales. - El software libre no tiene garantía proveniente del autor. - Disminuye el índice de software ”pirata”. Algunos ejemplos de software Libres que ayudan en la administración de una empresa son: 2. Estado actual del arte 8 2.1.1 OPENERP OpenERP 2 es un completo sistema de gestión empresarial (ERP) de código abierto que cubre las necesidades de las áreas de contabilidad, finanzas, ventas, RRHH, compras, proyectos y almacén entre otras. OpenERP permite la gestión dinámica de los distintos procesos de negocio de manera gráfica e intuitiva, gracias a su potente sistema de generación de flujos de trabajo. El sistema brinda la posibilidad de editar y modificar flujos de trabajo directamente desde la pantalla. Ventajas: - Proporciona la integración entre la cadena de suministro, el proceso de producción y administrativo. - Mejora de procesos. - Puede proporcionar una ventaja estratégica sobre los competidores. Desventajas: - Su implementación puede requerir cambios importantes en la compañía y sus procesos. - Su implementación implica un proceso continuo, que tal vez nunca termine. - La experiencia en ERP es limitada y asignarle personal representa un problema constante. 2 https://www.openerp.com/ 2. Estado actual del arte 9 2.1.2 Openbravo ERP Openbravo ERP 3 es una ERP basada en aplicación web como solución de negocio para la Pequeña y mediana empresa liberado bajo la licencia Openbravo Public License, basada en la Mozilla Public License. El modelo para el programa fue originalmente basado en el programa ERP Compiere que también es de código abierto, liberado bajo la licencia GNU General Public License versión 2. El programa se encontraba entre los diez proyectos más activos de Sourceforge en enero de 2008. Usando Openbravo, Organizaciones ERP pueden automatizar y registrar los procesos de negocio más comunes. Los procesos siguientes son compatibles: Ventas, Compras, Fabricación, Proyectos, Finanzas, MRP y mucho más. Numerosas extensiones funcionales comerciales están disponibles en la Openbravo Exchange que pueden ser adquiridos por los usuarios de la versión Professional Subscription de Openbravo ERP. Esta versión de pago ofrece funciones adicionales en comparación con la Edición para Comunidades gratuita (tales como: herramientas integradas de administración, herramienta no técnica de actualizaciones y mejoras, el acceso a Openbravo Exchange y un Acuerdo de nivel de servicio). Una característica de la aplicación Openbravo ERP es la interfaz web verde a través de la cual los usuarios pueden mantener los datos de la empresa en un navegador web en su PC o PDA. Openbravo También puede crear y exportar informes y datos a varios formatos, tales como PDF y Microsoft Excel. La arquitectura de Openbravo basado en Java se centra en dos modelos de desarrollo: - Ingeniería orientada a modelos, en la que los desarrolladores describen la aplicación en términos de modelos en lugar de código - Modelo vista controlador, un patrón de diseño bien establecido en la cual se mantienen la lógica de presentación y la lógica de negocios aislados. Estos dos modelos permiten la integración con otros programas con una sencilla interfaz. Debido a la aplicación de las normas de Openbravo ERP de código abierto se puede integrar con otras aplicaciones de código abierto como Magento, una tienda en línea, Pentaho Business Intelligence, ProcessMaker BPM, Liferay Portal and SugarCRM. Ventajas: - Openbravo se distribuye sin ningún tipo de coste por uso, número de usuarios, módulos funcionales utilizados o cualquier otro esquema habitual en otros ERPs. - Toda la aplicación se ha construido siguiendo estándares abiertos: J2EE, SQL, JDBC, HTML, CSS, MDD, XML Engine y SQLC para el desarrollo y XML, FOP, PDF, RTF para el intercambio y presentación de datos. - El lenguaje de desarrollo es Java y la base de datos Oracle. 3 http://www.openbravo.com/es 2. Estado actual del arte 10 Desventajas: - No permite manejar simultáneamente varios idiomas para los clientes: la versión estándar no permite indicar un idioma de comunicación distinto para cada cliente: puedes usar el Openbravo en varios idiomas, pero no simultáneamente (por ejemplo para generar facturas en el idioma del cliente). - No permite enviar facturas por mail en lugar de imprimirlas: a estas alturas parece mentira pero de momento esta funcionalidad requiere un desarrollo a medida. - Usabilidad pobre: para una herramienta que será usada por unos pocos usuarios profesionales, las teclas de acceso directo y la navegación por tabulador son fundamentales. Openbravo al ser 100%web tiene este aspecto muy poco trabajado. - El software es gratuito pero la implementación no es barata: la propuesta que nos ha hecho el partner de Openbravo consultado ronda los 27.000 € de coste de implementación inicial. - De forma general el producto es aún poco completo. 2. Estado actual del arte 11 2.2 SOFTWARE COMERCIAL Es el software, libre o no, que es comercializado, es decir, que las compañías que lo producen, cobran dinero por el producto, su distribución o soporte. Posee restricciones en el uso, copia o modificación o cuyo código fuente no está disponible (código cerrado). La mayoría del software comerciales privativo, pero hay software libre comercial, y hay software no libre no comercial. Ventajas: - El software comercial cuenta con más opciones de software de terceros y soporte general de la industria. - El software comercial ofrece mejores beneficios en construcción de aplicaciones a la medida. Desventajas: - Es ilegal extender una pieza de software comercial para adaptarla a las necesidades particulares de un problema específico. - La innovación es derecho exclusivo de la compañía fabricante. - Es ilegal hacer copias del software propietario sin antes haber contratado las licencias necesarias. Algunos ejemplos de Software Comercial de aplicación para el área de administración de empresas son los siguientes: 2.2.1 Microsoft Dynamic CRM Microsoft Dynamics CRM 4 es un software comercial que permite definir una estrategia de negocio centrada en anticipar, conocer y satisfacer las necesidades y los deseos presentes y previsibles de sus clientes, incrementando la efectividad de los empleados de ventas y servicios. Con módulos para ventas, mercadotecnia y servicio al cliente, Microsoft Dynamics CRM 4.0 le da una rápida, flexible y accesible solución que conduce a mejoras consistentes y medibles en cada proceso del negocio y le permite una relación más cercana con sus clientes que ayudará a su empresa a alcanzar nuevos niveles de rentabilidad. Entre su amplia gama de funciones se encuentra: - Administración financiera: Las capacidades de administración financiera de Microsoft Dynamics le ofrecen un método para aumentar la visibilidad de las métricas. Microsoft Dynamics ERP permite la implementación de una administración financiera sólida que establece las bases para desarrollar todo el potencial de su empresa. - Administración de recursos humanos: Las soluciones de administración de recursos humanos de Microsoft Dynamics ERP pueden ayudarle a sacarle el máximo rendimiento a la capacidad delos empleados y a aumentar su fidelidad al tiempo que se reducen los costos y la complejidad de la administración de nóminas, las 4 http://www.microsoft.com/es-es/dynamics/default.aspx 3. Recursos utilizados 18 3.1.2 Plataforma Java Requerido para la ejecución de la aplicación. La plataforma Java 9 es el nombre de un entorno o plataforma de computación originaria de Sun Microsystems, capaz de ejecutar aplicaciones desarrolladas usando el lenguaje de programación Java u otros lenguajes que compilen a bytecode y un conjunto de herramientas de desarrollo. 3.1.3 NetBeans Como entorno de desarrollo se ha utilizado NetBeans 10 . NetBeans es un entorno de desarrollo integrado libre, hecho principalmente para el lenguaje de programación Java. Existe además un número importante de módulos para extenderlo. NetBeans IDE1 es un producto libre y gratuito sin restricciones de uso. NetBeans es un proyecto de código abierto de gran éxito con una gran base de usuarios, una comunidad en constante crecimiento, y con cerca de 100 socios en todo el mundo. Sun MicroSystems fundó el proyecto de código abierto NetBeans en junio de 2000 y continúa siendo el patrocinador principal de los proyectos. La plataforma NetBeans permite que las aplicaciones sean desarrolladas a partir de un conjunto de componentes de software llamados módulos. Un módulo es un archivo Java que contiene clases de java escritas para interactuar con las APIs de NetBeans y un archivo especial (manifest file) que lo identifica como módulo. Las aplicaciones construidas a partir de módulos pueden ser extendidas agregándole nuevos módulos. Debido a que los módulos pueden ser 9 http://www.java.com/es/ 10 https://netbeans.org/ 3. Recursos utilizados 19 desarrollados independientemente, las aplicaciones basadas en la plataforma NetBeans pueden ser extendidas fácilmente por otros desarrolladores de software. 3.1.4 JavaFX Scene Builder JavaFX Scene Builder 11 es una nueva herramienta para diseñar y crear contenidos en JavaFX, que básicamente es un editor de archivos FXML. Es el comienzo de una herramienta más completa de tipo RAD (desarrollo rápido de aplicaciones) para JavaFX, con capacidades de construir un GUI mediante arrastrar y soltar, y eventualmente conexión de datos. 3.1.5 StarUML StarUML 12 es una herramienta para el modelamiento de software basado en los estándares UML (Unified Modeling Language) y MDA (Model Driven Arquitecture), que en un principio era un producto comercial y que hace cerca de un año paso de ser un proyecto comercial (anteriormente llamado plastic) a uno de licencia abierta GNU/GPL. 11 http://www.oracle.com/technetwork/java/javafx/tools/index.html 12 http://staruml.sourceforge.net/en/ 3. Recursos utilizados 20 Dicha aplicación se utilizó para el desarrollo del software, concretamente para el modelado de los diagramas de casos de uso, diagramas de clase, diagramas de secuencia y diagrama de colaboración. 3.1.6 Microsoft Word Para la redacción del presente documento se utilizó Microsoft Word 13 . Microsoft Word es un software destinado al procesamiento de textos. Fue creado por la empresa Microsoft, y actualmente viene integrado en la suite ofimática Microsoft Office. Originalmente fue desarrollado por Richard Brodie para el computador de IBM bajo sistema operativo DOS en 1983.Versiones subsecuentes fueron programadas para muchas otras plataformas, incluyendo, las computadoras IBM que corrían en MS-DOS (1983). Es un componente de la suite ofimática Microsoft Office; también es vendido de forma independiente e incluido en la Suite de Microsoft Works. Las versiones actuales son Microsoft Office Word 2013 para Windows y Microsoft Office Word 2011 para Mac. Ha llegado a ser el procesador de texto más popular del mundo. 13 http://office.microsoft.com/es-es/word/ 3. Recursos utilizados 21 3.2 RECURSOS HARDWARE 3.2.1 Portátil El trabajo se ha realizado con un portátil Lenovo IDEAPAD z500 14 que tiene las siguientes características: - Procesador: Intel® Core i7-3612QM Ivy Bridge Quad Core 2.10GHz (max. con Turbo Boost 3.10GHz) - Memoria RAM: 8 GB tipo DDR3 a 1600MHz - Tarjeta gráfica: Intel HD Graphics 4000 y NVIDIA ® GeForce ® GT 740M gráficos DirectX ® 11 - Audio: Estéreo integrados con tecnología Dolby Home Theater v4 y chip RealTek HDAudio (ALC269) - Conexiones: Lector de tarjetas, SD, Puertos, HDMI, Puerto USB 3.0, 2 puertos USB 2.0, Puerto VGA, Combo línea de audio - Conectividad: Ethernet, Bluetooth 4.0, WiFi 802.11 b/g/n - Pantalla: Tamaño 15.6 - Batería: Litio ión de 4 celdas - Sistema Operativo preinstalado: Windows 8 (64 bits) 3.2.2 Escáner de código de barras Escáner que por medio de un láser lee un código de barras y emite el número que muestra el código de barras, no la imagen. No es un requisito indispensable, pero facilita mucho a la hora de identificar un producto o un ticket. En nuestro caso, dicho escáner se conectaba directamente al puerto PS2 del teclado por medio de un adaptador. Cuando se pasa un código 14 http://shop.lenovo.com/es/es/laptops/ideapad/z-series/z500/ 3. Recursos utilizados 22 de barras por el escáner es como si se hubiese escrito en el teclado el número del código de barras. 3.2.3 Impresora térmica Una impresora térmica se basa en una serie de agujas calientes que van recorriendo un papel especial (termosensible) que al contacto se vuelve de color negro. Dicho hardware es necesario para el impreso de tickets y cierre de cajas en las sucursales. En este trabajo hemos usado la impresora térmica SUP58T2 15 , las características técnicas de dicha impresora son: - Método de impresión: térmica de línea directa - Velocidad de impresión : 90 mm / seg - Ancho del papel: 57,5 ± 0,5 mm - Papel exterior: diámetro 75mm máximo - Densidad de impresión : 384dots/line - Comando de impresión: Compatible ESC / POS - Tipo de interfaz: USB + RJ45 para cajón de monedas - Imprime código de barras: JAN13 ( EAN13 ) / JAN8 ( EAN8 ) / CODE39 - Impresión de papel grueso: 0.06 - 0.08mm - Adaptador de voltaje de entrada: AC 110V/220V , 5060Hz - Salida de tensión del adaptador: DC 12V/3ª - Impresora Voltaje de entrada: DC12V/3ª - Temperatura de trabajo: 0-45 ℃, Humedad : 10 a 80 % - Driver: Win 9x , Win 2000 , Win 2003 , Win XP , Win Vista, Win 7 , Win8 , Linux - Tamaño: 190 * 132 * 119 mm 15 http://www.sunphor.com/index.php/product_detail_id_17.html 3. Recursos utilizados 23 3.2.4 Cajón de dinero El cajón de dinero está diseñado para puntos de venta donde el espacio es elemental para el punto de venta. Su diseño lo hace ser muy funcional para los pequeños comercios, ya que las medidas y el precio se adaptan a la perfección. Las características generales son: - 8 separadores de Moneda - 4 separadores de Billete. - llave de 3 posiciones. - Ranura de documentos. - Conexión RJ11. - Sujetadores de billetes Metálicos. 3. Recursos utilizados 24 3.2.5 Impresora Necesario para el impreso de etiquetas y códigos de barras. La utilizada en este trabajo ha sido la Canon i-SENSYS LBP62 16 . Es una impresora láser compacta con impresión a doble cara automática de uso personal. Sus características generales son: - Tamaño reducido - 25 ppm, tiempo de salida de la primera impresión: 6 segundos - Impresión a doble cara automática - Ahorro energético - Funcionamiento silencioso - Cartucho Todo en Uno para un funcionamiento sin mantenimiento 16 http://www.canon.es/For_Home/Product_Finder/Printers/Laser/i-SENSYS_LBP6020/index.aspx 4. Planificación del trabajo 25 4 PLANIFICACIÓN DEL TRABAJO 4.1 METODOLOGÍA DE DESARROLLO El plan de trabajo que se va a seguir para la realización de dicho proyecto es mediante la metodología PUD (Proceso Unificado de Desarrollo Software). El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado 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. Las características de dicha metodología son: - Iterativo e Incremental: El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo. - Dirigido por los casos de uso: En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño, implementación, prueba, etc. - Centrado en la arquitectura: El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema. - Enfocado en los riesgos: El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de Elaboración deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero. 4. Planificación del trabajo 26 4.2 PLANIFICACIÓN Y TEMPORIZACIÓN Este punto recoge la planificación de la realización del presente trabajo, así como un análisis del tiempo empleado. Es decir, se describe las distintas fases por las que ha transcurrido el desarrollo del trabajo y la duración de cada una de ellas. Descripción Horas Documentación y análisis 60 - Búsqueda de información 10 - Establecer entorno de trabajo 10 - Familiarización con nuevas tecnologías 30 - Análisis de requisitos 10 Diseño y construcción 200 - Diseño del sistema 50 - Diseño del programa 50 - Codificación 100 Pruebas y mejoras 60 - Pruebas de caja blanca 20 - Pruebas de caja negra 20 - Verificación 10 - Mejoras 10 Realización de la memoria 50 Procesos administrativos 10 TOTAL 380 4. Planificación del trabajo 27 4.3 PRESUPUESTO El presupuesto es el cálculo anticipado del coste requerido para la realización del trabajo. El presupuesto necesario para la realización de este proyecto se descompone en tres tipos de costes según sus características: - Coste del hardware: Es el coste correspondiente a los equipos utilizados. - Coste del software: Incluye los gastos derivados de la utilización de las herramientas empleadas para la realización del proyecto. - Coste del personal: Gastos derivados de la remuneración de la persona que desarrolla el proyecto. Las siguientes secciones detallan cada uno de los costes anteriores. 4.3.1 Coste del hardware En la siguiente tabla se muestran los elementos físicos utilizados en la realización de este trabajo, además de su coste: Elemento Hardware Coste Ordenador portátil 650€ Escáner de códigos de barras 80€ Impresora térmica 110€ Cajón de efectivo 140€ Impresora 100€ TOTAL 1.080€ 4.3.2 Coste del software Todo el software utilizado, exceptuando el editor de texto, se encuentra bajo la licencia GNU General Public License, por lo que tenemos la libertad de usar, estudiar, compartir (copiar) y modificar el software sin ningún coste al respecto. En cuanto al editor de texto utilizado, Microsoft Office 2013, tiene un coste por licencia de 135,00€. 5. Desarrollo del trabajo 34 El supervisor de contabilidad, de recursos humanos y de compras son los responsables de cada departamento en concreto. Al tratarse de una pyme dichos departamentos no requieren de más empleados, por lo que son gestionados por una persona cada uno de ellos. En el departamento de mantenimiento se encuentra: - El supervisor de mantenimiento: Responsable del departamento y encargado de los operarios de mantenimiento. - Operarios de mantenimiento: Trabajadores del jefe de mantenimiento. En el departamento de ventas: - Supervisor de ventas: Responsable del departamento de ventas. - Encargados: Responsables de cada punto de venta. - Empleados: Su única función es la de atender a los clientes y venderles los productos de la empresa. En el departamento de almacén: - Jefe de almacén: Responsable del departamento, lleva la logística del mismo. - Mozo de almacén: Ayudante del jefe. Y finalmente en el departamento de administración: - Supervisor de administración: Responsable del departamento - Personal de administración: Encargados de pasar todos los pedidos al soporte informático y verificar que esté todo correctamente. 5.1.1.3.2 Relacionados con el negocio Además de los actores nombrados con anterioridad, existen otros actores que aunque no trabajen en la empresa, son importantes para la misma. Estos son: - Clientes: Son el motor de la empresa. Sus ingresos son lo que hace que una empresa sea rentable o no. Estos se relacionan con el departamento de ventas, ya sea para realizar una compra o una devolución de alguno de los productos de la empresa. - Representantes: Se relacionan con el departamento de compras. Y son los que junto al jefe de compras realizan las propuestas de pedidos para cada temporada. - Fábricas: Se relacionan con el departamento administrativo. Y son a los actores a los que acude el jefe de administración en caso de que exista alguna incidencia en algún pedido. - Asesoría: Se relaciona con el jefe de contabilidad y se le aporta la información necesaria para que puedan llevar correctamente la contabilidad de la empresa. - Bancos: Se relacionan también con el jefe de contabilidad. Este les da la aprobación de realizar cualquier pago. 5. Desarrollo del trabajo 35 5.1.1.4 Procesos importantes en la empresa Los procesos básicos e importantes en Galerías Lorens se pueden englobar en cinco, concretamente en la entrada, distribución y venta/devolución de mercancía, la contabilidad y la gestión de incidencias. A continuación veremos en profundidad cada uno de ellos. 5.1.1.4.1 Entrada de mercancía Dicho proceso comienza cuando el supervisor de compra se reúne con el representante de una marca para ver el muestrario de la temporada. En dicha reunión se hace una selección de los productos que se desean, se acuerdan las cantidades, la forma de pago y se concreta la fecha de envío. Como resultado se obtiene una propuesta de pedido donde se detalla el pedido realizado, la fecha de realización, el precio del mismo, etc. Dicha propuesta de pedido se le envía al departamento de administración donde el personal de administración lo añade al soporte informático de la empresa. Una vez se ha añadido en el software de la empresa, ya se ha creado todos los productos que se van a recibir, habiéndole especificado el precio costo, precio de venta y tipo de producto. Según lo acordado en el muestrario, la mercancía llega al almacén central. Hay que tener en cuenta que lo que se realizó en el muestrario fue la propuesta de pedido, por tanto, lo que llega de dicho pedido no tiene por qué concordar al 100% (productos agotados, que no se fabricaron, etc.). Es aquí, donde los mozos de almacén junto con el supervisor verifican que lo que se encuentra dentro de las cajas y el albarán concuerda. El albarán no es más que una lista detallada de lo que se encuentra dentro de las cajas. En caso de que no concordasen, se le avisa al departamento de administración que ha faltado mercancía para que dicho departamento lo resuelva (poniéndose en contacto con el fabricante y alertando del problema). Representante Gerente Personal de administración Supervisor de administración Propuesta de pedido Realizan Envía Introducen Soporte informático Réplica propuesta pedido 5. Desarrollo del trabajo 36 Además de todo esto (esté completo o no el pedido) el departamento de almacén captura todos los productos recibidos para que el soporte informático pueda asignarle el código de barras a cada producto y además tener una constancia de lo que ha llegado. Destacar que cada marca trabaja de distinta manera, es decir, lo explicado hasta ahora es el estándar que más o menos todas las marcas siguen. Por ejemplo, hay marcas que además del albarán, también envían dentro de cada caja un packing list, que no es más que una lista detallada de lo que se encuentra dentro de la caja en cuestión (además del albarán). 5.1.1.4.2 Distribución de mercancía La distribución de mercancía es denominada en la empresa como traspaso. Los traspasos pueden ser de tienda a tienda, o bien, del almacén a tienda o viceversa. Para comenzar un traspaso, se introduce en el software de la empresa todo lo que se vaya a enviar, especificándole además la sucursal de origen y la de destino. Una vez finalizado el traspaso se introduce en cajas y se llama a la central para avisar a los de mantenimiento. Estos distribuyen dichas cajas de la tienda origen a la de destino. En la tienda de destino se captura toda la mercancía recibida, de manera que el soporte informático puede controlar que lo enviado y recibido concuerdan. Comentar que actualmente en la empresa no existe ningún medio que indique si se ha de distribuir mercancía o no. Es decir, el supervisor de almacén periódicamente observa las existencias de cada sucursal y decide si se ha de realizarse algún traspaso. En caso de que sí, este avisa telefónicamente a la sucursal en concreto para que lo realice. Mozos de almacén Supervisor de almacén AlbaránPacking list Producto Soporte informático Réplica albarán Verifican 5. Desarrollo del trabajo 37 5.1.1.4.3 Abrir/cerrar caja La gestión de cajas en un proceso por el cual se lleva un control diario de los cajones de efectivo de cada sucursal de la empresa. Dicho control consiste en anotar la cantidad de dinero que se encuentra en el cajón de efectivo (normalmente 300€) al comenzar la jornada laboral de la tienda (abrir caja). Una vez llegado a este punto, se pueden empezar a realizar ventas. En caso de pagos con tarjeta se almacenará en el cajón de efectivo una copia del pago. Al llegar la hora de cerrar se procede al cierre de caja. En este momento el soporte informático te especifica que cantidad ha de haber de cada método de pago (vales, efectivo, distintas tarjetas, etc.). En caso de concordar lo especificado con lo que se encuentra en el cajón de efectivo, se deja en el cajón los 300€ correspondientes, y el resto (las ventas pagadas en efectivo) se ingresan en el banco. Mencionar que la política de Galerías Lorens indica que si en el cierre de caja falta dinero (se ha cometido algún error a la hora de devolver al cliente o directamente hay alguna empleada que esté robando) son las mismas empleadas las que han de poner el dinero faltante. Empleada 1 Empleada 2 Traspaso Crea Recibe Operarios de mantenimiento Transporta Producto Empleada Caja Abre/Cierra Venta 5. Desarrollo del trabajo 38 5.1.1.4.4 Venta/devolución de mercancía El proceso de venta a los clientes en las distinta tiendas es el proceso más importante en la empresa, ya que este proceso es el que hace rentable a una empresa. Toda venta generará un ticket con la fecha, sucursal, productos vendidos, importe total y las condiciones de devolución. Cuando un cliente desea devolver algún producto, se ha de presentar en cualquier sucursal de la empresa con el producto a devolver y el respectivo ticket. La dependienta verifica que la devolución está dentro del plazo permitido (30 días) y en caso de estar todo correcto se generaría un vale con el importe de la prenda. La política de Galerías Lorens es que no se devuelve el dinero, únicamente se emiten vales por el mismo importe. Un vale es un documento que establece un importe y se puede utilizar en la empresa como si fuera dinero real. 5.1.1.4.5 Contabilidad Toda la contabilidad de la empresa la lleva una única persona y es el supervisor de contabilidad. Su función es almacenar organizadamente todos los gastos de la empresa (material, pedidos, facturas de agua, luz, alquileres, nóminas, etc.), introducirlos en el soporte informático y proporcionar todos los datos requeridos por la asesoría para que esta pueda llevar la verdadera contabilidad, pagar impuestos, etc. 5.1.1.4.6 Gestión de incidencias Actualmente la gestión de incidencias en Galerías Lorens se alertan telefónicamente. Una vez alertada una incidencia, los operarios de mantenimiento se dirigen al lugar afectado para solucionarlo. Empleada Venta Cliente Producto Quiere Vende Realiza Ticket Genera Supervisor de contabilidad Gasto Contabiliza 5. Desarrollo del trabajo 39 Al hablar de incidencias, generalizo en cuento a problemas técnicos (bombillos fundidos, ordenadores rotos, impresoras rotas...), falta de material (bolsas, papel, bolígrafos…), distribución de mercancía, etc. 5.1.2 Lista de características En la lista de características se detallan todas las posibles funcionalidades y atributos que se pretende que tenga el software de gestión a desarrollar. A continuación, se muestra una pequeña leyenda que explica algunos elementos utilizados en los contenidos de la lista de características: Código Descripción del campo AD Perteneciente al departamento de administración AL Perteneciente al departamento de almacén VENT Perteneciente al departamento de venta COMP Perteneciente al departamento de compras CONT Perteneciente al departamento de contabilidad MANT Perteneciente al departamento de mantenimiento RH Perteneciente al departamento de recursos humanos COMUN Perteneciente a todos los departamentos SUPER Perteneciente al supervisor del sistema Prioridad Se mide de Alta a Baja, estando el punto intermedio Media. Estado Propuesta: La característica está a la espera de ser mostrada al cliente para su aceptación. Aceptada: La característica se desarrollará en esta versión del producto. En desarrollo: Ya se está desarrollando. Finalizada: Se ha terminado de desarrollar. Postergada: No se desarrollará hasta una versión futura. Rechazada: Probablemente no se desarrollará en ninguna versión. A continuación se mostrará la lista de características: Operarios de mantenimiento Incidencia Empleado Alerta Resuelven 5. Desarrollo del trabajo 40 Código Nombre Descripción Prioridad Estado COMUN.01 Loguearse en el sistema Permite a cualquier usuario mediante un usuario y contraseña acceder a los servicios que se le han sido otorgados. Alta Aceptado COMUN.02 Salir del sistema Permite a cualquier usuario logueado en el sistema, salir del mismo. Alta Aceptado COMUN.03 Cambiar contraseña Permite a cualquier usuario logueado en el sistema cambiar su contraseña. Alta Aceptado COMUN.04 Crear incidencia Permite informar acerca de cualquier incidencia surgida. Media Postergada COMUN.05 Ver incidencias Permite ver las incidencias surgidas en el área de trabajo en el que se encuentra el usuario logueado. Media Postergada SUPER.01 Gestionar usuarios Permite listar, añadir, eliminar, modificar usuarios en el sistema. Al añadir un usuario en el sistema hay que asignarle un nombre, contraseña y privilegios que se le otorgan, periodo de contratación y salario. Media Postergada SUPER.02 Gestionar tiendas Permite añadir, modificar y eliminar tiendas. Una tienda tiene un número de teléfono, ubicación, código postal y nombre. Media Postergada 5. Desarrollo del trabajo 41 SUPER.03 Gestionar tipos de gastos. Permite añadir, modificar y eliminar tipos de gastos en el sistema (aparte de los existentes por defecto) Media Postergada SUPER.04 Gestionar familias de productos Permite añadir, modificar y eliminar familias de productos (aparte de las existentes por defecto). Media Postergada SUPER.05 Gestionar tipos de incidencias Permite añadir, modificar y eliminar tipos de incidencias. Media Postergada RH.01 Gestionar vacaciones y días libres Permite establecer un periodo de vacaciones a todos los usuarios del sistema. Baja Rechazada RH.02 Gestionar remesa de nóminas Genera un fichero con la cuantía de los salarios de cada uno de los trabajadores. Se envía al departamento de contabilidad para que ellos realicen la orden de pago. Baja Rechazada VENT.01 Gestionar promocion es Permite enviar correos a todos los clientes de la empresa promocionando y ofertando productos por su fidelidad. Baja Rechazada VENT.02 Gestionar oferta por cumpleaño s Permite activar o desactivar el envío de mensajes a todo cliente que sea su cumpleaños obsequiándolo con una oferta en cualquier tienda de la empresa Baja Rechazada VENT.03 Informe de las repercusio nes de Permite valorar la repercusión en ventas o afluencia de gente de cada promoción. Baja Rechazada 5. Desarrollo del trabajo 42 cada promoción VENT.04 Informe de ventas Permite ver las ventas de todas las sucursales. A dicho informe se le podrá aplicar un filtro por rango de fecha, tienda y empleados. Alta Aceptado VENT.05 Gestionar traspasos Permite enviar y recibir mercancías de otras sucursales, ya sea tienda o almacén. Para ello es necesario funcionalidades como listar recibidos y sin enviar, crear, modificar, eliminar y controlar traspaso. Alta Aceptado TPV-AL.01 Realizar inventario Permite realizar un inventario en cualquier sucursal, ya sea un punto de venta o el almacén. Alta Aceptado TPV.01 Gestionar cajas Permite abrir y cerrar caja en un punto de venta. Una caja tiene un estado y un dinero inicial. Alta Aceptado TPV.02 Gestionar ventas Permite realizar ventas en las tiendas de la empresa. Alta Aceptado TPV.03 Gestionar devolucion es Permite realizar una devolución en cualquier tienda de cualquier producto de la empresa que haya sido comprado en un periodo inferior a 15 días. Toda devolución emitirá un vale de la empresa. Alta Aceptado 5. Desarrollo del trabajo 43 TPV.04 Gestionar clientes Permite dar de alta, modificar o eliminar un cliente en la empresa. Para darse de alta es necesario un nombre, apellido, DNI, fecha de nacimiento y correo electrónico. Baja Rechazada TPV-AL.02 Ver existencias en la sucursal Permite ver los productos que están en la sucursal, ya sea punto de venta o almacén. Alta Aceptado TPV-AL.03 Buscar producto Permite realizar una búsqueda de un modelo de producto en concreto. Alta Aceptado AD.01 Gestionar fabricantes Permite listar, añadir, eliminar, modificar un fabricante en el sistema. Un fabricante está compuesto por un nombre, CIF, marcas y proveedor que lo distribuye. Alta Aceptado AD.02 Gestionar pedidos Permite listar pedidos sin finalizar, añadir, eliminar, modificar pedidos. Un pedido tiene una fecha de realización, fabricante, estado, detalle del pedido y coste total. Alta Aceptado AD.03 Seguimien to de pedidos Permite listar los pedidos abiertos. De aquí se puede ver los albaranes llegados de cada uno. Resolver los albaranes que se hayan cerrado con incidencias y cambiar estado del pedido a finalizado. Alta Aceptado AD.04 Informe de pedidos Permite ver los pedidos finalizados. Alta Aceptado 5. Desarrollo del trabajo 50 5.2.2.2.4 Casos de uso paquete sucursal El supervisor de ventas posee el privilegio de poder ver las ventas de todas las sucursales. Dicha funcionalidad le permite establecer un rango de fechas por las que quiera ver las ventas, así como las sucursales que desea ver. Por otro lado, las empleadas pueden ver las existencias de cada producto en las distintas sucursales (incluido en la misma). Además de poder abrir y cerrar caja. En el periodo entre abrir y cerrar caja se pueden realizar ventas/devoluciones. Dicha funcionalidad emitirá siempre un ticket/vale (Anexo 6) según se realice una venta o una devolución. Para concluir, mencionar que al cerrar caja se imprime un cierre de caja (Anexo 7) que no es más que una lista detallada de cuanto se ha vendido en el día, especificando por cada tipo de pago (Efectivo, vales y distintas tarjetas). System Empleada Supervisor de ventas Ver ventas Ver existencias Abrir caja Cerrar caja Realizar venta <<extend>> <<extend>> Imprimir ticket/vale Imprimir cierre de caja <<include>> <<include>> Filtrar por tiendas <<extend>> Filtrar por fecha<<extend>> 5. Desarrollo del trabajo 51 5.2.3 Especificación de casos de uso En esta sección se expone la especificación detallada de los casos de uso más relevantes. 5.2.3.1 Crear pedido Nombre del C.U. Crear pedido Descripción Comienza un nuevo pedido. Actores Usuarios de administración. Precondiciones Haberse logueado en el sistema y estar posicionado en el listado de pedidos en construcción dentro del módulo de administración. Postcondiciones Pedido añadido a la Base de Datos. Camino normal Camino alternativo 1. El usuario hace clic sobre el botón crear pedido 2. El sistema habilita una interfaz para que el usuario pueda especificar la temporada, fabricante, fecha, … (Figurado 1) 3. El usuario introduce todos los datos del pedido. 4. A continuación el usuario introduce los productos (Figura 2) 5.- Finalmente el usuario cambia el estado del pedido a “Abierto” y finaliza el pedido cliqueando Guardar pedido 5.1.a. El usuario hace clic en Guardar pedido con el estado en “Construcción” 5.1.b. Se almacena el pedido en la base de datos, pero aún como no terminado. 5.1.c. Puede seguir editando el pedido o salir. 5.2.a. El usuario hace clic en Eliminar pedido. 5.2.b. El pedido es eliminado completamente, tanto de la interfaz como de la base de datos. 5.2.c. Salta a 6. 6. Fin del Caso de Uso. Interfaces 5. Desarrollo del trabajo 52 Figura 1: Figura 2: 5. Desarrollo del trabajo 53 5.2.3.2 Crear albarán Nombre del C.U. Crear albarán Descripción Comienza un nuevo albarán. Actores Usuarios de almacén. Precondiciones Haberse logueado en el sistema y estar posicionado en el listado de albaranes en construcción dentro del módulo de almacén. Postcondiciones Albarán añadido al sistema. Camino normal Camino alternativo 1. El usuario hace clic sobre el botón crear albarán 2. El sistema habilita una interfaz para que el usuario pueda especificar el pedido al que pertenece, coste de transporte, … (Figurado 1) 3. El usuario introduce todos los datos del albarán 4. A continuación el usuario introduce los productos que llegaron (Figura 2) 5.- Finalmente el usuario finaliza el albarán pulsando sobre “Finalizar albarán”. 5.1.a. El usuario hace clic en Guardar albarán. 5.1.b. Se almacena el albarán en la base de datos, pero aún como no terminado. 5.1.c. Puede seguir editando el albarán o salir. 5.2.a. El usuario hace clic en Eliminar albarán. 5.2.b. El pedido es eliminado completamente, tanto de la interfaz como de la base de datos. 5.2.c. Salta a 6. 6. Fin del Caso de Uso. 5. Desarrollo del trabajo 54 Interfaces Figura 1: Figura 2: 5. Desarrollo del trabajo 55 5.2.3.3 Iniciar sesión Nombre del C.U. Iniciar sesión Descripción Inicia sesión en el sistema Actores Usuarios no registrado Precondiciones Haberse accedido al sistema y estar en la zona de iniciar sesión. Postcondiciones El usuario queda registrado y accede al panel principal del módulo donde haya realizado en login. Camino normal Camino alternativo 1. El sistema muestra una interfaz donde se le solicita al usuario no registrado su usuario y contraseña (Figura 1) 2. El usuario introduce los datos y pulsa Entrar. 3. El usuario, la contraseña y los permisos son correctos, por lo que accede a la zona principal del módulo. 3.1.a. El usuario o la contraseña es incorrecto/a. 3.1.b Se le deniega el acceso al usuario (Figura 2). 3.2.a. El usuario y contraseña son correctos, pero no tiene autoridad para acceder a dicho módulo del sistema. 3.2.b. Se le deniega el acceso al usuario. 4. Fin del Caso de Uso. Interfaces Figura 1: 5. Desarrollo del trabajo 56 Figura 2: 5. Desarrollo del trabajo 57 5.2.3.4 Ver ventas Nombre del C.U. Ver ventas Descripción Permite ver al supervisor de ventas las ventas por las distintas sucursales Actores Supervisor de ventas Precondiciones Haberse logueado en el sistema en el módulo del TPV (terminal punto de venta) como supervisor de ventas y estar en el área de ver ventas. Postcondiciones Se muestran las ventas solicitadas Camino normal Camino alternativo 1. El sistema muestra una interfaz en la que se le solicita el rango de fechas y las sucursales en las que desea ver las ventas. 2. El supervisor de ventas especifica las fechas y las sucursales y pincha en ver ventas. 3. El sistema muestra las ventas solicitadas (Figura 1). 4. Fin del Caso de Uso. Interfaces Figura 1: 5. Desarrollo del trabajo 58 5. Desarrollo del trabajo 59 5.2.3.5 Ver existencias Nombre del C.U. Ver ventas Descripción Permite ver los empleados las existencias de cualquier modelo en las sucursales. Actores Empleados Precondiciones Haberse logueado en el sistema en el módulo del TPV (terminal punto de venta) y estar en el área de ver existencias. Postcondiciones Se muestran las existencias del producto solicitado en cada sucursal seleccionada. Camino normal Camino alternativo 1. El sistema muestra una interfaz en la que se le solicita las sucursales en las que se desea buscas y el producto en cuestión. 2. La empleada inserta los datos de búsqueda 3. El sistema muestra las existencias (Figura 1). 4. Fin del Caso de Uso. Interfaces Figura 1: 5. Desarrollo del trabajo 66 5.2.3.8 Cerrar caja Nombre del C.U. Cerrar caja Descripción Permite a los empleados cerrar la caja para finalizar la jornada laboral. Actores Empleados Precondiciones Haberse logueado en el sistema en el módulo del TPV (terminal punto de venta) y estar la caja abierta. Postcondiciones Queda contabilizado en el sistema el cierre de caja. Camino normal Camino alternativo 1. El sistema muestra una interfaz en la que se indica la cantidad que debería de haber en el cajón de efectivo según cada tipo de pago. 2. La empleada introduce en el cierre de caja la cantidad que verdaderamente hay en el cajón de efectivo y cliquea cerrar caja. 2.1.a. La empleada pulsa cancelar y se cierra la interfaz de cerrar caja 2.1.b. Salta al punto 4. 3. El sistema imprime un cierre de caja que consta de la sucursal, fecha de apertura, cierre y cantidad vendida detallada según cada tipo de pago. 4. Fin del Caso de Uso. Interfaces Figura 1: 5. Desarrollo del trabajo 67 5. Desarrollo del trabajo 68 5.3 MODELO DE ANÁLISIS El modelo de análisis es la primera representación técnica de un sistema. Utiliza una mezcla de formatos en texto y diagramas para representar los requisitos del software, las funciones y el comportamiento. De esta manera se hace mucho más fácil de comprender dicha representación, ya que es posible examinar los requisitos desde diferentes puntos de vista aumentando la probabilidad de encontrar errores, de que surjan debilidades y de que se descubran descuidos. En este caso dicho modelo de análisis estará compuesto por la realización del caso de uso, el diagrama de clases y el de colaboración. Debido al tamaño de este trabajo, únicamente analizaremos los casos de uso más importantes a desarrollar que son: - Crear pedido - Crear albarán - Iniciar sesión - Abrir caja - Realizar venta - Cerrar caja 5.3.1 Crear pedido 5.3.1.1 Realización de caso de uso Esta colaboración describe como se ejecuta el caso de uso 'Crear pedido', por lo que representa una traza directa hacia el caso de uso 'Crear pedido'. 5.3.1.2 Diagrama de clases La creación de un nuevo pedido comienza cuando un usuario de administración se posiciona sobre el botón de crear pedido en el listado de pedidos en construcción. Cuando esto se produce, el control de pedido muestra la interfaz al usuario para que rellene los datos necesarios y añada los productos oportunos al pedido en cuestión. Una vez que está listo toda la información respecto al pedido, el control que ya ha generado el pedido, activa el 'control de Persistencia' para que procese el pedido. Crear pedido Crear pedido <<trace>> 5. Desarrollo del trabajo 69 5.3.1.3 Diagrama de colaboración La siguiente imagen es el diagrama de colaboración que describe el caso de uso 'Crear pedido'. Comienza cuando un usuario de administración decide crear un pedido, el control de pedido se encarga de cargar la interfaz para que el usuario rellene los datos oportunos, añada productos y cree su pedido. Una vez el usuario finaliza esta tarea, el control principal obtiene todos los datos y crea el pedido en cuestión. A continuación, activa el control de persistencia para que el pedido sea procesado y almacenado, y es este último el que confirma que se ha procesado con éxito y se finaliza el caso de uso. 5.3.2 Crear albarán 5.3.2.1 Realización de caso de uso Esta colaboración describe como se ejecuta el caso de uso 'Crear albarán’, por lo que representa una traza directa hacia el caso de uso 'Crear albarán'. Usuario de administración IU Crear pedido Control Pedido Control Persistencia Pedido rellena > < muestra activa > genera > obtiene > : Usuario de administración : IU Crear pedido : Control Pedido : Pedido : Control Persistencia < 1: Carga interfaz 2: Inserta pedido > 3: Obtiene datos > 4: Genera > 5: Activa control > 6:Oobtiene > < 7: Confirma Crear albarán Crear albarán <<trace>> 5. Desarrollo del trabajo 70 5.3.2.2 Diagrama de cases La creación de un nuevo albarán comienza cuando un usuario de almacén se posiciona sobre el botón de crear albarán en el listado de albaranes en construcción. Cuando esto se produce, el control de albarán muestra la interfaz al usuario para que seleccione el pedido al que pertenece y realice el albarán. Una vez que está listo toda la información respecto al albarán, el control que ya ha generado el albarán, activa el 'control de Persistencia' para que lo procese. 5.3.2.3 Diagrama de colaboración El diagrama de colaboración describe el caso de uso 'Crear albarán', que comienza cuando el control de albarán carga la interfaz necesaria para crear el mismo. Tras el usuario crear el albarán el control obtiene todos los datos y genera el albarán. Es entonces, cuando el control de persistencia obtiene dicho albarán para procesarlo y almacenarlo. Tras ello confirma al control de albarán que el procesamiento del mismo ha sido realizado con éxito. Usuario de almacén IU Crear albarán Control albarán Control Persistencia Albarán rellena > < muestra activa > genera > obtiene > : Usuario de almacén : IU Crear albarán : Control albarán : Albarán : Control Persistencia < 1: Carga interfaz 2: Inserta albarán > 3: Obtiene datos > 4: Genera > 5: Activa > 6: Obtiene > < 7: Confirma 5. Desarrollo del trabajo 71 5.3.3 Iniciar sesión 5.3.3.1 Realización de caso de uso La ejecución del caso de uso ‘Iniciar sesión’ se representa con una traza directa al caso de uso del mismo. 5.3.3.2 Diagrama de clases El inicio de sesión en el soporte informático comienza cuando cualquier usuario no logueado ejecuta cualquier aplicación del mismo. El control de login muestra al usuario la interfaz para que este especifique su usuario y contraseña. Al introducirlos en control activa el control de persistencia y genera un usuario, el cual es procesado por el control de persistencia y este verifica que es usuario es correcto. Finalmente si la verificación es positiva, el control de login informa al control de la aplicación en cuestión para que este muestre ya al usuario logueado la interfaz oportuna según la aplicación que se esté ejecutando. En caso contrario, vuelve a mostrarle la interfaz de login especificándole que no se ha encontrado el usuario en cuestión. 5.3.3.3 Diagrama de colaboración La siguiente imagen muestra el diagrama de colaboración que describe el caso de uso Iniciar sesión'. El primer paso en la realización del caso de uso es que el control de login cargue la interfaz. El usuario introduce los datos y el control con los datos proporcionados genera un usuario. Es activado el control de persistencia y este obtiene dicho usuario y lo procesa. En Iniciar sesión Iniciar sesión <<trace>> Usuario no logueado Usuario registrado IU Login Control login Usuario Control Persistencia IU Aplicación rellena > < muestra activa > obtiene > genera > Control aplicación informa > < muestra 5. Desarrollo del trabajo 72 caso de que el usuario sea correcto, el control de login informa al control de la aplicación de dicho suceso y este carga la interfaz oportuna a la aplicación que se esté ejecutando. En caso contrario, el control de login notifica al usuario mediante la interfaz que el usuario es incorrecto. 5.3.4 Abrir caja 5.3.4.1 Realización de caso de uso La realización del caso de uso abrir caja posee una traza directa con el caso de uso en cuestión. 5.3.4.2 Diagrama de clases El proceso de abrir caja comienza cuando una empleada pincha sobre el botón de abrir caja. Es aquí cuando el control de abrir caja muestra la interfaz abrir caja para que se especifique la cantidad de la misma. Cuando el dato es introducido el control genera una caja y activa el control de persistencia para que este procese la caja. : Usuario no logueado : IU Login : Control login : Usuario : IU Aplicación : Control Persistencia : Control aplicación < 1: Carga interfaz 2: Inserta usuario > 3: Obtiene datos > 4: Genera > 5: Activa > 6: Obtiene > < 7: Confirma 8: Informa > < 9: Carga Interfaz 10: Observa > Abrir caja Abrir caja <<trace>> 5. Desarrollo del trabajo 73 5.3.4.3 Diagrama de colaboración La siguiente imagen muestra el diagrama de colaboración que describe el caso de uso Abrir caja'. El control de abrir caja carga la interfaz necesaria para que la empleada inserte la cuantía en efectivo que se encuentra en el cajón de efectivo. Tras concluir dicho paso, el control de abrir caja obtiene el dato suministrado y genera una caja, la cual es procesada por el control de persistencia tras su activación. Una vez que la caja es procesada y almacenada por el control de persistencia, dicho control informa al control de abrir caja el éxito del procesamiento. 5.3.5 Realizar venta 5.3.5.1 Realización de caso de uso La ejecución de dicho caso de uso describe una traza directa con el mismo. Empleada Control Persistencia IU Abrir caja Control Abrir caja Caja rellena > < muestra activa > genera > obtiene > : IU Abrir caja : Control Abrir caja : Control Persistencia : Caja : Empleada < 1: Carga interfaz 2: Rellena > 3: Obtiene > 4: Genera > 5: Activa > 6: Obtiene > 7: Confirma Realizar venta Realizar venta <<trace>> 5. Desarrollo del trabajo 74 5.3.5.2 Diagrama de clases La realización de una venta comienza cuando una empleada registra en la interfaz de venta unos productos. Es entonces cuando también ha de especificar el tipo de pago, así como la cuantía. Tras completar todos los datos solicitados el control de venta genera una venta y activa al control de persistencia para que la procese. Cuando el control de persistencia confirma la venta, el control de venta informa al control de impresión que se ha realizado una venta para que este genere el ticket. 5.3.5.3 Diagrama de colaboración La siguiente imagen muestra el diagrama de colaboración que describe el caso de uso Realizar venta'. Primero el control de venta carga el interfaz necesario para que la empleada pueda introducir los productos que se desean comprar. Cuando los datos son introducidos el control de venta genera la venta consecuente y activa el control de persistencia para que este la procese. Al finalizar el procesamiento, el control de venta informa al control de impresión que se ha realizado una venta con éxito para que genere el ticket correspondiente. Empleada Control Persistencia IU Venta Control Venta Venta Control de impresion Ticket rellena > < muestra genera > activa > obtiene > informa > < genera : Empleada : IU Venta : Control Venta : Venta : Ticket : Control de impresion : Control Persistencia < 1: Carga interfaz 2: Introduce productos > 3: Obtiene datos > 4: Genera > 5: Activa > 6: Obtiene > < 7: Confirma 8: Informa > < 9: Genera 5. Desarrollo del trabajo 75 5.3.6 Cerrar caja 5.3.6.1 Realización de caso de uso Al igual que en el resto de realizaciones de caso de uso, Este se relaciona mediante una traza directa con el caso de uso perteneciente, es decir, cerrar caja. 5.3.6.2 Diagrama de clases El cierre de caja comienza cuando una empleada pulsa sobre el botón cerrar caja. Es entonces cuando el sistema muestra la interfaz del cierre de caja donde la empleada rellena los datos solicitados (cantidades de cada tipo de pago existente en el cajón de efectivo). Al concluir, el control de cierre de caja actualiza la caja y activa al control de persistencia para que la procese nuevamente. Tras concluir con éxito dicho procesamiento, el control de cierre de caja informa al control de impresión que se ha cerrado la caja para que este pueda generar el cierre de caja. 5.3.6.3 Diagrama de colaboración La siguiente imagen muestra el diagrama de colaboración que describe el caso de uso 'Cerrar caja'. Primer el control de cierre de caja carga la interfaz para que la empleada introduzca los datos. Tras esto, el control de cierre de caja actualiza la caja con los datos proporcionados y activa el control de persistencia para que este procese la actualización. Al Cerrar cajaCerrar caja <<trace>> Control Persistencia Empleada Control de impresion IU Cerrar caja Control Cierre caja Caja obtiene > Cierre de caja rellena > < muestra actualiza > activa > informa > < genera 5. Desarrollo del trabajo 82 5.4.3.4 Iniciar sesión La funcionalidad de login es común a los tres módulos, ya que los tres requieren de él para el acceso de usuario a los distintos módulos. Al llamar a dicha interfaz (Login) se le especifica que tipos de permisos se requieren para entrar (según el módulo que lo haya llamado), tras el usuario introducir sus datos, el controlador de dicha interfaz (LoginController) genera una clase Usuario con las datos aportados y se lo pasa a la clase ConsultaComun para que este chequee que el usuario existe y tiene los permisos necesarios. Login LoginController +crearUsuario() Usuario +nombre +usuario +contraseña ColsultaComun +verificaUsuario() Almacen Administracion TPV 5. Desarrollo del trabajo 83 5.4.3.5 Abrir caja Abrir caja pertenece al módulo del terminal punto de venta (TPV), y el controlador principal de dicho módulo es TPVController. Dicho controlador muestra al usuario la interfaz para abrir la caja (AbrirCaja) y tras introducir el fondo de caja su controlador (AbrirCajaController) instancia la clase Caja con el fondo de caja introducido y la fecha de apertura y se la pasa a la clase ConsultaTPV para que la almacene en la base de datos. TPVController +AñadirProducto() AbrirCaja Caja +fechaApertura +fechaCierre +fondoCaja AbrirCajaController +crearCaja() ConsultaTPV +saveCaja() +saveVenta() 5. Desarrollo del trabajo 84 5.4.3.6 Realizar venta/devolución Esta funcionalidad al igual que la anterior pertenece al módulo de TPV. El controlador principal muestra la interfaz Venta donde se introducen los productos que se van a vender y los oportunos descuentos (en caso de haberlos). Tras esto, el controlador de la interfaz VentaController instancia la clase Venta con los productos en cuestión y sus respectivos descuentos. A continuación TPVController muestra la interfaz FinalizarVenta, donde la empleada introduce el dinero entregado por el cliente. El controlador FinalizarVentaController actualiza la clase Venta con el dinero entregado y finalmente le pasa dicha Venta a la clase ConsultaTPV para que la almacene en la base de datos. ConsultaTPV +saveCaja() +saveVenta() TPVController +AñadirProducto() TPV FinalizarVenta FinalizarVentaController +ActualizaImporteEntregado() Venta +fecha 5. Desarrollo del trabajo 85 5.4.3.7 Cerrar caja Dicha funcionalidad es muy parecida a la de abrir caja. El controlador principal muestra al usuario la interfaz Cerrarcaja, donde se introducen los datos del dinero que se encuentra en el cajón de efectivo (tarjetas, metálico, vales, etc.). Tras introducirlos, el controlador CerrarCajaController actualiza dichos datos en la Caja abierta previamente y se lo pasa a la clase ConsultaTPV para que lo actualice en la base de datos. ConsultaTPV +saveCaja() +saveVenta() TPVController +AñadirProducto() TPV FinalizarVenta FinalizarVentaController +ActualizaImporteEntregado() Venta +fecha 5. Desarrollo del trabajo 86 5.4.4 Diagramas de secuencia Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. El diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos. En dicho trabajo expondremos los diagramas de secuencia de los casos de uso especificado con anterioridad. 5.4.4.1 Crear pedido El siguiente diagrama representa un diagrama de secuencia para el caso de uso ‘Crear pedido’ donde se describe paso a paso como se realiza el caso de uso, los objetos que intervienen y las llamadas que se realizan. Dicho caso de uso comienza cuando un usuario de administración desea crear un nuevo pedido, que lo hará mediante la función clickNuevoPedido(), es ahí cuando se le muestran todos los pedidos que están en construcción y en caso de querer comenzar uno nuevo cliquea en crear pedido lanzando la función clickCrearPedido(). En entonces cuando comienza con la creación del pedido y tras concluirlo se lanza la función crearPedido() para generar la clase correspondiente y finalmente ConsultaAdministracion lo almacena en la base de datos con la función savePedido(). A continuación si todo el proceso ha finalizado con éxito se envían las confirmaciones hasta que se le muestra al usuario de administración que el pedido ha sido creado con éxito. : ListaPedidoConstruccionController : AdministracionController : CrearPedidoController : ConsultaAdministracion : Usuario de administración 1 : clickNuevoPedido() 2 : clickCrearPedido() 3 : crearPedido() 4 : savePedido() 5 : sendConfirmation() 6 : sendConfirmation() 7 : sendConfirmation() 8 : showConfirmation() 5. Desarrollo del trabajo 87 5.4.4.2 Crear albarán El caso de uso crear ‘Crear albarán’ empieza cuando un usuario de almacén cliquea en ‘Nuevo albarán’ y se le muestran los albaranes en construcción. Una vez en dicha interfaz se pulsa sobre el botón ‘crear’ y se lanza la función clickCrearAlbarán() que muestra otra interfaz donde se solicita toda la información necesaria para la creación del mismo. Cuando todos los datos están introducidos, el controlador de dicha interfaz lanza la función crearAlbaran() para generarlo. Finalmente ConsultaAlmacen lo almacena en la base de datos con saveAlbaran() y se mandan los mensajes de confirmación correspondientes. : Usuario de almacén : AlmacenController : ListaAlbaranesConstruccionController : CrearAlbaranController : ConsultaAlmacen 1 : clickNuevoAlbaran() 2 : clickCrearAlbaran() 3 : crearAlbaran() 4 : saveAlbaran() 5 : sendConfirmation() 6 : sendConfirmation() 7 : sendConfirmation() 8 : showConfirmation() 5. Desarrollo del trabajo 88 5.4.4.3 Iniciar sesión ‘Iniciar sesión’ comienza cuando un usuario no logueado accede al cualquier módulo del soporte informático de la empresa. Es aquí cuando mediante una interfaz se le solicita el usuario y la contraseña. Al introducirlos ha de pulsar sobre el botón ‘entrar’ que lanza la función crearUsuario(). Dicho usuario es verificado por la clase ConsultaComun con la función verificaUsuario(). Finalmente se le muestra al usuario no logueado si los datos son correctos o no. : Usuario no logueado : LoginController : ColsultaComun 1 : crearUsuario() 2 : verificaUsuario() 3 : sendResponse() 4 : showResponse() 5. Desarrollo del trabajo 89 5.4.4.4 Abrir caja Dicho caso de uso empieza cuando una empleada pulsa sobre el botón ‘abrir caja’ es entonces cuando se lanza la función clickAbrirCaja() que muestra la interfaz que solicita el fondo de caja para generar la misma. Cuando se ha introducido el fondo de caja y se pulsa ‘ok’ se lanza la función crearCaja() para generarla y finalmente la clase ConsultaTPV la almacena con la función saveCaja(). Para concluir se le muestra a la empleada que la caja ha sido abierta con éxito. : Empleada : TPVController : ConsultaTPV : AbrirCajaController 1 : clickAbrirCaja() 2 : crearCaja() 3 : saveCaja() 4 : sendConfirmation() 5 : sendConfirmation() 6 : showConfirmation() 5. Desarrollo del trabajo 90 5.4.4.5 Realizar venta ‘Realizar venta’ comienza cuando la empleada añade productos en la tabla de venta. Dicha acción lanza la función añadirProducto(). Cuando concluye pulsa sobre el botón ‘finalizar venta’ y le muestra la interfaz para introducir el importe entregado mediante la función clickFinalizarVenta(). Finalmente la clase ConsultaTPV almacena la venta con la función saveVenta() y confirma que la venta ha sido almacenada con éxito. : Empleada : TPVController : FinalizarVentaController : ConsultaTPV 1 : añadirProducto() 2 : clickFinalizarVenta() 3 : saveVenta() 4 : sendConfirmation() 5 : sendConmirmation() 6 : showConfirmation() 5. Desarrollo del trabajo 91 5.4.4.6 Cerrar caja ‘Cerrar caja’ es muy similar al caso de uso ‘abrir caja’. Comienza cuando una empleada pulsa sobre el botón ‘cerrar caja’ que se lanza la función clickCerrarCaja() y a consecuencia de esto se muestra la interfaz para cerrar la misma. Cuando se introducen los datos oportunos en la interfaz, la clase ConsultaTPV almacena la caja con la función saveCaja() y se le confirma a la empleada el éxito del proceso. : Empleada : CerrarCajaController : TPVController : ConsultaTPV 1 : clickCerrarCaja() 2 : cerrarCaja() 3 : saveCaja() 4 : sendConfirmation() 5 : sendConfirmation() 6 : showConfirmation() 5. Desarrollo del trabajo 98 5.6 PRUEBAS Para la fase de pruebas 21 de dicho software se ha empleado pruebas dinámicas. Es decir, pruebas que para su ejecución requieren la ejecución de la aplicación. El objetivo de las pruebas no es asegurar la ausencia de defectos en un software, únicamente puede demostrar que existen defectos en el software. El objetivo de esta fase es diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo. Las características de una buena prueba son: - Una buena prueba debe centrarse en dos objetivos: 1) probar si el software no hace lo que debe hacer, y 2) probar si el software hace lo que no debe hacer. - Una buena prueba no debe ser redundante. El tiempo y los recursos son limitados, así que todas las pruebas deberían tener un propósito diferente. - Una buena prueba debería ser la “mejor de la cosecha”. Esto es, se debería emplear la prueba que tenga la más alta probabilidad de descubrir una clase entera de errores. - Una buena prueba no debería ser ni demasiado sencilla ni demasiado compleja, pero si se quieren combinar varias pruebas a la vez se pueden enmascarar errores, por lo que en general, cada prueba debería realizarse separadamente. La fase de pruebas de este proyecto se basó en dos procesos. Un primer proceso de pruebas empleando una técnica de caja blanca, para solventar la mayor parte de defectos y finalmente una técnica de caja negra para asegurarnos el correcto funcionamiento del software 5.6.1 Técnica de caja blanca Dicha técnica se basa en un minucioso examen de los detalles procedimentales del código a evaluar, por lo que es necesario conocer la lógica del programa. En nuestro caso se generaron pruebas unitarias para cada clase de las entidades existentes utilizando la librería JUnit. JUnit es un conjunto de bibliotecas creadas por Erich Gamma y Kent Beck que son utilizadas en programación para hacer pruebas unitarias de aplicaciones Java. JUnit es un conjunto de clases (framework) que permite realizar la ejecución de clases Java de manera controlada, para poder evaluar si el funcionamiento de cada uno de los métodos de la clase se comporta como se espera. Es decir, en función de algún valor de entrada se evalúa el valor de retorno esperado; si la clase cumple con la especificación, entonces JUnit devolverá 21 http://es.wikipedia.org/wiki/Pruebas_de_software 5. Desarrollo del trabajo 99 que el método de la clase pasó exitosamente la prueba; en caso de que el valor esperado sea diferente al que regresó el método durante la ejecución, JUnit devolverá un fallo en el método correspondiente. 5.6.2 Técnica de caja negra Tras la realización de las pruebas unitarias y verificar que todo funcionaba correctamente se empleó una técnica de caja negra. Dicha técnica de pruebas consiste en realizar pruebas sobre la interfaz del programa a probar, entendiendo por interfaz las entradas y salidas de dicho programa. Al no ser necesario conocer la lógica del programa, únicamente la funcionalidad que debe realizar dicha prueba. Esta consistió en poner en explotación dicho software en un entorno real (es decir, en una tienda de la empresa “Galerías Lorens”). Gracias a esta última prueba se pudieron perfeccionar pequeños defectos de la interfaz gráfica y también verificar que el software cumplía con todas las necesidades básicas de una sucursal. 6. Conclusiones y trabajo futuro 101 6 CONCLUSIONES Y TRABAJO FUTURO A continuación se expondrán las conclusiones tras este trabajo fin de grado y finalmente el trabajo futuro. 6.1 CONCLUSIONES Primeramente comentar que estoy muy orgulloso del trabajo desarrollado. No sólo por el resultado del trabajo, sino también por todo lo que me ha aportado la realización e implementación del mismo. Hay que tener en consideración que el desarrollo e implementación de todas estas tecnologías nombradas en la memoria conllevan también el aprendizaje de su uso. Considero que las tecnologías aprendidas me han sido de gran ayuda, tanto para dicho trabajo como para posteriores proyectos. Asimismo, se consideran alcanzados de forma exitosa los objetivos académicos planteados, utilizando conocimiento de entre otras asignaturas: - Sistemas operativos - Ingeniería del Software - Seguridad en los Sistemas de Información - Bases de Datos - Tecnologías de los Sistemas de Información Para finalizar con estas conclusiones, mencionar que gracias a este trabajo también he podido lograr mi objetivo personal, el ser capaz de realizar un software de gestión que abarcara lo básico para poderse poner en explotación en un entorno real. 6.2 TRABAJO FUTURO A pesar de considerar el material desarrollado como muy satisfactorio siempre es posible realizar mejoras sobre él. De esta forma, se proponen las siguientes mejoras y posibles líneas de desarrollo: - Realización del resto de funcionalidades de la lista de características: Debido al tiempo disponible para el desarrollo del trabajo fin de grado no ha sido posible realizar todas las funcionalidades sugeridas por el cliente, no obstante se realizaron las más importantes para el mismo. - Ampliación de la funcionalidad de los módulos desarrollados: Los módulos desarrollados cuentan con lo básico, no obstante, existen más funcionalidades no desarrolladas hasta el momento. 6. Conclusiones y trabajo futuro 102 - Mejora de las interfaces gráficas. - Desarrollo de un módulo de gestión del software: Necesario para crear nuevos usuarios, añadir nuevas tiendas, editar permisos, etc. Actualmente se realiza mediante la modificación de la base de datos. - Sistema de ayuda: Incorporar sistemas de ayuda en la aplicación, como por ejemplo, vídeos demostrativos de cada funcionalidad. - Sistema de mantenimiento: Desarrollar un sistema que realice copias de seguridad (backup) periódicamente de la base de datos. A. Competencias 103 A. COMPETENCIAS A continuación se expondrán las competencias cubiertas en el presente trabajo, así como una breve explicación de cómo fueran cubiertas. A.1 CII01 Capacidad para diseñar, desarrollar, seleccionar y evaluar aplicaciones y sistemas informáticos, asegurando su fiabilidad, seguridad y calidad, conforme a principios éticos y a la legislación y normativa vigente. En dicho trabajo final de carrera se ha diseñado, desarrollado, seleccionado y evaluado las aplicaciones y sistemas informáticos que garanticen la fiabilidad, seguridad y calidad del mismo. Además todo se ha desarrollado conforme a los principios éticos y a la legislación y normativa vigente. A.2 CII02 Capacidad para planificar, concebir, desplegar y dirigir proyectos, servicios y sistemas informáticos en todos los ámbitos, liderando su puesta en marcha y su mejora continua y valorando su impacto económico y social. Esta competencia se ha visto satisfecha a lo largo del todo el trabajo. Cumpliendo con el liderado de su puesta en marcha y su mejora continua en la fase de prueba y valorando su impacto económico y social en el apartado de aportaciones del mismo. A.3 CII04 Capacidad para elaborar el pliego de condiciones técnicas de una instalación informática que cumpla los estándares y normativas vigentes. Pliego de condiciones técnicas de una instalación informática que cumpla los estándares y normativas vigentes. A. Competencias 104 A.3.1 Expositivo El soporte informático para una pyme (pequeña y mediana empresa) ha sido siempre una cuenta pendiente en muchas de ellas, o bien, una mala experiencias para muchas otras. Motivos como: somos expertos en usar programas informáticos”. on mis datos actuales si cambio?” Son la consecuencia de que muchas empresas hoy en día tengan soportes informáticos muy complejos y con un sinfín de servicios que ni saben usar o por otro lado soportes muy simples que no se ajustan a las necesidades del cliente. El objetivo de este proyecto es lograr un punto medio entre la complejidad y la simpleza intentando abarcar todas las ventajas de ambos extremos. A.3.2 Objeto del contrato El presente pliego tiene por objeto la contratación de los servicios ofrecidos por dicho proyecto para el soporte informático para pymes especializadas en el comercio textil. El pliego definirá las prescripciones técnicas para conseguirlo. A.3.3 Ámbito geográfico El ámbito geográfico en que se prestará el servicio será en España A.3.4 Confidencialidad El adjudicatario quedará obligado al cumplimiento de lo dispuesto en la Ley orgánica 15/1999 de 13 de Diciembre, de Protección de Datos de Carácter Personal y sus disposiciones de desarrollo. La presente Ley Orgánica tiene por objeto garantizar y proteger, en lo que concierne al tratamiento de los datos personales, las libertades públicas y los derechos fundamentales de las personas físicas, y especialmente de su honor e intimidad personal y familiar. A. Competencias 105 A.3.5 Transferencia tecnológica Durante la contratación de dichos servicios se le facilitará toda la información necesaria a la empresa solicitante, así como las tecnologías requeridas para la total explotación de los servicios prestados. De esta manera dispondrán de un pleno conocimiento para resolver eventuales problemas que puedan plantearse y de las tecnologías, métodos y herramientas utilizadas para resolverlos. A.3.6 Documentación La empresa contratante ha de poseer toda la documentación necesaria, que incluye tanto el manual de usuario como el mantenimiento. Por lo tanto, es necesario que exista una documentación adecuada para poder llevar a cabo el soporte de la aplicación sin necesidad de los conocimientos del creador. A.3.7 Entrega El sistema se considerará como entregado en el momento de integración y puesta en marcha en el entorno de producción. Todo ello, junto con la documentación exigida. A.3.8 Especificaciones técnicas El sistema ha de poder ser integrado en cualquier ordenador (independientemente del sistema operativo), por tanto se ha de desarrollar en Java. A.3.9 Fiabilidad Como se aclara en el CII01 es soporte informático ha de asegurar la fiabilidad, seguridad y calidad, conforme a principios éticos y a la legislación y normativa vigente. A.3.10 Metodología y aseguramiento de la calidad Ni se exige ni se impone ninguna metodología a seguir. A.3.11 Propiedad del resultado A. Competencias 106 Todos los documentos como sistema resultante son propiedad del desarrollador. Las empresas que contraten los servicios tienen el usufructo de los mismos, careciendo de estos una vez finalizado el periodo de contratación. A.3.12 Organización del trabajo La organización del trabajo queda en manos del adjudicatario del proyecto. No se especifica ninguna organización en concreto. No obstante, esto no exime al mismo del correcto cumplimiento de dicho pliego. A.3.13 Plazo de Ejecución El plazo máximo de entrega de dicho proyecto será de 2 meses, siendo la fecha inicial el día de firma del contrato. Se considera entregado el proyecto una vez completado todos los requisitos descritos en dicho pliego. A.3.12 Penalizaciones Cualquier incumplimiento de plazos de entrega, conllevará una penalización del 0,001% por cada día natural de incumplimiento sobre el precio del contrato. A.4 CII18 Conocimiento de la normativa y la regulación de la informática en los ámbitos nacional, europeo e internacional. La competencia CII08 ha sido cubierta con el apartado de normativa y legislación, donde se exponen todas las normativas, leyes y licencias que afectan a dicho proyecto, demostrando así el conocimiento de la normativa y la regulación de la informática en los ámbitos nacional, europeo e internacional. A.5 TFG01 Ejercicio original a realizar individualmente y presentar y defender ante un tribunal universitario, consistente en un proyecto en el ámbito de las tecnologías específicas de la Ingeniería en Informática de naturaleza profesional en el que se sinteticen e integren las competencias adquiridas en las enseñanzas. A. Competencias 107 Esta competencia se alcanza gracias a la completa realización de este Trabajo de Fin de Grado, abarcando todos los ámbitos dentro de las tecnologías específicas de la Ingeniería Informática C. Manual de usuario 114 En caso de editar, se muestra una interfaz similar, pero con los datos del fabricante que se desea modificar: En caso de pulsar “Eliminar” se procederá a la eliminación del fabricante seleccionado (hay que tener en cuenta que no se permite eliminar un fabricante si existe algún pedido relacionado con él). Y finalmente, “Seleccionar” que seleccionaría al fabricante seleccionado para seguir con la realización del pedido. C. Manual de usuario 115 Temporadas Al pulsar sobre temporadas se muestra la siguiente interfaz: Dicha interfaz te permite crear una nueva temporada especificando el nombre y pulsando sobre el botón “Añadir”. También se permite: - Seleccionar: se selecciona la temporada indicada para seguir con el pedido. - Desactivar: dicha funcionalidad permite que una temporada no se vuelva a mostrar más (útil en caso de temporadas pasadas que no se requerirán mas) - Eliminar: permite eliminar la temporada seleccionada (sólo si dicha temporada no pertenece a ningún pedido). C. Manual de usuario 116 Realizar pedido Una vez que se ha introducido todos los datos solicitados te pulsa sobre el botón “Empezar pedido” y se muestra la siguiente interfaz: Esta interfaz permite las siguientes funcionalidades: - Modificar los datos introducidos hasta ahora. - Cambiar el estado del pedido - Eliminar el pedido C. Manual de usuario 117 - Guardar pedido: el pedido se almacena en la base de datos y en caso de que el estado sea “CREACION” se añadirá a la lista de pedidos en construcción. En caso de que sea “Abierto” se añadirá a la lista de seguimiento de pedidos. - Quitar producto: se elimina el producto seleccionado del pedido - Añadir Producto: permite añadir productos al pedido. Añadir producto Este es la funcionalidad principal a la hora de realizar un producto, “Añadir producto”. Dicha interfaz permite de una manera sencilla, rápida y organizada añadir productos al pedido. Se especifica el modelo, color, género, tipo, familia, PVP, talla, talla int., cantidad y precio costo del producto y se pulsa sobre “add” (botón del signo +). A continuación, únicamente se ha de especificar la talla y color para seguir añadiendo productos del mismo modelo, permitiendo así una manera rápida de añadir productos. A continuación se explicará con más detalle el significado de cada parámetro que se solicita: - Modelo: referencia que distingue un producto de otro. Todos los productos iguales donde lo único que cambia es el color y la talla poseen el mismo modelo. C. Manual de usuario 118 - Color: color del producto, normalmente los fabricantes emplean un número de 3 dígitos para su referencia. - Género: género al que va destinado el producto a añadir. - Tipo: especifica el tipo de producto (textil, perfumería, baño, complemento, etc.). - Familia: detalla aún más el tipo seleccionado (dentro de textil encontramos polo, sueter, chaqueta, etc.). - PVP: porcentaje por el que se desea multiplicar el precio de costo para calcular el precio de venta (normalmente se emplea un 240). - Talla: talla que se especifica en la etiqueta del producto. - Talla int. (talla interna): cada fabricante trabaja con un formato de talla distinto (italiano, español, estándar, etc.) por lo que se almacena el tallaje empleado en la empresa para así tener una estandarización en todos los productos. - Cant. (cantidad): cantidad a añadir - P. costo (precio costo): precio costo del producto. Finalmente cuando todos los productos de un modelo están añadidos, se pulsa “Añadir” y se prosigue con el siguiente modelo. Modificar pedido Al pulsar modificar pedido, se accede a la misma interfaz de crear pedido, pero con los datos del pedido seleccionado. Eliminar pedido Se procede a la eliminación del pedido seleccionado. C. Manual de usuario 119 Seguir pedidos Al pulsar sobre “Seguir Pedidos” se muestran los pedidos que se encuentran en estado “ABIERTO”. Es decir, aquello pedidos que aún no se han recibido la mercancía o no están controlados. Dicha interfaz únicamente te permite “Ver seguimiento”. C. Manual de usuario 120 Ver seguimiento Ver seguimiento permite informarse acerca del estado de cada pedido. Con dicha funcionalidad se puede observar las cantidades pedidas de cada producto, así como las llegadas hasta el momento. Además de las cantidades se puede ver los costes del pedido, la suma del precio de venta, etc. Cuando se crea oportuno cerrar el pedido, únicamente se ha de pulsar sobre “Cerrar Pedido”, para que este pase a estado cerrado y se añada en la lista de pedidos realizados. C. Manual de usuario 121 C.2.2 Área de almacén El área de almacén, al igual que el de administración, muestra una interfaz de inicio de sesión para acceder a él. Una vez accedido a él, se muestra la siguiente interfaz principal: Nuevo albarán C. Manual de usuario 122 Al cliquear en nuevo albarán, se listan los albaranes que están en fase de construcción: Al igual que en el área de administración, se puede “Crear”, “Modificar” y “Eliminar” albaranes. Crear albarán Al pulsar sobre “crear”, se muestra una primera interfaz donde se solicita el pedido al que va a pertenecer el albarán, la fecha de recepción y el coste del transporte: C. Manual de usuario 123 Tras introducir los datos, se pulsa sobre el botón “Empezar albarán” y prosigue con la siguiente interfaz: En dicha interfaz se lista una plantilla de lo solicitado en el pedido en cuestión. Es aquí donde hay que buscar cada producto recibido, añadir su respectivo código de barras y cantidad. Para facilitar dicha búsqueda se ha desarrollado un filtro y para un mayor rendimiento, cuando se introduce un código de barras a un producto, la cantidad se actualiza a uno automáticamente. En caso de querer añadir un producto que se encuentre en la plantilla, se posee la funcionalidad “Añadir Producto” la cual se ha explicado en el apartado anterior. Finalmente, al igual que en realizar pedido, se permite guardar el pedido, para poder continuarlo en cualquier otro momento, eliminar y concluir con el mimo con el botón “Terminar albarán”. Modificar albarán Semejante a crear albarán, pero partiendo del albarán seleccionado. Eliminar albarán Permite eliminar el albarán seleccionado. C. Manual de usuario 130 Ver existencias Ver existencias permite a las empleadas conocer la cuantía de un producto en las distintas sucursales de la empresa. Esta funcionalidad permite seleccionar las tiendas en las que se desea realizar la búsqueda, así como utilizar un filtro para concretar un producto en concreto, un color, modelo, etc. C. Manual de usuario 131 Ver ventas Para acceder a dicha interfaz es necesario tener el permiso de supervisor de ventas. Dicha interfaz permite ver las ventas durante un rango de fechas en las sucursales seleccionadas. Además te informa del sumatorio de las mismas. Bibliografía 132 BIBLIOGRAFÍA  [1] Sistema de planificación de recursos empresariales. http://es.wikipedia.org/wiki/Sistema_de_planificaci%C3%B3n_de_recursos_empresariales  [2] Página oficial de OpenERP. https://www.openerp.com/  [3] Página oficial de OpenBravo. http://www.openbravo.com/es  [4] Página oficial de Microsoft Dynamic CRM. http://www.microsoft.com/eses/dynamics/default.aspx  [5] Página oficial de SAP. http://global.sap.com/spain/index.epx  [6] Página oficial de Verial. http://www.verialsoft.es/  [7] Página oficial de Hibernate. http://www.hibernate.org/  [8] Página oficial MySQL. http://www.mysql.com/  [9] Página oficial Java. http://www.java.com/es/  [10] Página oficial Netbeans. https://netbeans.org/  [11] Página oficial JavaFX Scene Builder. http://www.oracle.com/technetwork/java/javafx/tools/index.html  [12] Página oficial StarUML. http://staruml.sourceforge.net/en/  [13] Página oficial Microsoft Word. http://office.microsoft.com/es-es/word/  [14] Ordenador portátil Lenovo Z500. http://shop.lenovo.com/es/es/laptops/ideapad/zseries/z500/  [15] Impresora térmica SUP58T2. http://www.sunphor.com/index.php/product_detail_id_17.html  [16] Impresora Canon i-SENSYS LBP62. http://www.canon.es/For_Home/Product_Finder/Printers/Laser/iSENSYS_LBP6020/index.aspx  [17] Página oficial de JavaFX. http://docs.oracle.com/javafx/  [18] Librería Dialogs. http://edu.makery.ch/blog/2012/10/30/javafx-2-dialogs/ Bibliografía 133  [19] Librería JBarcodeBean. http://jbarcodebean.sourceforge.net/intro.html  [20] Librería DatePicker. http://edu.makery.ch/blog/2013/01/07/javafx-date-picker/  [21] Pruebas de software. http://es.wikipedia.org/wiki/Pruebas_de_software  [22] GNU General Public License. http://es.wikipedia.org/wiki/GNU_General_Public_License  [23] LEY ORGÁNICA 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal. http://www.boe.es/boe/dias/1999/12/14/pdfs/A43088-43099.pdf  [24] B.3 R.D.L, 1/1996 LEY DE PROPIEDAD INTELECTUAL. http://www.mcu.es/propiedadInt/docs/RDLegislativo_1_1996.pdf  [25] Ivar Jaconson, Grady Booch y James Rumbaugh, El proceso unificado de desarrollo de software, Addison Wesley, 2000