MÁSTER EN INGENIERÍA WEB Proyecto Fin de Máster · MÁSTER EN INGENIERÍA WEB Proyecto Fin de...

UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos

MÁSTER EN INGENIERÍA WEB

Proyecto Fin de Máster

Editor de encuestas

Autor

David Chiva Villalba

Tutor Luis Fernando de Mingo López

Editor de encuestas

3 de julio de 2017

Editor de encuestas

AGRADECIMIENTOS

Agradezco a todos los profesores del Máster en Ingeniería Web su dedicación puesto que de cada uno de ellos me ha aportado algo positivo, y en general, a todos los profesores con los que me he encontrado a lo largo de mi trayectoria que viven con pasión la docencia y me han transmitido las ganas de seguir creciendo. Le doy las gracias también a mi familia y amigos porque sin ellos no podría afrontar los desafíos que se me plantean día a día con el mismo ímpetu. Finalmente, le doy las gracias especialmente a Carla, la mujer de mi vida. Gracias por apoyarme en las distintas decisiones de mi vida y por ser partícipe de mis momentos más felices. Te quiero.

Editor de encuestas

RESUMEN

En este documento se recogen los procesos realizados para desarrollar un proyecto para la asignatura PFM del Máster en Ingeniería Web de la Universidad Politécnica de Madrid. El proyecto consiste en una aplicación de encuestas que le permite al usuario crear encuestas, con diferentes versiones y preguntas de tres tipos diferentes, texto, selección única y selección múltiple. Además el usuario puede organizar las preguntas añadiendo condiciones, con el objetivo de generar varios posibles caminos, que llevarán al encuestado a una pregunta o a otra en función de sus respuestas. La aplicación también muestra los resultados de las contestaciones que ha tenido la encuesta en forma de estadísticas.

PALABRAS CLAVE Encuestas, PHP, CODEIGNITER, API

Editor de encuestas

ABSTRACT

This document includes the processes to develop a project for the PFM subject of the Master in Web Engineering of the Polytechnic University of Madrid. The project consists of a survey application that allows the user to create surveys, with different versions and questions of three different types, text, single selection and multiple selection. In addition the user can organize the questions by adding conditions, with the aim of generating several possible paths, which will lead the respondent to a question or another depending on their answers. The application also shows the results of the responses that have had the survey as statistics.

KEYWORDS Surveys, PHP, CODEIGNITER, API

Editor de encuestas

TABLA DE CONTENIDOS

1. Introducción

1.1. Contexto y motivación del proyecto 1.2. Objetivos del proyecto 1.3. Alcance

1.3.1. Alcance organizativo 1.3.2. Alcance informático 1.3.3. Alcance funcional

1.4. Restricciones del sistema

2. Descripción del proyecto

2.1. Características del proyecto 2.2. Tecnologías utilizadas

3. Planificación del proyecto

3.1. Metodología 3.2. Planificación 3.3. Estimación de recursos y costes del sistema

3.3.1. Recursos humanos 3.3.2. Recursos software 3.3.3. Recursos hardware 3.3.4. Costes del proyecto

4. Análisis del sistema

4.1. Casos de uso

4.1.1. Diagrama de casos de uso 4.1.2. Priorización de casos de uso 4.1.3. Especificación de casos de uso

5. Diseño del sistema

Editor de encuestas

5.1. Arquitectura del sistema 5.2. Modelo conceptual de datos 5.3. Diseño lógico de la base de datos 5.4. Diseño de las interfaces de usuario

6. Implementación y pruebas

6.1. Detalles de implementación 6.2. Verificación y validación

7. Bibliografía 8. Conclusiones

Editor de encuestas

OBJETIVOS

- Añadir una nueva aplicación al sistema wisclic que permita la creación de encuestas para recopilar el número máximo de datos sobre los potenciales clientes.

- Asentar los conocimientos adquiridos en el Máster en Ingeniería Web.

Editor de encuestas

CAPÍTULO 1

INTRODUCCIÓN

1.1 Contexto y motivación del proyecto El proyecto presentado en esta memoria se desarrolló durante el periodo correspondiente a la asignatura PFM del Máster en Ingeniería Web (MIW). Para comenzar, se empezará introduciendo el contexto del proyecto y los términos necesarios para la comprensión del proyecto. En primer lugar está Ideapp Solutions, un grupo con el cual colabora el autor de esta memoria, que se dedica principalmente a la creación de páginas web. El grupo está formado por 3 miembros, un estudiante de economía y marketing, encargado de todas las funciones relacionadas con el marketing, otro miembro con el grado de Ingeniería Informática, encargado del diseño de las interfaces de usuario y el último miembro, el autor de esta memoria, encargado del diseño de la arquitectura e implementación de los sistemas web. Ideapp Solutions dispone de un CRM propio en desarrollo, denominado wisclic, implementado en php con el framework Codeigniter. Antes de seguir se definirá el concepto de CRM, que proviene de las siglas en inglés Customer Relationship Manager, que no es más, que un sistema que permite gestionar la relación de una empresa con sus clientes. Actualmente parece imprescindible para las empresas disponer de un sistema de este tipo para conseguir almacenar la máxima información posible de cada cliente, consiguiendo así conocerlo mejor y tener una ventaja competitiva para incrementar las ventas. El sistema anteriormente mencionado tiene las funciones de crear nuevas tablas en la base de datos, nuevos campos para las tablas y relaciones entre tablas mediante una interfaz de usuario muy sencilla. Además el sistema permite diferenciar los diferentes

Editor de encuestas

perfiles o roles que se pueden encontrar en un sistema concreto otorgando a cada perfil los permisos que se deseen. Junto a las anteriores funciones mencionadas se pueden configurar formatos de página que permiten la generación automática de interfaces para realizar la inserción, modificación, lectura y borrado de los objetos correspondientes a las tablas creadas. El sistema también permite la creación de disparadores en php que se ejecuten antes o después de insertar, modificar o borrar un objeto. Se ha comentado la funcionalidad básica del sistema wisclic, pero a parte de esto, lo que convierte a wisclic en un sistema CRM son las aplicaciones extras de las que dispone. Actualmente se dispone de una aplicación de email marketing que permite la creación de plantillas de email mediante una sencilla interfaz basada en arrastrar y soltar (drag and drop), la creación de campañas de tipo email, el envío de dichas plantillas a un conjunto de usuarios añadidos a la campaña y posteriormente la visualización de qué usuario ha leído o hecho clic en algún enlace del email. Además wisclic también dispone de una versión básica de una aplicación de redes sociales que te permite ver, crear y eliminar publicaciones de twitter y facebook. La idea de la implementación de una nueva aplicación para el sistema wisclic que permite realizar encuestas, surge de la necesidad de los clientes (usuarios del sistema) por conocer las necesidades de sus clientes o la experiencia que han tenido al contratar sus servicios. Es por ello que este nuevo módulo le otorga mucho valor al sistema ya que va a permitir la recopilación de datos de una forma sencilla y fiable. Esta mejora va a permitir que poco a poco wisclic se vaya diferenciando de otros sistemas, y que por lo tanto, aumenten los usuarios que apuesten por él. 1.2. Objetivos del proyecto Los principales objetivos del proyecto son:

- Añadir una nueva aplicación al sistema wisclic que permita la creación de encuestas para recopilar el número máximo de datos sobre los potenciales clientes.

- Asentar los conocimientos adquiridos en el Máster de Ingeniería Web 1.3. Alcance del proyecto A continuación se definirán el alcance organizativo, el funcional y el informático.

Editor de encuestas

1.3.1. Alcance organizativo El alcance organizativo lo debemos dividir en interno de la organización y alcance externo de la organización. En cuanto al alcance organizativo interno, el sistema va a ser utilizado por los clientes del sistema wisclic que quieran añadir este módulo a sus sistema. Del alcance organizativo externo, en cambio, podemos decir que el sistema será utilizado por usuarios de todo tipo encargados de responder la encuesta. 1.3.2. Alcance funcional La aplicación de encuestas debe cumplir las siguientes funcionalidades:

- Crear, modificar y eliminar encuestas. - Crear, modificar versiones. - Permitir activar una versión. - Crear, modificar y eliminar preguntas. - Crear, modificar y eliminar opciones para las preguntas. - Ver estadísticas. - Organizar encuestas mediante un diagrama en el cual se pueden definir

diferentes caminos en función de diferentes condiciones - Responder encuesta.

1.3.3. Alcance informático En cuanto al alcance informático la aplicación a desarrollar deberá integrarse a la perfección con el sistema wisclic para permitir en el futuro añadirlo sin problema. Esto implica que a la hora de crear, modificar o eliminar registros han de utilizarse los métodos que proporciona el sistema wisclic. Además las interfaces de usuario deben seguir la línea de diseño de wisclic para que haya armonía en el diseño de la aplicación y que los usuarios puedan de forma muy intuitiva aprender a usar la aplicación de encuestas.

1.4. Restricciones del sistema

Editor de encuestas

Como ya se ha mencionado la aplicación de encuestas debe ser capaz de integrarse a la perfección con el sistema wisclic, es por ello, que todas las acciones de creación, modificación y borrado de datos de la base de datos se hagan utilizando los métodos que proporciona wisclic para insertar, actualizar y eliminar registros mediante la extensión del modelo IStandard_m. Además el diseño de las interfaces debe tener un estilo similar al estilo utilizado en el sistema wisclic.

Editor de encuestas

CAPÍTULO 2

DESCRIPCIÓN DEL PROYECTO

2.1. Características del proyecto Como ya se ha comentado previamente en la memoria, el proyecto consiste en el desarrollo de un sistema de encuestas, a continuación se detallará más concretamente en qué consiste el proyecto. En cuanto al desarrollo del sistema de encuestas se ha hecho pensando en las posibles necesidades de los futuros clientes. Es por eso, que cada encuesta debe poder ser activada o desactivadas por el cliente en función de sus necesidades. Además, es muy importante poder crear diferentes versiones de una encuesta para posteriormente poder analizar los resultados en función de la encuesta. El hecho de poder crear varias versiones de una encuesta no es para almacenar en cada versión configuraciones o preguntas diferentes sino para poder analizar diferentes etapas. Por ejemplo, si un cliente se dedica a realizar cursos online, puede tener una encuesta por cada curso, pero en el caso de modificar un curso puede crear una nueva versión de la encuesta para posteriormente poder analizar si el curso modificado ha tenido más éxito que el curso original. Cada encuesta no tendrá límite de preguntas y las preguntas podrán ser de tres tipos:

- Texto: Este tipo de preguntas será muy simple ya que simplemente se tendrá que almacenar una cadena de texto de longitud máxima de 1000 caracteres.

- Radio Button: Para una pregunta de este tipo el usuario deberá crear las opciones que desee para que posteriormente el encuestado pueda seleccionar una opción de entre todas las disponibles.

- Checkbox: Para este tipo de preguntas el usuario deberá crear las opciones que desee para que posteriormente el encuestado seleccione las opciones que desee.

El usuario creador de las encuestas podrá en cualquier momento crear, modificar o eliminar opciones para las preguntas de tipo Radio Button y Checkbox. Las opciones

Editor de encuestas

únicamente tendrán un campo identificador de tipo entero generado automáticamente y un campo texto de longitud 255. Una vez creadas las preguntas de una encuesta, estas pueden ser ordenadas mediante la creación de un diagrama compuesto por preguntas y condiciones, permitiendo así, poder generar diferentes caminos, que en función de las respuestas que vaya contestando un usuario le conducirán por uno u otro. Esta característica de la aplicación de encuestas es muy importante porque le permite a los usuarios del sistema poder obtener la información concreta que quieren de cada cliente o de cada tipo de cliente y por lo tanto se puede obtener una información muy bien segmentada. Además, por lo general los encuestados suelen abandonar la encuestas si cuentan con muchas preguntas y gracias a esta característica se puede conseguir preguntar a cada usuario las preguntas concretas obviando preguntas que no necesitemos obtener de un usuario en cuestión. En cuanto a la parte de los encuestados se debe permitir que contesten una encuesta, dirigiendolos por el camino de preguntas adecuado en función a sus respuestas. La interfaz de usuario de los encuestados debe ser muy sencilla para que les resulte muy fácil responder las encuestas y conseguir que no abandonen una encuesta. Además de lo anteriormente comentado se debe permitir que los usuarios encargados de realizar la encuesta tengan acceso a ver las estadísticas de cada encuesta. Estas estadísticas consistirán en la visualización del número total de encuestados, el número de encuestas respondidas completamente y el número de encuestas que no han sido respondidas hasta el final. En el caso de que exista algún encuestado que haya abandonado una encuesta también se mostrará el número medio de preguntas respondidas por usuario que ha abandonado la encuesta y un gráfico mostrando las respuestas en las cuales han ocurrido los abandonos y el número de abandonos en dichas preguntas. A parte de los datos comentados anteriormente también se mostrará una lista con las preguntas con alguna respuesta y el número de respuestas que ha obtenido cada pregunta. Si la pregunta es de tipo Radio Button o tipo checkbox se mostrará un gráfico indicando las opciones respondidas y el número de veces que ha sido elegida esa opción.

Editor de encuestas

2.2. Tecnologías y herramientas utilizadas Las tecnologías utilizadas son:

- HTML - JavaScript - AJAX - CSS - MYSQL - PHP - GIT

Para simplificar el desarrollo de código se ha utilizado el framework Codeigniter para el desarrollo en PHP ya que nos proporciona la implementación del patrón MVC y una arquitectura muy bien definida. Además de la librería JQuery para hacer más sencillo el desarrollo en JavaScript y AJAX. Para el estilo vamos a utilizar el framework bootstrap que proporciona una forma sencilla de realizar diseños responsive. Las últimas dos librerías que se van a utilizar son Chartjs para incluir gráficos dentro de la aplicación y jsPlumb un plugin JavaScript para la implementación de diagramas. Las herramientas empleadas en el desarrollo del proyecto son:

- Eclipse Neon PHP: Es una herramienta fundamental ya que es un entorno muy cómodo para el desarrollo de código PHP.

- Plugin e-git: Es un plugin para eclipse que permite una gestión sencilla, visual e

intuitiva del repositorio git.

- GITHUB: Brinda la posibilidad de almacenar en remoto el repositorio de código correspondiente al proyecto.

Editor de encuestas

CAPÍTULO 3

PLANIFICACIÓN DEL PROYECTO

3.1. Metodología En este proyecto no se ha seguido ninguna metodología en concreto, pero se podría decir que la metodología más próxima a la forma de trabajar ha sido una metodología tradicional en cascada. El hecho de ser la misma persona la que desea desarrollar un proyecto de software y la que realiza el proyecto facilita el uso de esta metodología puesto que desde un primer momento el desarrollador de software comprende a la perfección la funcionalidad que desea el cliente y los requisitos del sistema. El proyecto se comenzó definiendo los objetivos, el alcance, las restricciones del sistema, los posibles riesgos y describiendo el sistema deseado. Una vez definido todo lo anteriormente comentado se pasó al análisis de la aplicación, encontrando actores y casos de uso, priorizando dichos casos de uso y se especificaron los casos de uso para determinar las respuestas del sistema en función de las acciones del usuario. Una vez obtenidos los casos de uso, se definieron tareas un poco más concretas como por ejemplo, la creación de la base de datos, o la creación de un método en el controlador y otro en el modelo para un caso de uso concreto. Una vez finalizado el desglose de tareas se procedió al diseño del sistema, donde se definió la arquitectura del sistema, el modelo conceptual de datos en la base de datos y el diseño de las interfaces de usuario. Alcanzado este punto se pudo empezar con el desarrollo de la aplicación empezando por los casos de uso que tenían más prioridad. Finalmente una vez acabado el sistema se realizaron tests de aceptación para comprobar el buen funcionamiento del sistema.

Editor de encuestas

3.2. Planificación A continuación se muestra una tabla con las principales tareas del proyecto. Por simplicidad se ha decidido agrupar las tareas contenidas dentro de un caso de uso en una única tarea porque sino la tabla sería demasiado grande teniendo en cuenta que casi todos los casos de uso tienen varias tareas muy similares como una tarea para la creación de la ruta, otra para la creación del método en el controlador, otra para la creación de un método en el modelo y normalmente una tarea consistente en el desarrollo de la vista.

Identificador Nombre tarea Dependencias Tiempo estimado (h)

Tiempo real (h)

1 Inicio 6 6

1.1 Definir anteproyecto 2 2

1.2 Definir objetivos 1 1

1.3 Definir alcance 2 2

1.4 Definir restricciones del sistema

1 1

2 Análisis 26 31

2.1 Recopilación de casos de uso 1 5 5

2.2 Priorizar casos de uso 2.1 1 1

2.3 Especificación de casos de uso 2.1 20 25

3 Diseño 2 31 31

3.1 Definición de la arquitectura 5 5

3.2 Modelo conceptual de datos 6 6

3.3 Diseño de las interfaces de usuario

20 20

4 Implementación 3 180 218

4.1 Creación de la base de datos 1 1

Editor de encuestas

4.2 Creación de las tablas en la base de datos

7 7

4.3 Configuración básica del entorno de desarrollo

6 6

4.3.1 Creación del proyecto en eclipse

5 5

4.3.2 Vincular proyecto con repositorio git

1 1

4.4 Implementación de los casos de uso

4.4.1 CU02: Login 10 10

4.4.2 CU03: Crear encuesta 5 5

4.4.3 CU06: Listar encuestas 3 3

4.4.4 CU05: Eliminar encuesta 3 3

4.4.5 CU07: Ver encuesta 10 20

4.4.6 CU16: Crear versión 5 5

4.4.7 CU18: Activar versión 2 3

4.4.8 CU17: Modificar versión 5 5

4.4.9 CU10: Crear pregunta de encuesta

10 15

4.4.10 CU12: Eliminar pregunta de encuesta

3 3

4.4.11 CU11: Modificar pregunta de encuesta

5 5

4.4.12 CU19: Organizar preguntas - Cargar diagrama

10 15

4.4.13 CU20: Organizar preguntas - Añadir pregunta

5 7

4.4.14 CU21: Organizar preguntas - 10 15

Editor de encuestas

Añadir condición

4.4.15 CU23: Organizar preguntas - Nuevo diagrama

2 2

4.4.16 CU27: Organizar preguntas - relacionar elementos diagrama

5 5

4.4.17 CU25: Organizar preguntas - guardar diagrama

8 8

4.4.18 CU22: Organizar preguntas -Añadir ELSE

2 2

4.4.19 CU26: Organizar preguntas - eliminar elemento

6 6

4.4.20 CU24: Organizar preguntas - Ayuda

1 1

4.4.21 CU13: Crear opciones de pregunta

4 4

4.4.22 CU15: Eliminar opciones de pregunta

3 3

4.4.23 CU14: Modificar opciones de pregunta

5 5

4.4.24 CU01: Responder encuesta 15 20

4.4.25 CU08: Ver estadísticas de encuestas

15 20

4.4.26 CU09: Activar/Desactivar encuesta

3 3

4.4.27 CU04: Modificar encuesta 5 5

5 Pruebas 4 12 12

6 Elaboración de la memoria 50 70

TOTAL 305 368

Editor de encuestas

3.3. Estimación de recursos y costes del proyecto A continuación se detallarán los diferentes tipos de recursos utilizados, tanto para el desarrollo del proyecto como para la redacción de la memória. También se propondrá una estimación de los costes del proyecto. 3.3.1. Recursos humanos El desarrollo de este proyecto ha sido realizado exclusivamente por David Chiva, el autor de esta memoria. El tiempo estimado para la realización del proyecto entero, incluyendo la memoria, es de 305 horas. Mientras que el tiempo real es de 368 horas. 3.3.2. Recursos software Los recursos software son imprescindibles a la hora de llevar a cabo un proyecto y, en este caso, se han utilizado los siguientes:

- Servidor XAMPP - Eclipse - Plugin E-Git para eclipse - JSPLUMB versión gratuita - Chartjs - Diferentes navegadores (Google Chrome, Safary y Mozilla Firefox) - Google Docs para la redacción del proyecto - StarUML para la generación de diagramas.

3.3.3. Recursos hardware En cuanto a los recursos hardware solo se ha necesitado un ordenador tanto para el desarrollo del software como para la realización de la memória. Ordenador:

- Procesador: Intel core i7 - Memoria Ram: 8 GB - Sistema operativo: Os X El Capitán

En este caso, no se ha necesitado ningún recurso hardware extra porque el sistema wisclic ya dispone de un servidor online.

Editor de encuestas

Además del ordenador se habría necesitado contratar un servicio de alojamiento web (hosting) y un dominio para poder hacer accesible desde la web la aplicación realizada. Pero como el proyecto que se ha realizado es una aplicación para el sistema wisclic, no es necesario contratar un dominio específico ni un alojamiento web ya que wisclic ya está alojado en un servidor online y tiene contratado su dominio. 3.3.4. Costes del proyecto Determinar los costes del proyecto siempre es una tarea compleja puesto que hay muchos factores a tener en cuenta. Como este proyecto ha sido realizado como una mejora interna no ha supuesto un coste económico, simplemente temporal, pero aún así se estimará el precio del proyecto como si el desarrollo se hubiera hecho para un tercero, con el objetivo de poder evaluar el coste económico de un proyecto con estas características. A la hora de obtener el coste económico del desarrollo simplemente se va a tener en cuenta el coste temporal de la realización del proyecto multiplicado por el precio por hora de desarrollo, que en este caso será de 5 euros por hora. Tras hacer cálculos se obtiene que el desarrollo del proyecto habría costado 1275 euros atendiendo a las horas estimadas, ya que las horas estimadas han sido 255 (sin las horas de desarrollo de la memoria). En el caso de querer obtener el coste económico real del proyecto se deberá multiplicar los 5 euros por hora por las 298 horas de desarrollo reales, lo que daría como resultado 1490 euros. Por lo tanto se puede afirmar que en el desarrollo de este proyecto se habrían perdido 215 euros, que a priori, no es una gran diferencia pero errores como los cometidos en un proyecto más grande con salarios más altos podría hacerle perder a una empresa mucho dinero. Aunque no se ha necesitado contratar el alojamiento web y el dominio, se incluirá una tarifa básica para que se pueda ver cuanto se le debería cobrar a cada cliente mínimo para no perder dinero. Ya que el sistema wisclic le proporciona a sus clientes una base de datos independiente y un dominio personalizado. Una tarifa básica que incluya un servidor php, una base de datos mysql y un dominio personalizado en una empresa como Loading costaría 46’80 euros (sin iva), lo que sería 56’60 euros (con iva) anualmente.

Editor de encuestas

En el caso de querer recuperar el dinero invertido en tiempo en el proyecto de encuestas se le debería cobrar un dinero extra al mes a cada usuario que desee tener la aplicación de encuestas. Supondremos que vamos a tener 10 clientes y que queremos recuperar la inversión en 3 años. Por lo tanto tendríamos que dividir los 1510 euros invertidos en tiempo real entre el número de cuotas que cobraremos (10*3*12=360), con lo que obtenemos que se le debería cobrar al cliente 4,15 euros al mes. Si además de lo anteriormente mencionado se le suma la tarifa de hosting y dominio, el precio mensual por cliente sería de 8,87 euros al mes por cliente.

Editor de encuestas

CAPÍTULO 4

ANÁLISIS DEL SISTEMA El análisis de la aplicación ha consistido en la definición de los casos de uso, la priorización de estos a la hora de desarrollarlos y la especificación de cada caso de uso que se ha elaborado mediante diagramas de actividad. 4.1. Casos de Uso Los casos de uso es una parte muy importante del análisis ya que permite definir las principales funciones que debe cumplir un sistema y los actores que intervienen en dichas acciones. En esta aplicación los actores que intervendrán son el usuario formulador de las encuestas que es el usuario que tendrá acceso a la mayor parte de la funcionalidad del sistema (27 CU) y el actor encuestado que es el usuario que solamente tendrá acceso a responder la encuesta. Los casos de uso obtenidos han sido los siguientes:

- CU01:Responder encuesta - CU02: Login - CU03: Crear encuesta - CU04: Modificar encuesta - CU05: Eliminar encuesta - CU06: Listar encuestas creadas - CU07: Ver encuesta - CU08: Ver estadísticas de encuesta - CU09: Activar/Desactivar encuesta - CU10: Crear pregunta de encuesta - CU11: Modificar pregunta de encuesta - CU12: Eliminar pregunta de encuesta - CU13: Crear opciones de pregunta - CU14: Modificar opciones de pregunta - CU15: Eliminar opciones de pregunta

Editor de encuestas

- CU16: Crear versión - CU17: Modificar versión - CU18: Activar versión - CU19: Organizar preguntas - Cargar diagrama - CU20: Organizar preguntas - Añadir pregunta - CU21: Organizar preguntas - Añadir condición - CU22: Organizar preguntas - Añadir else - CU23: Organizar preguntas - Nuevo diagrama - CU24: Organizar preguntas - Ayuda - CU25: Organizar preguntas - Guardar diagrama - CU26: Organizar preguntas - eliminar elemento diagrama - CU27: Organizar preguntas - relacionar elementos diagrama - CU28: Exportar informe de las respuestas obtenidas en una encuesta

Editor de encuestas

4.1.1. Diagrama de casos de uso

Imagen DCU01: Diagrama de casos de uso

Editor de encuestas

4.1.2. Priorización de casos de uso

Para llevar a cabo la priorización de los casos de uso se ha tenido en cuenta que el desarrollo se ha realizado por una sola persona y que por lo tanto no se podían avanzar tareas en paralelo. Por ello, para agilizar el desarrollo del proyecto evitando tener que generar mocs el orden seguido a la hora de la realización de los casos de uso ha sido el siguiente:

- CU02: Login - CU03: Crear encuesta - CU06: Listar encuestas - CU05: Eliminar encuesta - CU07: Ver encuesta - CU16: Crear versión - CU18: Activar versión - CU17: Modificar versión - CU10: Crear pregunta de encuesta - CU12: Eliminar pregunta de encuesta - CU11: Modificar pregunta de encuesta - CU19: Organizar preguntas - Cargar diagrama - CU20: Organizar preguntas - Añadir pregunta - CU21: Organizar preguntas - Añadir condición - CU23: Organizar preguntas - Nuevo diagrama - CU27: Organizar preguntas - Relacionar elementos diagrama - CU25: Organizar preguntas - Guardar diagrama - CU22: Organizar preguntas - Añadir ELSE - CU26: Organizar preguntas - Eliminar elemento - CU24: Organizar preguntas - Ayuda - CU13: Crear opciones de pregunta - CU15: Eliminar opciones de pregunta - CU14: Modificar opciones de pregunta - CU01: Responder encuesta - CU08: Ver estadísticas de encuestas - CU09: Activar/Desactivar encuesta - CU04: Modificar encuesta

Editor de encuestas

4.1.3. Especificación de casos de uso

Para la especificación de casos de uso, como ya se ha comentado, se ha realizado un diagrama de actividad para cada caso de uso con el objetivo de poder definir cómo debe comportarse el sistema ante las diferentes situaciones.

CU01:Responder encuesta

Imagen DCU02: Diagrama de actividad caso de uso CU01

Editor de encuestas

CU02: Login

Imagen DCU03: Diagrama de actividad CU02

Editor de encuestas

CU03: Crear encuesta


Editor de encuestas

CU04: Modificar encuesta


Editor de encuestas

CU05: Eliminar encuesta


Editor de encuestas

CU06: Listar encuestas creadas


CU07: Ver encuesta


Editor de encuestas

CU08: Ver estadísticas de encuesta


Editor de encuestas

CU09: Activar/Desactivar encuesta


Editor de encuestas

CU10: Crear pregunta de encuesta


Editor de encuestas

CU11: Modificar pregunta de encuesta


Editor de encuestas

CU12: Eliminar pregunta de encuesta


Editor de encuestas

CU13: Crear opciones de pregunta


Editor de encuestas

CU14: Modificar opciones de pregunta


Editor de encuestas

CU15: Eliminar opciones de pregunta


Editor de encuestas

CU16: Crear versión


Editor de encuestas

CU17: Modificar versión


Editor de encuestas

CU18: Activar versión


Editor de encuestas

CU19: Organizar preguntas - Cargar diagrama


Editor de encuestas

CU20: Organizar preguntas - Añadir pregunta


Editor de encuestas

CU21: Organizar preguntas - Añadir condición


Editor de encuestas

CU22: Organizar preguntas - Añadir else


CU23: Organizar preguntas - Nuevo diagrama


Editor de encuestas

CU24: Organizar preguntas - Ayuda


Editor de encuestas

CU25: Organizar preguntas - Guardar diagrama


Editor de encuestas

CU26: Organizar preguntas - eliminar elemento diagrama


Editor de encuestas

CU27: Organizar preguntas - relacionar elementos diagrama


Editor de encuestas

CAPÍTULO 5

DISEÑO DEL SISTEMA

En este capítulo se describirán la arquitectura del sistema, el modelo conceptual de datos, el diseño lógico de la base de datos y el diseño de las interfaces de usuario. 5.1. Arquitectura del sistema La arquitectura del sistema viene marcada por el framework utilizado, Codeigniter, que lleva implícito el patrón MVC (modelo-vista-controlador) y por algunas modificaciones hechas sobre el framework para el sistema wisclic que permiten que se puedan diferenciar los clientes dentro del sistema. Cuando empezamos un proyecto desde cero en Codeigniter podemos ver dos paquetes bien diferenciados “system” y “application”. El primer paquete está destinado a los archivos base del framework donde se encuentran los archivos necesarios para la funcionalidad que proporciona Codeigniter, un paquete que no se debe modificar. El segundo paquete, application, es donde se debe trabajar y donde se colocarán todos los desarrollos. Este paquete consta a su vez de diferentes paquetes:

-Models: Este paquete contendrá todas las clases correspondientes al modelo. Las clases de este paquete serán las encargadas de acceder a la base de datos. -Controllers: Este paquete contendrá todas las clases correspondientes a los controladores. Las clases de este paquete serán las encargadas de utilizar los modelos para la lectura, creación, modificación y borrado de datos y de cargar las vistas correspondientes.

-Views: Este paquete contiene todas las clases correspondientes a las vistas, es decir, el código html, css y javascript. Los controladores pueden inyectarle variables a las vistas para poder hacer aplicaciones dinámicas. Las vistas no

Editor de encuestas

deberían hacer llamadas a métodos del controlador ni del modelo. Si se requiere funciones para utilizar en varias vistas se debería almacenar en la carpeta helpers o libraries.

-Config: Este paquete contiene todos los ficheros de configuración. Los ficheros más destacados son:

· Config: Este fichero sirve para configuraciones generales de la

aplicación como por ejemplo la ruta base de la aplicación.

· Routes: Sirve para definir las rutas accesibles en nuestra aplicación y relacionarlas con métodos de los controladores. Las rutas aceptan elementos dinámicos de tipo texto (:any) y numérico (:num) que después se pueden inyectar como parámetros en los métodos del controlador. Un ejemplo de ruta definida sería: $route[‘encuesta/(:num)’]=’controlador/metodo1/$1’;

· Database: Sirve para definir la configuración de la base de datos a

utilizar.

· Constants: Sirve para definir constantes que después se utilizarán en el resto de aplicación.

· Autoload: Este fichero sirve para definir qué clases deben ser cargadas

directamente por el sistema al iniciar la aplicación.

· Hooks: Este fichero de configuración se utiliza para definir los aspectos de la aplicación, es decir, con este fichero podemos definir qué métodos deben ejecutarse en un momento concreto de la aplicación (Antes de cargar el controlador, después de cargarlo, antes de cargar el sistema...). Gracias a los hooks se puede administrar de forma sencilla las zonas privadas y públicas de una aplicación.

-Helpers: Este paquete sirve para almacenar funciones auxiliares de la aplicación, es como un conjunto de útiles que pueden reutilizarse fácilmente entre aplicaciones. Los helpers son clases con métodos independientes pero con un ámbito común.

Editor de encuestas

-Libraries: Este paquete sirve para almacenar funciones auxiliares de la aplicación, es como un conjunto de útiles que pueden reutilizarse fácilmente entre aplicaciones. Las libraries se diferencian de los helpers en que los métodos de las libraries comparten información común mientras que los métodos de los helpers son independientes, es decir, no requieren información común.

-Hooks: Este paquete sirve para almacenar los hooks. Un hook es una clase que contiene un conjunto de métodos que se utilizarán como aspectos en la aplicación.

A pesar de que en este proyecto no influyen en gran medida los cambios en el framework para adaptarlo al modelo de negocio de wisclic, se van a comentar brevemente. Por las necesidades del sistema wisclic se necesita en todos los proyectos un conjunto de clases iguales, como por ejemplo, las que proporcionan la funcionalidad de email marketing, pero también se requiere un conjunto de clases distintas para permitir el

Editor de encuestas

desarrollo de funcionalidades extra dentro del sistema o el desarrollo de la página web del cliente. Además, cada cliente, debe disponer de su propia base de datos y de su propio dominio. Por eso, la extensión del framework Codeigniter consiste en la creación de un nuevo paquete denominado “Sites” dentro del cual se encuentra un paquete por cada cliente con los siguientes subpaquetes:

-Models: Este paquete contiene los modelos del cliente concreto.

-Views: Este paquete contiene las vistas del cliente concreto

-Controllers: Este paquete contiene los controladores del cliente concreto. -Config: Este paquete contiene las configuraciones concretas de cada cliente,

como por ejemplo, la base de datos, las rutas, las constantes y un fichero para determinar a qué aplicaciones tiene acceso cada cliente.

-Files: Este paquete contiene todos los archivos extra del cliente (Imagenes, videos, pdfs, archivos css, archivos javascript...). Para conseguir relacionar cada dominio con el paquete concreto al que debe apuntar existe un fichero en el paquete “Config” estándar denominado “sites” en el cual se debe definir el nombre de dominio y el paquete al que apuntan. Esta arquitectura permite tener el sistema wisclic y todos sus clientes en un mismo servidor de una forma muy organizada, ya que cada cliente tiene todos sus ficheros muy localizados. Además esta arquitectura permite que las actualizaciones del núcleo de wisclic sean sencillas, ya que solo se debe actualizar un servidor y no uno por cada cliente. De esta forma el equipo de desarrolladores puede centrarse en desarrollar nuevas aplicaciones o funcionalidades para el sistema en lugar de en el mantenimiento. Como se ha comentado anteriormente estos cambios en la arquitectura no afectan al desarrollo de la aplicación de encuestas, ya que esta nueva funcionalidad formará parte de todos los proyectos. Por lo tanto, solo utilizaremos los paquetes base de Codeigniter puesto que son estos las que almacenan las funcionalidades comunes del sistema wisclic.

Editor de encuestas

Editor de encuestas

5.2. Modelo conceptual de datos A continuación se mostrarán las diferentes tablas que han sido propuestas para la solución de almacenamiento de los datos de la aplicación de encuestas:

ISystem_surveys: Esta tabla se utilizará para almacenar las encuestas.

ISystem_surveys_versions: Esta tabla se utilizará para almacenar las versiones de las encuestas. Para saber cual es la versión activa, se utilizará un campo en esta tabla para evitar un ciclo.

ISystem_surveys_questions: Esta tabla se utilizará para almacenar las preguntas de las encuestas.

ISystem_surveys_options: Esta tabla se utilizará para guardar las opciones de cada pregunta.

ISystem_surveys_surveyed: Esta tabla se utilizará para almacenar los datos generales de un encuestado.

ISystem_surveys_responses: Esta tabla se utilizará para almacenar las respuestas de los encuestados a las preguntas. Si el encuestado puede seleccionar varias opciones en una pregunta se debe almacenar un registro por cada opción seleccionada.

ISystem_permissions_users: Esta tabla se utilizará para almacenar los usuarios con acceso a la parte de gestión de encuestas.

Editor de encuestas

Editor de encuestas

5.3. Diseño lógico de la base de datos Para obtener el diseño lógico de la base de datos se ha utilizado directamente la herramienta de diseñador de phpMyAdmin. Como se puede observar en la imagen la tabla ISystem_permissions_users esta relacionada con el resto de tablas puesto que en el sistema wisclic siempre se almacena el usuario creador del registro y el usuario que lo ha modificado.

5.4. Diseño de las interfaces de usuario El diseño de las interfaces se ha realizado pensando en la usabilidad y la agilidad para realizar las diferentes funcionalidades del sistema. Es por ello, que se han planteado unas interfaces principales de tipo SPA (Single Page Application) que permitan realizar más de una funcionalidad sin tener que recargar la página constantemente. Las interfaces principales son:

Editor de encuestas

- Listar encuestas: ● Listar encuestas ● Ir a una encuesta ● Eliminar una encuesta ● Crear una encuesta

- Ver encuesta:

● Ver encuesta ● Modificar encuesta ● Ver versiones ● Crear y modificar versiones ● Activar una versión ● Ver, crear, modificar una pregunta ● Listar, añadir, modificar y eliminar opciones de pregunta. ● Ir a organizar preguntas ● Ir a ver estadísticas ● Ir a listar encuestas

- Organizar encuestas:

● Cargar diagrama ● Nuevo diagrama ● Guardar diagrama ● Añadir pregunta a diagrama ● Añadir condición a diagrama ● Añadir ELSE a diagrama ● Relacionar elementos del diagrama ● Eliminar elementos del diagrama ● Ayuda

- Ver estadísticas

● Ver estadísticas ● Exportar informe

- Responder encuesta

● Responder encuesta

Editor de encuestas

El diseño de la interfaz principal de listar encuestas, como se puede apreciar en la imagen DI01, es muy sencillo. Consta de una tabla donde cada fila corresponde a una encuesta. Cada una de estas filas consta de dos botones, uno para dirigirse a ver la encuesta y otro para eliminar la encuesta. A la hora de eliminar encuestas es muy importante solicitar confirmación al usuario, como se puede apreciar en la imagen DI02, puesto que si el usuario le diera por error al botón eliminar y no existiera esta confirmación podría perder muchos datos y horas de trabajo. Además de lo anteriormente comentado, en esta interfaz podemos encontrar un botón que nos permite crear nuevas encuestas mediante un modal, dicho modal puede apreciarse en la imagen DI03.

Imagen DI01: Interfaz listar encuestas.

Imagen DI02: Confirmación eliminar encuesta

Editor de encuestas

Imagen DI03: Modal para la creación de encuestas

El diseño de la interfaz principal ver encuestas, que podemos ver en la imagen DI04, está pensado para que de forma muy dinámica se pueda modificar el contenido principal de una encuesta, es decir, la versión y las preguntas. Si se hace clic sobre el icono del ojo situado junto a la versión actual se abrirá un modal como el que aparece en la imagen DI05 donde de forma muy rápida se podrán ver las versiones de la encuesta, la versión activa (que podrá ser cambiada haciendo clic en el icono de la columna activa de la versión que se quiera activar), se podrá añadir una nueva versión rellenando el campo de texto y haciendo clic en el botón con un signo más y finalmente se podrá editar el nombre de una versión haciendo clic en el icono del lápiz, que cambiará la interfaz mostrando en el modal una interfaz como la que aparece en la imagen DI06. Si el usuario hace clic sobre el botón añadir pregunta se abrirá un modal como el de la imagen DI07, donde se aprecia un botón con el texto “Añadir”, si el usuario selecciona un tipo que incluya opciones el texto de dicho botón cambiará a “Siguiente” como se puede apreciar en la imagen DI08 para que el usuario pueda introducir las opciones de la pregunta antes de finalizar como se puede apreciar en las imágenes DI09 y DI10.

Editor de encuestas

Además al añadir opciones antes de finalizar la pregunta, si se ha puesto una opción incorrecta se puede eliminar mediante el botón con el texto “x” que se observa en la imagen DI10. En el caso de querer ver los detalles de las preguntas se deberá hacer clic sobre el botón “Ver” que hay en la fila de la pregunta, que nos abrirá un modal con todos los detalles de la pregunta como se puede observar en la imagen DI11 si la pregunta no tiene opciones o como en la imagen DI13 en el caso de que la pregunta tenga opciones. En el caso de querer editar una pregunta simplemente se deberá hacer clic en el botón “Editar” que mostrará un modal como el de la imagen DI12. En el caso de querer eliminar opciones de una pregunta simplemente se deberá hacer clic en el icono “x”, que puede verse en la imagen DI13, y para añadir y modificar opciones el funcionamiento es igual que en las versiones, puede apreciarse en las imágenes DI13 y DI14.

Imagen DI04: Interfaz de ver encuesta

Editor de encuestas

Imagen DI05: Listar y añadir versiones.

Editor de encuestas

Imagen DI06: Editar versión

Editor de encuestas

Imagen DI07: Modal de añadir pregunta

Editor de encuestas

Imagen DI08: Modal de añadir pregunta al seleccionar un tipo con opciones

Imagen DI09: Modal de añadir pregunta al seleccionar siguiente

Editor de encuestas

Imagen DI10: Modal de añadir pregunta con opciones

Imagen DI11: Modal de ver pregunta sin opciones

Editor de encuestas

Imagen DI12: Modal de editar pregunta

Editor de encuestas

Imagen DI13: Modal de ver pregunta con opciones

Editor de encuestas

Imagen DI14: Modal de ver pregunta editando una opción

La siguiente interfaz importante es la de organizar preguntas ya que se basa en la creación de un diagrama mediante un editor que permite añadir preguntas, añadir condiciones, añadir condición else, empezar el diagrama de nuevo, solicitar ayuda y guardar el diagrama. Por defecto, como solo se permite un diagrama por encuesta, se carga el diagrama correspondiente a la encuesta seleccionada. En la imagen DI16 podemos ver el modal para añadir una pregunta al diagrama. Simplemente se le pregunta al usuario que pregunta desea añadir entra las preguntas disponibles en la encuesta.

Editor de encuestas

En la imagen DI17 podemos observar el modal que aparece al solicitar añadir una condición al diagrama. Se pueden apreciar tres selectores, uno con las preguntas que su tipo admite opciones, otro con el comparador que se desea y un último selector, que se carga dinámicamente en función del primer selector, donde aparecen las opciones disponibles. Además si se desea aplicar condiciones más complejas se puede hacer clic en el botón “+” que dará como resultado una interfaz como la de la imagen DI18. Se pueden incrementar las condiciones lo que se desee sin número máximo de veces que se puede hacer clic sobre el botón “+”. Con el botón “-” se eliminará la última condición añadida. Como se puede observar una solución que permite crear condiciones complejas de forma muy intuitiva. En el caso de seleccionar el signo de interrogación que se aprecia en la imágen DI15, aparecerá un modal como el de la imágen DI19 con información de cómo usar el editor de diagramas. Finalmente para eliminar un elemento del diagrama se ha optado por añadir un menú al hacer clic derecho sobre el elemento en cuestión que muestra las opciones disponibles, en este caso, simplemente la opción de eliminar, como puede apreciarse en la imagen DI20.

Imagen DI15: Editor para organizar preguntas

Editor de encuestas

Imagen DI16: Modal para añadir pregunta al diagrama

Imagen DI17: Modal para añadir condición

Editor de encuestas

Imagen DI18: Modal para añadir condición con varias condiciones

Imagen DI19: Modal con texto de ayuda para el uso del editor de diagramas

Editor de encuestas

Imagen DI20: Menú que aparece con botón derecho sobre elemento

A continuación se muestran un conjunto de imágenes correspondientes a la interfaz principal de responder encuestas donde se puede ver la primera interfaz donde el usuario pulsa el botón “iniciar encuesta” (Imagen DI21), otra imagen, la DI22, donde se puede ver como se muestra un error en caso de no haber respondido correctamente la pregunta, otra imagen, la DI23, que muestra una pregunta de tipo selección múltiple donde se puede apreciar como la barra de progreso va avanzando a medida que se van superando preguntas y finalmente se puede observar la imagen DI24 donde se muestra la interfaz de encuesta finalizada.

Editor de encuestas

Imagen DI21: Iniciar encuesta

Editor de encuestas

Imagen DI22: Mensaje de error al no responder una pregunta

Editor de encuestas

Imagen DI23: Pregunta de tipo selección multiple (checkbox)

Editor de encuestas

Imagen DI24: Finalización de encuesta

Editor de encuestas

Imagen DI25: Interfaz de Login

El último diseño que falta por mostrar es el correspondiente a la interfaz de ver estadísticas (Imagen DI26), que consta de una cabecera donde se puede ver de un vistazo los usuarios que han contestado la encuesta y los que no han finalizado la encuesta. En el caso de haber algún usuario que no haya finalizado la encuesta se puede ver un gráfico que muestra la última pregunta que ha respondido el usuario y el número de usuarios que ha abandonado en esa pregunta, también se muestra la media de respuestas que responde un encuestado que abandona la encuesta (puede observarse en la imagen DI27). Por cada pregunta que tiene al menos una respuesta el sistema muestra el número de respuestas y en el caso de ser una pregunta con opciones se muestra un gráfico de las opciones seleccionadas por los usuarios (Imagen DI28).

Editor de encuestas

Imagen DI26: Interfaz de estadísticas

Editor de encuestas

Imagen DI27: Gráfico que muestra las últimas preguntas contestadas por los usuarios que no han acabado la encuesta

Editor de encuestas

Imagen DI28: Gráfico que muestra las opciones elegidas por el encuestado

Editor de encuestas

CAPÍTULO 6

IMPLEMENTACIÓN Y PRUEBAS

6.1. Detalles de implementación Como ya se ha comentado previamente las tecnologías utilizadas para el desarrollo del proyecto han sido, por el lado del servidor, PHP sobre el framework Codeigniter, utilizando una base de datos MYSQL, y por el lado del cliente ha sido desarrollado con HTML, CSS utilizando el framework Bootstrap, AJAX y JavaScript utilizando la librería JQuery. A continuación se va a redactar los detalles de implementación y para ello se va a empezar comentando las rutas definidas para este proyecto y después se explicarán los detalles relacionados a la implementación de alguna de estas rutas, ya que muchas de ellas son muy similares y sería muy repetitivo. Cabe destacar que hay dos tipos de rutas definidas, las que se utilizarán para mostrar una página y las que serán usadas como API para agilizar las acciones mediante AJAX y no tener que recargar la página constantemente. Antes de continuar se debe comentar que para conseguir que Codeigniter funcione como un API debemos utilizar una libreria proporcionada por un tercero, que puede ser encontrada en la url https://github.com/chriskacerguis/codeigniter-restserver, que permite de una forma muy sencilla crear un servidor REST.

Editor de encuestas

Imagen I01: Ejemplo de implementación método PUT

Las rutas utilizadas para mostrar una página han sido las siguientes:

- R01: survey/(:num) - R02: control/surveys - R03: control/survey/(:num) - R04: control/survey/(:num)/organize-questions - R05: control/survey/(:num)/statistics

Las rutas utilizadas para el API han sido las siguientes:

- R06: control/api-surveys/survey -> POST - R07: control/api-surveys/survey/(:num) -> DELETE - R08: control/api-surveys/survey/(:num)/organize -> PUT - R09: control/api-surveys/version -> POST - R10: control/api-surveys/version/(:num) -> PUT - R11: control/api-surveys/version/(:num)/activate -> PUT - R12: control/api-surveys/question -> POST - R13: control/api-surveys/question/(:num) -> PUT - R14: control/api-surveys/question/(:num) ->DELETE - R15: control/api-surveys/option -> POST - R16: control/api-surveys/option/(:num) -> PUT - R17: control/api-surveys/option/(:num) -> DELETE - R18: api-surveys/surveyed -> POST - R19: api-surveys/surveyed/(:num) -> PUT - R20: api-surveys/surveyedResponse ->POST

Editor de encuestas

- R21:control/api-surveys/survey/(:num) -> PUT - R22: control/survey/(:num)/statistics/export-data -> GET

Para definir las rutas en Codeigniter se utiliza, como ya se ha comentado, el fichero routes.php. La estructura utilizada para definir dichas rutas es la utilizada en la siguiente imagen, donde se puede apreciar que lo que se hace para definir una ruta es definir un vector que tiene como clave el nombre de la ruta y como valor otro vector que debe ser rellenado con una clave correspondiente a uno de los métodos HTTP y con el valor correspondiente al método y controlador donde encontrar el código a ejecutar cuando se acceda a esa ruta.

Imagen I02: Definición de las rutas de la aplicación.

La ruta R01: survey/(:num) es la utilizada públicamente por los encuestados para contestar a una encuesta. Si el número que se pasa en la url no corresponde al identificador de una encuesta o existe pero no está activa o no es pública el sistema mostrará un mensaje indicando que la encuesta no existe.

Editor de encuestas

Si la encuesta existe el usuario se encuentra con un botón para iniciar encuesta. En cuanto el usuario presiona el botón, mediante AJAX se hace una llamada al API para crear un nuevo encuestado (api-surveys/surveyed). En caso de error se muestra un error indicando el motivo. En caso de haber creado el encuestado correctamente se oculta el contenedor (div) de inicio y se muestra el contenedor (div) de las preguntas, además, se guarda el identificador del encuestado para usarlo posteriormente y se solicita preparar la siguiente pregunta ($.nextQuestionStep()).

Imagen I03: Método JavaScript para iniciar encuesta

El método $.nextQuestionStep() se encarga de obtener la siguiente pregunta ($.nextQuestion()), en el caso de existir siguiente pregunta se actualiza la barra de progreso ($.setSurveyProgress( númeroPreguntas, máximoPreguntas)) y se actualiza el html en función a la actual pregunta ($.setActualQuestion(actualQuestion)). En caso de no existir una siguiente pregunta se da paso a la finalización de la encuesta ($.finishSurvey()).

Editor de encuestas

Imagen I04: Código para el cambio a la siguiente pregunta

El método $.nextQuestion() es el encargado de encontrar la siguiente pregunta, para ello, recorre los caminos todavía disponibles y de cada uno de ellos obtiene la questionWrapper correspondiente al identificador obtenido al acceder a la posición n (número de preguntas) del camino. Para cada uno de los wrappers obtenidos se comprueba si pasa los filtros necesarios para poder seguir el camino. En el caso de tener filtro “ELSE” ese camino se añade al final de todo el vector de caminos, para que solo sea seleccionado ese camino en caso de no haber otro disponible, y por lo tanto, cumplir la función de “else”.

Editor de encuestas

Imagen I05: Código que devuelve la siguiente pregunta.

El método $.finishSurvey() simplemente esconde el contenedor de preguntas, muestra el contenedor de finalizar encuesta, cambia el progreso de la barra al 100%, obtiene el camino seguido por el usuario y finalmente realiza la petición AJAX al API para actualizar el encuestado marcándolo como finalizado y guardando el camino seguido (api-surveys/surveyed).

Editor de encuestas

Imagen I06: Código que finaliza la encuesta.

Para cargar los caminos tenemos el método $.loadQuestionsPath() que en función del siguiente JSON obtiene los caminos.

Editor de encuestas

Imagen I07: JSON con los questionsWrappers

Este JSON es almacenado en el sistema cuando se guarda el diagrama al organizar preguntas. El JSON está formado por una lista de questionsWrappers, cada uno de ellos formados por su identificador, el identificador de la pregunta, una lista de identificadores de los questionsWrappers padres y un campo filtro con el código necesario para evaluar el filtro en javascript. El método $.loadQuestionsPath() se encarga a partir del JSON de crear un mapa con clave identificador del questionWrapper y con valor un vector con sus hijos. A partir de este mapa se llama a una función recursiva que obtiene el vector con los posibles caminos.

Editor de encuestas

Imagen I08: Código para la generación de los caminos

Para conseguir diferenciar una parte pública y una parte privada dentro de la aplicación se han utilizado los hooks de Codeigniter, que nos permiten programar orientado a aspectos para que se ejecute siempre el código contenido en el hook, en el caso de este proyecto se ha seleccionado la opción post_controller_constructor. Las partes de la aplicación que consiguen hacerse cargo de las comentadas sesiones son:

- El hook auth.php: Es el encargado de redirigir al login en el caso de no tener acceso a una parte de la aplicación.

- El controlador auth_c.php: Es el encargado de mostrar la vista de login, de verificar con el modelo si el login es correcto y posteriormente establecer la sesión.

- El modelo auth_m.php: Es el encargado de verificar si el usuario y contraseña son válidos.

- El fichero de configuración hooks.php: Es el encargado de activar el hook y definir la configuración de dicho hook.

- El fichero de configuración auth.php: Es el encargado de definir las partes públicas de la aplicación.

Editor de encuestas

6.2. Validación y verificación En cuanto a la validación y a la verificación el software ha sido sometido a tests de aceptación por parte de varios usuarios que probablemente después integren esta herramienta en su sistema wisclic. Esta prueba con el cliente ayuda al proyecto a detectar tanto fallos de verificación como de usabilidad ya que permite rectificar ciertos puntos del diseño para hacer que sea mucho más sencillo de usar para el usuario. En este caso la validación, en principio, ha sido llevada a cabo desde el primer momento ya que la herramienta ha sido solicitada y desarrollada por la misma persona y por lo tanto, en esta situación es mucho más sencillo llevar a la realidad lo que uno desea. La falta de tiempo y el desvio temporal entre el tiempo estimado y el tiempo real ha impedido que se hicieran pruebas unitarias, ya que al seguir una metodología más tradicional las pruebas se ubican en último lugar a la hora de realizar un proyecto.

Editor de encuestas

BIBLIOGRAFÍA

[1] Rest server Codeigniter: https://github.com/chriskacerguis/codeigniter-restserver [2] jsPlumb: https://jsplumbtoolkit.com/ [3] Customer Relationship Management: https://es.wikipedia.org/wiki/Customer_relationship_management [4] Validación y Verificación: http://clases3gingsof.wikifoundry.com/page/Verificaci%C3%B3n+y+Validaci%C3%B3n

https://es.wikipedia.org/wiki/Customer_relationship_management

https://jsplumbtoolkit.com/

https://github.com/chriskacerguis/codeigniter-restserver

Editor de encuestas

CONCLUSIONES Y POSIBLES AMPLIACIONES

Para concluir podemos afirmar que el proyecto ha sido muy positivo tanto a nivel personal, puesto que se han asumido los conocimientos adquiridos a lo largo del Máster en Ingeniería Web, como a nivel profesional, puesto que el proyecto presentado es un proyecto útil, que podrá ser utilizado por diferentes clientes próximamente, a pesar de que todavía falta pulir ciertos detalles y ampliar la funcionalidad.

En cuanto a la gestión del proyecto se ha podido comprobar que una mala gestión del tiempo puede llevar a un proyecto a perder mucho dinero. Es complicado estimar el tiempo, pero en proyectos reales es necesario poder llegar a detallar las tareas necesarias para conseguir cumplir los objetivos del proyecto desglosandolas en tareas pequeñas fáciles de medir para conseguir tener el control del tiempo. Además es fundamental en un proyecto real elegir una metodología para conseguir que todo el equipo trabaje de forma uniforme.

Las futuras ampliaciones que se le aplicarán al sistema serán:

- Permitir añadir usuarios a una encuesta privada con el objetivo de que esa encuesta simplemente pueda ser contestada por esos usuarios.

- Guardar un historial de las encuestas en las que ha participado un usuario encuestado.

- Enviar el enlace a la encuesta a los usuarios mediante la herramienta de email marketing de wisclic.

- Añadir preguntas de tipo entero. - Poder generar informes y gráficos personalizados en el apartado de estadísticas. - Permitir editar el estilo de la parte pública del sistema de encuestas.

MÁSTER EN INGENIERÍA WEB Proyecto Fin de Máster · MÁSTER EN INGENIERÍA WEB Proyecto Fin de...

Documents

Transcript of MÁSTER EN INGENIERÍA WEB Proyecto Fin de Máster · MÁSTER EN INGENIERÍA WEB Proyecto Fin de...