Plataforma modular para la gestión de ponencias de congresos internacionales

Proyecto de Fin de Grado Plataforma Modular para la Gestión de Ponencias de Congresos Internacionales Autor: Gabriel Urso Santana Reyes Tutores Dr. D. Javier. J. Sánchez Medina Dr. D. Enrique Rubio Royo Trabajo de Fin de Grado – Gabriel Urso Santana Reyes 1/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes DEDICATORIA Dedico el trabajo realizado a mi familia, que me ha apoyado siempre y que sin su ayuda no hubiera podido finalizarlo. Especialmente a mis padres que ya son informáticos de facto tras atender y escuchar todas mis ideas y quienes me ayudan indicando incluso cómo resolver los problemas. Y a mi hermano que está siempre dispuesto a escuchar mis lamentos. 2/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes 3/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Índice de contenido Introducción........................................................................7 1 Objetivos...............................................................................7 2 Estado del Arte: Aplicaciones de Gestión de Congresos, definición y algunas actualmente en uso.....................................8 2.1 Desarrollos similares de la ULPGC..........................................9 2.2 Desarrollos comerciales existentes..........................................12 2.2.1 Papercept / Paperplaza.....................................................12 2.2.2 Openconf............................................................................13 2.2.3 Easychair............................................................................16 2.2.4 Conftool..............................................................................17 3. Metodología.......................................................................19 4. Plan de trabajo y temporalización..................................20 5. Organización de la memoria............................................21 Competencias....................................................................22 Aportaciones.....................................................................23 Análisis..............................................................................24 1. Descripción del problema................................................24 2. Análisis de requisitos de usuario.....................................24 2.1 Descripción de los requisitos de usuario................................24 2.2 Workflow de los artículos........................................................29 2.3 Descripción de la metodología y herramientas utilizadas....36 3. Backbone: Tecnologías utilizadas y justificación. Ventajas y desventajas frente a otras alternativas...................40 3.1 Tecnologías de desarrollo en el lado del cliente.....................40 3.1.1 Lenguajes...............................................................................40 4/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes 3.1.2 Frameworks...........................................................................40 3.2 Tecnologías de desarrollo en el lado del servidor..................43 3.2.1 Lenguajes...............................................................................44 3.2.2 Frameworks...........................................................................45 Requisitos hardware y software......................................47 Desarrollo..........................................................................48 1. Descripción de la configuración de la aplicación...........51 2. Descripción del Módulo Conference...............................53 3. Descripción del Módulo de Gestión de Usuarios...........54 4. Descripción del Módulo de Gestión de Artículos...........56 Manual de usuario y software.........................................59 Conclusiones y líneas futuras..........................................60 Anexos...............................................................................64 Bibliografía.......................................................................65 Glosario.............................................................................66 El patrón modelo vista controlador................................68 Manual de Usuario...........................................................71 5/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Introducción La organización de congresos internacionales incluye un conjunto amplio de tareas diversas, de variadas naturalezas. Algunas de ellas requieren una supervisión cuidadosa al ser factor determinante del éxito del congreso. Es posible que la tarea más delicada y compleja sea la organización del programa científico del evento, porque requiere satisfacer las necesidades, a veces contrapuestas, de muchas personas diferentes, con diferentes roles de participación en el mismo. Las necesidades de un participante son totalmente diferentes a las de un ponente, las de un revisor, o a las del director de programa de la conferencia (program chair). El participante requiere recibir una información en el formato publicitado por el congreso, tal vez poder participar en discusiones o debates, y recibir una documentación en forma de actas, libro de resúmenes (abstracts), etc. Un autor requiere poder enviar para consideración un resumen o un artículo (paper), recibir el resultado de la evaluación del mismo y poder, si es aceptado, subir el artículo definitivo, conocer cuándo tendrá lugar su comunicación, etc. Para complicar más las cosas, puede darse el caso, y se da con frecuencia, que las mismas personas actúan en el congreso con más de un rol diferente. 1 Objetivos El propósito de este TFG no puede ser abarcar toda esta problemática, dada la fuerte restricción temporal de los Trabajos fin de Grado. Este TFG trata de esbozar un prototipo que pueda ser extendido con posterioridad este trabajo, donde se presente un prototipo con el esqueleto y estructura fundamental de una aplicación futura que englobe el máximo de elementos de la organización del congreso. También se desea que se desarrollen dos módulos fundamentales: •un módulo para la gestión de usuarios y roles, asumiendo que podemos definir los roles, vistas y privilegios. •y un módulo que debe cubrir el workflow de las ponencias, desde su recepción, asignación a revisores, comunicación de resultado y recepción de versión definitiva. Los objetivos del trabajo a desarrollar en el TFG propuesto son los siguientes: 1) Elección de la tecnología web a utilizar, según criterios de mantenibilidad, modularidad, expandibilidad, flexibilidad y prestaciones 2) Desarrollo del prototipo de la aplicación global 3) Desarrollo de un módulo para la gestión de los usuarios y roles. 4) Desarrollo de un módulo para la recepción, revisión e inclusión de comunicaciones en el programa científico de un congreso internacional. 6/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes 2 Estado del Arte: Aplicaciones de Gestión de Congresos, definición y algunas actualmente en uso Una aplicación de gestión de conferencias es el software que es utilizado para la organización de conferencias, especialmente científicas. Ayuda a los diferentes tipos de usuario (director de programa (program chair), editor asociado (associate editor), revisor (reviewer), autor (author), director/codirector de sesión (session chair/cochair), etcétera ) a realizar su labor, esas tareas que deben realizar los participantes en la conferencia junto con funcionalidades de ayuda son las siguientes: •Recibir artículos iniciales (initial submissions) (con artículo (papers), subida de fichero, y datos del mismo) •Recopilación de las preferencias temáticas de los revisores •Recogida de los conflictos de intereses •Asignación de los revisiones a los documentos •Difusión de artículos a los revisores •Informe de recomendaciones de los revisores •Monitoreo de las opiniones •Intercambio de opiniones entre el Comité del programa •Garantizar la independencia de las recomendaciones de los revisores (quienes no pueden ver otros informes de revisión de los artículos) •Proporcionar un foro de discusión por artículo entre los revisores •Calificación en los informes de revisión •Informes de comentarios de los revisores y la decisión del comité del programa para los autores •Recopilación de versiones finales de los artículos •Gestor de contenidos del congreso con información del mismo, de la programación, los artículos, y toda la información relevante Diferentes aplicaciones de gestión de conferencias realizan funciones adicionales, que aunque no son las que una aplicación de gestión de conferencias básica realiza, tiene servicios que pueden ser útiles, esos servicios que pueden ayudar a una aplicación de gestión de conferencias y otros que están implementados en diferentes aplicaciones aunque no sean destinadas a tal fin, pero sirven de ayuda son los siguientes: •Creación de la web del congreso, una especie de gestor de contenidos específico del congreso, en donde se especifica la información de la conferencia y demás información útil en la misma •Planificador del programa del congreso, que permita planificar las sesiones del congreso dependiendo de los valores de los artículos, de necesidades específicas de cada ponente, y demás valoraciones que el director del programa decida •Registrar a los participantes, que puede ser un registro de cada participante, que permita una carga inicial, dependiendo de las necesidades de la aplicación y del cliente •Pago online de la matrícula al evento, existen diferentes plataformas para realizar esta tarea, pueden estar incluidas en la aplicación o ser externas 7/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes •Gestión de las reservas, facturación, servicio que permite a los participantes del congreso reservar plaza en la misma, realizando el pago, y además de reservar alojamiento y demás necesidades que podría llegar a tener un participante del congreso •Selección de la sede, servicio que permite al organizador del congreso elegir entre diferentes localizaciones en la que podría celebrar el evento •Organización de las salas y horarios, servicio que planifica las sesiones en las diferentes salas dependiendo de valores indicados por el cliente •Publicitar, servicio que permite al organizador del congreso publicitar el evento, publicitándolo en redes sociales, enviando publicidad del mismo y demás formas de publicitación del evento Existen aplicaciones que realizan las tareas de la gestión de conferencias gestionando varias conferencias: hay que tener en cuenta que la aplicación desarrollada es una aplicación que gestiona una conferencia (la información de la misma, los usuarios, los artículos (submissions), etcétera), no se trata de una aplicación de organización de múltiples conferencias (que gestione la información de diferentes conferencias, que muestre información de diferentes conferencias que haya, etcétera) También hay que tener en cuenta que no es una aplicación de ayuda de creación de conferencias (en la que te indique lugares en los que organizar el evento, alojamientos para participantes, y demás servicios externos) como por ejemplo http://www.kineticsolutions.co.uk/. A continuación se mostrarán algunas de las aplicaciones que actualmente están en el mercado, enseñando algunas de sus funcionalidades, hay que tener en cuenta, que algunas son de pago y no pueden ser descargadas gratuitamente para su prueba. Las aplicaciones son las siguientes: 2.1 Desarrollos similares de la ULPGC Existen varios trabajos de fin de carrera de la Escuela de Informática de la ULPGC desarrollados centrados en la creación de una herramienta informática de apoyo a las reuniones científicas, los trabajos son: •Reuniones científicas : organización. Herramienta informática de apoyo a la gestión de reuniones científicas, de Jesús Miguel Quintana Hernández y dirigido por Alexis Quesada Arencibia de septiembre del 2006. •Implementación de un software de apoyo a la gestión de reuniones científicas, de Mario Martín Santana y tutorizado por Alexis Quesada Arencibia de junio del 2008. •Ampliación, validación y despliegue de software de apoyo a la gestión de reuniones científicas de Abel Silván Vega y tutorizado por Alexis Quesada Arencibia de abril del 2010. El primero de los trabajos realiza un estudio en profundidad de las reuniones científicas, realizando un análisis de requisitos, además de la base de datos que posteriores trabajos usarán, también da las directrices de las tecnologías que se usarán posteriormente. El siguiente trabajo normaliza el análisis de los requisitos de usuario y realiza la implementación de muchas de las funciones necesarias en el transcurso de reuniones científicas. El último de los trabajos amplia las funciones de los trabajos anteriores. Las funciones implementadas por los trabajos se pueden resumir en las siguientes: •Gestión de usuarios. 8/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Vista de las funcionalidades de conftool 15/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes 3. Metodología Inicialmente se ha realizado un análisis de las necesidades hardware de la aplicación, buscando necesidades del servidor en el que se implantaría la aplicación como en los cliente que van a acceder a ella. También se ha estudiado necesidades de probar la aplicación en diferentes plataformas de cliente, para tal necesidad, se ha comprobado la necesidad de utilizar máquinas virtuales si queremos comprobar su uso en clientes diferentes clientes Internet Explorer, ya que no es suficiente únicamente disponer de un software de testeado de html de IE porque el motor de IE6 no puede ser instalado conjuntamente con el de versiones superiores de Internet Explorer, eligiendo como software de virtualización de máquinas VirtualBox. Se ha estudiado las herramientas que se ajustan a la metodología de desarrollo de la aplicación, las herramientas de modelado, de versionado, de comunicación con el tutor y demás herramientas necesarias para el desarrollo de la aplicación. Tras realizar las necesidades de la aplicación se estudió los lenguaje y frameworks a utilizar en el desarrollo, lenguajes y frameworks que se ajustaran a las necesidades actuales y a la evolución de las mismas. Teniendo en cuenta que va a realizarse un desarrollo en cliente y en servidor, y eligiendo lenguajes y frameworks para cada uno de ellos. Se ha tenido en cuenta la metodología de desarrollo, intentando utilizar una metodología de desarrollo ágil, realizando entregas en periodos cortos de prototipos de la aplicación, que permitieran dar una visión del estado de la misma, que permitiera realizar modificaciones de las necesidades según se fueran observando, para lo cual ha sido necesario estar en contacto con el tutor lo más posible. Antes de comenzar con la implementación se han realizado utilizado diferentes herramientas de modelado y diseño, como diagramas de casos de uso y storyboards que han dado una visión muy importante de las necesidades de la aplicación. También se realizó un estudios del diseño de la base de datos de la aplicación utilizando el modelo entidad relación, que ayudó a tener una visión de las necesidades de la estructura de datos que iban a ser necesarias, aunque posteriormente se utilizó un modelo de datos orientado a objetos que fue exportado automáticamente por el framework de desarrollo a la base de datos. La implementación de la aplicación en el servidor se ha realizado utilizando python y django, que nos ha permitido realizar el prototipo de forma muy rápida, permitiendo realizar las pruebas con el motor de aplicaciones propio del framework, y utilizando herramientas como la aplicación de migración del modelo de datos a la base de datos a utilizar antes mencionado, la aplicación de administración propia, y demás herramientas muy útiles que dispone, además de proporcionarnos una estructura muy simple y útil de estructurar el código en aplicaciones. La implementación de la aplicación en el cliente se ha realizado utilizando HTML5, CSS3 y JavaScript, con la ayuda de jquery y API's que nos han permitido implementar algunas funcionalidades de forma mucho más sencilla. La memoria del proyecto ha sido realizada con LibreOffice, y la documentación y código fuente, entregado en un disco. 16/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes 4. Plan de trabajo y temporalización En relación al Plan de Trabajo a llevado a cabo, las etapas a cubrir durante el desarrollo del TFG propuesto fueron las siguientes: 1. Elaboración de las Especificaciones de Usuario. El peticionario del proyecto especifica un conjunto de requisitos, agrupados por roles, como pueden ser autor, revisor, director de programa, etc. 2. Partiendo de la Especificación de Usuario el proyectando diseña una base de datos relacional en la cual se implementan la información, las entidades y las relaciones presentes en el ciclo de envío, revisión y aceptación de artículos a congresos internacionales. 3. Diseño de Workflows, Storyboards, y demás diagramas previos a la programación web, para detectar posibles lagunas en la especificación de usuario, errores en la comprensión de la misma, etc. 4. Desarrollo del esqueleto de la aplicación web, haciendo hincapié en la modularidad y la extensibilidad de la aplicación para la futura incorporación de nuevos módulos, como de comprobación de formato de los artículos, de planificación de las comunicaciones en el congreso, etc. 5. Desarrollo y prueba del Módulo de Gestión de Usuarios y Roles 6. Desarrollo y prueba del Módulo requerido por el peticionario para la implementación del ciclo de envío, revisión y aceptación/rechazo de los artículos. 7. Testeo de la aplicación, tratando de buscar posibles debilidades, líneas futuras de desarrollo, etc. La estimación de la temporalización fue la la siguiente: Etapas Dedicación Estimada Etapa 1: Elaboración de las Especificaciones de Usuario 25 horas Etapa 2: Diseño de la Base de Datos a utilizar 40 horas Etapa 3: Diseño de Workflows, Storyboards, y demás diagramas previos a la programación web 75 horas Etapa 4: Desarrollo del esqueleto de la aplicación web 50 horas Etapa 5: Desarrollo del Módulo de Gestión de Usuarios y Roles 50 horas Etapa 6: Desarrollo del módulo de Gestión de las Comunicaciones del congreso 50 horas Etapa 7: Testeo de la aplicación/plataforma 10 horas Dedicación Estimada Total 300 horas 17/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes 5. Organización de la memoria Esta memoria está organizada en once capítulos: 1. Introducción: presenta el proyecto, objetivos, metodología, estado del arte, plan de trabajo, recursos necesarios. 2. Competencias: 3. Aportaciones: 4. Normativa y legislación: 5. Análisis: 6. Requisitos de Hardware y de software: 7. Desarrollo: explicación de las tecnologías usadas, justificación de las mismas, explicación de los requisitos de usuario, diagrama de flujo de los artículos (submissions), explicación de la arquitectura de la aplicación, explicación de los módulos 8. Manual de usuario y software: 9. Conclusiones y líneas futuras: se exponen las conclusiones que se han obtenido tras el desarrollo de la aplicación, y se explican lineas futuras posibles en la ampliación de la aplicación 10. Bibliografía: referencias 11. Glosario: términos usados 18/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Competencias El trabajo de fin de grado debe cubrir y cubre las competencias siguientes: CII01 Capacidad para diseñar, desarrollar, seleccionar y evaluar aplicaciones y sistemas informáticos, asegurando su fiabilidad, seguridad y calidad, conforme a principios éticos y a la legislación y normativa vigentes El trabajo es precisamente el desarrollo de una prototipo de aplicación en el que se ha tenido desarrollar, diseñar además de seleccionar las herramientas de desarrollo necesarias, tanto IDE, como frameworks, lenguajes, plataformas, hardware, conectividad. Teniendo en cuenta su fiabilidad y seguridad, realizando un estudio de comparación entre las diferentes opciones existentes. Además se ha tenido en cuenta la normativa vigente, utilizando herramientas libres y desarrollando sobre un sistema completamente libres. CII02 Capacidad para planificar, concebir, desplegar y dirigir proyectos, servicios y sistemas informáticos en todos los ámbitos, liderando su puesta en marcha y su mejora continua y valorando su impacto económico y social El proyecto ha sido planificado siguiendo metodologías de desarrollado, y comprobando su utilidad y adaptándola a las necesidades que se iban presentando, la finalización demuestra se ha tenido capacidad para concebir y concluir un proyecto. La creación del prototipo de la herramienta implementada tiene produce una ayuda social teniendo en cuenta la carencia de herramientas de este tipo en el mercado. CII04 Capacidad para elaborar el pliego de condiciones técnicas de una instalación informática que cumpla los estándares y normativas vigentes CII18 Conocimiento de la normativa y la regulación informática en los ámbitos nacional, europeo e internacional 19/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Aportaciones Este trabajo de fin de grado, además de aportar el desarrollo del prototipo de la aplicación en sí, que permite explicar las tecnologías utilizadas, comparándolas y explicando las metodologías de desarrollo utilizada, permite dar su punto de vista acerca de la organización y metodología de trabajo de la organización de congresos, ya que explica el flujo de los artículos desde que se crea el artículo inicial, hasta que se envía el final tras ser revisado el artículo inicial por el comité organizador, y valorado, para esa tarea da un ejemplo de interfaz de usuario para los diferentes participantes de este tipo de aplicaciones. Sobre el la comparativa de herramienta existentes, la explicación de la utilizada, la información se encuentra en el capítulo correspondiente, junto con la metodología de trabajo utilizada, además de explicar la arquitectura de la aplicación en sí. 20/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Análisis 1. Descripción del problema Se solicita el prototipo de una aplicación de gestión de conferencias internacionales, una aplicación que sea accesible desde internet, en la que se gestione usuarios y participantes, que puedan acceder y realizar las diferentes funcionalidades que se describen en el análisis de requisitos de usuario. Esta aplicación va a cubrir necesidades de la gestión de un congreso, tal como la gestión de artículos, la tarea más importante de la aplicación, que se describe con detalle en el análisis de flujo, y que comprende el proceso desde la creación del artículo hasta la entrega final del mismo, en la gestión de artículos intervienen diferentes tipos de usuarios del congreso, por lo que vamos a necesitar la gestión de los mismos, describiendo los roles y las tareas de cada uno de ellos, así como las particularidades que tienen. La aplicación va a ser accesible desde internet, por lo que vamos a aprovechar esta característica y desarrollar una interfaz que permita ver información del congreso, y además vamos a dotar a la aplicación de funcionalidades que permitan realizar un portal para el congreso, creando la estructura para la posible ampliación de la aplicación a un gestor de contenidos de congresos. 2. Análisis de requisitos de usuario Para el análisis de requisitos de usuario se ha utilizado la técnica de entrevistas con el cliente, en este caso el tutor, que ha indicado las necesidades de la aplicación, para comprobar la validez de los requisitos obtenidos se ha utilizado herramientas como la realización de storyboards, diagramas de casos de uso y diagrama de flujo A medida que se tenía una idea más clara de los requerimientos se ha ido implementado el prototipo, adaptándolo a las necesidades que se iban encontrando, en esta fase, se realizaban encuentros cortos en los que se mostraban los avances en el desarrollo de la aplicación. 2.1 Descripción de los requisitos de usuario Inicialmente fue dada información sobre el funcionamiento de la organización de las conferencias, indicando acciones que se tienen en cuenta, términos necesarios, tipo de usuarios, datos a incluir de cada tipo de usuario, información sobre los artículos, funcionalidades que podría tener la aplicación, incluyendo posibles ampliaciones, la información es la siguiente: Autor (author): El autor es un usuario del congreso que produce una publicación de algún tipo, la cual desea sea incluida en el Programa Científico de la Conferencia, hay que tener en cuenta que un artículo puede ser realizado por varios autores, de los cuales uno será el autor para correspondencia, que será descrito más adelante. 21/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Artículo (submission): Un artículo es enviado y será aceptado o rechazado, siendo o no incluido en la conferencia, debe incluir el artículo en un formato compatible, produciendo la presentación (communication) o exposición oral, durante el desarrollo de la conferencia. Una artículo tiene un conjunto de datos asociados. •Título •Título corto: versión reducida del título para los listados •Palabras clave •Autor para correspondencia (Corresponding Author): un autor del artículo al que le llega la información de las revisiones y quien debe enviar la información del artículo que va a ser presentado en la conferencia •Autores: conjunto de autores ordenados. Un listado corto podría ser resumido indicando el apellido del primer autor y “et al.” Artículo inicial (Initial Submission): El artículo que inicialmente se envía al sistema implementado para su evaluación por los colaboradores, de este artículo se producirá el informe que el autor leerá indicando las razones de la aceptación o rechazo y las modificaciones necesarias en el artículo final a entregar si fueran necesarias. Informe de revisiones (Reviewers Report): Producido por los Editores Asociados, que compila las calificaciones y comentarios de las opiniones (review templates) de los revisores, además de los comentarios hacia el autor y el director de programa (program chair) y la evaluación del editor asociado. Plantilla de la opinión (review template): Un formulario que permite a los revisores para anotar observaciones del artículo específico para ayudar a los editores asociados para tomar una decisión sobre su aceptación/rechazo de su inclusión dentro de la conferencia. Autor para correspondencia (corresponding author): Cada artículo tiene asociado un autor para correspondencia, el cual es uno de los autores, y que será la misma persona a la que se dirigen las comunicaciones relativas a ese artículo específico. En otras palabras, el autor para correspondencia es la persona de contacto para un artículo (submission) específico, la que enviará el artículo tanto inicial como final y recibirá las notificaciones e informes. Palabra clave (keyword): Una palabra o conjunto de palabras que expresan un tema específico dentro del alcance de la conferencia organizada. Pueden ser utilizados como etiquetas de indexación/categorización en los artículos, revisores, sesiones, talleres, tutoriales, y demás entidades participantes de las que deseemos indexar. Sesión: Cada parte de tiempo ininterrumpida durante el desarrollo de una conferencia, donde está previsto que haya una serie de comunicaciones que se expondrán en el evento. Se espera que los artículos programados en una sesión que se agrupen atendiendo a un conjunto de palabras clave. Los artículos programados en sesión son el resultado filtrado de un proceso de revisión desarrollado antes de la conferencia. Director de Programa (program chair): uno o más voluntarios en el comité organizador de la conferencia a cargo del desarrollo de todo el programa científico de la reunión. Su función principal es la gestión de los artículos. En la tarea de gestión de artículos, tendrá que asignar cada artículo a un editor asociado, para que evalúe el artículo tras comprobar los informes de los revisores que el editor haya seleccionado para cada artículo. La asignación del artículo al editor asociado y posterior evaluación del mismo se realiza para facilitar su tarea de aceptación o rechazo de los mismos. También tiene la función de gestionar los usuarios, la cual realiza indicando el rol que tiene cada 22/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes usuario en el sistema. Editor Asociado: Un voluntario que está de acuerdo en coordinar el proceso de revisión de una serie de artículos, su tarea principal es asignar la revisión de cada artículo que tenga que evaluar a un revisor, y tras comprobar los informes enviar al director del programa su evaluación. Director/Codirector de Sesión (session chair/cochair): Un voluntario que se compromete a llevar a cabo una sesión específica, presentando a los participantes, la promoción de preguntas y debate útil, controlar el tiempo y las condiciones adecuadas para la sesión, etc. Director de inscripciones (registration chair): Uno o más voluntarios en el comité organizador de la conferencia a cargo del registro de participantes, la producción de registro asociada a la documentación, registro, certificados / insignias Categoría de inscripción: El sistema debe manejar un conjunto de diferentes categorías de registro, dependiendo de registro temprano o tarde, la condición a la de registro, los tipos de registro (registro completo, inscripción de artículo adicional, inscripción reducida, pase de comida, pase de comida extra, reducción de cuota de inscripción, tasas de matrícula estudiantil, etc. ) Requisitos de cada rol: Usuario (user): Una persona con derecho a actuar con uno o más de los roles definidos para el sistema, y con la siguiente información introducida en el sistema: •nombre de usuario (username) •contraseña (password) •nombre (name) •apellidos (surname) •dirección de correo electrónico (email addresses) •dirección de trabajo (office address) •afiliación académica (Affiliation/Institution) (es necesario que sea elegible entre las existentes, y si no existiera que se pudiera añadir) •teléfono (telephone) •fax •palabras clave (keywords): se utilizan para identificar el campo de la experiencia y/o interés de un usuario, que es útil para algunas funciones diferentes (autor, revisor, AE) Autor (author): Un subtipo de usuario que produce una publicación de algún tipo, con derecho a ser incluidos en el Programa Científico de la Conferencia. Un autor tiene asociados algunos datos personales: •toda la información asociada a su usuario •relevancia (VIP condition) •número de miembro IEEE (IEEE membership number) •condición de miembre IEEE (IEEE member condition) •condición de miembro IEEE ITSS (IEEE ITSS member condition) Acciones: •Tiene que ser capaz de cargar uno o más artículos. Sólo los autores para correspondencia de cada artículo al que corresponde puede modificarlo, así también los artículos finales y transferencia de derechos de autor •Deberá cargar la información referente al artículo: ◦título (title) 23/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes ◦título corto (short title) ◦resumen (abstract) ◦palabras clave (keywords) (Permitir elegir entre las existentes e introducir nuevas) •Al enviar el artículo debe poder descargarlo para comprobar que es su artículo •Si el artículo es aceptado, entonces tendrá que ser capaz de recibir el informe de revisión •A continuación, tiene que enviar el artículo final en el formato adecuado, y también una transferencia de derechos de autor •El artículo debe pasar un filtro de plagio •Una vez cargado correctamente el artículo, los datos asociados y la forma de transferencia de derecho de autor, el autor tiene que consultar dónde/cuándo se programará su artículo para su presentación. •Un autor puede tener que expresar sus preferencias o necesidades en cuanto al momento en que se programará su artículo. Una de las prioridades de planificación que se utilizará en función de su relevancia (condición VIP) Editor Asociado (AE - associate editor): Un usuario que está de acuerdo en coordinar el proceso de revisión de una serie de artículos. •Inicialmente, tiene que ser asignado por el director de programa de la conferencia (program chair), que le enviará los artículos iniciales •A continuación, tendrá que asignar cada artículo inicial a una serie de revisores, dependiendo de las palabras clave del artículo y la experiencia de los revisores, expresada también como un conjunto de palabras clave. •Puede tener que enviar recordatorios a los colaboradores inicialmente asignados para confirmar que aceptan la tarea de revisión de cada artículo •Puede tener que volver a asignar un artículo a un grupo diferente de revisores si alguno por algún motivos rechazara la revisión del mismo Revisor (reviewer): un usuario que se compromete a revisar una serie de artículos, valorándolos de acuerdo a una plantilla, incluyendo algunas ideas de mejora y una recomendación de decisión ([Aceptado (accepted) | Aceptado con cambios menores (accepted with minor changes)| Aceptado con modificaciones principales (accepted with mayor changes) | Rechazado (rejected)] ). También tendrá que comprobar el artículo asignado para detectar casos de plagio. Director de programa (PC program chair): uno o más usuarios de la conferencia del comité organizador encargado de desarrollar todo el programa científico de la reunión. •Dependiendo del alcance de conferencias, necesitará para definir los perfiles de los artículos para que sean aceptados •Puede asignar los roles editor asociado y revisor a los usuarios. •El proceso de revisión se inicia asignando los editores asociados a los artículos, dependiendo de la relación de las palabras clave de las mismas y el perfil de los editores •Necesitará reasignar artículos dependiendo de diversos motivos •Podría tener que enviar mensajes de aviso instando a los editores que confirmen su aceptación o rechazo de un envío de artículo •Tendrá que recibir los informes de revisión de cada artículo, con el fin de tomar la decisión de aceptación. •Puede tener que enviar recordatorios para instar a los editores que dispongan sus informes de los artículos •Después se toman las decisiones, tendrá que enviar la notificación a todos los autores 24/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes 3. Backbone: Tecnologías utilizadas y justificación. Ventajas y desventajas frente a otras alternativas. Las especificaciones iniciales indican que el desarrollo es el de una aplicación web, por lo que la elección de las tecnologías debe dividirse en el lado del cliente y en el lado del servidor. Al hablar de las tecnologías utilizadas en el lado del cliente nos referimos que el cliente es un navegador web, los requisitos del mismo son que soporte HTML5, CSS3 y JavaScript, aunque muchas de las características de HTML5 y CSS3 de las que carezcan navegadores antiguos podrán ser utilizadas gracias al uso del framework 960gs que permite compatibilidad con navegadores que carezcan de muchas de las características utilizadas. Al hablar de las tecnologías utilizadas en el lado del servidor nos referimos a un servidor que pueda soportar el servidor de aplicaciones de django y el sistema de gestor de bases de datos sqlite3. 3.1 Tecnologías de desarrollo en el lado del cliente Según las necesidades de la aplicación en el lado del cliente podíamos elegir entre desarrollar sobre flash o HTML con CSS y JavaScript, las especificaciones de la aplicación nos permiten elegir entre cualquiera de ellas, ya que HTML-CSS-JavaScript no requieren instalación de ningún tipo de software adicional al navegador. Se ha optado por esa tecnología. Además teniendo en cuenta que los navegadores actuales en su mayoría soportan HTML5, y CSS3, se ha utilizado muchas de sus características, también teniendo en cuenta algunos navegadores más antiguos, el framework 960gs utilizado permite que las característica que no soportan sean suplidas por las que soportan. 3.1.1 Lenguajes Los lenguajes elegidos por tanto han sido HTML5, CSS3 y JavaScript, tal como se ha indicado anteriormente tiene la ventaja de venir por defecto en los clientes sobre los que vamos a desarrollar, a diferencia de otras tecnologías como Flash. HTML5 es un lenguaje de marcas utilizado para el diseño de la interfaz de usuario. CSS3 es un lenguaje para describir la presentación semántica (descrita por HTML) por lo que describe el aspecto y formato. JavaScript es un lenguaje de programación interpretado del que la mayoría de navegadores disponen de intérprete y su utilidad utilizada ha sido la validación de formularios y proporcionar características adicionales como selección múltiple en algunos campos de formularios. 3.1.2 Frameworks 31/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Se ha utilizado el framework 960gs, para la maquetación de la aplicación, es un framework css que divide la pantalla en 12 o 16 columnas que vamos combinando según las necesidades pudiendo montar de una forma sencilla webs con múltiples secciones diferentes en tamaño, zonas para cajas, etc. Estas divisiones se configuran de forma natural, donde simplemente tendremos que ir sumando los tamaños que vamos concatenando para llegar a esas columnas que estamos usando como guía. El uso de un framework para la maquetación como 960gs nos proporciona unas ventajas muy importantes como la compatibilidad, siendo compatible con la mayoría de los navegadores más utilizados como el Mozilla Firefox, Google Chrome, Safari, Internet Explorer y Opera, la estructura para la diagramación de los sitios web que dispone, pues evita el proceso de creación de una nueva estructura cada vez que se inicia un proyecto, un sistema como este ofrece una retícula que mejora el balance, la alineación y el espacio para lograr una mejor experiencia visual, Por lo que el uso implica una mayor velocidad de desarrollo, ya que la compatibilidad con diferentes navegadores y la maquetación en columnas definidas está ya implementada. Para la creación de campos de selección múltiple se ha utilizado la API select2 que permite la selección de múltiples datos, esta API es utiliza JQuery, por lo también que ha sido importada en la 32/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes aplicación. La API select2 permite muchísimas personalizaciones y en su portal tiene un manual muy explicativo [1]. 3.2 Tecnologías de desarrollo en el lado del servidor En el desarrollo de una aplicación web, un factor muy importante es el framework elegido, es la herramienta con la que vamos a desarrollar la aplicación, por lo que su elección es un factor determinante. Hay que tener en cuenta el lenguaje en el que vamos a desarrollar con ese framework, por lo que hay que conocer las características del mismo, y si es un lenguaje script, además conocer las características de su intérprete. Los lenguajes que se ha estudiado su uso han sido: Java, ASP.NET, python, php y ruby. Y de cada lenguaje se ha elegido un framework para comparar, de Java JSF, de ASP.NET ASP.NET MVC, de python Django, de PHP Symphony y de ruby Ruby on Rails, se han elegido estos frameworks de cada lenguaje opinando que son los que más se ajustan a las necesidades propias. Hay que tener en cuenta también el sistema de gestión de base de datos a usar, en este caso, ya que se trata de un prototipo, se ha optado por un sistema de gestión de base de datos ligero, de fácil uso y configuración como es sqlite3, además el tiene soporte en muchas plataformas y por los diferentes frameworks a elegir. 3.2.1 Lenguajes El lenguaje de desarrollo en el servidor elegido es python, lenguaje de programación interpretado cuya filosofía hace hincapié en una sintaxis muy limpia y que favorezca un código legible. Se trata de un lenguaje de programación multiparadigma, ya que soporta orientación a objetos, programación imperativa y, en menor medida, programación funcional. Es un lenguaje interpretado, usa tipado dinámico y es multiplataforma. [1] http://ivaynberg.github.io/select2/ 33/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Además de la legibilidad, orientación a objetos y demás características que son muy importantes en la implementación de la aplicación, debemos tener en cuenta ya que se trata de un lenguaje interpretado del intérprete del que disponemos, y es una gran ventaja, ya que existen intérprete para muchas plataformas, como Windows, OS X, UNIX y GNU/Linux, y se caracteriza por su velocidad y robustez. Una característica tenida en cuenta ha sido la comunidad de desarrolladores de python, una amplia comunidad, muy activa. 3.2.2 Frameworks El framework de desarrollo en el lado del servidor elegido ha sido Django es un framework de desarrollo web de código abierto, escrito en Python, que respeta el paradigma conocido como Model Template View. Fue desarrollado en origen para gestionar varias páginas orientadas a noticias de la World Company de Lawrence, Kansas, y fue liberada al público bajo una licencia BSD en julio de 2005. La meta fundamental de Django es facilitar la creación de sitios web complejos. Django pone énfasis en el re-uso, la conectividad y extensibilidad de componentes, el desarrollo rápido y el principio No te repitas (DRY, del inglés Don't Repeat Yourself). Python es usado en todas las partes del framework, incluso en configuraciones, archivos, y en los modelos de datos. En la elección del framework de desarrollo, se han comparado ASP.NET MVC, JavaServer Faces, Symphony, Ruby on Rails y Django. La comparativa entre los frameworks elegibles para el trabajo, donde se indican algunas 34/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes características relevantes, están descritas en la siguiente tabla. Project Lenguaje Versión estable actual Versión de lanzamiento Licencia Django python 1.5.1 2013-03-28 BSD Symfony php 2.3.1 2013-06-19 MIT JavaServer Faces java 2.1 2010-10-22 CDDL, GPL 2, Apache 2.0, Ruby on Rails ruby 4.0.0 2013-06-25 MIT, Ruby ASP.NET MVC ASP.NET 4.0 2012-08-15 Apache v2 Project Ajax MVC framework MVC push-pull i18n & L10n? ORM Testing framework(s) DB migration framework(s) Django Full stack Push Yes Yes Django ORM Yes Provided by South Symfony Any Yes Push Yes Propel, Doctrine (YAML) Yes Plugin exists JavaServer Faces Yes Yes Pull using Java i18n external, built-in Ruby on Rails Prototy pe, script.a culo.us, jQuery ActiveRecord , Action Pack Push Yes ActiveRe cord Unit Tests, Functional Tests and Integration Tests Yes ASP.NET MVC Yes Yes Push Yes ORM-in depende nt Unit tests, Functional Tests, Integration Tests Entity Framework Project Security framework(s) Template framework(s) Caching framework(s) Form validation framework(s) Django ACL-based Django Template Language Cache Framework Django Forms API Symfony Yes PHP, Twig Yes Yes JavaServe r Faces pluggable pure HTML-SVG page caching normal Java 35/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Project Security framework(s) Template framework(s) Caching framework(s) Form validation framework(s) Ruby on Rails Plug-in Yes Yes Yes ASP.NET MVC ASP.NET Forms Authentication (Default), Pluggable Razor (Default), ASPX, Pluggable Yes Yes (client-side via plugins) Las características más importantes que influido en la elección del framework están descritas a continuación: •Intérprete del lenguaje integrado en la mayoría de los servidores •Robustez y velocidad del intérprete •Framework maduro •Patrón de desarrollo del framework que se ajusta a nuestras necesidades (una descripción del mismo se puede observar en el anexo de esta memoria) •Comunidad de desarrolladores muy amplia y activa •Multitud de aplicaciones útiles que se pueden añadir 36/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Requisitos hardware y software Herramientas software utilizadas en el desarrollo: •VIM (IDE de desarrollo para python y django) •bash (para lanzar scripts) •gedit (editor para HTML, CSS y JavaScript) •firebug (herramienta de depuración de JavaScript y CSS) •Navegadores Chrome, FireFox e Internet Explorer Recursos software de soporte: •Sistema operativo Ubuntu 12.04 •LibreOffice Recursos Hardware: •Portátil con los recursos: 4Gb RAM, procesador i5, 500Gb de HD Frameworks e intérpretes necesarios: •python 2.7.3 •django 1.5 •960gs (framework css) •jquery 1.9 •select2 (api que permite selección múltiple en formularios) 37/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Desarrollo En este capítulo se presenta tanto el análisis de requisito de usuario, presentando el problema a resolver, y las medidas adoptadas para resolverlos, herramientas utilizadas, metodología de desarrollo y una explicación de los módulos desarrollados. El desarrollo de la aplicación se ha realizado teniendo en cuenta metodologías de desarrollo ágil, aunque inicialmente se realizó un análisis exhaustivo de los requisitos de usuario, utilizando para tal tarea herramientas como diagramas de casos de uso, diagramas entidad relación y storyboards, posteriormente se optó por ir desarrollando el prototipo e ir mostrándolo y mejorándolo a medida que el cliente veía su funcionamiento comprobando que sus necesidades se cubrían. La aplicación está modulada en lo que Django denomina aplicaciones, que son … , las aplicaciones que en las que se ha modulado la aplicación son: •conference •submission •user •admin •auth Django estructura el código de la aplicación almacenando cada módulo o aplicación, como lo denomina Django en un directorio, que contiene los scripts 'views.py' (script que contiene los controladores), 'test.py' (script que contiene las pruebas de la aplicación), 'models.py' (script que contiene los modelos). Además mantiene un directorio con el mismo nombre de la aplicación en el que almacena la configuración de la misma, las url ('url.py'), el script de configuración ('settings.py'). La estructura de los archivos de la aplicación es la siguiente: 38/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes La forma con la que Django trabaja con las url es muy sencilla, elegante y potente, en el directorio de configuración de la aplicación tiene un script que tiene un hash que relaciona un patrón, que se utiliza para comparar con la entrada en el servidor de aplicaciones con un método que se ejecuta al recibir esa petición. El script que contienen las rutas url con las que se accede a la aplicación están definidas en el fichero 'url.py' del directorio djcon de la aplicación. A continuación se encuentra una parte del script de las url de nuestra aplicación: 1. Descripción de la configuración de la aplicación La aplicación se ha implementado sobre el intérprete de python 2.7.3, y utilizado django 1.5, además el SGBD usado es SQLite3 se han instalado las aplicaciones de admin, y módulos de seguridad, además de la configuración completa de la aplicación, idioma, zona horaria, ruta de instalación de la aplicación, aplicaciones instaladas, y demás datos necesarios de la configuración que se encuentra en el fichero setting.py del directorio djcon de la aplicación. La aplicación utiliza en su inicialización una carga de datos necesaria, que introduce información sobre los grupos de la aplicación (roles que se tienen el el congreso) e información inicial para el congreso. La carga cargando el fichero 'initial_data.json' realizado mediante mismo comando que también crea la estructura de la base de datos a partir de los modelos de las diferentes aplicaciones, que es 'python manage.py syncdb'. La creación de la estructura de la base de datos, tal como indicamos anteriormente, se realiza con el comando 'python manage.py syncdb', que lee los modelos de las diferentes aplicaciones instaladas, 39/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes y la crea a partir de estos. A continuación una muestra de setting.py Se han instalado diferentes aplicaciones que nos permite utilizar muchas funcionalidades útiles para la aplicación, son: •'django.contrib.auth', •'django.contrib.contenttypes', •'django.contrib.sessions', •'django.contrib.sites', •'django.contrib.messages', •'django.contrib.staticfiles', No sólo se ha instalado la aplicación de admin, sino que se ha configurado las diferentes aplicaciones para que el admin pueda acceder a los modelos y modificar la información sobre ellos, es muy útil ya que la aplicación admin es muy configurable y de una forma muy sencilla. Para que admin acceda a los modelos de las diferentes aplicaciones de la aplicación, se crea el archivo 'admin.py' en cada aplicación, en el que se debe indicar los modelos que van a ser accedidos por el admin y la forma de hacerlo. A continuación se puede observar la página principal de la administración de la aplicación 40/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Manual de usuario y software El código fuente de la aplicación se encuentra en el disco adjunto, el cual está documentado. El manual de usuario de la aplicación se encuentra en el anexo de la memoria. 47/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Conclusiones y líneas futuras La elaboración del trabajo de fin de grado ha ayudado a tener una visión práctica del desarrollo de una aplicación web, pues nos da un punto de vista práctico al realizar la aplicación desde cero, tarea que ha permitido observar todo el ciclo de vida del desarrollo de la aplicación, adquiriendo la experiencia que implica, realizar todas las tareas necesarias en la creación de la aplicación, desde la elección del hardware y software necesario, junto a las tecnologías con las que se va a desarrollar el proyecto, el análisis de requisitos de usuario, la elección de metodología de trabajo y demás pasos necesarios hasta la implementación de la aplicación junto a las pruebas de la misma. El desarrollo de una aplicación que gestione las ponencias de congresos internacionales ha sido una gran idea, ya que en el mercado no existen suficientes aplicaciones que implementen las exigencias de un congreso de forma completa, por lo que al necesitar gestionar multitud de actividades, las gestionan dependiendo de la funcionalidad concreta que requieren, por lo que muchos de los requisitos se encuentran desarrollados de forma independiente, no existiendo aplicaciones que integren la totalidad de las necesidades que un congreso debe gestionar, por lo que esta aplicación de gestión de congresos internacionales puede servir de base de una aplicación mayor que implemente las ampliaciones descritas en las líneas futuras. El desarrollo de la aplicación se ha apoyado en el uso de metodologías ágiles de desarrollo, aunque inicialmente se ha realizado un minucioso análisis de los requisitos de usuario, donde una vez tenido claro cuales eran las necesidades del cliente, y de la aplicación, se han utilizado estas metodologías, realizando entregas a medida que se iban realizando diferentes funcionalidades, y observando si las cuales, implementadas en cada entrega eran las adecuadas y si la dirección que iba tomando el desarrollo del proyecto era el correcto, permitiendo planificar el desarrollo, ajustándolo a lo que se iba comprobando, y realizando adaptaciones siempre que fuera necesario. A medida que se iba desarrollando la aplicación, ampliando el número de entregas, recortando el tiempo entre ellas, se ha visto más útil, ya que al aumentar la comunicación con el cliente, se ha conocido mejor sus necesidades. Las herramientas tanto de software como de hardware elegidas se ajustaron a las necesidades de desarrollo de la aplicación, y están descritas en requisitos de hardware y software, habiendo escogido en todo momento herramientas software que fueran libres, desde el sistema operativo utilizado en el desarrollo de la aplicación, al entorno de desarrollo, hasta el editor de textos utilizado en la elaboración de la memoria. Conocer inicialmente el tipo de aplicación a desarrollar: una aplicación web accedida por navegadores web con la capacidad de html5, css3 y JavaScript. Elegir que la lógica de la aplicación estuviera principalmente en el servidor y el patrón de desarrollo modelo vista controlador permitió dirigir el desarrollo de la aplicación en la dirección tomada, eligiendo django por las razones descritas en el apartado de tecnologías en el lado del servidor descrito en la sección de Análisis. Una vez finalizada la implementación de la aplicación se ha comprobado que la elección del framework django fue muy acertada. Ha permitido conocer una tecnología que actualmente está en auge, su uso además ha implicado conocer de la comunidad de desarrolladores, una filosofía de 48/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes desarrollo muy interesante, aunque inicialmente ha supuesto un coste de tiempo importante encontrar los sitios y foros en los que buscar la información que se iba necesitando, y la forma de solucionar los problemas que iban surgiendo a medida que se iba progresando en la elaboración de la aplicación. El uso del framework de desarrollo django ha ayudado mucho en la modularización de la aplicación, ya que django, ofrece por defecto una normalización en la organización del código, proporcionando una estructura muy sencilla y práctica, y que siguiendo esa estructura estandarizada, que django posee, se ha utilizado facilitando la implementación de la aplicación, al estructurarla según los cánones del framework. Se ha utilizado características de django que permiten mejorar la seguridad de la aplicación, desde el uso de los módulos de autenticación, hasta el módulo que nos permite eliminar la vulnerabilidad de secuencias de comandos en sitios cruzados, el uso de estas características en django se realiza de una forma muy sencilla. El tratamiento de base de datos en el desarrollo de la aplicación ha sido realizado atendiendo principalmente a la manera en la que django trabaja por defecto, utilizando las características de las que dispone, tal como la configuración de la conexión de la aplicación a la base de datos, que se realiza de una forma muy sencilla, la creación de las estructuras relacionales a partir de los modelos creados en cada aplicación, evitándonos la tarea de traducción de los modelos a tablas, la validación de los campos y el uso de los métodos que nos ofrecen los modelos para el acceso a los datos, haciendo innecesario realizar consultas manualmente. Todo esto ha facilitado mucho la labor. Además nos permite en un futuro migrar a cualquier sistema de gestión de base de datos en el que queramos alojar la aplicación en producción de forma muy cómoda. La implementación de la interfaz de la aplicación apoyándose en la tecnología de html5, junto con css3 y JavaScript permite que la aplicación sea fácilmente personalizable para diferentes plataformas, como ordenadores de sobremesa, portátiles, o móviles, que dispongan sistemas operativos varios, además sin realizar ningún tipo de instalación de software adicional del que por defecto dispone. El uso de otras tecnologías como flash nos hubiera requerido la instalación de software adicional, y no nos da ningún tipo de funcionalidad añadida que requiramos en la aplicación desarrollada. El uso de JavaScript ha sido muy útil ampliando características de controles de html, para lo que se ha utilizado una librería que amplia las funcionalidades del control de selección múltiple del que dispone html. El manual de usuario realizado contempla las características de la aplicación e indica la forma en la que cada tipo de usuario trabaja, desde el director de programa, hasta un autor, describiendo las acciones que su rol tiene asignado. En la realización de un proyecto de este estilo para el trabajo de fin de grado del curso de adaptación a grado de ingeniería informática, habría que tener los conocimientos de los lenguajes en los que se va a desarrollar y en el framework que se utilizará, ya que el desarrollo de este proyecto implica una inversión de horas para dominar los lenguajes y frameworks, puesto que sin tenerlos, sería imposible la realización del mismo en el número de horas que el trabajo de fin de grado exige. 49/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes El prototipo de la aplicación está completo, al estar modulada según los estándares de django, y estructurado el código siguiendo los cánones del mismo, resulta muy sencillo añadir módulos y funcionalidades adicionales. Entre las funcionalidades que se podrían implementar ampliando la actual aplicación estarían las siguientes: •Módulo de Mensajería En el que los diferentes usuarios pudieran comunicarse mediante mensajería interna, también podrían enviarse correos electrónicos, e incluso comunicarse de forma síncrona. •Módulo de Cumplimiento de Formato Que comprobara el formato en el que se encuentran los artículos y que indicara si cumple o no en el que se deben enviar los artículos, indicando los posibles errores que existieran si no se cumpliera el formato que el congreso exigiera, pudiendo incluso personalizar las exigencias de formato de cumplimiento que tuviera el congreso concreto para el que se utilizara la aplicación. •Módulo de Planificación Que permitiera organizar el congreso, indicando los posibles conflictos en las exposiciones de los artículos. Habría que indicar el tiempo de cada exposición ya que el tiempo del congreso es limitado, habría que tener en cuenta las localizaciones de las que dispone el congreso, indicando las salas, las necesidades de cada exposición, al aforo al que va destinado, las capacidades de las presentaciones individuales, preferencias de cada autor sobre la sesión en la que se va a celebrar, las prioridades del congreso respecto a las exposiciones dependiendo del artículo, y que el módulo indique posibles planificaciones. •Módulo de Comprobación de Plagio La necesidad de la comprobación del plagio de los artículos presentados a un congreso es habitual, por lo que el desarrollo de un módulo que facilite la gestión de la comprobación de los artículos facilitaría la tarea, siendo de ayuda en muchos congresos. •Módulo de Registro y Facturación En los congresos se realizan tareas de registro y facturación, por lo que la creación de un módulo que amplíe las características de la aplicación sería de gran ayuda. El sistema podría manejar un conjunto de diferentes categorías de registro: condiciones de registro, elementos de registro, registro completo, registro de página adicional, entrada con comida, entrada con servicios extra, cuota reducida de inscripción, matrícula estudiantil, etc., además la facturación del mismo también se podría realizar de forma automatizada, realizando el pago online, mediante tarjeta de crédito o paypal. Ejemplo de tareas que podría realizar este módulo serían: ◦El sistema de registro podría capturar la información de tarjeta de crédito y la información de facturación. ◦El sistema podría generar automáticamente un recibo pdf y enviarlo cuando una persona se registra. •Módulo de Ayuda o tutorial Este módulo podría estar basado en los roles, en donde a cada usuario, dependiendo de su tipo, se le indicara la forma en la que realizar su tarea según su rol, para lo cual se le indicara las funciones propias en el congreso dentro del proceso del mismo, además podría señalarse el flujo de trabajo que debe realizar. •Módulo de Gestor de Contenidos ampliado El congreso necesita un portal donde publicitarse, mostrar la información del mismo tanto a autores, como a interesados en el mismo. Ya que la mayoría de los congresos tienen estas mismas necesidades, sería conveniente que se realizara un gestor de contenidos enfocado a 50/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes congresos, en el que se añadiera la información del mismo y permitiera elegir entre diferentes visualizaciones de un congreso. Sería interesante enlazar la información del congreso con las distintas redes sociales, por lo que también podría tener la posibilidad de relacionar el portal con las redes sociales más usadas en estos momentos, facebook, twitter, google+. •Módulo de Sistema de Log de Acciones de los usuarios Puede ser interesante almacenar las acciones que realizan los diferentes usuarios, de esta manera, podríamos acceder a esa información, o al existir cualquier problema, seríamos capaces de dejar el sistema en el estado que anteriormente se encontraba, permitiendo restaurar dicho sistema. 51/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Anexos 52/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Bibliografía http://www.python.org/doc/ http://www.python.org/ https://www.djangoproject.com/ https://docs.djangoproject.com/en/1.5/ http://960.gs/ http://jquery.com/ http://ivaynberg.github.io/select2/ http://librosweb.es/xhtml/ http://librosweb.es/css/ http://librosweb.es/javascript/ 53/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Glosario Autor (author): Produce una publicación de algún tipo, la cual desea sea incluida en el Programa Científico de la Conferencia. Artículo (submission): Normalmente irá acompañada de un artículo (paper) y es enviado y gestionado por el autor para correspondencia (corresponding author), inicialmente se envía un artículo inicial y una vez aceptado, se enviará el final. produciendo una presentación (communication) o la exposición oral, durante el desarrollo de la conferencia. Artículo inicial (Initial Submission): El artículo que inicialmente se envía al sistema implementado para su evaluación por los colaboradores. Informe de revisiones (Reviewers Report): Producido por los Editores Asociados, que compila las calificaciones y comentarios de las opiniones (review templates), además de los comentarios hacia el director de programa (program chair) y la evaluación del editor asociado. Plantilla de la opinión (review template): Un formulario que permite a los revisores anotar observaciones del artículo específico ayudando a los editores asociados a en la valoración del artículo y sobre su aceptación en la conferencia. Autor para correspondencia (corresponding author): Cada artículo tiene asociado un autor para correspondencia, el cual es uno de los autores, y que será la misma persona a la que se dirigen las comunicaciones relativas a ese artículo específico. En otras palabras, es la persona de contacto del artículo (submission). Palabra clave (keyword): Una palabra o conjunto de palabras que expresan un tema específico dentro del alcance de la conferencia organizada. Pueden ser utilizadas de etiquetas de indexación/categorización del artículo, los revisores, las sesiones, los talleres, los tutoriales, … Sesión: Cada parte de tiempo ininterrumpida durante el desarrollo de una conferencia, donde está previsto que haya una serie de comunicaciones que se expondrán, comentarán, … Se espera que todos los envíos programados dentro de una sesión que se agrupen en un conjunto de palabras clave. Todos los artículos programados en sesión son el resultado filtrado de un proceso de revisión desarrollado antes de la conferencia. Director de Programa (program chair): uno o más usuarios incluidos en el comité organizador de la conferencia a cargo del desarrollo de todo el programa científico de la reunión. Editor Asociado: Un usuario que está de acuerdo en coordinar el proceso de revisión de una serie de artículos. Director/Codirector de Sesión (session chair/cochair): Un usuario que se compromete a llevar a cabo una sesión específica, presentando a los participantes, la promoción de preguntas y debate útil, controlar el tiempo y las condiciones adecuadas para la sesión, etc Director de inscripciones (registration chair): Uno o más usuarios incluidos en el comité organizador de la conferencia, a cargo del registro de participantes, la generación de la documentación, certificados, insignias Categoría de inscripción: El sistema debe manejar un conjunto de diferentes categorías de registro, 54/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes dependiendo de registro temprano o tarde, la condición de registro, los tipos de registro (registro completo, registro de página adicional, el registro en papel, pase de comida, pase de comida extra, reducción de cuota de inscripción, tasas de matrícula estudiantil, etc) Usuario (user): Una persona con derecho a actuar con uno o más de los roles definidos para el sistema. Revisor (reviewer): un usuario que se compromete a revisar una serie de artículos, valorándolos de acuerdo a una plantilla, incluyendo ideas de mejora y una recomendación de decisión ([Aceptada (accepted) | Aceptada con cambios menores (accepted with minor changes)| Aceptada con modificaciones principales (accepted with mayor changes) | Rechazada (rejected)] ). Director de programa (PC program chair): uno o más usuarios de la conferencia del comité organizador encargado de desarrollar todo el programa científico de la reunión. Director de inscripciones (RC - registration chair): uno o más participanted del comité organizador de la conferencia a cargo de la inscripción de los participantes, la producción de documentos de registro/certificados/insignias Director/Codirector de sesión (SC/ScC - session chair/co-chair): un usuario que se compromete a llevar a cabo una sesión específica, introduciendo a los participantes, la promoción de preguntas y debate útil, controlar el tiempo y las condiciones adecuadas para la sesión, etc Administrador (admin): Uno o varios usuarios del comité organizador de la conferencia que tienen una vista completa del Sistema de Información de la Conferencia. Pueden cambiar los parámetros de la configuración de la conferencia. 55/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes El patrón modelo vista controlador El patrón modelo vista controlador ha sido desde el primer momento del desarrollo tenido en cuenta en el desarrollo del proyecto, desde el diseño hasta la implementación de la aplicación, ha sido el patrón utilizado en la arquitectura de la aplicación, la explicación del mismo está descrita a continuación: El Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define componentes para la representación de la información, y por otro lado para la interacción del usuario. Este patrón de diseño se basa en las ideas de reutilización de código y la separación de conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento. Historia El patrón MVC fue una de las primeras ideas en el campo de las interfaces gráficas de usuario y uno de los primeros trabajos en describir e implementar aplicaciones software en términos de sus diferentes funciones. MVC fue introducido por Trygve Reenskaug en Smalltalk-76 durante su visita a Xerox Parc en los años 70 y, seguidamente, en los años 80, Jim Althoff y otros implementaron una versión de MVC para la biblioteca de clases de Smalltalk-80. Sólo más tarde, en 1988, MVC se expresó como un concepto general en un artículo. En esta primera definición de MVC el controlador se definía como "el módulo que se ocupa de la entrada" (de forma similar a como la vista "se ocupa de la salida"). Esta definición no tiene cabida en las aplicaciones modernas en las que esta funcionalidad es asumida por una combinación de la 'vista' y algún framework moderno para desarrollo. El 'controlador', en las aplicaciones modernas de la década de 2000, es un módulo o una sección intermedia de código, que hace de intermediario de la comunicación entre el 'modelo' y la 'vista', y unifica la validación (utilizando llamadas directas o el "observer" para desacoplar el 'modelo' de la 'vista' en el 'modelo' activo). Descripción del patrón Una típica colaboración entre los componentes de un MVC es la siguiente: 56/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes La cuenta de autor Listado de presentaciones Para ver las presentaciones que hemos creado, los borradores de las presentaciones que enviaremos, el estado de las presentaciones enviadas y las presentaciones finales, accedemos con el perfil de autor y en el menú que se encuentra en la barra izquierda, seleccionamos “Submissions” La creación de una submission se realiza seleccionando “new submission” que está en la parte superior de los listados de submissions 63/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes En la introducción de datos, hay que tener en cuenta que una presentación puede tener múltiples autores, los seleccionamos clicando sobre ellos mientras apretamos la tecla de “control”, si deseamos introducir un usuario que no se encuentra en el listado, hay que crear la cuenta de la forma antes indicada, tras introducir los datos de la submission podemos elegir si enviarla o crear un borrador, las opciones están tras los campos de los datos “Draft” y “Send” Si queremos enviar un borrador, en el listado de submission, al que accederemos clicando sobre “Submissions” en el menu de autor que se encuentra a la izquierda, clicamos sobre editar. 64/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Tras seleccionar editar el borrador, en vez de almacenarlo clicando sobre “Draft”, podemos enviarla clicando sobre “Send” Una vez hemos enviado una presentación, esperaremos a conocer la evaluación de la misma, para saberlo, en el listado de presentaciones enviadas, comprobaremos “status”, cuando la pressentación sera corregida, pasará el estado “Reviewing” en revisión a “Accepted”, acepttada o “Rejected”, rechazada 65/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Enviar una presentación final, se realizará cuando el estado de la presentación sea aceptada, comprobaremos que aparecerá la opción “send final” enviar presentación final: --------- Al seleccionar la presentación final, comprobaremos los comentarios que se han realizado sobre la presentación para mejorarla y enviar la presentación final, comprobamos que los datos previamente introducidos de la presentación final están introducidos para facilitar la introducción de datos 66/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes También podrémos comprobar la presentaciones finales que hayamos enviado, y si queremos commprobar la información de las mismas, clicar sobre “show” de la misma La cuenta del program chair El program chair puede comprobar las presentaciones iniciales existentes, su estado, ver los datos, asignar las presentaciones a los editores asociados, aceptar las presentaciones, introducir comentarios de las presentaciones para que el autor de las mismas, listar las presentaciones finales, sus datos. Para ver el listado de presentaciones iniciales y finales accede con el perfil program chair y selecciona “Submissions” del menú de la izquierda 67/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Para asignar la presentación al editor asociado, se debe seleccionar “review” del listado de presentaciones Una vez hemos seleccionado la presentación inicial, elegimos el editor que va a dar su opinión de la presentación ayudado de los revisores 68/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Cuando se haya realizado una valoración de la presentación se aceptará o rechazará, apoyándose de los informes del editor asociado y los revisores, que aparecen tras la información de la presentación, y puede introducir información al autor sobre la presentación inicial, dando información sobre lo que debe mejorar en la presentación final El program chair puede gestionar los roles de los usuarios, para ello, debe seleccionar sobre su menú la opción “Users” 69/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Al seleccionar la opción indicada, aparecerá un listado de los usuarios del listado Seleccionamos editar sobre del usuario que deseemos modificar los datos personales y/o rol y nos aparecerá la siguiente ventana en la cual modificaremos los datos que deseemos 70/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes La cuenta del associate editor El associate editor selecciona los revisores de las presentaciones iniciales a las que ha sido asignado, y posteriormente da una opinión sobre la aceptación o rechazo. Listar las presentaciones que le han asignado: Asignar la presentación a los revisores, e introducir los comentarios lo hará desde la siguiente ventana, hay que tener en cuenta que si el editor asociado, elimina un revisor, la revisión asociada se eliminará 71/75 Trabajo de Fin de Grado – Gabriel Urso Santana Reyes Dar opinión de aceptación o rechazo de la presentación, una vez introduzca la aceptación de la presentación, no podrá volver a modificarla La cuenta del revisor El reviewer revisa las presentaciones que le han asignado Listar las presentaciones que le han asignado 72/75