Proyecto realizado por el alumno/a: Alberto Gutiérrez García. Fdo.: Alberto Gutiérrez García Fecha: 01/ 09/ Autorizada la entrega del proyecto

Proyecto realizado por el alumno/a: Alberto Gutiérrez García Fdo.: Alberto Gutiérrez García Fecha: 01/ 09/ 2011 Autorizada la entrega del proyecto EL DIRECTOR DEL PROYECTO Alfonso Villar Chicharro Fdo.: Alfonso Villar Chicharro Fecha: 01/ 09/ 2011 Vº Bº del Coordinador de Proyectos Eduardo Alcalde Lancharro Fdo.: Eduardo Alcalde Lancharro Fecha: 01/ 09/ 2011

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO TÉCNICO EN INFORMÁTICA DE SISTEMAS SISTEMA INTEGRAL DE GESTIÓN DE GRANDES SUPERFICIES Autor: Alberto Gutiérrez García Director: Alfonso Villar Chicharro Madrid Septiembre de 2011

Agradecimientos Debo dar las gracias a mi familia, ya que sin su ayuda no podría haber llegado hasta aquí. Y dedico este proyecto a todas aquellas personas que de una manera u otra me han ayudado, y han estado a mi lado durante los años de universidad.

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERÍA TÉCNICA EN INFORMÁTICA DE SISTEMAS SISTEMA INTEGRAL DE GESTIÓN DE GRANDES SUPERFICIES AUTOR: ALBERTO GUTIÉRREZ GARCÍA DIRECTOR: ALFONSO VILLAR CHICHARRO UNIVERSIDAD PONTIFICIA COMILLAS ICAI RESUMEN Se conseguirá el desarrollo de una aplicación en entorno web, orientada a la gestión y control de recursos, en este caso, clientes, personal, productos y proveedores, relacionados con el negocio. Se pretende que el usuario final sea consciente, mediante la aplicación, de saber en todo momento el estado de su negocio en áreas tan variadas como el turno de trabajo de un empleado hasta el precio unitario del último producto puesto a la venta. Este usuario final será en muchos casos el gerente de la tienda de proximidad, y el acceso a esta cantidad de información influirá de forma directa en las decisiones estratégicas que puedan llegar a tomarse dentro del negocio.

Palabras Clave SISTEMA INTEGRAL DE GESTIÓN DE GRANDES SUPERFICIES Algunos términos que definen el proyecto son: Gestión Web 2.0 Base de datos Toma de decisiones Beneficio Introducción A día de hoy es difícil encontrar una empresa o negocio que no disponga de una herramienta para el tratamiento de la información de manera local, ya sea simplemente para realizar transacciones o para gestionar de forma adecuada la información procedente de los resultados contables del negocio. Con esta herramienta se pretende ir más allá, y cubrir las necesidades de gestión que surgen cuando, por cualquier causa, no se puede estar de forma física en la zona donde se desarrollan las actividades de negocio. Principalmente por este motivo se ha elegido un desarrollo orientado al espacio web, que permite al usuario final desarrollar al menos parte de sus funciones se encuentre, donde se encuentre. Otro punto importante es el ahorro en costes adherido a la impresión de informes, ya que con la aplicación que se pretende desarrollar se podrá acceder a toda esta información en formato digital. Esta manera de actuar aparte de ahorrar costes a la empresa, favorecerá la visión que se tiene de la misma desde el punto de vista del consumidor, ya que una empresa que respeta el medio ambiente es mejor valorada que otra que no lo hace. III

También se ha tenido en cuenta la disminución del tiempo invertido en la toma de decisiones en todos los niveles, repercutiendo a su vez en una ventaja bastante significativa frente al resto de competidores de un mercado tan saturado y competitivo. Revisando el mercado se han encontrado herramientas similares a la que se define en este proyecto, casi todas pertenecientes a grandes marcas franquicia. Sin embargo estas herramientas están destinadas casi exclusivamente a almacenar informes generados por herramientas locales en las centrales de las compañías. Este proyecto se puede dividir en las siguientes partes: Presentación de necesidades, objetivos y requisitos. Diseño y planificación del desarrollo. Valoración y toma de decisión para el desarrollo. Implementación de la aplicación. Resultados Con la realización de este proyecto se ha logrado desarrollar una aplicación robusta y de gran accesibilidad que permite gestionar de forma eficiente los recursos de la empresa, y que facilita la toma de decisiones a todos los niveles. También se puede decir que se han adquirido nuevos conocimientos sobre todo en la etapa de la codificación de la aplicación, ya que se ha tratado de conocer nuevos lenguajes de programación orientados a la programación de soluciones web. Aún así también se han afianzado conocimientos en campos ya estudiados durante la carrera entre los que cabe destacar: Ingeniería del Software, Bases de Datos, Control Informático de Gestión o Estructura de datos. IV

Conclusiones SISTEMA INTEGRAL DE GESTIÓN DE GRANDES SUPERFICIES conclusiones: Una vez terminado el desarrollo del proyecto, se desprenden una serie de Se ha conseguido comprender la organización y la gestión de un negocio de tienda de proximidad. Gracias al punto anterior, se ha conseguido cubrir las necesidades y objetivos que se plantearon al inicio del proyecto. Se han afianzado los conocimientos adquiridos durante los años de carrera, especialmente de asignaturas como Ingeniería del Software, Bases de Datos y Estructura de Datos. Conocimientos que podrán ser usados en futuros proyectos. Se han conseguido nuevos conocimientos relacionados con la seguridad informática, y la gestión de proyectos. Se ha logrado el desarrollo de una aplicación sólida, basada en lenguajes de programación no incluidos en el plan de estudios de la carrera. V

Referencias SISTEMA INTEGRAL DE GESTIÓN DE GRANDES SUPERFICIES [BARR01] Barranco de Areba. Metodología del análisis estructurado de sistemas. Madrid: Publicaciones Universidad Pontificia de Comillas, 2001. Web de descarga y ayuda para las herramientas de desarrollo del software de la aplicación web: [WWW01] http://www.apachefriends.org/es/xampp.html español: Web oficial del distribuidor de componentes informáticos Hewlett Packard, en [WWW02] http://www.hp.es Web oficial del distribuidor de software y herramientas de desarrollo Adobe Systems, en español: [WWW03] http://www.adobe.es JavaScript: Comunidad web de ayuda a la programación, principalmente de PHP, HTML y [WWW04] http://www.desarrolloweb.com VI

Abstract SISTEMA INTEGRAL DE GESTIÓN DE GRANDES SUPERFICIES The means to develop a Web-based application, oriented management and control of resources, in this case, customers, staff, products and suppliers relating to the business. It is intended that the end user is aware, through the application, always know the status of your business in areas as varied as the shift of an employee to the unit price of the latest product offered for sale. The end user will in many cases the store manager of proximity and access to this wealth of information will directly affect the strategic decisions that may come to be in business. Key Words Some terms that define the project are: Management Web 2.0 Database Decision Profits VII

Introduction SISTEMA INTEGRAL DE GESTIÓN DE GRANDES SUPERFICIES Today it is difficult to find a company or business that does not have a tool for processing information locally, either just to make transactions or to manage adequately the information from the financial results of the business. This tool aims to go beyond, and management needs that arise when, for whatever reason, can t be physically available in the area where the business activities develop. Mainly for this reason we have chosen a development oriented web site that allows end users to develop at least part of their duties are, wherever you are. Another important point is the cost savings attached to the printing of reports, since the application to be developed will be able to access all this information in digital format. This course of action other than cost savings to the company, encourage the view we have of it from the standpoint of the consumer, as a company that respects the environment is more valued than another does not. Also taken into account the reduction of time spent on decision making at all levels, affecting in turn a pretty significant advantage against other competitors in a market so saturated and competitive. Reviewing the market similar tools has been found to be defined in this project, almost all belonging to franchise brands. However, these tools are used almost exclusively to store reports generated by local power tool companies. This project can be divided into the following parts: Presentation of needs, objectives and requirements. Design and development planning. Assessment and decision making for development. Implementation of the application. VIII

Results With the completion of this project has developed a robust and highly accessible which enables efficient management of company resources, and facilitates decision-making at all levels. You can also say that they have acquired new skills especially in the stage of coding the application, as it has tried to learn new programming languages oriented programming web solutions. Still have also been secured and studied knowledge in fields during the race among which include: Software Engineering, Databases, Management Information Control and Data Structure. Conclusions Upon completion of the project, it draws several conclusions: It has come to understand the organization and management of store business proximity. Thanks to the above, has managed to cover the needs and goals that were raised at the beginning of the project. We have strengthened the knowledge acquired during the years of career, especially in subjects such as Software Engineering, Databases and Data Structures. Knowledge that can be used in future projects. We have achieved new knowledge related to computer security, and project management. IX

It has succeeded in developing a solid application, based on programming languages not included in the curriculum of the race. References [BARR01] Barranco de Areba. Metodología del análisis estructurado de sistemas. Madrid: Universidad Pontificia de Comillas Publicaciones, 2001. application: Download Web and support for software development tools for the web [WWW01] http://www.apachefriends.org/es/xampp.html Spanish: Official website of the distributor of Hewlett Packard computer parts in [WWW02] http://www.hp.es Official website of the supplier of software and development tools Adobe Systems, in Spanish: [WWW03] http://www.adobe.es Web community for programming assistance, mainly PHP, HTML and JavaScript: [WWW04] http://www.desarrolloweb.com X

Índice 1. Memoria... 1 1.1. Introducción... 2 1.2. Motivación del proyecto... 2 1.3. Objetivos del proyecto... 3 1.4. Metodología de trabajo... 4 1.5. Recursos a utilizar... 5 2. Identificación de necesidades... 7 2.1. Introducción... 8 2.2. Objetivos del sistema... 9 2.3. Alcance del sistema... 10 2.4. Tipología de usuarios... 11 2.5. Restricciones... 12 2.6. Organización y funciones empresariales... 13 2.7. Antecedentes... 13 3. Análisis de requisitos... 15 3.1. Introducción... 16 3.2. Reconocimiento del sistema... 17 3.2.1. Ámbito del sistema... 17 3.2.2. Unidades afectadas en la organización... 18 3.3. Modelo del sistema actual... 19 3.4. Lista de requisitos... 19 3.5. Modelo lógico del nuevo sistema... 48 3.5.1. Nivel contextual... 49 CÓDIGO... 50 TIPO... 50 NOMBRE... 50 DESCRIPCIÓN... 50 3.5.2. Nivel conceptual... 52 CÓDIGO... 53 TIPO... 53 NOMBRE... 53 DESCRIPCIÓN... 53 XI

3.5.3. Explosión de Validación de usuario... 57 CÓDIGO... 57 TIPO... 57 NOMBRE... 57 DESCRIPCIÓN... 57 3.5.4. Explosión de Gestión de Clientes... 60 CÓDIGO... 60 TIPO... 60 NOMBRE... 60 DESCRIPCIÓN... 60 3.5.5. Explosión de Gestión de Proveedores... 62 CÓDIGO... 62 TIPO... 62 NOMBRE... 62 DESCRIPCIÓN... 62 3.5.6. Explosión de Gestión de Personal... 64 CÓDIGO... 64 TIPO... 64 NOMBRE... 64 DESCRIPCIÓN... 64 3.5.7. Explosión de Gestión de Productos... 66 CÓDIGO... 66 TIPO... 66 NOMBRE... 66 DESCRIPCIÓN... 66 3.6. Modelo conceptual de datos... 68 3.7. Diagrama entidad-relación... 74 4. Diseño de la arquitectura técnica... 75 4.1. Diagrama de presentación... 76 4.2. Especificación de componentes básicos... 77 4.3. Planificación del proyecto... 82 5. Diseño externo... 83 5.1. Modelo físico del nuevo sistema... 84 5.1.1. Diseño de entradas y salidas... 84 XII

5.1.2. Modelo lógico de datos... 99 6. Programación... 101 7. Pruebas del sistema... 113 7.1. Plan de pruebas... 114 8. Implantación... 115 9. Conclusiones... 117 10. Bibliografía... 119 11. Anexos... 121 11.1. Valoración económica... 122 XIII

1. Memoria 1

1.1. Introducción Este proyecto surge a partir de las necesidades de gestión de la información que se pueden encontrar en cualquier empresa de venta al por menor. Necesidades que surgen, en mayor medida, por el tiempo que se utiliza en revisar y manejar de forma adecuada todas las funcionalidades de un negocio. De ahí que como Proyecto de Fin de Carrera se haya elegido el desarrollo de una aplicación para la gestión interna de algunos procesos de negocio. Se ha elegido el formato de aplicación web por delante de otros, en primer lugar por la gran accesibilidad que presenta al usuario final, para acceder a los procesos de negocio de la empresa. En segundo lugar, se ha sabido destacar el fácil e intuitivo manejo del interfaz de gestión de recursos que proporciona una aplicación web debido a su estructura de enlaces. Por último, se ha tenido en cuenta la disminución del tiempo invertido en la toma de decisiones, tanto en el nivel táctico como en el nivel operativo. Este hecho repercute en una reducción de los costes en la empresa. Como principal consecuencia a los puntos anteriormente descritos se ha de apreciar una mejora en la gestión integral del negocio y derivado de este como consecuencia última se ha de experimentar un incremento de los beneficios, aumentando las posibilidades de la empresa frente a la competencia. 1.2. Motivación del proyecto Hasta hace relativamente poco tiempo, solo se podía distinguir entre dos formatos claramente diferenciados. Por un lado está el formato del hipermercado, que ha dominado la mayor parte del porcentaje de ventas al público, en mayor medida gracias a un surtido muy extenso 2

y variado. Otra de sus características es el lugar donde se encuentra, normalmente a las afueras de las ciudades, en amplios parques comerciales. Su principal desventaja, no estar diseñado para la compra diaria. En el otro lado de la balanza se sitúa el formato de la tienda de barrio, el pequeño comercio especializado en una reducida gama de productos y establecido dentro de los núcleos urbanos. Este formato es el gran perjudicado al no poder competir en precios con las grandes superficies. Sin embargo es el más cercano a nuestros hogares y por tanto el más accesible. Ya que ambos formatos tienen desventajas importantes es lógico que en los últimos años haya proliferado un nuevo modelo que se sitúa entre ambos. Este nuevo modelo se conoce como tienda de proximidad. Son grandes superficies de venta localizadas dentro de las urbes, que ofrecen un surtido variado, centrado en las necesidades diarias del cliente. Con este nuevo modelo se dispone de un número de usuarios estable al que ir ofreciendo productos nuevos cada día. Los principales precursores del nuevo modelo de tienda de proximidad, a parte de las grandes marcas (Carrefour, Eroski, ), son pequeños empresarios que deciden ampliar su negocio, y con cada negocio surge la necesidad de informatizarlo. Esa necesidad es la se intentará cubrir con la aplicación aquí propuesta. 1.3. Objetivos del proyecto El principal objetivo del proyecto es la creación de una aplicación web que permita al usuario final una perfecta interacción con los procesos de negocio. Esta web debe presentar, con la mayor claridad posible, todo tipo de información, ya sean informes de ventas, stock disponible, fechas de vacaciones, como datos de clientes y proveedores. 3

Con el desarrollo de una web también se conseguirá otro de los objetivos más importantes, una gran accesibilidad a herramientas e información que en otro caso no podrían ser usadas fuera del mismo negocio. 1.4. Metodología de trabajo La metodología elegida para la realización del proyecto ha sido la metodología lineal o en cascada, que se sostiene en los siguientes ciclos: Identificación de necesidades (IDN): Trata de exponer el entorno global del problema en estudio, especificando objetivos y funciones de negocio, perfil de los usuarios finales y restricciones de costes y tiempo. Análisis de requisitos (ARQ): Se intenta alcanzar un conocimiento suficiente del sistema, definiendo necesidades, problemas y requisitos del cliente, mediante la realización del modelo físico y lógico del sistema actual y el modelo lógico del nuevo sistema. Estudio de la arquitectura técnica (DAT): Consiste en definir posibles soluciones que cumplan los requisitos, especificando hardware, software y elementos de comunicaciones necesarios para este fin. Y una vez se elige la solución a seguir, se confecciona la planificación del proyecto. Diseño externo (DEX): Se obtienen el modelo físico del nuevo sistema y el modelo lógico de datos y se define la estrategia para las pruebas y la implantación del sistema. Diseño interno (DIN): Se diseñan los componentes software de la aplicación web: módulos, fases, bases de datos, Se intenta en todo 4

caso seguir un diseño estructurado y modular. En esta fase se inician los primeros planes de pruebas. Programación (PRO): Codificación de los módulos y componentes software. Se realizan las pruebas unitarias de los componentes y se verifica la disponibilidad hardware/software para la instalación. Pruebas del sistema (PRU): Se prueba la funcionalidad, operatividad e integridad del sistema. Se realizan pruebas de encadenamiento, integración, usabilidad, rendimiento, carga y pruebas de aceptación de usuario. Implantación (IMP): Implementación del nuevo sistema en producción real. Se prepara la entrada en producción, y se busca la aprobación final del cliente. Con esta serie de pasos se intenta conseguir una aplicación eficiente y robusta que solvente de forma adecuada los problemas de la empresa. Durante todo el proceso de desarrollo se hará especial hincapié en el diseño de las bases de datos que serán uno de los puntos más importantes dentro de la aplicación. 1.5. Recursos a utilizar En primer lugar, a nivel de recursos hardware, se ha utilizado un ordenador portátil Acer Aspire 5930G, con SO Windows 7 Ultimate x64, para el desarrollo tanto de la aplicación web como de la memoria, y una tableta Advent Vega, con SO Android 2.2 Froyo, para probar el correcto funcionamiento de la aplicación web. Por otro lado, a nivel de recursos software, el paquete de ofimática utilizado ha sido Microsoft Office 2007, destacando Microsoft Word 2007, Microsoft Visio 2007, 5

para la preparación de los DFD s, Microsoft PowerPoint 2007 y Microsoft Project 2007 para la realización de esquemas y la planificación del proyecto. Como software de ayuda en la codificación de la aplicación web se ha utilizado Adobe Dreamweaver CS5, parte del paquete Adobe CS5. Este programa hará de entorno de desarrollo para el código PHP, HTML y JavaScript presente en la aplicación. Una de las ventajas principales es que permite comprobar el diseño final mientras se desarrolla cada módulo de la aplicación. Para la implementación de la base de datos (BD) se ha optado por el uso de una tecnología gratuita y muy extendida como es MySQL, un sistema de gestión de bases de datos relacional, multiusuario y multihilo. Y para gestionar la información dentro de la base de datos se ha utilizado el gestor phpmyadmin, un gestor muy completo con las funcionalidades necesarias para el manejo de los datos del sistema. 6

2. Identificación de necesidades 7

2.1. Introducción En esta etapa del modelo se presenta el problema que se ha de resolver y se plantean las directrices a seguir. Como resultado final se obtiene el Documento de conceptos del sistema. En las diferentes partes del documento se encuentran las necesidades del sistema y la situación actual del negocio en el que se va a intervenir. El documento de conceptos del sistema contiene los siguientes puntos: Objetivos del sistema: Son aquellos objetivos a desarrollar desde el punto de vista empresarial. Alcance del sistema: Define las funciones de negocio que se quiere ver cumplidas dentro de la aplicación. Tipología de usuarios: Presenta el perfil de las personas que van de utilizar la aplicación, los usuarios finales del sistema. Restricciones: Se consideran todas las restricciones que pueda sufrir el proyecto y su desarrollo, ya sean de tipo organizativo, económico o de un cambio en la planificación. Antecedentes: Tanto los motivos por los que se desarrolla el proyecto como si existe algún sistema similar realizado con anterioridad. Es el cliente quien debe marcar los objetivos y necesidades contenidos en el documento de conceptos del sistema, por lo que debe tener conocimientos suficientes sobre la problemática actual del negocio. Cuanto más detallada sea la información que facilita para el desarrollo del sistema, más problemas se evitarán en el futuro. 8

Para la obtención de esta información se suele utilizar como punto de apoyo la técnica de la entrevista, entre el cliente y el jefe de proyecto. 2.2. Objetivos del sistema Son los objetivos de la aplicación que se pretende desarrollar, en este caso la informatización de la mayor parte de las funciones de negocio de una tienda de proximidad o superficie de venta: El objetivo principal es una mejor accesibilidad a informes de todo tipo y un mayor control sobre los procesos del negocio. En principio la empresa dispone de un nivel medio de informatización, ya que cuenta con diversas aplicaciones de escritorio para generar informes, preparar facturas y pedidos y un paquete ofimático para el seguimiento de las ventas y las cuentas de correo electrónico. Con la realización del proyecto se pretende: Unificar la gestión de los puntos descritos anteriormente. Mejorar la calidad de los datos recopilados día a día. Para esto se van a crear bases de datos optimizadas en las que se permita añadir, eliminar y actualizar las unidades de información que contengan. 9

2.3. Alcance del sistema En el alcance del sistema se definen aquellas funciones de negocio que se han de desarrollar para el cumplimiento de los objetivos del sistema. Las funciones que el sistema debe abarcar son las siguientes: Clientes: En este módulo se gestionan todo lo relacionado con los datos de aquellos clientes que decidan darse de alta como tal en la aplicación, y serán beneficiarios de ofertas, promociones y descuentos que se ajusten a su perfil. Cada cliente es único en el sistema y se pueden aplicar tres funciones: Alta de cliente (se añade un nuevo cliente a la BD), Baja de cliente (se elimina al cliente del sistema) y Modificar cliente (se modifican los datos pertenecientes a un cliente ya dado de alta). Productos: Es un módulo destinado a la gestión del inventario disponible para poner a la venta. A cada producto se le asigna un identificador unívoco (código interno) y para cada producto se dispone de su precio de venta al público, su precio de compra, familia de productos a la que pertenece, proveedor o proveedores que lo ofertan, así como aquellos datos derivados de los anteriores, por ejemplo el margen de beneficio. A cada producto se le pueden aplicar las siguientes funciones: Alta de producto (se añade un nuevo producto a las tablas), Baja de producto (se elimina un artículo de la BD) y Modificar producto (se modifican los datos pertenecientes a un producto ya dado de alta). Personal: Módulo dedicado al control de la plantilla. Debe permitir la gestión de los empleados en la medida de lo posible, presentando informes sobre cada empleado, acompañado de su nómina, turnos de trabajo, vacaciones, y posibles incidencias. Cada empleado contratado por la empresa debe tener un identificador unívoco y 10

puede sufrir: Alta de empleado (se añade un nuevo empleado a la BD), Baja de empleado (se elimina al empleado del sistema) y Modificar empleado (se modifican los datos pertenecientes a un empleado ya dado de alta). Proveedores: Módulo encargado de la gestión de los proveedores de los que dispone la empresa para abastecerse. Cada proveedor posee un identificador unívoco. Alta de proveedor (se añade un nuevo proveedor a la BD), Baja de proveedor (se elimina al proveedor del sistema) y Modificar proveedor (se modifican los datos pertenecientes a un proveedor ya dado de alta). Informes: El sistema debe ser capaz de presentar la información que se requiera de cada uno de los módulos (Clientes, Productos, Personal y Proveedores), con la mayor claridad y precisión posibles para conseguir una mejor gestión de los procesos de negocio y por tanto un mayor control sobre el negocio. 2.4. Tipología de usuarios En esta parte del Documento de conceptos del sistema se presenta el perfil de él/los usuarios que van a estar en contacto directo con la aplicación. Para este sistema se pueden encontrar dos tipos de usuarios finales: Por un lado está el usuario al que está dirigido en mayor medida la aplicación, que es el gerente de la empresa. Suelen ser varones de mediana edad de entre 30 y 55 años, con una extensa experiencia en su sector y que exigirán informes precisos y claros en el menor tiempo posible. 11

También se debe tener en cuenta a otro tipo de usuario final, el encargado de sección o encargado de tienda que utilizará la aplicación en menor medida y como un soporte excepcional a las herramientas de las que dispone en el día a día. Suelen ser personas de ambos sexos con edades de entre 25 y 40 años, con poca formación académica. 2.5. Restricciones En este apartado se tratan los puntos críticos que se pudieran encontrar a la hora de realizar el proyecto. A continuación se detallan los puntos más significativos: Se debe tener en cuenta los requisitos de hardware y software que necesita la aplicación. Para que esto no suponga un desembolso demasiado grande para la empresa, se intentará reciclar en la medida de lo posible los recursos ya existentes en la empresa. Para una mayor confianza en el sistema, todos los datos relativos a personas o entidades se trataran según la legislación vigente. Y si existiera alguna incidencia con los mismos, se seguirían los métodos más aconsejables para resolver el problema. Ya que la aplicación está destinada a distintos tipos de usuarios debe ser intuitiva y fácil de manejar. La aplicación web debe ser concebida como una herramienta de ayuda a la gestión de los procesos de negocio. En principio el acceso a la aplicación está restringido al responsable de la tienda. 12

El proyecto debe ser terminado y presentado en septiembre de 2011. 2.6. Organización y funciones empresariales Debido a que en este tipo de negocio no existe un modelo único o estándar para la organización de la empresa, se describirán los puestos según las funciones básicas que deberían estar cubiertas en una tienda de proximidad: Gerente: Encargado final del correcto funcionamiento de la tienda. Encargado de almacén: Aquella persona que responde por las funcionalidades donde el almacén, y los productos que hay en él, estén implicados. Encargado de sección: Puede haber un encargado por sección o un encargado general que se ocupe de toda la zona de venta. Personal administrativo: Aquellas personas que controlan la contabilidad de la empresa, los recursos humanos, Personal de servicio: seguridad, reponedores, cajeros, carniceros, mozos de almacén, ). 2.7. Antecedentes En el sistema actual de la empresa se dispone de varias aplicaciones de escritorio que controlan ventas, stock y ciclos de aprovisionamiento. Así como documentos de texto y hojas de cálculo para la gestión del personal, los listados de clientes con promociones y la consulta de datos globales de beneficios. Esto supone un enorme gasto de tiempo y recursos a la hora de buscar una determinada información en varios programas o ficheros de datos. 13

Otro de los problemas del sistema actual es la portabilidad y disponibilidad de información relativa a ciertos procesos de negocio. En muchos casos es incómodo o casi prohibitivo imprimir largos listados de productos cuyos parámetros pueden cambiar diariamente. Por esto se puede justificar la creación de una aplicación web que sirva como plataforma para aliviar ciertos puntos de los procesos de negocio de la empresa. 14

3. Análisis de requisitos 15

3.1. Introducción En esta fase del desarrollo se pretende alcanzar un conocimiento suficiente del sistema, definiendo las necesidades, problemas y requisitos del usuario, para expresarlo posteriormente mediante modelos de procesos y de datos. Para la correcta realización de esta etapa, se deben detallar tanto los procesos del sistema actual del negocio como la lista de requisitos que debe cumplir el nuevo sistema. Con todo esto al final de la etapa se conseguirá un modelo del nuevo sistema junto con el modelo de datos. Esta fase consta de los siguientes puntos: Reconocimiento del sistema: Se deben reconocer los elementos del sistema de la misma manera que los reconoce el usuario del sistema. Para este paso se tiene en cuenta el Documento de conceptos del sistema. Modelo del sistema actual: Es la representación gráfica de los elemento que componen el sistema actual, teniendo en cuenta procesos, flujos de datos y entidades externas relacionadas con el sistema. Lista de requisitos: Con la información obtenida mediante el formato de la entrevista, se confecciona un listado con los requisitos que debe cumplir el modelo del nuevo sistema. Modelo lógico del nuevo sistema: Es la representación gráfica de los elementos que componen el nuevo sistema, describiendo procesos, flujos de datos y entidades externas que puedan intervenir en el nuevo sistema. 16

Modelización de datos: Se presentan las tablas de datos que maneja el sistema, debidamente normalizados. Diagrama de entidad-relación: Como su nombre indica, en este paso se muestra la representación gráfica de las relaciones existentes entre las distintas tablas de datos 3.2. Reconocimiento del sistema En este apartado se define el ámbito del sistema y las unidades de la organización afectadas. 3.2.1. Ámbito del sistema El sistema tiene como finalidad unificar y automatizar una serie de procesos de negocio, que actualmente se desarrollan con diferentes herramientas, descritos a continuación: Gestión de Clientes: Permite la gestión y control de los datos relativos a los clientes. Puede llevar a cabo las siguientes funciones: Dar de alta a clientes, eliminar una instancia de cliente, modificar cualquier atributo relativo a un cliente y posibilitar la consulta de datos sobre un cliente. Gestión de Productos: Permite la gestión y control de los datos relativos a los productos. Puede llevar a cabo las siguientes funciones: Dar de alta un artículo, eliminar una instancia de producto, modificar cualquier atributo relativo a un producto y posibilitar la consulta de datos sobre un artículo. 17

Gestión de Personal: Permite la gestión y control de los datos relativos a los empleados. Puede llevar a cabo las siguientes funciones: Dar de alta a un empleado, modificar los datos de un empleado y posibilitar la consulta de datos sobre el personal. Gestión de Proveedores: Permite la gestión y control de los datos relativos a los proveedores. Puede llevar a cabo las siguientes funciones: Dar de alta a un proveedor, borrar los datos de un proveedor, modificar cualquier atributo relativo a un proveedor y posibilitar la consulta de datos sobre los proveedores. Generación de Informes: Los distintos módulos del sistema deben permitir la generación y consulta de informes sobre los tipos de datos que manejan. 3.2.2. Unidades afectadas en la organización En este apartado se presentan los procesos de la aplicación y las unidades de la organización afectadas por cada uno de ellos: Gestión de Gestión de Gestión de Gestión de Clientes Personal Productos Proveedores Gerente XX XX XX XX Encargado de Almacén Encargado de Sección Personal Administrativo XX XX XX XX XX XX 18

Personal de Servicio XX 3.3. Modelo del sistema actual Debido a la ausencia de un sistema actual unificado y automatizado que lleve a cabo las funciones descritas en anteriores apartados, se omite la descripción del modelo del sistema actual, ya que no transmitiría información relevante. 3.4. Lista de requisitos En esta lista se detallan los requisitos, que por medio del formato de la entrevista, han sido marcados por el cliente, para el nuevo sistema. Según su naturaleza se pueden distinguir los siguientes tipos de requisitos: Funcionales: Se refieren a las funciones propias de los procesos de negocio. Operativos: Están referidos a la operatividad del sistema. Pertenecen a los requisitos no funcionales. Prestaciones: Atienden a funciones adicionales del sistema. Pertenecen a los requisitos no funcionales. Seguridad: Describen aquellos requisitos relacionados con funciones de control y privacidad que pueden ser encontrados en el sistema. Pertenecen a los requisitos no funcionales. Fiabilidad, Integridad y veracidad de la información: Son los requisitos vinculados al control de calidad del producto final. Pertenecen a los requisitos no funcionales. 19

Para la descripción de cada requisito se utiliza el formato de la ficha, que contiene los siguientes campos de datos: Título del Proyecto Nombre del Jefe de Proyecto Fecha Versión del sistema Estado Prioridad Título del requisito Identificador Fuente Categoría Descripción del requisito Medición Beneficios Comentarios/Soluciones sugeridas Documentos relacionados Requisitos relacionados A continuación se detallan todos los requisitos presentes en el sistema. 20

IDENTIFICACIÓN Título del Proyecto: Sistema Integral de Gestión de Grandes Superficies Nombre del Jefe de Proyecto: Alberto Gutiérrez García REQUISITO Fecha: 30/11/2010 Versión: 1.0 Estado/Prioridad: Final/Alta Título del requisito: Gestión de Clientes Identificador: R1 Categoría: Funcional Fuente: Cliente Descripción del requisito: El sistema debe permitir una correcta gestión de datos de clientes, permitiendo altas, bajas y modificaciones sobre los mismos. Se pretende que cada cliente pueda recibir promociones y ofertas adecuadas a su perfil. MEDICIÓN Este requisito es imprescindible para el desarrollo del sistema, por lo que su cumplimiento es obligado. BENEFICIOS El desarrollo de un módulo para la gestión y control de clientes es importante, ya que se mejora el trato a clientes preferenciales que han sido registrados en el sistema. COMENTARIOS/SOLUCIONES SUGERIDAS Para el buen funcionamiento del módulo, también se desarrolla una tabla de datos de clientes, contenida en la BD del sistema. DOCUMENTOS RELACIONADOS Documento de conceptos del sistema. 21

REQUISITOS RELACIONADOS 22

IDENTIFICACIÓN Título del Proyecto: Sistema Integral de Gestión de Grandes Superficies Nombre del Jefe de Proyecto: Alberto Gutiérrez García REQUISITO Fecha: 30/11/2010 Versión: 1.0 Estado/Prioridad: Final/Alta Título del requisito: Gestión de Productos Identificador: R2 Categoría: Funcional Fuente: Cliente Descripción del requisito: El sistema debe permitir una correcta gestión de datos de los artículos, permitiendo altas, bajas y modificaciones sobre los mismos. Se pretende que el usuario tenga acceso total sobre los datos de productos, tanto los que están a la venta como aquellos que han sido retirados temporalmente o aun no están a la venta. MEDICIÓN Este requisito es imprescindible para el desarrollo del sistema, por lo que su cumplimiento es obligado. BENEFICIOS El desarrollo de un módulo de gestión y control de productos (o stock), permite al usuario conocer en cualquier momento, cualquier información relativa a un producto, ya sea su precio unitario, proveedor, COMENTARIOS/SOLUCIONES SUGERIDAS Para el buen funcionamiento del módulo, también se desarrolla una tabla de datos de productos, contenida en la BD del sistema. 23

DOCUMENTOS RELACIONADOS Documento de conceptos del sistema. REQUISITOS RELACIONADOS 24

IDENTIFICACIÓN Título del Proyecto: Sistema Integral de Gestión de Grandes Superficies Nombre del Jefe de Proyecto: Alberto Gutiérrez García REQUISITO Fecha: 30/11/2010 Versión: 1.0 Estado/Prioridad: Final/Alta Título del requisito: Gestión de Personal Identificador: R3 Categoría: Funcional Fuente: Cliente Descripción del requisito: El sistema debe permitir una correcta gestión de datos de los empleados, permitiendo altas, bajas y modificaciones sobre los mismos. Se pretende que el usuario puede acceder a los datos de empleados y consultar cualquier información que necesite, ya sea vacaciones, turnos, horarios, nómina, MEDICIÓN Este requisito es imprescindible para el desarrollo del sistema, por lo que su cumplimiento es obligado. BENEFICIOS El desarrollo de un módulo de gestión y control de personal favorece el seguimiento de los empleados, pudiendo aprovechar de manera más eficiente los recursos humanos de la empresa. COMENTARIOS/SOLUCIONES SUGERIDAS Para el buen funcionamiento del módulo, también se desarrolla una tabla de datos de empleados, contenida en la BD del sistema. 25

DOCUMENTOS RELACIONADOS Documento de conceptos del sistema. REQUISITOS RELACIONADOS 26

IDENTIFICACIÓN Título del Proyecto: Sistema Integral de Gestión de Grandes Superficies Nombre del Jefe de Proyecto: Alberto Gutiérrez García REQUISITO Fecha: 30/11/2010 Versión: 1.0 Estado/Prioridad: Final/Alta Título del requisito: Gestión de Proveedores Identificador: R4 Categoría: Funcional Fuente: Cliente Descripción del requisito: El sistema debe permitir una correcta gestión de datos de los proveedores, permitiendo altas, bajas y modificaciones sobre los mismos. Se pretende que el usuario puede acceder a los datos de proveedores y consultar cualquier información relacionada con estos. MEDICIÓN Este requisito es imprescindible para el desarrollo del sistema, por lo que su cumplimiento es obligado. BENEFICIOS El desarrollo de un módulo de gestión y control de proveedores facilitará la toma de decisiones a la hora de elegir un proveedor u otro en el aprovisionamiento de un determinado producto. COMENTARIOS/SOLUCIONES SUGERIDAS Para el buen funcionamiento del módulo, también se desarrolla una tabla de datos de proveedores, contenida en la BD del sistema. DOCUMENTOS RELACIONADOS Documento de conceptos del sistema. 27

IDENTIFICACIÓN Título del Proyecto: Sistema Integral de Gestión de Grandes Superficies Nombre del Jefe de Proyecto: Alberto Gutiérrez García REQUISITO Fecha: 30/11/2010 Versión: 1.0 Estado/Prioridad: Final/Media Título del requisito: Generar informes Identificador: R5 Categoría: Funcional Fuente: Cliente Descripción del requisito: El sistema debe ser capaz de mostrar consultas y generar informes sobre clientes, productos, personal y proveedores cuando se requiera. Al realizar una consulta el módulo implicado accederá a la tabla correspondiente de la BD y mostrará el contenido pedido por el usuario. MEDICIÓN Este requisito es imprescindible para el desarrollo del sistema, por lo que su cumplimiento es obligado. BENEFICIOS Con la posibilidad de generar consultas e informes se pretende facilitar la toma de decisiones en puntos críticos de los procesos de negocio, y por tanto reducir el tiempo invertido y sus costes añadidos. COMENTARIOS/SOLUCIONES SUGERIDAS DOCUMENTOS RELACIONADOS Documento de conceptos del sistema. 29

IDENTIFICACIÓN Título del Proyecto: Sistema Integral de Gestión de Grandes Superficies Nombre del Jefe de Proyecto: Alberto Gutiérrez García REQUISITO Fecha: 30/11/2010 Versión: 1.0 Estado/Prioridad: Final/Media Título del requisito: Creación de la base de datos del sistema Identificador: R6 Categoría: Operativo Fuente: Cliente Descripción del requisito: Se debe crear una base de datos para almacenar la información que precisa el sistema para un correcto funcionamiento. La base de datos se encontrará en el servidor de la empresa. Esta base de datos cuenta con tablas de clientes, productos, empleados y proveedores, que serán accesibles desde los módulos del sistema. MEDICIÓN La base de datos debe ser accesible en todo momento para los usuarios con permisos. Se controlará que no haya información corrupta, duplicada o sin acceso en las tablas. BENEFICIOS Con la creación de bases de datos se consigue tener disponible una gran cantidad de información. COMENTARIOS/SOLUCIONES SUGERIDAS DOCUMENTOS RELACIONADOS Documento de conceptos del sistema. 31

IDENTIFICACIÓN Título del Proyecto: Sistema Integral de Gestión de Grandes Superficies Nombre del Jefe de Proyecto: Alberto Gutiérrez García REQUISITO Fecha: 30/11/2010 Versión: 1.0 Estado/Prioridad: Final/Media Título del requisito: Gestión de datos de clientes Identificador: R7 Categoría: Operativo Fuente: Cliente Descripción del requisito: El sistema debe permitir el alta, baja y modificación de datos de clientes. Se tendrá especial cuidado en no duplicar información relativa a un campo. Por ejemplo antes de dar de alta a un cliente se comprueba si ya está en la tabla de clientes. Cada instancia de cliente contiene los siguientes campos: ID_Cliente NombreCompleto DNI Dirección Teléfono Email TipoCliente MEDICIÓN Para cada consulta en la tabla se debe verificar el correcto tratamiento de la información. 33

BENEFICIOS Con la optimización de la base de datos se podrán evitar futuras incidencias y fallos en la aplicación. COMENTARIOS/SOLUCIONES SUGERIDAS DOCUMENTOS RELACIONADOS Documento de conceptos del sistema. REQUISITOS RELACIONADOS 34

IDENTIFICACIÓN Título del Proyecto: Sistema Integral de Gestión de Grandes Superficies Nombre del Jefe de Proyecto: Alberto Gutiérrez García REQUISITO Fecha: 30/11/2010 Versión: 1.0 Estado/Prioridad: Final/Media Título del requisito: Gestión de datos de productos Identificador: R8 Categoría: Operativo Fuente: Cliente Descripción del requisito: El sistema debe permitir el alta, baja y modificación de datos de productos. Se tendrá especial cuidado en no duplicar información relativa a un campo. Por ejemplo antes de dar de alta un artículo, se comprueba si ya está en la tabla de productos. Cada instancia de producto contiene los siguientes campos: ID_Producto Nombre Familia Descripción PrecioUnitario Existencias Proveedor MEDICIÓN Para cada consulta en la tabla se debe verificar el correcto tratamiento de la información. 35

IDENTIFICACIÓN Título del Proyecto: Sistema Integral de Gestión de Grandes Superficies Nombre del Jefe de Proyecto: Alberto Gutiérrez García REQUISITO Fecha: 30/11/2010 Versión: 1.0 Estado/Prioridad: Final/Media Título del requisito: Gestión de datos de personal Identificador: R9 Categoría: Operativo Fuente: Cliente Descripción del requisito: El sistema debe permitir el alta, baja y modificación de datos de empleados. Se tendrá especial cuidado en no duplicar información relativa a un campo. Por ejemplo antes de dar de alta a un empleado se comprueba si ya está en la tabla de personal. Cada instancia de empleado contiene los siguientes campos: ID_Empleado NombreCompleto DNI Dirección Teléfono Email Puesto Nomina Turno MEDICIÓN Para cada consulta en la tabla se debe verificar el correcto tratamiento de la información. 37

IDENTIFICACIÓN Título del Proyecto: Sistema Integral de Gestión de Grandes Superficies Nombre del Jefe de Proyecto: Alberto Gutiérrez García REQUISITO Fecha: 30/11/2010 Versión: 1.0 Estado/Prioridad: Final/Media Título del requisito: Gestión de datos de proveedores Identificador: R10 Categoría: Operativo Fuente: Cliente Descripción del requisito: El sistema debe permitir el alta, baja y modificación de datos de proveedores. Se tendrá especial cuidado en no duplicar información relativa a un campo. Por ejemplo antes de dar de alta a un proveedor se comprueba si ya está en la tabla de proveedores. Cada instancia de proveedor contiene los siguientes campos: ID_Proveedor Nombre CIF Dirección Teléfono Fax Email Artículos MEDICIÓN Para cada consulta en la tabla se debe verificar el correcto tratamiento de la información. 39

IDENTIFICACIÓN Título del Proyecto: Sistema Integral de Gestión de Grandes Superficies Nombre del Jefe de Proyecto: Alberto Gutiérrez García REQUISITO Fecha: 30/11/2010 Versión: 1.0 Estado/Prioridad: Final/Media Título del requisito: Control de acceso a la plataforma Identificador: R11 Categoría: Seguridad Fuente: Cliente Descripción del requisito: Para garantizar un cierto control sobre el acceso a la plataforma, será necesario el desarrollo de un sistema de identificación con usuario y contraseña. Los datos introducidos por el usuario se comparan con datos guardados en una tabla de la base de datos. Cada instancia de usuario contiene los siguientes campos: ID_Usuario User Password Solo serán necesarios ID_Usuario y Password para acceder a los contenidos de la aplicación. MEDICIÓN Para cada intento de acceder a la plataforma se requerirá el usuario y la contraseña. Si son correctos, el usuario podrá acceder a la siguiente pantalla. Si son incorrectos, se mostrará un mensaje de error. 41

BENEFICIOS Con la creación de un filtro con contraseña, se consigue un cierto nivel de seguridad para la aplicación web, y los datos que contiene. COMENTARIOS/SOLUCIONES SUGERIDAS DOCUMENTOS RELACIONADOS Documento de conceptos del sistema. REQUISITOS RELACIONADOS 42

IDENTIFICACIÓN Título del Proyecto: Sistema Integral de Gestión de Grandes Superficies Nombre del Jefe de Proyecto: Alberto Gutiérrez García REQUISITO Fecha: 30/11/2010 Versión: 1.0 Estado/Prioridad: Final/Baja Título del requisito: Realizar copias de seguridad Identificador: R12 Categoría: Seguridad Fuente: Cliente Descripción del requisito: Para evitar en lo posible la pérdida de información de forma inesperada, se deben realizar copias de seguridad y backups de forma periódica. MEDICIÓN Se deberían realizar copias de seguridad de forma periódica, siendo recomendable que se realicen cada mes. BENEFICIOS Con la realización de backups se puede evitar que la empresa pierda la información del sistema, si se produce una incidencia que acabe con el servidor donde se encuentra la base de datos. COMENTARIOS/SOLUCIONES SUGERIDAS DOCUMENTOS RELACIONADOS Documento de conceptos del sistema. 43

IDENTIFICACIÓN Título del Proyecto: Sistema Integral de Gestión de Grandes Superficies Nombre del Jefe de Proyecto: Alberto Gutiérrez García REQUISITO Fecha: 30/11/2010 Versión: 1.0 Estado/Prioridad: Final/ Título del requisito: Medidas de seguridad Identificador: R13 Categoría: Fuente: Cliente Descripción del requisito: Protección de datos del usuario, se ha de llevar a cabo un correcto trato de los datos personales, ya sea de clientes, proveedores o empleados que se utilicen en el sistema. MEDICIÓN Se deberían seguir todos los pasos necesarios para cumplir con la LOPD. BENEFICIOS Al cumplir con los estándares de protección de datos, no se incurrirá en faltas legales. COMENTARIOS/SOLUCIONES SUGERIDAS DOCUMENTOS RELACIONADOS Documento de conceptos del sistema. REQUISITOS RELACIONADOS 45

IDENTIFICACIÓN Título del Proyecto: Sistema Integral de Gestión de Grandes Superficies Nombre del Jefe de Proyecto: Alberto Gutiérrez García REQUISITO Fecha: 30/11/2010 Versión: 1.0 Estado/Prioridad: Final/ Título del requisito: Control de entrada de datos Identificador: R14 Categoría: Fuente: Cliente Descripción del requisito: Se controla la integridad de los datos de entrada. La aplicación controla que los valores de los datos de entrada se ajusten de manera precisa a lo que se espera en cada campo de entrada dentro de los distintos formularios que componen el sistema. MEDICIÓN Es un requisito que afecta a la parte de diseño y codificación de la aplicación y que mejora de forma sensible la misma, haciendo que presente menos fallos y que sea más robusta. BENEFICIOS La aplicación notará cierta mejora en su calidad. COMENTARIOS/SOLUCIONES SUGERIDAS DOCUMENTOS RELACIONADOS Documento de conceptos del sistema. 46

3.5. Modelo lógico del nuevo sistema Partiendo del sistema actual (inexistente en este caso) y de la lista de requisitos se crea el modelo lógico del nuevo sistema. Para representar el funcionamiento del sistema, se utiliza un elemento gráfico llamado DFD o diagrama de flujo de datos. En el DFD se representan todas las componentes del sistema. Se parte del nivel contextual, que explica la relación del sistema con las entidades externas y los flujos de datos que comparten. En los siguientes niveles o niveles conceptuales se profundiza en el sistema, y en los módulos, tablas y flujos de datos que lo componen. Una vez se realice la componente gráfica, se procede a la explicación y definición de cada uno de los elementos que aparecen en el dibujo. Esta parte es llamada Diccionario de datos, y los elementos a definir pueden ser: Entidades externas: Se representan mediante polígonos rectangulares, y definen entidades que no están dentro del sistema pero que de alguna manera están relacionadas con el mismo. Procesos: Se representan mediante círculos, y definen las funciones que va a realizar el sistema. Los procesos primitivos representan los módulos de la aplicación. Flujos de datos: Se representan mediante flechas, que indican el sentido de los datos que transportan. Almacenes de datos: Se representan mediante líneas paralelas, y definen las tablas de información de la base de datos. 48