PROYECTO FIN DE CARRERA. Reprografía online

Transcripción

1 PROYECTO FIN DE CARRERA Título Reprografía online Autor/es José Ramón Herce Martínez Director/es Beatriz Pérez Valle Facultad Facultad de Ciencias, Estudios Agroalimentarios e Informática Titulación Proyecto Fin de Carrera Departamento Matemáticas y Computación Curso Académico

2 , proyecto fin de carrera de José Ramón Herce Martínez, dirigido por Beatriz Pérez Valle (publicado por la Universidad de La Rioja), se difunde bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los titulares del copyright. El autor Universidad de La Rioja, Servicio de Publicaciones, 2013 publicaciones.unirioja.es publicaciones@unirioja.es

3 UNIVERSIDAD DE LA RIOJA Facultad de Ciencias, Estudios Agroalimentarios e Informática PROYECTO FIN DE CARRERA Ingeniería Técnica en Informática de Gestión Reprografía online Alumno: Jose Ramón Herce Martínez Director: Beatriz Pérez Valle Logroño, Julio 2013

4 RESUMEN El siguiente proyecto pretende llevar a cabo el desarrollo de un sistema, formado por dos aplicaciones web, para gestionar el servicio de una reprografía online de modo que facilite tanto a la empresa como a los usuarios de la misma, los servicios más habituales que se llevan a cabo en un empresa de reprografía. El objetivo principal es el desarrollo de un sistema y su posterior implantación como servicio online de negocio en una empresa. Documentación 1

5 Documentación 2 Reprografía online

6 ÍNDICE DE CONTENIDOS Resumen Introducción Especificación del proyecto Motivo de elección Documento de objetivos del proyecto Antecedentes Universo del proyecto Intención del proyecto Participantes Comunicación Entregables Tecnologías a utilizar Documentación necesaria Metodología del desarrollo de software Planificación del proyecto Estructura de descomposición del proyecto (EDP) Descripción del EDP Estimaciones globales, diagramas de Gantt y de sectores Identificación de riesgos y planes de acción Aplicación Web Análisis Descripción del proceso general Terminología Catálogo de requisitos Modelo de Casos de Uso Vistas de interacción Análisis del modelo de datos Análisis de requisitos de las interfaces Diseño Definición de la arquitectura Documentación 3

7 3.2.2 Diseño de las clases Diseño de la base de datos Prototipo de interfaces de usuario Construcción Código relevante Interfaces finales Seguridad Pruebas Aplicación de Impresión Análisis Terminología Catálogo de requisitos Modelo de Casos de Uso Análisis del modelo de datos Diseño Definición de la arquitectura Diseño de la base de datos Prototipo de interfaces de usuario Construcción Código relevante Interfaces finales Pruebas Gestión del Proyecto Gestión prevista del proyecto Gestión no prevista del proyecto Gestión real del proyecto Comparativas Conclusiones Opinión personal Futuras mejoras Bibliografía Documentación 4

8 8 anexo 1 - pruebas Test de la aplicación web Test final por parciales Test final completo Test de la aplicación de impresión ÍNDICE DE ILUSTRACIONES Ilustración 1: Gráfico estructura descomposición del proyecto (EDP) Ilustración 2: Diagrama de Gantt: PFC Reprografía Online Ilustración 3: Diagrama de Gantt: Dirección-Gestión-Seguimiento del proyecto Ilustración 4: Diagrama de Gantt: Documentación del proyecto Ilustración 5: Diagrama de Gantt: Aplicación web Ilustración 6: Diagrama de Gantt: Aplicación web - Análisis Ilustración 7: Diagrama de Gantt: Aplicación web - Diseño Ilustración 8: Diagrama de Gantt: Aplicación web - Construcción Ilustración 9: Diagrama de Gantt: Aplicación de impresión Ilustración 10: Diagrama de sectores: Coste de tiempos del proyecto Ilustración 11: Diagrama de sectores: Coste de tiempos de la aplicación web Ilustración 12: Diagrama de sectores: Coste de tiempos de la aplic. de impresión Ilustración 13: Diagrama de casos de uso de la aplicación web Ilustración 14: Diagrama de actividad: Alta Socio Ilustración 15: Diagrama de actividad: Identificación Ilustración 16: Diagrama de actividad: Olvidar contraseña Ilustración 17: Diagrama de actividad: Añadir producto Ilustración 18: Diagrama de actividad: Realizar pedido Ilustración 19: Diagrama de secuencia: Alta socio Ilustración 20: Diagrama de secuencia: Identificación Ilustración 21: Diagrama de secuencia: Olvidar contraseña Ilustración 22: Diagrama de secuencia: Añadir Paquete Ilustración 23: Diagrama de secuencia: Realizar pedido Ilustración 24: Esquema de entidad relación Ilustración 25: Arquitectura Cliente- servidor en 3 niveles Ilustración 26: UML de las clases del modelo de negocio Ilustración 27: Modelo lógico de la aplicación web Ilustración 28: Interfaz principal de Usuario Invitado Ilustración 29: Interfaz principal de Usuario Registrado Ilustración 30: Interfaz principal de Usuario Administrador Documentación 5

9 Ilustración 32: Diagrama de Casos de Uso: Aplicación de impresión Ilustración 33: Diagrama de Actividad: Envío SMS Ilustración 34: Diagrama de Actividad: Marcar Pedido Entregado Ilustración 35: Esquema E/R: Entidad Paquete Ilustración 36: Esquema E/R: Entidad Pedido e HistoricoPedido Ilustración 37: Módelo lógico de la aplicación de impresión Ilustración 38: Gráfico de horas estimadas del proyecto Ilustración 39: Gráfico de horas reales del proyecto Ilustración 40: Gráfico de comparativa entre horas estimadas y horas empleadas Documentación 6

10 INTRODUCCIÓN Documentación 7

12 1 INTRODUCCIÓN 1.1 Especificación del proyecto La idea de este proyecto es el desarrollo de un sistema de reprografía online llevado a cabo para un cliente real, consistente en dos aplicaciones web, una destinada a los clientes de la empresa y su gestión, que de ahora en adelante llamaremos Aplicación Web, y otra destinada a los empleados para proceder a la impresión, que de ahora en adelante llamaremos Aplicación de Impresión. El sistema formado por las dos aplicaciones lo llamaremos Aplicación Completa. En la aplicación web, además de mostrar lo referente a los productos ofrecidos, un usuario bajo registro pueda solicitar la impresión sus archivos en cualquiera de los formatos permitidos. Posteriormente, desde la aplicación de impresión, los empleados de la empresa podrán imprimir los archivos. En el servidor en el cual estarán alojadas las aplicaciones, se diseñara un sistema en el cual los archivos que han sido enviados para su impresión, quedarán ordenados en un sistema de carpetas y archivos basados en una nomenclatura determinada. Por cada uno de los pedidos, se generará un nuevo documento que irá al inicio del conjunto del pedido, en el cual se especificarán todos los datos necesarios para la entrega. El resultado final que verá el cliente será la impresión de un documento con todos los datos del pedido y la impresión de todos los documentos incluidos en el pedido. Para un mayor entendimiento de las aplicaciones a desarrollar, a continuación se presenta un escenario habitual. 1. El usuario deberá estar registrado en la aplicación habiendo rellenado previamente en el momento de su registro un formulario con sus datos. 2. Para que el registro tenga lugar, el usuario deberá validar su cuenta mediante su correo electrónico. 3. Una vez registrado el usuario podrá entrar en la intranet con su nombre de usuario y contraseña. 4. Se elegirá un documento perteneciente a uno de los formatos permitidos como por ejemplo archivos con extensiones doc, docx, pdf y odt. 5. Se podrán seleccionar las propiedades de impresión que queramos dar a dicho documento. Documentación 9

13 6. Estas operaciones (pasos 4 y 5) se repetirán tantas veces se desee, siempre y cuando no se superen los límites económicos establecidos por la aplicación. 7. Una vez finalizado el pedido, se elegirá la forma de entrega, recogida o envío introduciendo los datos oportunos. 8. Se especificará, si se desea factura o albarán del producto, introduciendo los correspondientes datos. 9. Todos los datos del pedido y su fichero se enviarán al servidor. 10. En la interfaz del usuario, aparecerá una plataforma de pagos donde abonar los costes producidos. 11. Una vez realizado el pago, se confirmará el pedido y el sistema enviará un correo electrónico al cliente con los datos del pedido. A la par, la plataforma de pagos enviará otro correo electrónico con los datos del pago. En caso de que ocurra algún problema durante el pago, la siguiente vez que se conecte a la aplicación tendrá la opción de recuperar su pedido o cancelarlo. 12. El empleado de la empresa reprográfica, se conectará a la aplicación de impresión creada propiamente para este fin, desde la cual se le facilitará la impresión de los documentos del servidor. 13. Tras la finalización de la impresión del documento desde la propia aplicación, se enviará un mensaje de texto al teléfono móvil del usuario para avisarle, bien para que pase a recogerlo, en caso de que la forma de entrega elegida sea recogida en el local, o bien indicándole que su pedido ya ha sido enviado al domicilio indicado, en caso de haberse decantado por el envío a domicilio. 14. Una vez se haya procedido a la entrega del pedido, desde la aplicación se pasarán los datos de dicho pedido a un histórico. El usuario registrado dispondrá en la aplicación Web principal de diferentes módulos para ver y modificar su cuenta, así como para visualizar su historial de pedidos en la aplicación. Existirá un tipo de usuario administrador que tendrá módulos para ver todo lo que ocurre en la aplicación, estadísticas, manuales de uso y dispondrá de un módulo para la gestión de históricos de la base de datos. Documentación 10

14 El proyecto, es una idea propia, propuesta por el desarrollador y aceptada por una empresa. El producto se implementará en la empresa PYC Papel y Copia, la cual impondrá los requisitos que desea para el producto final. Los derechos sobre el producto los mantendría el proyectante, en este caso mi persona, con objeto de poder implantar el prototipo en otras empresas en un futuro. 1.2 Motivo de elección La realización de este proyecto parte de la necesidad real de un sector empresarial que todavía no ha desarrollado herramientas dedicadas a fines comerciales vía online. El interés mostrado por empresas del sector en la realización de esta aplicación (especialmente la reprografía PYC Papel y Copia, para la cual, previo al comienzo del desarrollo del producto, ya existe un acuerdo para la integración del producto) ha llevado al proyectante a desarrollar éste como su proyecto fin de carrera. Documentación 11

16 DOCUMENTO DE OBJETIVOS DEL PROYECTO (DOP) Documentación 13

18 2 DOCUMENTO DE OBJETIVOS DEL PROYECTO 2.1 Antecedentes Una empresa de reprografía de venta directa al público, como cualquier empresa del sector terciario que se precie, tiene una serie de clientes que acuden al local de la empresa para realizar in situ sus pedidos. Los pedidos pueden ser de lo más variados puesto que existen diferentes alternativas en cada tipo de actividad que dicha empresa ofrece. Una de las actividades que ocupan gran parte de los recursos humanos de la empresa se basa en la impresión de documentos. Éstos son llevados por el usuario al local en dispositivos de almacenamiento. Aquí se producirá un proceso de espera debido a la atención del resto de usuarios que están por delante en la cola. En el momento de la atención, el cliente entrega dicho dispositivo al empleado y le específica, tanto los archivos que desea que se impriman, como la forma en la cual quiere que quede el resultado final de la impresión. De esta forma, el empleado introduce el dispositivo de almacenamiento en el ordenador, busca y selecciona el archivo a imprimir, piensa, calcula y especifica el formato resultante del documento, y finalmente lo imprime. Posteriormente, le entrega al usuario su dispositivo y la documentación impresa, calcula el coste y realiza el cobro. Aparentemente es un proceso sencillo. Existen unas variables de impresión que el cliente debe elegir. También puede darse el caso de equivocarse en el cálculo del coste. Por ello, consideramos que estas tareas se pueden minimizar, agilizar o expandir mediante el uso de las nuevas tecnologías. Así, partiendo de la necesidad de la empresa de agilizar y expandir el negocio, surge la idea de la creación de un software específico que satisfaga estas necesidades. Dicho software debe adaptarse, tanto a las necesidades de la empresa como a las de los usuarios finales, debiendo ser así una herramienta de carácter útil, sencilla y lo más completa posible para ambos. El hecho de no existir una aplicación de carácter general y de venta pública establecida dedicada a este fin, conlleva a la empresa que quiera instaurarlo a solicitar su creación. Documentación 15

19 Tras contactar con empresas del sector, parece interesar la idea de desarrollar la aplicación. Concretamente una de ellas muestra especial interés (PYC Papel y Copia) por lo que se decide realizar el desarrollo de las aplicaciones, web y de impresión, de acorde con los requisitos que nos establece la empresa, teniendo en cuenta que dichos requisitos son lo suficientemente independientes de la empresa PYC como para poder adaptar fácilmente la aplicación final a otras empresas del sector. 2.2 Universo del proyecto La funcionalidad de la aplicación web se basará en la prestación de recursos a los clientes de la empresa para la gestionar la impresión de sus documentos. El usuario, del cual se supone que dispone de una conexión a internet y una forma de realización de pago por internet, se dirigirá a la dirección web de la empresa para la realización del trámite. Una vez dentro, suponiendo que esté registrado previamente, procederá a identificarse. Existirán varios tipos de usuarios en la aplicación web o roles como pueden ser usuario administrador, usuario registrado o usuario invitado, cada uno de ellos dispondrá de su propia interfaz. Para la aplicación de impresión existirá otro tipo de usuario, el usuario empleado. Cuando un usuario entra en la aplicación web de inicio lo hará como un usuario invitado hasta el momento en que se registre o identifique. Tras la identificación y variando según sea su rol, accederá a la interfaz correspondiente, pudiendo ser ésta de usuario registrado o usuario administrador. En el caso más habitual, es decir de un usuario registrado, su interfaz dispondrá de herramientas para gestionar sus pedidos y su cuenta. Solo habrá un usuario administrador, predefinido al inicio de la aplicación web por el programador con el fin de proporcionar una mayor seguridad al sistema. Tendrá una interfaz donde podrá realizar operaciones sobre los usuarios y consultar estadísticas que puedan aportar mejoras para la aplicación. Además podrá visualizar los organigramas de la web, de la base de datos y el manual de la aplicación. También podrá gestionar los históricos de los pedidos. En lo que se refiere a la aplicación de impresión, solamente tendrá un usuario empleado, predefinido al inicio de la aplicación por el programador. Tendrá una interfaz donde podrá realizar todas las operaciones de impresión, aviso al cliente y entrega del producto imprimido. Documentación 16

20 Todos los archivos que se van recibiendo pasarán al servidor ordenados mediante un sistema de carpetas y archivos. Este sistema lo diseñaremos de forma que quede lo mejor estructurado posible para facilitar la labor de la aplicación de impresión. Una vez alojados estos archivos, a través de una aplicación expresamente diseñada para facilitar la impresión a la empresa, con la ayuda del empleado, se imprimirán los archivos de acorde a los parámetros establecidos. También, desde dicha aplicación se podrán enviar los mensajes de texto a los clientes de la empresa. Una vez los pedidos hayan sido entregados, se pasarán a un histórico de pedidos. Con el tiempo, una vez comprobado que las entregas han sido correctas y estimando un tiempo adecuado en el que no se hayan registrado quejas por parte de los usuarios finales del producto, se eliminarán los archivos que anteriormente fueron imprimidos. 2.3 Intención del proyecto La intención de nuestro proyecto es la automatización de impresión de documentos en formato informático, reduciendo el tiempo de espera, la indicaciónrecepción de órdenes de impresión de forma verbal, el sistema de cálculo de costes, el pago-cobro en efectivo e incluso el desplazamiento a la sede de la empresa en caso de envió postal. De esta forma, con este sistema informático facilitaremos las operaciones, agilizaremos el trabajo, controlaremos mejor los costes, reduciremos costes laborales y permitiremos al usuario visualizar, y por tanto utilizar, todas las diferentes opciones de impresión para que personalice el producto final. El uso de esta aplicación debe ser fácil y sencillo tanto para clientes como para los empleados de producción. La seguridad en los sistemas de pago debe ser una clave importante a valorar, puesto que el cliente debe sentirse seguro. 2.4 Participantes Personas o empresas que participan en el proyecto y el papel que desempeñan: o Cliente en versión final: o Dirección del proyecto: o Desarrollador del Proyecto: PYC Papel y Copia Beatriz Pérez Valle José Ramón Herce Martínez Documentación 17

21 2.5 Comunicación La fase de desarrollo del proyecto irá guiada por la directora de proyecto, la profesora Beatriz Pérez Valle, perteneciente al Departamento de Matemáticas y Computación de la Universidad de La Rioja. Durante el proceso de desarrollo del proyecto es posible que surjan dudas técnicas sobre la creación del producto que sean ajenas a la dirección del proyecto y que necesitaremos que sean solventadas por expertos en la materia que están a nuestra disposición, como son los profesores de la universidad. Partiremos de la comunicación con la empresa para el establecimiento de unos requisitos iniciales. Estos deberán ser claros, fijos e inamovibles para el buen transcurrir del proyecto. Esta comunicación se llevará a cabo de forma verbal y el resultado de esta consecución de requisitos quedará anotado y firmado para evitar problemas de cara al futuro. Durante el desarrollo de la aplicación, los canales de comunicación con los diferentes actores participantes en la consecución del proyecto serán los siguientes: Correo Electrónico: mediante este medio solventaremos las dudas básicas que surjan en el desarrollo del proyecto. También por este medio se enviarán las documentaciones realizadas, así como las actas creadas en las reuniones. Reuniones: o Con la empresa: Durante todo el proceso de creación estaremos en continuo contacto con la empresa para satisfacer en todos los aspectos del desarrollo las necesidades de la aplicación. o Con la directora de proyecto: Cada reunión con la directora de proyecto vendrá recogida en su correspondiente acta que posteriormente se enviará al correo electrónico de la directora. Las reuniones se solicitarán previamente mediante el correo electrónico. o Con asesores: En caso de ser necesario, solicitaremos reuniones con dichos asesores mediante el uso del correo electrónico, para acordar un lugar de encuentro en el que resolver las dudas que el proyecto haya originado. Tras la finalización del proceso de creación de la aplicación completa nos trasladaremos en la fase de instalación y pruebas en la empresa. Allí la comunicación será verbal, puesto que estaremos en contacto presencial con los encargados y empleados, a los cuales se les ofrecerá un curso acerca del manejo de cada uno de los módulos de la aplicación completa. Documentación 18

22 2.6 Entregables Terminado el PFC se entregará lo siguiente: Documento de Objetivos del Proyecto (DOP) Memoria del PFC. Producto final a entregar a cliente. o Aplicación web de la reprografía. o Aplicación de impresión de la reprografía. o Credenciales de usuarios 2.7 Tecnologías a utilizar En un principio, se barajaban 2 entornos de programación: J2EE ó PHP. A la hora de decidir por una opción u otra, se valoraron diferentes aspectos como el futuro exitoso de ambos lenguajes de programación en el desarrollo web o el conocimiento del desarrollador de ambos entornos. Finalmente, tras realizar una estimación de tiempos de desarrollo con ambas tecnologías, y debido a la necesidad de una rápida realización, se decidió por la utilización de PHP. Para el desarrollo de este entorno de programación usaremos el IDE NetBeans en su versión , al ser la más estable pese a no ser la más actual. Para cuestiones de diseño también utilizaremos el entorno Adobe Dreamweaver en su versión CS5. Respecto al Sistema Gestor de Base de Datos (SGBD), utilizaremos MySql. Las razones para el uso de éste son su libre distribución (importante en la viabilidad económica del proyecto, debido al elevado coste de otros sistemas), así como la amplia capacidad del sistema para cubrir las necesidades de nuestro proyecto. Como herramienta para la administración de MySql utilizaremos PHPMyAdmin y MySQLAdministrator. Durante la fase de desarrollo en servidor local usaremos la plataforma XAMPP en su última versión 1.8.1, la cual nos ofrecerá además del servidor, el servicio de base de datos PHPMyAdmin que posteriormente usaremos en el servidor final de la aplicación. También, durante la fase de desarrollo local, usaremos el servicio Mercury para el envío de correos electrónicos desde el servidor local. Para el envío de mensajes de texto usaremos el entorno creado SMS. Documentación 19

23 2.8 Documentación necesaria Durante el proceso del PFC necesitaremos: Documentación sobre lenguaje PHP. Documentación sobre lenguaje SQL. Manual de XAMPP. Manual de NetBeans IDE. Manual de PHPMyAdmin. Manual de JavaScript. Documentación sobre instalación de protocolos criptográficos SSL. No se descarta tener que recurrir a foros o páginas especializadas para la búsqueda de recursos técnicos o solución de cualquier problema que se nos plantee. 2.9 Metodología del desarrollo de software Tras valorar las diferentes alternativas existentes como son el Proceso Unificado de Desarrollo de Software, Top Down, Rapid Application Development (RAD), Proceso Unificado de Rational (RUP), modelo en espiral y otros modelos, decidimos seguir el modelo en cascada, también llamado modelo tradicional o clásico. El modelo en cascada es un enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior. Se distinguen las siguientes fases: Análisis Diseño Construcción Pruebas Capacitación y entrega parcial Las razones que nos hacen llegar a esta decisión son: El PFC no es de gran envergadura como para seguir una de metodología compleja. La fase de desarrollo del proyecto se realizara de forma individual en su totalidad, por lo que evitará la mayor desventaja en el uso de este modelo. La desventaja de esta metodología es la tardía detección de errores, por tanto, es preciso otorgar una mayor dedicación a las fases de análisis y diseño. Esta metodología será utilizada por separado en las aplicaciones a realizar. Documentación 20

24 2.10 Planificación del proyecto En esta sección se mostrarán las horas asignadas para cada una de las etapas del proyecto, así como la Estructura de Descomposición del Proyecto (EDP), donde se pueden observar las tareas que se realizarán Estructura de descomposición del proyecto (EDP) Ilustración 1: Gráfico estructura descomposición del proyecto (EDP) Documentación 21

25 Documentación 22

26 Descripción del EDP Dirección-gestión del proyecto Recogeremos la información sobre la forma de gestionar el proyecto. PLANIFICACIÓN Diferenciar las partes en las que esté dividido el proyecto para que desarrollador y cliente puedan tener un concepto claro de la situación o fase en la que se encuentra el proyecto. ESTIMACIÓN: 3 HORAS REUNIONES o REUNIONES CON LA DIRECTORA DE PROYECTO Se adoptarán una serie de reuniones programadas con la directora del proyecto para valorar el trabajo realizado, acordar las siguientes fases o resolver las dudas que se generen. También se tratará la finalización del proyecto, presentación y defensa. ESTIMACIÓN: 10 HORAS o REUNIONES CON ASESORES DEL PROYECTO Durante el desarrollo del proyecto nos surgirán dudas específicas y técnicas y por tanto recurriremos a expertos en la materia. ESTIMACIÓN: 3 HORAS SEGUIMIENTO Se realizará un seguimiento del proyecto tanto por correo electrónico, como presencialmente, con la directora de proyecto. Se expondrá resumidamente lo realizado desde la última reunión, retraso y el estado actual del proyecto. Se irá enviando informes del progreso incluyendo las desviaciones en la planificación. ESTIMACIÓN: 8 HORAS DELIMITACIÓN DEL PROYECTO La magnitud del proyecto puede ser muy amplia al existir siempre infinidad de mejoras. Es labor del desarrollador delimitar la versión entregable del proyecto. ESTIMACIÓN: 2 HORAS Estimación: 26 horas Documentación 23

27 Documentación del proyecto Todo proyecto debe estar documentado de principio a fin e incluirá cada uno de los aspectos que se traten en él. Sigue una estructura predeterminada. GENERACIÓN DEL DOCUMENTO DE OBJETIVOS DEL PROYECTO (DOP) El DOP, es el documento que incluye los objetivos que el proyecto quiere conseguir. Requiere de su presentación y aprobación entre el alumno y el tutor. Pueden producirse cambios sobre el guion marcado. ESTIMACIÓN: 15 HORAS GENERACIÓN DE LA MEMORIA La memoria es el documento en el cual va incluido toda lo referente al Proyecto de Fin de Carrera. Expresa por fases de desarrollo todo lo realizado en el proyecto. Estará redactada de forma concisa y clara. Lo no estrictamente necesario aparecerá en anexos. ESTIMACIÓN: 55 HORAS PREPARACIÓN DE LA PRESENTACIÓN De cara a la defensa del proyecto debemos preparar una exposición que presente los objetivos, desarrollo y consecución de nuestro proyecto. ESTIMACIÓN: 9 HORAS DEFENSA DEL PROYECTO El proyecto debe ser evaluado por un tribunal formado por profesores del Departamento de Matemáticas y Computación. Dicho departamento nos proporcionará un día, una hora y un lugar en el que defender nuestro proyecto usando la presentación nombrada en el punto anterior. ESTIMACIÓN: 1 HORA Estimación: 80 horas Documentación 24

28 Formación Todo proyecto generalmente tiene una parte en su desarrollo en la cual su conocimiento en la materia se desconoce, más, si como es el caso, se trata de un Proyecto Fin de Carrera, en el que el usuario además de no partir con la experiencia de un trabajador dedicado al sector, tampoco conoce todas las técnicas de desarrollo. Tras una evaluación previa sobre las tecnologías que debemos conocer para la realización de la aplicación, nos damos cuenta que, en mayor o menor medida, necesitaremos un aprendizaje de cada uno de ellos. No buscaremos el aprendizaje total de los entornos sino de lo necesario para llevar a cabo nuestras tareas, por tanto, nuestra formación será continua, sin una planificación previa. Así, a medida que surjan los problemas, buscaremos la solución. Los entornos que manejaremos y por tanto de los que necesitaremos formación serán: Lenguaje PHP Lenguaje JAVASCRIPT Formación en JQUERY Formación en instalación APACHE Formación en instalación MERCURY Formación sobre instalación en SERVIDORES WEB Estimación: 50 horas Documentación 25

29 Aplicación Web En este apartado, incluimos todo lo referente a la aplicación web, separado en cada una de sus fases (análisis, diseño, construcción, pruebas e implantación). ANALISIS Durante esta fase nos dedicaremos al análisis de la aplicación web. Para ello expondremos, mediante diferentes diagramas acompañados de su correspondiente explicación, las pautas que debe seguir nuestro programa para la consecución de cada uno de sus objetivos. o DIAGRAMA DE CASOS DE USO, ESPECIFICACIÓN DE CASOS DE USO Y DIAGRAMAS DE ACTIVIDAD Diagramas diseñados utilizando el Lenguaje de Modelado Unificado (UML), que nos ofrecerá una perspectiva general y posteriormente individualizada del comportamiento de la aplicación. Describe mediante notación gráfica, el comportamiento global de la aplicación. En el caso de ser un caso de uso complejo, éste irá acompañado de un diagrama de actividad. Los diagramas de actividad, por otro lado, describen una mejor idea del caso de uso. Los diagramas de actividad describen el flujo de trabajo de la actividad, su comportamiento general, así como cada alternativa dada a dicha línea habitual. ESTIMACIÓN: 15 HORAS o VISTAS DE ITERACCIÓN Para casos de uso específicos, indicaremos todos sus escenarios significativos mediante notación gráfica. Para ello vamos a usar los Diagramas de Secuencia del Sistema (DSS) que muestra los eventos que un actor genera durante la interacción con el sistema. ESTIMACIÓN: 3 HORAS o ANALISIS DEL MODELO DE DATOS Crearemos una pre-relación entre todos los componentes de la aplicación para que posteriormente sea plasmada en el Esquema de Entidad-Relación (EER) y/o el Diagrama de Clases diseñados en el Lenguaje de Modelado Unificado (UML). ESTIMACIÓN: 7 HORAS Documentación 26

30 o PROTOTIPO DE INTERFACES Crearemos una idea previa al diseño en la que expondremos una perspectiva inicial de cómo queremos que sea nuestro sistema. ESTIMACIÓN: 5 HORAS ESTIMACIÓN PARCIAL : 30 HORAS DISEÑO Expondremos mediante diferentes diagramas, textos y otros útiles, acompañados de su correspondiente explicación, las pautas que debe seguir nuestra aplicación a la hora de su construcción. o DISEÑO DE BASE DE DATOS Necesitaremos un buen diseño de almacenamiento de datos para evitar cualquier tipo de problema posterior. Nos ayudaremos de diagramas y los documentaremos. ESTIMACIÓN: 6 HORAS o DISEÑO DE CLASES DE NEGOCIO IDENTIFICACIÓN Observación y detección de clases de negocio para nuestra aplicación. Estas serán utilizadas en los posteriores diagramas. Trascendente en el desarrollo. ESTIMACIÓN: 8 HORAS DIAGRAMAS Las clases de negocio deberán estar relacionadas entre sí para darles algún sentido en su uso. Durante esta fase detectaremos esas relaciones y las plasmaremos en el documento junto con las clases de negocio nombradas. ESTIMACIÓN: 5 HORAS DOCUMENTAR CLASES Indicaremos el comportamiento y las propiedades de cada clase de negocios y sus relaciones. ESTIMACIÓN: 3 HORAS Documentación 27

31 o DISEÑO DE INTERFACES GENERACIÓN DE INTERFACES Diseñaremos forma y propiedades de las interfaces para su construcción en fases siguientes. ESTIMACIÓN: 5 HORAS DOCUMENTAR INTERFACES Las interfaces creadas deberán ir justificadamente explicadas de forma que se puedan consultar el cómo y el porqué de la realización de dichas interfaces. ESTIMACIÓN: 3 HORAS ESTIMACIÓN PARCIAL: 30 HORAS CONSTRUCCIÓN Implementación de la aplicación web. Parte central de toda nuestra aplicación web y lo realmente visible de cara al cliente. Tarea más costosa del proyecto. o CREACIÓN DEL SCRIPT DE LA BASE DE DATOS Este script se creará a partir del modelo lógico establecido en la fase de diseño. ESTIMACIÓN: 5 HORAS o IMPLEMENTACIÓN Utilizando las técnicas y herramientas de las cuales disponemos y siguiendo los diagramas creados durante la fase de diseño construiremos la aplicación. ESTIMACIÓN: 100 HORAS o GENERACIÓN DE LA AYUDA Sistema de ayuda al usuario final a resolver sus dudas bien sea del proceso o de términos u operando por otro sistema aparentemente más sencillo para el usuario. Solo disponible para alguna de las opciones de la aplicación. ESTIMACIÓN: 10 HORAS ESTIMACIÓN PARCIAL: 120 HORAS Documentación 28

32 PRUEBAS Se realizarán las pruebas pertinentes para comprobar el correcto comportamiento de la aplicación. o PRUEBA DE BASE DE DATOS Se probará el correcto comportamiento de la base de datos en su uso, de forma que puedan surgir errores en el diseño de la misma. El correcto funcionamiento producirá su finalización. ESTIMACIÓN: 4 HORAS o PRUEBAS UNITARIAS DE LA APLICACIÓN Con las pruebas unitarias cada apartado de la aplicación probamos el correcto funcionamiento de los módulos de código de forma individual Incluiremos dentro de este apartado las pruebas de integración en el cual comprobaremos el correcto comportamiento en la unión de dichos módulos. ESTIMACIÓN: 8 HORAS ESTIMACIÓN PARCIAL: 12 HORAS IMPLANTACIÓN DEL SISTEMA Consiste en instaurar el sistema ya finalizado y probado en el lugar de trabajo, para ello necesitaremos el manual de instalación. o INSTALACIÓN DEL EQUIPO Durante esta tarea se logrará la correcta instalación de un equipo en la empresa. ESTIMACIÓN: 2 HORAS o INSTALACION DE LA APLICACIÓN WEB Durante esta tarea se lograra la correcta instalación de la aplicación web en el servidor web. Para ello usaremos el manual de instalación de la aplicación. ESTIMACIÓN: 3 HORAS ESTIMACIÓN PARCIAL: 5 HORAS Estimación: 212 horas Documentación 29

33 Aplicación de impresión En este apartado incluimos todo lo referente a la aplicación de impresión separado en cada una de sus fases (análisis, diseño, construcción, pruebas e implantación). No se explicará con tanto detalle porque ya se ha descrito para la aplicación web. ANALISIS Evaluaremos todas las alternativas para la realización de la aplicación y elegiremos la opción que creamos más correcta. Posteriormente los expondremos mediante diferentes diagramas acompañados de su correspondiente explicación. ESTIMACIÓN: 8 HORAS DISEÑO Durante esta fase nos dedicaremos al diseño de la aplicación de impresión. Para ello expondremos mediante diferentes diagramas, textos y otros útiles, acompañados de su correspondiente explicación, las pautas que nuestra aplicación debe seguir en su construcción. ESTIMACIÓN: 11 HORAS CONSTRUCCIÓN Implementación de la parte visible de la aplicación de impresión. Programaremos lo anteriormente especificado en la fase de diseño. También crearemos lo referente a la ayuda de usuario y documentación del código. ESTIMACIÓN: 45 HORAS PRUEBAS Realizaremos las pruebas pertinentes para comprobar el correcto comportamiento de la aplicación. En el caso de encontrarse errores, se tendrán que solventar y en el caso de no encontrarse, se dará por finalizada la parte de implementación. ESTIMACIÓN: 3 HORAS IMPLANTACIÓN DEL SISTEMA Consiste en instaurar el sistema ya finalizado y probado en el lugar de trabajo. Usaremos el manual de instalación de la aplicación. ESTIMACIÓN: 3 HORAS Estimación: 70 horas Documentación 30

34 DIRECCIÓN Y GESTION DEL PROYECTO Planificación Reuniones con la directora Reuniones con los asesores Seguimiento Limitación del proyecto DOCUMENTACIÓN DEL PROYECTO Generación DOP Generación de la memoria Preparación de la presentación Defensa del proyecto HORAS ESTIMADAS FORMACIÓN 50 APLICACIÓN WEB Análisis Diagramas de Casos de uso, especificación de casos de uso y diagramas de actividad Vistas de Interacción Análisis del modelo de datos Prototipo de interfaces Diseño Diseño de la base de datos Diseño de las clases de negocio Identificación Diagramas Documentación de clases Diseño de interfaces Generación de interfaces Documentación interfaces Construcción Generación del Script de la base de datos Implementación Generación de la ayuda Documentación de código Pruebas Prueba de la base de datos Pruebas unitarias de la aplicación Implantación Implantación del equipo Implantación de la aplicación web APLICACIÓN DE IMPRESIÓN Análisis Diseño Implementación Pruebas Implantación del sistema TOTAL 438 Documentación 31

36 Estimaciones globales, diagramas de Gantt y de sectores. La estimación total de tiempo para llevar a cabo la aplicación es de 438 horas. De las cuales se espera realizar semanalmente una media de 8,5 horas para lograr completar el proyecto. La media sale teniendo en cuenta los momentos seguros en los que el proyecto este parado por otros motivos que valoraremos más adelante. Estimamos que el tiempo para la consecución en su totalidad del proyecto será de 1 año hábil desde su comienzo en octubre de PFC REPROGRAFÍA ONLINE: 438 horas Ilustración 2: Diagrama de Gantt: PFC Reprografía Online. DIRECCIÓN-GESTIÓN-SEGUIMIENTO DEL PROYECTO: 26 horas Ilustración 3: Diagrama de Gantt: Dirección-Gestión-Seguimiento del proyecto. Documentación 33

37 DOCUMENTACIÓN DEL PROYECTO: 80 horas Ilustración 4: Diagrama de Gantt: Documentación del proyecto. APLICACIÓN WEB: 212 horas Ilustración 5: Diagrama de Gantt: Aplicación web. Documentación 34

38 APLICACIÓN WEB - ANÁLISIS: 30 horas Ilustración 6: Diagrama de Gantt: Aplicación web - Análisis. APLICACIÓN WEB DISEÑO: 30 horas Ilustración 7: Diagrama de Gantt: Aplicación web - Diseño. Documentación 35

39 APLICACIÓN WEB CONSTRUCCIÓN:135 horas Ilustración 8: Diagrama de Gantt: Aplicación web - Construcción. APLICACIÓN DE IMPRESION: 70 horas Ilustración 9: Diagrama de Gantt: Aplicación de impresión. Documentación 36

40 COSTE DE TIEMPOS EN LA PLANIFICACIÓN DEL PROYECTO En la siguiente gráfica podemos ver la estimación de tiempo dedicada a cada parte del proyecto. Dirección y gestion del proyecto Formación Aplicación de impresión 16% 48% Documentación del proyecto Aplicación web 6% 18% 12% Ilustración 10: Diagrama de sectores: Coste de tiempos del proyecto. COSTE DE TIEMPOS EN LA PLANIFICACIÓN DE LA APLIACIÓN WEB En la siguiente gráfica podemos ver la estimación de tiempo dedicada a cada parte de la aplicación web. Claramente la construcción es la parte que más tiempo dedicaremos. 6% 3% 15% 61% 15% Análisis Diseño Construcción Pruebas Implantación Ilustración 11: Diagrama de sectores: Coste de tiempos de la aplicación web. Documentación 37

41 COSTE DE TIEMPOS EN LA PLANIFICACIÓN DE LA APLIACIÓN DE IMPRESIÓN En la siguiente gráfica podemos ver la estimación de tiempo dedicada a cada parte de la aplicación de impresión. Claramente la construcción es la parte que más tiempo dedicaremos. Pruebas Construcción Implantación Análisis Diseño 4% 11% 17% 4% 64% Ilustración 12: Diagrama de sectores: Coste de tiempos de la aplic. de impresión. Documentación 38

42 2.11 Identificación de riesgos y planes de acción Se refiere a la posibilidad de sufrir causas negativas en el desarrollo del proyecto, es por ello que se deben analizar los riesgos que pueden dar lugar y sus posibles soluciones. En caso de que se produzca algún daño durante el desarrollo del proyecto, se tomarán las medidas adecuadas para que no se produzca una parada en éste. A continuación, se listan los riesgos más probables, así como sus planes de acción: Problemas de carácter personal por parte del alumno. o Riesgo: El proyecto se desarrolla durante un periodo tan largo de tiempo que no se pueden determinar circunstancias ocurrentes que alteren la planificación como puede ser problemas de abandono temporal por enfermedad u otra causa que priorice o necesite de una mayor dedicación en nuestra vida. o Probabilidad del suceso: Alta. o Momento previsto: En cualquiera de las fases de desarrollo. o Plan de contingencia: Si ocurre este riesgo afectará en la planificación de fechas, surgiendo así un cambio que produzca retraso en dicha planificación y que, por consiguiente, afectará de forma consecutiva a las siguientes fases o tareas. Exámenes, trabajos o nuevos proyectos de mayor prioridad. o Riesgo: El hecho de llevar paralelamente al proyecto otras tareas de índole educativa y necesaria su superación para la presentación del proyecto, implicará que se le ofrezca a éstas una mayor prioridad. Estas tareas pueden estar determinadas temporalmente y por tanto se cuentan con ellas en la planificación del proyecto. Pero también pueden ser inesperadas y por tanto afectar a la planificación de fechas del proyecto. o Probabilidad del suceso: Segura. o Momento previsto: En momentos previstos de las fases de desarrollo. o Plan de contingencia: Este riesgo está contemplado en mayor medida puesto que están fijadas las fechas en las que ocurre. Puede surgir un cambio de forma imprevista. En ese caso surgirá un cambio que seguramente produzca un retraso en dicha planificación y que por consiguiente afectará de forma consecutiva a las siguientes fases o tareas. Documentación 39

43 Errores en la estimación de fechas del proyecto o Riesgo: Es posible que se calculen tiempos de forma optimista en la consecución de las fases o tareas produciendo un sobrecoste de tiempo en la planificación de fechas del proyecto. También es posible pero menos común que se estime de forma pesimista de forma que sobrara tiempo, pero eso no producirá un riesgo. Este fallo puede ser producido por la evidente inexperiencia del desarrollador, puesto que es la primera vez que se enfrenta a un proyecto de esta dimensión. o Probabilidad del suceso: Muy alta. o Momento previsto: En cada momento de las fases de desarrollo. o Plan de contingencia: En caso de ocurrir este riesgo afectará en la planificación de fechas, surgiendo así un cambio que produzca retraso en dicha planificación y que, por consiguiente, afectará de forma consecutiva a las siguientes fases o tareas. Problemas de software o hardware en el equipo que se desarrolla el proyecto o Riesgo: Durante el transcurso del proyecto es posible que surjan problemas bien sea con el software o con el hardware del equipo que necesiten de un coste temporal para su solución y por tanto en consecuencia afecten a la planificación en fechas del proyecto. o Probabilidad del suceso: Baja. o Momento previsto: En momentos de las fases de desarrollo. o Plan de contingencia: Si ocurre este riesgo afectará en la planificación de fechas, surgiendo así un cambio que produzca retraso en dicha planificación y que, por consiguiente, afectará de forma consecutiva a las siguientes fases o tareas. Desconocimiento de herramientas necesarias en el desarrollo del proyecto o Riesgo: Por inexperiencia puede surgir el problema de dar por conocido un entorno que, a la hora de trabajar con él, sea necesaria la adaptación del alumno. Esto conllevará un sobrecoste temporal producido por la necesidad de conocimiento de esas herramientas. Esto afectará en la planificación de las fechas del proyecto, así como en las horas dedicadas a dichas fases. o Probabilidad del suceso: Alta. o Momento previsto: En momentos de las fases de desarrollo. o Plan de contingencia: Si ocurre este riesgo afectará en la planificación de fechas, surgiendo así un cambio que produzca retraso en dicha planificación y que, por consiguiente, afectará de forma consecutiva a las siguientes fases o tareas. Documentación 40

44 Tiempos de espera ajenos al desarrollador. o Riesgo: Es posible que no se pueda avanzar en una fase o pasar de una fase a otra hasta que no se esté conforme por parte del director de proyecto o bien hasta que no se solucione el problema por parte de alguno de los asesores. Si la solución de estos problemas se prolonga en el tiempo, bien sea por la inadaptación del desarrollador al problema, o bien sea porque director de proyecto o asesor no tenga disponibilidad en la atención, puede producir un sobrecoste temporal que afecte a la planificación en fechas del proyecto. o Probabilidad del suceso: Media. o Momento previsto: En momentos finales de las fases de desarrollo. o Plan de contingencia: Si ocurre este riesgo afectará en la planificación de fechas, surgiendo así un cambio que produzca retraso en dicha planificación y que, por consiguiente, afectará de forma consecutiva a las siguientes fases o tareas. Problemas en la integración del producto en la empresa. o Riesgo: Es posible que a la hora de la instalación de la aplicación en la empresa donde realizaremos las pruebas, para dicha empresa sea mal momento por diversos problemas ajenos al desarrollador y que desconoceremos mayoritariamente, como pueden ser flujo de trabajo excesivo que limita la atención a la integración de la aplicación, incapacidad de atención por parte de los empleados de la empresa por cualquier problema de carácter personal o cualquier otro problema. o Probabilidad del suceso: Media. o Momento previsto: En momentos finales de las fases de desarrollo. o Plan de contingencia: Si ocurre este riesgo afectará en la planificación de fechas, surgiendo así un cambio que produzca retraso en dicha planificación y que, por consiguiente, afectará de forma consecutiva a las siguientes fases o tareas. Documentación 41

46 APLICACIÓN WEB Documentación 43

48 3 APLICACIÓN WEB 3.1 Análisis Descripción del proceso general El primer objetivo del Proyecto Fin de Carrera consiste en la realización de una aplicación web que: Permita ser un escaparate de la empresa y de sus productos, poder ver su localización, contactar con ella y permita acceder a sus productos online. Permita al usuario realizar pedidos online, ver el estado en el que se encuentran y manejar su cuenta. Permita a un administrador, visualizar y controlar los aspectos más significativos de la aplicación, así como, en la medida de lo posible, interactuar con ellos. En esta aplicación se han identificado tres tipos de usuario: usuario invitado, usuario registrado y usuario administrador. La aplicación web constará de tres tipos de interfaces webs una para cada tipo de usuario que participa en ella. Cada uno de ellos deberá disponer de unas herramientas que se adecuen a su rol y que el sistema deba proporcionarle. Estableceremos una clara división en el manejo de los tres tipos de interfaces, en todas las fases de producción de la aplicación. Los pequeños detalles son los que, en definitiva, marcarán la calidad del producto Terminología Para familiarizarse con el lenguaje empleado en la reprografía online, se presenta una explicación sobre los términos más importantes mencionados en la documentación. Reprografic: Nombre, con el cual, denominaremos a la aplicación completa. Cliente: Usuario final de la empresa, y que corresponde con la persona que interactúa con la empresa con el objetivo de realizar las operaciones que ésta le ofrece. Sistema: conjunto formado por la aplicación web y la aplicación de impresión. Aplicación web: parte del producto final que consta de la página web donde el cliente realiza sus pedidos. Documentación 45

49 Pedido: como su nombre indica, se refiere al producto que el cliente crea con el objetivo de que la empresa lo produzca. Paquete: unidad de pedido, identifica cada una de las partes que componen el pedido final. Consta de un documento y propiedades de impresión. Histórico: se refiere a cuando, tanto para un pedido como para un paquete, ya han sido producidos por la empresa y por lo tanto han pasado a un registro de producciones pasadas. Usuario invitado: usuario que entra en la aplicación web sin ningún tipo de privilegio. Usuario registrado: usuario que tras un previo registro en la aplicación web puede realizar las diferentes operaciones que la empresa pone a su disposición. Usuario administrador: único usuario que tiene el privilegio de interactuar en la zona de administración de la aplicación web. PayPal: se refiere a la plataforma de pago externa que usa la aplicación web para realizar los cobros de sus productos vía internet. Intranet: parte de la aplicación web donde acceden los usuarios con privilegios (registrado y administrador) para usar las herramientas que el sistema le proporciona. Servidor web: sitio web donde están alojadas tanto la aplicación web como la aplicación de impresión para su uso compartido en la red. Dominio: dirección web desde el cual se puede acceder a las aplicaciones web Catálogo de requisitos Los requisitos mínimos a establecer con el cliente, serán alcanzados en su totalidad. En caso contrario, no se hará entrega del proyecto en las fechas establecidas hasta su consecución. Además de los requisitos mínimos, el cliente aportará unas mejoras a desarrollar que se llevarán a cabo en función del tiempo que se establece como límite y la prioridad de éstas Requisitos funcionales del sistema Por conveniencia del cliente, consideramos cuatro roles diferentes: usuario invitado, usuario registrado y usuario administrador. A continuación se muestran los requisitos pedidos al sistema. Los presentamos agrupados por bloques, ordenados de menor a mayor según su privilegio en la aplicación. Documentación 46

50 Requisitos Usuario Invitado El usuario invitado es aquel que entra en la aplicación web sin ningún tipo de privilegio. De primeras, hasta el momento en que realice su identificación, toda persona que entre en la aplicación será usuario invitado. Los requisitos de este usuario son los siguientes: El usuario invitado no necesitará ninguna credencial de identificación. Corresponde a cualquier usuario con una conexión a internet desde la cual acceder al dominio de la empresa podrá serlo. Desde el usuario invitado, puede realizarse la identificación para entrar en la interfaz de un usuario registrado o usuario administrador. Este tipo de usuario puede visualizar todas las características que, a modo de expositor, ofrece la empresa, como son una breve descripción de la empresa, la localización de la sede física de la empresa, formas de contactar, los productos que se ofrecen, así como sus precios y formas de entrega y pago. Desde el usuario invitado se ofrece un acceso directo a las redes sociales de las que dispone la empresa, como son las plataformas Facebook y Twitter. Un usuario podrá registrarse en la aplicación a través de un usuario invitado, accediendo a la zona de registro. Se podrá pedir desde un usuario invitado, siendo otro tipo de usuario con más privilegios, la contraseña con la que identificarse en caso de haber olvidado esta Requisitos Usuario Registrado El usuario registrado, es aquel usuario que tras haberse registrado en algún momento del pasado, ha entrado a la aplicación como usuario invitado y se ha identificado en la aplicación. Los requisitos de este usuario son los siguientes: El usuario registrado tendrá unas credenciales para identificarse con el sistema. Este tipo de usuario puede visualizar todas las características que, a modo de expositor, ofrece la empresa, como son una breve descripción de la empresa, la localización de la sede física de la empresa, formas de contactar, los productos que se ofrecen, así como sus precios y formas de entrega y pago. Desde el usuario registrado se ofrece un acceso directo a las redes sociales de las que dispone la empresa, como son las plataformas Facebook y Twitter. Este usuario podrá visualizar su perfil en la aplicación y modificarlo. El usuario podrá darse de baja de la aplicación. El usuario registrado que anteriormente haya realizado algún pedido podrá ver el estado de sus pedidos, pudiendo elegir entre los que ya han sido entregados, que pasarán a un histórico, de los que están en proceso. El usuario registrado podrá realizar un pedido, pudiendo elegir los documentos y propiedades de impresión de cada uno de sus paquetes. Todo esto, siempre dentro de lo que la aplicación le permita hacer. Documentación 47

51 El usuario podrá cambiar las unidades de un paquete, visualizar este o eliminarlo del pedido. El usuario podrá elegir si pasa a recoger el pedido o se le envía a casa, introduciendo consecuentemente sus datos para su aviso, y si el caso, para su envío. El usuario podrá elegir entre recibir, junto con el producto, un albarán de pago o factura que detalle los gastos del pedido. El usuario deberá realizar el pago mediante la plataforma de pago PayPal. En caso de no haber podido realizar correctamente el pago, el usuario podrá recuperar su pedido la siguiente vez que se conecte a la aplicación, donde podrá continuar con la operación o rechazarla Requisitos Usuario Administrador El usuario administrador, es un usuario único. Dispondrá de unas credenciales otorgadas por parte del desarrollador para la identificación con este rol. Se identificará como tal desde la interfaz de usuario invitado. Los requisitos de este usuario son los siguientes: El administrador tendrá unas credenciales para identificarse con el sistema. El administrador puede ver todo lo referente a los usuarios, registrados en ese momento o que lo estuvieron en su momento, eligiendo los criterios para su búsqueda. El administrador puede ver todo lo referente a las sesiones de los usuarios, eligiendo los criterios para su búsqueda. El administrador puede ver todo lo referente a los pedidos actuales o pasados eligiendo los criterios para su búsqueda. El administrador puede ver todo lo referente a los paquetes actuales o pasados eligiendo los criterios para su búsqueda. El administrador puede ver mediante gráficas la facturación de la empresa en concepto de ingresos, sellos y sobres. El administrador puede modificar desde la aplicación los costes de impresión, los costes de envío y los pesos de los productos. El administrador puede visualizar desde la aplicación los organigramas web y de la base de datos. El administrador puede realizar una limpieza rutinaria de la base de datos, pudiendo: o Eliminar usuarios no validados tras un tiempo prudencial. o Eliminar pedidos y paquetes que no han sido pagados tras un tiempo prudencial. o Cerrar sesiones inactivas abiertas. Documentación 48

52 Requisitos no funcionales del sistema El sistema debe ser seguro. Al manejar tanto datos personales como realizarse movimientos monetarios, uno de los aspectos más importantes en la realización de este proyecto será la seguridad en la aplicación. El sistema será multiusuario. El sistema debe responder en un tiempo razonable. El sistema tendrá una interfaz intuitiva y sencilla. El fácil manejo de la aplicación debe ser otro de los factores que predominen en la aplicación. El perfil de usuario que se registra en la aplicación busca una interfaz sencilla que le permita de forma cómoda y rápida realizar su acometido Requisitos de ampliación Introducción de datos de prueba en una base de datos externa al sistema en donde se almacenará todo lo referente a usuario, sesiones, pedidos y paquetes Implantación del sistema en la empresa. Impartir un curso sobre el uso de la aplicación. Documentación 49

53 3.1.4 Modelo de Casos de Uso Diagrama de Casos de Uso Ilustración 13: Diagrama de casos de uso de la aplicación web. Documentación 50

54 Especificación de casos de uso Alta Socio Caso de uso Objetivo Actores Precondiciones Pasos Extensiones Alta Socio Dar de alta a un socio en la aplicación. Usuario Invitado - Debe ser mayor de edad. - El correo electrónico no puede estar repetido en el sistema. - El nombre de usuario debe tener entre 6 y 12 caracteres. - El nombre de usuario no puede estar repetido en el sistema. - La contraseña debe tener entre 8 y 20 caracteres. - Los datos introducidos deben coincidir con sus tipos. - Deben aceptarse los términos legales. 1. El usuario introduce sus datos personales. 2. El usuario envía los datos pulsando el botón enviar. 3. El sistema comprueba que todos los campos del formulario están rellenados. 4. El sistema valida que todos los datos coinciden con sus tipos. 5. El sistema valida que el captcha sea correcto. 6. El sistema valida que las contraseñas introducidas son iguales. 7. El sistema valida que no existe otro usuario con ese nombre. 8. El sistema valida que no existe otro usuario con ese correo electrónico. 9. El sistema introduce los datos en la base de datos. 10. El sistema envía un correo electrónico al usuario para la validación. 11. El sistema abre una página web para la solicitud de confirmación del registro. 12. El usuario abre el correo electrónico que el sistema le ha enviado. 13. El usuario pincha el enlace que aparece en el correo electrónico. 14. El sistema realiza la validación del usuario y le aplica el rol registrado. 15. El sistema abre una página web de usuario registrado con los valores del nuevo socio. 1.1 Se visualiza en pantalla si el correo electrónico está disponible o no lo está. 1.2 Se visualiza en pantalla si el nombre de usuario está disponible o no lo está. 2.1 Se hace una primera comprobación de que todos los campos del formulario estén rellenados y pertenezcan a sus tipos, en caso negativo, no se permite enviar el formulario, se retorna a la página anterior y se indican los campos fallidos. 3.1 Si no están todos los campos rellenados, se retorna a la página anterior y no se guardan los datos. Documentación 51

55 Comentarios 4.1 Si los datos no coinciden con sus tipos se retorna a la página anterior y no se guardan los datos. 4.2 Se calculara la edad del individuo, en caso de no ser mayor de edad se retorna a la página anterior y no se guardan los datos 5.1 Si el captcha no es correcto se retorna a la página anterior y no se guardan los datos. 6.1 Si las contraseñas no coinciden se retorna a la página anterior y no se guardan los datos. 7.1 Si existe otro usuario con ese nombre se retorna a la página anterior y no se guardan los datos. 8.1 Si existe un coincidente con el introducido se retorna a la página anterior y no se guardan los datos. 9.1 Si no consiguen guardar los datos en las base de datos se retorna a la página anterior y no se guardan los datos. 9.2 No se enviará el correo electrónico dando el alta. - El sistema de alta de socio, lleva por seguridad una triple validación de datos. La primera en la propia página del formulario, la segunda en la aplicación que registra los datos y la tercera a nivel de la base de datos. - El captcha no será realizado por el usuario sino que se adaptará un modelo predefinido. - La disponibilidad de los nombres de usuario y correo electrónico se podrá comprobar antes de proceder al registro. Documentación 52

56 Diagrama de actividad Alta Socio Ilustración 14: Diagrama de actividad: Alta Socio. Documentación 53

57 Identificación Caso de uso Objetivo Actores Precondiciones Pasos Extensiones Comentarios Identificación Identificarse en la aplicación para obtener un rol superior. Usuario Invitado, Usuario Registrado, Usuario Administrador - El usuario debe estar registrado en la aplicación. 1. El usuario introduce su nombre de usuario y contraseña. 2. El usuario envía los datos pulsando el botón entrar. 3. El sistema comprueba que los campos estén rellenados. 4. El sistema comprueba que el usuario existe. 5. El sistema comprueba el rol del usuario. 6. El sistema almacena los datos de la sesión. 7. El sistema accede a la web correspondiente según su rol 7.1 En caso de ser usuario registrado Si existe algún pedido pendiente de pago el usuario accede a la página de pedidos pendientes Si no existe ningún pedido pendiente de pago el accede a la página principal de usuario registrado. 7.2 En caso de ser usuario administrador el usuario accede a la página principal de usuario administrador. 3.1 Si los campos alguno de los campos está vacío, se retorna a la página anterior indicando el problema. 4.1 Si el usuario no existe se retorna a la página anterior indicando el problema. 5.1 Si todavía no dispone de un rol de usuario al no haber confirmado su registro, se retorna a la página anterior indicando el problema. 6.1 Si no se puede almacenar los datos de la sesión se retorna a la página anterior indicando el problema. Existe un rol por defecto pero no consta como rol de usuario. Documentación 54

58 Diagrama de actividad Identificación Ilustración 15: Diagrama de actividad: Identificación Olvidar Contraseña Caso de uso Objetivo Actores Pasos Olvidar Contraseña Recuperar la contraseña olvidada. Usuario Registrado 1. El usuario accede a la web de olvido de contraseña. 2. El usuario introduce del nombre de usuario y del El usuario pinchara el botón de envío. 4. El sistema comprueba que los datos del formulario coinciden con sus tipos. 5. El sistema comprueba que los datos del formulario no están vacíos. 6. El sistema comprueba que el usuario y correo electrónico existen para el mismo usuario. 7. El sistema cambia la contraseña anterior por una provisional y envía un correo electrónico al usuario. 8. El sistema muestra una web que indica que la contraseña ya ha sido enviada. Documentación 55

59 Extensiones Comentarios 9. El usuario entra en su correo donde aparece la contraseña provisional y un link en el cual pinchar para entrar a una interfaz donde cambiar la contraseña provisional. 10. El usuario introduce y envía el nombre de usuario y para mayor seguridad en dos apartados la nueva contraseña. 11. El sistema comprueba que alguno de los campos del formulario no estén vacíos y coinciden con sus tipos. 12. El sistema vuelve a comprobar que alguno de los campos del formulario no estén vacíos. 13. El sistema comprueba que las contraseñas son iguales. 14. El sistema comprueba que existe un usuario con ese nombre de usuario y esa contraseña provisional. 15. El sistema cambia la contraseña. 16. El sistema muestra al usuario una web indicando que la contraseña ha sido cambiada. 4.1 Alguno de los campos del formulario está vacío o no coincide con sus tipos y se retorna a la página anterior detallando el atributo a modificar. 5.1 Alguno de los campos del formulario está vacío y se retorna a la página anterior detallando el problema. 6.1 La combinación de nombre de usuario y correo electrónico no coinciden para el mismo usuario, se envía a una página indicando que no se puede enviar la contraseña. 7.1 El sistema no consigue cambiar la contraseña por una provisional y envía al usuario a una página indicando que no se puede enviar la contraseña Alguno de los campos del formulario está vacío o no coincide con sus tipos y se retorna a la página anterior detallando el atributo a modificar. (primera validación) Alguno de los campos del formulario está vacío y se retorna a la página anterior detallando el problema (segunda validación) El sistema no consigue cambiar la contraseña y envía al usuario a una página indicando que la contraseña no ha sido cambiada. Las primeras validaciones se hacen en el propio formulario, las segundas validaciones se hacen en la página que registra las operaciones. Documentación 56

60 Diagrama de actividad Olvidar Contraseña Ilustración 16: Diagrama de actividad: Olvidar contraseña. Documentación 57

61 Ver Características Caso de uso Objetivo Actores Opciones Ver Características Ver las características de empresa y producto. Usuario Invitado, Usuario Registrado - Ver portada de la web y video publicitario. - Ver características de la empresa. - Ver productos de los que se dispone. - Ver los precios de los diferentes productos. - Ver los tipos de pagos de los que dispone la web. - Ver las características de envíos de los pedidos Contactar Caso de uso Objetivo Actores Opciones Contactar Ver las opciones de contacto con la empresa. Usuario Invitado, Usuario Registrado - Localización en mapa. - Teléfono de contacto. - Acceso directo a comunicación mediante Skype. - Acceso a las redes sociales de las que se dispone, Twitter y Facebook Acceso Redes Sociales Caso de uso Objetivo Actores Pasos Acceso Redes Sociales Acceder directo a las redes sociales de la empresa. Usuario Invitado, Usuario Registrado. - Acceso al Facebook de Reprografic. - Acceso al Twitter de Reprografic Consultar Datos Caso de uso Objetivo Actores Pasos Consultar Datos Consultar los datos de usuario que en su momento registro Usuario Registrado, Usuario Administrador 1. Entrar en la web de consultar perfil. 2. Ver los detalles de tu perfil y tus sesiones en la aplicación. Documentación 58

62 Modificar Datos Caso de uso Objetivo Actores Pasos Extensiones Modificar Datos Modificar los datos de registro de usuario. Usuario Registrado 1. El usuario entra en la web de modificaciones 2. El usuario entra selecciona los datos que se quieren modificar 3. El usuario entra introduce los nuevos valores. 4. El sistema valida los nuevos valores. 5. El sistema sustituye los nuevos valores. 6. El sistema retorna a la página anterior informando al usuario de que los cambios se han realizado con éxito. 4.1 Si los valores no son válidos se retorna a la página anterior indicando el motivo por el que el dato no es válido Baja Socio Caso de uso Objetivo Actores Precondiciones Pasos Extensiones Baja Socio Darse de baja como Usuario Registrado. Usuario Registrado El usuario no debe tener ningún pedido en proceso. 1. El usuario entra en la web de modificación de perfil. 2. El usuario accede al apartado de baja de usuario. 3. El usuario introduce sus credenciales en la aplicación y las envía 4. El sistema valida las credenciales. 5. El sistema comprueba que el usuario no dispone de ningún pedido en proceso. 6. El sistema pasa el estado del usuario a no activo. 7. El sistema muestra una web al usuario indicando que el usuario se ha eliminado correctamente. 4.1 En caso de no ser correctas las credenciales se retornará a la página anterior, informando al usuario de que no se ha llevado a cabo la operación. 5.1 En caso de que el usuario tenga en ese momento un pedido activo, no se le permitirá dar de baja y se le retornará a la página anterior indicando el motivo por el que no se ha llevado a cabo la operación. Documentación 59

63 Ver Pedidos Caso de uso Objetivo Actores Pasos Ver Pedidos Ver los pedidos que ha realizado tanto en proceso como históricos. Usuario Registrado 1. El usuario entra en la página de ver pedidos. 2. El usuario debe elegir entre ver los pedidos en proceso o los ya finalizados. 3. El usuario visualiza sus pedidos Ver Cesta Detallada Caso de uso Objetivo Actores Precondiciones Pasos Ver Cesta Detallada Ver detalladamente los paquetes que tenemos en la cesta. Usuario Registrado El usuario debe disponer de algún paquete en la cesta. 1. El usuario entra en una web que disponga la visualización de cesta. 2. El usuario ve los paquetes que hay en la cesta y puede operar sobre ellos Añadir Producto Caso de uso Objetivo Actores Precondiciones Pasos Extensiones Comentarios Añadir Producto Añadir un paquete a la cesta. Usuario Registrado El archivo debe pertenecer a uno de los formatos establecidos. 1. El usuario entra en la web en la que se realizan los pedidos. 2. El usuario introduce un documento. 3. El usuario introduce todas las propiedades de impresión. 4. El usuario envía el paquete. 5. El sistema valida todo lo introducido por el usuario. 6. El sistema calcula los costes y pesos del paquete. 7. El sistema almacena los datos introducidos y calculados en las cookies. 5.1 En caso de no ser válido lo introducido se retornará a la pagina anterior indicando los motivos por los que no es válido. No serán compatibles todos los tipos de propiedades entre sí, se deberá crear un sistema para solo mostrar las compatibles. Documentación 60

64 Diagrama de actividad Añadir Producto Ilustración 17: Diagrama de actividad: Añadir producto Eliminar Producto Caso de uso Objetivo Actores Precondiciones Pasos Comentarios Eliminar Producto Elimina un paquete de la cesta. Usuario Registrado - Debe haber algún paquete a borrar. - La cesta no debe estar cerrada. 1. El usuario localiza el paquete a borrar. 2. El usuario pincha el botón eliminar. 3. El sistema cuenta cuantos paquetes dispone la cesta. 3.1 Si solo hay un paquete, el sistema borra el conjunto de la cesta y esta se queda vacía. 3.2 Si hay más de un paquete, el sistema localiza el paquete, lo borra y reordena la cesta. 4. El sistema actualiza la cesta. Es importante un buen sistema de reordenación de la cesta tras el borrado para evitar un fallo grande en la cesta que la deje inutilizable Cambiar Número de Unidades Caso de uso Objetivo Actores Precondiciones Cambiar Número de Unidades Cambia el número de unidades de un paquete. Usuario Registrado - Debe haber algún paquete sobre el que aplicar el cambio. - La cesta no debe estar cerrada. - No podrá haber menos de una unidad. - No podrá superarse un coste máximo de pedido. Documentación 61

65 Pasos Extensiones 1. El usuario accede a la cesta. 2. El usuario sube o baja el número de unidades. 3. El sistema cambia el número de unidades. 2.1 En caso ser 1 el número de unidades no dejará bajar las unidades, las mantendrá intactas. 2.2 En caso de llegar al máximo de coste de pedido no dejará subir las unidades, las mantendrá intactas Realizar Pedido Caso de uso Objetivo Actores Precondiciones Pasos Realizar Pedido Finaliza un pedido Usuario Registrado Debe haber algún paquete en la cesta 1. El usuario ejecutar el finalizar pedido. 2. El sistema comprueba que se puede finalizar. 3. El sistema cierra el pedido. 4. El sistema abre una web para elegir el método de entrega. 5. El usuario indica el método de entrega. 6. El sistema abre un formulario para que introduzca los datos de entrega. 7. El usuario introduce los datos de entrega y los envía. 8. El sistema comprueba que los datos introducidos son validos. 9. El sistema almacena los datos de entrega como cookie. 10. El sistema abre una web para elegir si desea factura o albarán. 11. El usuario indica su preferencia. 12. El sistema abre un formulario para que introduzca los datos de factura o albarán. 13. El usuario introduce los datos de entrega y los envía. 14. El sistema comprueba que los datos introducidos son validos. 15. El sistema almacena los datos de entrega como cookie. 16. El sistema abre una web con el resumen del pedido. 17. El usuario acepta el resumen y confirma el pago. 18. El sistema almacena las cookies guardadas en la base de datos. 19. El sistema abre la web de pagos. 20. El usuario introduce sus credenciales de pago. 21. El sistema comprueba las credenciales. 22. El usuario confirma el pago. 23. El sistema realiza el cobro. 24. El sistema actualiza la base de datos. 25. El sistema envía dos s, uno con la confirmación del pedido y otro desde la plataforma de pagos con el resumen de este. Documentación 62

66 Extensiones Comentarios 2.1 No hay ningún paquete en la cesta y por lo tanto el sistema no permite finalizar el pedido, retorna a la página anterior informando del motivo. 8.1 Los datos introducidos por el usuario no son correctos y el sistema lo retorna a la página anterior informando del motivo Los datos introducidos por el usuario no son correctos y el sistema lo retorna a la página anterior informando del motivo Si las credenciales no son correctas retorna a la página anterior Si hay algún problema con el cobro, se envía a una página informando de que su pedido ha sido cancelado. Si durante el transcurso del proceso surge algún problema distinto a los comentados, el sistema retorna a la página anterior a finalizar el pedido. Si no se ha podido efectuar el pago, el pedido se recuperará la siguiente vez que se conecte al sistema. Documentación 63

67 Diagrama de actividad Realizar Pedido Ilustración 18: Diagrama de actividad: Realizar pedido. Documentación 64

68 Ver Actividad Caso de uso Objetivo Actores Pasos Ver Actividad Ver la actividad que tiene la aplicación. Usuario Administrador 1. El usuario elige la actividad que quiere ver de la aplicación eligiendo entre sesiones, usuarios, pedidos, paquetes y los históricos de estos dos últimos. 2. El usuario elije si lo desea criterios de búsqueda. 3. El usuario elije si lo desea orden de búsqueda. 4. El sistema muestra la actividad que ha elegido Ver Facturación Caso de uso Objetivo Actores Pasos Ver Facturación Ver la facturación que produce la aplicación Usuario Administrador 1. El usuario elige la facturación que quiere ver de la aplicación eligiendo entre ingresos, sellos y sobres. 2. El sistema muestra mediante gráficas que ha elegido Modificaciones Caso de uso Objetivo Actores Pasos Extensiones Comentarios Modificaciones Modificar aspectos de la aplicación como costes de impresión, costes de envío o pesos. Usuario Administrador 1. El elige la modificación que quiere ver de la aplicación eligiendo entre costes de impresión, costes de envió o pesos. 2. El usuario cambia los valores que desea y los envía. 3. El sistema comprueba que los nuevos valores son correctos. 4. El sistema abre una web indicando que los valores han sido modificados. 3.1 Si los valores introducidos no son correctos, envía al usuario a una web que indica que los valores no han sido modificados. Los valores no se almacenarán en una base de datos sino que los conservaremos en un archivo XML. Documentación 65

69 Ver Organigramas Caso de uso Objetivo Actores Pasos Ver Organigramas Ver los organigramas web o de BD de la aplicación. Usuario Administrador 1. El usuario elige el organigrama que quiere ver de la aplicación eligiendo entre el de la distribución de la web o el de la base de datos. 2. El sistema muestra el documento elegido Limpieza de la aplicación Caso de uso Objetivo Actores Pasos Limpieza de la aplicación Limpiar todos los datos no necesarios en la aplicación. Usuario Administrador 1. El usuario ejecutará la opción de limpieza de la aplicación. 2. El sistema actualizará si hay sesiones inactivas 3. El sistema borrará los usuarios que tras 15 días no han sido validados en la aplicación. 4. El sistema borrará los paquetes en los que el usuario no ha terminado un pago, siempre y cuando este usuario no se haya conectado en los anteriores 10 dias. 5. El sistema borrará los pedidos en los que el usuario no ha terminado un pago, siempre y cuando este usuario no se haya conectado en los anteriores 10 dias. 6. El sistema mostrará una web indicando lo que ha eliminado en la limpieza Vistas de interacción Para los casos de uso más complejos especificamos todos sus escenarios significativos. Para esto vamos usar los DSS (Diagramas de Secuencia del Sistema), que muestra los eventos que un actor genera durante la interacción con el sistema. Para el resto de casos no se han incluido los diagramas de secuencia correspondientes debido a que en dichos casos de uso no se crea, se destruye o se modifica ningún objeto o asociación. Documentación 66

70 Alta Socio Referente al caso de uso Alta socio (Apartado ) Ilustración 19: Diagrama de secuencia: Alta socio. Documentación 67

71 Identificación Referente al caso de uso Identificación (Apartado ) Ilustración 20: Diagrama de secuencia: Identificación. Documentación 68

72 Olvidar Contraseña Referente al caso de uso Olvidar contraseña (Apartado ) Ilustración 21: Diagrama de secuencia: Olvidar contraseña. Documentación 69

73 Añadir Paquete Referente al caso de uso Añadir paquete (Apartado ) Ilustración 22: Diagrama de secuencia: Añadir Paquete Realizar Pedido Referente al caso de uso Realizar pedido (Apartado ) Ilustración 23: Diagrama de secuencia: Realizar pedido. Documentación 70

74 3.1.6 Análisis del modelo de datos Analizados los casos de uso, en este apartado se presenta el diseño E/R de nuestra base de datos. Ilustración 24: Esquema de entidad relación Documentación 71

75 En la aplicación diferenciaremos seis entidades referentes a los usuarios, las sesiones, los pedidos y los paquetes, de estos dos últimos, añadiremos sus respectivos históricos para cuando ya no los usemos. La entidad Usuario registrará un identificador de usuario, así como un rol que el sistema le otorgue. Esto será fundamental para todo el devenir del proceso de realización de un pedido. Además necesitará una contraseña como credencial para identificarse. El sistema debe almacenar todos los datos personales del usuario como son el nombre, apellidos, correo electrónico, teléfono móvil, fecha de nacimiento, sexo, provincia, localidad, dirección y código postal del usuario. Como método de seguridad almacenaremos una pregunta y respuesta, que actualmente no usaremos en nuestro sistema pero que nos podrá servir en las futuras mejoras de la aplicación. Se almacenará también la fecha en la que el usuario fue registrado. De cara a la seguridad en el registro, también guardaremos un código de activación y un atributo llamado codigoactiv, que nos indique si el usuario está validado. Al almacenar los datos de los usuarios que se han dado de baja, indicaremos mediante un atributo llamado activo, si el usuario está activo o no en la aplicación. La aplicación envía rutinariamente correos electrónicos con la información acerca de la empresa y sus productos. Deberemos indicar mediante el atributo info, si un usuario desea o no recibir esa información. La entidad Sesión registrará las sesiones abiertas del usuario. Crearemos un índice en la entidad. Además, se almacenará la fecha en la que inició la sesión. También una fecha de última actualización, que irá actualizándose cada vez que el usuario abra una página. Por ultimo habrá un atributo llamado activa, que indique si en ese momento el usuario está o no está activo en la web. La entidad Pedido registrará un identificador de pedido. Tendrá una referencia con el usuario que haga el pedido. Contemplará los atributos dedicados a un pedido como el total de paquetes, el coste de impresión, la forma de entrega y un número de teléfono donde avisar del pedido. En caso de realizarse un envío del producto a domicilio, también necesitaremos almacenar el peso del producto completo, un coste y un tamaño del sobre donde enviarlo, el coste de los sellos y una dirección a la que realizar el envío. Guardaremos también la forma de pago (aunque en principio solo existirá una sola forma), así como su fecha. Necesitaremos almacenar también si se ha solicitado factura o albarán. La entidad Histórico Pedido mantendrá los mismos atributos de pedido y a la vez añadirá la fecha en que pasó a ser histórico. La entidad Paquete registrará un identificador del paquete y una referencia al pedido. A esto le sumaremos todas las propiedades de impresión de cada documento como el número de unidades a imprimir, el tamaño del folio, el tipo de folio, si lo quiere a color Documentación 72

76 o blanco y negro, a una o doble cara, ampliación del documento, orientación y número de páginas por hoja. También se añadirán determinados elementos que el sistema deberá calcular como el número de páginas, la dirección que el sistema le otorgue al documento y el coste de la impresión de ese paquete. La entidad Histórico Paquete mantendrá los mismos atributos que la entidad Paquete. A los atributos de las entidades que refieren a datos históricos, les añadiremos un distintivo en los atributos para evitar las confusiones con las mismas en el desarrollo del proyecto Análisis de requisitos de las interfaces En este apartado analizaremos, a muy alto nivel, los requisitos principales requeridos a nivel de interfaz. En particular, necesitamos una aplicación web que muestre las características de la empresa, sus redes sociales, formas para contactar con ella y muestre los productos disponibles. El aspecto de la web deberá ser muy organizado con la intención de dar una sensación de seriedad en el producto. No deberá existir más información ni detalles de los estrictamente necesarios para no agobiar al usuario de la aplicación innecesariamente. Debe haber facilidad en los métodos de registro y de identificación de usuario. El registro, para cumplir con las necesidades actuales o futuras de la empresa, debe ofrecer al usuario la forma de incluir sus datos, como son, los datos personales, la forma por la cual el sistema se comunique con él, unas credenciales para la identificación y una forma de recuperación de estas en caso de olvido. Incluiremos un captcha para evitar el registro masivo automático. El usuario podrá decidir desde el registro si desea recibir información a su correo. Será necesario aceptar unos términos legales. Tras completar el registro, se necesitará una validación segura mediante correo electrónico, con el fin de asegurarnos de la veracidad usuario-cuenta. El sistema deber ser muy seguro para quien haya olvidado la contraseña, puesto que una mala gestión para este sistema puede desembocar en la sustracción de una cuenta por parte de un usuario no deseado. Por ello, para gestionar este servicio usaremos también un sistema mediante correo electrónico. Documentación 73

77 En la gestión entre aplicación y usuario, se debe ofrecer un buen servicio y detallado. Las interfaces deben cubrir todos los requisitos que en este documento se especifican. 3.2 Diseño En el siguiente capítulo se van a tratar todos los temas relacionados con el diseño del sistema como por ejemplo el diseño de las clases, el diseño de la base de datos o las interfaces. Se explica también el tipo de arquitectura por el que se ha optado Definición de la arquitectura En sistema utilizará una arquitectura cliente-servidor que es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos (servidores) y los demandantes (clientes). En nuestro caso el lado del cliente es mínimo, se limita al uso de un navegador para acceso y presentación. En el servidor se almacena la aplicación web, la cual está compuesta por la capa de persistencia, la capa de lógica y la de presentación. En el lado del cliente no es necesario instalar ningún programa. Lo necesario para poder hacer uso del sistema es tener un navegador Web que interactuará con el servidor donde se encuentra alojada la aplicación. A continuación se muestra un esquema en el que se puede observar fácilmente el proceso que se lleva a cabo en la arquitectura cliente-servidor. Ilustración 25: Arquitectura Cliente- servidor en 3 niveles Documentación 74

78 Para la implementación de la aplicación se hará uso de un diseño separado en capas, en concreto en tres capas. Capa de presentación: también denominada capa de usuario, presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo proceso. Se comunica directamente con la capa de negocio. Para su desarrollo se hará uso del lenguaje HTML, CSS y de JavaScript. Capa de negocio: aquí se procesan las peticiones del usuario y se envía la respuesta tras el proceso. Al utilizar tecnología PHP aquí se alojaran los algoritmos necesarios para un buen funcionamiento. Capa de datos: lugar donde se encuentran los métodos de la capa de persistencia encargados de acceder a los datos Diseño de las clases Tras el análisis de los datos, ha resultado el siguiente diagrama UML que muestra las clases del modelo de negocio junto con sus relaciones. Ilustración 26: UML de las clases del modelo de negocio Documentación 75

79 A continuación, se presentan, para clase, los atributos identificados. Como dichas clases atributos corresponden a las entidades que aparecen en el sistema de información, se omitirá su descripción. Sesion o idsesion: int o idusuario: string o fechainicio: datetime o ultimafecha: datetime o active: boolean Usuario o idusuario: string o rol: int o contrasena: string o nombre: string o apellidos: string o string o movil: int o fechanac: date o sexo: string o provincia: string o localidad: string o direccion: string o cp: int o preguntaseg: string o respuestaseg: string o enviopubli: boolean o fecharegistro: datetime o codigoactiv: int o validado: boolean o activo: Boolean Pedido o idpedido: int o idusuario: string o totalpaquetes: int o costetotal: float o costeimpresion: float o costesobre: float o costesellos: float o tamanosobre: int o peso: float o formaentrega: boolean o movilaviso: int o direccionenvio: string o metodopago: string o factura: string o fechapago: datetime o fechaaviso: datetime HistoricoPedido o o o o o o o o o o o o o o o o o Paquete idpedidoh: int idusuarioh: string totalpaquetesh: int costetotalh: float costeimpresion: float costesobreh: float costesellosh: float tamanosobreh: int pesoh: float formaentregah: boolean movilavisoh: int direccionenvioh: string metodopagoh: string facturah: string fechapagoh: datetime fechaavisoh: datetime fechaentregah: datetime o idpaquete: int o idpedido: int o paginas: int o unidades: int o tamanofolio: int o tipofolio: int o color: boolean o doblecara: boolean o ampliacion: float o paginashoja: int o orientacion: boolean o direcciondoc: string o costeimpresion: float HistoricoPaquete o o o o o o o o o o o idpaqueteh: int idpedidoh: int paginash: int unidadesh: int tamanofolioh: int tipofolioh: int colorh: boolean doblecarah: boolean ampliacionh: float paginashojah: int orientacionh: boolean o direcciondoch: string o costeimpresionh: float Documentación 76

80 3.2.3 Diseño de la base de datos A partir del diagrama de clases visto en el apartado de la documentación, se muestra el diseño lógico de la base de datos en la que se alojarán los datos del sistema. Ilustración 27: Modelo lógico de la aplicación web. Descripción de las tablas de la base de datos del sistema: Sesion: De esta tabla guardaremos un identificador de la sesión (idsesion), un identificador del usuario propietario de esa sesión (idusuario), la fecha en que se crea (fechainicio), la última vez que se modificó (ultimafecha) y si el estado en que se encuentra (activa) siendo 1 el valor de estar activa y 0 el de inactiva. Esta tabla tiene una clave foránea idusuario a la tabla Usuario. Usuario: De esta tabla guardaremos un identificador de usuario (idusuario), el rol que desempeñara (siendo el valor 3 cuando no este validado, 1 cuando este validado como usuario registrado o 2 cuando este validado como usuario administrador) y la contraseña del usuario (contraseña). Además, guardaremos los datos personales del usuario en los campos nombre, apellidos, , móvil, Documentación 77

81 fechanac, sexo, provincia, localidad, dirección y CP. Por motivos de seguridad almacenaremos una pregunta y respuesta de seguridad (preguntaseg y respuestaseg). Guardaremos en otro campo si el usuario quiere o no recibir información (enviopubli) siendo el valor 1 una respuesta afirmativa y el valor 2 una respuesta negativa. Almacenaremos la fecha en que el usuario se registró (fecharegistro) con el fin de proporcionar unas estadísticas. También tendremos dos campos, uno con el código de activación (codigoactiv) y validado, como forma de seguridad en el registro. Por último contaremos con un campo activo en el que guardaremos el valor de si el usuario está o no activo, siendo 0 si está activo y 1 si está inactivo. Pedido: De esta tabla guardaremos un identificador de pedido (idpedido), el total de paquetes que tiene el pedido (totalpaquetes), los costes totales (costetotal), de impresión (costeimpresion), de los sobres y sellos en caso de que la forma de entrega sea por envío (costesobre y costesellos). En el mismo caso de entrega, almacenaremos el tamaño del sobre (tamanosobre). Se incluirá también el peso total del producto, con el embalaje en caso de ser el caso (peso). La forma de entrega se almacenará mediante el atributo formaentrega. Indicaremos un móvil al que avisar para realizar la entrega y una dirección de envío en caso de que ésta sea necesaria (direccionenvio). A la hora de realizar el pago, indicaremos su método (metodopago) aunque en principio solo habrá uno, y la fecha en que se realizó (fechapago). Se especificará en el campo factura si se pidió factura o albarán, y se incluirán los datos de éste. Por último, también incluiremos la fecha en la que se avisa al usuario de que su producto está finalizado (fechaaviso) para que pase a recogerlo o espere su recepción en su domicilio. Esta tabla tiene una clave foránea idusuario a la tabla Usuario. Documentación 78

82 Paquete: De esta tabla guardaremos un identificador de paquete (idpaquete), este atributo será una clave foránea con Pedido. De cada paquete almacenaremos su número de páginas (paginas), el número de unidades que se quieren (unidades), el tamaño y tipo de folio en el cual se quiere imprimir (tamanofolio y tipofolio). Si se quiere a color con el valor 1 o blanco y negro con el valor 0 en el campo color. También el atributo doblecara indicará mediante el valor 0 si es a una cara o el valor 1 si es a doble cara como se quiere la impresión. También habrá un campo que indicará mediante un porcentaje si queremos reducir o ampliar el documento en su impresión (ampliación). El número de páginas por hoja también quedara alojado en un campo mediante el atributo paginashoja. El campo orientacion tendrá valor 0 cuando la impresión sea horizontal y valor 1 cuando la impresión sea en vertical. El dirección donde está alojado el documento quedará en el atributo direcciondoc. Por último se almacenará el coste total de la impresión de ese paquete (costeimpresion). Esta tabla tiene una clave foránea idpedido a la tabla Pedido. HistoricoPedido: mantendrá los mismos campos que pedido pero con el distintivo de una H al finalizar el nombre del atributo para evitar confusiones con los campos de la tabla Pedido. Esta tabla tiene una clave foránea idusuarioh a la tabla Usuario. HistoricoPaquete: mantendrá los mismos campos que pedido pero con el distintivo de una H al finalizar el nombre del atributo para evitar confusiones con los campos de la tabla Paquete. Esta tabla tiene una clave foránea idpedidoh a la tabla historicopedido. Documentación 79

83 3.2.4 Prototipo de interfaces de usuario Esta sección mostrará las principales interfaces de lo que será el sistema. En cuanto a la usabilidad, cabe destacar que tanto el tipo de letra utilizado en el sistema como los colores e imágenes, ha sido impuesto por el cliente ya que la empresa PYC Papel y Copia tiene una imagen corporativa la cual debemos mantener. La imagen corporativa se podría cambiar fácilmente. Las interfaces se han diseñado de mutuo acuerdo con la empresa Interfaz principal de Usuario Invitado Ilustración 28: Interfaz principal de Usuario Invitado. Esta será la interfaz principal del usuario invitado. Como puede verse, en la parte del menú se muestra todo lo referente a la información de la empresa y los productos que oferta. El usuario desde esta web podrá identificarse como usuario registrado o usuario administrador. Así mismo el usuario podrá registrarse en la aplicación o recuperar su contraseña en caso de haberla olvidado. También desde esta interfaz podrá entrar en las redes sociales de la empresa de forma directa. Cada una de las interfaces de usuario invitado conservará la misma estructura que la imagen mostrada anteriormente, solo modificándose la parte donde se aloja la información y, en determinados casos donde no sea necesario, la parte de la identificación. Documentación 80

84 Interfaz principal de Usuario Registrado Ilustración 29: Interfaz principal de Usuario Registrado. Esta será la interfaz principal del usuario registrado. Como puede verse, en la parte del menú se muestra todo lo referente a la información de la empresa y los productos que oferta. En la parte central se podrá elegir entre las herramientas de las que dispone el usuario registrado. En la parte lateral derecha se podrá visualizar el estado de la cesta. También desde esta interfaz podrá entrar en las redes sociales de la empresa de forma directa. Cada una de las interfaces de usuario registrado conservará la misma estructura que la imagen mostrada anteriormente, solo modificándose la parte donde se aloja la información. Y en determinados casos donde no sea necesario, la parte de la cesta. Documentación 81

85 Interfaz principal de Usuario Administrador Ilustración 30: Interfaz principal de Usuario Administrador. Esta será la interfaz principal del usuario administrador. Como puede verse en la parte del menú se muestran todas las herramientas que el usuario administrador dispone para controlar todo lo referente a web. Cada una de las interfaces de usuario administrador conservará la misma estructura que la imagen mostrada anteriormente, solo modificándose la parte central, donde se aloja la información. Documentación 82

86 3.3 Construcción En el siguiente apartado se tratarán de mostrar los aspectos más importantes de la fase de construcción o implementación Código relevante En éste apartado se mostrarán algunos fragmentos de código relevantes para el funcionamiento del sistema Conexión con la base de datos La base de datos la tendremos alojada en un servidor virtual. Cada vez que queramos acceder a la base de datos, accederemos mediante un archivo de configuracion, de la siguiente manera: En este archivo estan alojados las credenciales para acceder a ella, que son los siguientes: Las llamadas a esta base de datos la haremos de la siguiente manera: Dentro de ese código irán todas las operaciones que hagamos sobre la base de datos. Documentación 83

87 Cada vez que realicemos una operación de actualización, inserción o borrado de la base de datos, lo haremos con el siguiente modus operandi: Es decir, usaremos los comandos BeginTrans(), CommitTrans() y RollbackTrans(). En el caso de realizar consultas SQL usaremos lo siguiente: Es decir, usaremos el comando SelectLimit() para seleccionar todos los campos, fields para sacar el valor de los campos y MoveNext() para recorrer los campos hacia delante. En caso de que busquemos que una consulta nos devuelva un solo valor, utilizaremos el comando getone(), de la siguiente manera: A partir de estos comandos se realizarán todas las consultas a la base de datos y por tanto obviaremos su explicación de aquí en adelante. Documentación 84

88 Uso de jquery Para dinamismo a la web se han usado bibliotecas JavaScript, concretamente las denominadas jquery, que contiene las funcionalidades comunes de DOM, eventos, efectos y AJAX. La característica principal de la biblioteca es que permite cambiar el contenido de una página web sin necesidad de recargarla, mediante la manipulación del árbol DOM y peticiones AJAX. Para ello utiliza las funciones $(). Se combinan en el uso con CSS para un mejor diseño del elemento. Será necesaria en todo momento la manipulación de su código para su adaptación a nuestra página, tanto a nivel estético como a nivel funcional. Las librerías las tendremos descargadas en nuestra aplicación y subidas a nuestro servidor. El hecho de que haya diferentes elementos según las versiones que se dispongan de estas librerías nos lleva a tener que usar diferentes versiones del mismo elemento. En esta aplicación usaremos las versiones y de las librerías. La hoja de estilos CSS de la versión nos servirá para los elementos de la versión Cada vez que queramos incluir en nuestra página web un elemento jquery deberemos incluir el siguiente código: Además de la inclusión de estas librerías en nuestro código, deberán recibir una invocación de código, esto lo indicaremos parte por parte según nos vayan apareciendo elementos a lo largo de la explicación que estamos haciendo sobre la construcción de producto. Documentación 85

89 Código relevante en Usuario Invitado Código de integración de APIs Las APIs o Interfaces de programación de aplicaciones son el conjunto de funciones y procedimientos que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción. En nuestro caso las utilizaremos para agregar elementos a la aplicación que nos son externos a ésta Código API Google Maps El API de Google Maps nos permite incorporar un mapa con un destino indicado en nuestro sitio web o aplicación. En este caso, la utilizaremos para incorporar en la web, la localización de la sede de nuestra empresa. Esto lo haremos mediante el siguiente código: Código API Skype El API de Skype nos permite incorporar un enlace para realizar una comunicación directa mediante esta plataforma en nuestra Web. Esta funcionalidad la conseguimos con el siguiente código: Documentación 86

90 Código Identificación A la hora de realizar la identificación, primero comprobamos que el usuario ha introducido los datos necesarios. A continuación, comprobamos si existe un rol para dicho usuario mediante la secuencia: Según sea su rol, se decanta por una opción siendo el rol 1 para entrar en la interfaz de usuario registrado, y el rol 2 para el usuario administrador. En ambos casos introducirá una sesión mediante la siguiente secuencia: En el caso de ser un usuario registrado, primero almacenará las variables de sesión oportunas y seguido comprueba si existe algún pedido pendiente de pago, según el resultado de éste le lleva bien a una web donde completar el pago, o bien a la web principal de usuario registrado, respectivamente. Lo explicado anteriormente se consigue mediante el siguiente código: Documentación 87

91 En el caso de ser un usuario administrador, primero almacenará las variables de sesión oportunas y seguido lleva a la web principal de usuario administrador, esto se realizará mediante el siguiente código: Código Ayuda en los campos Mediante la jquery Tooltip vamos a crear una ayuda al usuario sobre cómo debe ser el atributo de un campo del formulario a rellenar. Por ello, debemos llamar antes de cada código que refiere a un dato a rellenar, la llamada a la función será la siguiente: Para hacerlo real, en la etiqueta del campo incluiremos la ayuda mediante el distintivo title, de la siguiente manera: Código Validación Javascript Registro Cada campo del formulario tendrá una primera validación mediante código Javascript en la propia página cuando el usuario ejecute el enviar los datos. Para ello en la propia web invocaremos a los archivos de validación mediante el siguiente código: Documentación 88

92 Cada campo se valida de forma distinta según sus tipos de datos y sus parámetros. Un ejemplo del uso de este puede ser el del siguiente código: De esta si el valor introducido es incorrecto, no pasa el filtro, se alerta al usuario mediante mensaje de error, se le lleva al campo erróneo y no completa la acción Código Calendario del registro Cuando un usuario quiere registrarse, en el formulario aparecerá un calendario para poder indicar su fecha de nacimiento. Para ello, usaremos una función predefinida en jquery, que llevará de inicio el siguiente código, que hemos modificado hasta conseguir el resultado de calendario que hemos deseado: Para hacer visual este script usaremos el siguiente código: Documentación 89

93 Código Disponibilidad Usuario/Correo electrónico Tanto para el correo electrónico como para el identificador de usuario habrá una primera validación mediante código Javascript y AJAX. En la propia página se indicará si los datos existen ya en la base de datos y por lo tanto no podrán elegirse. Para ello, en la propia web invocaremos a los archivos de disponibilidad mediante el siguiente código: Este archivo de disponibilidad incluirá el siguiente código creado: Documentación 90

94 Y a la vez este código invocará a un código almacenado en el que se busca en la base de datos un usuario o correo electrónico, en este caso usuario, para ver si ya existe o no, devolviendo según el caso uno u otro resultado. El código es el siguiente: Para que aparezca en pantalla el resultado de si existe o no dichos atributos usaremos el siguiente código: Código Captcha Usamos una librería de nombre captcha que modificamos hasta adaptarla al objetivo que buscamos. De esta forma basaremos la consecución de un buen captcha dividiendo su integracion en dos partes, muestra y validación. Para su muestra utilizaremos el siguiente codigo que irá en el formulario. De esta forma el código aparecerá integrado en él. Documentación 91

95 Ya en la parte de la integración, necesitaremos incluir en el archivo del formulario el codigo que mostramos a continuación: Este codigo busca, mediante la creación de una cookie llamada ($GLOBALS[ DEBUG_MODE ]), que se pueda almacenar un valor para luego su comprobación. Para ello es necesario iniciar una sesión en el sistema mediante el comando de PHP session_start. A la hora de la validación seguiremos con la sesion empezada e incluiremos la librería del captcha como podemos comprobar en el siguiente código: Documentación 92

96 Para llevar a cabo la validación, la librería captcha procesa el valor mediante la función process_si_contact_form donde saca el resultado de la comparación de las cadenas. En caso de que la cadena no esté vacía y coincida con el valor verdadero, permitirá a la aplicación continuar con su cometido, mediante el siguiente código: Código Envío Correo Electrónico La función predefinida mail será la encargada del envío de correos electrónicos en el lenguaje php. Esta función tendrá varios parámetros que se deberán incluir en un orden, como son el destinatario, el asunto, el texto que irá agregado y, si se desea, se podrán especificar cabeceras con las que indicar información extra. Los 3 primeros parámetros coincidirán en descripción con el nombre de las variables. En la cabecera, desde from podremos indicar el nombre de emisor del sistema en lugar de que el servidor de correo le otorgue uno por defecto. El Reply-to indica el destinatario al cual responder al correo desde el que se envía no tiene posibilidad de recepción de respuestas. A continuación se muestra el código: Código Validación de Usuario Cuando un usuario completa su registro, mediante la capa lógica se realiza una validación de usuario en la base de datos. Para ello se realizan dos pasos. Primero se actualiza el campo de usuario de nombre validado pasando su valor de 0 a 1. A continuación, se actualiza el rol, modificando el campo rol, del valor por defecto que es 3 a 1, que es el número de rol del usuario registrado. Todo esto se realiza mediante las siguientes secuencias: Documentación 93

97 A continuación, realizaran los mismos pasos que en la identificación vista en el punto de este documento Código Olvidar Contraseña Cuando una contraseña se nos ha olvidado, la podremos recuperar mediante esta opción. Para ello se deben introducir otras credenciales a la identificación y que también definan al usuario de manera única. Para ello se realiza la comprobación del usuario mediante el nombre de usuario y su correo electrónico. En el caso de existir este usuario, se cambia la contraseña que tiene por una nueva creada aleatoriamente una contraseña y con carácter provisional, mediante la siguiente secuencia: Una vez realizado este cambio, se envía la nueva contraseña junto con su enlace para realizar el cambio vía , como vimos en el punto , para que el usuario pueda realizar el cambio. Documentación 94

98 Código relevante en Usuario Registrado Código Diálogos de error Disponemos de una función jquery para indicar errores ocurridos devueltos por la capa lógica. De esta forma cada vez que el sistema de un error, se volverá a la página anterior donde aparece sobrepuesto a la web una ventana indicando del error, para ello desde la capa lógica se devuelve solo una variable problema y en la capa de presentación ira el siguiente código que se muestra a continuación: Y seguido el código para que el mensaje de error aparezca pudiendo detallarlo Código Menú Desplegable de Impresión Para mostrarle al usuario todas las propiedades de impresión, se ha creado un menú desplegable. La problemática de este menú es la imposibilidad de compaginar todas las opciones de impresión entre sí. La mayoría de las opciones son compatibles unas con otras y por tanto debemos crear de forma dinámica un menú que varíe de opciones según se elijan. Por ejemplo, en el caso de que se seleccione un tamaño de folio A2, no se permitirá una impresión a doble cara, o si se escoge un tipo de folio de color, no se permitirá la impresión en color. Este dinamismo conlleva problemas a la hora de realizar la carga de los datos, dado que un código tan amplio y dinámico como el que manejamos necesita sus tiempos de ejecución. Por ello se ha creado una interfaz de carga que no muestra el contenido del menú hasta que no se cargue de forma completa. Esta interfaz constará de dos imágenes y un texto indicativo, formando así una imagen completa. Esta interfaz se posicionará coincidiendo con el marco del menú. Su código es el siguiente: Documentación 95

99 Todo este código funciona gracias al siguiente código javascript, que hace que las imagen completa de carga esté visibre cuando no esté el contenido cargado y oculto. Visto ésto, hablaremos sobre el propio menú desplegable. Como necesitaremos subir un documento será necesario declarar el enctype del formulario como multipart/form-data de la siguiente manera: Posteriormente usaremos un input type file para recogerlo con la siguiente etiqueta: En la elección del tipo papel y su tamaño lo gestionamos de forma combinada mediante una combinación de select dinámicos, de forma que según elijamos en el select del tamaño del papel, aparecen unas u otras opciones en el select del tipo de papel. Para la realización de esto hemos encontrado en la web una librería javascript llamada chainedmenu que nos permite realizar estas operaciones. La modificación del archivo pese a finalmente parecer sencilla no lo fue así en su implementación. En la capa de presentación, es decir en la web donde aparece el menú visible incluiremos el siguiente código en el que invocaremos a la librería chainedmenu y a Documentación 96

100 la configuración de la librería que le llamaremos config mediante el siguiente código: En el archivo javascript config.js irán incluido el contenido de los select, primero declararemos el listado del tamaño mediante la siguiente secuencia: Y le daremos los valores con las siguientes secuencias: Tras esto según el valor del menú le daremos al segundo select unos valores u otros. Por ejemplo para el valor a4 que es el que más opciones distintas de tipo de papel posee, dispondrá del siguiente código: Documentación 97

101 Y para los tamaños A0, A1 y A2 que solo dispondrán de un tipo de papel blanco normal dispondrá del siguiente código: Para hilar los dos select en la capa de presentación usaremos el identificador del primer select, como vemos en las siguientes etiquetas. Otro aspecto a valorar también en el dinamismo del menú se basa en los botones radio. Así, según actives un botón radio u otro, se activa uno u otro botón de otro campo, creando de esta manera una dependencia entre ellos, lo podemos ver en el siguiente código: Pero para que ésto ocurra debemos tener una librería instalada y en este caso usamos la librería javascript formmanager que invocaremos desde la capa de presentación a Documentación 98

102 la capa lógica con el siguiente código: Este código lo usaremos para los campos color, doble cara, orientación y páginas por hoja. También influirá en la ampliación o reducción del documento de forma que si en algún caso no se permite esta opción, se deshabilitará el campo con el siguiente código dentro del input: Código de Tipos Admitidos Contrastaremos los tipos de documentos admitidos por la aplicación. El sistema solo admite documentos con extensiones PDF, DOC, DOCX y ODT, por lo que deberemos restringir el paso a solo estos formatos. Para ello los respectivos fabricantes de formato de estos documentos nos ofrecen su tipo de datos que no sirven para hacer la comparativa y por tanto la restriccion. Ésto lo haremos con el siguiente código: Código Consecución Número de páginas Código Consecución de número de páginas para archivos PDF La función count_pagespdf cuenta el número de páginas que tiene un pdf mediante funciones establecidas, la forma en la que lo hace, es mirando los atributos de archivo que tiene un documento PDF. Lo vemos en el siguiente código: Documentación 99

103 Código Consecución de número de páginas para archivos DOC y DOCX La función count_pagesdocx, similar la funcion count_pagesdoc, cuenta el numero de páginas que tiene un documento word mediante funciones establecidas, la forma en que lo hace es abriendo el propio documento y a partir de ahí encuentra los atributos de archivo que tiene un documento DOC o DOCX. Lo vemos en el siguiente código: Código Consecución de número de páginas para archivos ODT La función count_pagesodt es más compleja. En particular no he encontrado en internet ninguna funcion que saque el numero de páginas. Por lo tanto he tenido que inventar mi propio algoritmo. Un documento de texto de OpenOffice es de codigo abierto. Los archivos ODT están comprimidos. De la descompresion de éstos resultan 6 archivos y una carpeta. Tras descomprimir el archivo ODT borramos todos los documentos y carpeta que no nos hacen falta dejando solo el documento meta.xml donde encontraremos todos los atributos del archivo. Mediante un sistema creado que lee XML, recorreremos el sistema buscando la etiqueta document-statistic donde se almacena todo lo referente a los atributos del documento. En particular tenemos que sacar el valor de la variable page-count donde se almacena el número de páginas. Todo esto lo sacaremos con el siguiente código: Documentación 100

104 Código Contar costes y pesos de un documento XML Para realizar el cálculo de costes de impresión, como veremos en el punto , será necesario tomar los valores de los costes de impresión. Estos valores están dentro de un documento XML, el cual manejamos mediante unas funciones creadas: De esta forma, mediante el código que exponemos a continuación sacamos los valores alojados en su interior. Documentación 101

105 Código cálculo de los costes del paquete Para calcular los costes de un paquete primero debemos validar que todos los parámetros sean correctos y sean compatibles entre ellos. De esta manera si pasa esta fase supondrá que la combinación de los parámetros introducido es compatible entre ellos. Destacamos los referentes a la recepción del documento, para lo que usaremos el siguiente código: Si ha conseguido pasar esta fase indicará que el archivo es correcto. Entonces daremos un nombre al documento subido y lo almacenaremos en nuestro sistema mediante el siguiente código: Documentación 102

106 Contaremos el número de páginas invocando a las funciones anteriormente expuestas mediante la siguiente asignación: Crearemos el coste páginas del pedido por unidades dando ésta lugar al número de caras de folio total a imprimir mediante la siguiente asignación: Posteriormente sacaremos los costes de impresión mediante la función creada y a cada uno le asignaremos una variable con el siguiente código: Jugando con las variables color, tipo de documento y formato de documento que serán las que pueden incrementar el precio, sacaremos el coste total del paquete mediante el siguiente código: Como la aplicación nos pide que el coste total del pedido no sea más de 1000 euros, desarrollaremos un código que haga cumplirlo, así si no existen paquetes en el pedido no habrá problema, pero si lo hay, debemos comprobarlo con el siguiente código: Documentación 103

107 Si no se cumple, no permitirá continuar con la operación Código introducción de paquete en cookies Introducimos los datos que hemos recibido del formulario y que hemos calculado en una variable de sesión de tipo array. Lo llamaremos paquetex y a la vez ésta irá en otro array llamado conjuntopaq donde se almacenan todos los paquetes. Lo haremos con el siguiente código: Código de pedido cerrado En el momento en que se dispone a la finalización de un pedido, la cesta se cierra para no poder modificar los datos cuando ya estén almacenados. Ésto lo haremos mediante el almacenamiento en una cookie de sesión de una variable que llamamos cestacerrada. A esta variable se le asignará e valor 1 que indica que la cesta está cerrada. En el caso de volver a abrirse se destruirá dicha variable de sesión. Documentación 104

108 A la hora de maniobrar, permitirá seguir haciendo operaciones en la cesta en caso de que ésta no esté cerrada. Se podrá volver a abrir. La comprobacion hara con el siguiente código: Código cesta La cesta dispondrá de un menú desplegable basado en jquery. El nombre de esta función será accordion, describiendo el nombre de ésta su comportamiento. Para ello incluye el siguiente script: Invocaremos a esta función mediante la siguiente etiqueta: Cada elemento del menú será un paquete de los contenidos en el pedido, los sacaremos mediante el siguiente esquema de recorrido: Incluido en cada elemento estará cada paquete, su descripción se puede mostrar en pantalla mediante su código central, que es el siguiente: Documentación 105

109 Código de menú para modo entrega y factura Utilizamos una jquery basada en el DOM Selectable, una librería php para elegir opciones, la modificamos y finalmente nos queda el siguiente código: Este código no servirá de nada si no se puede elegir una opción, esto se hace mediante la exposición en forma de código html con las siguientes etiquetas: Para visualizar el resultado, en los apartado span, aparece el código escrito en las variables $codigo1 y $codigo2; Documentación 106

110 Código traslado de pago a PayPal Paypal proporciona al desarrollador de una serie de métodos para adaptar las opciones de pago. En este caso, con el siguiente código, modificaremos las siguientes acciones: - return: la web a la que PayPal lleva cuando finalice correctamente la aplicación. - business: la clave de identificación del vendedor. - quantity: el valor 1 indica que no se pueden modificar las cantidades. - item_name: el asunto de pago. - ítem_ numer: el número de referencia. - amount: el coste que el usuario debe pagar. - currency_code: la moneda en que se desea recibir el pago. - cancel_return: la web a la que PayPal accede en caso de cancelación. - no_shipping: el valor 1 significa que no lleva gastos extra de envío. - image: será la imagen mediante la cual acceder a la web de pagos. Documentación 107

111 Código almacenamiento de datos en la base de datos Para una correcta inserción, lo debemos realizar todo mediante una sola transacción. Lo haremos con el siguiente código: En el caso de haberse insertado bien el pedido, insertaremos uno por uno cada paquete con el siguiente código: Documentación 108

112 Si por algún casual, algo falla, se deshacer todas las operaciones de inserción Código recuperación del pago En el caso que haya algún pedido que no se haya pagado, en la identificación se hace una comprobación y en caso de existir algún caso se envía a una web de recuperación del pago del pedido. Lo haremos con el siguiente código: Código relevante en Usuario Administrador Documentación 109

113 Código de Facturación Utilizaremos las gráficas Graphpico para realizar nuestros gráficos. Se trata de una herramienta para generar gráficos de carácter estadístico en línea. Componente escrito en PHP + GD, genera gráficos en formato.png, actualmente existen los estilos Porcentaje, Barras y Pastel Gráfico de porcentajes El gráfico mide la rentabilidad mensual, se supone la rentabilidad del sistema cuando se llegue a los 1000 euros de facturación al mes. El 100% indica el momento en que se ha llegado a la rentabilidad. Lo mostraremos en gráfico con el siguiente código: Gráfico de barras El gráfico mide el consumo total durante los 6 últimos meses. Con esta etiqueta aparece el grafico con sus consumos. Por cada mes que se haya representado en la gráfica deberemos incluir una etiqueta como la siguiente: Con ésta podremos aclarar mediante una simbología de colores a que mes pertenece cada barra de la gráfica. Documentación 110

114 Gráfico de pastel El gráfico de pastel mide el porcentaje de los pedidos que son para recogida y el porcentaje que son para envío. Lo mostraremos en gráfico con el siguiente código: Cadena de Modificación del fichero XML Los datos que queremos modificar están en un archivo XML. Para modificar este de modo seguro, cambiaremos de manera completa el archivo mediante el uso de cadenas, cambiando en la cadena el valor o los valores que queramos sustituir. El código de modificación será para costes de impresión, costes de envío y pesos. Un ejemplo de la forma en que se almacena este código es la siguiente: Documentación 111

115 3.3.2 Interfaces finales En el siguiente apartado se mostrarán algunas de las interfaces del sistema para que pueda verse el resultado final Interfaces de Usuario Invitado Interfaz Principal Interfaz Identificacion La interfaz Identificación representa la identificación y autenticación del usuario con el sistema. Tras introducir un nombre de usuario y contraseña y darle al botón Enviar, se realiza una comprobación de que los datos son válidos. En caso de que sean correctos se envía a la sección correspondiente, en caso contrario se muestra un mensaje de error mediante ventana emergente. Documentación 112

116 Interfaz Registro La interfaz Registro representa la creación de un nuevo usuario registrado. Tras introducir todos los datos solicitados se realiza una comprobación de que los datos son válidos. En caso de que sean correctos se completará el registro desde el correo electrónico. En caso contrario se muestra un mensaje de error Interfaz Olvidar Contraseña La interfaz Olvidar Contraseña se utiliza para cuando algún usuario haya extraviado su contraseña pueda recuperarla. Para ello habrá que introducir nombre de usuario y correo electrónico, y se realizará una comprobación de que los datos son válidos. En caso de que sean correctos se cambiará a través del correo electrónico, en caso contrario se muestra un mensaje de error Interfaz Cambio de Contraseña La interfaz de Cambio de Contraseña será el paso siguiente tras recibir la contraseña provisional en el correo electrónico. Tras ello, el usuario debe introducir nombre de usuario y nueva contraseña. Se realiza una comprobación de que los datos son válidos. En caso de que sean correctos se cambiará a través del correo electrónico, en caso contrario se muestra un mensaje de error. Documentación 113

117 Interfaces de Usuario Registrado Interfaz Principal Interfaz Consultar Perfil La interfaz Consultar Perfil mostrará al usuario todo lo referente a los datos de su cuenta y al control de sesiones que el sistema ha tenido sobre él Interfaz Modificar Perfil La interfaz Modificar Perfil permitirá al usuario hacer un cambio en alguno de los datos de su perfil o incluso dar de baja su cuenta. Se realizará una comprobación de que los datos son válidos. En caso de que sean correctos se actualizará o borrará, en caso contrario, se muestra un mensaje de error. Documentación 114

118 Interfaz Éxito Modificación La interfaz Éxito Modificación mostrará con una señal que todo el proceso ha funcionado de la forma adecuada, consiguiendo el propósito final de la operación Interfaz Ver Pedidos La interfaz Ver Pedidos permitirá al usuario ver los pedidos que ha realizado en la aplicación Interfaz Hola Usuario La interfaz Hola Usuario dará la bienvenida al usuario indicando su nombre y el estado en el que se encuentra su sesión Interfaz Añadir Paquete La interfaz Añadir Paquete muestra las opciones de impresión de las que dispone el usuario, deberá rellenarlas y enviarlas. Tras ésto, se realizará una comprobación de que los datos son válidos. En el caso de que sean correctos, se almacenará el paquete, en caso contrario se muestra un mensaje de error. Documentación 115

119 Interfaz Cesta La interfaz Cesta permitirá al usuario ver en todos los momentos el estado en que se encuentra su pedido a la hora de realizarlo, desde el podrá eliminar el pedido, subir las unidades o ver más detallado cada paquete del pedido Interfaz Paquete Detallado La interfaz Paquete Detallado mostrará todos los detalles del paquete que se ha seleccionado. Desde esta interfaz también se podrán incrementar o decrementar su número de unidades Interfaz Entrega La interfaz Entrega mostrará la correspondiente interfaz en caso de que el usuario se decante por la opción de recogida como de envío a domicilio. En ambos casos aparecerán unos formularios que el usuario deberá rellenar con los datos correspondientes. Tras esto se realizará una comprobación de que los datos son válidos. En caso de que sean correctos se almacenará en el pedido, en caso contrario se muestra un mensaje de error. Documentación 116

120 Interfaz Factura La interfaz Factura permitirá al usuario se decante por la opción de factura como albarán. En ambos casos aparecerán unos formularios que el usuario deberá rellenar con los datos correspondientes. Tras esto se realizará una comprobación de que los datos son válidos. En caso de que sean correctos se almacenará en el pedido, en caso contrario se muestra un mensaje de error Interfaz Pago La interfaz Pago será donde el usuario realice el pago de su pedido. Para ello la plataforma de pagos PayPal le pedirá las credenciales de la aplicación para realizar el pago. Se realizará una comprobación de que los datos son válidos. En caso de que sean correctos se realizará el pago, en caso contrario se muestra un mensaje de error, y pedirá al usuario que vuelva a introducir sus datos correctos. Documentación 117

121 Interfaz Recuperar Pedido La interfaz Recuperar Pedido se abrirá en caso de que el usuario tenga algún pedido pendiente a la hora de abrir una nueva sesión en la aplicación. El usuario deberá elegir entre recuperar el pedido o eliminarlo y continuar Interfaz Pago Pendiente La interfaz Pago Pendiente permitirá a un usuario volver a la interfaz Pago para realizar este en caso que anteriormente hubiese fallado, indicará los datos del pedido y la opción de entrar en la plataforma de pagos Interfaces de Usuario Administrador Interfaz Principal Documentación 118

122 Interfaz Visualizar Datos La interfaz Visualizar Datos permite al administrador ver lo que está ocurriendo en la aplicación a nivel de cada entidad del sistema como son, Sesiones, Usuarios, Pedidos, Paquetes y los históricos de estos tres últimos Interfaz Facturación La interfaz Facturación permite al administrador ver la facturación que tiene a nivel de ingresos, de sobres y de sellos Interfaz Modificaciones La interfaz Modificaciones permite al administrador modificar los valores para los costes de impresión, los costes de envío y para los pesos de cada elemento que se contemple en la aplicación. Documentación 119

123 Interfaz Organigramas La interfaz Organigramas mostrará mediante un formato PDF los documentos esquematizados sobre el asunto que queramos visualizar, bien sea el organigrama web o el organigrama de la base de datos Seguridad En la siguiente sección de implementación, se van a detallar algunos aspectos referentes a la seguridad del sistema Control de acceso a la aplicación Como se ha ido comentando anteriormente, hay secciones de la aplicación web en las que es necesario identificarse con el sistema. Para ello los usuarios con estos privilegios poseen unas credenciales únicas e intransferibles que les permite el acceso. Además, cada uno de los usuarios posee un rol diferente. En caso de que un usuario quiera acceder a un entorno para la cual no tiene privilegios, el sistema le direccionará automáticamente a su entorno. Documentación 120

124 3.4 Pruebas Para verificar que lo que se está realizando funciona correctamente, es necesario llevar a cabo un plan de pruebas. Durante la fase de implementación se han ido realizando pruebas diariamente hasta lograr el funcionamiento perfecto de la aplicación. Es por ello que mostrar todas las pruebas sería una tarea muy repetitiva. Sin embargo, se han realizado dos grandes pruebas finales con el objetivo de comprobar que la aplicación funciona en su totalidad. Una de estas pruebas se ha realizado por cada uno de los tres módulos, y la otra, siguiendo un proceso de desarrollo lineal. Las pruebas han logrado en su totalidad un resultado satisfactorio. El resultado de estas pruebas se puede ver en el anexo 1. Documentación 121

126 APLICACIÓN DE IMPRESIÓN Documentación 123

128 4 APLICACIÓN DE IMPRESIÓN 4.1 Análisis El Proyecto Fin de Carrera, además de la aplicación web, tendrá una aplicación de impresión que permita al usuario empleado: Ver en un listado, los pedidos detallados que están pendientes para su impresión. Avisar mediante mensaje de texto al teléfono móvil del usuario, de la finalización de su pedido. De esta forma, éste puede pasar a recogerlo o ya ha sido enviado a su domicilio Pasar a un histórico los pedidos, una vez éstos ya hayan sido entregados. Limpiar los documentos que ya han sido impresos, con un margen de tiempo suficiente para ser innecesarios en la aplicación. La aplicación web constará de una misma interfaz general para toda esta aplicación. En este apartado existirán las herramientas necesarias para realizar todas las operaciones. Estableceremos una clara división para los diferentes grupos de herramientas. Al manejar un sistema de mensajería, suponiendo este un coste, uno de los aspectos más importantes en la realización será la seguridad en la aplicación. El fácil manejo de la aplicación debe ser otro de los factores que predominen en la aplicación. El usuario empleado debe disponer de una interfaz ágil que le permita de forma sencilla y rápida realizar su acometido. Comenzamos esta sección de análisis con un apartado de terminología, posteriormente describiremos los requisitos de la aplicación de impresión, a continuación presentaremos los casos de uso y, terminaremos con el modelo de datos. Como muchas partes del proceso de desarrollo de esta aplicación coinciden con los de la aplicación web, hemos considerado oportuno incluir aquellos aspectos que aporten alguna novedad a lo ya presentado. Documentación 125

129 4.1.1 Terminología La mayoría de los términos que se usarán en esta aplicación, son los mismos que aparecen en la terminología de la aplicación web (ver punto 3.1.2). Otros términos del lenguaje empleado en la aplicación de impresión son los siguientes: Aplicación de impresión: es también una aplicación web donde los empleados de la empresa acceden para llevar a cabo la impresión de los documentos enviados por el cliente. SMS: Servicio disponible en los teléfonos móviles que permite el envío de mensajes cortos. Usuario Empleado: usuario de la aplicación de impresión, al que se le entregan unas credenciales para su identificación. Puede utilizar las diferentes herramientas que la aplicación de impresión pone a su disposición. Fpdf: Plataforma para la generación de documentos en formato PDF. Cliente: Usuario Registrado al cual pertenece el pedido Catálogo de requisitos A continuación, describiremos los requisitos tanto funcionales como no funcionales de la aplicación Requisitos funcionales del sistema El usuario empleado, es el usuario único que, tras haberse recibido unas credenciales para este rol por parte del desarrollador, ha entrado directamente a la aplicación de impresión. Los requisitos identificados para este usuario son los siguientes: El usuario empleado necesitará unas credenciales para identificarse con el sistema. El usuario empleado podrá visualizar los pedidos pendientes de impresión y manejarlos. Entre otras cosas podrá acceder a un pedido y ver detalladamente las propiedades de los paquetes que lo componen. El usuario empleado puede descargar cada uno de los documentos de un pedido. El usuario empleado puede descargarse para su impresión, el documento que el sistema creará con todo lo referente al pedido y a cada uno de sus paquetes. El usuario empleado tendrá la herramienta de enviar SMSs a los clientes cuando el pedido este realizado. El usuario empleado podrá ver el estado en que esta un mensaje, y visualizar mediante un listado los mensajes enviados. El usuario empleado deberá tener una herramienta para, cuando el pedido haya sido entregado, poder pasar los pedidos y paquetes a sus históricos. Documentación 126

130 La aplicación deberá permitir al usuario empleado hacer una limpieza de los archivos cuando haya pasado un tiempo suficiente desde su uso, establecido en 30 dias Requisitos no funcionales del sistema El sistema debe responder en un tiempo razonable. El sistema tendrá una interfaz sencilla de usar Requisitos de ampliación Población de una base de datos que se compartirá con la aplicación web. Impartir curso sobre el uso de la aplicación Modelo de Casos de Uso Los diagramas de casos de uso que se han identificado son los siguientes: Diagrama de Casos de Uso Ilustración 31: Diagrama de Casos de Uso: Aplicación de impresión. Documentación 127

131 Especificación de casos de uso Mostrar Pedidos Pendientes Caso de uso Objetivo Actores Pasos Mostrar Pedidos Pendientes Muestra los pedidos pendientes para su impresión. Usuario Empleado 1. El empleado accede a la web de pedidos pendientes de impresión. 2. El empleado visualiza los pedidos pendientes de impresión. 3. El empleado puede acceder a las opciones que dispone, que son: entrar en pedido detallado, ir a envío de SMS, marcar el pedido como entregado o sacar el resumen del pedido en PDF Mostrar Paquetes Caso de uso Objetivo Actores Precondiciones Pasos Mostrar Paquetes Muestra los paquetes con sus propiedades de impresión de un pedido. Usuario Empleado Debe existir un paquete para poder entrar en él. 1. El usuario accede a la web de Mostrar Paquetes. 2. El usuario pincha sobre un paquete. 3. La aplicación muestra todas las propiedades de impresión del paquete Marcar Paquete Imprimido Caso de uso Objetivo Actores Precondiciones Pasos Marcar Paquete Imprimido Marcar un paquete como impreso una vez este se haya imprimido. Usuario Empleado Debe existir un pedido con algún paquete. 1. El usuario indica que el paquete ha sido imprimido. 2. La aplicación marca el paquete como impreso Crear PDF Pedido Caso de uso Objetivo Actores Precondiciones Pasos Crear PDF Pedido Crear un documento PDF con todas las propiedades del pedido y las propiedades de impresión de cada uno de los paquetes. Usuario Empleado Debe seleccionar algún pedido. 1. El empleado pincha sobre el pedido que quiere ver resumido en formato PDF. 2. La aplicación genera documento PDF. 3. La aplicación muestra el documento PDF. Documentación 128

132 Gestión SMS Caso de uso Objetivo Actores Pasos Gestión SMS Permite elegir mediante un menú cualquiera de las opciones sobre SMS existentes. Usuario Empleado 1. El empleado accede a la web de gestión de SMSs 2. El sistema muestra un menú con las diferentes opciones Envío SMS Caso de uso Objetivo Actores Precondiciones Pasos Extensiones Enviar SMS Envío de un SMS a un cliente Usuario Empleado Debe existir un pedido finalizado 1. El empleado introduce el número de pedido y número de móvil. 2. El empleado envía la información. 3. La aplicación comprueba que existe el pedido. 4. La aplicación comprueba la forma de entrega. 5. Según la opción de entrega, el sistema asigna unas propiedades u otras al SMS. 6. La aplicación comprueba el saldo de mensajes de la aplicación. 7. La aplicación envía el mensaje. 8. La aplicación recibe la confirmación del envío. 9. La aplicación muestra las propiedades del envío correcto. 10. La aplicación guarda los datos del mensaje en la base de datos. 4.1 Si los datos no son correctos, se muestra una web indicando que los datos no son correctos. 7.1 Si no se dispone de saldo no se enviara en mensaje informando del error. 9.1 Si la aplicación no envía correctamente el SMS, la aplicación informa al empleado del error Si los datos no se guardan en la base de datos, el sistema accede a una web para introducirlos manualmente. Documentación 129

133 Diagrama de actividad Envío SMS Ilustración 32: Diagrama de Actividad: Envío SMS Documentación 130

134 Inserción manual en la base de datos del SMS Caso de uso Objetivo Actores Precondiciones Pasos Cuestiones Inserción manual en la base de datos del SMS Introducción de los datos del SMS en caso de fallo en la inserción en la base de datos. Usuario Empleado Debe haberse enviado antes algún SMS y fallado su inserción. 1. La aplicación ofrece una web donde poder insertar los datos. 2. El empleado introduce el identificador de pedido, de SMS y de usuario. 3. La aplicación muestra el resultado en la actualización en la base de datos. El hecho de que el envío del SMS y la inserción del dato en la base de datos no pueda hacerse en una transacción, conlleva a tener que plantear la inserción del mensaje de forma manual en caso de que no se haya insertado correctamente el dato en la base de datos Ver Estado SMS Caso de uso Objetivo Actores Precondiciones Pasos Ver Estado SMS Ver el estado en que se encuentra algún SMS. Usuario Empleado Debe haberse enviado antes algún SMS. 1. El empleado accede a la web de estado del SMS. 2. El empleado introduce el identificador de pedido, de SMS y de usuario. 3. La aplicación muestra el estado del SMS Consultar SMSs Enviados Caso de uso Objetivo Actores Pasos Consultar SMSs Enviados Muestra mediante un listado los mensajes enviados. Usuario Empleado 1. El empleado accede a la web de consultas de SMS. 2. El empleado introduce las fechas entre las que quiere ver los SMS enviados. 3. La aplicación muestra el listado de los mensajes enviados Marcar Pedido Entregado Caso de uso Objetivo Actores Precondiciones Marcar Pedido Entregado Pasa a históricos un pedido cuando éste ha sido recogido. Usuario Empleado Debe haber un pedido que haya sido recogido o enviado. Documentación 131

135 Pasos Extensiones 1. El empleado accede a la web de entrega de pedidos. 2. El empleado introduce los identificadores de pedido y usuario, y el número de paquetes del pedido. 3. La aplicación comprueba que existe el pedido. 4. La aplicación comprueba que se ha avisado mediante SMS al cliente. 5. La aplicación pasa los pedidos y los paquetes a un histórico, borrándolos de los pedidos actuales. 3.1 Si el pedido no existe el sistema informa del error. 4.1 Si no se ha avisado al cliente el sistema informa del error. 5.1 Si la aplicación no consigue pasar los pedidos y paquetes al histórico en su totalidad, deshace la operación e informa del error Diagrama de actividad Marcar Pedido Entregado Ilustración 33: Diagrama de Actividad: Marcar Pedido Entregado Limpiar Archivos Caso de uso Objetivo Actores Pasos Limpiar Archivos Limpia los archivos que ya han sido imprimidos con un margen de entrega establecido. Usuario Empleado 1. El empleado accede a la web de limpieza. 2. El empleado ejecuta la opción de limpieza. 3. La aplicación elimina los documentos tras pasar un tiempo prudencial desde su uso estimado en 30 dias. Documentación 132

136 4.1.4 Análisis del modelo de datos La aplicación de impresión compartirá la misma base de datos que la aplicación web, la única variante que ofrecerá sobre ésta será la inserción de 3 nuevos atributos. En particular, en el diseño E/R, para la entidad Paquete se ha añadido el atributo impreso, que indicará cuando un paquete está ya impreso o a falta de impresión. Lógicamente, este atributo no aparecerá en el histórico de pedidos puesto que cuando se realiza la entrega, y por tanto la información del pedido pasa a un histórico, el paquete siempre estará impreso. La entidad Paquete en el esquema E/R quedará así: Ilustración 34: Esquema E/R: Entidad Paquete Los otros dos atributos serán los identificadores del envío de mensajes, tanto para pedido como para el histórico de pedido (idenviosms e idenviosmsh respectivamente). Las entidades Pedido e HistoricoPedido en el esquema E/R quedarán así: Ilustración 35: Esquema E/R: Entidad Pedido e HistoricoPedido Documentación 133

137 4.2 Diseño Esta sección describirá la arquitectura de la aplicación de impresión, el diseño de la base de datos y el prototipo de interfaces Definición de la arquitectura La aplicación de impresión sigue la misma arquitectura que la aplicación web, que se ha descrito en el punto Definición de la arquitectura por lo que no diremos más al respecto Diseño de la base de datos Modificadas las tablas de la base de datos, incluyendo los nuevos atributos especificados anteriormente en el modelo de datos, el diseño final de la base de datos será el siguiente: Ilustración 36: Módelo lógico de la aplicación de impresión Documentación 134

138 El atributo impreso de la tabla Paquete, será de tipo booleano siendo el valor 0 el que indique que no está impreso el documento, y el valor 1 indicando que si lo está. El atributo idenviosms de la tabla Pedido e idenviosmsh de HistoricoPedido, tendrán un valor numérico otorgado por el sistema de mensajería con el que se identificará al mensaje de aviso que se le envió al usuario Prototipo de interfaces de usuario Esta sección mostrará las principales interfaces de la aplicación de impresión. En cuanto a la usabilidad, cabe destacar que,, tanto el tipo de letra utilizado en el sistema como los colores e imágenes, han sido impuesto por el cliente ya que la empresa PYC Papel y Copia tiene una imagen corporativa la cual debemos mantener. Como se ha comentado para la aplicación web, la imagen corporativa se podría cambiar fácilmente. Las interfaces se han diseñado de mutuo acuerdo con la empresa. Ésta será la interfaz principal del usuario empleado. Para acceder a ella, el usuario anteriormente deberá haberse identificado como usuario empleado. Desde esta interfaz el usuario empleado podrá acceder desde el menú a todos los módulos de los que dispone para realizar sus operaciones. Documentación 135

139 4.3 Construcción Por último, en este aparatado describiremos los aspectos más relevantes de la fase de construcción y mostraremos parte de las interfaces finales de la aplicación. Comparte con la aplicación web todos los aspectos de programación y de conexión con la base de datos, por lo que omitiremos cualquier tipo de información sobre ellas Código relevante Código Identificación La identificación se realiza de la misma forma que vimos para la aplicación web, reutilizando su código para solo admitir un tipo de rol, con valor 4 que indicará que el usuario es usuario empleado. Lo haremos con el siguiente código: Elección del logotipo de descarga A la hora de mostrar un paquete con sus propiedades y la opción de descargar el documento, hemos indicado mediante un icono el formato del documento, para ello, y dependiendo de los cuatro tipos de formatos admitidos, usaremos el siguiente código: Documentación 136

140 Código de envío de SMS Para los envíos de SMS usaremos una librería PHP llamada SMSsend, con su archivo de extensión.inc, que nos proporciona la compañía donde tenemos alojado el servidor web. Este servicio es de pago, y se contrata por número de mensajes, por lo que es posible que haya un momento en el que éstos se agoten. Es por ello por lo que debemos llevar un control en la web. La implementación de este servicio web necesita de varios cambios sobre lo que se nos ofrece. Así, solo modificaremos los parámetros y la forma en que queremos mostrarlos al usuario. Será necesaria la inclusión de la librería mediante el comando: Según sea la forma de entrega (recogida o envío), le daremos un texto al mensaje u otro, con el siguiente código: A continuación, definiremos todas las opciones tanto de configuración del servicio, con setaccount, donde indicaremos el nombre de usuario de la aplicación, y setpwd, Documentación 137

141 donde pondremos la contraseña del servicio. Además con setto, incluiremos el número de móvil al cual queremos enviar el SMS mientras que el texto del mensaje se asignará con settext. Si queremos poner el nombre del contacto desde el cual se envía el mensaje, se hará con setfrom (ver el siguiente código). Tras tener todos los parámetros introducidos para el envío, procederemos a enviarlo con el siguiente comando: Una vez enviado el mensaje, necesitaremos confirmación de que se ha realizado con éxito. Esta información, junto con el resto de datos del mensaje, se pueden obtener fácilmente de objeto testsms. A partir de estos comandos devolvemos los resultados del envío. Posteriormente, introduciremos en el registro correspondiente de la tabla pedido, la fecha de aviso y el identificador del envío en la base de datos mediante el siguiente código: Documentación 138

142 Código de estado de SMS Tras comprobar que existe un SMS coincidente con los datos introducidos, solicitaremos a la aplicación que nos ofrezca su estado mediante los siguientes comandos: Sacamos el número del teléfono móvil al cual se le envío el mensaje, mediante la siguiente instrucción: El estado en que se encuentra el mensaje lo sacaremos mediante la siguiente instrucción: El resto de datos del pedido que mostraremos saldrán de hacer la consulta en la base de datos Código de la entrega del pedido Como hemos comentado anteriormente, este paso busca enviar los datos de la tabla de pedidos y paquetes actuales a las de un historico. Para ello, primero insertaremos los datos del pedido en el histórico de pedidos. Luego, uno por uno, haremos lo mismo con los paquetes en el histórico de paquetes. Para terminar, borraremos el pedido y los paquetes, que hemos pasado a historico, de las tablas pedido y paquete. En caso de que estos pasos no se realicen de forma completa, se deshará todo el proceso informando del error. Teniendo en cuenta esto, en primer lugar, sacaremos todos los datos d el pedido mediante la siguiente consulta: Dicos datos los insertaremos en el histórico de pedido mediante la siguiente sentencia, que incluye lo campos de la consulta anterior: Documentación 139

143 A continuación, se seguirán los mismos pasos para los paquetes. En particular uno por uno sacaremos los paquetes mediante la consulta: Y los pasaremos al histórico de paquetes con el siguiente código: Documentación 140

144 Por último, borraremos el pedido y los paquetes que quedan en las tablas de pedido y paquete actuales mediante las siguientes secuencias: Para paquetes primero: Para pedidos después: Todo ello se realiza en una única transacción de forma que de no realizarse de forma completa se desharía en su totalidad Código de la limpieza de archivos Cuando desee el usuario empleado, podrá eliminar los archivos que hayan pasado 30 días desde su entrega mediante la opción limpieza de archivos de la pagina de impresión. En dicha opción se ejecuta la siguiente instrucción: Documentación 141

145 4.3.2 Interfaces finales A continuación, mostraremos algunas de las interfaces finales más representativas de la aplicación de impresión Interfaz Identificación La interfaz Identificación contiene el formulario de acceso a las herramientas de la aplicación de impresión. Para acceder, será necesario disponer de las credenciales de acceso Interfaz Principal La interfaz Principal contiene el menú con las herramientas del usuario empleado. Documentación 142

146 Interfaz Pedidos Pendientes La interfaz Pedidos pendientes nos mostrará un listado con todos los pedidos pendientes de impresión. Podremos ver las características más relevantes del pedido. Desde esta interfaz podremos, para cada pedido: Acceder a su gestor de impresión. Acceder al envío de SMS de aviso. Acceder al gestor de entregas de pedidos. Abrir un PDF que muestra todas las características del pedido Interfaz Mostrar Pedido Detallado La interfaz Mostrar pedido detallado muestra los datos más relevantes del pedido y los paquetes de los que dispone, pudiendo acceder a cualquiera de ellos. También podremos visualizar que paquetes están ya impresos. Desde esta aplicación se puede ir al envío de mensaje. Documentación 143

147 Interfaz Mostrar Paquetes La interfaz Mostrar Paquetes muestra los datos más relevantes del pedido, todos los datos del paquete elegido, los paquetes que han sido ya impresos y el formato de archivo del documento enviado. Desde ésta interfaz se podrá ir al aviso del pedido, dar por finalizado un paquete y descargar el archivo a imprimir Interfaz Menú Gestión SMSs La interfaz Gestión SMSs muestra en forma de menú, las opciones que el usuario empleado tiene acerca de la gestión de mensajes de texto de la aplicación Interfaz Enviar SMS La interfaz Enviar SMS permite al usuario empleado, enviar un mensaje de texto con todos los detalles de la entrega en domicilio o recogida en tienda. Para ello, debe introducir el identificador de pedido y el número de móvil. Documentación 144

148 Interfaz Estado SMS La interfaz Estado SMS permite al usuario empleado, ver el estado en que se encuentra un mensaje. Para ello debe introducir el identificador del pedido y el número de móvil al cual se envió. Se decide pedir estos dos datos por motivos de seguridad Interfaz Consulta SMS La interfaz Consulta SMS permite al usuario empleado, ver los mensajes que han sido enviados entre las dos fechas que ha introducido Interfaz Entrega Pedido La interfaz Entrega Pedido permite al usuario empleado, dar como entregado un pedido con solo incluir sus respectivos: identificador de pedido, identificador de usuario y su número de paquetes. Se decide pedir estos tres datos por motivos de seguridad. Documentación 145

149 Interfaz Limpieza de archivos La interfaz Limpieza de archivos permite al usuario empleado, mediante un click en un botón, hacer una limpieza de archivos. 4.4 Pruebas Al igual que con la aplicación web hemos verificado que la aplicación funciona correctamente llevando a cabo un plan de pruebas. Las pruebas han logrado en su totalidad un resultado satisfactorio. El incluirlas aquí no aportaría nada nuevo, por tanto, se ha decidido incluirlas en el anexo 1. Documentación 146

150 GESTIÓN DEL PROYECTO Documentación 147

152 5 GESTIÓN DEL PROYECTO 5.1 Gestión prevista del proyecto El objetivo real de este apartado es dejar constancia de las horas reales que se han dedicado a realizar el proyecto y compararlas con la estimación que se hizo al inicio. Como suele pasar, las horas estimadas no coinciden en todas las etapas con las horas empleadas reales. Algunos de los factores que han hecho que se alargue el número de horas empleadas en algunos casos son factores como: Errores de estimación. Falta de formación por parte de la proyectante. 5.2 Gestión no prevista del proyecto La estimación indicaba que el momento de finalización del proyecto sería Septiembre del 2012, sin embargo no ha sido así, siendo el momento de finalización real, Julio del El proyecto se ha demorado en tiempo debido a los siguientes factores: El proyectante pasó dos etapas viviendo en Irlanda, haciendo cursos de inglés y buscando trabajo allí. El proyectante pasó cuatro meses en periodo de prácticas. El proyectante en su tramo final paso los dos últimos meses de proyecto, compatibilizando éste con el trabajo. 5.3 Gestión real del proyecto A continuación, se muestra una tabla en la que se pueden observar las horas estimadas al inicio del proyecto y las horas reales que se han empleado en cada una de las etapas. Documentación 149

153 DIRECCIÓN Y GESTION DEL PROYECTO Planificación Reuniones con la directora Reuniones con los asesores Seguimiento Limitación del proyecto DOCUMENTACIÓN DEL PROYECTO Generación DOP Generación de la memoria Preparación de la presentación Defensa del proyecto Estimadas Reales Diferencia * 1* FORMACIÓN APLICACIÓN WEB Análisis Diagramas de Casos de uso, especificación de casos de uso y diagramas de actividad Vistas de Interacción Análisis del modelo de datos Prototipo de interfaces Diseño Diseño de la base de datos Diseño de las clases de negocio Identificación Diagramas Documentación de clases Diseño de interfaces Generación de interfaces Documentación interfaces Construcción Generación del Script de la base de datos Implementación Generación de la ayuda Documentación de código Pruebas Prueba de la base de datos Pruebas unitarias de la aplicación Implantación Implantación del equipo Implantación de la aplicación web APLICACIÓN DE IMPRESIÓN Análisis Diseño Implementación Pruebas Implantación del sistema TOTALES Documentación 150

154 A continuación se muestran dos gráficos. El primero representa las horas estimadas del proyecto según las etapas: Aplicación web 48% Aplicación de impresión 16% Dirección y gestion del proyecto 6% Documentación del proyecto 18% Formación 12% Ilustración 37: Gráfico de horas estimadas del proyecto A continuación, mostraremos el gráfico referente a las horas reales invertidas en el desarrollo del proyecto. Aplicación de impresión 16% Dirección y gestion del proyecto 6% Documentación del proyecto 18% Aplicación web 48% Formación 12% Ilustración 38: Gráfico de horas reales del proyecto Se puede apreciar que, en proporción nos hemos equivocado de forma similar en todas las fases. Documentación 151

155 Para finalizar, mostrar un gráfico en el que puede verse de forma visual la diferencia existente entre las horas estimadas y las empleadas. Dirección y gestion del proyecto Documentación del proyecto Formación Horas empleadas Horas estimadas Aplicación web Aplicación de impresión Ilustración 39: Gráfico de comparativa entre horas estimadas y horas empleadas 5.4 Comparativas Después de haber finalizado el proyecto y analizando los resultados obtenidos, podemos decir que, como bien explicaremos más adelante en las conclusiones, que el proceso ha sido más costoso de lo que se había estimado. La razón principal de este desfase de horas ha sido un exceso de confianza en los conocimientos sobre la tecnología que se ha utilizado para el desarrollo. Durante la captación de los requisitos, el proyectante tuvo que insistir mucho sobre cuáles eran las funcionalidades exactas del sistema ya que el cliente se basaba más en los aspectos visuales que en su funcionalidad. El gran desfase se ha producido en la etapa de la implementación. El proyectante se ha enfrentado a lo largo de la implementación a errores que no sabía resolver directamente y para los que he tenido que dedicar un tiempo mayor del esperado. Documentación 152