Embed Size (px)
Citation preview
Javier Ruiz Sáenz de Pipaón
Juan José Olarte Larrea
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
Desarrollo de una aplicación web de recomendacionessiguiendo el patrón MVC
Autor/es
© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2016
publicaciones.unirioja.esE-mail: [email protected]
Desarrollo de una aplicación web de recomendaciones siguiendo el patrónMVC, trabajo fin de grado
de Javier Ruiz Sáenz de Pipaón, dirigido por Juan José Olarte Larrea (publicado por la 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
Desarrollo de una aplicación web de recomendaciones
siguiendo el patrón MVC
Alumno:
Javier Ruiz Sáenz de Pipaón
Tutores:
Juan José Olarte Larrea
Logroño, junio, 2016
1
Resumen
A día de hoy existen diversos sitios web o aplicaciones, en las que puedes solicitar un trabajo.
FORMAVOLUCION quiere formar una red donde las grandes y medianas empresas estén
comunicadas con los usuarios y de esta forma poder recomendar a la persona más adecuada
para cada puesto de trabajo. Esta selección se realiza a través de determinados test que han
desarrollado para tal efecto.
Además, mediante esta aplicación, no sólo pueden dirigir sus equipos de trabajo sino que
también les permite la confección de los mismos de una forma sencilla, ya que la aplicación
recomienda a la persona más adecuada para desarrollar cada función dentro del equipo
teniendo en cuenta sus características, tanto humanas como profesionales.
Abstract
Now a days there are several websites, which you can ask for a job.
FORMAVOLUCION wants to make a network, where the big and medium sized enterprises are
connected with users, in order to recommend a position intelligently, doing the test that they
have for it.
In addition to the management of the company´s teams, which using this application they can
control the make of theirs multidisciplinary teams in an easy way, because the application
recommend the best person for the position, considering his field and human skills.
2
Índice Objetivo del TFG ................................................................................................................................... 4
Contexto ............................................................................................................................................... 4
Desarrollo ............................................................................................................................................. 5
Alcance ................................................................................................................................................. 6
Planifiación ........................................................................................................................................... 7
Gestión del proyecto .......................................................................................................................... 11
Seguimiento ................................................................................................................................... 11
Análisis ............................................................................................................................................... 16
Identificación de roles .................................................................................................................... 16
Modelo de casos de uso ................................................................................................................. 20
Requisitos: .......................................................................................................................................... 23
Requisitos funcionales ................................................................................................................... 23
Requisitos no funcionales .............................................................................................................. 23
Diseño ................................................................................................................................................ 25
Base de datos ................................................................................................................................. 25
Páginas ........................................................................................................................................... 28
Diagrama de navegación ............................................................................................................ 36
Diseño Arquitectónico ................................................................................................................... 37
Implementación ................................................................................................................................. 38
Clases usadas para el desarrollo .................................................................................................... 38
phpmailer ................................................................................................................................... 38
imageresize ................................................................................................................................ 38
Clases creadas para el desarrollo ................................................................................................... 39
Gestión de las operaciones ............................................................................................................ 39
Creación de un paginador .............................................................................................................. 40
Creación de la jerarquía de la organización ................................................................................... 42
3
Recomendación de trabajadores ................................................................................................... 44
Rediseños ....................................................................................................................................... 45
Problemas encontrados ................................................................................................................. 46
Calidad ................................................................................................................................................ 47
Rendimiento ................................................................................................................................... 47
Pruebas........................................................................................................................................... 47
Conclusiones ...................................................................................................................................... 48
Agradecimientos ................................................................................................................................ 49
Bibliografía ......................................................................................................................................... 50
4
Objetivo del TFG
El objetivo de este Trabajo de Fin de Grado (TFG), es añadir un módulo a la aplicación Ítaca que será
desarrollada por los alumnos de la Universidad de La Rioja.
La aplicación Ítaca tiene como misión encargarse de la evaluación de usuarios, recomendaciones de
cursos, gestión de organizaciones, y recomendación de usuarios para un puesto.
Dicho módulo sirve para la gestión de organizaciones y equipos, así como para la recomendación de
usuarios para puestos, 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 evaluaciones por medio de test.
Contexto
La aplicación Ítaca puede tener utilidad tanto en el ámbito institucional, por medio de la
recomendación de usuarios para los puestos, como en la formación de empleados, ya que en esta
aplicación web (Ítaca) se recomiendan cursos acorde a las capacidades de cada uno.
El conocimiento de las capacidades de los usuarios 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 misma organización. Esta aplicación está dirigida a los departamentos
de recursos humanos.
Dentro de la empresa ya existía una aplicación con el nombre de Ítaca (vieja Ítaca) que no podía
ofrecer la funcionalidad que se presenta en este proyecto, ya que se realizó de forma poco
extensible y con archivos muy grandes a los que era casi imposible hacerles cualquier modificación.
Esto hace imposible ir evolucionando la aplicación en un futuro y añadirle la funcionalidad deseada
por parte de la empresa. Por estos motivos se decidió rediseñar dicha aplicación para hacerla
modular y extensible (nueva Ítaca), así como añadirle funcionalidad que antes era inexistente e
imposible realizar con la antigua Ítaca.
Por ello:
Durante el primer cuatrimestre de este curso (durante Las prácticas de empresa), 2015-
2016, mi compañero Daniel Espinosa y yo (Javier Ruiz), planificamos y diseñamos el portal
sobre el que ahora se integrarán las distintas funcionalidades de que consta esta aplicación.
Por otro lado, además de proyectar y elaborar una primera parte de la base de datos,
también partimos de cero en la elaboración de Ítaca; añadiendo, quitando o modificando las
5
funciones básicas tales como la autenticación, y rediseñamos la zona de usuarios en sus
diferentes aspectos: envío de correo para la activación de la cuenta y cambios en el perfil.
Los alumnos de la Universidad de La Rioja que realizaremos nuestro TFG en la empresa nos
dedicaremos a añadir nuevas funcionalidades a la aplicación básica desarrollada (la que se
hizo durante las prácticas).
o Daniel Espinosa: Gestión, creación y eliminación de test y las habilidades de los
usuarios.
o Marina Blanco: Gestión de curos.
o Yo (Javier Ruiz): Gestión de organizaciones, equipos, permisos y recomendación de
trabajadores.
Es de suponer que este desarrollo previo marcará cómo va a realizarse el desarrollo de los TFG en
esta empresa.
Desarrollo
La aplicación básica (la realizada en las prácticas), se desarrolló en PHP, sin hacer uso de frameworks,
ya que la realización previa del inicio de este portal se hizo en PHP y como éste, es un lenguaje
válido para la realización de programación web se seguirá usando en el desarrollo del TFG. La
información de la que hacía uso este portal se almacenó en una base de datos (BDD) en MySQL que
se ha administrado haciendo uso de la herramienta web phpMyAdmin. Para el diseño de la
aplicación web se hará uso de una plantilla de Bootstrap comprada por la empresa, que contiene
elementos prediseñados con su respectivo HTML y CSS, esta plantilla es la que usa la empresa
normalmente para el desarrollo web, por lo que se nos sugirió utilizarla para el desarrollo de la
nueva Ítaca. Para la modificación del código de HTML y programación en PHP se usará el programa
Notepad++, que mediante el plugin NppFTP permite conectarse con el servidor donde están
alojados los ficheros de la aplicación y guardarlos allí de forma automática, al principio fuimos a usar
aptana pero el repositorio no estaba disponible, por lo que decidimos trabajar con Notepad para no
demorar el desarrollo. En nuestro caso el servidor se simula mediante una máquina virtual, con el
sistema operativo Debian, que está formado por apache, MariaDB y phpMyadmin.
6
Alcance
Se pretende añadir a la aplicación toda la funcionalidad necesaria para la ayuda de selección de
usuarios para puestos de trabajo en función de sus capacidades. Estos resultados para la selección
estarán disponibles en una tabla.
La aplicación comparará las habilidades de los candidatos para un puesto de trabajo dentro de un
grupo de selección. Esta operación sólo la podrá hacer un administrador. Un usuario con permisos
de administrador podrá gestionar tanto la selección de candidatos como la creación de grupos de
trabajo nuevos. Los grupos o equipos de trabajo serán, en realidad, un conjunto de puestos. El
manejo de estos puestos permitirá la creación de equipos multidisciplinares o de equipos centrados
en un determinado perfil. Toda la información relativa a los puestos y grupos de trabajo, así como
de las solicitudes deberá ser almacenada.
La selección se llevará a cabo de la siguiente manera: en primer lugar, el administrador asignará
para cada puesto un maestro (persona o perfil mejor indicado para el puesto) que tendrá que
realizar un test para determinar sus características. En segundo lugar, el administrador creará un
grupo de selección, formados por los candidatos a dicho puesto. Estos realizarán la misma prueba
que el maestro. Posteriormente se compararán los resultados obtenidos con el maestro y se
recomendará al mejor para esa función. El administrador es libre de elegir al que él quiera, sin tener
en cuenta la recomendación de la aplicación. También se tendrá que tener en cuenta a las personas
que el administrador pueda elegir para el grupo de selección, limitando los niveles de acceso a la
aplicación, ya que se diferenciarán los casos en el que se quiera seleccionar a una persona
jerárquicamente superior a él, inferior o igual o menor y el caso en el que se quiera añadir a una
persona que no esté en la empresa.
Para que una persona pase a formar parte de un grupo de selección se le enviará una invitación, si
el usuario no contesta se le enviará u mensaje de recordatorio, si pasados un número concreto de
mensajes no contesta se tomarán las medidas pertinentes determinadas por la política de la
empresa.
Esto implicará la necesidad de implementar la creación, eliminación y modificación de un puesto.
Como el portal está pensado para que lo utilicen varias organizaciones, hay que hacer una correcta
separación de los recursos de las mismas, además para ello hay que hacer un exhaustivo análisis de
los roles que contendrá este módulo.
7
Planifiación
Se utilizará una metodología Scrum (metodología ágil) para el desarrollo del trabajo, aunque no se
seguirá esta metodología de forma exhaustiva, ya que los roles como el Product Ower, Scrum master
y el equipo de desarrollo estarán formados por la misma persona.
Siguiendo esta metodología ágil se realizaran sprints de una duración estimada entre dos y tres
semanas.
Este proyecto se comienza durante el transcurso del segundo cuatrimestre (15-02-2016).
Para llevar a cabo la planificación, el proyecto se divide en tareas de un tamaño óptimo para realizar
un correcto seguimiento y control de las mismas.
En la figura 1 se muestran las tareas más significativas con una breve descripción de cada una de
ellas, así como el tiempo planificado que puede costar cada una de ellas, sumando en total 300
horas.
8
Nombre de la tarea Descripción de la tarea Tiempo
estimado
(horas)
Planificación Planificar el grueso del proyecto 19 Análisis Lleva a cabo un análisis del módulo de la aplicación
de Ítaca 39
Identificar Identificar los roles y operaciones que hace cada rol 15
Diagramas Realización de diagramas para la explicación de las operaciones.
15
Pila del producto Crear por prioridades las necesidades de la fase de implementación.
5
Requisitos Definir los requisitos con el cliente 4
Diseño Diseño del módulo, además de la realización de diagramas para ver la interacción del módulo.
50
Diseño de interfaz Diseñar mediante plantillas de Bootstrap una interfaz intuitiva y útil, que cumpla toda la funcionalidad
35
Diagrama de navegación
Diseñar la navegación entre las ventanas de la aplicación 3
Diseño de pruebas Diseño de pruebas para comprobar que la aplicación no falle frente a datos críticos.
2
Diseño de base de datos
10
Implementación Realización del código para el desarrollo del módulo.
119
Separación del portal
Separar el portal para que cada organización tenga separada su zona.
3
Separación entre roles
Asegurarse de que cada rol solo puede hacer lo que el rol le permita, es decir, que no pueda hacer operaciones ilegitimas.
10
Base de datos Diseño e implementación de la base de datos para garantizar una correcta gestión de los roles, organizaciones y la elección inteligente del personal.
10
Recomendación de trabajadores
Creación de un grupo de selección dentro de un puesto, además de mandar la realización de tests a los diferentes participantes para su posterior evaluación.
30
Gestión de equipos Proporcionar una herramienta usable para la correcta gestión de los equipos de trabajo.
35
Gestión de puestos Proporcionar una herramienta usable para la correcta gestión de los puestos de trabajo.
28
Pruebas Realización de las pruebas diseñadas anteriormente. 3
Redacción de la memoria
Redacción de la memoria, que se llevará a cabo a lo largo del transcurso del trabajo.
58
Reuniones y seguimiento
Reuniones con el tutor del TFG y con los miembros de la empresa, además de realizar un seguimiento del proyecto
15
Total 300 Figura 1 - Planificación
9
En la figura 2 se muestra el gráfico de Gantt que representa cómo se va a seguir la elaboración del proyecto a lo largo de este cuatrimestre.
Figura 2- Gantt
10
Calendario
A continuación se muestra un calendario (figura 3) en el que están marcados los hitos más
importantes y los días festivos, según el horario y las horas dedicadas al proyecto, se prevé que se
realizarán las horas previstas.
Febrero Marzo Abril L M X J V S D L M X J V S D L M X J V S D
1 2 3 4 5 6 1 2 3
7 8 9 10 11 12 13 4 5 6 7 8 9 10
15 16 17 18 19 20 21 14 15 16 17 18 19 20 11 12 13 14 15 16 17
22 23 24 25 26 27 28 21 22 23 24 25 26 27 18 19 20 21 22 23 24
29 28 29 30 31 25 26 27 28 29 30
Mayo Junio L M X J V S D L M X J V S D
1 1 2 3 4 5
2 3 4 5 6 7 8 6 7 8 9 10 11 12
9 10 11 12 13 14 15 13 14 15 16 17 18 19
16 17 18 19 20 21 22 20 21 22 23 24 25 26
23 24 25 26 27 28 29 27 28 29 30
30 31 Figura 3- Calendario
Leyenda
Representa un hito (hecho importante en el proyecto)
Representa día festivo.
Los fines de semana están marcados en rojo Hitos
15-02-2016: Inicio de proyecto
25-02-2016: Fin de planificación
8-03-2016: Fin análisis
29-03-2016: Fin de diseño y creación de prototipos
21-04-2016: Primer prototipo funcional
5-05-2016: Segundo prototipo funcional
19-05-2016: Tercer prototipo funcional
2-06-2016: Fin de desarrollo
15-06-2016: Fin de pruebas
17-06-2016: Fin de TFG
22-06-2016: Depósito de TFG
11
Gestión del proyecto
Seguimiento
A continuación se muestra el seguimiento individual, el cual contiene las tareas de forma más
desgranada, y las horas planificadas para cada tarea seguido de las horas reales empleadas.
Sprint de planificación (15/02/2016-29/02/2016)
Nombre Horas estimadas
Horas reales Desviación
Fecha inicio Fecha Fin
Planificación 13.5 13 -2 18/02/2016 25/02/2016 reuniones 4 4 0 15/02/2016 29/02/2016 Redacción de la memoria 5 5 0 15/02/2016 29/02/2016 Total 22.5 22
Sprint 1 (29/02/2016-13/02/2016)
Nombre Horas estimadas
Horas reales Desviación
Fecha inicio Fecha Fin
Requisitos 4 4 0 29/02/2016 29/02/2016 Análisis 35 29 -6 29/02/2016 03/03/2016
Pila del producto 5 6 1 01/03/2016 03/03/2016 Identificar 15 13 -2 29/02/2016 03/03/2016 Diagramas 15 10 -5 01/03/2016 02/03/2016
Redacción de la memoria 10 8 -2 29/02/2016 13/03/2016 Diseño 6 7 1 09/03/2016 12/03/2016
Diseño de interfaz 6 7 1 09/03/2016 13/03/2016 Total 55 48
Sprint 2 (14/03/2016-28/03/2016)
Nombre Horas estimadas
Horas reales Desviación
Fecha inicio Fecha Fin
Planificación 3 3 0 14/03/2016 14/03/2016 Diseño 42 46 4 14/03/2016 28/03/2016
Diseño de interfaz 29 35 6 14/03/2016 27/03/2016 Diseño Base de datos 10 10 0 14/03/2016 22/03/2016 Diagrama de navegación 3 1 -2 27/03/2016 18/03/2016
Reuniones 1 1 0 21/03/2016 21/03/2016 Redacción de la memoria 0 1 1 28/03/2016 28/03/2016 Total 46 51
12
Sprint 3 (4/04/2016-21/04/2016)
Nombre Horas estimadas
Horas reales Desviación
Fecha inicio Fecha Fin
Planificación Sprint 1 1 0 04/04/2016 04/04/2016 Rellenar base de datos 4 5 1 05/04/2016 06/04/2016 Redacción de la memoria 5 6 04/04/2016 21/04/2016 Implementación 31 36 5 06/04/2016 21/04/2016
separación roles 10 10 0 06/04/2016 21/04/2016 Organizar panel de administración 4 4 0 13/04/2016 14/04/2016 Añadir Usuario a Organización 2 2 0 06/04/2016 07/04/2016 Crear Organización 3 2 -1 06/04/2016 07/04/2016 Crear y eliminar Equipo 3 7 4 09/04/2016 14/04/2016 ListarEquipos 3 5 2 15/04/2016 20/04/2016 Crear y eliminar puesto 3 2 -1 20/04/2016 21/04/2016 Crear la visualización de equipo
con sus puestos 3 4 1 21/04/2016 21/04/2016 Reuniones 2 2 0 21/04/2016 21/04/2016 Total 43 50
Sprint 4 (21/04/2016-06/05/2016)
Nombre Horas estimadas
Horas reales Desviación
Fecha inicio Fecha Fin
Planificación Sprint 0.5 0.5 0 21/04/2016 21/04/2016 Redacción de la memoria 8 10 2 21/04/2016 06/05/2016 Implementación 39 48 9 21/04/2016 06/05/2016
Mostrar puesto 3 5 2 21/04/2016 22/04/2016 Añadir y eliminar miembro a
equipo 6 8 2 25/04/2016 26/04/2016 Creación de un grupo de selección 6 5 -1 27/04/2016 27/04/2016 Añadir y eliminar miembro a
grupo de selección 7 8 1 28/04/2016 29/04/2016 Ver jerarquía 20 22 2 02/05/2016 06/05/2016
Reuniones 1 1 0 05/05/2016 05/05/2016 Total 48.5 59.5 11
Nombre Horas estimadas
Horas reales Desviación
Fecha inicio Fecha Fin
Planificación Sprint 0.5 0.5 0 09/05/2016 09/05/2016 Redacción de la memoria 10 10 0 09/05/2016 19/05/2016 Implementación 36 33 09/05/2016 19/05/2016
Añadir miembro especial a equipo y selección 6 6 0 09/05/2016 10/05/2016
Sistema de mensajes 20 20 0 11/05/2016 17/05/2016 envío de mensajes de invitación 3 2 -1 18/05/2016 18/05/2016 Aceptación del mensaje 3 2 -1 18/05/2016 18/05/2016 Rechazo del mensaje 1 1 0 18/05/2016 18/05/2016 Eliminación del mensaje 3 2 -1 19/05/2016 19/05/2016
Reuniones 1 1 0 19/05/2016 19/05/2016 Total 47.5 44.5
13
Sprint 6 (23/05/2016-06/06/2016)
Nombre Horas estimadas
Horas reales Desviación
Fecha inicio Fecha Fin
Planificación Sprint 0.5 0.5 0 23/05/2016 23/05/2016 Redacción de la memoria 10 15 5 23/05/2016 06/06/2016 Implementación 9 8 23/05/2016 19/05/2016
Listar equipos a los que pertenece un usuario 3 1 -2 23/05/2016 23/05/2016
Listar puestos 2 2 0 23/05/2016 23/05/2016 Listar puestos a los que pertenece
un usuario 2 2 0 23/05/2016 23/05/2016 Recomendación de usuarios 2 3 1
Reuniones 2 1 -1 19/05/2016 19/05/2016 Total 21.5 24.5
Sprint 7 (6/06/2016-20/06/2016)
Nombre Horas estimadas
Horas reales Desviación
Fecha inicio Fecha Fin
Redacción de la memoria 10 10 0 06/06/2016 20/06/2016 Reuniones 4 4 06/06/2016 20/06/2016 Pruebas 2 2 06/06/2016 06/06/2016 Total 16 16
Figura 4- Seguimiento individual
Real Planificado
Planificación 18.5 19
Análisis 33 39
Diseño 55 50
reuniones y seguimiento 14 15
Redacción 65 58
Implementación 130 119
TOTAL 315.5 300 Figura 5- Tabla tiempo real vs planificado
14
Figura 6- Tiempo real vs planificado
Figura 7- Tiempo real vs planificado
Como se observa en la figura 7 Durante el desarrollo del proyecto se han cumplido las fases y los
hitos adecuadamente.
Durante la realización del proyecto he tenido algunos problemas que en cierta forma han influido
en un aumento de horas de trabajo, estos problemas se describirán más adelante.
0
50
100
150
200
250
300
350
Planificación Análisis Diseño reuniones yseguimiento
Redacción Iplementacion TOTAL
Horas reales vs planificadas
Real Planificado
0
20
40
60
80
100
120
140
160
180
200
220
240
260
280
300
320
Sprint 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7
Horas planificadas y reales
PLANIFICADAS REALES
15
En las figuras 8 y 9 se muestra a modo de ejemplo el progreso de realización del proyecto, gracias a
la herramienta proporcionada por la universidad. La figura 8 corresponde al 15 de mayo, mientras
que la figura 9 hace referencia al día 1 de Junio
Figura 8- progreso (15-05-2016)
Figura 9- progreso (01-06-2016)
Además de realizar un seguimiento individual (figura 4), se aprovechó la herramienta facilitada por
la Universidad de la Rioja para realizar un seguimiento comparativo con el resto de proyectos
(figura 6) que sirvió para comprobar que el desarrollo del proyecto se encontraba en todo
momento dentro de la media.
16
Figura 10- progreso comparativo (15-05-2016)
Análisis
En este apartado se muestran los aspectos más importantes del análisis realizado para el desarrollo
del proyecto. A partir de este punto de la memoria, todo lo que se comenta se refiere al módulo
que estoy llevando a cabo en mi proyecto, enmarcado dentro de la aplicación Ítaca.
Identificación de roles
El número de roles identificados en la gestión de una organización es tan amplio, debido a que la
empresa quería hacer una distinción notoria en cuento a los permisos de añadir usuarios a grupos
o puestos. Por ello cada grupo de administración (excepto el administrador global de una
organización) se divide según las combinaciones de los permisos de añadir.
AdminFormavolucion
Administrador capaz de hacer cualquier operación y gestionar todo el portal web. A cargo de este
rol estará un empleado de Formavolucion, empresa dueña del portal.
Súper Admin
Será el administrador de una organización, encargado de la gestión de la aplicación en su empresa,
tendrá permisos para crear grupos, eliminarlos, añadir empleados y eliminarlos.
Puede cambiar roles a un nivel inferior del suyo, nunca igual o superior.
Admin
Administrador de un grupo o de varios, tiene la potestad de añadir y eliminar participantes de los
grupos, el administrador de un grupo no tiene por qué ser un participante del grupo.
17
Existen diferentes niveles de este rol, los niveles de este rol se diferencian en los permisos que tiene
para poder añadir a los grupos de trabajo o de selección los tres tipos de personas mencionadas en
el punto dos del apartado de requisitos. Estos diferentes permisos vienen dados por un rol superior.
Admin A
Pueden añadir a los tres tipos de personas, es decir, a las personas que son jerárquicamente
superiores en la misma empresa, personas con su mismo o inferior nivel jerárquico y a las
personas que no forman parte de la empresa (ajenas a la empresa).
Admin B
Puede añadir personas que no formen parte de la empresa y a personas con su mismo o
inferior nivel jerárquico dentro de la misma empresa.
Admin C
Puede añadir a cualquier persona que pertenezca a su misma empresa, es decir, que puede
añadir a personas de la empresa impedientemente de su nivel jerárquico. Si no se especifica
nada será el admin por defecto.
Admin D
Solo puede añadir al personal de la misma empresa que está debajo o al mismo nivel
jerárquicamente.
Director
El rol de director de un grupo solo se le puede dar a un participante del mismo grupo, si dicha
persona está en más de un grupo puede ser director de varios. El director es el encargado de
gestionar los grupos una vez creados. El director se divide en subroles dependiendo de las personas
a las que puede añadir al igual que los distintos niveles del Admin, el que elige de qué tipo de director
se va a ser es un rol superior.
Director A
Pueden añadir a los tres tipos de personas, es decir, a las personas que son jerárquicamente
superiores en la misma empresa, personas con su mismo o inferior nivel jerárquico y a las
personas que no forman parte de la empresa (ajenas a la empresa).
Director B
Puede añadir personas que no formen parte de la empresa y a personas con su mismo o
inferior nivel jerárquico dentro de la misma empresa.
18
Director C
Puede añadir a cualquier persona que pertenezca a su misma empresa, es decir, que puede
añadir a personas de la empresa impedientemente de su nivel jerárquico.
Director D
Solo puede añadir al personal de la misma empresa que está debajo o al mismo nivel
jerárquicamente. Si no se especifica nada será el director por defecto.
Usuario Medio
Usuario que está dentro de una empresa en la aplicación, puede hacer tests, solicitar que hagan un
test y formar parte de un grupo de trabajo.
Básico
Está registrado en la aplicación, operacionalmente en este módulo puede realizar prácticamente
todas las operaciones de un usuario medio, pero conceptualmente es distinto.
Foráneo
Usuario que no está autenticado dentro de la aplicación, pero tiene la capacidad de realizar test, ya
que para la evaluación de los usuarios, se envían test a diferente personal para que evalúen a dicho
usuario.
A continuación, viene una tabla que está dividida en dos partes, en la que se expone las funciones
que va a tener la aplicación y los roles que las puede llevar a cabo.
19
Figura 11- operaciones de los roles
Tarea Admin
Formavolucion
Super
admin
admin A B C D Director A B C D Usuario
medio
Básico
Crear/Eliminar puesto x x x x x x x x x x x x
Añadir miembro a
organización
x x
Listar usuarios de la
organización
x x
Listar equipos de
organización
x x x x x x x
Listar puestos x x x x x x x
Listar mis equipos x x x x x x x x x x x x x
Listar mis puestos x x x x x x x x x x x x x
Aceptar invitación x x x x x x x x x x x x x x
Rechazar invitación x x x x x x x x x x x x x x
Asignar un maestro a un
puesto
x x x x x x x x x x x x
Crear un grupo de
selección
x x x x x x x x x x x x
Añadir persona igual o
inferior jerárquicamente
x x x x x x x x x x x x
Añadir persona
jerárquicamente
superior
x x x x x x x
Añadir persona ajena a
la empresa
x x x x x x
Eliminar persona de un
grupo de selección
x x x x x x x x x x x x
mandar test x x x x x x x x x x x x
comprobar si se ha
hecho test
x x x x x x x x x x x x
recomendar personas a
puesto
x x x x x x x x x x x x
Elegir persona para el
puesto
x x x x x x x x x x x x
Eliminar persona de un
puesto
X x x x x x x x x x x x
Modificar equipo x x x x x x x
Eliminar equipo x x x x x x x
20
Modelo de casos de uso
En esta sección se incluyen los casos de uso más relevantes del sistema. No vienen los distintos tipos
de roles (Admin A, Admin B, Director A,…), ya que vienen explicados anteriormente. Los roles de
Admin y de Director tienen los permisos por defecto.
Figura 12- Diagrama cdu
21
Descripción de casos de uso Cada caso de uso lo he descrito utilizando la plantilla como la que aparece a modo de ejemplo a continuación (figura 13), correspondiente al caso de uso añadir persona al grupo de selección. No se incluyen el resto en la memoria por razones de espacio.
Caso de uso Añadir persona al grupo de selección
Descripción Se añadirá una persona al grupo de selección.
Precondición Estar logueado y ser como mínimo director
Postcondición
Actor Director
Secuencia Paso Acción
1 Seleccionar el botón de añadir
2 El usuario selecciona de una lista previamente construida con las personas a las que pude añadir a la persona que quiere añadir
3 El usuario le da al botón de añadir
4 Se muestra el resultado de la operación.
Extensiones
3.1 Se añade el usuario y se da un mensaje de añadido satisfactoriamente
3.1.1 Se envía una invitación al usuario
Excepciones Figura 13- plantilla descripción cdu
22
Para alguno de los casos de uso he realizado diagramas de actividad para describir mejor el proceso. Incluyo en la memoria el caso de uso añadir persona al grupo de selección para que sirva de ejemplo.
Figura 14- Diagrama de actividad de añadir persona al grupo de selección
23
Requisitos:
Esta captura de requisitos cumple las directrices establecidas por el estandar IEEE Recommended
Practice for Software Requirements Specification ANSI/IEEE 830-1998.
Requisitos funcionales
El administrador de una organización podrá añadir usuarios (a su organización) y activarlos
una vez estén añadidos.
Se deberá realizar la recomendación de:
o Puestos que han sido ofertados para un usuario ajeno a la organización (puede que
la organización quiera realizar una subcontrata).
o Usuarios de la organización para un determinado puesto.
En la recomendación de personal para un puesto se distinguen tres casos; el caso en el que
quieres añadir a una persona jerárquicamente superior, el caso en el que quieres añadir a
una persona jerárquicamente igual o inferior y el caso en el que quieres añadir al grupo de
selección un candidato ajeno a la empresa.
Se podrá modificar los datos básicos de un puesto o de un equipo de trabajo una vez creados,
estos datos son: nombre, descripción e imagen.
Se podrán eliminar puestos de trabajo de un equipo una vez creados.
Se podrán eliminar los candidatos de un grupo de selección.
Una vez que un puesto tenga un trabajador, no se podrá crear un grupo de selección o
modificarlo si ya está creado.
Realizar un sistema de mensajería interna para la invitación a grupos de selección, y la
aceptación por parte del usuario invitado.
Usando el sistema de mensajería implantado en la plataforma, se enviarán mensajes de
notificación cuando un usuario sea añadido a un puesto de trabajo.
Requisitos no funcionales
Usabilidad:
o Realizar una interfaz para el usuario intuitiva y fácil de usar.
o Ágil en el tiempo de respuesta si la conexión a internet es óptima.
Seguridad:
24
o Identificar los roles que pueda tener la aplicación para cumplir con la ley sobre
seguridad del mínimo privilegio.
o Las consultas a la base de datos no pueden quedar en un estado inconsistente, para
que no haya un impacto no deseado.
o Deberá ser compatible con el protocolo https.
Multiplataforma:
o Debe ser visible para los navegadores más utilizados (Google Chrome, Mozilla
Firefox, Opera y Safari).
Legales
o Se deberá satisfacer la Ley Orgánica de Protección de Datos (LOPD).
o Contar con licencias de uso y condiciones que el usuario deba aceptar para poder
hacer uso de la aplicación.
25
Diseño
Base de datos
La antigua Ítaca contaba con una base de datos, con deficiencias, ya que no permitía introducir
nueva funcionalidad al estar muy poco estructurada, con tablas con muchos atributos y pocas
relaciones entre las tablas. La nueva base de datos soluciona este problema y permite añadir más
tablas en un futuro si fuera necesario. La figura 15 muestra el nuevo diseño de la base de datos.
Figura 15- Base de datos
26
Recalcar que esta es mi parte de la base de datos. Al trabajar en colaboración con otros compañeros
de carrera, desarrollando partes distintas de la aplicación de Ítaca, las tablas de la base de datos
conjunta serán más. Todo esto requiere un trabajo coordinado y un especial cuidado para no
modificar esta base de datos hasta que todas las partes estén de acuerdo, ya que podríamos
estropear parte del trabajo realizado.
Tablas USER_Usuario
ID Nombre Apellidos Via Numero Puerta municipio CP Provincia pais tlfn
sexo contrasena email avatar ultimaConexion activado fechaActivacion
unique
ORG_Empleado
ID jefe
CE: Usuario ORG_Organización
ID Nombre IDAdmin IDOrganizacionPadre logo idJefe
CE: Usuario CE: Organización CE: Usuario
ORG_TRAB_Equipo
ID IDOrganizacion Nombre descripción IDAdmin IDEquipoPadre logo IDJefe
CE: Organización CE: Usuario CE: Equipo CE:usuario
ORG_TRAB_REL_UsuarioOrganizacionEquipo
ID IDUsuario IDOrganizacion IDEquipo
CE: Usuario CE: Organización CE: Equipo
ORG_UsuarioProfesional
ID descripcion curriculum Estudios fondo
ORG_REL_UsuarioUsuarioProfesionalOrganizacion
ID IDUsuario IDUsuarioProfesional IDOrganizacion
CE: Usuario CE: UsuarioProfesional CE: Organizacion ORG_TRAB_PuestoDeTrabajo
ID nombre descripcion IDTrabajador
CE: Usuario
ORG_TRAB_REL_OrganizacionEquipoPuesto
ID IDOrganizacion IDEquipo IDPuesto
CE: Organización CE: Equipo CE: Puesto
27
ORG_TRAB_GrupoDeSeleccion
ID IDPuestoTrabajo NºpersonasMax IDMaestro IDElegido Nº personas
CE: PuestoTrabajo CE: Usuario CE: Usuario unique ORG_TRAB_REL_SeleccionUsuario
ID IDSeleccion IDUsuario aceptado
CE: Grupo de Selección CE: Usuario ORG_TRAB_Mensaje
ID titulo contenido IDGrupoSeleccion IDUsuario leido
CE: Grupo de Selección CE: Usuario PERM_ Rol
idRol Nombre descripcion
PERM_ UsuarioRol
ID idUsuario idRol IDOrganización
CE: Usuario CE: Rol CE: IDOrganizacion PERM_ Operaciones
idRol Autenticar crearTest … Hacer_test
CE: Rol
A la hora de especificar las relaciones he decidido quitar las etiquetas por motivo de espacio; las
etiquetas son:
Org: Significa que la tabla pertenece a la categoría de organizaciones.
TRAB: Sub-etiqueta de organización que indica que pertenece a la categoría de trabajo.
PERM: categoría de permisos
Normalización Las tablas ya están en forma normal de Boyce-Codd, es decir, que todos los atributos no primos
dependen de forma total de la clave y para toda xy, x es superclave.
28
Páginas
Para realizar las páginas en html se ha usado una plantilla de Bootstrap llamada Artifcial Reason.
Como se ha dicho anteriormente, esta plantilla es la que se usa en la empresa, por lo que a petición
de Formavolucion se usa para el desarrollo del TFG.
Dicha plantilla contiene páginas ya prediseñadas, que se pueden cambiar, combinar con otras
páginas o añadir cualquier otro elemento de html.
Esta plantilla contiene también elementos prediseñados como barras de progreso, tarjetas de perfil,
títulos, tablas, botones, iconos, listas, etc. Cualquiera de estos elementos se puede incluir en
cualquier página. En la siguiente imagen muestro el panel de los elementos que trae la plantilla de
Artificial Reason.
Figura 16- Menú de los elementos de Arificial Reason
Además de estos elementos contiene animaciones que se pueden añadir a cualquier elemento.
Bootstrap me ha parecido una herramienta bastante útil para la creación de páginas html, ya que
permite una gran flexibilidad, y una amplia gama de elementos y tutoriales sobre su uso en internet.
Como pega decir que sus css y javascript son demasiado extensos por lo que modificar alguna cosa
resulta bastante difícil, aunque sí que puedes crear tu propia hoja de estilos o tu propio javascript y
añadirlo.
29
La cuadrícula de Boostrap se compone de doce columnas, como se muestra en esta imagen.
Figura 17- Grid de Bootstrap
Para estructurar estas doce columnas se dispone de clases definidas en el CSS de Bootstrap.
Container: se encarga de alinear y ajustar los márgenes adecuadamente.
Row: son grupos horizontales de columnas, esta clase se debe declarar siempre dentro de
un container.
Tipos de columnas: para dividir las columnas se usa un número detrás de cada tipo de
columna, este número hará de divisor de doc (Ej: 12/6) y el resultado será el número de
cuadriculas que ocupa.
o Col-xs-*: se utiliza para mostrar en dispositivos con una pantalla de resolución menor
a 768px (móviles).
o Col-sm-*: se utiliza para mostrar en dispositivos con una pantalla de resolución
mayor o igual a 768px (tablets).
o Col-md-*: se utiliza para mostrar en dispositivos con una pantalla de resolución
mayor o igual a 992px (ordenadores portátiles y de sobremesa).
30
No he utilizado otras herramientas de diseño para maquetar las páginas web porque no he
necesitado su uso, ya que Bootstrap me proporcionó lo necesario. Primero decidí ver los elementos
que componen la plantilla y bootstrap en general. Una vez inspeccionado los elementos de
bootstrap, pasé a construir las páginas con los elementos que me parecieron útiles. De esta forma
consiguí un diseño en html adecuado para nuestras necesidades.
A continuación se van a mostrar los diseños de las páginas y sus elementos. En su versión html, estas
páginas pueden tener otro aspecto, ya que esto es un prototipo.
Cabecera:
Figura 18- Cabecera
En esta imagen se muestran los elementos que tendrá la cabecera.
Arriba a la izquierda se encuentra una imagen que un futuro será la imagen de la empresa, con el
nombre del proyecto de la aplicación y un eslogan. A la misma altura a la derecha se encuentran las
redes sociales más usadas y el panel de entrada (login), si el usuario ya se ha conectado a la
aplicación se mostrará en vez del login, el panel de su sesión.
En la parte media (color gris) se encuentra el menú de la aplicación, si el usuario está registrado con
permisos de admiración aparecerá un nuevo apartado llamado administración.
Por último en la zona de color verde Se indicará el nombre de la página y unas migas de pan para
saber en dónde te encuentras en todo momento.
31
Página de mis equipos.
Se usará para mostrar los equipos de los que un usuario tiene permisos de administración dentro
de una misma empresa. Se podrá también usar para listar los equipos en los que está un
determinado usuario.
Figura 19- Listado de equipos
Está página contiene un elemento paginador para ir mostrando poco a poco los equipos, ya que si
un usuario llegará a tener muchos, no sería visualmente agradable mostrar toda la información en
una sola página, ya que se tendría que hacer demasiado scroll.
32
Equipo
Esta página servirá para mostrar los datos de un determinado equipo: nombre, descripción y a los
integrantes del mismo.
Figura 20- Equipo
33
Grupo de selección
El diseño de dicha página es similar al de un equipo, con las diferencias de que tiene un maestro, y
un submenú con las opciones de ver y esconder la realización del test, esta opción lo que hace es
mostrar una barra de progreso con el porcentaje de realización que tiene cada uno. Además de estas
opciones está la opción de recomendar, que muestra la comparación de los participantes.
Figura 21- Puesto y grupo de selección
34
Mis mensajes
Página que sirve para mostrar los mensajes del usuario. La mayoría de dichos mensajes serán
invitaciones a grupos de trabajo.
Figura 22- Mensajes
Los mensajes leídos tendrán un fondo gris y sin letra en negrita, mientras que los mensajes leídos
estarán resaltados con un fondo blanco y letra en negrita.
Al clicar en la papelera para eliminar los mensajes aparecerá un mensaje para la confirmación de
borrado de dichos mensajes.
Se añadieron los siguientes elementos para la gestión de los mensajes y para mejorar la usabilidad
de usuario:
Recargar
Borrar un único mensaje o varios.
Mensaje
Se mostrará el mensaje entero con su título y el texto del mensaje, además de mostrar sus opciones
por defecto la de eliminación del mensaje, como antes se ha comentado la mayoría de los mensajes
serán de invitación a un grupo por lo que se podrá rechazar o aceptar la invitación.
Al elegir cualquiera de estas tres opciones aparecerá un mensaje de verificación.
Figura 23- Mensaje
Los elementos encontrados en la parte inferior derecha, el tic, la cruz y la papelera sirven para
aceptar, rechazar la invitación y elimar el mensaje respectivamente.
35
Búsqueda
Esta página sirve para buscar personas y añadirlas a un puesto directamente o a un grupo de
selección.
Figura 24- Búsqueda para la selección de usuarios
Está página dispone de un paginador, filtros y opciones de visualización. Los filtros sirven para
mostrar un grupo de personas determinado y ordenarlos por nombre. En las opciones de
visualización se encuentran las opciones de cambiar el número de personas que se muestran por
filas y la visualización de la descripción de los usuarios mostrados.
Nota: los nombres mostrados en esta página son suficientemente públicos como para no comprometer la privacidad
de las personas.
Administración
Página para mostrar las opciones de administración. Esta página cambiará de aspecto según el tipo
de usuario que se conecte, es decir, cambiará acorde a los permisos que tenga cada usuario.
Figura 24- Administración
36
El panel de administración está separado por grupos funcionales (equipos, puestos, usuarios,…), en
este diseño no están puestas todas las funcionalidades ni grupos funcionales, ya que es un prototipo
y el resto de grupos funcionales no son mi tarea.
Las páginas de creación de organización, equipo, puesto, grupo de selección he decidido no incluirlas
en la memoria porque son simples formularios.
Diagrama de navegación
Figura 25- Diagrama de navegación
Al panel de administración y a los mensajes se pueden acceder desde cualquier página, ya
que estas dos estarán disponibles en el menú de la cabecera.
El símbolo significa que es un formulario.
37
Diseño Arquitectónico
En la aplicación he creado un diseño formado por las capas de persistencia, lógica de negocio y
presentación. Siguiendo el patrón modelo-vista-controlador (MVC).
Este patrón separa los datos y la lógica de negocio de la aplicación de la interfaz de usuario.
Vista: La que muestra los datos de forma que se puedan interactuar con ellos. Está
compuesta por las diferentes páginas php que son las encargadas de servir de interfaz al
usuario.
Controlador: Responde a las acciones del usuario y hace peticiones al modelo cuando se
tiene alguna solicitud sobre la información. También puede mandar información a la vista,
por lo que se pude decir que el controlador hace de intermediario entre la vista y el modelo.
Lógica de negocio, está formada por páginas de php que simulan a los servlets en java.
Modelo: Es la representación de la información con la que la aplicación opera, por lo que gestiona los accesos a la información. Persistencia esa capa la he dividido en varias clases: class.persistenciaGestion, class.persistenciaEquipos, class.persistenciaOrganizacion, class.persistenciaPuestos, class.persitenciaListar, class.persistenciaGrupoSeleccion y class.persistenciaGestion. La he dividido en diferentes clases para que el tamaño del archivo sea manejable, además de esta forma los métodos de acceso según su grupo funcional.
Figura 26- Diseño arquitectónico
Vista
Controlador
Persistencia
Modelo
38
Implementación
Clases usadas para el desarrollo
phpmailer
Esta clase sirve para mandar correos, para la utilización del envío de emails hace falta configurar
algunos parámetros antes del envío del mismo, algunos de estos parámetros son:
Especificar el protocolo de envío (SMTP, POP3).
El host de correo que vas a usar, por ejemplo: smtp.gmail.com
Elegir conexión segura si se quiere.
El puerto del protocolo que vas a usar.
El nombre de usuario de la cuenta de correo y el envío.
Por último el tipo de codificación del correo, el contentype, el asunto del correo y el cuerpo.
imageresize
Esta clase la he utilizado para subir imágenes al servidor y modificar el tamaño, proporciona
métodos para cambiar el tamaño de la imagen, es decir, a la hora de subir la imagen puedes
redimensionarla según el alto y el ancho o ponerlos de forma proporcional. Esto te permite crear
diferentes medidas para una misma imagen, lo cual es bastante útil porque según donde quieras
usar esa imagen es más apropiado un tamaño u otro. Por ejemplo para la foto de perfil del usuario
hemos redimensionado la imagen que sube el usuario a unos tamaños cuadrados de 50x50, 150x150
y 290x290.
Todas las imágenes que se suben con esta clase se convierten al formato png.
Para trabajar con esta clase hay que crearla con una ruta temporal de la imagen, con esta imagen
temporal es sobre la que trabaja y hace las redimensiones, posteriormente se guarda la imagen en
una ruta final.
39
Clases creadas para el desarrollo
Además de las clases de persistencia, creé diferentes clases para la gestión y el control de la
aplicación, estas clases son:
comprobadora: esta clase contiene métodos para el control de los permisos de los usuarios,
accede a los diferentes permisos que pueda tener el usuario, según el equipo, puesto y
organización. De este modo se puede saber si un usuario tiene los permisos necesarios para
realizar una acción.
equipo y organización: estas clases contiene métodos para la gestión de dichos elementos,
tales como su creación eliminación y modificación.
usuario: contiene los datos más relevantes del usuario que ha hecho la operación de login,
además de métodos para acceder y cambiar dichos datos.
loginCom: gestiona el login de los usuarios y comprueba al acceder a cualquier página que
el usuario se ha logueado en la aplicación y que contiene los datos necesarios en sesión para
el su uso.
Gestión de las operaciones
Las operaciones que permite hacer la aplicación están guardadas en una tabla de la base de datos
junto a los roles que la pueden realizar, indicando mediante un booleano qué rol la puede hacer.
Figura 30- Tabla de operaciones
Contemplé dividir la tabla en grupos operacionales, para no tener todas las operaciones en la misma
tabla, pero se desechó esta idea porque no merecía la pena llevarla a cabo por el tiempo necesario
para su realización y además, de este modo no se podía encontrar a simple vista qué operaciones
podía hacer un determinado rol.
Este tipo de gestión de los permisos no se había llevado a cabo en ninguna asignatura impartida en
la universidad, por lo que supuso un reto llegar a la forma óptima para una gestión adecuada de los
permisos de cada rol.
40
Creación de un paginador
Para la creación de un paginador lo primero que hay que definir son dos variables, el número de
elementos que va a tener cada página (en mi caso la variable la he llamado registros, por defecto 5)
y el número máximos de enlaces que se van a mostrar (a esta variable la he llamado enlazadas y
tiene como valor fijo 5).
Mi variable registros se puede cambiar, es decir, que por medio de la url o del menú proporcionado
en la página se puede cambiar el número de elementos mostrados por página, este número se coge
a través del parámetro reg que contiene la url. Código:
Figura 30- comprobación
Esta sencilla parte de código lo que hace es comprobar que exista por medio de get la variable reg,
si existe y es número se cambiará el número de elementos por página, si no el número será 5.
Además de estas variables hay que crear también una variable que contenga el número de
elementos que hay en total, posteriormente si el número total de elementos no está vacío o es igual
a 0 se pasará a calcular el número de páginas totales, se obtiene al hacer la división entre el número
de registros totales y el número de registros por página.
Para obtener el conjunto de elementos a mostrar en la página hay que hacer una consulta a la base
datos como mínimo con los siguientes parámetros:
Desde: este parámetro representa el número desde el cual hay que coger los elementos, se
calcula con el número de página menos uno y multiplicando el número de elementos por
página.
o Ejemplo: Si nuestro página es la dos dicha operación quedaría así: (2-1)* número de
registros por página, que es igual a número de registros por página, esto viene de
que en la página uno, empezaríamos por el elemento 0 hasta el número de
elementos por página, por lo que en la primera página ya cogeríamos los primeros n
elementos y en la página posterior habría que empezar desde ahí.
Hasta: el número de registros que vamos a mostrar en la página.
41
Una vez hecho todo lo anterior, debemos mostrar los enlaces de las siguientes y/o anteriores
páginas. Para hacer esto necesitamos en mi caso de 6 variables:
Anterior: Representa el número de página anterior a la actual, si el número de página es
mayor que uno, se calculará y mostrará esta variable representada en un elemento html.
Intervalo: El intervalo es la diferencia de páginas que va haber entre la página actual y sus
anteriores y posteriores, la calculo con la siguiente operación:
$intervalo = ceil($enlazadas / 2) - 1; (ceil redondea al número más alto). Mi número de
páginas enlazadas es cinco por lo que el intervalo será de 2.
o Un ejemplo para comprenderlo mejor: Supongamos que estamos en la página
cuatro, nuestro intervalo es de dos, por lo que de páginas anteriores se mostrará
hasta la página dos, y de las páginas superiores suponiendo que hay más se mostrará
hasta la 6(si solo hay 5 páginas, solo se mostrará hasta la 5), siendo el resultado:
Desde: Calcula el primer número que debe aparecer en el paginador, se calcula restando a
nuestra página actual el intervalo, en nuestro ejemplo anterior dicho número es el dos. Si al
hacer la operación la variable desde quedaría en número negativo, pasaría a valer 1.
Hasta: Calcula el último número que debe aparecer en al paginador, se calcula sumando a la
página en la que nos encontramos el intervalo calculado anteriormente. Si la variable desde
es menor que uno, hay que hacer la siguiente operación: $hasta -= ($desde - 1) (el menos es
porque es negativo y lo que queremos es sumar - -+. Con esto nos aseguramos que se
mantiene el número de enlaces a mostrar.
Siguiente: Representa el número de la siguiente página a la actual, si el número de esta
página es mayor que el número de páginas totales no se mostrará este elemento.
42
Creación de la jerarquía de la organización
Para la creación de la jerarquía de una organización he creado dos clases:
class.jerarquia.php: Es la que verdaderamente construye la jerarquía, la construye mediante
dos métodos. El primer método llamado construir recorre los equipos que no tienen padre,
estos equipos se entiende que son los que están en el nivel superior de la jerarquía, ya que
no dependen de ningún otro equipo que esté por encima. Por cada uno de esos equipos crea
un nodo del director del equipo y debajo de este va creando de forma recursiva, con el
segundo método otros nodos que corresponden a personas que están por debajo del equipo
del director (equipos hijo). Por cada nodo director, se añade una segunda lista con los
miembros pertenecientes al equipo al que dirige el nodo principal (nodo director).
Esta clase contiene el identificador de la organización a la que pertenece la jerarquía y el
nodo principal que es el jefe de la organización, y dentro de este nodo se encuentran
contenidos los demás nodos por medio de listas de listas, creando una estructura en árbol.
Además de los métodos mencionados anteriormente, contiene métodos para mostrar la
jerarquía con un formato de lista en html y otro método para encontrar la posición más alta
de un miembro perteneciente a la organización, como la creación de la estructura se ha
realizado por medio de un árbol es fácil sacar esta información.
class.nodo.php: Es la clase sobre la cual se construye la jerarquía. Cada nodo representa a
un miembro de la jerarquía.
Esta clase contiene:
o El identificador del miembro.
o El identificador del equipo al que pertenece dentro de la organización.
o Miembros: Una lista con los nodos miembros del equipo, en el caso de que el nodo
actual sea un director, estos nodos miembro tendrán su lista miembros y siguientes
vacía.
o Siguientes: Una lista con los nodos directores que están directamente debajo de él,
es decir a una altura más baja, estos nodos a su vez contienen los mismos
elementos que el nodo superior, ya que son el mismo tipo de clase (nodo). De esta
forma se crea una lista de listas.
o Altura a la que se encuentra dentro de la organización.
43
Estructura del árbol para la jerarquía:
Figura 31- árbol
Con este diagrama (figura 30) lo que quiero mostrar es un posible ejemplo de cómo quedaría la
estructura jerárquica de una organización según mi función.
En primer lugar tendríamos el nodo principal (jefe de la organización), que colgarían de él dos listas
de nodos, la primera lista contiene la lista de miembros que pertenecen al equipo, en este caso
vacía, la siguiente lista contiene los nodos que están directamente por debajo, es decir, los nodos
que representan a los directores de los equipo que son padres del equipo padre de la organización,
estos nodos a su vez contienen las mismas listas y así recursivamente.
Los principales problemas encontrados
En un primer momento al crear la jerarquía, lo hice creando una lista que contuviera más
listas, sin la clase nodo (descrita anteriormente), pero de esta forma al separar entre un
miembro y un director de un equipo inferior jerárquicamente no se hacía correctamente, ya
que estaban en el mismo nivel de la lista y al recorrerla no se obtenía con garantías el nivel
jerárquico más alto de un usuario. Por esto se pensó de otra forma, teniendo una clase nodo
que tuviera una lista de miembros y otra lista para los directores de un nivel jerárquico
inferior.
A la hora de mostrar la jerarquía en html, tuve varios problemas porque se quedaban divs
sin abrir o sin cerrar, conseguí arreglar el problema identificando los divs que se mostraban
mediante comentarios en ellos y descargando el código fuente de la página. De esta forma
se podía identificar bien las etiquetas que daban el error.
Nodo Principal
Miembros
Siguientes
Nodo
MiembrosNodo
Nodo
Siguientes Nodo
Nodo
Miembros
Siguientes
Nodo
Miembros
Siguientes
44
Recomendación de trabajadores
La recomendación de trabajadores para un puesto se hace comparando de forma visual las
capacidades que se obtienen del candidato al puesto y el maestro del puesto por medio de la
realización de un test.
De esta forma se puede comparar sencillamente las capacidades de una y otro, superponiendo los
valores en un gráfico de araña. Este tipo de gráfico sirve para mostrar diferentes conjuntos de datos
en dos dimensiones. Es una técnica iconográfica que se apoya en la aptitud natural del cerebro
humano para clasificar objetos parecidos.
Figura 32- comparación de habilidades
Para la realización de este gráfico se han usado el script D3.js
D3.js s una librería de JavaScript para producir, a partir de datos, infogramas (representaciones
visuales) dinámicos e interactivos en navegadores web. Hace uso de tecnologías bien sustentadas
como SVG, HTML5, y CSS. Esta librería es sucesora de la librería Protovis.1 En contraste con muchas
otras librerías, D3.js permite tener control completo sobre el resultado visual final.
D3 permite hacer infinidades de gráficos, tales como gráficos de araña, de barras, cartogramas,
mapas, etc.
45
Rediseños
A la hora de hacer el desarrollo me di cuenta de que faltaban campos en la base datos, para ser más
concretos en la tabla ORG_Empleado faltan el ID de la organización y el equipo, además la clave
principal ya no sería el identificador del usuario, sino que habría que añadir un identificador por
cada relación. Dicha tabla quedaría de la siguiente forma:
Figura 27- Empleado
ORG_Empleado
ID IDUsuario IDOrganizacion IDEquipo jefe
CE: Usuario CE: Organización CE: Equipo A la hora de controlar los roles que tienen los usuarios, decidí separar también por equipos, ya que un usuario puede tener por ejemplo un rol de director B en un equipo y en otro de director D.
Figura 28- usuario_rol
Entrando más en profundidad en la realización del sistema de mensajería, decidí crear más campos
en la tabla. Estos campos son id del emisor del mensaje, un identificador del equipo desde que se
envía el mensaje (en caso de que se envíe de un equipo) con este campo se abre la posibilidad de
tener que aceptar la inserción a un puesto de trabajo o mandar una notificación, el puesto al cuál
se ha añadido, la organización a la cual pertenece el mensaje y un tipo de mensaje para diferenciar
entre notificaciones e invitaciones de unión.
46
Finalmente dicha tabla quedaría así.
Figura 29- Mensaje
De esta tabla pueden ser nulos los campos: IDEquipo, IDGrupoSeleccion, IDPuesto y asunto.
Problemas encontrados
Durante la implementación me he encontrado con algunos problemas. La mayor parte de ellos
tienen que ver con la creación de la jerarquía, los cuales se explican en dicho apartado, los demás
por el cerrado de las etiquetas html, en concreto tuve problemas con el envío de datos por este
motivo, primero pensé que la recogida o el envío de datos no era la correcta, después miré si se
debía a algún conflicto con alguna variable, por último consulté los datos en la sesión por si pudiera
haber algún dato que interfiriera. Al final resultó ser que los formularios no se cerraban de forma
adecuada.
47
Calidad
Rendimiento
La web carga de forma fluida si la conexión a internet es de una calidad media. En cuanto a la
creación de la jerarquía, cuyo algoritmo es más complejo y puede provocar algún retardo en la carga,
este retardo solo se produciría la primera vez, puesto que una vez creado se guarda en la sesión, ya
que si se ha consultado una vez es bastante probable que se vuelva a consultar. Por otra parte las
pruebas realizadas con una organización de ejemplo no han aparecido problemas de rendimiento.
Pruebas
Se han realizado pruebas unitarias de las siguientes operaciones:
Crear, eliminar y modificar:
o Organización.
o Equipo.
o Puesto.
o Eliminar usuario de puesto y grupo de selección.
Modificar permisos.
Añadir usuario a:
o Organización.
o Puesto.
o Grupo de selección.
Comprobar el estado de realización de test.
Listado de los puestos y equipos de cada usuario.
Para cada prueba se ha seguido la plantilla de la figura 33, incluyo solo la prueba de creación de
organización a modo de ejemplo, ya que por motivos de espacio no incluyo el resto.
Además de estas pruebas se han realizado pruebas de la comprobación de permisos y control de las
funciones realizadas por cada uno, todas ellas de forma satisfactoria.
También se han realizado pruebas de integración con la parte de gestión te test, de mi compañero
Daniel Espinosa, puesto que esa parte era necesaria para mi proyecto, debido a que necesito el
estado de los test y las mediciones de cada uno para poder hacer la parte de comparación de
usuarios. Las pruebas realizadas en la integración han sido satisfactorias.
48
Nombre Creación de organización
Entrada Nombre, organización padre, administrador de la organización
Descripción Se crea una organización, introduciendo los datos de la nueva
organización y se pulsa crear.
Resultado esperado Se crea la nueva organización con el administrador correspondiente. Y
se crea una relación entre ellos dos.
Resultado real Correcto.
Comentario
Figura 33- Plantilla para pruebas
Conclusiones
Desarrollar un proyecto por mí mismo me ha supuesto un reto, ya que la dificultad es mayor que
cualquier otro proyecto realizado durante la carrera. El proyecto me ha servido para darme cuenta
que la realización de aplicaciones web es un ámbito que me gusta y en el que quisiera seguir
profundizando. Por otro lado, haber estado dentro de una empresa me ha permitido conocer otro
ámbito del cual no se enseña en la carrera, de esta forma he podido ver cómo es el mundo laboral
desde dentro.
Además he tenido que estar coordinado con mis compañeros, porque cada TFG era una parte de la
aplicación Ítaca, esto ha supuesto un trabajo extra, ya que teníamos que estar en constante
comunicación para no pisar el trabajo realizado por los demás, puesto que un cambio en la base de
datos o llamar igual a una variable podía causar problemas.
En general me siento satisfecho con el trabajo realizado y con el ambiente que hemos tenido tanto
con los integrantes de la empresa como con los compañeros de la carrera.
En cuanto a la elaboración del proyecto se ha completado a la totalidad la funcionalidad acordada
y deseada por la empresa de forma satisfactoria.
Existen algunas posibles mejoras o ampliaciones que se podrían incluir en la aplicación, pero por
razones de tiempo y de que no se acordaron en un principio en el alcance del proyecto, no se han
incluido en esta versión. Las posibles mejoras son las siguientes:
Incluir puestos estándar con sus correspondientes habilidades para no tener que depender
de la realización de un test por parte de un maestro de un puesto. De esta forma se
agilizarían los procesos de selección al tener ya perfiles fijos para puestos.
Poder crear perfiles para puestos de trabajos específicos, es decir, que una organización
tenga la potestad de crear un perfil con las habilidades y datos que crea adecuados para un
determinado puesto.
49
Que las diferentes organizaciones puedan ofertar puestos para que los usuarios se puedan
inscribir a él, sin la necesidad de que un administrador les añada. Dependiendo del tipo de
oferta que haga la organización podrán apuntarse personal de la empresa, ajeno a la
empresa o ambos.
Durante el transcurso del segundo cuatrimestre y tras la aceptación del tema del trabajo de fin de
grado por parte de la universidad, la empresa decidió cambiar el tema que en un principio era:
Generalización en el acceso, uso y gestión de un dispositivo weareable del mercado para registrar
actividades en bases de datos, finalmente y tras un acuerdo entre la universidad y la empresa el TFG
pasó a ser el actual: Desarrollo de una aplicación web de recomendaciones utilizando el patrón MVC.
Esto me supuso un ligero contratiempo ya que había empezado a buscar información para
desarrollar el proyecto inicialmente concertado.
Agradecimientos
El presente trabajo fue tutelado por Juan José Olarte a quién me gustaría expresar mi
agradecimiento por su paciencia, tiempo y dedicación.
Agradecer también a la empresa Formavolucion junto a todos sus participantes, ya que este trabajo
no podría haberse realizado sin su participación y por el trato recibido durante mis prácticas y
desarrollo del proyecto.
Por otro lado me gustaría agradecer a mis compañeros Daniel Espinosa y Marina Blanco por su
colaboración y el trabajo en equipo desarrollado.
50
Bibliografía
Apuntes de la asignatura programación de aplicaciones web por Francisco García Izquierdo.
Apuntes de consultas SQL por de la asignatura: Bases de Datos.
Apuntes de la asignatura de diseño de bases de datos por César Domínguez Pérez y Arturo
Jaime Elizondo.
Apuntes sobre sobre EVS y Requisitos, Análisis, Diseño y Pruebas por Juan José Olarte
Larrea de la asignatura Ingeniería del Software.
Tutorial sobre el grid de bootstrap: https://openwebinars.net/tutorial-bootstrap-3-
sistema-grid/
Tutorial sobre el grid de bootstrap: http://v4-alpha.getbootstrap.com/layout/grid/#how-
it-works
Tutorial sobre el uso de bootstrap: http://www.w3schools.com/bootstrap/
Consulta de los métodos de PHP: http://php.net/
Consulta de dudas sobre programación: http://stackoverflow.com
http://gcoch.github.io/D3-tutorial/
https://graves.cl/radar-chart-d3/
https://github.com/alangrafu/radar-chart-d3
51
Anexos
Anexo 1. Actas de reunión
Acta de reunión 2/2/2016
Datos generales:
Lugar: Logroño
Fecha: 2-2-2016
Hora de inicio: 9:30
Hora de fin: 11:00
Asistentes
Javier Ruiz Sáenz de Pipaón.
Juan José Olarte.
Jesús García Caro.
Orden del día
Concretar la forma de hacer el TFG y tener una toma de contacto antes del mismo.
Acuerdos
Consultar el correo frecuentemente.
Mantener al tutor informado del desarrollo del proyecto.
Darse de alta en la página de Facebook y en la aplicación de yaiza.
Concretar la forma de trabajo del tfg y la regularidad con la que hay que informar al tutor
sobre los avances en el proyecto.
Acordar la información que tiene que presentar la memoria del proyecto
Javier Ruiz Sáenz de Pipaón.
52
Acta de reunión 29/2/2016
Datos generales:
Lugar: Fomavolucion, Logroño
Fecha: 29-2-2016
Hora de inicio: 10:00
Hora de fin: 11:00
Asistentes
Javier Ruiz (Director de mi proyecto).
Daniel Espinosa.
Marina Blanco.
Álvaro Saenz (Director de los proyectos de formavolucion).
Orden del día
Concretar el alcance del proyecto y poner ideas en común entre los tres participantes de desarrollo
de Ítaca (Daniel, Javier y Marina) los cuales desarrollamos módulos independientes de la aplicación.
Acuerdos
A continuación, expongo los acuerdos que me afectan a mí.
Realizar un análisis exhaustivo de los roles de la aplicación, y las diferentes operaciones (de
la aplicación total) que estarían autorizados a realizar.
Realizar y diseñar un panel de usuario usable para la gestión del perfil y uso de la aplicación.
Se deberá realizar la recomendación de:
o Puestos que han sido ofertados para un usuario ajeno a la organización.
o Usuarios para un puesto.
En la recomendación de personal para un puesto se distinguen tres casos; el caso en el que
quieres añadir a una persona jerárquicamente superior, por debajo o tu nivel y el caso en el
que quieres añadir al grupo de selección.
Cuando se quiera añadir a un usuario a un puesto de trabajo el usuario debe dar el okey, por
lo que se mandará una invitación al usuario. Si el usuario no responde a las invitaciones se
le enviarán mensajes en forma de recordatorio. Si no responde en x mensajes se tomarán
medidas.
Para ordenar y seleccionar al personal más adecuado dentro del grupo de selección, se
requerirá que un trabajador “maestro” (el mejor en su puesto) haga un test para comparar
los resultados con el personal dentro del grupo de selección.
Modificar la base de datos para que se pueda ver la jerarquía de una organización de forma
sencilla.
Guardar un historial de grupos de selección.
En el caso de que un usuario sea borrado, en el historial de grupos de selección deberá
aparecer un mensaje o un usuario de nombre usuario eliminado, para que se vea el número
de participantes hubo en el grupo de selección y los datos de los participantes que todavía
están en la aplicación.
53
A continuación, se tratan los temas que involucran al equipo en conjunto, ya que al realizar módulos
de la misma aplicación hay casos en los que tenemos que ponernos de acuerdo en la forma de
realizar el trabajo.
Ponernos de acuerdo a la hora de realizar la estructura de la aplicación para la funcionalidad
del multilenguaje.
Comunicarnos los cambios que podamos realizar en la base de datos que puedan afectarnos
a cualquiera de nosotros (Daniel, Javier y Marina).
Javier Ruiz Sáenz de Pipaón.
54
Acta de reunión 21/3/2016
Datos generales:
Lugar: Logroño
Fecha: 21-3-2016
Hora de inicio: 10:00
Hora de fin: 11:00
Asistentes
Javier Ruiz (Director de mi proyecto).
Daniel Espinosa.
Marina Blanco.
Álvaro Sáenz (Director de los proyectos de formavolucion).
Fernando Berruezo (Empleado de formavolucion).
Orden del día
Explicar cómo vamos a nombrar tablas y campos a partir de ahora en la BBDD, para que las
vayáis construyendo a conforme a un modelo
Poner en común las tablas que va a necesitar cada uno, y darlas a conocer por si otra persona
del equipo necesita hacer uso de ella en el futuro
Acuerdos
Normas para archivos:
o Nombre de los archivos siempre en minúsculas.
o Nombre de los archivos de clases ha de ser class.nombrearchivo.php
o La codificación del archivo ha de ser UTF-8 sin BOM. En caso que el servidor tenga
otra configuración ésta será ANSI.
Normas para Bases de Datos:
o Nombre para las tablas <NOMBRESECCION_NombreDeTabla>
"TEST_HabilidadesUsuario".
o Nombre para los campos las tablas <NombreDelCampo> "CodigoPostal"
"FechaNacimiento".
o El Campo ID de las tablas, si lo tiene estará siempre en mayúsculas "ID".
o Nunca se usarán tildes o ñ's en ningún caso para evitar cualquier tipo de problema
con las codificaciones.
Javier Ruiz Sáenz de Pipaón.
55
Acta de reunión 22/3/2016
Datos generales:
Lugar: Logroño
Fecha: 22-3-2016
Hora de inicio: 11:30
Hora de fin: 12:20
Asistentes
Javier Ruiz.
Juan José Olarte (Tutor del TFG)
Orden del día
Tratar la redacción de los documentos entregados.
Acuerdos
Se dieron pautas para la redacción de los documentos.
Realizar las explicaciones de los documentos más claras y explicar términos que un primer
lector pueda no entender, aunque al redactor le parezcan obvias.
Integrar todos los documentos enviados en uno mismo.
Javier Ruiz Sáenz de Pipaón.
56
Acta de reunión 4/5/2016
Datos generales:
Lugar: Logroño
Fecha: 4-5-2016
Hora de inicio: 12:30
Hora de fin: 13:30
Asistentes
Javier Ruiz Sáenz de Pipaón.
Juan José Olarte.
Orden del día
Mostrar una primera versión de la aplicación y revisar la memoria.
Acuerdos
Mejorar en la redacción de la memoria.
Dejar claro en la memoria que el proyecto se hace en colaboración con otros alumnos de
informática y que a la finalización del proyecto hay que unificar cada parte.
57
Acta de reunión 12/5/2016
Datos generales:
Lugar: Logroño
Fecha: 12-5-2016
Hora de inicio: 10:30
Hora de fin: 13:30
Asistentes
Javier Ruiz.
Daniel Espinosa.
Marina Blanco.
Álvaro Sáenz (Director de los proyectos de formavolucion).
Xavier Capellades (Jefe de formavolucion).
Eva Vidañez (Encargada de ventas y pedagoga).
Orden del día
Mostrar cada uno su aplicación y explicar su funcionamiento.
Acuerdos
Añadir la funcionalidad de crear perfiles de puestos y de ofertar puestos, si diera tiempo.
58
Anexo 2. Glosario
Glosario
Grupo de trabajo: conjunto de personas asignadas o auto asignadas, de acuerdo a sus habilidades,
conocimientos y competencias específicas (profesionales o expertos), para cumplir una
determinada meta bajo la conducción de un coordinador (director del grupo). Está formado por
puestos de trabajo.
Grupo de selección: grupo que pertenece a un puesto, está formado por un maestro, que será el
referente para la comparación del test y un conjunto de usuarios, que serán los candidatos al puesto
los que se tendrán en cuenta para realizar la recomendación de ese puesto.
Organización: sistema diseñado para alcanzar ciertas metas y objetivos (Empresas, instituciones,
colegios, etc.). Estos sistemas pueden, a su vez, estar conformados por otros subsistemas
relacionados que cumplen funciones específicas como grupos de trabajo.
Puesto de trabajo: espacio que uno ocupa en una empresa, institución o entidad desarrollando
algún tipo de actividad.
Usuario ajeno a la organización: usuario de la aplicación que no pertenece a la organización activa
(de la que se está accediendo. Ejemplo: Un usuario A pertenece a la organización AA, otro usuario
B pertenece a la organización BB, para el usuario A que accede desde la organización AA, el usuario
B es ajeno a la organización AA, aunque pertenece a otra.).
Usuario jerárquicamente superior: usuario de la misma empresa activa, que tiene un orden
jerárquico superior al usuario que está utilizando la aplicación.
Estructura en árbol: es una estructura de datos que imita la forma de un árbol (un conjunto de
nodos conectados). Un nodo es la unidad sobre la que se construye el árbol y puede tener cero o
más nodos hijos conectados a él. Se dice que un nodo α es padre de un nodo β si existe un enlace
desde α hasta β (en ese caso, también decimos que β es hijo de α). Sólo puede haber un único nodo
sin padres, que llamaremos raíz. Un nodo que no tiene hijos se conoce como hoja. Los demás nodos
(tienen padre y uno o varios hijos) se les conoce como rama.
