La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

APLICACIÓN PARA EL ESTUDIO EN GRUPO DE PROBLEMAS COMPLEJOS

Presentaciones similares


Presentación del tema: "APLICACIÓN PARA EL ESTUDIO EN GRUPO DE PROBLEMAS COMPLEJOS"— Transcripción de la presentación:

1 APLICACIÓN PARA EL ESTUDIO EN GRUPO DE PROBLEMAS COMPLEJOS
Buenos días/tardes, con el permiso del tribunal voy a comenzar con la presentación del proyecto fin de carrera titulado “Aplicación para la resolución en grupo de problemas complejos”. Autor: Pablo Villaverde Masa Tutor: José Manuel Pérez Ríos Proyecto Fin de Carrera Universidad de Valladolid Mayo, 2011

2 Índice Escenario del proyecto. Objetivos.
Esquema general del Proyecto. Tecnología empleada. Demostración práctica. Pruebas. Conclusiones y posibles ampliaciones. La exposición del proyecto se seguirán las pautas indicadas en el siguiente índice: Comenzaré explicando el escenario en el que se desarrolla el proyecto. Para ello hablare de los procesos que se dan en esta aplicación, unas líneas generales de cómo funciona y una descripción del proyecto en que se basa esta versión del “Organizador de debates”. En los objetivo, concretaré los puntos que se han pretendido alcanzar al realizar este proyecto. En el apartado Esquema general del Proyecto describiré aspectos del análisis, modelado e implementación de la aplicación. Continuaré explicando las tecnologías usadas para después realizar una demostración práctica del funcionamiento del Organizador de debates. Después de esta prueba, haré un breve repaso a las pruebas realizadas y acabaré la presentación señalando las principales conclusiones que he sacado desarrollando este proyecto y posibles líneas futuras de desarrollo.

3 Índice Escenario del proyecto. Objetivos.
Esquema general del Proyecto. Tecnología empleada. Demostración práctica. Pruebas. Conclusiones y posibles ampliaciones. La exposición del proyecto se seguirán las pautas indicadas en el siguiente índice: Comenzaré explicando el escenario en el que se desarrolla el proyecto. Para ello hablare de los procesos que se dan en esta aplicación, unas líneas generales de cómo funciona y una descripción del proyecto en que se basa esta versión del “Organizador de debates”. En los objetivo, concretaré los puntos que se han pretendido alcanzar al realizar este proyecto. En el apartado Esquema general del Proyecto describiré aspectos del análisis, modelado e implementación de la aplicación. Continuaré explicando las tecnologías usadas para después realizar una demostración práctica del funcionamiento del Organizador de debates. Después de esta prueba, haré un breve repaso a las pruebas realizadas y acabaré la presentación señalando las principales conclusiones que he sacado desarrollando este proyecto y posibles líneas futuras de desarrollo.

4 Escenario del proyecto
Ámbito y alcance del proyecto Cliente: Departamento de Organización de Empresas, Comercialización e Investigación de Mercados. Necesidad: Crear una nueva aplicación para la resolución en grupo de problemas complejos. Organizador de Debates La nueva aplicación puede reutilizar conceptos de anteriores aplicaciones del Organizador de Debates. Este proyecto fin de carrera es propuesto desde el Departamento de Organización de Empresa, Comercialización e Investigación de Mercados. EL propósito es crear una nueva versión de una aplicación ya existente y en uso llamada Organizador de Debates. Para ello, se pretende actualizar el código de la aplicación, dándole una nueva estructura y añadir mejoras que satisfagan las nuevas necesidades que han ido surgiendo desde que se creara el programa.

5 Escenario del proyecto
Proceso generador de debates Para conocer mejor el propósito del organizador de debates, voy a explicar los conceptos y procesos que se aplican en el Organizador de Debates. Estos conceptos aparecen en el glosario de términos que hay en el final de la documentación. La aplicación sigue un proceso generador de debates, es decir, ayuda a sustentar la base de futuros debates obteniendo las ideas finales que se han de tratar en un futuro debate. Este proceso, se divide en varias fases o etapas y en cada una se realizan acciones diferentes. Para explicar las fases, antes voy a definir varios conceptos que ayudarán a entender este proceso. Una fase es cada una de las partes en las que se divide el debate en función del tiempo. Una idea es cualquier afirmación relevante referida al ámbito del tema de que trata el debate. Relacionada con la definición anterior, tenemos el concepto de idea agregada, o composición de ideas, que es la unión de varias ideas que pretende englobar una serie de aspectos a tratar y que contemplan detalles uno de los ámbitos del tema que trata el debate. Las ideas finales son aquellas ideas agregadas que han pasado por todo el proceso y que el supervisor del debate ha escogido entre las candidatas (elegidas por los usuarios) El proceso comienza en la fase 0, donde los usuarios aportan ideas al debates, permitiendo que otros usuarios puedan opinar sobre ellas. Una vez que hay suficientes ideas, se pasa a la fase 1. En esta fase, se empiezan a componer idea agregadas a partir de las ideas aportadas por los usuarios. Esta fase tiene la peculiaridad de ser iterativa, es decir una vez creadas las ideas agregadas a partir de las idea, se puede volver a iterar la fase permitiendo crear nuevas ideas agregadas no solo de las ideas existentes, si no de las ideas agregadas que hay ya expuestas. Una vez existan ideas agregadas suficiente, cada usuario podrá firmar, o da su apoyo a las ideas que crea convenientes con el fin de obtener un conjunto de ideas candidatas para ser finales. Si el proceso de firmas no es suficiente para llegar a un número de ideas candidatas manejable, se pasa a la fase 2. En esta fase, cada usuario dispone de unos votos que reparte entre las ideas que son más relevantes para el, ponderándolas con la cantidad de votos que crea necesaria. Una vez concretado el grupo de ideas candidatas y que el supervisor haya elegido las ideas finales, se pasa a la fase 3. Esta fase final expone las ideas finales resultantes de todo el proceso.

6 Escenario del proyecto
Líneas generales del funcionamiento del Organizador de Debates SUPERVISOR PARTICIPANTES MENSAJERIA: Mensajes entre usuarios,… DEBATE: Ideas, firmas, votos, comentarios,… USUARIO ANÓNIMO Ahora voy a explicar en líneas generales el funcionamiento base del organizador de debates creado en la primera versión. En este caso, un usuario anónimo se identificaba frente al sistema. Una vez identificado, pueden darse dos casos: El usuario es el administrador de la aplicación, lo cual le lleva a su panel de administración correspondiente donde se crean/borran los debates. El usuario pertenece al grupo de participantes del debate. Dentro de este grupo, puede ser que el identificado sea el supervisor que actua como moderador del debate y es capaz de concretar ciertos aspectos del debate. Estos participantes tendrán acceso a la mensajería que pone a disposición de la aplicación así como a las acciones correspondientes a las etapas del proceso generador de debates anteriormente explicadas. ADMINISTRADOR: Inicia los debates

7 Escenario del proyecto
Organizador de Debates v1.0 Basado en la primera aplicación del Organizador de Debates. Características: Un usuario Un debate. Un único tipo de debate. Asociación de una idea a un tema. Sistema de carros para ideas agregadas. Único tipo de encuesta. Poca claridad en el código. Este proyecto esta basado en el código de la primera versión del Organizador de Debates. Las principales características de la primera versión eran: Un usuario estaba restringido a un único debate. Si quería acceder a otro debate, debía crearse una cuenta nueva para poder acceder. Sólo existía un único tipo de debate, que contemplaba una única estructura y hacía que fuera poco atrayente para nuevos usuarios. Las ideas estaban clasificadas en tema, de tal forma que se podía agrupar en función del tema. Para crear ideas agregadas se seguía el sistema de carros, metáfora del carrito de la compra que en vez de artículos usa ideas.

8 Índice Escenario del proyecto. Objetivos.
Esquema general del Proyecto. Tecnología empleada. Demostración práctica. Pruebas. Conclusiones y posibles ampliaciones.

9 Índice Escenario del proyecto. Objetivos.
Esquema general del Proyecto. Tecnología empleada. Demostración práctica. Pruebas. Conclusiones y posibles ampliaciones.

10 Objetivos Modelo de usuarios. Nuevos tipos de debates.
Objetivos concretos Modelo de usuarios. Un usuario Varios debates. Dar acceso a todo tipo de usuarios. Sistema de permisos y credenciales Espectador – Participante – Supervisor Nuevos tipos de debates. Desarrollo: Completo o Parcial. Acceso: Público o Privado. Los objetivos propuestas para esta versión del Organizador de Debates pasan por: Re modelar el sistema de usuarios. El nuevo modelo debe permitir a un mismo usuario acceder a varios debates sin tener que cambiar de cuenta. Debe permitir que nuevos usuarios puedan ver el transcurso de los debates, sirviendo de “cebo” para que se unan y participen en el debate. Esto conlleva un sistema de permisos y credenciales para poder distinguir supervisor, participantes y espectadores del debate. Permitir personalizar el debate pudiendo distinguir 4 tipos: En función del número de fases e iteraciones, tendremos un debate completo (similar al antiguo modelo) o parcial, que no permite iteraciones ni votaciones. En función del acceso de los participantes, habrá debates público a los cuales podrá solicitar permiso para participar cualquier persona y debates privados, en que solo se podrá participar con previa invitación.

11 Objetivos Asociar las ideas a etiquetas (tags). Manejo de encuestas.
Objetivos concretos Asociar las ideas a etiquetas (tags). Navegabilidad entre ideas. Manejo de encuestas. Tipo: Recomendadas y Obligatorias. Sistema de ideas favoritas. Sustitución de los carros. Código con la estructura de Symfony. Cambiar la clasificación de temas por la de etiquetas o tags. Este permitirá mejorar las identificación de ideas y se podrá navegar entre ideas de temática similar El sistema contempla la realización de encuestas para evaluar los conocimientos de los usuarios. Debido al problema de que no toda la gente las contestaba se desea mejorar el sistema permitiendo crear encuestas obligatorias de realizar. El sistema de carros ha sido sustituido por un nuevo sistema fácil de manejar y de comprender. Migrar el código a la estructura del Framework Symfony. Al hacerlo, aumentará el grado de modularidad de la aplicación, así como su escalabilidad y su portabilidad. Además, la seguridad de las acciones y el uso de buenas prácticas como el patrón MVC estarán asegurdas. Mejorar la interfaz de la aplicación.

12 Índice Escenario del proyecto. Objetivos. Desarrollo del Proyecto.
Tecnología empleada. Demostración práctica. Pruebas. Conclusiones y posibles ampliaciones.

13 Índice Escenario del proyecto. Objetivos. Desarrollo del Proyecto.
Tecnología empleada. Demostración práctica. Pruebas. Conclusiones y posibles ampliaciones.

14 Desarrollo del proyecto
Planificación A continuación el diagrama de Gantt de seguimiento, para indicar que se ha seguido una planificación con unas fechas y unos objetivos. Las barras azules indican el tiempo estimado inicialmente para completar dicha tarea. Las barras rojas indican el tiempo real empleado en acometer dicha tarea. Analizando un poco la planificación se puede apreciar que las tareas que mayor tiempo han llevado son la de recopilar información y la implementación de la aplicación. También se puede apreciar cómo se han producido desviaciones en cuanto a lo planificado, fruto de diversas situaciones, todas ellas descritas en el plan de riesgos.

15 Desarrollo del proyecto
Modelo arquitectónico: Patrón Modelo-Vista-Controlador ADMINISTRADOR ESPECTADOR SUPERVISOR PARTICIPANTE Cliente INTERNET Petición VISTA Respuesta CONTROLADOR MODELO Servidor Modelo-Vista-Controlador (MVC) es un patrón de arquitectura software que separa la lógica de negocio (el modelo) y la presentación (la vista) por lo que se consigue un mantenimiento más sencillo de las aplicaciones. Si por ejemplo una misma aplicación debe ejecutarse tanto en un navegador estándar como un navegador de un dispositivo móvil, solamente es necesario crear una vista nueva para cada dispositivo; manteniendo el controlador y el modelo original. El controlador se encarga de aislar al modelo y a la vista de los detalles del protocolo utilizado para las peticiones (HTTP, consola de comandos, , etc.). El modelo se encarga de la abstracción de la lógica relacionada con los datos, haciendo que la vista y las acciones sean independientes de, por ejemplo, el tipo de gestor de bases de datos utilizado por la aplicación.

16 Desarrollo del proyecto
Diagrama de casos de uso Presentamos ahora los diagramas de casos de uso de la aplicación. En este diseño, los actores siguen una jerarquía en la cual, a medida que van consiguiendo permisos y credenciales, el número de acciones que pueden realizar aumenta. Como se puede ver, el usuario anónimo puede realizar unas acciones base que implican poder participar de forma pasiva en los debates. Una vez se identifique, como usuario registrado podrá acceder a los casos de uso relativos a la red social de mensajería. Si desea participar activamente de un debate , debe conseguir un permiso y así convertirse en un participante. Por último, si el administrador u otro supervisor lo desea, podrá ganar el último credencial disponible que le permitirá convertirse en supervisor y tener acceso a los casos de uso de supervisor. A parte, tenemos al administrador con las capacidades iniciar y terminar debates.

17 Desarrollo del proyecto
Diagrama de clases de diseño Se muestra los diagramas de clases de la aplicación. Divididos en tres paquetes, tenemos: (en cada paquete explicar las clases) el paquete de gestión de usuarios y red social. En este paquete, se representan la gestión de los distintos usuarios de la aplicación y la parte de red social referida al perfil de usuario, contactos y mensajes. El paquete de desarrollo del debate, en que se puede ver todas las clases que intervienen desde que el usuario entra en un debate hasta que sale. Como eje central de la aplicación tenemos la clase sfGuardUser que representaría al usuario y la clase debate, asociada con las entidades principales que permiten el proceso genrador de debates, ideas e ideas agregadas. El último paquete hace referencia a la administración.

18 Desarrollo del proyecto
Diseño de la base de datos: Mensajería y desarrollo del debate Para el diseño físico de la base de datos, tenemos el modelo de la mensajería y del desarrollo del debate Explicar tablas

19 ORGANIZADOR DE DEBATES
Desarrollo del proyecto Implementación PROYECTO ORGANIZADOR DE DEBATES APLICACIONES ADMEND FRONTEND PLUGINS DIRECTORIOS CONFIG MÓDULOS (2) LIB I18N (15) El proyecto Organizador de debates esta contruido con la estructura propuesta por Symfony. Esto permite crear varias aplicaciones bajo un proyecto. En este caso, FRONTED es la aplicación para los usuarios que desean participar en los debates, y el ADMEND es la aplicación exclusiva para la administración. En medio, tenemos las aplicaciones creadas por otro usuarios (plugins) pero que gracias a las propiedades de symfony, pueden ser añadidas a nuestro proyecto. Cada aplicación está compuesta por una serie de directorios representativos. El directorio CONFIG alberga todos los archivos de configuración de la respectiva aplicación. Desde configuración de vistas hasta el manejo de las factorías. En el directorio lib se almacena las librerías que los módulos llamarán para realizar operaciones ou obtener información. Por otro lado , el directorio i18n tiene el diccionario de idiomas de la aplicación si esta dispone de internacionalización. Por último, cada aplicación contiene los módulos necesarios para hacer funcionar la aplicación. Cabe destacar, que a nivel de proyecto, también existen directorios que son accesibles para todas las aplicaciones y que contiene desde los archivos web, las clases de modelo, hasta la configuración de la base de datos.

20 Índice Escenario del proyecto. Objetivos. Desarrollo del Proyecto.
Tecnología empleada. Demostración práctica. Pruebas. Conclusiones y posibles ampliaciones.

21 Índice Escenario del proyecto. Objetivos. Desarrollo del Proyecto.
Tecnología empleada. Demostración práctica. Pruebas. Conclusiones y posibles ampliaciones.

22 Tecnología empleada Servidor Web. Servidor de Base de Datos.
Lenguajes de programación y soportes Servidor Web. Servidor Apache vX.X Servidor de Base de Datos. MySQL vX.X Lenguaje de programación. PHP Javascript + AJAX + CSS Framework y Librerías Symfony v JQuery IDE: Netbeans 6.8 Una vez estudiados los requisitos de nuestro sistema llegamos a la conclusión de que la mejor tecnología que se adaptaba a nuestro sistema era la siguiente: Para la implementación del Servidor Web Apache 2.2 Para el de Base de Datos MySQL 5.0 El lenguaje de programación elegido PHP v5.2. Dado que el framework Symfony está en continua evolución y mejora utilizamos la última versión disponible que fuese estable, la 1.2 junto con el plugin SfGuardPlugin que nos permite implementar de manera efectiva la seguridad y el control de acceso a nuestro sistema. En cuanto la entorno de desarrollo Software se eligió Eclipse 3.3.2

23 Índice Escenario del proyecto. Objetivos. Desarrollo del Proyecto.
Tecnología empleada. Demostración práctica. Pruebas. Conclusiones y posibles ampliaciones.

24 Índice Escenario del proyecto. Objetivos. Desarrollo del Proyecto.
Tecnología empleada. Demostración práctica. Pruebas. Conclusiones y posibles ampliaciones.

25 Índice Escenario del proyecto. Objetivos. Desarrollo del Proyecto.
Tecnología empleada. Demostración práctica. Pruebas. Conclusiones y posibles ampliaciones.

26 Índice Escenario del proyecto. Objetivos. Desarrollo del Proyecto.
Tecnología empleada. Demostración práctica. Pruebas. Conclusiones y posibles ampliaciones.

27 Pruebas Pruebas de integración de sistema. Pruebas de privilegios.
Catálogo de pruebas Pruebas de integración de sistema. Sistemas operativos y navegadores. Pruebas de privilegios. Identificación y asociación de permisos Pruebas de funcionalidad. CRUD de formularios. Pruebas de casos límite. Pruebas de desarrollo del debate. Etapas y tipos de debate. En este apartado se explicarán de forma general el catálogo de pruebas realizadas a los distintos módulos del organizador de debates. La finalidad de las pruebas han sido detectar los posibles errores del código para su posterior corrección. Tenemos las pruebas de integración del sistema. En ellas, se han probado el funcionamiento en sistemas operativos de Windows y de Linux. También se ha probado el funcionamiento de la aplicación en tres navegadores de uso general como son internet explrer, mozilla firefoz y google chrome. El siguiente punto son las pruebas realizadas sobre los módulos para comprobar la seguridad de estos y el manejo de credenciales para el acceso por parte de los usuarios a las acciones que les están permitidas. Con las pruebas de funcionalidad se ha querido probar todas las operaciones de creación, lectura, borrado y actualización de los objetos de la aplicación. Por poner un ejemplo, la creación de un debate, así como su presentación en un listado, su borrado cuando acaba y la actualización de los parámetros para que un supervisor pueda personalizarlo. Gracias al framework de Symfony, no se han realizado apenas pruebas de caso límite ya que trae incorpora un mecanismo de validación que asegura que todos los posibles casos límite a la hora de realizar una operación va a estar controlado. Por último, con las pruebas de desarrollo del debate se ha querido comprobar que está bien implementado el proceso generador de debates en esta aplicación y todos los mecanismo que permiten llevarlo a cabo, como son el control de fechas, las funciones de firmar, votar y la restricción de inserción de ideas según las etapas.

28 Índice Escenario del proyecto. Objetivos. Desarrollo del Proyecto.
Tecnología empleada. Demostración práctica. Pruebas. Conclusiones y posibles ampliaciones.

29 Índice Escenario del proyecto. Objetivos. Desarrollo del Proyecto.
Tecnología empleada. Demostración práctica. Pruebas. Conclusiones y posibles ampliaciones.

30 Conclusiones y posibles ampliaciones
Objetivos logrados Sistema abierto a todo tipo de usuarios. Sistema seguro de permisos para debates. Personalización de debates a las necesidades del supervisor. Variedad de tipos de encuestas. Navegabilidad entre ideas con la misma etiqueta. Sistema de favoritos más cercano al usuario. Diseño modular, escalable y portable. Como conclusión, todos los objetivo propuestos al principio han sido realizados con éxito. Así pues se dispone de una aplicación con una interfaz actualizada. Junto a esto, el nuevo modelo de usuario permite a usuario anónimos investigar en los debates de tal forma que pueda servir de ‘’gancho’’ para animar a que se registren y participen de ellos. Para complementar el sistema de usuarios nuevo, hay un sistema de permisos y credenciales que asegura las acciones y evita que usuarios malintencionados accedan a contenidos restringidos. A nivel de debate, a mejorado la personalización de los debates pudiendo seleccionar el tipo de desarrollo y su privacidad. Además, se ha mejorado la herramienta de encuestas que anima a los usuarios a que las rellenen. Para las ideas, existe una nueva forma de navegar entre ideas de temática similar gracias a los tags, y además, se ha sustituido el sistema de carros por un sistema de favoritos que facilita la comprensión y manejo al usuario. Por último, la migración del código PHP al framework Symfony ha permitido crear un diseño modular más eficiente, lo cual ha dado pie a un diseño más portable y escalable para futuras mejoras.

31 Conclusiones y posibles ampliaciones
Nuevas funcionalidades de red social. Plugin SfSocial y SfGuard  Grupos y Eventos. Mejorar el sistema de favoritos guardando de forma permanente los favoritos en la base de datos. Un analizador sintáctico para la extracción de tags Mejora del modulo de i18n: Nuevos idiomas. Tras todo este trabajo y las mejoras implementadas, existen todavía puntos de los cuales partir para mejorar la aplicación. Uno podría ser aprovechar al completar las capacidades de los plugin sfSocial y sfGuard para ampliar la red social con grupos y eventos para los usuarios. En cuanto a las ideas, existe cabida a implementar un nuevo diseño que permita guardar las ideas favoritas de forma permanente en una base de datos. También, otra posible mejora, sería refinar el analizador sintáctico para la extracción de tags de una idea. Por último, se podrían añadir nuevos diccionarios de idiomas para ampliar el modulo de internacionalización de la aplicación.

32 Autor: Pablo Villaverde Masa Tutor: José Manuel Pérez Ríos
APLICACIÓN PARA el estudio EN GRUPO DE PROBLEMAS COMPLEJOS Gracias por su atención Gracias por su atención. Autor: Pablo Villaverde Masa Tutor: José Manuel Pérez Ríos Proyecto Fin de Carrera Universidad de Valladolid Mayo, 2011


Descargar ppt "APLICACIÓN PARA EL ESTUDIO EN GRUPO DE PROBLEMAS COMPLEJOS"

Presentaciones similares


Anuncios Google