Especificación de un sistema de comercializacion móvil para el sector servicios

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA GRADO EN INGENIERÍA DEL SOFTWARE ESPECIFICACIÓN DE UN SISTEMA DE COMERCIALIZACIÓN MÓVIL PARA EL SECTOR SERVICIOS DEVELOPMENT SPECIFICATION OF A MOBILE MARKETING SYSTEM FOR THE SERVICE INDUSTRY Realizado por Rocío Rueda Villanúa Tutorizado por Dr. Bartolomé Rubio Muñoz Departamento Lenguaje y Ciencias de la Computación UNIVERSIDAD DE MÁLAGA MÁLAGA, OCTUBRE 2014 Fecha defensa: El Secretario del Tribunal RESUMEN: Este Trabajo Fin de Grado aborda la especificación para el desarrollo de un sistema de comercialización orientado al sector Servicios que trabaje en tiempo real y que se fundamente en poner en contacto la oferta y la demanda. De esta forma, cuando un cliente requiera un servicio se activa como demandante y los proveedores de ese servicio reciben esa petición y pueden enviarle una oferta. El proyecto consta de una primera parte de introducción y descripción de las herramientas empleadas, para luego pasar a la metodología. La planificación especifica los requisitos del sistema que serán estudiados con más profundidad posteriormente en el estudio de viabilidad. Para el diseño y el análisis del sistema nos centramos en la definición de los casos de uso y las clases que se van a emplear durante el desarrollo. Por último se describe un prototipo que define las interfaces con las que se comunicarán los usuarios de la aplicación. Se describen en la parte final unas conclusiones y los posibles avances futuros del proyecto. PALABRAS CLAVE: Especificaciones, Métrica, UML, Aplicaciones, Móviles, Sector Servicios, Planificación, Análisis y Diseño ABSTRACT: This end-of-degree project is about the specifications for development of a marketing system focused on the services industry. This system is running real time and the main objective is connecting supply and demand. That is, when customer needs a service, this user is marked as buyer. Providers of this service are sent a request and they can make an offer. The first part of this project is and introduction and description of the tools used and the second part is about the methodology. The planning specifies the system requirements to be studied in more depth in the feasibility study. For the design and the analysis of the system, we focus on the definition of use cases and classes that will be used during development. Finally, you will find a prototype description which defines the interfaces that the users use to communicate. In the final section, some conclusions and the possible future advances of this project are described. KEYWORDS: Specifications, Measurements, UML, Applications, Mobile, Services Industry, Planning, Analysis and Design. TABLA DE CONTENIDO 1. INTRODUCCIÓN ......................................................................................... 9 1.1. Necesidad y Motivación ............................................................................. 9 1.2. Estado del arte .......................................................................................... 10 1.3. Propuesta .................................................................................................. 11 1.4. Objetivos ................................................................................................... 12 1.5. Métodos y fases de trabajo ....................................................................... 13 1.6. Contenidos ................................................................................................ 14 2. HERRAMIENTAS UTILIZADAS .............................................................. 16 2.1. Metodología empleada ............................................................................. 16 2.2. Aplicaciones utilizadas ............................................................................. 18 3. PLANIFICACIÓN DEL SISTEMA DE INFORMACIÓN ......................... 20 3.1. Objetivos de la planificación .................................................................... 20 3.2. Identificación de los requisitos ................................................................. 20 3.3. Diseño del modelo de sistema .................................................................. 22 3.4. Definición de la arquitectura tecnológica. ................................................ 23 3.5. Plan de Acción General ............................................................................ 23 4. ESTUDIO DE VIABILIDAD DEL SISTEMA ........................................... 25 4.1. Objetivos del estudio de viabilidad .......................................................... 25 4.2. Definición y clasificación de los requisitos del sistema ........................... 25 4.3. Selección de la alternativa de construcción .............................................. 28 5. ANÁLISIS Y DISEÑO DE LOS CASOS DE USO. ................................... 30 5.1. Objetivos de esta fase ............................................................................... 30 5.2. Identificación de los elementos del sistema ............................................. 30 5.3. Confección del diagrama de caso de uso .................................................. 31 5.4. Diagrama de Interacción de Objetos. ....................................................... 32 6. ANÁLISIS Y DISEÑO DE CLASES. ......................................................... 35 6.1. Objetivo del análisis de clases .................................................................. 35 6.2. Elaboración del modelo de datos. ............................................................. 35 6.3. Modelo entidad Relación extendido ......................................................... 37 6.4. Desarrollo del diagrama de Clases ........................................................... 41 7. DEFINICIÓN DEL INTERFAZ DE USUARIO. ........................................ 42 7.1. Objetivos de la definición del interfaz ...................................................... 42 7.2. Principios Generales de la Interfaz ........................................................... 42 7.3. Identificación de Perfiles y Diálogos........................................................ 43 7.4. Especificación de Formatos de la Interfaz ................................................ 43 7.5. Comportamiento Dinámico de la Interfaz. ............................................... 55 7.6. Diálogos y Notificaciones ........................................................................ 56 8. AMPLIACIONES Y FUTURAS MEJORAS .............................................. 58 9. CONCLUSIONES ....................................................................................... 59 10. BIBLIOGRAFÍA .......................................................................................... 60 Índice de Imágenes -7ÍNDICE DE IMÁGENES Imagen 1: Reserva en Restaurantes .................................................................................. 9 Imagen 2: Funcionamiento del sistema .......................................................................... 12 Imagen 3: Diagrama sobre las fases de métrica v.3 ....................................................... 17 Imagen 4: Definición gráfica de la arquitectura tecnológica del sistema ....................... 23 Imagen 5: Fase del desarrollo del sistema dentro del plan de acción ............................. 23 Imagen 6: Planificación del desarrollo completo del sistema. ....................................... 24 Imagen 7: Diagrama de Gantt. ........................................................................................ 24 Imagen 8: Arquitectura Básica del sistema .................................................................... 29 Imagen 9: Diagrama de casos de usos del actor Cliente ................................................ 31 Imagen 10: Diagrama de casos de usos del actor Proveedor .......................................... 32 Imagen 11: Diagrama de casos de usos general ............................................................. 32 Imagen 12: Diagrama de Secuencia Cliente ................................................................... 33 Imagen 13: Diagrama de Secuencia Proveedor .............................................................. 34 Imagen 14: Modelo de datos inicial ............................................................................... 35 Imagen 15: Modelo Entidad Relación ............................................................................ 36 Imagen 16: Generalización de los usuarios .................................................................... 37 Imagen 17: Modelo Entidad Relación Extendido........................................................... 40 Imagen 18: Diagrama de Clases ..................................................................................... 41 Imagen 19: Pantalla de Inicio ......................................................................................... 44 Imagen 20: Pantalla de Alta Usuario .............................................................................. 44 Imagen 21: Pantalla recuperación de contraseña ............................................................ 45 Imagen 22: Pantalla del Menú Cliente ........................................................................... 45 Imagen 23: Pantalla de Búsqueda ................................................................................... 46 Imagen 24: Pantalla de listado de ofertas ....................................................................... 47 Imagen 25: Pantalla de Reserva...................................................................................... 48 Imagen 26: Pantalla de listado de reservas realizadas .................................................... 49 Índice de Imágenes -8Imagen 27: Pantalla que muestra la información del proveedor .................................... 50 Imagen 28: Pantalla de Configuración del Cliente ......................................................... 51 Imagen 29: Pantalla Menú del Proveedor....................................................................... 51 Imagen 30: Pantalla que muestra todas las ofertas del proveedor .................................. 52 Imagen 31: Pantalla de edición de oferta ....................................................................... 53 Imagen 32: Pantalla que muestra las peticiones que realizan a un proveedor ................ 54 Imagen 33: Pantalla de listado de reservas ..................................................................... 54 Imagen 34: Pantalla sobre el comportamiento dinámico del interfaz cliente. ................ 55 Imagen 35: Pantalla sobre el comportamiento dinámico del interfaz proveedor ........... 56 Introducción -91. INTRODUCCIÓN 1.1. NECESIDAD Y MOTIVACIÓN El mercado de reservas online está en pleno auge. En algunos sectores como el de restauración actualmente se está incrementando las ventas por la incorporación de las tecnologías móviles. En la imagen 1 vemos cómo han evolucionado las reservas online en restaurantes, dentro de las cuales se incluyen las reservas desde dispositivos móviles a lo largo de los últimos 3 años. Vemos cómo son especialmente éstas, las reservas móviles, las que cuentan con el margen de crecimiento más grande. Imagen 1: Reserva en Restaurantes Un total de 1,4 millones de reservas vía móvil en 2013 las cuales han generado más de 15,2 millones de euros. En el último año se han cuadruplicado las reservas realizadas por móvil en este sector, por lo que no cabe duda de que se trata de un medio de llegar al cliente que se está viendo cada vez más. Pero este hecho particular no se reduce únicamente al sector de la restauración, sino que se extiende a otros sectores, donde el móvil se está convirtiendo en una herramienta clave. Los dispositivos móviles se han convertido en el centro de la vida digital de las personas tal y como se observa en el último estudio anual de la sociedad de la información, donde queda de manifiesto que el uso de estos dispositivos se ha disparado en los últimos años. Se destaca que el aumento de conexión a internet desde el móvil ha crecido un 300 % y, además, el uso de aplicaciones (apps) se ha incrementado un 150 % en el 2013. Todo ello nos lleva a un cambio radical en la manera en la que nos relacionamos y nos comunicamos, así como en la forma en la que visualizamos información. Los conocidos “smartphones” han ido adquiriendo nuevas funcionalidades que los convierten en indispensables en determinados momentos de la vida cotidiana. Por estas Herramientas Utilizadas -162. HERRAMIENTAS UTILIZADAS 2.1. METODOLOGÍA EMPLEADA Para desarrollar software se precisa de una serie de pasos y procedimientos, así como un método de trabajo que ayude a los desarrolladores a realizar software de forma sistemática. Las metodologías de desarrollo de software definen un conjunto de filosofías, fases, procedimientos, reglas, técnicas y herramientas para que los desarrolladores de sistemas de información puedan realizar su labor de forma más eficiente. Reuniendo todos estos aspectos, obtenemos que una metodología se define como un conjunto de componentes que definen:  Cómo dividir un proyecto en etapas diferenciadas.  Qué tareas deben llevarse a cabo en cada una de las etapas.  Qué resultados se producen y cuándo se deben producir.  Qué restricciones deben tenerse en cuenta.  Qué herramientas utilizar.  Cómo gestionar y controlar un proyecto. El desarrollo del presente proyecto se inspira en Métrica v.3, que es una metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información. Métrica v3 es la metodología oficial para el desarrollo de software de la administración española. Esta metodología propia está basada en el modelo de procesos del ciclo de vida de desarrollo ISO/IEC 12207, así como en la norma ISO/IEC 15504 SPICE. Además Métrica v.3 ofrece a las organizaciones un instrumento útil para la sistematización de las actividades que dan soporte al ciclo de vida del software dentro del marco que permite alcanzar los siguientes objetivos:  Proporcionar o definir Sistemas de Información que ayuden a conseguir los fines de la Organización mediante la definición de un marco estratégico para el desarrollo de los mismos.  Dotar a la Organización de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al análisis de requisitos.  Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la Información y las comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible.  Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en Herramientas Utilizadas -17cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.  Facilitar la operación, mantenimiento y uso de los productos software obtenidos. Métrica Versión 3 tiene un enfoque orientado al proceso, ya que la tendencia general en los estándares se encamina en este sentido y por ello, se ha enmarcado dentro de la norma ISO 12.207, que se centra en la clasificación y definición de los procesos del ciclo de vida del software. Como punto de partida y atendiendo a dicha norma, Métrica Versión 3 cubre el Proceso de Desarrollo y el Proceso de Mantenimiento de Sistemas de Información. Métrica Versión 3 ha sido concebida para abarcar el desarrollo completo de Sistema de Información sea cual sea su complejidad y magnitud, por lo cual su estructura responde a desarrollos máximos y deberá adaptarse y dimensionarse en cada momento de acuerdo a las características particulares de cada proyecto. La metodología descompone cada uno de los procesos en actividades, y éstas a su vez en tareas. Para cada tarea se describe su contenido haciendo referencia a sus principales acciones, productos, técnicas, prácticas y participantes. Las actividades pueden realizarse en diferente orden de numeración o bien en paralelo. Los procesos de la estructura principal de Métrica Versión 3 son los siguientes:  PLANIFICACIÓN DE SISTEMAS DE INFORMACIÓN.  DESARROLLO DE SISTEMAS DE INFORMACIÓN.  MANTENIMIENTO DE SISTEMAS DE INFORMACIÓN. En cuanto al Proceso de Desarrollo de Sistemas de Información, para facilitar la comprensión y dada su amplitud y complejidad se ha subdividido en cinco procesos:  ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS).  ANÁLISIS DEL SISTEMA DE INFORMACIÓN (ASI).  DISEÑO DEL SISTEMA DE INFORMACIÓN (DSI).  CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN (CSI).  IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA (IAS). Imagen 3: Diagrama sobre las fases de métrica v.3 Herramientas Utilizadas -18Además de esta metodología nos basaremos en conceptos y técnicas propias de UML, con las que podemos trabajar dentro de la libertad que permite el uso de la métrica v.3. Lenguaje Unificado de Modelado o UML es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad, se encuentra respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados. Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no específica en sí mismo qué metodología o proceso usar. UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, sólo se diagrama la realidad de una utilización en un requisito. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas. Sobre esos diagramas son sobre los que vamos a trabajar a lo largo del presente proyecto. 2.2. APLICACIONES UTILIZADAS Para la realización del presente proyecto se han necesitado una serie de herramientas que han permitido llevarlo a cabo y las cuales describimos a continuación: Sistema Operativo: Windows 7 Windows 7 es una versión de Microsoft Windows, línea de sistemas operativos producida por Microsoft Corporation. Esta versión está diseñada para uso en PC, incluyendo equipos de escritorio en hogares y oficinas, equipos portátiles, tablet PC, netbooks y equipos media center. Herramientas Utilizadas -19Aplicaciones Ofimáticas: Microsoft Office 2007 Microsoft Office es una suite de oficina que abarca el mercado completo en Internet e interrelaciona aplicaciones de escritorio, servidores y servicios para los sistemas operativos Microsoft Windows y Mac OS X. En particular, para este proyecto dentro de la suite se emplea el procesador de texto (Word), un editor de hojas de cálculo (Excel) y un editor de presentaciones (Powerpoint) para la exposición del proyecto. Herramientas CASE: MagicDraw UML v. 17.0.4 Para el presente proyecto se ha elegido la herramienta MagicDraw UML que es una herramienta CASE desarrollada por No Magic. La herramienta es compatible con el estándar UML 2.3, desarrollo de código para diversos lenguajes de programación así como para modelar datos. Se compone de diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Diseño Gráfico: Adobe Photoshop CS6 Para la edición de algunas imágenes y capturas de pantallas se cuenta con un editor gráfico como Adobe Photoshop que es un editor de gráficos rasterizados desarrollado por Adobe Systems principalmente usado para el retoque de fotografías y gráficos. Es líder mundial del mercado de las aplicaciones de edición de imágenes y domina este sector de tal manera que su nombre es ampliamente empleado como sinónimo para la edición de imágenes en general. Planificación del sistema de información -203. PLANIFICACIÓN DEL SISTEMA DE INFORMACIÓN 3.1. OBJETIVOS DE LA PLANIFICACIÓN El objetivo de un Plan de Sistemas de Información es proporcionar un marco estratégico de referencia para los Sistemas de Información de un determinado ámbito de la Organización, elaborando una arquitectura de información y un plan de proyectos informáticos para dar apoyo a los objetivos estratégicos. Por este motivo es necesario un proceso como el de Planificación de Sistemas de Información, en el que participen, por un lado los responsables de los procesos de la organización con una visión estratégica y por otro, los profesionales de SI capaces de enriquecer dicha visión con la aportación de ventajas competitivas por medio de los sistemas y tecnologías de la información y comunicaciones. Por un lado vamos a describir el alcance y los requisitos del sistema, para a partir de ellos desarrollar un modelo aproximado del sistema y una arquitectura tecnológica. Como productos finales de esta fase tendremos: - Listado de Requisitos Generales - Modelo de sistemas de información. - Arquitectura tecnológica. 3.2. IDENTIFICACIÓN DE LOS REQUISITOS El objetivo final de esta actividad va a ser la especificación de los requisitos de información del proyecto. Para ello seguiremos las directrices que establece Métrica: en primer lugar analizaremos el problema, y a partir de ahí, localizaremos los requisitos. Análisis del problema Se pretende desarrollar una plataforma donde se identifican los siguientes elementos Actores:  Clientes: Son los que realizan las peticiones al sistema.  Proveedores: Son los que envían ofertas a los clientes. Conceptos:  Petición: El cliente cuando desea realizar una actividad, realiza una petición en la plataforma. En una petición se definen 3 parámetros:  ¿Qué servicio es el que se está buscando? Identifica el tipo de servicio y la actividad: Estética (como pelarse, teñirse, depilación), Taller (como cambio de neumáticos, averías y reparaciones), Planificación del sistema de información -21-  ¿Cuándo desea realizarlo? Este momento indica cuándo desea realizar esta actividad. Es opcional.  ¿Dónde quiere hacerlo? Indica la zona donde quiere realizar el servicio, y puede ser identificada como una localidad o por la cercanía a la ubicación actual del usuario.  Oferta: El proveedor recibe una petición y como respuesta a esta puede dar una respuesta al cliente mediante el envío de una oferta. Los elementos de una oferta son:  Tipo de servicio y actividad.  Descripción.  Condiciones.  Precio final o Descuento.  Imágenes.  Reserva: El cliente puede reservar alguna de las ofertas recibidas, para lo cual además de estar dado de alta en el sistema debe proporcionar su número de teléfono. Esa reserva se le notifica al proveedor del servicio en el mismo momento. Sistemas de Información:  Sistema del Cliente: Este sistema da soporte al cliente para realizar sus peticiones y formalizar las reservas. Cuenta con:  Administración del perfil.  Realizar petición. Envía las peticiones a los proveedores interesados.  Ofertas recibidas. Donde realiza las reservas.  Mis reservas.  Sistema del Proveedor: Este sistema permite a los proveedores crear y enviar las ofertas a potenciales clientes, así como configurar los datos de su cuenta.  Sistema interno: Este sistema se encarga de gestionar todas las peticiones, ofertas y reservas. Definir requisitos generales Se quiere desarrollar un sistema de información que permita a los clientes mandar peticiones y confirmar ofertas de los proveedores que cumplan los requisitos (zona y horario) y respondan mediante una oferta. - Se podrán realizar peticiones en función de la posición actual o de una localidad concreta. - En las peticiones es obligatorio indicar la actividad y la zona. Planificación del sistema de información -22- - Las peticiones sólo serán enviadas a los proveedores que cumplan que se encuentren en la zona donde se busca, y que se estén abiertos a la hora que indica la petición. - Los proveedores podrán tener ofertas ya almacenadas para agilizar el envío de éstas. - Para confirmar una reserva el cliente debe facilitar su número de teléfono. - Las peticiones nueva que reciba un proveedor deben ser notificadas. - Cuando se recibe una nueva oferta se le debe notificar al cliente que la recibió. - El sistema debe trabajar en tiempo real. - Los sistemas del cliente y del proveedor deben ser móviles. 3.3. DISEÑO DEL MODELO DE SISTEMA En esta actividad se va a obtener un marco de referencia para el desarrollo del sistema de información respondiendo a los objetivos marcados. Condiciones generales del sistema Estas condiciones definen las procesos básicos de los que se compone el desarrollo del proyecto. - Diseño e implementación de la Base de Datos. Consiste en la obtención de una base de datos sólida y consistente que permita llevar a cabo el almacenamiento de los datos manejados por el sistema. - Diseño de la estructura y desarrollo del sistema de procesamiento interno. Este desarrollo consiste en el eje principal del proyecto y siendo la parte inteligente del sistema y la que permite la comunicación entre ambas partes. - Diseño de la estructura y desarrollo de la aplicación móvil asociada al cliente. Este área define la comunicación con el cliente, y se define por una interfaz muy usable y sencilla. - Diseño de la estructura y desarrollo de la aplicación móvil proveedor. Este área define la interacción con el proveedor, debe incluir todas las opciones para una sencilla administración de la cuenta y las ofertas. Factores Críticos de éxito: Existen factores importantes que son los que hacen que el sistema alcance o no los objetivos marcados. - Consistencia de la base de datos. La creación de la base de datos es uno de los puntos más críticos del desarrollo, siendo la consistencia de los datos una característica imprescindible dentro del proyecto. - Simplicidad y usabilidad en las aplicaciones móviles. El fácil manejo de la aplicación mediante un interfaz sencillo resulta imprescindible para que sea útil para el usuario. Planificación del sistema de información -23- - Seguridad. La seguridad y el control de acceso a determinadas áreas administrables, resulta transcendental para la estabilidad del sistema. - Tiempo real. Una de las características que hace que este sistema sea de gran utilidad en su desempeño es que se trata de un sistema en tiempo real, eso quiere las peticiones y las ofertas son enviadas en el mismo momento y que se puede trabajar sobre la marcha de manera instantánea. 3.4. DEFINICIÓN DE LA ARQUITECTURA TECNOLÓGICA. En esta actividad se propone una arquitectura tecnológica que de soporte al modelo de información y de sistemas de información definiendo los requisitos de carácter tecnológico. - Una aplicación móvil que permita a los clientes realizar la búsqueda de los servicios. - Una aplicación móvil que permita a los proveedores ofrecer sus servicios. - Un backend que sirva de comunicación entre ambas y que trabaje en tiempo real con las peticiones que se le realicen. Imagen 4: Definición gráfica de la arquitectura tecnológica del sistema 3.5. PLAN DE ACCIÓN GENERAL Como plan de acción general tomamos los procesos del proyecto y se ordenan las etapas según el gráfico que aparece en la imagen 5. Imagen 5: Fase del desarrollo del sistema dentro del plan de acción App Móvil Cliente App Móvil Proveedor Sistema Interno Backend Diseño y Análisis del Sistema Desarrollo de Back-end Implementación Base de Datos Desarrollo de la app Cliente Desarrollo de la app Proveedor Diseño Base de Datos Planificación del sistema de información -24Según se observa en la imagen 5, en primer lugar se define cómo va a ser el sistema, con los correspondiente requisitos y especificaciones que marquen las pautas de lo que se va a desarrollar con posterioridad. Un punto clave de este proceso es el diseño de la base de datos, para su posterior implementación. Después de que el sistema quede definido pasamos a desarrollar la parte interna y donde se desarrollaran todas las operaciones y procesos. Para un correcto acceso a esta parte, se desarrollan las aplicaciones que interaccionan con los usuarios tanto cliente como proveedores. A partir de las necesidades expuestas se confecciona un plan de acción con una planificación como la que muestra la imagen 6 y 7. Imagen 6: Planificación del desarrollo completo del sistema. Imagen 7: Diagrama de Gantt. Estudio de viabilidad del sistema -254. ESTUDIO DE VIABILIDAD DEL SISTEMA 4.1. OBJETIVOS DEL ESTUDIO DE VIABILIDAD El objeto del Estudio Viabilidad del Sistema es analizar las necesidades y proponer una solución a corto plazo, basada en este caso, en los criterios técnicos del proyecto. La solución obtenida como resultado del estudio será de alguna forma la definición del proyecto. Para ello, se identifican y clasifican los requisitos que se han de satisfacer. A partir de los requisitos planteados, se estudian las alternativas de solución. Se describe cada una de las alternativas, indicando los requisitos que cubre. Una vez descritas cada una de las alternativas planteadas, se valora su impacto, la inversión a realizar en cada caso y los riesgos asociados. Esta información se analiza con el fin de evaluar las distintas alternativas y seleccionar la más adecuada, definiendo y estableciendo su planificación. 4.2. DEFINICIÓN Y CLASIFICACIÓN DE LOS REQUISITOS DEL SISTEMA Descripción general del sistema: Se va a desarrollar un sistema para la centralización de la ofertas en el sector servicios. Las necesidades del sistema son: Módulo Cliente a) Debe ser un sistema accesible y usable, donde se muestre la información a través de un interfaz sencillo. b) Debe poder también realizar peticiones sobre sus necesidades. c) El sistema puede formalizar las reservas. d) Se puede gestionar la información de perfil. Módulo Proveedor a) Debe ser administrable toda la información sobre la cuenta. b) Se debe poder gestionar todas las ofertas y su lanzamiento. c) Interfaz sencillo que permita un uso intuitivo. Módulo Interno: a) Se debe almacenar con una base de datos. b) La comunicación y el procesamiento de la información debe realizarse en tiempo real. c) Se notificará a los proveedores cuando haya una petición de su interés o una reserva y a los clientes cuando se le envié una oferta Análisis y diseño de los casos de uso -32Por parte del proveedor de servicios tenemos una serie de utilidades y casos de usos diferentes (imagen 10). Imagen 10: Diagrama de casos de usos del actor Proveedor Entre ambos actores se definen interrelaciones entre sus casos de usos de firma tanto extendida como inclusiva, ya que existen casos que no tienen sentido sin la presencia de otros. Por ejemplo, para que el cliente realice una reserva, tiene que haber lanzado una oferta el proveedor, no tendría sentido una reserva sin el lanzamiento de una oferta. Imagen 11: Diagrama de casos de usos general 5.4. DIAGRAMA DE INTERACCIÓN DE OBJETOS. Para representar la interacción de objetos hemos seleccionado el diagrama de secuencia, que dentro de los diagramas de interacción, representa mejor la forma en que un actor se comunica en función de eventos. Estos diagramas se verán también diferenciados por cada uno de los actores en cada caso. Análisis y diseño de los casos de uso -33Para el caso del actor Cliente contamos con las siguientes secuencias básicas descritas en la imagen 12. Imagen 12: Diagrama de Secuencia Cliente El cliente interactúa con la aplicación por medio de diferentes secciones que se pueden recorrer definiendo la usabilidad de la aplicación. Contamos con las siguientes secciones en el caso del cliente: Inicio, Nueva Cuenta, Recuperar Contraseña, Menú, Buscador, Ofertas, Detalle de la oferta, Reservas, Detalles de Reserva y una sección que permite el acceso a los datos. El cliente se mueve por las estas secciones a través de las acciones que se definen dentro de cada una de ellas. Por ejemplo, el menú permite acceder al buscador a través de un botón “buscar” y desde esa sección se puede volver al menú a través del botón de volver. Análisis y diseño de los casos de uso -34El diagrama de interacción del proveedor cuenta con los siguientes objetos y secuencias: Imagen 13: Diagrama de Secuencia Proveedor En el caso del proveedor también cuenta con una serie de sección para gestionar su cuenta y sus ofertas. Dentro de las secciones tenemos: Inicio, Nueva Cuenta, Recuperar Contraseña, Menú, Administrador de Ofertas, Peticiones, Reservas y al igual que los clientes, la sección de acceso a los datos. Dentro de las acciones para cambiar de secciones destaca la de asignar petición que permite la secuencia entre una oferta y asignar ésta a una petición. Análisis y diseño de clases -356. ANÁLISIS Y DISEÑO DE CLASES. 6.1. OBJETIVO DEL ANÁLISIS DE CLASES El objetivo de esta actividad es describir cada una de las clases que ha surgido, identificando las responsabilidades que tienen asociadas, sus atributos, y las relaciones entre ellas. Para describir el modelado de datos pasamos a realizar un esquema que básico de entidad relación donde se localizan las principales clases, con sus atributos y las relaciones entre ellas. Posteriormente el modelado de clases permite realizar una definición más profunda de cuál va a ser la estructura del sistema. 6.2. ELABORACIÓN DEL MODELO DE DATOS. La base de datos se compone de un conjunto de tablas donde se almacena la información del sistema, por lo que la estructura de este modelo resulta fundamental en el rendimiento de nuestro producto. En un primer análisis obtenemos las siguientes tablas: - Proveedor: Se almacena la información necesaria sobre el proveedor de servicios. Se identifican los datos de usuarios, de localización, así como de facturación. - Cliente: La información sobre los clientes se basa en su usuario y datos de contacto. - Oferta: Las ofertas son muy variadas y llevan asociadas diferentes atributos sobre sus características. - Petición: Las peticiones del cliente se almacena tanto el momento en el que fueron realizadas, como los requisitos de la búsqueda. - Reserva: En este caso encontramos datos de la reserva. Imagen 14: Modelo de datos inicial Cliente Proveedor Oferta Petición Reserva realiza sobre hace realiza es lanzada para Análisis y diseño de clases -36Una vez desarrollamos el primer esquema empezamos a pensar en una estructura de datos más completa, añadiendo algunas tablas más. Cuando analizamos el proveedor nos damos cuenta que puede contar con uno o con varios usuarios que sean empleados de una misma empresa, al igual que puede también estar establecida en uno o varios establecimientos. A cargo de estos establecimientos se tiene uno a varios empleados que desarrollan su trabajo en él. Los empleados del establecimiento son los que podrán gestionar las ofertas de éste. Además debemos incluir clases que definan los diferentes tipos de ofertas y los diferentes tipos de actividades a desarrollar por los proveedores. También cuando se lanza una oferta esta debe ser llevar una fecha de caducidad asociada, que es el tiempo con el que cuenta el cliente para reservarla. Con estos datos nuevos pasamos a describir el modelo Entidad Relación básico que queda de la siguiente manera: Imagen 15: Modelo Entidad Relación Cliente Empleado Oferta Petición Reserva crea sobre hace realiza Es lanzada para Compañía proveedora tiene Establecimiento ofrece posee hay cargo Fecha_ caducidad Actividad para sobre 1 N 1 N N M 1 N 1 N 1 1 N N M N 1 1 1 1 Análisis y diseño de clases -37Dentro de las características de los servicios que son posibles, resulta interesante clasificarlos según su tipología o su área, para ello en el modelo entidad relación también incorpora el concepto de actividad. Como ejemplo de actividad contamos con Estética, Mecánica y Restauración, entre otros. 6.3. MODELO ENTIDAD RELACIÓN EXTENDIDO Ya sabemos que nuestra plataforma contará con 2 tipos de usuarios. Por un lado los proveedores y por otro los clientes. Imagen 16: Generalización de los usuarios Tanto un proveedor como un cliente cuenta con un usuario, en el caso del proveedor puede contar con varios usuarios y cada uno de ellos con perfiles diferentes, donde se determinarán las funciones que cada uno de ellos puede desarrollar en los diferentes establecimientos. Además debemos desglosar las relaciones entre clases que cuentan con atributos como es el caso de: destino (define la relación entre un empleado y un establecimiento) y oferta lanzada (define la relación entre una oferta y una petición a un cliente). Además quitamos los datos que puedan parecer redundantes como es el caso de la relación directa entre un empleado y su empresa que vendrá dado por la nueva tabla destino. El modelo queda definido con las correspondientes tablas: - Proveedor: Define la compañía o empresa proveedora de servicios y se localizan los datos sobre esta. o Id _proveedor: (Clave primaria) Código de identificación de los proveedores o Nombre_Empresa o Tipo_Sociedad o NIF d Empleado_ Proveedor Cliente Usuario Análisis y diseño de clases -38o Dirección o Localidad o Provincia o Persona_Contacto o Telefono_Contacto o Email_Contacto - Usuario: Se trata de un usuario que pueda acceder al sistema ya sea cliente o empleado. o Id_usuario: (Clave primaria) Código de identificación de los usuarios o Alias o Contraseña o Email o Teléfono o Nombre o Apellidos o Estado o Fecha_Nacimiento o DNI o Dirección o Localidad o Provincia - Empleado: Empleado de la empresa proveedora que podrá gestionar ofertas y datos sobre ese proveedor. o Id_usuario: (Clave primaria) Código de identificación de los proveedores. o Antigüedad_total - Cliente: Cliente que realiza peticiones de servicios, recibe las oferta y realiza la reserva. o Id_usuario: (Clave primaria) Código de identificación de los proveedores. o Fecha_alta - Establecimiento: Local donde se localiza una oferta que pertenece a una empresa y en el que están destinado varios empleados. o Id_establecimiento: (Clave primaria) Código de identificación de los establecimientos. o Id proveedor: (Clave foránea) Código de identificación de los proveedores. o Dirección o Localidad o Provincia o Observaciones o Coordenadas_Localización o Estado Análisis y diseño de clases -39- - Destino: Define el perfil de un empleado en un establecimiento y por consecuencia en la empresa. o Id_establecimiento (Clave foránea) Código de identificación de los establecimientos. o Id empleado (Clave foránea) Código de identificación de los empleado. o Fecha_alta o Perfil o Estado - Oferta o Id_oferta: (Clave primaria) Código de identificación de las ofertas. o Id_actividad: (Clave foránea) Código de identificación de la actividad. o Id_establecimiento: (Clave foránea) Código de identificación de los establecimientos. o Id_empleado_creada: (Clave foránea) Código de identificación del empleado que crea la oferta. o Tipo_oferta o Fecha_inicio o Fecha_fin o Capacidad_total o Min_participantes o Max_participantes o Nombre o Precio o Descripción o Estado - Reserva o Id_reserva: (Clave primaria) Código de identificación de la reserva. o Id_cliente: (Clave foranea) Código de identificación de los clientes. o Id_oferta: (Clave foranea) Código de identificación de las ofertas. o Fecha_actual o Fecha_reserva o Num_Participantes o Estado - Petición: o Id_peticion: (Clave primaria) Código de identificación de las peticiones. o Id_cliente: (Clave foranea) Código de identificación de los clientes. o Id_actividad: (Clave foranea) Código de identificación de las actividades. o Coordenada_x o Coordenada_y o Distancia Análisis y diseño de clases -40o Numero_participantes o Fecha_realizada o Fecha_pedida o Estado - Oferta_lanzada: o Id_oferta: (Clave foránea) Código de identificación de las ofertas. o Id_peticion: (Clave foránea) Código de identificación de las peticiones. o Fecha Caducidad o Estado - Actividad o Id_actividad: (Clave primaria) Código de identificación de las actividades. o Nombre o Descripción Imagen 17: Modelo Entidad Relación Extendido Cliente Empleado Oferta Petición Reserva crea sobre hace realiza Es lanzada para Usuario d Proveedor Establecimiento ofrece posee hay Actividad para sobre hay Destino Oferta_ Lanzada sobre 1 1 1 1 1 1 1 1 1 1 1 1 1 1 N N N N N N N N N N Análisis y diseño de clases -416.4. DESARROLLO DEL DIAGRAMA DE CLASES Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas informáticos, para crear un modelo conceptual de la información que se manejará en el sistema. Para ello se describen las diferentes clases, sus propiedades y las relaciones que existen entre ellas. Presenta una estructura en árbol donde se incluyen los conceptos de herencia que pueden surgir entre clases. Imagen 18: Diagrama de Clases Definición del interfaz de usuario -48Pantalla Cliente 7: RESERVAR Imagen 25: Pantalla de Reserva En esta pantalla se muestra un formulario sobre los detalles de la reserva donde introduce el momento en que quiere reservar el servicio y el número de personas que disfrutar de él. También desde esta pantalla se da acceso para ampliar la información sobre el proveedor o confirmar la reserva. Definición del interfaz de usuario -49Pantalla Cliente 8: LISTADO DE RESERVAS Imagen 26: Pantalla de listado de reservas realizadas Muestra un listado de las reservas que se tienen activas. Además puede acceder para modificarla, cancelarla, visualizar más información sobre el proveedor o activar el navegador para que me guie a la localización donde se va a desarrollar la actividad. Definición del interfaz de usuario -50Pantalla Cliente 9: MÁS INFO Imagen 27: Pantalla que muestra la información del proveedor Para la sección más información se cuenta con una interfaz donde se muestra una descripción del proveedor, además de incluir las ofertas que tiene activas. También se puede activar el navegador pulsando en ir a, que nos guía a la localización del establecimiento. Definición del interfaz de usuario -51Pantalla Cliente 10: CONFIGURACIÓN Imagen 28: Pantalla de Configuración del Cliente La pantalla de configuración permite editar los datos que la aplicación almacena de este usuario como cliente. En el caso de la aplicación para el proveedor, se establecen una serie de pantallas comunes con las del cliente como son: Pantalla de inicio (imagen 19), Pantalla de alta de usuario (imagen 20) y Pantalla de recuperación de contraseña (imagen 21). Por otro lado contamos con otra serie de pantallas específicas para el proveedor, entre las que se encuentran: Pantalla Proveedor 1: MENÚ Imagen 29: Pantalla Menú del Proveedor Definición del interfaz de usuario -52En el menú localizamos los diferentes apartados de la aplicación en este caso del proveedor donde podemos acceder a sus ofertas, sus peticiones, sus reservas y su configuración de la cuenta. Pantalla Proveedor 2: LISTADO DE OFERTA Imagen 30: Pantalla que muestra todas las ofertas del proveedor El listado de ofertas les permite ver las ofertas que tiene y adminístralas, pudiendo añadir, editar y eliminar las ofertas de ese proveedor. Definición del interfaz de usuario -53Pantalla Proveedor 3: EDICIÓN DE OFERTAS Imagen 31: Pantalla de edición de oferta Esta interfaz permite al proveedor editar la oferta seleccionada, en ella podemos modificar todas las características de la oferta en cuestión, como es la descripción, el tipo de oferta, el precio, el periodo de validez y el número de plazas. Definición del interfaz de usuario -54Pantalla Proveedor 4: LISTADO DE PETICIONES Imagen 32: Pantalla que muestra las peticiones que realizan a un proveedor Esta pantalla permite visualizar todas las peticiones de los clientes que cumplen los requisitos de ese proveedor, por actividad y por zona. Con esto el proveedor puede ver los clientes que están buscando sus servicios por su área. Pantalla Proveedor 5: LISTADO DE RESERVAS Imagen 33: Pantalla de listado de reservas Definición del interfaz de usuario -55En este listado se visualiza todas las reservas que han confirmado los clientes y permite contactar con ellos o cancelar la reserva en el caso de que haya algún incidente con ellas. 7.5. COMPORTAMIENTO DINÁMICO DE LA INTERFAZ. Una de las principales características del interfaz es su comportamiento dinámico dentro del sistema, ya que se trata de un ente vivo. A continuación se muestra el comportamiento de la interfaz por parte del cliente. Se observa cómo se navega a través de las diferentes pantallas que vienen definidas por los rectángulos. Imagen 34: Pantalla sobre el comportamiento dinámico del interfaz cliente. Por parte del proveedor tenemos un comportamiento dinámico bastante similar, tal y como se muestra en la imagen 35. Inicio Login Alta Usuario Recuperar Contraseña Menú Buscador Listado de Ofertas Reservar Más Info Listado de Reservas Configuración Primer acceso Definición del interfaz de usuario -56Imagen 35: Pantalla sobre el comportamiento dinámico del interfaz proveedor 7.6. DIÁLOGOS Y NOTIFICACIONES Dentro de la interfaz de las aplicaciones que son desarrolladas para este proyecto cuenta con especial importancia el sistema de notificaciones de nuestra plataforma móvil. Para ello se debe desarrollar un sistema de notificación para cada sistema operativo con el que se trabaje. Estas notificaciones son definidas como avisos para el usuario del dispositivo y alertan de determinas circunstancias. En el caso de la aplicación de cliente se contará con 2 motivos de notificaciones: - Notificación de nueva oferta recibida. Se alertará al cliente en el momento que reciba una oferta de su interés. Esta notificación es configurable al realizar una búsqueda. - Notificación de cancelación de reserva. En el caso de que un proveedor no pueda efectuar un servicio, tiene la opción de notificarlo al cliente mediante la cancelación de la reserva, se enviará, en este caso, una alarma al cliente de que no se va a efectuar el servicio. Por el lado del proveedor contamos con otro tipo de notificaciones aunque no varían tanto: Inicio Login Alta Usuario Recuperar Contraseña Menú Ofertas Peticiones Edición de ofertas Listado de Reservas Configuración Primer acceso Definición del interfaz de usuario -57- - Notificación de nueva petición recibida. Indica cuando un cliente está buscando un servicio por su zona. El proveedor recibe por lo tanto un aviso de un posible cliente para que pueda enviarle una oferta. - Notificación de cancelación de reserva. En el caso de que un cliente desea cancelar un servicio, tiene la opción de notificarlo al proveedor mediante la cancelación de la reserva, se enviará, en este caso, una alarma al proveedor de que no se va a efectuar ese servicio Además de las notificaciones tenemos también que hablar de las formas de contacto entre cliente y proveedor. En un principio, consideramos que la forma de comunicación va a ser mediante email de forma externa a la aplicación necesitando por lo tanto que el cliente ceda sus datos, en particular su email, para su manipulación por parte de los proveedores cuyos servicios haya reservado. De igual forma que el proveedor también debe permitir facilitar su email a potenciales clientes.