Herramienta inteligente para desplegar test en portal ... · Se creará un prototipo en la fase de...
57
Daniel Espinosa Azofra Eduardo Sáenz de Cabezón Irigaray Facultad de Ciencia y Tecnología Grado en Ingeniería Informática 2015-2016 Título Director/es Facultad Titulación Departamento TRABAJO FIN DE GRADO Curso Académico Herramienta inteligente para desplegar test en portal corporativo Autor/es
Transcript of Herramienta inteligente para desplegar test en portal ... · Se creará un prototipo en la fase de...
Daniel Espinosa Azofra
Eduardo Sáenz de Cabezón Irigaray
Facultad de Ciencia y Tecnología
Grado en Ingeniería Informática
2015-2016
Título
Director/es
Facultad
Titulación
Departamento
TRABAJO FIN DE GRADO
Curso Académico
Herramienta inteligente para desplegar test en portal corporativo
Autor/es
© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2016
publicaciones.unirioja.esE-mail: [email protected]
Herramienta inteligente para desplegar test en portal corporativo, trabajo fin degrado
de Daniel Espinosa Azofra, dirigido por Eduardo Sáenz de Cabezón Irigaray (publicado porla Universidad de La Rioja), se difunde bajo una Licencia
Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los
titulares del copyright.
Facultad de Ciencia y Tecnología
TRABAJO FIN DE GRADO
Grado en Ingeniería Informática
Herramienta inteligente para desplegar test en portal
corporativo
Alumno:
Daniel Espinosa Azofra
Tutores:
Eduardo Sáenz de Cabezón Irigaray
Logroño, junio, 2016
1
ÍNDICE Índice ............................................................................................................. 1
Resumen ........................................................................................................ 5
Abstract .......................................................................................................... 5
1. Introducción ................................................................................................ 7
1.1. Antecedentes ....................................................................................... 7
1.2. Objetivos .............................................................................................. 8
1.2.1. Objetivos operativos ...................................................................... 8
1.2.2. Objetivos académicos ................................................................... 9
1.3. Integrantes y relaciones ....................................................................... 9
1.4. Decisiones y justificación ................................................................... 10
1.4.1. Tecnologías ................................................................................ 10
1.4.2. Metodología ................................................................................ 10
1.5. Riesgos .............................................................................................. 11
1.5.1. Riesgos específicos del proyecto ................................................ 12
1.5.2. Riesgos generales de cualquier proyecto ................................... 12
2. Planificación y seguimiento ...................................................................... 13
2.1. Calendario ......................................................................................... 13
2.2. Hitos del Trabajo de Fin de Grado ..................................................... 13
2.3. Diagrama de Gantt y horas por tarea ................................................ 14
2.4. Estudio de carga del trabajo .............................................................. 15
3. Gestión del proyecto ................................................................................ 17
3.1. Seguimiento ....................................................................................... 17
3.2. Re planificaciones ............................................................................. 18
3.3. Comparativa tiempo estimado y real ................................................. 18
4. Análisis ..................................................................................................... 21
4.1. Definiciones ....................................................................................... 21
2
4.2. Descripción general del sistema ........................................................ 21
4.3. Actores .............................................................................................. 22
4.4. Diagrama de casos de uso ................................................................ 22
4.4.1. Especificación de casos de uso .................................................. 24
4.5. Catálogo de requisitos funcionales .................................................... 24
4.6. Catálogo de requisitos no funcionales. .............................................. 26
4.7. Especificación del entorno del sistema .............................................. 27
4.7.1. Entorno hardware........................................................................ 27
4.7.2. Entorno software ......................................................................... 28
4.8. Diagrama de clases, modelo conceptual ........................................... 28
5. Diseño ...................................................................................................... 31
5.1. Arquitectura de la aplicación .............................................................. 31
5.2. Diagrama relacional ........................................................................... 31
5.3. Estructura de directorios .................................................................... 33
5.4. Definición de interfaces de usuario .................................................... 34
5.4.1. Principios de diseño de la interfaz............................................... 34
5.4.2. Diagrama para la navegación de la aplicación ............................ 35
5.4.3. Detalle de las interfaces .............................................................. 36
5.5. Diseño de plan de pruebas ................................................................ 38
5.5.1. Pruebas de unidad ...................................................................... 38
5.5.2. Pruebas de integración ............................................................... 38
5.5.3. Pruebas de aceptación ............................................................... 38
5.5.4. Documentación de pruebas ........................................................ 38
6. Desarrollo ................................................................................................. 41
6.1. Tecnologías usadas .......................................................................... 41
6.2. Librerías empleadas .......................................................................... 42
6.3. Desarrollo de la aplicación ................................................................. 42
3
6.3.1. Creación de test .......................................................................... 42
6.3.2. Manejo de test mediante paquetes ............................................. 43
6.3.3. Realización de test ...................................................................... 43
6.3.4. Procesado de los parámetros de habilidades ............................. 44
6.3.5. Realización y procesado de test externamente .......................... 44
6.3.6. Envío de peticiones de test pendientes ....................................... 45
6.3.7. Visualización de habilidades ....................................................... 45
6.3.8. Importación de preguntas de test ................................................ 45
6.3.9. Creación de una habilidad y problemas surgidos ....................... 46
6.3.10. Errores con la librería UploadImage .......................................... 46
7. Pruebas .................................................................................................... 47
7.1. Pruebas unitarias ............................................................................... 47
7.1.1. Creación de un test ..................................................................... 47
7.1.2. Creación de un paquete .............................................................. 47
7.1.3. Realización de un test ................................................................. 47
7.1.4. Envío de solicitud de un test ....................................................... 48
7.1.5. Reanudar y detener un test ......................................................... 48
7.2. Pruebas de integración ...................................................................... 48
7.2.1. Prueba de integración ................................................................. 49
8. Conclusiones ............................................................................................ 51
8.1. Aprendizaje individual ........................................................................ 51
8.2. Aspectos a recalcar ........................................................................... 52
8.3. Ampliaciones ..................................................................................... 52
9. Bibliografía ............................................................................................... 53
4
5
RESUMEN
La empresa Formavolución dispone de una serie de test para medir diferentes rasgos
de la personalidad de sus usuarios y recomendar recursos formativos en función de los
resultados obtenidos.
La implementación actual de dichos test se realiza sobre un documento plano de PHP
con un mantenimiento costoso. Los principales problemas: cualquier cambio requiere
acceder al código y a la base de datos, la creación de un nuevo test implica su
desarrollo desde cero en un documento nuevo y no existe separación entre la capa de
presentación y la de lógica de negocio.
Este trabajo de fin de grado pretende solucionar los anteriores problemas al crear
todas las funcionalidades necesarias para que determinados usuarios puedan
gestionar los test.
ABSTRACT
Formavolución has series of test to measure scores on various personality traits of
its users and recommends training courses according to the results obtained.
The actual implementation of the test is carried out manually using a plain PHP
document, which is expensive. The main problems are: any change requires the access
to the code and the database, the creation of a new test implied is development from
the ground and there is not real separation between the presentation tier and the
business logic.
This end of degree work aims to resolve the problems presented by creating all the
functionalities to manage the tests.
6
7
1. INTRODUCCIÓN
A continuación, se van a comentar los antecedentes al desarrollo de este Trabajo de Fin
de Grado (TFG), así como los objetivos a alcanzar, los integrantes y las relaciones con los
mismos, las decisiones tomadas junto con su justificación y diversos riesgos que pueden
afrontarse a lo largo del TFG.
1.1. Antecedentes
La aplicación web Ítaca, desarrollada por la empresa Formavolución, es un portal para
la formación de sus usuarios en función de sus capacidades.
Para ello se lleva a cabo una evaluación de las habilidades cognitivas y de las
capacidades de aprendizaje de los usuarios, haciendo uso de test.
Esta aplicación puede tener utilidad tanto en el ámbito institucional como en la
formación de empleados.
El conocimiento de las capacidades de los usuarios también puede servir, en caso de
ser usado en el entorno laboral, para la formación de equipos multidisciplinares o la
recomendación de puestos de trabajo determinados dentro de una determinada
organización.
La aplicación presentada ya había sido desarrollada con anterioridad, pero la empresa
ha decidido que es necesario reestructurarla para hacerla modular y extensible.
Por ello:
Durante el primer cuatrimestre de este curso, 2015-2016, Javier Ruiz y yo, Daniel
Espinosa, desarrollamos la aplicación básica sobre la que ahora se desarrollarán
las funcionalidades anteriormente presentadas.
Los tres alumnos de la Universidad de La Rioja (UR) que realizaremos nuestro TFG
en la empresa nos dedicaremos a añadir nuevas funcionalidades a la aplicación
básica desarrollada.
La aplicación básica se desarrolló en PHP, sin hacer uso de frameworks, y la
información de la que hacía uso la misma se almacenó en una base de datos (BDD) en
MySQL que se ha administrado haciendo uso de la herramienta phpMyAdmin.
Para el desarrollo de la aplicación web se hizo uso de una plantilla para el diseño de
HTML y CSS que había sido previamente comprada a Bootstrap por parte de la empresa.
8
Todo lo mencionado en el párrafo anterior va a marcar el desarrollo de los TFGs que
se realizarán en la empresa.
En lo referente a los test la aplicación inicial tenía una serie de problemas:
La implementación de los test se realizaba directamente sobre un documento PHP.
Esto implicaba un alto coste de mantenimiento ya que cualquier cambio
introducido conllevaba la modificación directa del código y de la BDD.
La creación de un nuevo test se debía hacer desde cero.
No existía una separación entre la capa de presentación y la de lógica de
negocio.
Los problemas expuestos provocaban una reducción de la utilidad de la aplicación que
únicamente contaba con cuatro test.
Esto va a intentar ser subsanado en este TFG.
1.2. Objetivos
Se pretende añadir a la aplicación básica desarrollada en el primer cuatrimestre toda la
funcionalidad necesaria para la realización de test.
1.2.1. Objetivos operativos Será necesario especificar, diseñar e implementar todas las funcionalidades
mencionadas siguiendo la planificación presentada en el Apartado 2. Para ello:
Se implementarán las habilidades que se prueban en cada test y en cada
pregunta.
Se desarrollarán funcionalidades para la gestión de test, preguntas y
respuestas, así como de las habilidades que se manejan.
Se tendrá en cuenta el rol del usuario, así como la organización a la que
pertenece a la hora de decidir que operaciones podrá realizar.
Se ampliarán las funcionalidades propias al desarrollo de los test.
Se hará posible la creación de diversas vistas para las respuestas.
9
Se generarán funcionalidades para que una vez los test se completen:
Sean procesados y su información resultante almacenada, teniendo en cuenta la
información previa del usuario que lo haya realizado.
La información generada pueda visualizarse mediante gráficas.
La aplicación desarrollada será modular y deberá integrarse a la aplicación Ítaca
mencionada anteriormente.
1.2.2. Objetivos académicos La realización de este proyecto también deberá ser útil para:
Ampliar mi experiencia en la gestión de proyectos.
Ampliar mis conocimientos sobre PHP, HTML y CSS, así como del desarrollo de
aplicaciones web.
1.3. Integrantes y relaciones
Xavier Capellades: Tutor de TFG en la empresa.
Visualización del estado de mi proyecto y de los documentos generados haciendo
uso de la herramienta para la gestión de proyectos usada en la empresa, Redmine.
Eduardo Sáenz de Cabezón: Tutor de TFG en la Universidad de La Rioja (UR).
Comunicación semanal de entregables haciendo uso de la plataforma de TFG.
Uso de correo electrónico para la resolución de dudas menores.
Reuniones presenciales quincenales.
Álvaro Sáenz: Coordinador de proyectos en la empresa.
Reuniones presenciales de seguimiento.
Visualización del estado de mi proyecto y de los documentos generados haciendo
uso de la herramienta para la gestión de proyectos usada en la empresa, Redmine.
Eva Vidáñez: Coordinador de proyectos en la empresa.
Reuniones presenciales y pruebas del módulo una vez finalizado.
10
Javier Ruiz y Marina Blanco: Compañeros de la UR desarrollando otros módulos para la
aplicación en la empresa.
Reuniones presenciales de seguimiento.
Puntualmente colaboración en aspectos concretos del proyecto.
1.4. Decisiones y justificación
A continuación, expongo una serie de decisiones tomadas junto con su justificación.
1.4.1. Tecnologías Tras el estudio de la aplicación Ítaca y de la aplicación básica sobre la cual se va a
desarrollar este módulo el conjunto de estudiantes de la UR que llevaremos a cabo nuestros
proyectos en Formavolución hemos decidido utilizar PHP y MySQL ya que los dos casos
mencionados hacen uso de estas tecnologías.
Tras estudiar la posibilidad de hacer uso de frameworks así como las propiedades de
varios de ellos se ha decidido que no se hará uso de frameworks pues el tiempo que se
dedicaría en la implantación y el aprendizaje de los mismos sería excesivamente
elevado. A esto se suma que la aplicación básica tampoco se desarrolló haciendo uso
de un framework por lo que debería modificarse para que las funcionalidades básicas
funcionasen correctamente.
1.4.2. Metodología La colección de requisitos cerrada, la experiencia en proyectos de similares
características y el conocimiento de los lenguajes a utilizar han marcado la elección de
la metodología a utilizar.
Se ha optado por un modelo iterativo-incremental que se combinará con el desarrollo
de prototipos para presentar al equipo de Formavolución una visión parcial de la
aplicación, destapando de esta forma posibles requisitos ocultos.
11
Figura 1. Iteraciones del proyecto.
Se creará un prototipo en la fase de diseño con el fin de marcar como las habilidades
y los parámetros de cada test se combinan tal y como se desea una vez se haya creado
una versión inicial del back-end.
La iteración 1 fijará los requisitos del back-end: gestión de usuarios, roles, test,
preguntas y respuestas; así como de habilidades y parámetros de esas habilidades.
La iteración 2 añadirá el formulario para la creación de test, así como el resto del front-
end y consolidará la interfaz del módulo. Estas iteraciones se darán en durante el
desarrollo del proyecto.
La iteración 3, que se realizará en el periodo de pruebas, servirá para la corrección de
errores y la mejora de funcionalidades en el entorno de la aplicación sin que esto suponga
ningún problema para la aplicación Ítaca de la empresa.
1.5. Riesgos
A continuación, se van a exponer la serie de riesgos que presumiblemente se van a
afrontar durante el desarrollo de este proyecto.
12
1.5.1. Riesgos específicos del proyecto En primer lugar, se desglosarán los riesgos específicos del proyecto.
1.5.1.1. Mantenimiento de habilidades Actualmente existe una tabla en la BDD que almacena una docena de habilidades
para un determinado usuario, eliminando, al ser procesado cada nuevo test, el contenido
de la tabla. Los datos no tendrán que mantenerse por lo que el único riesgo de pérdida de
datos será el derivado de la copia incorrecta de las habilidades a medir cuando se cree
la funcionalidad correspondiente al procesamiento de test.
1.5.1.2. Desarrollo por separado de tres módulos de manera simultánea Los tres alumnos de la UR que desarrollaremos nuestros TFGs en la empresa
trabajaremos en diferentes módulos, pero haciendo uso del mismo servidor con una
base de datos compartida. También será usada por los tres la misma aplicación básica.
Para evitar conflictos derivados de la modificación de partes comunes de la
aplicación cada alumno trabajará sobre una copia de la aplicación básica realizada al
comienzo del desarrollo de cada TFG.
1.5.2. Riesgos generales de cualquier proyecto A continuación, se enumerarán los riesgos comunes al conjunto de los proyectos.
1.5.2.1. Planificación incorrecta Se han calculado 20 horas extra para riesgos que puedan derivarse de una
estimación incorrecta de las fechas.
Ya que las fechas de entrega académica son estrictas, pero no son así las propias
del proyecto, será posible la entrega de la segunda iteración y la realización de la tercera
una vez realizada la presentación.
13
2. PLANIFICACIÓN Y SEGUIMIENTO
A continuación, se va a presentar parte de la información generada durante la
planificación del TFG.
2.1. Calendario
Teniendo en cuenta el horario marcado en el ANEXO I, que limitaba a 20 horas
semanales el desarrollo del TFG, y el tipo de proyecto y sus riesgos se fijó el calendario
que presenta la figura 2. Se hizo uso del calendario académico de la UR como base para
fijar los días festivos y los días de desarrollo del TFG:
En púrpura se muestran los días lectivos, en los que se desarrollará el TFG.
En rojo los días festivos.
En verde claro las fechas para la realización de los exámenes del grado.
Se marcaron una serie de hitos recuadrando la fecha correspondiente el calendario.
Figura 2. Calendario del TFG.
2.2. Hitos del Trabajo de Fin de Grado
Los hitos marcados para el TFG fueron los siguientes:
8 de febrero: inicio del TFG.
14
15 de febrero: fin de la planificación del TFG.
22 de febrero: fin del análisis. Entrega de la planificación y el análisis.
4 de abril: fin del diseño. Entrega del diseño.
2 de mayo: fin desarrollo.
17 de junio: fin de implantación y pruebas.
20 de junio: fin del TFG. Entrega de la memoria completa.
22 de junio: fecha estimada de depósito de TFG.
7 de julio: fecha estimada de defensa de TFG.
2.3. Diagrama de Gantt y horas por tarea
La distribución estimada de horas por tarea queda como muestra la figura 3.
Figura 3. Horas estimadas para cada tarea.
Puede observarse como el desarrollo y el diseño son las fases fundamentales del
proyecto con una carga horaria de 70 horas en el primer caso y 55 en el segundo. Las
horas estimadas para la documentación, seguimiento y desarrollo se emplearán a lo
largo del desarrollo del proyecto.
En la figura 4 que muestra un diagrama de Gantt en el que se puede apreciar cómo se
llevará a cabo el trabajo. En el momento de realizar la captura ya se habían dedicado 50
horas al desarrollo del TFG.
10
30
55
70
50
40
15
30Planificación
Análisis
Diseño
Desarrollo
Implantación y pruebas
Documentación
Reuniones
Seguimiento
15
Figura 4. Diagrama de Gantt del TFG, tras 50 horas de trabajo.
2.4. Estudio de carga del trabajo
Con el calendario y la distribución de tareas presentadas se ha repartido la carga de
trabajo uniformemente, dedicando 20 horas semanales al desarrollo del TFG durante
todo el periodo de realización del mismo.
Únicamente se han marcado como semanas no hábiles para el desarrollo del TFG las
que corresponden con Semana Santa y al periodo de exámenes. Por lo que hay un total
de dieciséis semanas útiles.
El cómputo total de horas disponibles para el desarrollo del TFG daría un total de 320.
Esto se debe a que se han calculado 20 horas extra para compensar riesgos y posibles
imprevistos.
16
17
3. GESTIÓN DEL PROYECTO
A continuación, se presenta toda la información correspondiente a la gestión del
proyecto.
3.1. Seguimiento
Durante el desarrollo de las primeras fases del proyecto se han cumplidos los hitos
de forma correcta.
Sin embargo, a medida que se avanzaba en la fase de desarrollo ha quedado claro que
se necesitaba un número superior de horas para desarrollar toda la funcionalidad
planificada en el TFG por lo que la fase de desarrollo pasó de las 70 horas planificadas
a 105 horas.
Además de realizar un seguimiento individual, haciendo uso de la herramienta de la
empresa, se ha aprovechado la herramienta de la universidad para realizar un seguimiento
comparativo, que sirvió para comprobar que el desarrollo de mi proyecto se encontraba
dentro, o ligeramente por encima, de la media.
Figura 5. Estado comparativo del TFG a día 16/05/2016
Con respecto al seguimiento comparativo, la realización de mi TFG en una empresa
con compañeros de la UR, que estaban desarrollando los suyos, me ha permitido tener
una visión comparativa diaria.
18
3.2. Re planificaciones
Al alcanzar a la fase de desarrollo se concretó por parte de la empresa que iba a ser
complicado llevar a cabo una implantación del módulo del TFG y, ante la imposibilidad
de dedicar a esta fase todo el tiempo planificado y la necesidad de más horas para llevar a
cabo el desarrollo, se redistribuyeron las horas otorgándole un mayor número a la fase
de desarrollo.
Ante la imposibilidad de llevar a cabo una implantación, se realizó una
demostración interna con el propósito de llevar a cabo un conjunto de pruebas
pormenorizadas de las funcionalidades del módulo desarrollado en el TFG.
Junto con la modificación del reparto de horas entre fases hubo una modificación en el
reparto de semanas útiles. Esto se debe a que a medida que avanzó el cuatrimestre quedó
claro que las semanas de exámenes, que habían sido marcadas como una parada en el
desarrollo del TFG, también iban a emplearse para el desarrollo del mismo.
El proyecto pasó de 300 horas a 298.
Figura 6. Horas dedicadas a cada tarea.
3.3. Comparativa tiempo estimado y real
A continuación, se muestra la figura 7 en la que se puede ver la diferencia entre el
tiempo estimado y el real para el desarrollo de cada tarea.
10
35
45
105
20
40
13
30Planificación
Análisis
Diseño
Desarrollo
Implantación y pruebas
Documentación
Reuniones
Seguimiento
19
Figura 7. Comparativa horas estimadas y horas reales.
0
20
40
60
80
100
120
H. Estimadas H. Reales
20
21
4. ANÁLISIS
A continuación, se va a presentar un resumen de la información generada durante la fase
de análisis del TFG.
4.1. Definiciones
A continuación, se definen varios términos importantes para el desarrollo del TFG:
Autenticarse: Se entiende que un usuario se ha autenticado cuando ha introducido
su email y la contraseña en el formulario de autenticación de la aplicación.
Realización de test: Realizar un test conllevará responder la batería completa de
preguntas que lo componen pudiéndose detener el mismo para posteriormente
reanudarlo.
Habilidades cognitivas y capacidades de aprendizaje: Serie de características de
un usuario que se miden en función de las respuestas que los mismos introduzcan
en los test.
Organización: La aplicación web de la empresa Formavolución está pensada de
forma que pueda ser usada tanto por instituciones educativas como por empresas.
Una organización será por tanto el cliente directo de Formavolución y podrá ser, por
poner un ejemplo, tanto Repsol como el I. E. S. Comercio.
Equipo: Las organizaciones están compuestas a su vez de equipos que engloban a
un conjunto de usuarios. Por tanto, y teniendo como referencia las organizaciones
presentadas anteriormente, un equipo podría ser tanto el departamento de ventas
de Repsol como la clase de 4º A del I. E. S. Comercio.
4.2. Descripción general del sistema
La aplicación web Ítaca desarrollada por Formavolución es un portal para la formación
de usuarios en función de sus capacidades. Para ello se desarrollará un módulo para la
evaluación de las habilidades cognitivas y de las capacidades de aprendizaje de los
usuarios haciendo uso de test. Se hará posible no únicamente la realización sino la
gestión de los test a de la aplicación.
El módulo desarrollado deberá ser integrable en la aplicación existente.
22
4.3. Actores
Los roles que habían sido creados para la aplicación básica se mantendrán en el
desarrollo de este módulo. Existen 5 roles de usuario.
La disponibilidad de una funcionalidad no dependerá únicamente del rol, ya que se
tendrá en cuenta la organización a la que pertenecen los usuarios:
Existirá un súper-administrador único.
El resto de roles serán entendidos como roles dentro de una organización.
Los roles serán:
Súper-administrador: administra el sistema, tiene permisos para acceder a todo el
back-end.
Administrador: Asigna o deniega el rol de usuario intermedio y gestiona usuarios
básicos y paquetes de test.
Usuario intermedio: Dispone de acciones para la gestión de test en caso de
pertenecer a Formavolución. Gestiona a los usuarios básicos en el resto de casos.
Usuario básico: Puede visualizar su información, realizar test o enviar una petición
para la realización de un test.
Visitante: Puede registrarse o realizar un test si ha sido invitado.
4.4. Diagrama de casos de uso
A continuación, se muestra el diagrama de casos de uso de la aplicación.
23
Figura 8. Diagrama de casos de uso
24
4.4.1. Especificación de casos de uso A continuación, se pretende especificar dos casos de uso complejos.
4.4.1.1. Invitar a la realización de un test Para invitar a la realización de un test se debe seleccionar un test en primer lugar y a
continuación introducir la información necesaria para que se envíe la petición a un visitante. Nombre: Invitar a la realización de un test. Descripción: Un usuario básico invita a un visitante a la realización de un test. Actores: Usuario básico. Precondición: El usuario básico debe estar autenticado en el sistema. Flujo normal: En el menú de visualización de test se selecciona el test que se pretende enviar.
Se introduce el nombre, email y cuerpo del mensaje que se enviará al visitante. El sistema gestiona la realización del test por parte del invitado:
Se crea un identificador para el test a realizar por el visitante. Se envía un correo a la dirección introducida por el usuario añadiendo también
el cuerpo y el nombre introducidos. También se incluye la dirección URL para la realización del test.
Postcondición: Se puede realizar un test por parte de un visitante.
4.4.1.2. Visualizar habilidades de usuarios Para visualizar las habilidades de un usuario seleccionar el usuario en primer lugar.
Nombre: Visualizar habilidades de usuarios. Descripción: Un usuario intermedio visualiza las habilidades de otro usuario. Actores: Usuario intermedio. Precondición: El usuario intermedio debe estar autenticado en el sistema. Flujo normal: En el menú de la aplicación se indica que desean visualizarse habilidades de usuarios.
Se indica el usuario cuyas habilidades se desean visualizar. El sistema gestiona la visualización de las habilidades:
Se obtiene la calificación de las habilidades. Se genera una gráfica en la que se pueden ver estas habilidades.
Postcondición: Se pueden visualizar las habilidades de un usuario.
4.5. Catálogo de requisitos funcionales
Debo remarcar que los roles de la aplicación básica contaban con otras
funcionalidades, en su mayor parte relacionadas con la gestión de organizaciones,
equipos y puestos de trabajo. Estas funcionalidades no influyen en el desarrollo de
este módulo centrado en test, por lo que no han sido mencionadas.
A continuación, se muestra el catálogo de requisitos funcionales. Los requisitos que son
necesarios para este módulo pero que ya se han desarrollado han sido remarcados
haciendo uso del formato cursiva.
25
Súper-administrador.
o Gestionar roles.
Modificar rol.
o Gestionar administradores.
Asignar rol de administrador.
Denegar rol de administrador.
Administrador.
o Gestionar usuarios intermedios.
Asignar rol de usuario intermedio.
Denegar rol de usuario intermedio.
o Gestionar usuario básico:
Dar de baja a usuario básico.
Asignar usuario a organización.
o Gestionar test.
Crear paquete de test.
Ocultar paquete de test.
Hacer visible paquete de test.
Asignar test a paquete de test.
Asignar paquete de test a organización.
Usuario intermedio.
o Gestionar test (Estas funcionalidades sólo serán accesibles para usuarios
cuya organización sea Formavolución).
Crear test.
Asignar pregunta.
o Gestionar pregunta (Estas funcionalidades sólo serán accesibles para
usuarios cuya organización sea Formavolución).
Crear preguntar.
Añadir imagen a una pregunta.
Asignar respuesta.
o Gestionar respuesta (Estas funcionalidades sólo serán accesibles para
usuarios cuya organización sea Formavolución).
Crear respuesta.
Añadir imagen a una respuesta.
Asignar valores a una respuesta.
o Visualizar habilidades de usuarios.
26
o Visualizar paquetes de test disponibles.
o Enviar a usuarios básicos solicitudes para la realización de test.
Permitir a un usuario repetir un test.
Usuario básico.
o Autenticarse.
Mediante un email y una clave.
o Cerrar sesión.
o Modificar datos personales.
o Realizar test.
Guardar test en proceso.
Reanudar test.
o Consultar habilidades propias.
o Invitar a un visitante a la realización de un test.
Visitante.
o Registrarse en la aplicación.
o Realizar test previa invitación.
4.6. Catálogo de requisitos no funcionales.
A continuación se presentan los requisitos no funcionales que pretende cumplir la
aplicación:
Cumplimiento de estándares.
o Interfaz de la aplicación: HTML5, CSS3.
o Calidad de código.
Accesibilidad.
o Pautas de Accesibilidad al Contenido en la Web (WCAG), nivel de
Conformidad "A".
Seguridad.
o HTTPS.
o Cifrado de claves haciendo uso de AES.
Requisitos legales.
o La inscripción del fichero en la AEPD y la supervisión de la seguridad la llevará
a cabo el responsable del Servicio.
27
Licencia del código.
o Los derechos de autoría y explotación del producto pertenecerán a la empresa
Formavolución.
Interfaz.
o Se hará uso de una plantilla Bootstrap por lo que se espera conseguir un
resultado que pueda visualizarse correctamente en al menos los navegadores
más extendidos (Chrome, Firefox e Internet Explorer).
o El uso de la plantilla también debería de hacer adaptable la aplicación a
dispositivos móviles.
o En el back-end:
Anticipación: la aplicación deberá anticiparse a las necesidades del
usuario intermedio, especialmente en la introducción de datos para la
creación de preguntas y respuestas y de asignar valores a las mismas.
Autonomía: proveerá al usuario intermedio un entorno flexible para
que rápidamente pueda conocer el funcionamiento de la aplicación.
Consistencia: los elementos comunes deberán aparecer situados en
la misma posición de una manera ordenada y coherente,
consiguiéndose de esta forma una imagen de unidad.
o En el front-end:
Simplicidad: la aplicación deberá poder ser utilizada por usuarios que
no tengan conocimientos amplios en informática.
La interfaz deberá seguir la plantilla de la empresa.
El módulo de la aplicación se creará en español, pero será creado de forma que pueda
ser multilingüe en el futuro.
4.7. Especificación del entorno del sistema
Para desarrollar el módulo se ha alojado la aplicación en un servidor virtual con las
especificaciones que se mencionan a continuación:
4.7.1. Entorno hardware A continuación, se especifican las propiedades del servidor virtual:
Un procesador Dual Core.
28
2GB de memoria RAM.
Un disco duro de 50 GB.
Sistema de copia del disco duro en sistema de almacenamiento en red (NAS) de 1
TB.
4.7.2. Entorno software A continuación, se va a especificar el software del servidor:
Sistema operativo Debian 8.x
Servidor Apache 2.4.4
PHP 5.6.x
phpMyAdmin 4.2
MariaDB 10.1
4.8. Diagrama de clases, modelo conceptual
A continuación, se muestra la figura 9 en la que puede verse el diagrama de clases de
la aplicación.
La clase operaciones está compuesta por una lista de operaciones que hace la
función de tabla de permisos para el conjunto de roles.
Los equipos y las organizaciones pueden depender de un equipo u organización
padre, respectivamente.
Los equipos sólo tendrán sentido cuando pertenezcan a una organización.
La clase característica fija para un usuario el valor que, en función de los test, se ha
marcado para una determinada habilidad.
Un test estará formado por un conjunto de preguntas que a su vez tendrán asignadas
unas respuestas.
Las respuestas tendrán asignado un valor que servirá para fijar la puntuación de un
usuario para una determinada habilidad, con la que estará relacionada la pregunta.
29
Figura 9. Diagrama de clases.
30
31
5. DISEÑO
A continuación, se presenta un resumen de la información generada durante la fase de diseño del TFG.
5.1. Arquitectura de la aplicación
Se hará uso de una particularización de la arquitectura de tres capas: el patrón Modelo
Vista Controlador (MVC). Este patrón está compuesto por: el modelo, que es el objeto de la aplicación; la vista, que lo representa; y el controlador, que define el comportamiento en función de la entrada del usuario. El controlador maneja el flujo de la aplicación y hace la función de “intermediario” entre el modelo, al que pide lo que el usuario solicita; y la vista, a través de la cual muestra una representación del modelo. De esta forma es posible incluir la lógica relacionada con los datos en el modelo, el código de la presentación en la vista y la lógica de la aplicación en el controlador.
Figura 10. Cooperación entre modelo, controlador y vista.
5.2. Diagrama relacional
A partir del diagrama de clases presentado en el análisis se ha generado el
diagrama relacional, para ello ha sido necesario modificar las relaciones 1 a N mediante
la creación de nuevas entidades. Las nuevas entidades mencionadas son usuario_rol,
usuario_organizacion_equipo, usuario_habilidad, pregunta_test y pregunta_respuesta.
Se ha añadido una nueva entidad, paquete, que servirá para agrupar un conjunto de test.
Se ha suprimido la entidad parametro, ya que se almacenará directamente el valor de
una habilidad para un determinado usuario.
Se han creado una serie de entidades para permitir el almacenamiento de la
información correspondiente a la realización de un test por parte de un usuario:
usuario_test, almacena información sobre la realización de un test por parte de un
usuario, en concreto los identificadores de ambas entidades.
32
test_realizado, para una relación entre usuario y test se almacena la fecha en la que
se ha realizado. Tiene además un campo, esExterno, que sirve para indicar si el test
ha sido realizado por un usuario, o visitante, diferente al evaluado.
test_pendiente, almacena los identificadores de los test que se ha solicitado que un
usuario realice. Tiene, al igual que la entidad anterior, un campo esExterno.
test_detenido, almacena los identificadores de los test que un usuario ha detenido,
así como la fecha en que se detuvo la realización del mismo.
Se ha fijado por parte de la empresa que es necesario almacenar las respuestas de
un usuario para un determinado test, para lo que se ha creado la entidad test_respuesta.
Se ha modificado la relación entre las entidades pregunta y habilidad, fijando que
una pregunta puede relacionarse únicamente con una habilidad.
Se han añadido nuevos campos a las entidades, las modificaciones fundamentales
son:
A la entidad operaciones se han añadido todos los campos booleanos necesarios
para fijar las operaciones propias de la aplicación básica y las correspondientes a
este módulo.
A la entidad usuario_habilidad se le ha fijado un campo valor de tipo decimal (6, 5)
para almacenar valores numéricos con 6 dígitos entre 0 y 1. También se le ha
añadido el campo fechaMedida de tipo date para almacenar la fecha en la que se
llevó a cabo la medición de la habilidad.
A las entidades pregunta y respuesta se les ha añadido un campo imagen de tipo
varchar (100) que contendrá la dirección de una imagen en el servidor en caso de
que su contenido no sea únicamente textual.
Se han nombrado correctamente las claves de cada entidad y se han añadido
claves extranjeras a aquellas entidades que lo necesitaban.
El resultado final puede observarse en la figura 11.
33
Figura 11. Diagrama relacional.
5.3. Estructura de directorios
El proyecto se estructurará dentro del servidor. Se dedicará un directorio al módulo
para las funcionalidades propias de la realización de test. Dentro del mismo se crearán
directorios para:
assets: Conjunto de ficheros necesarios para la correcta visualización de la
plantilla de Bootstrap.
34
clases: Conjunto de clases auxiliares para la realización de diferentes
funcionalidades básicas.
images: Conjunto de imágenes que serán usadas por la aplicación.
include: Contenido común al conjunto de páginas de la aplicación.
sistema: Conjunto de clases y funciones necesarias para que la aplicación, y
en concreto este módulo, sea funcional.
Figura 12. Estructura de directorios.
5.4. Definición de interfaces de usuario
A continuación, se definirán las interfaces de usuario.
5.4.1. Principios de diseño de la interfaz Se buscará que en el back-end prime la eficacia, las bases para su diseño serán:
Anticipación: Se garantizará con la presentación de bloques de respuestas
posibles previamente creados en función del número de las mismas para una
determinada pregunta.
Autonomía: Se pretende incluir una sección de ayuda contextual.
35
Consistencia: Se presentarán ordenados y agrupados los elementos comunes,
situados siempre en la misma posición, dando de esta forma una imagen de unidad.
En el front-end, la sencillez y la adecuación a la plantilla de la que hace uso la empresa
será fundamental:
Simplicidad: Se implementarán, y serán visibles, únicamente las funciones
necesarias para cada usuario.
Se harán uso de metáforas visuales al menos para la representación de usuarios,
equipos, organizaciones, test y avisos.
Figura 13. Metáforas visuales para usuario, equipo, organización, test y aviso.
5.4.2. Diagrama para la navegación de la aplicación El flujo de navegación estará claramente diferenciado entre el front y el back-end, ya
que dependiendo del rol del usuario se mostrará una funcionalidad concreta a partir del
punto de entrada a la aplicación.
A continuación, se presenta la figura 14 que muestra el diagrama de navegación. Puede
observarse existen cuatro opciones para realizar una entrada a la aplicación, pero
únicamente haciendo uso del Formulario de autenticación es posible acceder a toda la
funcionalidad del módulo.
36
Figura 14. Diagrama de navegación.
5.4.3. Detalle de las interfaces Las interfaces se desarrollarán haciendo uso de la plantilla de Bootstrap de la que
dispone la empresa Formavolución. La elección de colores es corporativa por lo que
deberá ser tenida en cuenta en el conjunto de interfaces que se desarrollen para este
módulo.
A resultas de lo anterior se ha decidido que el prototipado se llevará a cabo mediante
la utilización de los diferentes elementos propios de Bootstrap de los que dispone la
herramienta utilizada.
El formulario de autenticación y de registro ha sido diseñado previamente para la
aplicación básica y se muestran en la figura 15.
37
Figura 15. Detalle del formulario de autenticación y registro.
Una vez se accede al front-end se muestra la lista de acciones que puede llevar a
cabo un usuario. También muestra los accesos a las propiedades del usuario, que pueden
ser modificadas. Es asimismo posible realizar una salida de la aplicación.
A continuación, se muestra la figura 16 en la que puede observarse un detalle del diseño
del front-end, en concreto de la pantalla que muestra un conjunto de preguntas durante la
realización de un test.
Figura 16. Detalle del front-end: Realizar test.
38
El back-end tendrá un aspecto más desarrollado y mostrará, en primer lugar, las
acciones realizables por usuarios cuyo rol necesariamente será superior al de usuario
básico. En función del rol estas acciones disponibles serán más o menos numerosas,
mostrándose la totalidad del back-end para el rol super-administrador.
La vista del menú de funcionalidades disponibles del back-end así como un conjunto de
prototipos de interfaz desarrollados en la fase de diseño se muestra en el ANEXO II.
5.5. Diseño de plan de pruebas
A continuación, se expone el plan de pruebas de calidad para el desarrollo de este
proyecto.
5.5.1. Pruebas de unidad Las pruebas de unidad se irán realizando a lo largo del desarrollo de los elementos,
que se crearán para implementar las funcionalidades del módulo. Estas pruebas servirán
para probar el correcto funcionamiento de cada elemento desarrollado.
5.5.2. Pruebas de integración Estas pruebas, que se realizarán una vez se aprueben las pruebas unitarias, se
usarán para analizar todos los elementos unitarios que componen una funcionalidad.
5.5.3. Pruebas de aceptación Pruebas finales que se utilizarán para determinar que el módulo desarrollado
cumple con las especificaciones iniciales y logra su objetivo.
5.5.4. Documentación de pruebas Toda la documentación relativa a la realización de pruebas se documentará mediante
una tabla como la que muestra la figura 17.
39
Prueba: Nombre de la prueba
Descripción: Descripción de la prueba. Resultado: Resultado de la prueba (CORRECTO/INCORRECTO). Comentarios: Comentarios sobre la prueba.
Figura 17. Plantilla para la documentación de pruebas.
40
41
6. DESARROLLO
A continuación, se presenta un resumen de la información generada durante la fase de
desarrollo del TFG.
6.1. Tecnologías usadas
Uno de los aspectos fundamentales de este proyecto era que pretendía añadir una
funcionalidad a una aplicación básica desarrollada por los becarios de la Universidad de
La Rioja durante el primer cuatrimestre. Por ello se hizo uso de la tecnología propia de
la misma, de tipo web, (en concreto de HTML5, CSS3 y PHP). Esto ha permitido
desarrollar una aplicación ejecutable en diferentes sistemas operativos con una
interfaz profesional y personalizable.
Al no tener restricciones se optó por desarrollar el código desde cero, ya que hacer
uso de frameworks como Symphony implicaría una modificación de la aplicación básica y
esto, junto con la necesidad de tiempo para formación, haría imposible el correcto desarrollo
de la funcionalidad en las horas disponibles.
Las interfaces creadas se han desarrollado haciendo uso de Bootstrap y están
basadas en una plantilla que poseía la empresa.
Existían dos tipos de documentos diferenciados para la implementación del patrón
Modelo-Vista-Controlador en el módulo. Los dos tipos de documentos estarán
desarrollados haciendo uso de la tecnología web indicada y tendrán un diseño muy
diferenciado:
Los documentos que contienen la información de la interfaz gráfica.
Los documentos nombrados como class.* que hacen la función de controlador y
permiten modificar dinámicamente la interfaz.
Para la edición de los documentos se ha utilizado el programa Notepad++, que es
un editor de texto y código fuente configurable para manejar PHP, HTML y CSS. Además,
permite el acceso y modificación de documentos mediante FTP, función imprescindible
al desarrollarse el módulo en un servidor de la empresa.
También se utilizó, en una medida infinitamente menor, Javascript. Esta utilización se
justifica en la necesidad de introducir editores What You See Is What You Get o “lo que
ves es lo que obtienes” (WYSIWYG) y de un gráfico de tipo radar. La biblioteca jQuery o
la librería D3.js hicieron posible estos añadidos.
42
6.2. Librerías empleadas
A la hora de la implementación se han utilizado diferentes librerías para facilitar el
proceso. Las principales han sido las siguientes:
1. PHPMailer: Se ha hecho uso de esta librería, previamente adaptada por
Formavolución, que nos proporciona funcionalidad para llevar a cabo el envío de
emails.
2. UploadImage: Desarrollado por la empresa, se trata de una librería que posibilita la
subida de imágenes redimensionadas a la dirección del servidor que nosotros
marquemos.
3. D3.js: Se ha hecho uso de esta librería, concretamente de la funcionalidad
desarrollada para transformar datos de forma que estos sean visibles en forma de
un gráfico de tipo radar, también llamado “polar” o “spider”. Esta librería ha sido
necesaria para poder conocer las habilidades de un usuario de un vistazo.
6.3. Desarrollo de la aplicación
En este apartado se profundiza en el desarrollo de la aplicación, dando especial
importancia a sus aspectos más destacables y a los problemas surgidos más interesantes,
así como la solución encontrada para los mismos.
6.3.1. Creación de test La aplicación desarrollada pretende posibilitar la creación de test, añadiendo todos los
datos que sean introducidos haciendo uso de la interfaz y permitiendo una navegación
fluida a lo largo de la creación de preguntas y respuestas que conformen el mismo.
Para ello se ha hecho uso de variables de sesión y de formularios HTML.
Se ha añadido también, como se ha comentado, un editor WYSIWYG y mediante
formularios se han añadido todos los campos fundamentales de test, preguntas y
respuestas.
Para posibilitar el almacenado de campos numéricos decimales ha sido tenido en
cuenta que inicialmente la aplicación estará en español, por lo que se han procesado las
cadenas introducidas en el formulario.
43
6.3.2. Manejo de test mediante paquetes Los test creados se manejarán mediante paquetes. Esta forma de agrupación posibilita
hacer visibles o no diferentes grupos de test en función de los paquetes que tenga
asignados una organización concreta.
La creación, activación, desactivación, modificación y eliminación de paquetes de test ha
sido desarrollada de manera simplista.
Se ha desarrollado toda la funcionalidad necesaria para la asignación y des
asignación de test a paquetes, bien en la creación o como una modificación de los
mismos.
Se ha desarrollado también toda la funcionalidad necesaria para la relacionar
paquetes con organizaciones. Al igual que en el caso anterior esto podrá realizarse tanto
en la creación o como una modificación de los paquetes.
6.3.3. Realización de test Una vez creados y empaquetado un test será posible para el usuario la realización del
mismo.
Se ha creado una vista que presenta un conjunto de preguntas por página, fijado el
número de preguntas en la creación del test, y permite la selección de una respuesta
por pregunta, siendo estas un input de tipo radio acompañado por la respuesta. Tanto las
respuestas como la pregunta pueden ser únicamente textuales, contener imágenes y texto
o tener únicamente una imagen. Esta vista muestra también una barra de progreso sobre
el desarrollo del test.
Una vez finalizadas todas las preguntas relativas a un test se indica la finalización del
mismo.
También se ha desarrollado una vista para test simples que para cada pregunta
únicamente presenta un grupo de radio inputs que permiten escalar el acuerdo del usuario
con el enunciado de la pregunta.
Se ha fijado que deben almacenarse todas las respuestas marcadas por el usuario, lo
que sucede cada vez se completa una página de preguntas. Esto posibilita que en caso de
que un usuario no finalice un test podrá continuarlo en el momento que desee sin que
esto provoque ningún problema en el procesado de los parámetros.
Una vez finalizado el test se almacenará el mismo como un test finalizado, eliminando el
registro que almacenaba el test en el conjunto de test detenidos.
44
En caso de que se estuviese tratando un test pendiente, se presenta la funcionalidad
para marcar test pendientes en el apartado 6.3.7, se elimina el registro del test de la tabla
que almacena los test pendientes.
6.3.4. Procesado de los parámetros de habilidades Una vez un test ha sido realizado se lleva a cabo el procesado de las habilidades en él
medidas.
Se ha optado por agrupar todas las mediciones de una cada habilidad del test
finalizado y eliminar los extremos, superior e inferior, de las mismas.
En segundo lugar, se calcula la media de los valores restantes de cada habilidad y
se almacena esta medición indicando cual es el peso del test, fijado en la creación del
mismo.
Una vez procesadas todas las habilidades, medidas en el test, se recalculan las
habilidades del usuario según el valor de las mediciones de cada habilidad y el peso
que tiene el test con el cual se obtuvieron las mismas.
6.3.5. Realización y procesado de test externamente Se ha decidido imposibilitar al usuario la realización de un test por segunda vez, pero se
ha posibilitado la opción de enviar solicitudes para que otros usuarios, o cualquier
persona ajena a la aplicación, rellenen un determinado test.
La solicitud se enviará mediante un email que contendrá la información que quiera
introducir el usuario y un enlace para la realización de test.
El enlace para la realización del test muestra información sobre el identificador del
test ya que el envío de un hash con la información cifrada se descartó al no posibilitar
la configuración del servidor un cifrado simétrico sencillo y considerarse que no era
necesario buscar soluciones más complejas, como almacenar cada hash en una nueva
entidad de la BDD preparada para ello.
Estos test se procesan de la misma manera que los test realizados por el usuario,
por lo que podrán recomenzarse haciendo uso del enlace. Una vez finalizado no podrá
volver a hacerse uso del enlace.
Esta forma de llevar a cabo las invitaciones permite al usuario enviar correos a su propia
cuenta o enviar varias solicitudes a una misma cuenta, pero es prácticamente imposible
conseguir un control absoluto, a no ser que se fije un número máximo bajo de peticiones
45
enviadas, ya que la creación de un correo electrónico actualmente no supone prácticamente
coste temporal.
Una vez finalizado el test es procesado del mismo modo que un test realizado por
el usuario, pero los resultados a recalcular serán las mediciones externas de las
habilidades de un usuario.
6.3.6. Envío de peticiones de test pendientes La funcionalidad para el envío y procesado de un test externo se ha usado como base
para posibilitar el envío de mensajes con una petición para la realización de test a un
usuario de la aplicación, que pasará a tener ese test como pendiente hasta el momento
que lo realice y se procesen las habilidades del mismo como propias.
Gracias a esta funcionalidad se permitirá al usuario repetir la realización de un test
previa petición por parte de un usuario con permisos.
6.3.7. Visualización de habilidades La visualización de habilidades será propia de cada usuario. Se ha creado una vista
que distingue para cada habilidad cual es la medición obtenida mediante test rellenados
por el propio usuario y cuál es la medición externa. Se muestran, ambas mediciones,
mediante barras de progreso.
También se ha posibilitado que el usuario despliegue un gráfico radial con las
mediciones de ambos tipos superpuestas.
Para esta vista en primer lugar deberán cargarse las habilidades propias del usuario.
En caso de no contar con mediciones de una habilidad se fijará el valor medio, de 0.5,
a esa medición.
6.3.8. Importación de preguntas de test Se ha implementado una funcionalidad que permite crear un test fijando sus preguntas,
y las habilidades medidas por éstas, en función de las líneas que componen un fichero
de texto plano.
Ha sido posible desarrollar esta importación con funciones para el manejo de ficheros
y de cadenas de caracteres multibyte, para llevar a cabo una conversión del texto
introducido a UTF-8.
La creación de preguntas ha utilizado funciones previas para la creación de test
simples.
46
Se han controlado las cadenas leídas y las inserciones para evitar la creación de test
incorrectos. Para el control de test ha sido necesario desarrollar funcionalidades para
la eliminación de test, preguntas y relaciones.
6.3.9. Creación de una habilidad y problemas surgidos Se ha posibilitado la creación de habilidades, una funcionalidad que no había sido fijada
en el alcance, mediante un formulario simple, pues de otra forma las mediciones de los test
estarían restringidas a las 12 habilidades iniciales.
Esta funcionalidad simple desveló un problema en el modo de almacenamiento de
las habilidades sin mediciones de un usuario. Al no conocerse la necesidad de esta
funcionalidad en un principio se fijó que se almacenaría un valor por defecto por cada
habilidad disponible en el momento en que un usuario era creado. Esta forma de dar
valores iniciales a cada habilidad se convierte en una operación altamente costosa si
para cada habilidad añadida debe añadirse una medición, con el valor por defecto, a
cada usuario de la aplicación.
Se decidió por tanto que no se van a almacenar habilidades por defecto, únicamente
las derivadas de la realización del test y que para la muestra de las habilidades de un
usuario se poblarán con el valor por defecto las habilidades sin entradas, sin afectar
a la BDD.
6.3.10. Errores con la librería UploadImage Como había introducido en el apartado segundo del desarrollo, la librería que pretendía
usarse para el almacenamiento de imágenes sería la propia de la empresa.
Al hacer uso de la misma, que inicialmente estaba planteada para la subida imágenes
de avatares de usuarios, se ha percibido que existen ciertos errores en la subida de
archivos, ya que el renombrado de los mismos no se llevaba a cabo correctamente. Una
vez subsanados los mismos se descubrió que la ruta donde se almacenaba la imagen no
podía ser modificada sin provocar un error en la librería.
Con la ayuda del desarrollador de la librería se descubrió que el error estaba provocado
por la falta de permisos sobre el directorio en el cual se quería llevar a cabo la subida de
imágenes y al modificar los permisos del mismo se pudo llevar a cabo la subida de
imágenes sin problemas.
47
7. PRUEBAS
A continuación, se presenta un resumen de la información generada al llevar a cabo
pruebas durante la fase de desarrollo y pruebas TFG. Para poder realizar las mismas se
hizo una pequeña prueba completa del módulo.
7.1. Pruebas unitarias
Se han llevado a cabo una serie de pruebas unitarias en las cuales sólo se hacía uso de
las funcionalidades que se querían probar.
7.1.1. Creación de un test Para probar correctamente la creación de un test se deben utilizar todas las formas
disponibles de creación de preguntas y respuestas.
Prueba: Crear test
Descripción: Un usuario con permisos suficientes llevará a cabo la creación de un test explorando todas las formas posibles de creación de preguntas y respuestas.
Resultado: La información propia de los test así como sus preguntas y respuestas son correctamente almacenadas (CORRECTO).
Comentarios: El test se crea sin estar asignado un paquete.
7.1.2. Creación de un paquete La creación de un paquete es una funcionalidad sencilla.
Prueba: Crear paquete
Descripción: Un usuario con permisos suficientes llevará a cabo la creación de un paquete asignando al mismo un conjunto de test.
Resultado: La información propia de los paquetes así como sus relaciones con un conjunto de test son correctamente almacenadas (CORRECTO).
Comentarios: El paquete se crea activado por defecto.
7.1.3. Realización de un test La prueba de la realización de un test se ha llevado a cabo sobre el test creado en la
prueba 7.1.1 por lo que las preguntas del mismo tenían diferentes formatos, así como sus
respuestas. Esto se ha marcado así para poder explorar todos los elementos creados en la
vista.
48
Prueba: Realizar test
Descripción: Un usuario con permisos suficientes llevará a cabo la realización de un test marcando una respuesta para cada pregunta.
Resultado: La información propia de la realización del test - relaciones entre el usuario, el test y las preguntas marcadas – y las habilidades procesadas son correctamente almacenadas. (CORRECTO).
Comentarios: El test pasa a estar finalizado y no puede volver a ser realizado por el usuario.
7.1.4. Envío de solicitud de un test El envío de una solicitud únicamente comprueba que el campo introducido para el email
tiene un formato correcto.
Prueba: Enviar solicitud de test
Descripción: Un usuario con permisos suficientes lleva a cabo el envío de un email mediante el cual posibilita a la persona destinataria la realización de un test, sin necesidad de que esa persona sea un usuario.
Resultado: Se almacena la información necesaria para que el test pueda ser realizado por cualquier persona y se lleva a cabo el envío de un mail a la dirección introducida (CORRECTO).
Comentarios: El receptor de la solicitud podrá realizar el test de una manera idéntica a un usuario de la aplicación.
7.1.5. Reanudar y detener un test La vista para la selección del test a realizar mostrará opciones diferentes para un usuario
en función de que se trate de un test a realizar o de un test detenido.
Prueba: Reanudar test
Descripción: Un usuario con permisos suficientes y que había dejado sin finalizar un test lo reanuda completando únicamente un bloque de preguntas, es decir, dejándolo, una vez más, sin finalizar.
Resultado: Se carga correctamente la información ya almacenada de la realización de test. Se almacena la información generada al rellenar las preguntas (CORRECTO).
Comentarios: Las habilidades medidas con el test no son procesadas hasta la finalización del mismo.
7.2. Pruebas de integración
Se va a llevar a cabo una única prueba de integración en la cual se creará un test y se llevarán a cabo todas las operaciones disponibles haciendo uso del mismo:
1. Creación de un test. 2. Creación de un paquete. 3. Asignación de un test a un paquete. 4. Realización del test. 5. Envío de una solicitud de realización del test. 6. Visualización de una comparativa entre la medición propia y externa de las
habilidades.
49
7.2.1. Prueba de integración La prueba de integración lleva a cabo las operaciones indicadas.
Prueba: Prueba de integración
Descripción: Prueba de integración en la que se realizarán todas las tareas posibles haciendo uso del módulo desarrollado.
Resultado: Todas las tareas se realizan adecuadamente y los datos quedan debidamente almacenados (CORRECTO).
Comentarios: El resultado obtenido es el esperado.
50
51
8. CONCLUSIONES
Al reflexionar sobre los problemas surgidos durante es desarrollo del TFG queda claro
que uno de los más graves, que ha retrasado la subida de imágenes, ha surgido por la
utilización de librerías insuficientemente testeadas y que no habían sido comentadas. Esto
podría haberse evitado si cada módulo desarrollado por la empresa hubiese sido
correctamente testeado y documentado.
Otro punto que merece atención son las desviaciones del alcance durante el
desarrollo de un trabajo. El desarrollar un módulo escalable ha provocado que cuando se
daba por finalizado el TFG se fijasen nuevas vías de ampliación por parte de la empresa.
El acuerdo inicial sobre las funcionalidades a implementar durante el TFG ha evitado
que las funcionalidades que requiriesen un coste temporal excesivo tuviesen que
desarrollarse como parte del TFG. Los cambios que sí han sido llevados a cabo han
provocado modificaciones notables de la lógica como el presentado para la adición de
nuevas habilidades.
Por otro lado, la realización de módulos sobre copias independientes de la misma
aplicación básica provoca un alto coste temporal cuando se lleve a cabo la integración
de estos módulos. Esto podría haberse evitado haciendo uso de una herramienta de
control de versiones. Al necesitar llevar a cabo la integración manualmente, Javier y yo,
sufrimos conflictos derivados de modificaciones mínimas que hubiesen sido fácilmente
identificables haciendo uso de, por ejemplo, Git.
Junto con lo anteriormente mencionado el hacer uso de una BDD común y desarrollar
ficheros similares, a los de mis compañeros de la UR, dejó claro que era necesario llevar a
cabo una documentación y una nomenclatura de ficheros reglada para conseguir un
resultado uniforme.
8.1. Aprendizaje individual
El desarrollo del TFG me ha permitido reforzar mis conocimientos de PHP y MySQL,
también me ha permitido afianzar mis conocimientos de jQuery y me ha permitido poner
en práctica lo aprendido sobre la gestión de proyectos.
52
8.2. Aspectos a recalcar
El módulo desarrollado ha hecho uso de plantillas responsivas desarrolladas haciendo
uso del framework Bootstrap por lo que puede visualizarse tanto en equipos móviles como
de escritorio.
Es también totalmente escalable, ya podrían añadirse nuevas funcionalidades sin
provocar errores en las ya desarrolladas.
He cumplido los objetivos fijados al comienzo del TFG en el plazo establecido
mediante el seguimiento de un plan de manera metódica y organizada. Este proceso queda
plasmado con la aplicación desarrollada y la memoria.
8.3. Ampliaciones
Pese a haber cumplido con los objetivos iniciales fijados y haber desarrollado alguna
funcionalidad complementaria, han surgido posibles ampliaciones que sería interesante
desarrollar en un futuro:
Permitir la modificación de test, preguntas y respuestas. Esta funcionalidad
facilitará enormemente la gestión de test y facilitará la creación de los mismos en
caso de que la empresa decida que organizaciones que hagan uso de la aplicación
pueden crear test.
Crear una funcionalidad que permita la importación completa de test. A
diferencia de la funcionalidad desarrollada se marcarán todas las características de
un test en el documento importado. Se ha fijado por parte de la empresa que el
fichero a importar se generaría haciendo uso de Microsoft Excel.
Crear una vista de test que en la cual las respuestas no serán seleccionables
sino ordenables. El procesado de estos test diferirá del desarrollado en este TFG.
Crear una vista comparativa de las habilidades en un momento determinado con
respecto a las habilidades del usuario en el momento de la consulta. Esta vista
deberá mostrar las habilidades mediante barras de progreso y gráficas, al igual que
la vista para desarrollada ya en este módulo.
Crea una nueva vista para la realización de test que permita que las imágenes
cargadas se visualicen como una única imagen. Se pretende que de esta forma se
pueda obtener una funcionalidad similar al marcado de zonas de imagen por
coordenadas pero aprovechando la funcionalidad ya desarrollada en este módulo.
53
9. BIBLIOGRAFÍA
A continuación, se presenta la bibliografía utilizada para el desarrollo de este TFG:
Guías y manuales adquiridos por Formavolución sobre desarrollo PHP.
Apuntes sobre el desarrollo de aplicación web por Francisco García Izquierdo de la
asignatura Programación de Aplicaciones Web.
Apuntes sobre EVS y Requisitos, Análisis, Diseño y Pruebas por Juan José Olarte
Larrea de la asignatura Ingeniería del Software.
Manuales de PHP:
o https://secure.php.net/manual/es/index.php.
o http://stackoverflow.com/.
Tutorial de Bootstrap:
o http://www.w3schools.com/bootstrap/.
Manual de Bootstrap:
o https://librosweb.es/libro/bootstrap_3/.
Ejemplos de gráficas:
o http://www.visualcinnamon.com/.
