Web 2.0 para la Gestión de Votaciones de Usuarios - PDF\nWeb 2.0 para la Gestión de Votaciones de Usuarios\nDownload "Web 2.0 para la Gestión de Votaciones de Usuarios"\nMagdalena Santos Blázquez\n1 Trabajo Fin de Grado Escuela de Ingeniería Informática Universidad de Las Palmas de Gran Canaria Web 2.0 para la Gestión de Votaciones de Usuarios Alexandre Alemán Pérez Las Palmas de Gran Canaria 14 Noviembre 2013\n3 Trabajo Fin de Grado realizado en la Escuela de Ingeniería Informática de la Universidad de Las Palmas de Gran Canaria, para la consecución del título de Grado en Ingeniería Informática. Título: Web 2.0 para la Gestión de Votaciones de Usuarios Alumno: Alexandre Alemán Pérez Tutor: Javier Sánchez Pérez Fecha: 14 de Noviembre 2013\n4 El secreto del éxito en la vida de un hombre está en prepararse para aprovechar la ocasión cuando se presente. Benjamin Disraeli ( ) Estadista inglés. A mi familia\n5 Índice General Prefacio...iv 1 Introducción ProAct y sus motivaciones Objetivos Aportaciones Organización del documento Estado actual del arte Historia Plataformas de votación Change.org Activism.com SuryeMonkey Relación entre ProAct y ProActPro Recursos utilizados Recursos software Recursos hardware Planificación del trabajo Metodología de desarrollo Dirigido por casos de uso Centrado en la Arquitectura Iterativo Incremental Fases del Proceso Unificado de Desarrollo Planificación y temporización Presupuesto Coste Personal Costes inventariarles Costes Fungibles Costes Indirectos Presupuesto Total Desarrollo del trabajo Requisitos del sistema i\n6 5.1.1 Modelo del dominio Lista de características Requisitos del software Actores Modelo de casos de uso Especificación de casos de uso más prioritarios Prototipo de interfaz de usuario Modelo de análisis Diagramas de clases Diagramas de colaboración Modelo de diseño Especificación de casos de uso Implementación Por qué Drupal? Módulos necesarios para la implementación Instalación de Drupal Configuración y creación de los elementos del portal Pruebas y arranque del servidor Conclusiones y trabajo futuro Conclusiones Implementación Rest y Trabajo futuro Anexo I: Competencias Anexo II: Legislación vigente Anexo III: Manual de usuario Anexo IV: Detalles de implementación Bibliografía ii\n8 Prefacio El trabajo expuesto en este documento refleja la realización de un proyecto de ingeniería del software que parte con el objetivo de desarrollar un portal web encargado de recibir propuestas de voto realizadas por los usuarios del portal. La pretensión de esta plataforma web es la de conseguir alcanzar un objetivo por cada una de las propuestas realizadas en el portal y a través de los votos de apoyo aportados por los usuarios. Un sistema de votaciones o de seguimientos como éste pretende mediante la unión de fuerzas ejercer una acción social que trascienda a través del apoyo a las causas expuestas y por tanto, efectuar un cambio en aquellos fundamentos sociales que el conjunto de la sociedad considera ya obsoletos. Se ilustrará la metodología de desarrollo empleada que en este caso es la del Proceso Unificado de Desarrollo Software (PUD) y se presentarán los productos generados según indica la misma, utilizando técnicas y herramientas como UML entre otras. Es una metodología Iterativa e Incremental, dirigida por casos de uso, centrada en la arquitectura y enfocada a detectar los posibles riesgos dentro del ciclo de vida del proyecto. La aplicación final hará uso del CMF Drupal encargado de la generación de portales a través de los distintos módulos. La interfaz ha ido generada mediante la modificación de los Themes de Drupal, además de la utilización del Paint como programa de diseño para los logotipos y colores que aportan una escala cromática certera al mismo. En último lugar, se muestran las pruebas generadas para comprobar el uso correcto de la aplicación, además de realizar alguna comparativa con el modelo de organizaciones generado de manera independiente. iv\n9 1 Introducción El voto y la firma electrónica son expresiones que comprenden varios tipos de votación y que abarcan tanto modos electrónicos de emitir votos (votos por internet), como medios electrónicos de contar los votos. Las tecnologías del voto y firma electrónica pueden acelerar el conteo de los votos y proveer una mejor accesibilidad para los votantes con algún tipo de discapacidad, ya que en el caso de la firma electrónica se establece un equivalente electrónico al de la firma manuscrita, donde una persona acepta el contenido de un mensaje electrónico a través de cualquier medio electrónico válido Una vez sabiendo la validez de la firma y el voto electrónico en cualquiera de sus facetas y dentro de un marco previamente establecido, se ha fusionado la necesidad de ejercer una acción social a través de los sistemas con el uso de una plataforma sencilla pero eficaz. En relación a este objetivo, la plataforma se caracteriza por ser una herramienta social, basada en la utilización de las firmas como medio de comunicación, consiguiendo que miles de personas se unan en pro del cambio a través de una causa en lo que solía ser un trabajo arduo que requería mucho tiempo, dinero y complejas infraestructuras 1.1 ProAct y sus motivaciones ProAct o Propuesta Activa como su acrónimo indica, nace de la necesidad existente en la sociedad de expresar sus inquietudes formando propuestas o consultas de orden social, personal o lucrativo en algún modo, con el objetivo de ser apoyadas o seguidas por el mayor número de personas posibles. El proyecto estará basado en un portal web interactivo en el que todo aquel usuario que desee acceder al mismo pueda efectuar su propia propuesta, la cual posee un objetivo a batir. Para poder alcanzar el objetivo será necesaria la firma de los diferentes usuarios, ya sean contactos a los que se les invita a participar o usuarios del portal que quieren aportar su opinión a las propuestas expuestas en el mismo. La aplicación permitirá gestionar tanto las propuestas como las votaciones o firmas de los usuarios, además de ofertar múltiples funcionalidades propias de los portales webs 2,0. Entre éstas funcionalidades, nos encontraremos con la posibilidad de aportar comentarios a las propuestas publicadas en el sistema, compartir con sus conocidos a través de correo electrónico las propuesta que se han decidido publicar en el portal o incluso, realizar una aportación económica a través de una pasarela de pago. 1\n10 1.2 Objetivos Teniendo los diferentes valores que obtiene una implementación de este tipo, se han considerado los siguientes objetivos a alcanzar a lo largo del proyecto. 1. Pasarela de pago relacionado con peticiones. Esta funcionalidad es implementada en el portal mediante un módulo PayPal, en el cual se permiten hacer donaciones a través del uso de cuentas de usuarios del mismo programa y en pro del portal para su mejora progresiva. 2. Funcionalidad 2.0 en relación a comentarios u opiniones de los usuarios Esta funcionalidad aporta la interactividad que poseen todos los portales 2.0 mediante la comunicación a través de comentarios sobre las propuestas publicadas en el sistema. 3. Control y seguimiento de peticiones mediante software de apoyo Para llevar a cabo la funcionalidad de este punto se hará uso del módulo rules, ya que permite la creación de reglas que llevan a cabo un seguimiento de cada propuesta e implementando las mismas, nos envían correos a los distintos usuarios que hayan participado de alguna u otra forma en la propuesta. 4. Interfaz funcional para los usuarios del portal Este objetivo viene proporcionado por Drupal aportando una interfaz bastante atractiva para el usuario, permitiendo añadir temas, modificar el estilo de los mismos y aportando una interfaz ágil y sencilla. 5. Muestra de peticiones a través del portal y de forma compartida El objetivo marcado, pretende la difusión de las propuestas de forma pública a través del portal, además de proporcionar una herramienta que permita a los usuarios de la plataforma decidir las personas con las que se desea compartir la propuesta creada. 6. Control de objetivos y muestra del mismo a través de diferentes listados. Para llevar a cabo esta tarea, se ha hecho uso de los módulos Views y Panels, los cuales nos permiten realizar vistas personalizadas en función de distintos aspectos. A razón de las funcionalidades que aportan estos módulos, se pueden hacer referencias entre distintas propuestas de una manera fácil y cómoda. Implementando finalmente a través del page manager la personalización deseada en la plataforma. 2\n11 1.3 Aportaciones Iniciativas y propuestas libres Las personas deben disfrutar de la libertad de crear iniciativas las cuales puedan cambiar el orden social establecido. Las propuestas están relacionadas con el libre pensamiento y con las convicciones de cada una de las personas que disfruten de la aplicación. La finalidad está encuadrada en un formato de votaciones que permite a todo usuario del portal formar parte de cada una de las iniciativas allí formadas. Propiedad y control de la información En este formato de software el control de la información formara parte de uno de los roles de usuario, ya que se ha considerado primordial la libertad a la hora de crear una propuesta sin necesidad de aportar más datos de los que el creador considere relevante para el misma. El aporte que el rol de censor va a ejercer es el de cumplir con el decoro y la legalidad en cuanto a las propuestas allí expuestas, además de mantener el control de las diferentes aportaciones que una web 2.0 incluye. Flujo libre de información Las personas deben tener libertad de acceso a toda la información que otros pongan a su disposición. Las personas también deben disponer de las herramientas prácticas para que compartir la información y acceder a ella resulte más fácil, rápido y eficaz. Igualdad fundamental Toda persona debe tener acceso a la creación y compartición dentro del servicio ofrecido por ProAct, independientemente de la actividad principal de dicha persona. Debe existir un conjunto único de principios, derechos y responsabilidades que se apliquen a todas las personas que utilicen el servicio de ProAct. Valor social El espíritu de ProAct es el de una plataforma de cambio social activo, permitiendo la formulación de propuestas para que puedan ser valoradas y apoyadas por un conjunto de personas que se sientan identificadas con la misma y así efectuar un cambio desde dentro del mismo conjunto social sin necesidad de imposiciones y con la libertad de que debe disponer todo ser humano. Plataformas y estándares abiertos Las personas deben contar con interfaces programáticas para crear y acceder a la información que se pone a su disposición. Las especificaciones para estas interfaces deben publicarse y ser accesibles para todos. 3\n12 Servicio fundamental Las personas deben ser capaces de utilizar ProAct de forma gratuita en su fase pública, permitiendo que todo usuario que desee formar parte de la plataforma pueda hacerlo sin impedimento alguno. En este sentido no solo se engloba a los usuarios que formulan las propuestas sino aquellos usuarios que acceden para visualizar los resultados de las mismas o que desean ejercer su derecho al voto sobre cada una de las que se sientan identificadas. 1.4 Organización del documento A lo largo del contenido de este documento se describirá todo el proceso necesario para acometer el desarrollo de la aplicación resultante, desde las etapas iniciales de investigación y análisis de requisitos, hasta las etapas finales de diseño e implementación. Para cada una de las etapas se especificarán las tareas involucradas y a continuación se desglosará el contenido correspondiente. El documento está dividido en seis capítulos centrados en el trabajo realizado y un conjunto de apéndices encargados de la información más técnica y específica. - El primer capítulo, está dedicado a dar una introducción al tema de los sistemas de votaciones y las aplicaciones asociadas a los mismos. También se describirá el ámbito en el que se encuentra la realización de este trabajo, así como se indicarán los objetivos que se buscan con la realización del proyecto. - El segundo capítulo y centrado en el estado actual del tema, se hará un recorrido por los diferentes sistemas de firmas y votaciones electrónicas existentes a día de hoy, así como se describirán algunas de las aplicaciones más utilizadas en la acción social mediante firmas. - Posteriormente en el tercer capítulo, se detallarán los recursos empleados para llevar a cabo este proyecto. Se indicarán los recursos hardware y software empleados a lo largo de la vida del mismo. - El capítulo número cuatro y centrado en la planificación del proyecto, englobará el plan de trabajo y el presupuesto necesario para construir la aplicación. Se expondrá y se explicará la metodología de desarrollo empleada en este proyecto, para posteriormente realizar una descomposición temporal de las actividades que componen el proyecto. Por último, se hará una estimación económica del coste de desarrollar la aplicación teniendo en cuenta los diversos factores que hay que aglutinar para obtener el coste total. - El capítulo cinco es el más largo de todos los que componen este documento y descompone todas las etapas del desarrollo del proyecto siguiendo la metodología descrita en el capítulo anterior. Dará comienzo con los requisitos del sistema, se seguirá con las fases de análisis y diseño, y concluirá con la fase de implementación; que estará dedicada a comentar algunos aspectos concretos de la implementación adoptados para dar forma a la aplicación web construida. También se hará hincapié en 4\n13 algunos problemas que surgieron durante esta fase de desarrollo y como se resolvieron. En cada etapa se mostrarán los productos generados de acuerdo a la metodología. - Para finalizar, el último capítulo contendrá las conclusiones obtenidas tras finalizar este proyecto en cuanto al trabajo realizado. Además, se hará un inciso acerca de las posibles líneas de actuación de cara a futuras ampliaciones en versiones posteriores de la aplicación y su integración en la fase de organizaciones. El documento se cierra con los apéndices técnicos y con la bibliografía empleada a lo largo de todo el proyecto, que sirvieron de soporte para efectuar una correcta elaboración del mismo. 5\n15 2 Estado actual del arte En este apartado se tratará la simbiosis existente entre la creación de los dos proyectos que se complementan para formar ProAct, los cuales están compuestos por la creación de una web 2.0 destinada a las votaciones de usuario y un sistema de gestión de votaciones orientado a las organizaciones. A lo largo de esta sección también se hará un breve repaso por las distintas plataformas existentes en el mercado encargadas de las votaciones o recogidas de firmas. 2.1 Historia Los sistemas de votación electrónica para electorados han estado en uso desde la década de los 60, cuando empezaron a usarse las tarjetas perforadas. Los más recientes sistemas de escaneo óptico de votos permiten que un ordenador compute marcas hechas por los votantes en papeletas. En Brasil los votantes usan en todas las elecciones máquinas de votar DRE que recogen y cuentan los votos en una sola máquina, como también sucede en gran escala en la India, Venezuela y los Estados Unidos. También hay sistemas híbridos que incluyen aparatos electrónicos de marcado de papeletas (normalmente sistemas de digitación sobre la pantalla similares a un DRE) u otras tecnologías de asistencia para imprimir una papeleta de papel verificable por el votante y el uso posterior de una máquina distinta para la tabulación electrónica. Asimismo, algunos países han implementado la votación por Internet, que es una modalidad del voto a distancia. El voto por Internet ha cobrado popularidad y ha sido usado para elecciones gubernativas y referéndum en el Reino Unido, Estonia y Suiza, así como también en elecciones municipales en Canadá y elecciones partidarias primarias en los Estados Unidos y Francia. Gracias a la implantación del voto electrónico mediante internet se han creado múltiples programas encargados de realizar el conteo y el pronóstico de voto, hasta un punto que la recogida de firmas ha tenido que ser implantada en este tipo de plataformas para fomentar el mayor apoyo a las causas que requieren la aportación ciudadana. Plataformas como change.org o activism.com son las precursoras en la creación de campañas que permitan realizar cambios en la sociedad, así como fomentar las ayudas necesarias para que las personas puedan vivir mejor o encontrarse en mejores situaciones económicas, sociales o laborales. 7\n16 2.2 Plataformas de votación En esta sección se muestran algunas de las plataformas más usadas dentro del mundo de las votaciones o encuestas electrónicas Change.org Change.org Inc. es una organización o corporación constituida legalmente como persona jurídica y cuyo negocio está vasado en la acogida libre y pública de peticiones por internet de carácter cívico, reformista, social y, en general reivindicativo del cumplimiento de los derechos humanos. Comenzó su prestación de servicios el 7 de febrero de siendo sus promotores el actual CEO Ben Rattray junto a Marcos Dimas. El amplio apoyo a las demandas a través de Change.org ha conseguido que muchas de sus peticiones se hayan logrado. En 2011 se propuso la fusión de la plataforma hispana Actuable en Change.org que se llevó a cabo en 2012 cuando se hizo efectiva la unión voluntaria de los usuarios de Actuable en la plataforma Change.org. 8\n17 2.2.2 Activism.com Activismo.com es una plataforma nacida en 2009 y que opera en el sector de la recogida de firmas online. Esta plataforma está basada en la creación de peticiones de forma gratuita con la posibilidad de promover las peticiones en Facebook y en otras redes sociales. El modelo de desarrollo que propone esta plataforma es el de una empresa que se pone en el mercado como portadora de altos valores molares tales como el pleno cumplimiento de la ley, el respeto de los empleados que le dan vida y una competencia leal con otras estructuras que operan en el mismo ámbito. Fieles a las opciones básicas, Firmas Online se basa, por lo tanto, en los valores de honestidad, transparencia, privacidad, seguridad y competencia leal y están obligados a cumplir con ese Código de Conducta en todos sus actos, ya sean internos o dirigidos al mundo exterior SuryeMonkey SurveyMonkey es una herramienta web para la creación de encuestas online. La aplicación te permite diseñar y enviar encuestas a través del correo electrónico, un enlace en tu web o página de Facebook, etc SurveyMonkey ofrece un plan BASIC gratuito con diversas funcionalidades. Una vez registrado ya se está listo para empezar: 9\n18 Se puede crear una encuesta nueva agregando tú mismo las preguntas o seleccionando una plantilla de encuesta diseñada por un experto. Modifica las opciones de la encuesta Envía la encuesta seleccionando una o varias de las diferentes formas de envío. Por ejemplo, puedes enviarla por correo pero también puedes insertarla en tu página de Facebook. Espera a obtener resultados. Los resultados puedes consultarlos desde la plataforma web y las versiones de pago te permiten también descargarlas a tu ordenador, establecer filtros o tabular datos 2.3 Relación entre ProAct y ProActPro El desarrollo de ProAct y ProActPro ha sido ideado como una plataforma general de votaciones subdividas por el volumen de trabajo que implican. Esta relación existente parte de la necesidad de libertad por parte de los usuarios de un portal a la hora de realizar propuestas y la integración de las organizaciones en el uso de las tecnologías de opinión y desarrollo. La dependencia de la cual parten las organizaciones o partidos políticos para su labor democrática ha sido la base fundamental para la creación de una plataforma que cumpla con los valores sociales a través de su sección pública y de herramienta primordial en cuanto a la comunicación mediante organizaciones a través de la participación de sus integrantes en el ámbito privado. 10\n19 El desarrollo general parte de la misma base en las dos implementaciones aunque sus diferencias son más grandes de lo que pueda parecer ya que la implementación partirá de diferentes visiones de trabajo. En este sentido, podemos subrayar el foco de unión que crea una propuesta o una votación se ve distanciado según los objetivos marcados por cada uno de los proyectos. La objetividad que crea una plataforma cerrada como es la de ProActPro dificulta la utilización del usuario final al contrario que pueda suceder en ProAct. La implementación de ambos sistemas se ha ideado como una única plataforma en la cual se muestran englobados todos los servicios expuestos en ambos PUDs y que son reflejados en cada uno de los proyectos de forma independiente. Por todo ello, podemos hablar de una plataforma ideada para toda aquella persona que desee ejercer una reivindicación de forma libre y con todas las garantías que te ofrece un portal de este tipo. Por tanto, hablamos de un portal encargado de nutrir a las organizaciones de una herramienta imprescindible hoy en día, que pertenece al ámbito de la comunicación en su organigrama a través de los grupos o consultas creados por éstas. 11\n23 Conexión a Internet vía Wi-Fi Hardware Cliente Sistema operativo: Windows XP, Windows Vista o Windows 7 / Apple Mac OS X 10.5 o superior (Intel) CPU: Pentium 4, 2,4 GHz o versiones posteriores o AMD 2400 XP o versiones posteriores Memoria del sistema (RAM): 512 MB Disco duro: 2 GB de espacio libre Velocidad de red: 768 Kbps Tarjeta gráfica: DirectX9 compatible con 3D con 256 MB de RAM de vídeo Pantalla: x en color real de 32 bits Hardware Servidor Procesador: Pentium IV o compatible Memoria RAM: 1 Gb Disco Duro: 2 Gb libres Placa de Red: Ethernet compatible Otros: Tarjeta Gráfica, Monitor recomendable Configuración de la Red Red LAN que soporte TCP/IP (en general, Internet) 15\n25 4 Planificación del trabajo En este capítulo se describirá la metodología aplicada para la realización de este proyecto, se desglosaran las tareas a realizar y se realizará una estimación temporal del desarrollo del mismo. También se realizará una estimación de los costes de mano de obra y material necesarios para el correcto desarrollo de este trabajo. 4.1 Metodología de desarrollo Para la realización del proyecto se ha optado por la metodología PUD (Proceso Unificado de Desarrollo de Software). El proceso de desarrollo de software puede definirse como el conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema software. Sin embargo, el Proceso Unificado de Software está basado en componentes, haciendo que el software resultante esté formado por componentes software interconectados a través de interfaces bien definidas. El Proceso Unificado de Desarrollo utiliza el Lenguaje Unificado de Modelado (UML) para definir y especificar las diversas partes de un sistema. Es un lenguaje con un fuerte bagaje debido a su amplio uso. Además, el proceso pone en práctica el basar gran parte del proyecto de desarrollo en componentes reutilizables, es decir, piezas de software con una interfaz bien definida. Esta metodología está encuadrada dentro de un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura, además de ser iterativo e incremental. La utilización de esta metodología permite realizar software de calidad cumpliendo con los objetivos propuestos. El ciclo de vida del proceso unificado consta de cuatro fases: 1. Inicio 2. Elaboración 3. Construcción 4. Transición 17\n26 Cada fase se subdivide en iteraciones. En cada iteración se desarrolla en secuencia un conjunto de disciplinas o flujos de trabajos. Las más importantes son: Requisitos, Análisis, Diseño, Codificación, y Prueba. Estas disciplinas se realizan para cada una de las cuatro fases. Cada ciclo constituye una versión del sistema Dirigido por casos de uso Un sistema software ve la luz para dar servicio a sus usuarios. Por lo tanto, para construir un sistema con éxito debemos conocer lo que sus futuros usuarios necesitan y desean. Cuando hablamos de un sistema dirigido por casos de uso, debemos tener en cuenta las premisas básicas por las que se rigen los casos de uso: Un caso de uso es un fragmento de funcionalidad del sistema que proporciona un resultado de valor a un usuario. Los casos de uso modelan los requerimientos funcionales del sistema. Todos los casos de uso juntos constituyen el modelo de casos de uso. Los casos de uso también guían el proceso de desarrollo (diseño, implementación, y prueba). Basándose en los casos de uso los desarrolladores crean una serie de modelos de diseño e implementación que llevan a cabo los casos de uso. De este modo los casos de uso no solo inician el proceso de desarrollo sino que le proporcionan un hilo conductor, avanza a través de una serie de flujos de trabajo que parten de los casos de uso. En definitiva, podemos decir que los casos de uso guían la arquitectura del sistema. Por lo cual, tanto la arquitectura del sistema como los casos de uso maduran según avanza el ciclo de desarrollo Centrado en la Arquitectura La arquitectura de un sistema software se describe mediante diferentes vistas del sistema en construcción. Es decir, el concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema. Y como es lógico, la arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando los detalles de lado. La arquitectura surge de las necesidades de la empresa, como las que perciben los usuarios y los inversores, y se refleja en los casos de uso. Sin embargo, también se ve influida por muchos otros factores, como la plataforma en la que tiene que funcionar el software, los bloques de construcción reutilizables de que se dispone, consideraciones de implantación, sistemas heredados, y requisitos no funcionales. Los casos de uso y la arquitectura están profundamente relacionados. Los casos de uso deben encajar en la arquitectura, y a su vez la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, actualmente y a futuro. En un sistema centrado en la arquitectura un desarrolla la forma o arquitectura a partir de la comprensión de un conjunto reducido de casos de uso fundamentales o críticos (usualmente no más del 10 % del total). En forma resumida, podemos decir que el arquitecto: 18\n27 Crea un esquema en borrador de la arquitectura comenzando por la parte no específica de los casos de uso (por ejemplo la plataforma) pero con una comprensión general de los casos de uso fundamentales. A continuación, trabaja con un conjunto de casos de uso, claves o fundamentales. Cada caso de uso es especificado en detalle y realizado en términos de subsistemas, clases, y componentes. A medida que los casos de uso se especifican y maduran, se descubre más de la arquitectura, y esto a su vez lleva a la maduración de más casos de uso. Este proceso continúa hasta que se considere que la arquitectura es estable Iterativo Incremental El desarrollo de un producto software comercial supone un gran esfuerzo que puede durar entre varios meses y hasta posiblemente un año o más. Es práctico dividir el trabajo en partes más pequeñas o mini proyectos. Cada mini proyecto es una iteración que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento del producto. Para una efectividad máxima, las iteraciones deben estar controladas; esto significa, que deben seleccionarse y ejecutarse de una forma planificada. Es por esto por lo que son mini proyectos. Los desarrolladores basan la selección de lo que se implementará en una iteración en dos factores. En primer lugar, la iteración trata de un grupo de casos de uso que juntos amplían la utilidad del producto desarrollado hasta ahora. En segundo lugar, la interacción trata los riesgos más importantes que deben mitigarse. En cada iteración los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseño utilizando la arquitectura seleccionada como guía, para implementar dichos casos de uso. Si la iteración cumple sus objetivos, se continúa con la próxima. Sino deben revisarse las decisiones previas y probar un nuevo enfoque. Un proyecto con éxito se ejecutará de una forma directa, sólo con pequeñas desviaciones del curso que los desarrolladores planificaron inicialmente. Por supuesto, en la medida en que se añadan iteraciones o se altere el orden de las mismas por problemas inesperados, el proceso de desarrollo consumirá más esfuerzo y tiempo. Uno de los objetivos de la reducción del riesgo es minimizar los problemas inesperados. Son muchos los beneficios de un proceso iterativo controlado: La iteración controlada reduce el coste del riesgo a los costes de un solo incremento. Si los desarrolladores tienen que repetir la iteración, la organización sólo pierde el esfuerzo mal empleado de la iteración, no el valor del producto entero. La iteración controlada reduce el riesgo de retrasos en el calendario atacando los riesgos más importantes primero. La iteración controlada acelera el desarrollo. Los trabajadores trabajan de manera más eficiente al obtener resultados a corto plazo. La iteración controlada tiene un enfoque más realista al reconocer que los requisitos no pueden definirse completamente al principio. 19\n28 4.1.4 Fases del Proceso Unificado de Desarrollo El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Al final de cada uno de ellos se obtiene una versión final del producto, que no sólo satisface ciertos casos de uso, sino que está lista para ser entregada y puesta en producción. En caso de que fuese necesario publicar otra versión, deber repetirse los mismos pasos a lo largo de otro ciclo. Las iteraciones de cada fase se desarrollan a través de las actividades de identificación de requisitos, análisis, diseño, implementación, pruebas e integración Fase de Inicio Durante la fase de inicio se desarrolla una descripción del producto final, y se presenta el análisis del negocio. En esta fase se identifican y priorizan los riesgos más importantes. El objetivo de esta fase es ayudar al equipo de proyecto a decidir cuáles son los verdaderos objetivos del proyecto. Las iteraciones exploran diferentes soluciones posibles, y diferentes arquitecturas posibles. Puede que todo el trabajo físico realizado en esta fase sea descartado. Lo único que normalmente sobrevive a la fase de inicio es el incremento del conocimiento en el equipo. La fase de inicio finaliza con el Hito de Objetivos del Ciclo de Vida. Este hito es alcanzado cuando el equipo de proyectos y las partes interesadas llegan a un acuerdo sobre: - Cuál es el conjunto de necesidades del negocio, y que conjunto de funciones satisfacen estas necesidades. - Una planificación preliminar de iteraciones. - Una arquitectura preliminar. 20\n29 Fase de Elaboración Durante la fase de elaboración se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura. Las iteraciones en la fase de elaboración: - Establecen una firme comprensión del problema a solucionar. - Establece la fundación arquitectural para el software. - Establece un plan detallado para las siguientes iteraciones - Elimina los mayores riesgos. El resultado de esta fase es la línea base de la arquitectura. La fase de elaboración finaliza con el hito de la Arquitectura del Ciclo de Vida. Este hito se alcanza cuando el equipo de desarrollo y las partes interesadas llegan a un acuerdo sobre: - Los casos de uso que describen la funcionalidad del sistema. - La línea base de la arquitectura - Los mayores riesgos han sido mitigados - El plan del proyecto Fase de Construcción Durante la fase de construcción se crea el producto. La línea base de la arquitectura crece hasta convertirse en el sistema completo. Al final de esta fase, el producto contiene todos los casos de uso implementados, sin embargo puede que no esté libre de defectos. La fase de construcción finaliza con el hito de Capacidad Operativa Inicial. Este hito se alcanza cuando el equipo de desarrollo y las partes interesadas llegan a un acuerdo sobre: - El producto es estable para ser usado - El producto provee alguna funcionalidad de valor - Todas las partes están listas para comenzar la transición Fase Transición La fase de transición cubre el período durante el cual el producto se convierte en la versión beta. Las iteraciones en esta fase continúan agregando características al software. Sin embargo las características se agregan a un sistema que el usuario se encuentra utilizando activamente. 21\n30 El equipo se encuentra ocupado fundamentalmente en corregir y extender la funcionalidad del sistema desarrollado en la fase anterior. La fase de transición finaliza con el hito de Lanzamiento del Producto. Este hito se alcanza cuando el equipo de desarrollo y las partes interesadas llegan a un acuerdo sobre: - Se han alcanzado los objetivos fijados en la fase de Inicio. - El usuario está satisfecho. 4.2 Planificación y temporización En este apartado se ilustran las diferentes secciones y tareas de las que se compone este proyecto, y que han sido necesarios cumplimentar para llegar a la conclusión del mismo. La planificación y temporización se han hecho en base a las directrices que marca la metodología PUD, por lo tanto se incluyen las cuatro fases de las que se compone: inicio, elaboración, construcción y transición, con sus disciplinas correspondientes. Las siguientes tablas muestran las diferentes tareas y su coste temporal, desglosadas por las distintas secciones que componen el proyecto: Gestión del TFG Gestión TFG Horas Diseño de la Planificación de TFG 3 Realización de la Planificación 2 Mantenimiento y Actualización de la 4 Planificación Presentación Secretaría de la propuesta TFG 1 Solicitar Secretaría Asignación TFG 1 Presentación secretaria documentación final 2 TFG Matriculación TFG 1 Presentación Secretaría solicitud de 1 nombramiento de Tribunal TOTAL 15 Realización y Tramitación de la Propuesta Realización y Tramitación de la Propuesta Horas Búsqueda de un Tema 3 Búsqueda Biblioteca Información Temas TFG 6 Búsqueda en Internet Información sobre 9 Temas TFG Búsqueda de un Tutor 2 Confeccionar un borrador de propuesta TFG 2 Discusión propuesta TFG con Tutor 2 TOTAL 24 22\n31 Cuestiones Previas Cuestiones previas a la realización del Horas trabajo Establecer el entorno de Trabajo 1 Establecer necesidades recursos TFG 2 Instalación del hardware y software 2 necesario TFG Elección del Procesador de texto para el TFG 1 Estudio de la Metodología PUD 5 TOTAL 11 Desarrollo del TFG Desarrollo del TFG Horas INICIO Requerimientos 10 Análisis 7 Diseño 5 Codificación 5 Prueba 5 SUBTOTAL 32 ELABORACIÓN Requerimientos 26 Análisis 20 Diseño 30 Codificación 30 Prueba 5 SUBTOTAL 111 CONSTRUCCIÓN Requerimientos 7 Análisis 15 Diseño 30 Codificación 50 Prueba 20 SUBTOTAL 122 TRANCISIÓN Requerimientos 0 Análisis 2 Diseño 3 Codificación 3 Prueba 5 SUBTOTAL 13 TOTAL\n32 Presentación y Defensa Presentación y Defensa Horas Memoria TFG 50 Supervisión de la memoria el Tutor 10 Realización de copias y encuadernación 1 Preparación de Presentación Oral 5 Defensa Oral TFG 1 TOTAL 67 Resumen de la Planificación Concepto Horas GESTIÓN TFG 15 REALIZACIÓN Y TRAMITACIÓN EL TFG 24 CUESTIONES PREVIAS A LA REALIZACIÓN DEL 11 TFG DESARROLLO DEL TFG 278 PRESENTACIÓN DEL TFG 67 TOTAL Presupuesto El presupuesto necesario para la realización de este proyecto se descompone en cuatro partes. Para cada una por separado se detalla el coste de la misma y al final se expone el coste completo de la realización del proyecto Coste Personal Para calcular los costes laborales lo primero sería determinar el coste por hora trabajada. En este caso se han determinado 16 euros cada hora trabajada por el alumno (suponiendo unos ingresos de 1280 euros brutos mensuales) y 30 euros cada hora trabajada por el profesor (2504 euros brutos mensuales). El reparto de horas dedicadas al proyecto por los distintos participantes quedará de la siguiente manera: Tutor 14 horas Alumno 300 horas 24\n33 Teniendo en cuenta los datos anteriores, tendríamos los siguientes costes laborales por participante: Total Tutor: 14 horas * 30 euros = 420 euros Total Alumno: 300 horas * 16 euros = euros Concepto Cantidad Precio por Unidad Precio Total Coste Laboral Tutor Coste Laboral Alumno Costes inventariarles El material necesario para el proyecto sería de un ordenador portátil. El software necesario para la elaboración del proyecto no supondrá ningún coste debido al uso de software libre y licencias de estudiante. Para el portátil su coste es de El coste total asciende a Teniendo en cuenta que el tiempo de amortización es de 48 meses, y que el equipo se usará durante 4 meses, el coste para ese periodo es de * 4 / 48 = 100 Concepto Cantidad Precio por Unidad Precio Total Ordenador Portátil Costes Fungibles Para la entrega del proyecto es necesario realizar cinco copias del mismo y sus respectivas encuadernaciones. Las cuales habrá que entregar en la administración, por lo tanto el coste es: Precio por tomo: 0.05 euros/pagina * 2 (ambas caras) * 70 páginas + 6 euros (encuadernación) = 13 euros Los 5 tomos: 13 euros * 5 tomos = 65 euros Concepto Cantidad Precio por Unidad Precio Total Tomo de la Memoria Costes Indirectos Son aquellos que no dependen directamente de la realización del proyecto, esto es: trabajo del personal de la administración, gastos en los servicios de alumbrado y de red del 25\n34 edificio de informática etc. Estos costes son difíciles de calcular por su complejidad y variedad, así que para simplificar se ha presupuestado un 5% del total del presupuesto. (Coste de personal + Costes inventariarles + Costes fungibles) * 5%= 6485 * 5% = 324,25 Concepto Total Porcentaje Precio Total CP+CI+CF % 324, Presupuesto Total A continuación se muestra una tabla resumen con los costes asociados al proyecto: CONCEPTO COSTE Costes laborales del alumno 4800 Costes laborales del tutor 420 Costes materiales 1200 Costes de documentación 65 Costes indirectos 324,25 TOTAL PRESUPUESTO 6809,25 El presupuesto total del proyecto es de 6809,25 euros. 26\n35 5 Desarrollo del trabajo En este capítulo se ilustrarán varios de los diferentes artefactos que se han seguido hasta llegar a obtener el producto final, desde la recopilación de requisitos hasta la etapa de diseño del software. La primera parte del desarrollo del proyecto consistirá en identificar los requisitos del sistema y los requisitos del software. Este estudio servirá como base para definir y delimitar el ámbito del proyecto, y para utilizarlo como guía de desarrollo. Las herramientas que se utilizarán serán el modelo del dominio, la lista de características y los casos de uso. La segunda parte de este capítulo permite definir cualquier característica que fuese deseable incluir en la aplicación y la última perfila de forma algo más concreta las funciones que se esperan del mismo. 5.1 Requisitos del sistema En este apartado se describirán dos artefactos muy importantes a la hora de establecer el ámbito en el que se moverá la aplicación: el modelo del dominio y la lista de características. También ayudan a los desarrolladores a comprender el contexto del sistema, además de poder recopilar requisitos funcionales y no funcionales Modelo del dominio Un modelo del dominio captura los tipos más importantes de objetos en el contexto del sistema. Los objetos del dominio representan las cosas" que existen o los eventos que suceden en el entorno en el que trabaja el sistema. Muchos de los objetos del dominio o clases (para emplear una terminología más precisa) pueden obtenerse de una especificación de requisitos o mediante la entrevista con los expertos del dominio. Las clases del dominio aparecen en tres formas típicas: - Objetos del negocio que representan cosas que se manipulan en el negocio, como pedidos, cuentas y contratos. - Objetos del mundo real y conceptos de los que el sistema debe hacer un seguimiento, como la aviación enemiga, misiles y trayectorias. - Sucesos que ocurrirán o han ocurrido, como la llegada de un avión, su salida y la hora de la comida. El modelo del dominio se describe mediante diagramas de UML (especialmente diagramas de clases). Estos diagramas muestran a los clientes, usuarios, revisores y a otros desarrolladores las clases del dominio y cómo se relacionan unas con otras mediante asociaciones. Desarrollo de un modelo del dominio: El modelado del dominio se realiza habitualmente en reuniones organizadas por los analistas del dominio, que utilizan UML y otros lenguajes de modelado para documentar los resultados. Para formar un equipo eficaz, estas reuniones deberán incluir tanto a expertos del dominio como a gente con experiencia en modelado. 27\n36 El objetivo del modelado del dominio es comprender y describir las clases más importantes dentro del contexto del sistema. Los dominios de tamaño moderado normalmente requieren entre 10 y 50 de esas clases. Los dominios más grandes pueden requerir muchas más. Los restantes cientos de clases candidatas que los analistas pueden extraer del dominio se guardan como definiciones en un glosario de términos; de otra manera, el modelo del dominio se hará demasiado grande y requerirá más esfuerzo del necesario para esta parte del proceso. Algunas veces, como en los dominios de negocio muy pequeños, no es necesario desarrollar un modelo de objetos para el dominio; en su lugar, puede ser suficiente un glosario de términos. El glosario y el modelo del dominio ayudan a los usuarios, clientes, desarrolladores, y otros interesados a utilizar un vocabulario común. La terminología común es necesaria para compartir el conocimiento con los otros. Cuando abunda la confusión, el proceso de ingeniería se hace difícil, si no imposible. Para construir un sistema software de cualquier tamaño, los ingenieros de hoy en día deben fundir" el lenguaje de todos los participantes en uno solo consistente. Por último, es necesaria una llamada de atención sobre el modelado del dominio. Puede ser bastante fácil el comenzar modelando las partes internas de un sistema y no su contexto. Por ejemplo, algunos objetos del dominio podrán tener una representación inmediata en el sistema, y algunos analistas del dominio podrán a su vez caer en la trampa de especificar los detalles relativos a esa representación. En casos como estos, es muy importante recordar que el objetivo del modelado del dominio es contribuir a la comprensión del contexto del sistema, y por lo tanto también contribuir a la comprensión de los requisitos del sistema que se desprenden de este contexto. En otras palabras, el modelado del dominio deberá contribuir a una comprensión del problema que se supone que el sistema resuelve en relación a su contexto. El modo interno por el cual el sistema resuelve este problema se tratará en los flujos de trabajo de análisis, diseño, e implementación. Dominio de ProAct ProAct es una plataforma basada en una web 2.0 que permite a los usuarios crear propuestas de voto o procesos de seguimientos sociales de forma que éstas puedan alcanzar el objetivo propuesto cuando se generaron. El usuario que accede al portal podrá visualizar todas las propuestas de voto que se encuentren activas e incluso filtrarlas para poder visualizar las que desee en ese momento. En este orden de cosas se podrán visualizar ya no solo las propuestas activas sino aquellas que han conseguido su objetivo o incluso compartirlas con amigos y demás usuarios que se deseen. El proceso de creación de propuestas estará basado en la creación de una nueva propuesta la cual hay que marcarle un objetivo del orden del número de votaciones recibidas. Los usuarios que deseen generar una propuesta procederán a un registro el cual dará la posibilidad de la creación y el manejo de la misma a través de un usuario autenticado. Todas las propuestas generadas podrán ser modificadas para su mejor visión, comprensión o estética en el portal. La plataforma ejercerá un control sobre el número de votaciones efectuadas por todos los usuarios que acceden al portal. Para poder difundir una propuesta se hará uso de las redes sociales o correos electrónicos que permitan dar a conocer la misma. 28\n37 Los usuarios que desean firmar una propuesta deberán dejar una reseña de sus datos basados en su nombre, apellidos y correo electrónico, además de ejercer el voto mediante el clic de un botón. También hay que ofrecer funcionalidades básicas de una Web 2.0, por lo que se permitirá agregar comentarios a las propuestas que se deseen, proporcionando una mayor interacción entre los usuarios que acceden al portal y sus objetivos dentro del mismo. Los usuarios podrán hacer uso de un servicio de mensajería interna que servirá como hilo de contacto entre los diferentes usuarios en el portal. Diagramas de Dominio Diagrama de Propuesta El siguiente diagrama gestiona la relación entre los diferentes elementos de una propuesta mostrando los elementos contenedores que forman una propuesta en sí. Se podrá observar la relación de uno a muchos entre los elementos que se alimentan de la actividad de los usuarios en contra punto con la victoria que forma parte de la finalización o la información reinante a lo largo de todo el ciclo de vida de la propuesta. Firma Contiene Propuesta 1 * Comentario * 1 1 Contiene 1 Contiene Contiene 0..1 Victoria * Voto Diagrama de relación entre el Usuario y la Propuesta El diagrama a mostrar nos permitirá visualizar las acciones pertenecientes a un usuario en relación a una propuesta previamente seleccionada o su opción de selección a través de la visualización. 29\n38 Firma 1 * Contiene 1 * Propuesta Contiene Victoria Contiene Tiene Visualiza * Contiene 1 1 Tiene Usuario Tiene Voto * * Comentario Diagrama con inclusión del usuario autenticado El siguiente diagrama pretende mostrar la necesidad del usuario identificado en el sistema mediante la inclusión de las clases usuario identificado y perfil. Estas clases serán las encargadas de permitir al usuario la creación de nuevas propuestas y la modificación de las propuestas que ya estén publicadas en el sistema, siendo el usuario el autor de las mismas. Firma 1 * Contiene 1 * Propuesta Contiene Victoria Contiene Tiene Visualiza * Contiene 1 1 Tiene Usuario Tiene Voto * * Comentario Usuario Identificado Tiene Perfil 1 1 Clases del modelo de Dominio: Clase Usuario: esta clase simboliza un usuario anónimo dentro de la plataforma Clase Usuario Identificado: esta clase hereda de la clase usuario anónimo adquiriendo mayores privilegios que ésta. 30\n39 Clase Perfil: esta clase pertenece al usuario identificado y permite que éste ejerza los privilegios adquiridos por su categoría en el sistema. Clase Firma: esta clase representa la firma de un usuario en una propuesta. Clase Propuesta: esta clase es el núcleo del sistema donde irán asociadas múltiples clases referentes en el sistema. Clase Voto: esta clase representa un voto de un usuario asociado a una propuesta. Clase Comentario: esta clase representa un comentario de un usuario asociado a una propuesta Clase Victoria: esta clase refleja el objetivo alcanzar por cada propuesta seleccionada Lista de características La lista de características es un artefacto que se obtiene después de aplicar la tarea de Enumerar los requisitos candidatos", que se propone en la metodología del PUD (Proceso Unificado de Desarrollo), para la captura de requisitos. Por lo tanto se encuentra englobada dentro de la fase de inicio. Esta lista sirve para contener las ideas de clientes, usuarios, analistas y desarrolladores a modo de fichas sobre los posibles aspectos que se podrían incluir en la aplicación, y que, posteriormente, se podrán traducir en requisitos del software. Estas ideas se consideran requisitos candidatos que se podrán desarrollar en la versión actual del sistema o se podrán postergar a versiones futuras. Este artefacto sirve para gestionar el proyecto y sólo se utiliza para la planificación del trabajo. Podrá ir variando a medida que avance el proyecto, pudiéndose añadir y modificar las características que se crean oportunas, en cualquier momento del desarrollo. proceso unificado de desarrollo de software - Jacobson, Booch, Rumbaugh. Leyenda Para describir las características, utilizamos una tabla con los siguientes campos: - Código: Es el identificador de la característica. Se especifica como LC + Categoría + Número. Las categorías se detallan más abajo. - Nombre de la característica. - Descripción: Breve descripción de lo que comprende la característica. - Prioridad: Se asigna una prioridad a cada una con el fin de determinar el orden en que se van a ir desarrollando. Las prioridades que se usarán serán dadas por un valor numérico que representa el nivel de prioridad donde 0 sería la más baja y 100 la más alta, luego están los rangos que se muestran a continuación (Muy alta) (Alta) (Media) (Baja) 0-20 (Muy baja) 31\n40 - Estado: Cada característica tiene un estado asociado que irá variando a medida que progrese el sistema. Los posibles estados son: Aceptado: La característica se desarrollará en esta versión del producto. Planificada: La característica ya ha sido planificada y se empezará a desarrollar en un plazo de tiempo corto. En desarrollo: Ya se está desarrollando. Finalizada: Se ha terminado de desarrollar. Postergada: No se desarrollará hasta una versión futura. Rechazada: Probablemente no se desarrollará en ninguna versión. - Riesgo: Cada característica puede tener asociado un riesgo que representa la dificultad para conseguir implementarla correctamente. Utilizamos tres niveles de riesgo: Crítico Significativo Rutinario Para organizar tenemos los identificadores para cada tipo de usuario de la aplicación A. Usuario Anónimo en ProAct I. Usuarios Identificados en ProAct M. Usuario Moderador de ProAct AD. Usuario Administrador de ProAct Con los identificadores anteriormente propuestos podemos ayudar a colocarle un código a cada característica con respecto al usuario que realiza la funcionalidad. Código Nombre Descripción Prioridad Estado Coste Riesgo LC-A.1 Buscar La aplicación permitirá a 99 Aceptada Propuesta cualquier usuario introducir el nombre de una propuesta y mostrará los resultados de la búsqueda LC-A.2 Visualizar La aplicación permitirá 98 Aceptada Propuesta una propuesta previamente localizada. LC-A.3 Visualizar El usuario puede acceder 64 Aceptada propuestas a un listado de las ganadas distintas propuestas las cuales han logrado su objetivo. LC-A.4 Visualizar El usuario podrá listar las 66 Aceptada propuestas recientes propuestas más recientes introducidas en el portal. LC-A.5 Visualizar El usuario podrá visualizar 70 Postergada propuestas en un listado las populares propuestas más firmadas del portal. LC-A.6 Visualizar El usuario podrá acceder a 76 Postergada 32\n41 LC-A.7 LC-A.8 LC-A.9 LC-A.10 propuestas organizadas por causas Compartir Propuesta Firmar propuesta Integrar donativo mediante PayPal Realizar Comentario una lista de peticiones organizadas por la causa objetivo El usuario podrá compartir una propuesta mediante correo electrónico o Redes sociales. El usuario puede rellenando sus datos firmar una propuesta determinada, apoyando la misma. El usuario podrá aportar un donativo a la propuesta mediante una pasarela de pago El usuario podrá comentar una petición determinada. 94 Aceptada 97 Aceptada 58 Aceptada 17 Aceptada LC-A.11 Denunciar propuesta El usuario podrá denunciar el contenido de una propuesta 40 Postergada LC-A.12 LC-A.13 LC-A.14 LC-I.1 LC-I.2 LC-I.3 LC-I.4 LC-I.5 LC-I.6 LC-I.7 Navegar en el portal Cambiar idioma Crear Cuenta Iniciar cesión Cerrar cesión Crear propuesta Editar propuesta Borrar Propuesta Enviar Mensajes Imprimir listado de El usuario podrá navegar por las funcionalidades del portal El usuario podrá cambiar el idioma del portal web El usuario debe registrarse en el sistema El usuario debe autenticarse para crear una propuesta El usuario podrá cerrar cesión El usuario efectuar una propuesta para su publicación El usuario podrá editar el formato de la propuesta El usuario que efectúa la propuesta podrá eliminarla. El usuario podrá enviar mensajes a cualquier creador de una petición en el portal El usuario podrá imprimir el listado de votos 38 Aceptada 35 Postergada 99 Aceptada 98 Aceptada 83 Aceptada 100 Aceptada 75 Aceptada 77 Aceptada 69 Postergada 10 Postergada 33\n42 LC-M.2 LC-M.3 LC-M.4 LC-M.5 LC- AD.1 LC- AD.2 LC- AD.3 firmantes firmantes en una propuesta Bloquear El moderador podrá Comentario bloquear cualquier comentario que tenga que ser revisado Eliminar El moderador podrá Comentario eliminar cualquier comentario que no cumpla con las reglas del portal Crear El moderador podrá crear Causas causas a las cuales se Borrar Causas Actualizar portal Bloquear el portal Dar permisos a los roles de usuario asocian las propuestas El moderador podrá borra causas creadas por error o redefinirlas El administrador podrá actualizar las diferentes funcionalidades del portal El administrador podrá bloquear el portal a fin de hacer modificaciones en el mismo El administrador podrá asignar los permisos de usuario a los roles creados 23 Aceptada 24 Aceptada 15 Postergada 14 Postergada 49 Aceptada 73 Aceptada 67 Aceptada 5.2 Requisitos del software La especificación de requisitos del software es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software, deducidos a partir de la información obtenida con el modelo de dominio y la lista de características. Los casos de uso también son conocidos como requisitos funcionales. Para cada usuario se crean Casos de uso", los cuales detallan y describen las operaciones que podrá realizar cada uno, en un lenguaje de alto nivel, en términos más coloquiales que técnicos. A partir de los casos de uso se refinan las operaciones, definiendo los pasos concretos que incluye cada una. Estos pasos se describen mediante las Tablas de flujo de sucesos". En general se realiza una tabla por cada caso de uso que exista. Además de los casos de uso, también contiene requisitos no funcionales, que son aquellos que realiza el sistema sin la interacción con un usuario de forma directa y que son necesarios para poder llevar a cabo acciones solicitadas por los mismos. Todo este trabajo servirá como base para desarrollar la etapa de análisis, la cual se explicará más adelante. 34\n43 5.2.1 Actores La clasificación de los actores es una primera aproximación para identificar y asociar con cada uno de los posibles usuarios; estos tipos de usuarios identificados no necesariamente tienen que ser los usuarios definitivos. Actores Generales de la aplicación (ProAct). - Anónimo: Este usuario podrá efectuar las labores de búsqueda y visualización de las distintas propuestas expuestas en el sistema de forma pública, además de votar, comentar y compartir aquellas propuestas de las que desee formar parte. Este usuario contabiliza entre sus derechos, la posibilidad de realizar un registro de usuario para poder formar parte del sistema y realizar propuestas pasando a ser un usuario identificado. - Identificado: Este usuario puede acceder al portal aportando su firma a las distintas peticiones o propuestas expuestas en el mismo, pudiendo incluir una aportación económica. El usuario identificado podrá compartir mediante las redes sociales o correos electrónicos las peticiones en las que haya aportado su firma. Este rol de usuario también podrá crear sus propias propuestas realizando el inicio de sesión necesario para poder efectuar el proceso de creación. Además, podrá modificar la las propuestas a través de un perfil creado para el manejo de las mismas. Dicho usuario tendrá disponible la mensajería interna con otros usuarios del portal. - Moderador: Este rol es aquel que posee todas las características del usuario anónimo, pero así mismo, se encarga de moderar el contenido de las distintas peticiones realizadas por los usuarios del portal haciendo que se cumpla la legalidad y el decoro correspondiente. Pudiendo eliminar aquellas que no fuesen oportunas y vanear a usuarios que ejerzan un mal uso de la plataforma. -Administrador: Este usuario posee un control total del portal teniendo acceso no solo a la plataforma como usuario sino a nivel de desarrollador. Dicho usuario puede modificar código de la plataforma y solucionar los errores que vayan surgiendo en el sistema, además de efectuar un mantenimiento continuo del sistema. 35\n44 5.2.2 Modelo de casos de uso Identificación de los Casos de uso Casos de Usos Buscar Propuesta 99 Visualizar propuesta 98 Visualizar propuestas ganadas 64 Visualizar propuestas recientes 66 Visualizar propuestas populares 70 Visualizar propuestas organizadas por causas 76 Crear Propuesta 100 Editar Propuesta 75 Compartir Propuesta 94 Firmar Propuesta 97 Declarar victoriosa una propuesta 95 Integrar donativo mediante PayPal 58 Realizar Comentario 17 Enviar Mensajes 69 Borrar Propuesta 77 Imprimir listado de firmantes 10 Denunciar Propuestas 40 Navegar en el portal 38 Cambiar Idioma 35 Bloquear Propuesta 43 Bloquear Comentario 23 Eliminar Comentario 24 Crear Causas 15 Borrar Causas 14 Actualizar Portal 49 Bloquear Portal 73 Dar permisos a roles de usuario 67 Crear Cuenta 99 Iniciar Cesión 98 Cerrar Cesión 83 Prioridad Diagramas de Casos de Uso Debido a las considerables dimensiones de los diagramas de casos de uso, se ha decidido separar en múltiples diagramas para poder tener una mejor comprensión y visualización de los mismos. Herencia entre los Actores Principales En este primer diagrama podemos observar como existe una herencia simple entre el usuario anónimo y el usuario identificado. Esta herencia parte de la necesidad de registro y 36\n45 posterior autenticación que tiene el usuario identificado a partir del usuario anónimo, ya que las funciones ejercidas por un usuario identificado solo pueden ser desarrolladas por éste dentro de su propio marco. Teniendo en cuenta que también forman parte de sus casos de uso las acciones relativas a los usuarios anónimos,se considera necesaria la herencia entre ambos para una mejor comprensión y uso del sistema. Usuario Anonimo Usuario Identificado Casos de uso del usuario anónimo Caso de uso Crear Cuenta de Usuario Se ha diferenciado el diagrama siguiente de los demás diagramas ya que es el caso de uso que crea el vínculo de herencia entre el usuario anónimo y el usuario identificado. Este vínculo nace de la necesidad que tiene un usuario identificado de tener su propia cuenta para ejercer sus funciones, actividad que por tanto está dirigida en un porcentaje alto al usuario anónimo. Usuario Anonimo Crear Cuenta de Usuario Casos de uso de visualización En este diagrama podremos observar los diferentes casos de uso relacionados con la visualización de las propuestas en el sistema. Hay que decir, que las visualizaciones parten de las múltiples vistas diseñadas o postergadas en el portal web y que proporcionan un fácil manejo y acceso a las propuestas por visualizar. 37\n46 System Visualizar Propuesta Visualizar Propuestas Victoriosas Visualizar Propuestas Recientes Usuario Anonimo Visualizar Propuestas Populares Visualizar Propuestas Clasificadas por Causas Casos de uso de Manejo de Propuestas El siguiente diagrama se encarga de mostrar todos aquellos casos de uso que tienen una relación directa con una propuesta previamente seleccionada. La única excepción a este respecto, es el caso de uso buscar propuesta que aun no teniendo una relación directa con las propuestas, es el caso de uso encargado de su búsqueda y por tanto debe recibir una categoría igual o superior a los casos de uso seleccionados en dicho diagrama. Buscar Propuesta System Compartir Propuesta Firmar Propuesta Usuario Anonimo Denunciar Propuesta Comentar Propuesta 38\n47 Casos de uso de navegabilidad El diagrama siguiente nos permite observar los casos de uso referentes a la navegabilidad e idioma en el sistema. Como se puede observar se ha tomado la decisión de encuadrar el caso de uso de donaciones en esta sección por la dificultad existente a la hora de indicar si las donaciones pertenecen a las propuestas o al sistema en sí. System Cambiar Idioma Navegavilidad del Portal Usuario Anonimo Realizar un donativo Mediante PayPal Vista general En este diagrama podemos ver de forma aislada practicamente todos los casos de uso asociados al rol de usuario anónimo. Las funcionalidades que realiza un usuario anónimo parten de la existencia de propuestas en el sistema de forma pública. La finalidad del usuario anónimo es la de intercatuar con las propuestas que los usuarios identificados y pertenecientes al sistema generen en el mismo. La puntualización de propuestas públicas esta relacionada con la asociacion directa con ProActPro ya que esta sección del sistema, posee distintos roles de usuarios a los especificados en esta parte del proyecto. 39\n48 Visualizar Propuesta System Buscar Propuesta Compartir Propuesta Firmar Propuesta Usuario Anónimo Comentar Propuesta Visualizar Propuestas Victoriosas Visualizar Propuestas Recientes Visualizar Propuestas Populares Visualizar Propuestas clasificadas por Causas Navegavilidad del portal Cambiar Idioma Denunciar Propuesta Realizar Un Donativo Mediante PayPal Casos de uso del usuario identificado Este diagrama es el encargado de mostrar los casos de uso que están asociados a los actores que se encuentran identificados y por tanto autenticados en el sistema. Como se puede observar en este diagrama, se han incluido los casos de uso de inicio y cerrar sesión que vienen explicados posteriormente en un apartado siguiente. Esta inclusión parte de la necesidad de mostrar en un diagrama el conjunto de casos de uso que formar parte del actor identificado. 40\n49 System Iniciar Sesión Cerrar sesión Editar Propuesta Usuario Identificado Declarar una Propuesta Victoriosa Crear Propuesta Imprimir listado de firmantes Enviar Mensajes Casos de uso interrelacionados entre el moderador y el usuario identificado Este diagrama nos muestra los casos de uso relacionados con el usuario identificado, a excepción de los relacionados con el proceso de inicio de sesión, ya que estos casos están relacionados con el proceso de identificación y crear una relación directa con el usuario anónimo. Borrar Propuesta System Enviar Mensajes Editar Propuesta Moderador Usuario Identificado Declarar Una Propuesta Victoriosa Bloquear Propuesta Crear Propuesta <<extend>> Imprimir listado de firmantes 41\n50 Como bien podemos observar, los casos de uso mostrados en este diagrama poseen dependencia con el inicio de sesión de un usuario. La razón de esta dependencia parte del caso de uso de manejo de perfil de propuestas y de la comunicación con los usuarios del sistema. También, se puede observar como el moderador comparte un caso de uso con el usuario, ya que puede eliminar cualquier propuesta del sistema. Casos de uso del proceso de identificación En este diagrama se puede observar como el proceso de registro y de inicio de sesión poseen una relación directa con los roles de usuario anónimo y usuario identificado. Esta relacion viene dada por la necesidad existente de crear una propuesta previo registro de un usuario en el sistema y logeado dentro del mismo. También podemos observar como los casos de uso iniciar sesión y registro dependen el uno del otro, ya que son casos necesarios para hacer uso del sistema de forma correcta. System Iniciar sesión Usuario Anónimo Registro de Usuario <<extend>> <<extend>> Usuario Identificado Cerrar sesión Casos de uso relacionados con el moderador de forma aislada En este caso, llamamos a los casos de uso relacionados con el moderado de forma aislada ya que será el único actor en poder ejecutar estas acciones y por tanto es necesaria la creación de un diagrama aislado para el mismo. Crear Causa Moderador Borrar Causa 42\n51 El moderador podrá crear o eliminar causas que servirán para englobar las múltiples propuestas en función de su objetivo social, político, religioso, etc. Casos de uso relacionados con el administrador Actualizar Portal Administrador Bloquear Portal Dar Permisos a los roles de usuario El administrador será el usuario encargado de la actualización y bloqueo en determinados momentos del portal, además de ser el encargado de asignar los roles correspondientes a los usuarios que accedan al sistema y que en un momento determinado y siendo participe del reglamento del portal, puedan ejercer el papel filtrante dentro del mismo Especificación de casos de uso más prioritarios Crear Propuesta Caso de Uso Actor Precondición Post condición Flujo normal Crear Propuesta Usuario Identificado El usuario debe de encontrarse identificado en el sistema La propuesta queda publicada en el sistema 1- La aplicación mostrará un formulario en el cual el usuario podrá incluir la propuesta que desea efectuar en conjunto con su correo electrónico como nombre de usuario y el objetivo alcanzar. 2- El sistema valida la información del formulario y la pública en el portal. Flujo alternativo 1.1 -El usuario no inserta toda la información necesaria para crear una propuesta. 43\n52 1.2 El sistema impide la creación de la propuesta mandando un mensaje para que se rellenen todos los datos. Buscar una Propuesta Caso de Uso Actor Precondición Post condición Flujo normal Buscar una Propuesta Usuario Anónimo El sistema mostrará un listado de propuestas según los parámetros de búsqueda introducidos 1- El usuario introduce los parámetros que desea encontrar en el buscador. 2- El sistema realiza la búsqueda dentro del portal 3- Se muestra un listado o una propuesta relacionada con los parámetros introducidos. Flujo alternativo 1.1- El usuario no introduce ningún parámetro de búsqueda El sistema muestra todas las propuestas ancladas en el portal. Visualizar Propuesta Caso de Uso Actor Precondición Post condición Flujo normal Visualizar Propuesta Usuario anónimo El sistema este mostrando los títulos de las propuestas existentes en el sistema El sistema muestra la propuesta con las vicisitudes de la misma. 1- El usuario selecciona la propuesta que desea visualizar. 2- El sistema muestra la propuesta Flujo alternativo Firmar Propuesta Caso de Uso Actor Precondición Firmar Propuesta Usuario anónimo La propuesta debe estar visualizándose previa selección 44\n53 Post condición Flujo normal La propuesta queda firmada por el usuario 1- El sistema muestra un formulario con los campos requeridos para realizar la firma 2- El usuario rellena los campos del formulario y presiona el botón de firmar. 3- El sistema valida la firma y la registra con éxito en la propuesta. Flujo alternativo 2.1- El usuario no rellena todos los campos necesarios para realizar la firma El sistema impide su avance y avisa de la falta de cumplimentación de los campos El usuario realiza una aportación económica a la firma rellenando los campos requeridos El usuario recibe la confirmación del ingreso de la aportación económica. Declarar victoriosa una propuesta Caso de Uso Declarar victoriosa una propuesta Actor Usuario Identificado Precondición El usuario debe encontrarse en la edición de la propuesta Post La propuesta queda declarada como victoriosa mostrándose como tal condición Flujo normal 1 - El usuario selecciona el botón de victoria de propuestas dentro de la edición de la misma 2 - El sistema comprueba si el objetivo marcado en la creación se ha cumplido. 3 - El sistema declara victoriosa la propuesta. Flujo alternativo 2.1- El sistema indica que no se ha cumplido el objetivo a batir 2.2- El sistema vuelve a la edición de la propuesta sin realizar cambios. Compartir Propuesta Caso de Uso Compartir Propuesta Actor Usuario anónimo Precondición El usuario debe encontrarse en la edición de la propuesta Post condición Flujo normal Se envían correos y mensajes a todos las personas indicadas 1- El usuario rellena el formulario con los correos electrónicos con quienes desea compartir la propuesta 2- Los correos son enviados correctamente. 45\n54 Flujo alternativo 1.1- El usuario rellena mal los correos de los usuarios a compartir El sistema muestra un mensaje de error El sistema vuelve al formulario de envío de correos. Crear Cuenta Caso de Uso Actor Precondición Post condición Flujo normal Crear Cuenta Usuario Anónimo El Usuario queda registrado en el sistema 1- La aplicación mostrará un formulario en el cual el usuario aportará sus datos personales para crear su cuenta en la aplicación 2- El sistema valida los datos y crea la cuenta del usuario en el portal Flujo alternativo 1.3 -El usuario no inserta toda la información necesaria para crear una elección. 1.4 El sistema impide la creación de la Elección mandando un mensaje para que se rellenen todos los datos. Iniciar Sesión Caso de Uso Actor Precondición Post condición Flujo normal Iniciar Sesión Usuario Identificado El usuario debe tener cuenta en el sistema El usuario queda logueado dentro del sistema 1- El usuario introduce su nombre de usuario y contraseña 2- El sistema comprueba los datos introducidos en el sistema 3- El usuario accede al sistema tras su logueado Flujo alternativo 1.3- El usuario no introduce correctamente el nombre de usuario o la contraseña 1.4- El sistema muestra un mensaje indicando la introducción errónea de datos 1.5- El sistema permanece en la introducción de nombre de usuario y contraseña 46\n55 5.2.4 Prototipo de interfaz de usuario En esta sección se describirá la futura interfaz de usuario de la aplicación a nivel físico y los elementos que la componen. Esta parte del desarrollo del software es de vital importancia pues es la responsable de la manera en que el usuario interactúa con la aplicación, ya sea durante la entrada o salida de datos, la forma de operar con los mismos, la generación de flujos de trabajo u otros Interfaz Página Principal En esta imagen se muestra la interfaz relacionada con la página principal, dentro de la cual podemos observar como muestra una estética acorde a un portal de diseño ágil y sencillo pero con un control de cromática avanzado y una correcta visualización de las propuestas realizadas. En esta captura de pantalla podemos ver la simbiosis existente entre las últimas propuestas realizadas y las victorias conseguidas por los usuarios, además de observar la imagen que aporta un alto nivel de información sobre las propuestas realizadas en el portal. En esta página de inicio también podemos observar el menú de usuario disponible en la misma y que cambiara según el rol del usuario que accede al portal, además de la actividad reciente en el sistema que muestra el volumen de publicaciones en el portal Interfaz Creación de Propuestas En esta imagen se muestra la interfaz encargada de la creación de nuevas propuestas por parte de los usuarios que accedan al portal. 47\n56 Esta segunda imagen sobre creación de propuestas, muestra como es la creación de una nueva propuesta partiendo de la cumplimentación del formulario siguiente, el cual está compuesto por el nombre de la misma y un conjunto de campos que permiten formar una propuesta adecuada. En esta imagen podemos observar como dentro del proceso de creación de propuestas se debe indicar el tiempo de expiración de la misma y si se ha conseguido la propuesta mediante la modificación del campo de victorias. Como se puede observar, existe una vinculación con la interfaz de ProActPro sin crear una dependencia entre ellas y por tanto permitiendo efectuar la labor encomendada sin que exista la necesidad de realizar funciones no especificadas en ProAct. 48\n57 Interfaz encargada del voto y de efectuar comentarios Esta imagen nos muestra la interfaz encargada de efectuar una votación perteneciente a una propuesta publicada en el portal, además de realizar comentarios relacionados con la propuesta creando un proceso de interactividad entre los usuarios del portal. También se ha considerado la necesidad de aportar la firma de los usuarios a la propuesta seleccionada, dándoles a los autores la posibilidad de efectuar listados de apoyo que sirvan de futuro soporte legal a las mismas Interfaz encargada de visualizar una propuesta 49\n58 En esta ocasión se muestra la interfaz que permite la visualización de una propuesta publicada en el sistema de forma que se puede ver una imagen relacionada con la propuesta, además del título con un texto explicativo del mismo Interfaz encargada de la visualización de victorias La impresión de pantalla anterior muestra la interfaz relacionada con las victorias declaradas en el sistema y que se muestran de forma vertical en conjunto con la actividad reciente en el sistema Interfaz encargada del perfil de una propuesta 50\n59 En esta ocasión, se puede visualizar la interfaz encargada de la creación de una cuenta de usuario en el sistema teniendo en cuenta que será requisito indispensable para efectuar aportaciones en cuanto a propuestas en el sistema. 5.3 Modelo de análisis El análisis se desarrollará sobre las tablas de flujo de sucesos descritas durante los requisitos. Primero se realizarán los diagramas de clase para identificar los elementos estructurales que intervienen en el caso de uso especificado. Posteriormente se obtendrá el diagrama de colaboración, en el que quedará reflejado cómo interactúan estas entidades, tanto en la forma de comunicarse (mensajes que se envían), como en la temporización de la interacción (orden en el que se realiza cada paso de la comunicación) Diagramas de clases A la hora de modelar las clases de análisis se utilizan dos tipos de diagramas: estáticos o de colaboración. Para elaborar estos diagramas se utilizan tres tipos de clases: - Interfaces: son clases que actúan de intermediarias en la comunicación entre usuario y sistema, o entre sistemas. - Control: son las clases que realizan la lógica del modelo de negocio. Sirven para coordinar y comunicar clases (interfaces, datos y otras clases de control). - Datos: representan un objeto de datos estático, normalmente una entidad del modelo de negocio. Generalmente son manipuladas por clases de control Diagramas de colaboración El objetivo de este apartado es identificar las clases cuyos objetos son necesarios para realizar un caso de uso y describir su comportamiento mediante la interacción dichos objetos. 51\n60 Modelo para el caso de uso: Crear Propuesta. Una clase de análisis y sus objetos normalmente participan en varias realizaciones de casos de uso, lo cual se representa de la siguiente manera en el caso de uso Crear Propuesta. Crear Propuesta Crear Propuesta <<trace>> Para el caso Crear usuario podemos observar como se ha utilizado una clase control Propuesta que es la que se encargará de realizar el cambio de estado entre los datos introducidos en la nueva propuesta y la imagen de la misma ya creada. También se está utilizando una clase de control Validar que se encargará de la validación de los datos introducidos en la nueva propuesta para poder confirmar la creación de la misma. Como no podía ser de otra manera debe existir una interfaz de formulario de propuestas que permita la introducción de la misma y una entidad que muestre la nueva propuesta ya terminada. Validar FormularioCrearPropuesta NuevaPropuesta RegistroPropuesta A continuación están los diagramas de colaboración para el flujo de sucesos 52\n61 Diagrama de colaboración para el flujo normal 1 Enviar() Validar 2 Registrar() FormularioCrearPropuesta 3 Mostrar() NuevaPropuesta RegistroPropuesta Diagrama de colaboración para el flujo alternativo 1 Enviar() Validar 2 Registrar() FormularioCrearPropuesta 3 Actualizar() NuevaPropuesta RegistroPropuesta Modelos para el caso de uso: Buscar Propuesta Una clase de análisis y sus objetos normalmente participan en varias realizaciones de casos de uso, lo cual se representa de la siguiente manera en el caso de uso Buscar Propuesta. Buscar Propuesta Buscar Propuesta <<trace>> En este diagrama podremos observar como se ha utilizado una interfaz formulario que será la encargada de recibir los datos de búsqueda proporcionados por los usuarios del sistema. También se ha utilizado una clase de control Buscador que realizará las labores de búsqueda de la información proporcionada en el formulario y que previamente ha sido validada por el control de validación. En último término y tras la realización de la búsqueda se 53\n62 muestra un listado con el resultado o los múltiples resultados que puedan mostrarse en ese momento. A continuación están los diagramas de colaboración para el flujo de sucesos Diagrama de colaboración para el flujo normal 54\n63 Diagrama de colaboración para el flujo alternativo. La igualdad de los diagramas de flujo normal y de flujo alternativo son debidos al funcionamiento normal de un buscador, ya que aun introduciendo mal los parámetros de búsqueda, el buscador procederá a efectuar la misma acción aunque no muestre ningún resultado aparente Modelos para el caso de uso: Visualizar Propuesta Una clase de análisis y sus objetos normalmente participan en varias realizaciones de casos de uso, lo cual se representa de la siguiente manera en el caso de uso Visualizar Propuesta. En este diagrama nos encontramos con la interfaz de selección que está basada en la muestra mediante imagen o texto de cualquiera de las propuestas creadas en el sistema. A través del elemento de control de Visualizador transforma la vista de visualización dejando la interfaz que se muestra en Vista Propuesta. A continuación están los diagramas de colaboración para el flujo de sucesos 55\n64 Diagrama de colaboración para el flujo normal Modelos para el caso de uso: Firmar Propuesta Una clase de análisis y sus objetos normalmente participan en varias realizaciones de casos de uso, lo cual se representa de la siguiente manera en el caso de uso Firmar Propuesta. Firmar Propuesta Firmar Propuesta <<trace>> En este diagrama nos vamos a encontrar con una interfaz Formulario Firma que será la encargada de recibir todos los datos de los usuarios firmantes de una propuesta que haya sido previamente seleccionada. Una vez relleno el formulario se procede a validar los datos que el firmante ha introducido a través del control de validación, que a su vez está asociada con el control de firma siendo éste el control encargado del paso intermedio y la contabilización de las nuevas firmas. Por último se muestra el aumento o la actualización del proceso de firmado. 56\n65 Diagrama de colaboración para el flujo normal Validar() Valida 3 2 Enviar() FormularioFirma 1 Mostrar() Mostrar() NuevaFirma 4 Firma Diagrama de colaboración para el flujo alternativo Validar() Valida 2 1 Enviar() FormularioFirma 3 Actualizar() NuevaFirma Firma Modelos para el caso de uso: Declarar Victoriosa una Propuesta. Una clase de análisis y sus objetos normalmente participan en varias realizaciones de casos de uso, lo cual se representa de la siguiente manera en el caso de uso Declarar Victoriosa una Propuesta. Declarar Victoriosa Propuesta Declarar Victoriosa Propuesta <<trace>> En este diagrama podemos observar el uso de la interfaz de usuario correspondiente a la declaración de una victoria sobre una propuesta. En este sentido será necesaria la asociación con un control de validación, que será el control encargado de la verificación de la victoria en función del objetivo marcado en la creación de la propuesta. Por último se mostrará una entidad de información de 57\n66 victorias que se encargará de la publicación de la misma para una posterior visualización por parte de los usuarios del sistema. Valida IUVictoria InfoVictoria Diagrama de colaboración para el flujo normal 1 Enviar() Valida 2 Validar() IUVictoria 3 Mostrar() InfoVictoria Diagrama de colaboración para el flujo alternativo. 1 Enviar() Valida 2 Validar() IUVictoria 3 Mostrar() InfoVictoria 58\n67 Modelos para el caso de uso: Compartir Propuesta Una clase de análisis y sus objetos normalmente participan en varias realizaciones de casos de uso, lo cual se representa de la siguiente manera en el caso de uso Compartir Propuesta. Compartir Propuesta Compartir Propuesta <<trace>> En este diagrama podemos observar como es necesaria una interfaz encargada del formulario de compartición o correo, que mediante el control de Envío y previo paso por el servidor de correo, muestra la información de la compartición a todos aquellos usuarios o personas con las que se desee compartir una propuesta. Servidor InfoEnvio FormularioCorreo Envio Diagrama de colaboración para el flujo normal 1 Enviar() Servidor FormularioCorreo 3 Mostrar() 2 Validar() 4 Mostrar() InfoEnvio Envio 59\n68 Diagrama de colaboración para el flujo alternativo. 1 Enviar() Servidor FormularioCorreo 3 Actualizar() 2 Validar() InfoEnvio Envio Modelos para el caso de uso: Crear Cuenta Una clase de análisis y sus objetos normalmente participan en varias realizaciones de casos de uso, lo cual se representa de la siguiente manera en el caso de uso Crear Cuenta Crear Cuenta <<trace>> Crear Cuenta En este diagrama podremos observar una interfaz llamada Formulario Registro, que será la encargada de mostrar el formulario que un usuario debe rellenar para crear su cuenta dentro de la aplicación. Una vez rellenado dicho formulario se procede a la validación de los datos introducidos en el sistema y se efectúa el registro de los datos en el sistema, mostrándose a continuación el apartado de inicio de sesión o de login del sistema. Validación FormularioRegistro login Registro 60\n69 Diagrama de colaboración para el flujo normal. 1Validar() Validación 2 Enviar() 3 Mostrar() login FormularioRegistro Registro Diagrama de colaboración para el flujo alternativo. 1Validar() Validación FormularioRegistro 3 Actualizar() 2 Enviar() login Registro Modelos para el caso de uso: Iniciar Sesión Una clase de análisis y sus objetos normalmente participan en varias realizaciones de casos de uso, lo cual se representa de la siguiente manera en el caso de uso Iniciar Sesión Iniciar Sesión Iniciar Sesión <<trace>> En este diagrama podemos observar el uso de un formulario de inicio de sesión que se encargará de la introducción del nombre de usuario y la contraseña de un usuario previamente registrado. Una vez relleno el formulario se procede al envío de los datos al servidor de validación que será el encargado de la comprobación de la identificación del usuario. Por último y una vez comprobada la autentificación de los datos se muestra el perfil del usuario. 61\n70 FormularioSesión ServidorValidación Perfil Diagrama de colaboración para el flujo normal. FormularioSesión 1 Validar() ServidorValidación 2 Mostrar() Perfil Diagrama de colaboración para el flujo alternativo. FormularioSesión +2 Actualizar() +1 Validar() ServidorValidación Perfil 5.4 Modelo de diseño Durante el diseño modelamos el sistema y su arquitectura para que soporte los requisitos funcionales y no funcionales. Una entrada esencial al diseño es el modelo de análisis. En esta fase se realizará, por un lado, un diagrama detallado de las clases finales que existirán en el modelo de implementación. Estas clases en muchos casos serán similares a las obtenidas durante el análisis, aunque también aparecerán nuevas clases que no fueron identificadas en la anterior etapa. Además, para cada diagrama de clases se adjuntará un diagrama de secuencia, que mostrará la evolución de las clases a lo largo del tiempo y la interacción entre ellas Especificación de casos de uso Modelos para el caso de uso: Crear Propuesta Una realización de caso de uso del diseño proporciona una traza directa a una realización de caso de uso de análisis en el modelo de análisis. 62\n71 Crear Propuesta Crear Propuesta <<trace>> En el diagrama siguiente podemos observar el conjunto de clases a utilizar en el caso de uso Crear Propuesta. Haciendo una descripción del diagrama podremos ver como se hará uso de una clase de validación encargada de comprobar que los datos introducidos en el formulario sean correctos. También podemos observar como la clase de registro especificada en el diagrama será la encargada de grabar en el sistema la nueva propuesta y una vez realizada esta acción dar paso a una nueva propuesta. Por último es obligado mentar el formulario de creación de propuestas que ejerce la función que su propio nombre indica, además de actualizar su imagen en caso de encontrarse dentro del periodo de flujo alternativo. RegistroPropuesta +Registrar() +Enviar() FormularioCrearPropuesta +Enviar() +Actualizar() NuevaPropuesta +Mostrar() Valida +Validar() Diagrama de secuencia para el flujo normal. 63\n72 Diagrama de secuencia para el flujo alternativo Modelos para el caso de uso: Buscar Propuesta. Una realización de caso de uso del diseño proporciona una traza directa a una realización de caso de uso de análisis en el modelo de análisis. Buscar Propuesta Buscar Propuesta <<trace>> En este diagrama se puede observar la utilización de la clase Generar Formulario que es utilizada para la creación de un nuevo formulario de búsqueda y que a su vez se complementa con la clase de validación de los datos que se han introducido en el buscador. No puede faltar la clase enviar, que se utiliza para el envío de los datos que ya han sido validados previamente. Las clases de muestra de formulario y de la muestra de los resultados efectuarán una labor de muestra tanto de los datos del formulario como de los datos que han sido recabados tras la búsqueda y que son generados por la clase generar Vista. 64\n73 Diagrama de secuencia para el flujo normal. Diagrama de secuencia para el flujo alternativo. 65\n74 El diagrama de flujo alternativo es equiparable al diagrama de flujo normal ya que la introducción errónea o no introducción de datos en el formulario del buscador proporcionará una búsqueda asociada al mismo en el caso de la introducción errónea o una búsqueda genérica en el caso de la no introducción de ningún dato Modelos para el caso de uso: Visualizar Propuesta Una realización de caso de uso del diseño proporciona una traza directa a una realización de caso de uso de análisis en el modelo de análisis. Visualizar Propuesta Visualizar Propuesta <<trace>> En este diagrama podemos observar cómo se hace uso de las clases Generar Formulario y Enviar Formulario las cuales generan la selección de visualización y envía la información al control de visualización respectivamente. Una vez en el Control Visualizador las clases que muestran el formulario y las propuestas a mostrar se activan en función de la acción que active el usuario. Por último la Propuesta es mostrada correctamente, siendo la finalidad de este caso de uso envuelto en el diagrama de clases del modelo de diseño. Diagrama de secuencia para el flujo normal. 66\n75 Modelos para el caso de uso: Firmar Propuesta Una realización de caso de uso del diseño proporciona una traza directa a una realización de caso de uso de análisis en el modelo de análisis. Firmar Propuesta Firmar Propuesta <<trace>> En este diagrama podemos observar cómo se hace uso de las clases Validar Formulario y Enviar Formulario que serán las encargadas del envío de los datos introducidos por el usuario firmante y la validación de los datos enviados de forma respectiva. Una vez realizado la validación, se reenvían los datos y se muestran el control de firma que será el encargado o de actualizar los datos, ya que no se ha realizado el proceso de forma correcta, o de contabilizar y reenviar la firma para que se muestre a través de la clase mostrar dentro de la entidad de Nueva Firma. Validar +EnviarValidacion() +MostrarValidacion() FormularioFirma +ValidarFormulario() +EnviarFormulario() NuevaFirma +Mostrar() Firma +EnviarFirma() +ActualizarFirma() 67\n76 Diagrama de secuencia para el flujo normal. InterfazFirma ControlValidacion ControlFirma NuevaFirma : Usuario Anonimo 1 : Rellena() 2 : Envia() 3 : Valida() 4 : Envia() 5 : Muestra() Diagrama de secuencia para el flujo alternativo. InterfazFirma ControlValidacion ControlFirma NuevaFirma : Usuario Anonimo 1 : Rellena() 2 : Envia() 3 : Valida() 4 : Envia() 5 : Actualiza() Modelos para el caso de uso: Declarar Victoriosa una Propuesta. Una realización de caso de uso del diseño proporciona una traza directa a una realización de caso de uso de análisis en el modelo de análisis. Declarar Victoriosa Propuesta Declarar Victoriosa Propuesta <<trace>> 68\n77 En este diagrama visualizamos las clases de Enviar Victoria y Enviar Validación que servirán de mensajería con respecto a los datos para ser validados en caso de una declaración de victoria y para el envío de la victoria cuando ha sido validada previamente. Como es evidente las clases de Envío de validación y Muestra de validación se hará uso de ellas una vez se realice la petición y se hayan comprobado y contabilizado los requisitos exigidos como objetivos para declarar la misma. En último término la muestra de la victoria es una clase encargada de mostrar la vista de la propuesta victoriosa. Validar +EnviarValidacion() +MostrarValidacion() InterfazVictoria +EnviarVictoria() +EnviarValidación() InfoVictoria +MostrarVictoria() Diagrama de secuencia para el flujo normal. InterfazVictorias ControlComprobacion Comprobación NuevaVictoria : Usuario Anonimo 1 : Seleccionar() 2 : Envia() 3 : Comprueba() 4 : Valida() 5 : Muestra() 69\n78 Diagrama de secuencia para el flujo alternativo. InterfazVictorias ControlComprobacion Comprobación NuevaVictoria : Usuario Anonimo 1 : Seleccionar() 2 : Envia() 3 : Comprueba() 4 : Valida() 5 : Muestra() Como se puede observar, el diagrama de secuencia de flujo alternativo es idéntico al diagrama de flujo normal, circunstancia que viene dada por la ruta marcada entre clases aunque no se tengan los mismos datos a recibir Modelos para el caso de uso: Compartir Propuesta. Una realización de caso de uso del diseño proporciona una traza directa a una realización de caso de uso de análisis en el modelo de análisis. Compartir Propuesta Compartir Propuesta <<trace>> A lo largo del siguiente diagrama podemos observar cómo se hace uso de las clases de Envío Correo en los diferentes pasos, ya que se considera una clase fundamental para la comunicación entre el servidor y el control de envío, además de cómo su nombre indica, sirve para la finalización del envío y la compartición de la propuesta. También se puede observar como la validación es una clase clave para el proceso de compartición de propuestas, ya que será la encargada de comprobar que los datos enviados sean los correctos o de redirigir a la actualización de datos para su posterior corrección. En último lugar y de forma imprescindible, la muestra de la información de envío forma parte de las clases que son necesarias para poder comprobar el correcto envío de una propuesta a compartir. 70\n79 Servidor +ValidaciónCorreo() +MostrarCorreo() FormularioCorreo +EnvioCorreo() +ValidacionCorreo() InfoEnvio +Mostrar() Envio +MostrarCorreo() +EnvioCorreo() +ActualizarDatos() Diagrama de secuencia para el flujo normal. InterfazCorreo ControlServidor Envio InfoEnvio : Usuario Anonimo 1 : Cumplimentar() 2 : Enviar() 3 : Validar() 4 : Enviar() 5 : Mostrar() Diagrama de secuencia para el flujo alternativo. InterfazCorreo ControlServidor Envio InfoEnvio : Usuario Anonimo 1 : Cumplimentar() 2 : Enviar() 3 : Validar() 4 : Enviar() 5 : Actualizar() 71\n80 Modelos para el caso de uso: Crear Cuenta Una realización de caso de uso del diseño proporciona una traza directa a una realización de caso de uso de análisis en el modelo de análisis. Crear Cuenta <<trace>> Crear Cuenta En este diagrama se puede observar la utilización de la clase Formulario de registro, que será la clase encargada de las operaciones de envío de los datos para validarse y la operación de actualización del formulario para crear los nuevos usuarios del sistema. También se puede observar como la clase de validación es la encargada de comprobar que los datos de los nuevos usuarios a registrarse sean los correctos y posteriormente enviarlos a la clase de registro, que será la clase realmente encargada de efectuar el registro de la nueva cuenta o de devolver el error y mostrar la actualización del formulario con los errores de registro. Por último la clase de login es la clase sobrevenida del correcto registro de una cuenta de usuario y procede a través de su operación de muestra de datos a la iniciación en el sistema. Validación +EnviarValidación() +MostrarDatos() Login FormularioRegistro +MostrarDatos() +EnviarValidación() +Actualización() Registro +Actualización() +MostrarDatos() 72\n81 Diagrama de secuencia para el flujo normal. FormularioRegistro Validacion Registro Login : Usuario Registrado 1 : Seleccion() 2 : Envio() 3 : Validacion() 4 : Muestra() Diagrama de secuencia para el flujo alternativo. FormularioRegistro Validacion Registro Login : Usuario Registrado 1 : Seleccion() 2 : Envio() 3 : Validacion() Modelos para el caso de uso: Iniciar Sesión. Una realización de caso de uso del diseño proporciona una traza directa a una realización de caso de uso de análisis en el modelo de análisis. Iniciar Sesión Iniciar Sesión <<trace>> 73\n82 En este diagrama visualizamos la clase de formulario de inicio de sesión, la cual está compuesta por las operaciones de envío de datos y de actualización, que serán los encargados de la validación de los datos en el servidor y de la actualización del formulario en caso de error. La clase del servidor de validación a través de sus operaciones se encargara de validar y de enviar los datos allí comprobados tanto al perfil si la validación se procede de forma correcta, como al formulario para su posterior rectificación. FormularioSesión +Actualización() +Envio() ServidorValidación +Envio() +Actualización() Perfil +Mostrar() Diagrama de secuencia para el flujo normal. FormularioIncioSesión ServidorValidación Perfil : Usuario Registrado 1 : Rellenar() 2 : Enviar() Diagrama de secuencia para el flujo alternativo. FormularioIncioSesión ServidorValidación Perfil : Usuario Registrado 1 : Rellenar() 2 : Enviar() 74\n83 5.5 Implementación En este capítulo de hará un repaso por toda la implementación del portal así como de los diferentes módulos necesarios para el funcionamiento del mismo. En primer lugar daremos una pincelada sobre la decisión de utilizar Drupal para efectuar el proyecto y poco a poco iremos desgranando la configuración e instalación para que el funcionamiento del mismo sea el adecuado Por qué Drupal? Antes de empezar a explicar los distintos aspectos de implementación del portal, vamos a realizar una justificación del porqué el uso de Drupal a la hora de llevar a cabo la implementación del portal. Por todos es sabido que la implementación de un portal web se puede realizar con muchos lenguajes de programación y CMS varios que permiten diferentes funcionalidades. En este sentido, la elección de Drupal no es un acto fortuito sino una elección premeditada que parte de los múltiples conectores y módulos previamente implementados que aporta Drupal y que a la vez proporcionan a nuestro sistema un amplio abanico de funciones a integrar en el mismo. Si bien se ha decidido usar Drupal porque no solo nos facilita mucho la vida a la hora de realizar el portal, también se ha tomado esta decisión porque es una herramienta testada por la comunidad informática aportando su correcto funcionamiento. Así mismo, nos ofrece a diferencia de otros gestores de contenido la posibilidad de modificarlo tal y como queremos a nivel no solo de usuario sino a nivel de una persona con conocimientos avanzados sobre Informática. Esto no quiere decir que viene todo hecho sino que hay que saber aportar múltiples conocimientos para el buen uso de la plataforma.. El ciclo de aprendizaje en cuanto a Drupal se va logrando con la práctica y a medida que se va avanzando en la implementación del sitio Web en cuestión. Además de adquirise estos conocimientos se refuerzan conocimientos previos tales como Php, Mysql, etc. Como conclusión, hemos decidido finalmente que Drupal es la herramienta oportuna ya que nos aporta bastante flexibilidad para llevar a cabo los requisitos de nuestra plataforma. Es por ello aprovechando los conocimientos ya adquiridos en una de las asignaturas de la carrera nos ha permitido valorar la mejor opción de uso en cuanto al desarrollo de nuestro portal web. 75\n84 5.5.2 Módulos necesarios para la implementación En primer lugar se va proceder a indicar donde hemos conseguido todos los módulos correspondientes para el buen funcionamiento del portal. Para ello y tras una ardua búsqueda, hemos decidido obtener todos los módulos directamente desde el sitio oficial de Drupal. Este portal nos proporcionará no solo la posibilidad de descargar el módulo sino también la posibilidad de obtener errores y opiniones de los distintos usuarios, los cuales ya han probado el módulo y han tenido la amabilidad de compartir esta información. Es por ello que resulta de gran utilidad esta información ya que nos ayuda bastante a la hora de buscar una solución en el caso de tener problemas con algún módulo, ya sea por un error nuestro o por no saber cómo configurar el mismo. Pudiendo así utilizar los comentarios de los distintos usuarios como valoración de si hemos instalando bien el módulo o no. En este momento nos encontramos en disposición de hacer un recorrido por los distintos módulos utilizados para implementar el sitio dando información de cada uno de ellos y así mismo justificando el porqué de uso. 76\n85 Views Este módulo nos permite hacer vistas personalizadas de nuestro contenido, pudiendo de esta manera ordenar bien el contenido según su tipo, según su fecha de publicación o cualquier otro filtro. Hay muchas combinaciones posibles y es un módulo muy importante ya que nos permite agrupar contenido de nuestro portal además de filtrarlo de distintas maneras. Su uso está más que justificado ya que gracias a él podemos organizar todo el contenido tal y como se quiera. En nuestro caso hemos utilizado este módulo para hacer las distintas vistas relacionadas con las propuestas en general o las propuestas de cada uno, etc. 77\n86 Panels El panels es otro módulo que en conjunto con el views nos permite la posibilidad de crear distintos paneles a una vista en concreto, así como realizar una vista personalizada en función de un contexto utilizando una relación Justificando el uso de este módulo, podemos decir que al hacer un Conten Pane crea una relación entre el usuario logueado mediante un elemento Token del sistema y la propuesta en concreto. Este proceso crea una asociación con el autor de la propuesta y permite la realización de una vista personalizada de sus propuestas Rules El modulo Rules es un excelente módulo el cual nos permite de una forma bastante intuitiva crear diferentes reglas en el portal, pudiendo hacer que el sistema sea bastante flexible y dinámico por decirlo de alguna forma. De esta forma podemos variar bastante el comportamiento del portal y configurar su comportamiento a nuestro gusto. 78\n87 Justificamos el uso de este módulo sobre todo a la hora de poder impedir el acceso a contenido dentro del portal por parte de roles los cuales no tienen permiso. Al mismo tiempo podemos redirigir a otro sitio de nuestro portal en caso de que uno de estos roles intente acceder al mismo WYSIWYG Este módulo lo consideramos uno de los más importantes, ya que nos permite configurar el formato de edición a la hora de agregar contenido y de esta manera facilita al usuario su trabajo a la hora de agregar contenido al portal, pudiendo tener un formato cómodo a la hora de trabajar con el mismo. La justificación es bastante obvia y es el poder enriquecer el formato a la hora de crear contenido para el portal. 79\n88 Page Manager Módulo importantísimo para poder modificar las distintas páginas del portal a gusto del consumidor, pudiendo modificar unas páginas en función de unas reglas o un comportamiento. También permite modificar la página principal o crear alguna página y agregarla o modificarla como queramos. Este módulo viene muy bien para poder enriquecer al portal de una forma dinámica su comportamiento, bien añadiendo reglas o bien, permitiendo una relación para mostrar cierto contenido o no. Su justificación en el portal es clara y es el poder mostrar contenido en función de los roles del portal así como poder modificar distintas páginas y mostrarlas tal y como se quiere Menú Administrador Módulo útil para poder administrar el sitio de una forma más cómoda ya que nos ofrece la posibilidad de navegar dentro de la configuración del sitio desde un menú navegable sin necesidad de estar perdiendo el tiempo. Su uso se justifica en que se ahorra tiempo a la hora de llegar al punto de configuración necesario. Masquerade Módulo el cual viene bastante bien a la hora de hacer pruebas ya que nos ofrece la posibilidad de cambiar de usuario sin necesidad de tener que estar cerrando la sesión del mismo. Tan solo con hacer clic al usuario que queremos cambiar este módulo realiza el cambio de sesión. 80\n89 Este módulo viene muy bien a la hora de llevar a cabo pruebas con distintos roles y poder comprobar que efectivamente cada rol cumple su función. Su uso está más que justificado y es bastante sencilla ahorrándonos tiempo CCK Es un módulo muy útil el cual nos permite agregar campos a nuestro contenido, pudiendo ser estos campos personalizados. Por tanto esto nos ayuda en gran medida a realizar posteriores relaciones con los distintos contenidos del portal y nos simplifica bastante la vida pudiendo así hacer relaciones complejas dentro del portal. Su uso se justifica en el poder añadir campos en los distintos tipos de contenido y de esta forma hacer una relación o añadir los campos necesarios para poder llevar a cabo funcionalidades del portal. 81\n90 Voting API El módulo Voting API es más que significativo para nuestro portal ya que nos permite poder llevar a cabo el sistema de votaciones de las distintas propuestas del sitio web de una manera eficiente y bastante testeada por los distintos usuarios. Es una manera bastante cómoda de poder implementar el sistema de votaciones de nuestro portal y su uso se ve más que justificado Organic Group Este módulo nos permite crear grupos dentro de Drupal pudiendo de esta manera organizar todo el grupo en función de grupos y relacionar todo el contenido de estos grupos pudiendo hacer contenido privado. De una u otra manera esto nos permite ir más allá que el uso de los roles, ya que podemos crear contenido en función de grupos y privatizar de esta manera el contenido de nuestro portal haciendo de éste mucho más complejo y permitiendo jugar mucho más con él. En este caso podemos diferenciar el uso de este módulo para poder llevar a cabo la implementación del lado de las organizaciones en este portal, pudiendo privatizar el contenido a las mismas Menú Item Visibility Módulo bastante útil más que nada por el hecho de facilitarnos la implementación a la hora de ocultar un enlace de un menú en función del rol. De esta manera podemos crear un menú dinámico en función del rol que se encuentre logueado. De esta manera justificamos su uso, ya que podemos llevar a cabo un menú en nuestro portal que sea dinámico en función de cada rol de los distintos usuarios del portal 82\n91 PayPal Módulo de pasarela del pago para dar las posibilidades a los usuarios del portal de hacer una donación a la organización del portal y de esta forma poder ayudar a mantener el mismo. Justificamos su uso ya que vemos importante el que se puede ayudar a los distintos desarrolladores que emplean tiempo mejorando la aplicación y apoyan en su crecimiento Instalación de Drupal Cabe destacar que esta instalación ha sido utilizando el sistema operativo Windows y a continuación se describen los pasos a seguir en este sistema operativo. En el caso de hacer uso de dispositivos en los cuales el sistema operativo Linux es su anfitrión, la instalación es prácticamente la misma Xampp Para comenzar se debe configurar el servidor Web y para ello utilizaremos XAMPP, que permite poner en funcionamiento nuestro portal de forma correcta. Procedemos a la descarga de la plataforma Xampp a través del portal web siguiente: 83\n92 Una vez efectuada la descarga, comenzamos con la instalación y la posterior ejecución desde el panel de control en donde procederemos a ejecutar el Apache y MySQL tanto para el servidor web como para la base de datos. Una vez instalado el XAMPP procedemos a descargar el Drupal del siguiente sitio https://drupal.org/project/drupal en este caso descargamos la versión 7.23 Una vez descargado Drupal descomprimimos todo su contenido en la carpeta Htdocs donde se encuentre localizado el XAMPP. Una vez descomprimido el contenido de Drupal procedemos a acceder al panel de control de la base de datos y creamos una base de datos para poder proporcionarle una a la hora de instalar el mismo. 84\n93 Accedemos a la misma desde el navegador a la dirección Realizados estos pasos accedemos al que sería nuestro portal e iniciamos la instalación de Drupal. Antes de realizar ningún otro paso, al acceder al sitio se nos va a lanzar un asistente de instalación en el cual procederemos a seguir los distintos pasos. 1) Seleccionar instalación Standard para que se nos instalen todos los módulos incluidos en esta versión. 2) Elegimos el idioma correspondiente en este caso español 3) Drupal nos pide la base de datos la cual le tenemos que proporcionar, ésta ya la hemos creado así que simplemente se la proporcionamos 4) Se procederá a instalar módulos y configuración predeterminada de Drupal así que simplemente es esperar 5) Información del sitio a proporcionar tal como nombre del sitio, correo del administrador, lema del sitio, etc. 6) Drupal se encuentra instalado y comenzaremos a configurar nuestro sitio. Con estos pasos hemos conseguido instalar Drupal, un gestor de contenido el cual vamos a utilizar para implementar nuestro portal. A continuación pasaremos a explicar el uso de los distintos módulos instalados y la justificación de los mismos así como la configuración del sitio hasta llegar al portal final. 85\n94 5.5.4 Configuración y creación de los elementos del portal A continuación se va a dar un repaso por toda la configuración del portal y los aspectos más importantes del mismo, dando a conocer la lógica del sitio web y como se ha llevado a cabo su puesta en marcha teniendo en cuenta sus futuras opciones a configurar o el alcance que podría llegar a tener el mismo. En primer lugar cuando nos encontramos con Drupal instalado y funcionando, observamos como la aplicación no nos aporta ninguna funcionalidad activa y por tanto tenemos que tener bien claro lo que queremos llevar a cabo antes de empezar a trabajar para llevar todo a buen término. En este caso como se explica en el documento, hemos utilizando el Proceso Unificado de Desarrollo y por tanto las distintas características que vamos a llevar a cabo y como queremos que se comporten cada una de ellas vienen marcadas por éste. Utilizando este documento y empleando la información adecuada acerca de Drupal e investigando sobre el tema, a medida que vamos avanzando comenzamos instalando los módulos necesarios y haciendo las pruebas oportunas para continuar la implementación del sitio hasta una vez conseguir de una manera objetiva el correcto funcionamiento del mismo. Este proceso no restringe los posibles bugs o errores que se pueden encontrar en el portal, aunque a través de las ayudas oportunas se van solventando. Ya que ninguna aplicación se crea inicialmente sin errores y estos se van corrigiendo a medida que van surgiendo, nosotros hemos ido corrigiendo los fallos a medida que han aparecido en el proceso de implementación Creación de elementos del portal Lo primero que nos encontramos a la hora de instalar Drupal, es un portal sin ningún tipo de contenido al que hay que ir añadiendo funcionalidades para obtener el resultado esperado. Una vez percatándonos de esta situación, se añadió el módulo views para poder agrupar el contenido. Dicho contenido no ha sido desarrollado aún y es por ello que lo primero que hacemos es crear el tipo de contenido que va a tener nuestro portal. En este caso y sin perder un segundo, nos ponemos a implementar el tipo de contenido Propuesta y se piensan en los distintos campos que puede a llegar a tener este tipo de contenido para crearlos, ya que es de gran utilidad para poder realizar las vistas y poder avanzar en nuestro portal. Otro tipo de contenido que creamos es el de tipo victoria, que sirve para poder asociar a cada tipo de propuesta una victoria en caso de tenerla y por tanto si tenemos en cuenta que a priori uno de los campos que es el ID de la propuesta en cuestión, se puede relacionar la una con la otra. Sin más dilación empezamos a crear las distintas vistas agrupando las propuestas pues ya con esto podemos añadir las mismas al menú principal. 86\n95 Una vez realizado esto, se quiere agrupar las propuestas con su creador siendo necesario asignar el tipo propuesta con un campo de enlace a la misma que permite acceder al perfil de la propuesta. Mediante el page manager se pudieron modificar las páginas a nuestro gusto, incluyendo este pane el cual aumenta su complejidad en nuestro portal. Tras este proceso y haciendo uso de los elementos anteriormente mencionados, se consigue una combinación entre los módulos que permite la ocultación de los menús y la redirección a través de las reglas oportunas a los usuarios que no poseen permisos. Este aspecto es muy importante, pues tenemos que tener en cuenta el perfil de la propuesta, ya que el acceso viene dado por la utilización del campo de enlace agregado y enviado al autor de la misma. Tenemos en cuenta el aspecto de los comentarios y de la valoración de las mismos, así como las supuestas victorias que puedan acaecer y que son aspecto importante pero algo complejo de llevar a cabo, ya que son dos tipos de contenido distinto y que están relacionados mediante un campo que muestra si hay victoria o no. Todo este proceso de implementación ha evolucionado en función de las diferentes necesidades que han ido acaeciendo a lo largo del desarrollo de software. Debemos tener aspectos en cuenta con respecto a la seguridad del sitio, ya que es muy importante controlar las distintas vulnerabilidades que el portal puede llegar a ofrecer. Una muestra puede ser que un usuario pueda acceder a contenido que no debe modificar de la configuración del portal aprovechando estos errores. Es por ello que se ha tenido muy en cuenta el uso del módulo rules añadiendo las reglas necesarias para evitar esto, tal como no poder entrar a contenido. En este sentido, se ha tenido especial cuidado con la configuración de los permisos y para ello cada vez que se instala algún módulo se tiene muy en cuenta este punto. Para testar esta situación se procedió a crear usuarios de prueba, probando todos los puntos o aspectos para que no exista ninguna vulnerabilidad. Se ha tenido en cuenta el punto vista de usuario final para poder evitar errores futuros, ya que creemos que hoy en día lo que menos se tiene en consideración es de la seguridad a la hora de diseñar portales y es un aspecto bastante importante del cual puede llegar a depender nuestra aplicación. Hablando de la seguridad debemos decir que las acciones acaecidas para solventar las vulnerabilidades del sistema no son absolutas y por tanto se nutren de la utilización y la aparición de erratas a través del continuo trabajo con el mismo Conjunto de aspectos englobados en la configuración En primer lugar nos encontramos con dos tipos de contenidos, los cuales hemos incorporado al portal en este caso y que son los de tipo propuesta y tipo victoria como se ilustran a continuación. 87\n96 Con los siguientes campos: Vistas del Portal Otro aspecto importante en la configuración del portal son las vistas, ya que son como se va a mostrar el contenido del portal y tienen la siguiente configuración: 88\n97 En este caso lo que nos importa es la vista relacionada con mis propuestas y las propuestas en general, así como la página principal. A continuación vamos a mostrar la relación con respecto al contexto y la configuración de la vista formada en Mis Propuestas ya que es la realmente interesante en este caso: 89\n98 Esta vista es una muestra de las formantes en el proyecto en relación a un contenido creado en el portal. Organic Group: Otro aspecto a tener en cuenta pero el cual se va desarrollando a media que se va utilizando el portal, es la inclusión necesaria de grupos por la necesidad existente de permitir el acceso a datos de forma exclusiva y por tanto lo que se ha hecho es incluir un tipo de contenido OG con las siguientes características. Como se puede observas en la fotografía se ha asociado este tipo de contenido como Grupo y como contenido de grupo, lo que posteriormente a la hora de crear un contenido se puede relacionar a este grupo creado. En la configuración de OG en el aspecto de Field Settings habría que añadir los campos correspondientes en este caso a propuestas. 90\n99 Como se muestra en la captura de pantalla tenemos dos campos los cuales nos dan la posibilidad de crear una propuesta y asignar una de estas propuestas a algunos de los grupos. Menú Principal Un aspecto de configuración importante que nos da acceso a los distintos enlaces del portal así como según el rol asignado a cada usuario, es el acceso a ciertos enlaces o no. Vamos a pasar a comentar cada uno de los enlaces: 91\n100 Inicio Enlace el cual nos da acceso a la página principal todos los usuarios tienen acceso a él. Propuestas Enlace el cual nos muestra la vista anteriormente comentada y nos da acceso a la vista Propuestas la cual tienen acceso todos los usuarios pero solo muestra el contenido al cual ellos pueden acceder. Crear Propuesta Enlace disponible para todos los usuarios el cual nos da la posibilidad de crear una propuesta directamente. Apariencia Que decir con respecto a este aspecto tan importante que es la apariencia, pues bien tras buscar en profundidad se ha decidido utilizar un tema llamado Business, el cual nos da la posibilidad de configurar tanto el logo como el juego de la paleta de colores dando un aspecto bastante sencillo pero elegante y cómodo para el usuario. 92\n101 Personas Con respecto a este aspecto hemos definido diferentes roles de usuarios los cuales, ya han sido especificado en el uso de la metodología PUD previamente utilizada. Módulos Al respecto de los módulos, los cuales ya se han mencionado más arriba, se va mencionar el módulo instalado a respecto de las votaciones, el cual nos da la posibilidad de votar las propuestas. Configuración del servidor de Correo Interno Que decir acerca de este aspecto tan importante el cual nos permite enviar correos desde un servidor de salida SMTP. Ha sido un módulo imprescindible y por tanto se procedió a su 93\n102 configuración para enviar correos desde nuestra web bien para confirmar a un usuario o para dar cierta información a ciertos usuarios. Rules Nos encontramos con un aspecto importante en el cual se han creado diferentes reglas dentro de las cuales se encuentran aquellas que no dejan acceder al perfil a personas no tengan permiso para acceder a la misma. 94\n103 5.6 Pruebas y arranque del servidor Una vez realizada la instalación y la configuración del portal, faltaba una de las partes claves de un sitio web, que es su correcto funcionamiento. Para comprobar el correcto uso del portal se ha decidido utilizar un servicio de NO-IP, el cual ofrece la posibilidad de agregar un host mediante el cual se permite el acceso desde el exterior. El proceso realizado en este servicio comienza con la creación de una cuenta de usuario y configurando el host, el cual ha recibido el nombre de proact.no-ip-org 95\n104 Tras realizar esta actividad se procedió a la apertura de puertos del router permitiendo posteriormente el acceso al portal desde una red ajena a la local. Encontrándonos en esta situación solo fue necesaria la descarga del software que proporciona el servicio de no-ip para modificar la ip de forma dinámica y mantener activa la base de datos y el servidor web Apache a través del Xampp 96\n105 6 Conclusiones y trabajo futuro Una vez dada por concluida la fase de desarrollo y prueba del proyecto se pueden extraer conclusiones del trabajo realizado, así como realizar un pequeño compendio de posibles ampliaciones a la aplicación creada. Estos dos puntos se tratarán por separado en los apartados que vienen a continuación. 6.1 Conclusiones Una vez llegados a este punto y tras efectuar todo un recorrido por la introducción, legislaciones, análisis, desarrollo y otros aspectos a tener en cuenta, es momento de efectuar las conclusiones oportunas sobre la realización del proyecto. En primer lugar, quiero hacer mención a la evolución reinante a lo largo de todo el proyecto, ya que si bien es considerado el comienzo del proyecto y el desarrollo del mismo, no es menos cierto que la idea de formar un portal de esta envergadura pertenece a un valor contable dentro del proceso de desarrollo. Una vez dicho esto, la labor de documentación ha sido una labor ardua de investigación en la cual se han tenido que valorar cuales eran las piezas claves y el verdadero espíritu que iba a ser aportado al portal web en la relación existente con los usuarios. El motivo de tan extensa tarea, es que no se conseguía el mismo efecto de libertad a la hora de obligar a los usuarios a retener sus datos dentro del portal que realizando este acto y por consiguiente creaba una relación de dependencia con el mismo que se aleja de la finalidad por la que fue diseñado. En cuanto al análisis ha sido complicado discernir cuales eran las características reseñables a implementar y posteriormente los casos de uso asociados a las mismas, ya que podrían crear conflictos a la hora de ubicar la conjunción de los proyectos ProAct Y ProActPRo. Otra conclusión a reseñar, es la necesidad existente de separar las dos versiones de ProAct, ya que se pretende aportar a los usuarios dentro de la misma plataforma web un soporte completo y a la vez diferenciados que aporte un punto de vista social y personal y otro organizativo e institucional. Tras la conclusión del análisis y en el proceso de desarrollo, han existido escollos que en cierta medida han podido salvarse en mayor o menor medida, ya que si bien el CMS de Drupal aporta una plataforma de desarrollo útil y orientada a los usuarios de forma segura. También encapsula dentro de su núcleo determinadas opciones a implementar, como son los aspectos interactivos o de interfaces que requieren la entrada a desarrollo en bajo nivel y que merma la velocidad de desarrollo del portal en otras secciones del mismo. La decisión de dejar abiertas ciertas secciones del software, parte de la necesidad de renovación y actualización que viene implícita en este tipo de portales y a razón de este hecho se puede hacer hincapié en los controles de seguridad a realizar periódicamente para comprobar la eficiencia del portal. En definitiva, la experiencia ha sido una labor completa de los conocimientos adquiridos a lo largo de todos mis años de estudio y sobre los cuales me encuentro orgulloso. 97\n106 6.2 Implementación Rest y Trabajo futuro Se ha decido incorporar en el portal la posibilidad de acceder mediante un cliente Rest a nuestro servidor de tal forma que en un futuro se deja abierta la posibilidad de poder acceder al portal a obtener datos, permitiendo ser representados en alguna aplicación para móvil bien para Android o IOS. La idea es no es tan compleja como puede parecer. Consiste en dar la funcionalidad a nuestro portal de actuar como un servidor Rest, ofreciendo la posibilidad mediante autenticación de poder acceder un nodo de nuestro sitio y representar u obtener una clase a partir de uno de estos Nodos. De esta manera podríamos obtener distintos datos de uno de los nodos, por ejemplo de un nodo tipo propuesta podríamos obtener la propuesta o el autor de la misma. Así mismo podríamos también actualizar un nodo mediante el acceso al servidor rest. Estas funcionalidades nos facilita el uso del software en un dispositivo móvil, ya que se podría implementar una aplicación Android la cual acceda a este portal para obtener la información y posteriormente representar en la aplicación correspondiente los datos o actualizar los mismos. Las pruebas realizadas para poder comprobar el correcto funcionamiento de este servidor, las hemos testado utilizando un Cliente Rest en java mediante Eclipse Juno. Básicamente se obtiene una clase a partir del XML generado y el cual representa los datos del Nodo del que queremos obtener los datos. Esta actividad sirve tanto para identificarnos en la plataforma como para la identificación del Nodo correspondiente, en el caso del Nodo que especifica el tipo propuestas. Una vez realizada la autenticación en el portal comprobamos obteniendo un Nodo en concreto la propuesta correspondiente accediendo a los datos donde también se podrían modificar los contenidos sin ningún tipo de problemas. Esta implementación deja abierta la posibilidad de aumentar la plataforma en futuras implementaciones y permitir mejoras. 98\n107 Anexo I: Competencias En este apartado se trataran las competencias que deben ser cubiertas a lo largo de la realización de este proyecto y poder crear una plataforma bajo los estándares de aprendizaje desarrollados por la ULPGC. En primer lugar debemos hablar de la competencia CII01, la cual nos indica que se debe conseguir la capacidad para diseñar, desarrollar, seleccionar y evaluar aplicaciones y sistemas informáticos, asegurando su fiabilidad, seguridad y calidad, conforme a principios éticos y a la legislación y normativa vigente. Como será evidente a lo largo del desarrollo del proyecto dicha capacidad queda inherente en el mismo, pues la finalidad planteada es la de desarrollar una aplicación que permita un uso seguro y de calidad, además de cumplir con todos los principios éticos y legales que permitan la buena utilización del portal. La segunda competencia de la cual vamos a hablar y que está clasificada como la CII02, nos indica que se debe tener la 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. En este sentido podemos a poyarnos en la utilización del PUD (Proceso de desarrollo unificado) el cual es parte reinante dentro de las metodologías de desarrollo ágil y que se ha utilizado para ejercer un desarrollo continuo, seguro y equilibrado del proyecto. También hay que decir que el liderazgo y la puesta en marcha del portal parten de la utilización de Drupal como base de desarrollo, ya que es considerada una plataforma de contante evolución y buena estructura de arranque además de no tener un impacto económico muy elevado. Otra competencia cubierta en el portal web y que está indicada así en los estándares de enseñanza, es la competencia CII04 la cual nos indica el uso de los estándares y técnicas de instalación vigentes y adecuadas. En referencia a esta condición se debe decir que se van a utilizar los estándares informáticos de instalación y de referencia generados por la comunidad informática, además de seguir la normativa vigente en cuanto a la realización del proyecto en cuanto a sus diferentes apartados. También hay que hacer mención a la competencia CII18 dentro de la cual este proyecto está inmerso, incluyéndose en el siguiente capítulo y que nos habla de la legislación en los ámbitos nacionales y europeos dentro de la cual se encuentra el portal web. En último lugar pero no menos importante ha de incluirse la competencia TFG01, dentro de la cual se puede mostrar como el desarrollo del trabajo cumple con las competencias adquiridas a lo largo de la enseñanza universitaria y permite dar rienda suelta a la imaginación, permitiendo integrar la diferentes tecnologías aprendidas a lo largo de la docencia universitaria. 99\n109 Anexo II: Legislación vigente Todo sitio web debe cumplir las leyes nacionales del lugar donde declara y realiza su actividad. En nuestro caso tratamos la legislación española y analizaremos los principales puntos que deberá tener en cuenta para saber si la página web se ve afectada. Básicamente se podría decir que si la web: - Realiza o es reflejo de una actividad mercantil -> Deberá cumplir la L.S.S.I. - Recoge datos personales de los usuarios mediante formularios -> Deberá cumplir la L.S.S.I. - Almacena datos personales de usuarios en bases de datos -> Deberá cumplir la L.O.P.D. Tras hacer un breve repaso por los apartados que debe cubrir un portal web, concretaremos aquellos puntos dentro de los cuales se encuentra encuadrada la plataforma a desarrollar y especificaremos en qué consisten dichos puntos. LSSI El portal web deberá estar bajo los auspicios de la L.S.S.I, tanto en cuento debe cubrir los siguientes objetos marcados por dicha ley: Todo servicio prestado normalmente a título oneroso, a distancia, por vía electrónica y a petición individual del destinatario. El concepto de servicio de la sociedad de la información comprende también los servicios no remunerados por sus destinatarios, en la medida en que constituyan una actividad económica para el prestador de servicios Son servicios de la sociedad de la información, entre otros y siempre que representen una actividad económica, los siguientes: La contratación de bienes o servicios por vía electrónica. La organización y gestión de subastas por medios electrónicos o de mercados y centros comerciales virtuales. La gestión de compras en la red por grupos de personas. El envío de comunicaciones comerciales. El suministro de información por vía telemática. El vídeo bajo demanda, como servicio en que el usuario puede seleccionar a través de la red, tanto el programa deseado como el momento de su suministro y recepción, y, en general, la distribución de contenidos previa petición individual. Ahondando en los servicios de la sociedad de la información se debe decir que: En el derecho de la Unión Europea, la definición legal de este tipo de servicios se halla en el apartado 2 del artículo 1 de la Directiva 98/34/CE, en su redacción modificada por la Directiva 98/48/CE. Se considera servicio de la sociedad de la información todo servicio prestado normalmente a cambio de una remuneración, a distancia, por vía electrónica y a petición individual de un destinatario de servicios. 101\n110 Lo que se pretende indicar con este requisito es que el servicio debe constituir una actividad de naturaleza económica para el prestador. Por tanto, son también servicios de la sociedad de la información los que se prestan gratuitamente y obtienen sus ingresos por otras vías, especialmente a través de la publicidad LSSICE Englobado dentro de la LSSI hay que hacer mención a la ley de antispam, la cual deja bajo las directrices de sus artículos a todos aquellos elementos informáticos que contravengan sus artículos: Artículo 20. Información exigida sobre las comunicaciones comerciales, ofertas promocionales y concursos. 1. Las comunicaciones comerciales realizadas por vía electrónica deberán ser claramente identificables como tales y deberán indicar la persona física o jurídica en nombre de la cual se realizan. En el caso en el que tengan lugar a través de correo electrónico u otro medio de comunicación electrónica equivalente incluirán al comienzo del mensaje la palabra «publicidad». 2. En los supuestos de ofertas promocionales, como las que incluyan descuentos, premios y regalos, y de concursos o juegos promocionales, previa la correspondiente autorización, se deberá asegurar, además del cumplimiento de los requisitos establecidos en el apartado anterior y en las normas de ordenación del comercio, que queden claramente identificados como tales y que las condiciones de acceso y, en su caso, de participación se expresen de forma clara e inequívoca. Artículo 21. Prohibición de comunicaciones comerciales no solicitadas realizadas a través de correo electrónico o medios de comunicación electrónica equivalentes. Queda prohibido el envío de comunicaciones publicitarias o promocionales por correo electrónico u otro medio de comunicación electrónica equivalente que previamente no hubieran sido solicitadas o expresamente autorizadas por los destinatarios de las mismas. LOPD La Ley Orgánica 15/1999 de 13 de diciembre de Protección de Datos de Carácter Personal, (LOPD), es una Ley Orgánica española que tiene por objeto garantizar y proteger, en lo que concierne al tratamiento de los datos personales, las libertades públicas y los derechos fundamentales de las personas físicas, y especialmente de su honor, intimidad y privacidad personal y familiar. Su objetivo principal es regular el tratamiento de los datos y ficheros, de carácter personal, independientemente del soporte en el cual sean tratados, los derechos de los ciudadanos sobre ellos y las obligaciones de aquellos que los crean o tratan. Partiendo de la esencia fundamental de dichas leyes, quedan redactados los principios fundamentales de las mismas y que son de obligado cumplimiento en el portal web a desarrollar: El Real Decreto 994/1999 de Medidas de Seguridad de los ficheros automatizados que contengan datos de carácter personal de 11 de junio de 1999 (RMS) : Es un reglamento que 102\n111 desarrolla la Ley Orgánica 5/1992, de 29 de octubre, de Regulación del Tratamiento Automatizado de los Datos de Carácter Personal (LORTAD), regula las medidas técnicas y organizativas que deben aplicarse a los sistemas de información en los cuales se traten datos de carácter personal de forma automatizada.(derogado desde 19 de abril de 2010) El Real Decreto 1720/2007, de 21 de diciembre de desarrollo de la Ley Orgánica de Protección de Datos. Se trata de un desarrollo de la Ley Orgánica 15/99 de Protección de Datos de 13 de diciembre; desarrolla tanto los principios de la ley, como las medidas de seguridad a aplicar en los sistemas de información. Se aplica tanto a ficheros en soporte automatizado, como en cualquier otro tipo de soportes. LPI La propiedad intelectual tiene que ver con las creaciones de la mente: las invenciones, las obras literarias y artísticas, los símbolos, los nombres, las imágenes y los dibujos y modelos utilizados en el comercio. Los derechos relacionados con el derecho de autor son los derechos de los artistas intérpretes y ejecutantes sobre sus interpretaciones y ejecuciones, los derechos de los productores de fonogramas sobre sus grabaciones y los derechos de los organismos de radiodifusión sobre sus programas de radio y de televisión. Teniendo identificados los motivos de la existencia de la propiedad intelectual, hay que concretar cuál de las dos ramas en las que se divide dicha ley, pertenece la actividad software a desarrollar. Para ello se mentara el artículo específico relacionado a la actividad a implementar: El derecho de autor, que abarca las obras literarias y artísticas, tales como las novelas, los poemas y las obras de teatro, las películas, las obras musicales, las obras de arte, como los dibujos, pinturas, fotografías y esculturas, y los diseños arquitectónicos. Se aplica a las creaciones artísticas como los poemas, las novelas, las obras musicales, las pinturas, las obras cinematográficas y los programas de ordenador. En inglés, a diferencia de los demás idiomas europeos, el derecho de autor se conoce con el nombre de copyright. El término copyright tiene que ver con actos fundamentales que, en lo que respecta a creaciones literarias y artísticas, sólo pueden ser efectuados por el autor o con su autorización. Se trata, concretamente, de la realización de copias de las obras literarias y artísticas, como los libros, las pinturas, las esculturas, las fotografías y las obras cinematográficas. Mientras, la expresión derecho de autor remite a la persona creadora de la obra artística, a su autor, subrayando así el hecho que se reconoce en la mayor parte de las leyes, en el sentido de que el autor goza de derechos específicos en relación con su creación, como el derecho a impedir la reproducción deformada de la misma, prerrogativa que sólo a él le pertenece, mientras que existen otros derechos, como el derecho a efectuar copias, del que pueden gozar terceros, por ejemplo, todo editor que haya obtenido una licencia del autor con ese fin. 103\n113 Anexo III: Manual de usuario A grandes rasgos, hay dos perfiles de audiencia claramente definidos a los que va dirigido este manual: el primero, integrado en su totalidad por los usuarios que acceden al portal para apoyar las propuestas, compuesto por aquellos que no necesitas o no tienen privilegios específicos dentro del portal; y el segundo, formado por los usuarios que pretenden crear propuestas y controlar las mismas. Por lo general, tanto los usuarios anónimos como los pertenecientes al portal, tienen escasos conocimientos técnicos, referentes al backend y la programación web, aunque sí un nivel considerable de experiencia en la navegación. Este manual pretende transmitir los conceptos y la estructura de la nueva web de votaciones para que cualquier usuario pueda sacar el máximo partido de ella. Estructura conceptual de la web de votos La reorganización de contenidos y reestructuración informativa, se ha basado en respetar al máximo la claridad visual y la simplicidad de uso, sin menospreciar contenido alguno, aumentando con ello la usabilidad global del sitio. En este sentido el principal hecho a destacar es la integración de las redes sociales a través de sus logotipos correspondientes aportando la necesidad existente en todos los portales de mantener la comunicación social. Existen 3 niveles de navegación: Navegación por menú: cumple con la función de menú principal homogénea en todas las vistas y es inamovible en las secciones públicas. Ésta recoge un total de cinco enlaces correspondientes a las principales secciones de la web. Cada uno de estos enlaces te conduce a la página donde se destacarán los contenidos más importantes. Navegación por redes sociales: es visible en la parte superior izquierda del portal y permite la integración en el mismo de las redes sociales más conocidas aportando un claro valor de sociedad. Está formado por cuatro enlaces distinguidos por los logotipos referentes en cada una de las redes sociales. Navegación de Propuestas: recoge los enlaces de acceso a algunos de los contenidos contextuales de varias secciones del menú principal. Esta muestra a su vez, navegación del contenido reinante en alguna de las secciones mostradas en el menú principal 105\n114 Estructura de la navegación por menú Como ya se ha comentado anteriormente, dentro del grupo de páginas principales se han creado unos menús especiales para cada uno de los usuarios del portal. En esta barra de menú correspondiente a la navegabilidad de un usuario anónimo en el portal nos encontraremos con los enlaces: - Inicio - Propuestas - Victorias - Crear Propuestas - Entrar 106\n115 La barra de menú siguiente nos muestra la estructura de la misma cuando el usuario es perteneciente al sistema, es decir cuando esta logueado en el mismo y puede acceder a secciones restringidas para los demás usuarios. - Inicio - Propuestas - Mis Propuestas - Victorias - Crear Propuestas - Salir Estructura de vista Propuestas y Victorias En estas vistas del portal se podrá observar la aparición de dos secciones que no existían en el portal principal y que permiten la navegabilidad y la comunicación e información de una forma ágil y sencilla. Los menús navegables serán: Menú de inicio sesión: este menú situado en la parte intermedia derecha permitirá mediante la autenticación en el mismo el acceso a los perfiles creados por los usuarios ya inscritos en el sistema. Menú de actividad reciente: cómo podemos observar es un menú el cual indica a los usuarios las diferentes actividades que se han sucedido en un corto espacio de tiempo en el portal y que están relacionadas con nuevas propuestas. 107\n116 Estructura de una propuesta Una vez encontrándonos en la vista interior de una propuesta, podremos observar cómo se divide en diferentes secciones para conformar una estructura homogénea y fácil de usar. La vista de una propuesta está conformada por cuatro secciones: Sección de Votación e Imagen: En esta sección se permite aportar un voto a la propuesta además de visualizar una imagen relacionada con la misma en conjunto a quien va dirigida Sección de Firma: aquí nos encontramos con la aportación más importante y que permite a los usuarios aportar su forma a través de sus datos a las propuestas que deseen apoyar. Sección de cuerpo: en este apartado se podrá leer el cuerpo de la propuesta y el motivo por el cual necesita el apoyo social. Sección de vitorias: en este apartado se podrá observar si el usuario ha alcanzado el objetivo propuesto cuando creo la propuesta. 108\n117 Estructura iniciar sesión Para poder tener efectuar aportar nuevas propuestas al portal, todo usuario debe de estar registrado en el sistema y por ende logueado dentro del mismo, por lo tanto es del todo imprescindible el uso de una sección de autenticación. La sección de autenticado está dividida en tres partes: Creación de cuenta: El usuario a través de los datos solicitados por el portal crea su cuenta de usuario en el sistema para poder acceder a los perfiles de las propuestas que ha creado o va a crear dentro del mismo. Iniciar sesión: El usuario que previamente ha creado su cuenta o que desea crear una petición y no se ha logueado requiere efectuar este paso previo para realizar la acción que desea. Solicitar contraseña: Previo requisito de seguridad esta sección permite a un usuario ya perteneciente al sistema recuperar o renovar la contraseña de usuario dentro del portal. 109\n118 Estructura de perfil de Propuestas Esta pantalla será la encargada del manejo de un perfil de propuestas y de la creación de una propuesta nueva y por ello se ha dividido en diferentes secciones para su mejor creación y modificación: El manejo de una propuesta se divide en seis secciones: - Nombre de la propuesta - A quien va dirigida la misma - Imagen de la propuesta - Cuerpo de la propuesta - Victoria de la propuesta - Tiempo en que expira la propuesta 110\nSistema de Gestión de procesos electorales en las organizaciones. Trabajo Fin de Grado. Escuela de Ingeniería Informática\nTrabajo Fin de Grado Escuela de Ingeniería Informática Universidad de Las Palmas de Gran Canaria Sistema de Gestión de procesos electorales en las organizaciones Carlos Aarón Villanueva Roca Las Palmas\nTrabajo Fin de Grado Escuela de Ingeniería Informática Universidad de Las Palmas de Gran Canaria Desarrollo de un sistema de videoconferencia en HTML 5.0 Autor: José Alberto Jinoria Fernández Tutor: Javier