aplicación web para la gestión de prácticas en empresadado que se desea que la aplicación que se...

David Peso Llamazares

Francisco José García Izquierdo

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Grado en Ingeniería Informática

2014-2015

Título

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

Aplicación web para la gestión de prácticas en empresa

Autor/es

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2015

publicaciones.unirioja.esE-mail: [email protected]

Aplicación web para la gestión de prácticas en empresa, trabajo fin de gradode David Peso Llamazares, dirigido por Francisco José García Izquierdo (publicado por la

Universidad de La Rioja), se difunde bajo una LicenciaCreative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.

Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a lostitulares del copyright.

Facultad de Ciencias, Estudios Agroalimentarios e Informática

TRABAJO FIN DE GRADO


Aplicación Web para la Gestión de Prácticas en Empresa

Alumno:


Tutores:

Francisco José García Izquierdo

Logroño, julio de 2015


2


3

RESUMEN

La Universidad de La Rioja, en su plan de estudios para el Grado en Ingeniería Informática, incluye las asignaturas Prácticas externas I (de carácter obligatorio) y Prácticas externas II (de carácter voluntario). Ambas se desarrollan en el cuarto curso de la titulación y ofrecen al estudiante un período de estancia en una empresa o institución donde participar en actividades del mundo de la ingeniería informática y afianzar sus conocimientos adquiridos hasta entonces en sus estudios.

La realización de este proyecto ha sido propuesta por el Director de Estudios del Grado en Ingeniería Informática D. Francisco José García Izquierdo y su objetivo es ofrecer un marco centralizado para facilitar la gestión relativa a las mencionadas asignaturas de prácticas en empresa, desde ofertas y solicitudes de plazas hasta envío de memorias y calificación. Será por tanto, una aplicación web que irá dirigida a todas las partes implicadas en los procesos de prácticas: estudiantes, centros de trabajo, tutores académicos y director de estudios.

ABSTRACT

The University of La Rioja includes as subjects Prácticas Externas I (compulsory) and Prácticas Externas II (optional) in its curriculum for Computer Engineering. Both are scheduled for the fourth year of the degree, and they offer to students a internship in Computer Engineering in a company or institution where they consolidate their knowledge gained so far in their studies.

The realization of this project has been proposed by the Director of Computer Engineering Studies, D. Francisco José García Izquierdo, and aims to provide a framework to facilitate centralized management concerning these internships, covering from tenders, applications and seats allocation, to reports sending and assessment. It is therefore a web application that will target all parties involved in the process: students, workplace, academic tutors and director of studies.


4

AGRADECIMIENTOS

En primer lugar, agradecer a Francisco García Izquierdo, por sugerirme la idea de desarrollar esta aplicación y por su dirección, asesoramiento y predisposición para atender siempre cualquier duda que pudiera tener. Sin su ayuda y su atención no hubiera sido posible realizar este proyecto.

En segundo lugar, a toda mi familia. A mis hermanas, mis tíos y, muy en especial, a mis padres, por su apoyo y sus ánimos en el día a día.

Y, finalmente, a todas las personas que me han acompañado en estos años de estudios. A mis

compañeros y amigos, en especial a Ignacio, a Cristian y a Mireia, y a todos los profesores que

me han enseñado tanto y cuyos conocimientos que me han transmitido han supuesto una

buena base para poder llegar hasta aquí.


5

Tabla de contenido

RESUMEN ............................................................................................................................ 3

ABSTRACT ........................................................................................................................... 3

AGRADECIMIENTOS ............................................................................................................. 4

CAPÍTULO 1. INTRODUCCIÓN ............................................................................................... 7

1.1. Contexto ............................................................................................................................. 7

1.2. Tecnologías ......................................................................................................................... 8

1.3. Planificación ....................................................................................................................... 8

1.3.1. Alcance ........................................................................................................................ 8

1.3.2. Estructura de Descomposición del Trabajo (EDT) ..................................................... 10

1.3.4. Descripción de las tareas del EDT.............................................................................. 11

1.3.5. Distribución temporal ............................................................................................... 12

1.3.6. Plan de comunicación ............................................................................................... 15

1.3.7. Plan de calidad .......................................................................................................... 15

CAPÍTULO 2. ANÁLISIS........................................................................................................ 17

2.1. Requisitos funcionales y roles .......................................................................................... 17

2.1.1. Administrador/Director de Estudios ......................................................................... 17

2.1.2. Tutores de empresa .................................................................................................. 18

2.1.2. Representante de empresa ....................................................................................... 18

2.1.3. Estudiantes ................................................................................................................ 19

2.1.4. Tutores académicos .................................................................................................. 19

2.1.5. Envío automático de correos electrónicos ................................................................ 20

2.2. Requisitos no funcionales ................................................................................................ 20

CAPÍTULO 3. DISEÑO .......................................................................................................... 21

3.1. Diseño de la base de datos ............................................................................................... 21

3.1.1. Descripción de la base de datos ................................................................................ 21

3.1.2. Diagrama Entidad-Relación ....................................................................................... 22

3.1.3. Modelo relacional ..................................................................................................... 23

3.2. Diseño de la interfaz gráfica de usuario y navegabilidad ................................................. 25

3.2.1. Proceso de registro ................................................................................................... 25

3.2.2. Menús de usuario ...................................................................................................... 27

3.2.3. Estudio de prototipos ................................................................................................ 29

CAPÍTULO 4. IMPLEMENTACIÓN ......................................................................................... 33


6

4.1. Estructura general de la aplicación .................................................................................. 33

4.1.1. Base de datos ............................................................................................................ 33

4.1.2. Capa de persistencia ................................................................................................. 33

4.1.3. Capa de lógica de negocio ......................................................................................... 35

4.1.4. Capa de presentación ................................................................................................ 37

4.2. Implementación de funcionalidades de la aplicación ...................................................... 40

4.2.1. Envío de correos electrónicos ................................................................................... 40

4.2.2. Descarga de plantillas de memoria ........................................................................... 41

4.2.3. Subida de memorias a la aplicación .......................................................................... 43

4.2.4. Descarga de memorias .............................................................................................. 45

4.2.5. Descarga de la copia de seguridad de la base de datos ........................................... 45

4.2.6. Página de error de la aplicación ................................................................................ 46

4.2.7. Manuales de usuario ................................................................................................. 47

4.3. Aspectos de seguridad ..................................................................................................... 47

4.3.1. Tratamiento de contraseñas de usuarios .................................................................. 47

4.3.2. Tratamiento de datos de entrada ............................................................................. 48

4.3.3. Prevención de ataques de inyección SQL y XSS ........................................................ 48

4.3.4. Protección de accesos ............................................................................................... 50

4.3.5. Protección del fichero de propiedades ..................................................................... 51

CAPÍTULO 5. INTEGRACIÓN Y PRUEBAS .............................................................................. 53

5.1. Despliegue de la aplicación en el servidor ....................................................................... 53

CAPÍTULO 6. CONCLUSIONES ............................................................................................. 55

6.1. Tabla comparativa de horas previstas y horas reales .................................................. 55

CAPÍTULO 7. BIBLIOGRAFÍA ................................................................................................ 57


7

CAPÍTULO 1. INTRODUCCIÓN

La presente memoria recoge los aspectos más importantes del Trabajo Fin de Grados realizado por David Peso Llamazares bajo el título “Aplicación Web para la Gestión de Prácticas en Empresa”. Este proyecto ha sido desarrollado para el Director de Estudios del Grado en Ingeniería Informática.

1.1. Contexto

El plan de estudios del Grado en Ingeniería Informática de la Universidad de La Rioja incluye dos asignaturas orientadas a que los estudiantes desarrollen prácticas en empresa para afianzar sus conocimientos y familiarizarse con el trabajo cotidiano al que se enfrentarán durante el ejercicio de su actividad profesional.

Son diversos los roles, tanto del mundo académico como empresarial, y las gestiones que intervienen en los procesos de prácticas externas, solicitudes, desarrollo y calificación de estas prácticas.

Para comprender mejor la motivación de este proyecto, se describen a continuación las diferentes fases que tienen lugar actualmente en todo este proceso:

o Oferta de prácticas. Las empresas o instituciones contactan con el Director de Estudios para comunicar que desean ofertar una o varias plazas para que los estudiantes desarrollen sus prácticas con ellas. Para ello, deben cumplimentar un documento y enviarlo a la Universidad. En este documento se indica el nombre de quien será el tutor de empresa del estudiante.

o Publicación de la oferta de prácticas. Concluido el plazo de oferta de prácticas, se publica en la página web de la universidad un documento con la relación de empresas, plazas y actividades a desarrollar en las mismas.

o Solicitud de prácticas. Publicada la oferta de prácticas, los estudiantes cumplimentan un documento disponible en la página web de la universidad en el que solicitan varias plazas por orden de preferencia para ellos. Este documento de solicitud lo deben enviar por correo electrónico a la Facultad de Ciencias, Estudios Agroalimentarios e Informática.

o Asignación de plazas. Concluido el plazo de solicitud de prácticas, y con la información relativa al expediente académico de los estudiantes, el Director de Estudios asigna las plazas de prácticas a cada estudiante. Posteriormente, se publica en la página web de la universidad un documento con la relación de plazas y estudiantes.

o Asignación de tutores académicos. El Director de Estudios asigna a cada estudiante un profesor del Departamento de Matemáticas y Computación, que actuará como su tutor académico durante las prácticas.

o Firma del convenio de prácticas. El estudiante recoge el documento del convenio en la Oficina del Estudiante, acude a firmarlo a la empresa, y devuelve una copia del documento firmado a la misma oficina.


8

o Desarrollo de las prácticas. El estudiante desarrolla sus actividades de prácticas en el centro de trabajo que le ha sido asignado dentro de los plazos establecidos.

o Evaluación de las prácticas. Concluido el período de prácticas, el estudiante y su tutor de empresa rellenan sendas memorias y las remiten firmadas al tutor académico del estudiante, quien también debe rellenar su propio informe con una calificación y enviarlo al Director de Estudios.

Como se puede observar, la documentación necesaria en las diferentes fases se encuentra dispersa en varios lugares. No existe actualmente un sistema informatizado para realizar todas las gestiones de las prácticas, lo cual puede suponer en numerosas ocasiones una ralentización de los procesos y una dificultad de coordinación, especialmente para el Director de Estudios.

Para superar estas barreras y dar solución a sus problemas surge el presente proyecto: una aplicación web, adaptable a cualquier dispositivo desde el que se visualice, que permita realizar todos los trámites de ofertas, solicitudes y calificación de prácticas, mejorando y haciendo más directo el intercambio de información entre estudiantes, empresas, tutores académicos y Director de Estudios.

Este Trabajo Fin de Grado ha sido propuesto por D. Francisco José García Izquierdo, Director de Estudios del Grado en Ingeniería Informática, quien ha actuado, además, como tutor y cliente del mismo.

1.2. Tecnologías

Hoy en día, las páginas web se visualizan en multitud de dispositivos, desde ordenadores personales o portátiles hasta smartphones, tabletas o libros electrónicos. Además, cada uno de estos dispositivos tiene sus características propias que lo diferencian de otros: resolución, tamaño de pantalla, capacidad de memoria, etc.

Dado que se desea que la aplicación que se va a desarrollar en este proyecto pueda funcionar y visualizarse correctamente independientemente del dispositivo desde el que se acceda a ella, se ha elegido seguir la filosofía de diseño web adaptable (en inglés, Responsive Web Design). Este diseño adaptable se consigue gracias a la introducción, en las propiedades de los estilos CSS, de las Media Queries, unas órdenes que indican al documento HTML cómo debe comportarse en diferentes resoluciones de pantalla.

El lenguaje de programación elegido para el desarrollo de la aplicación ha sido PHP y el sistema de gestión de base de datos que se ha utilizado MySQL.

1.3. Planificación

En esta sección se recoge una descripción del alcance del producto, la metodología de desarrollo que a seguir, así como la descomposición jerárquica de tareas y la planificación temporal de las mismas.

1.3.1. Alcance

El presente Trabajo Fin de Grado consiste en el desarrollo de una aplicación web que permitirá realizar los trámites de gestión de las prácticas en empresa. El producto final irá acompañado de un manual de usuario, que recogerá cómo debe utilizarse la aplicación.

Hay que tener en cuenta también que la aplicación registrará en su base de datos información relativa a datos personales y académicos de una alta sensibilidad. Por ello, además de diseñar y crear una base de datos consistente, deberá permitirse realizar una copia de seguridad de la base de datos.


9

Dada la complejidad del producto y siguiendo la metodología de la Ingeniería del Software, se llevarán a cabo fases adicionales a parte de la implementación, con el objetivo de conseguir un desarrollo óptimo. La metodología de desarrollo elegida ha sido el desarrollo en cascada. Cada una de las fases del ciclo de vida del proyecto se llevará a cabo una única vez y en un orden lineal: análisis, diseño, implementación y pruebas.

Además de lo ya dicho, durante el ciclo de vida del proyecto también se llevarán a cabo las siguientes tareas:

o Reuniones periódicas con el director de proyecto.

o Entrega, al finalizar cada fase, de un documento entregable al director de proyecto.

o Redacción de una memoria de aproximadamente 50 páginas, en la que se detallarán todas

las tareas realizadas durante la duración del trabajo.

o Seguimiento y control del trabajo realizado, en comparativa con el planificado.

o Realización y preparación de una presentación para la defensa del Trabajo Fin de Grado.

Aplicación Web para

1.3.2. Estructura de Descompo


Estructura de Descomposición del Trabajo (EDT)

10


11

1.3.4. Descripción de las tareas del EDT

Código Tarea Descripción Horas

previstas

T.1.0 Introducción Tareas previas al desarrollo en sí mismo del producto.

8

T.1.1 Contexto Descripción de la motivación que lleva a poner inicio al proyecto, así como los objetivos que se buscan conseguir.

2

T.1.2 Planificación Especificación de las tareas a realizar para satisfacer los requisitos del proyecto. Abarca la descomposición del trabajo (EDT) en subtareas lo suficientemente pequeñas como para poder cuantificar el tiempo necesario para su realización. Incluye, así mismo, la distribución temporal para estas subtareas.

6

T.2.0 Gestión Abarca las tareas transversales del proyecto, que se llevarán a cabo durante todo el ciclo de vida del mismo.

50

T.2.1 Memoria Redacción de una memoria de aproximadamente 50 páginas, con todos los aspectos relevantes del ciclo de vida del proyecto.

40

T.2.2 Seguimiento y control

Tareas orientadas a controlar el correcto desarrollo del proyecto, así como a detectar y corregir posibles desviaciones. Incluye las reuniones con el director de proyecto y cliente.

10

T.2.3 Defensa Tarea final del proyecto, en la que se defenderá el trabajo realizado ante un tribunal de la Universidad de La Rioja para su calificación. Esta tarea incluye la propia presentación y su preparación.

10 (estas horas

no se contabilizan en las 300)

T.3.0 Análisis Tarea orientada a la obtención, a partir de las reuniones con el cliente, de los requisitos que debe satisfacer el producto.

10

T.3.1 Requisitos funcionales

Descripción de las propiedades funcionales que debe ofrecer la aplicación.

7

T.3.2 Requisitos no funcionales

Descripción de los atributos que debe ofrecer la aplicación, y de los cuales depende la calidad de la misma.

3

T.4.0 Formación Tarea dirigida a la formación en las tecnologías que se usarán para el desarrollo de la aplicación, fundamentalmente del lenguaje PHP.

Las horas de esta tarea no

se contabilizan en las 300

T.5.0 Diseño Especificación de una solución para el sistema. 20

T.5.1 Diagrama de clases

Realización de un diagrama que describe la estructura del sistema mostrando sus clases, orientado a objetos.

6


12

Código Tarea Descripción Horas

previstas

T.5.2 Diseño de base de datos

Diseño de la estructura de la base de datos que utilizará la aplicación.

6

T.5.3 Diseño de interfaces

Tarea orientada a la realización de prototipos de las diferentes pantallas de la aplicación, con el objetivo de asegurar la aceptación final por parte del cliente.

8

T.6.0 Implementación Creación de la base de datos y desarrollo del código necesario de la aplicación. Esta implementación se llevará a cabo siguiendo el diseño en tres capas: presentación, lógica de negocio y persistencia.

200

T.6.1 Base de datos Creación de la base de datos y desarrollo de la capa encargada de trabajar con ella.

40

T.6.2 Presentación Desarrollo de la parte visual de la aplicación. 110

T.6.3 Lógica de negocio

Desarrollo de la capa que se comunicará con la de presentación y la de persistencia.

50

T.7.0 Pruebas Conjunto de acciones orientadas a comprobar el correcto funcionamiento de la aplicación, y en caso contrario poder poner en marcha los mecanismos necesarios para su corrección.

4

T.8.0 Manual de usuario

Redacción de una guía dirigida a los usuarios de la aplicación, que incluya una descripción de cómo debe utilizarse la misma para llevar a cabo diferentes acciones.

8

TOTAL HORAS TRABAJO FIN DE GRADO 300

1.3.5. Distribución temporal

La duración del proyecto se establece en 300 horas de trabajo, que quedarán distribuidas en 23 semanas entre el 2 de febrero y el 15 de julio de 2015. La semana del 6 al 12 de abril queda libre por ser festiva en el calendario académico de la Universidad de La Rioja, así como los días 2 y 3 de abril (Jueves y Viernes Santo) y el día 1 de mayo (Día del Trabajo). Los días 6 y 9 de febrero se dejan también libres por asuntos personales.

La dedicación semanal al proyecto será de 20 horas semanales, distribuidas entre 3 y 5 horas diarias de lunes a viernes, dependiendo de los asuntos ajenos al proyecto que se deban tratar en la semana.

Se establece una reunión con el director de proyecto aproximadamente cada dos semanas. En estas reuniones se analizarán el progreso, estado y calidad del TFG.

Se estipula el viernes 29 de mayo como fecha de fin de implementación de la aplicación, quedando la semana siguiente para efectuar la fase de pruebas y redactar el manual de usuario. De este modo, el trabajo quedará completamente terminado para el día 5 de junio, quedando pendiente por realizar el acto de defensa y su preparación previa.

A continuación se muestra, a modo gráfico, la distribución temporal en el calendario de cada una de las tareas:


13

abril mayo junio

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 1 2 3 1 2 3 4 5 6 7

6 7 8 9 10 11 12 4 5 6 7 8 9 10 8 9 10 11 12 13 14

13 14 15 16 17 18 19 11 12 13 14 15 16 17 15 16 17 18 19 20 21

20 21 22 23 24 25 26 18 19 20 21 22 23 24 22 23 24 25 26 27 28

27 28 29 30 25 26 27 28 29 30 31 29 30

Introducción y análisis Implementación

Formación Pruebas

Diseño Manual de usuario

Depósito del TFG

Debe señalarse que el calendario no recoge las tareas T.2.1 (Memoria) y T.2.2 (Seguimiento y control), dado que se realizarán durante todo el ciclo de vida del proyecto. De igual modo, no se indican las tareas T.2.3 (Defensa) y T.4.0 (Formación), al no estar incluidas en las 300 horas de duración del TFG.

A continuación se muestra un Diagrama de Hitos con los hitos más importantes del proyecto:

Semana

1 2 3 4 5 16 17 20 23

Hitos 2-5 feb

9-13 feb

16-20 feb

23-27 feb

2-6 mar

25-19 feb

1-5 jun

24 jun

13-15 jul

Comienzo del TFG •

1ª reunión con el director del TFG

•

Entrega de la introducción, planificación y análisis

•

2º reunión con el director del TFG

•

Comienzo de la formación

•

Comienzo del diseño •

Entrega del diseño •

febrero marzo

L M X J V S D L M X J V S D

1 1

2 3 4 5 6 7 8 2 3 4 5 6 7 8

9 10 11 12 13 14 15 9 10 11 12 13 14 15

16 17 18 19 20 21 22 16 17 18 19 20 21 22

23 24 25 26 27 28 23 24 25 26 27 28 29

30 31


14

Semana

1 2 3 4 5 16 17 20 23

3ª reunión con el director

•

Comienzo de la implementación

•

Entrega de la implementación

•

Comienzo de las pruebas •

Comienzo y entrega del manual de usuario

•

Depósito del TFG •

Defensa •

A continuación se muestra en Diagrama de Gantt con las tareas del proyecto:


15

1.3.6. Plan de comunicación

Durante la duración de todo el proyecto, se buscará mantener una comunicación fluida con el director de proyecto, quien también actúa como cliente del mismo. Dicha comunicación se realizará a través de los siguientes canales:

o Correo electrónico. El servicio de mensajería que utilizará el alumno será Outlook. o Reuniones presenciales. Tendrán lugar en el despacho del director del proyecto, situado en

el Edificio Vives de la Universidad de La Rioja. Las fechas en las que se desarrollarán estas reuniones serán previamente acordadas entre el alumno y el director.

o Aplicación de gestión de trabajos fin de grado. Será la herramienta empleada para efectuar el control y seguimiento del proyecto, así como el intercambio de archivos entregables entre el alumno y el director. Se encuentra disponible en la dirección https://yaiza.unirioja.es:1443/tfg/.

1.3.7. Plan de calidad

Al finalizar cada tarea de las planificadas, se realizará un entregable al director y cliente del proyecto, con el fin de corroborar si el trabajo que se ha llevado a cabo se adecúa a lo pedido y, en caso contrario, poner en marcha los mecanismos oportunos para su corrección.

En este sentido, cabe la posibilidad de que se elaboren plantillas para calificar los diferentes aspectos que se consideren oportunos, especialmente los relativos a la usabilidad de la aplicación. Con el fin de conseguir un producto que cuente con la aceptación de sus usuarios finales se podrá proponer la realización de test de evaluación heurística a diferentes personas.


16


17

CAPÍTULO 2. ANÁLISIS

Una vez descrito el contexto y esbozados los procesos de negocio a los que la aplicación a desarrollar debe dar soporte (ver secciones 1.1 y 1.3.1) en este capítulo, se recoge el análisis y documentación de los requisitos funcionales y no funcionales que deberá soportar la aplicación. Estos requisitos que deben satisfacerse han sido obtenidos mediante una consecución de reuniones con el Director de Estudios del Grado en Ingeniería Informática y el estudio de los problemas y necesidades actuales.

2.1. Requisitos funcionales y roles

La aplicación web a desarrollar estará enfocada a las diferentes partes que intervienen en las prácticas externas del Grado en Ingeniería Informática, en las que se distinguen cinco roles: estudiante, representante de empresa, tutor de empresa, tutor académico y director de estudios. Este último actuará como administrador del sistema. Los cinco serán, por tanto, los actores que se distinguirán en el sistema.

Para poder hacer uso de la aplicación será necesario estar registrado en la misma. Para ello, existirán dos formularios: uno de registro y otro de login. Este último incluirá una opción de recuerdo de contraseña.

El registro de los tutores académicos correrá a cargo del administrador, con el fin de facilitar el trabajo a dichos tutores. El de los tutores de empresa lo realizará el representante de la empresa. El registro para el resto de roles correrá a cargo de cada interesado, si bien también podrá llevarlo a cabo el propio administrador.

Los datos con los que se trabajarán en la aplicación serán los siguientes:

o Empresas: razón social, dirección y teléfono. o Estudiantes: DNI, nombre, apellidos, curso, email de notificaciones, teléfono móvil,

teléfono fijo y dirección. o Tutores académicos: nombre, apellidos, email y teléfono. o Tutores de empresa: nombre, apellidos, cargo y teléfono. o Oferta de prácticas: curso académico, número de práctica, posibilidad de

incorporación en la empresa posterior a las prácticas (Sí/No), posibilidad de realizar el proyecto de grado en la empresa, oferta total de horas en prácticas (175 h o ampliable a 350 h), actividades a realizar por el alumno, tecnologías a emplear durante la práctica, bolsa de ayuda y datos personales del tutor de empresa.

o Solicitud de prácticas: datos de la oferta de prácticas, número de la práctica incluido en la oferta, prelación (orden de preferencia) y datos del estudiante solicitante.

El administrador será, a su vez, tutor académico, al igual que un representante de empresa será también tutor de empresa. Por tanto, los datos del administrador serán los mismos que los de un tutor académico y los datos de un representante de empresa serán los mismos que los de un tutor de empresa.

Una vez identificado el usuario por la aplicación, tendrá acceso a las siguientes funcionalidades según su rol:

2.1.1. Administrador/Director de Estudios

o Modificación de sus datos (detallados antes) y su contraseña. o Alta, baja y modificación de los datos de una empresa, un tutor académico, un estudiante

o una oferta de prácticas en cualquier momento, dentro y fuera de los plazos establecidos.


18

o Visualización de todas las ofertas de prácticas enviadas por las empresas. o Visualización de todos los estudiantes, empresas y tutores académicos registrados y sus

datos. o Visualización de todas las asignaciones de prácticas. o Visualización de las solicitudes de prácticas enviadas por los estudiantes y modificación de

las mismas. Esta acción conllevará el envío de un email al estudiante comunicándole el cambio.

o Publicar la oferta de prácticas. A partir de este momento, las empresas no podrán crear, modificar ni eliminar sus ofertas, y el listado completo de prácticas pasará a estar visible para los estudiantes.

o Gestión de plazos. Podrá establecer las fechas durante las cuales se podrán ofertar, solicitar y calificar las prácticas, lo que conllevará la habilitación o inhabilitación de las acciones correspondientes. También podrá establecer la fecha de publicación de la asignación de plazas.

o Ver un listado ordenable de las notas de los estudiantes de un curso. o Modificar la persona administradora de la aplicación, necesario, por ejemplo, en caso de

que abandone su puesto de Director de Estudios. o Asignar una plaza de prácticas a un estudiante. o Publicar la asignación de plazas. La aplicación enviará un email a cada estudiante

comunicándole su plaza. La empresa no dispondrá de esta información hasta que el estudiante haya formalizado su matrícula en las prácticas, por lo que la aplicación no enviará esta notificación a la empresa.

o Editar la asignación de plazas. Esta edición conllevará el envío de un email al estudiante comunicándole el cambio.

o Descargar una copia de seguridad de la base de datos de la aplicación.

2.1.2. Tutores de empresa

o Modificación de sus datos (detallados antes) y su contraseña. o Visualización de los estudiantes que han sido asignados a las prácticas bajo su tutela en el

presente curso. o Calificación de una práctica bajo su tutela. Para ello dispondrá de un formulario

descargable en formato Word, que incorporará de forma automática los datos de la empresa y del alumno, de forma que no deban rellenarse nuevamente, así como los campos oportunos para efectuar la calificación. Este formulario podrá descargarse, editarse y subirse a la aplicación las veces que sea necesario. Posteriormente, en su versión definitiva, el usuario deberá firmarlo a mano, escanearlo y subirlo a la aplicación, que se encargará de guardarlo en la base de datos y enviarlo por correo electrónico al tutor académico del estudiante. El tutor de empresa no podrá ver el informe del tutor académico ni la memoria del estudiante.

2.1.2. Representante de empresa

o Modificación de sus datos propios y los de la empresa (ambos detallados antes). y su contraseña.

o Creación de una oferta de prácticas. Para ello dispondrá de un formulario online. Por defecto, la aplicación asignará como tutor de empresa de la práctica al representante de empresa, pudiendo ser modificado por el usuario.

o Modificación y eliminación de una oferta de prácticas.

Nota: Tanto la creación, como la modificación y la eliminación de una oferta de prácticas solamente se podrán llevar a cabo dentro del plazo establecido por el administrador para evitar así que se produzcan cambios en una plaza que ya ha sido asignada a un estudiante.


19

o Visualización de los estudiantes que han sido asignados a las prácticas de la empresa, tanto en el presente curso como en cursos anteriores.

o Calificación de una práctica bajo su tutela o bajo la tutela de otro tutor de la empresa. Nota: Tanto para el representante de empresa como para los tutores de empresa, la visualización de los estudiantes asignados solamente serán visibles una vez que estos hayan formalizado su matrícula en la asignatura Prácticas Externas I, Prácticas Externas II, o ambas.

2.1.3. Estudiantes

o Modificación de sus datos (detallados antes) y su contraseña. o Visualización de ofertas de prácticas. Podrán ver un listado con las prácticas ofertadas por

las empresas, una vez publicadas por el administrador. o Solicitud de plaza de prácticas. Podrán solicitar plaza de prácticas a través de un formulario

online indicando al menos cinco prácticas por orden de preferencia. o Modificación y eliminación de una solicitud de prácticas.

Nota: Tanto la creación, como la modificación y la eliminación de una solicitud de prácticas solamente se podrán llevar a cabo dentro del plazo establecido por el administrador.

o Visualizar su solicitud de prácticas. o Visualizar su asignación de plaza de prácticas. Incluirá los datos de la empresa, los datos

del tutor académico y la descripción de las actividades a realizar. o Recibir un email con la notificación de su asignación de prácticas. El sistema notificará al

estudiante por correo electrónico qué plaza de prácticas le ha sido asignada. o Rellenar la memoria de prácticas. En la aplicación estará disponible el formulario

descargable en formato Word, cuyas secciones correspondientes a los datos de la empresa y del estudiante se rellenarán automáticamente. El estudiante deberá rellenar el resto de campos de la memoria. En su versión definitiva, se procederá de la misma forma que se ha explicado para los casos de representante de empresa y tutor de empresa.

2.1.4. Tutores académicos

o Modificación de sus datos (detallados antes) y su contraseña. o Visualización de sus prácticas. Listado de las prácticas que le han sido asignadas, junto a los

datos de la empresa y del estudiante, así como su documentación correspondiente: memoria del estudiante y memoria del tutor de empresa.

o Calificación de las prácticas. Para ello dispondrá de una página de envío de memorias y calificación de la práctica.. Una vez emitida la calificación, el estudiante recibirá un correo electrónico con la notificación.

o Descarga del informe del tutor de empresa, el informe del tutor académico y la memoria del estudiante. Con estos tres documentos cumplimentados y descargados, el tutor académico seguirá el procedimiento habitual consistente en el envío de los mismos a la Oficina del Estudiante. Este envío no es realizado a través de la herramienta a desarrollar.

Independientemente del rol, en las diferentes pantallas de la aplicación se colocarán iconos de tipo “información” junto a términos de la jerga académica (prácticas curriculares, tutor académico, tutor de empresa, etc) con el fin de clarificarlos para una mejor comprensión del usuario. Este paso requerirá de la colaboración final del cliente de la aplicación.


20

2.1.5. Envío automático de correos electrónicos

Muchas de las acciones que se lleven a cabo con la aplicación conllevarán el envío automático de un correo electrónico. Estas funcionalidades son las siguientes:

Desde la cuenta de estudiante. Al solicitar una práctica se envía un email al estudiante y al director de estudios con los datos de la solicitud. Al enviar la memoria de prácticas se envía un email al estudiante y al tutor académico de la práctica.

Desde la cuenta de representante de empresa. Al ofertar una nueva práctica y editar o eliminar una práctica ya ofertada, se envía un email al representante de empresa y al director de estudios con los datos de la acción llevada a cabo. Al enviar la memoria de prácticas se envía un email al representante de empresa y al tutor académico de la práctica. Al registrar un tutor de empresa se envía un email a dicho tutor con un enlace para completar su registro.

Desde la cuenta de tutor de empresa. Al enviar la memoria de prácticas se envía un email al tutor de empresa y al tutor académico de la práctica.

Desde la cuenta de administrador/director de estudios. Al ofertar una nueva práctica, editar o eliminar una práctica ya ofertada, se envía un email al representante de la empresa de la práctica y al propio director de estudios. Al registrar un usuario nuevo se envía un email a dicho usuario con un enlace para completar su registro.

2.2. Requisitos no funcionales

Además de los requisitos funcionales ya enunciados, deberá tenerse en cuenta dos aspectos adicionales:

o La aplicación deberá ser accesible desde cualquier dispositivo y visualizarse correctamente, para lo cual se utilizará un diseño adaptativo (Responsive Design).

o La aplicación deberá contar con los mecanismos de seguridad óptimos para impedir ataques que puedan poner en riesgo la disponibilidad y la confidencialidad de los datos almacenados.


21

CAPÍTULO 3. DISEÑO

Este capítulo recoge los principales aspectos de diseño de la aplicación, con un especial énfasis en la base de datos que dará el soporte a la misma, así como la navegabilidad y el aspecto visual de las diferentes pantallas que conformarán la interfaz gráfica de usuario.

3.1. Diseño de la base de datos

3.1.1. Descripción de la base de datos

Para cada usuario se guarda su identificador, email de acceso, contraseña, rol y estado (activo/inactivo/eliminado). Cuando un usuario solicita registro en la aplicación se guarda el identificador del usuario, la fecha de solicitud y un código que se envía al email del usuario y que debe usar para completar su registro en la aplicación. Si el usuario no tiene estado activo puede solicitar registro en la aplicación todas las veces que quiera.

Un usuario puede ser un estudiante, un tutor de empresa (un representante de empresa también lo es) o un tutor académico (el administrador también lo es).

Un usuario tiene asignado un único rol: estudiante, tutor académico, tutor de empresa, representante de empresa o administrador.

Cada usuario puede solicitar varios cambios de contraseña si la ha olvidado. Para ello, se guarda la fecha de solicitud y un código que se envía al email del usuario y que debe usar para efectuar el cambio.

Para cada estudiante se guarda su DNI, nombre, primer apellido, segundo apellido, curso, teléfono móvil, teléfono fijo, email de notificaciones y dirección.

Para cada empresa se guarda su razón social, web y dirección, y nombre, primer apellido. Para cada tutor de empresa se guarda su nombre, primer apellido, segundo apellido, cargo y teléfono.

Un tutor de empresa puede ser representante de una o ninguna empresa, y una empresa debe tener un único representante de empresa.

Un representante de empresa puede ofertar varias prácticas. De cada práctica se guarda un identificador único, el número de práctica, el curso, el número de horas, la posibilidad de incorporación a la empresa después de las prácticas (Sí/No), la posibilidad de realizar el Trabajo Fin de Grado en la empresa (Sí/No), las actividades a realizar, las tecnologías a emplear y la cuantía de la bolsa de ayuda en caso de haberla.

Cada práctica que oferte un representante de empresa deberá tener asignado un tutor de empresa, que no tiene por qué coincidir con el representante de la empresa. Un tutor de empresa puede serlo de una o varias plazas de prácticas.

Un estudiante puede solicitar varias prácticas. De cada solicitud que haga se guarda el identificador de la práctica, el identificador del estudiante y la prelación con la que elige la plaza.

Una misma práctica puede ser solicitada por varios estudiantes o por ninguno.

A su vez, un estudiante puede tener asignada una práctica, varias (si ha repetido la asignatura o ha cambiado su práctica comenzado el curso) o ninguna (si no ha realizado ninguna solicitud o la ha realizado pero al final no ha formalizado su matrícula).


22

De cada práctica asignada se guarda el identificador de la práctica ofertada, el identificador del estudiante, el identificador del tutor académico, la nota final y los identificadores de las memorias del estudiante, del tutor de empresa y del tutor académico.

De cada memoria se guarda su identificador, nombre, tipo, tamaño y contenido.

De cada tutor académico se guarda su nombre, primer apellido, segundo apellido y teléfono. Un tutor académico puede tener asignadas varias prácticas o ninguna, y una plaza puede tener asignado un único tutor académico o ninguno en caso de que quede vacante.

Adicionalmente se guarda información relativa a los plazos del proceso de prácticas. En concreto se guarda el curso, que es único, las fechas de inicio y fin de la oferta de prácticas, las fechas de publicación de la oferta y la asignación de prácticas, y las fechas de inicio y fin de solicitud de prácticas.

3.1.2. Diagrama Entidad-Relación


23

3.1.3. Modelo relacional

USUARIO

id email contraseña rol estado

Tipos de datos: Id (int). Email, contraseña, rol y estado (varchar).

EMPRESA

id razon_social web direccion

Tipos de datos: Id (int). Razon_social, web y direccion (varchar).

PRACTICA_OFERTADA

id curso num_practica horas posibilidad_TFG

posibilidad_incorporacion tecnologias actividades bolsa_ayuda tutor_empresa

CE:TUTOR_EMPRESA

Tipos de datos: Id, num_practica, horas y tutor_empresa (int). Curso, posibilidad_TFG, posibilidad_incorporacion, tecnologias y actividades (varchar). Bolsa_ayuda (float).

MEMORIA

id nombre tipo tamanio contenido

Tipos de datos: Id y tamanio (int). Nombre, tipo (varchar) y contenido (mediumblob).

PRACTICA_ASIGNADA

id estudiante tutor_academico nota

CE: PRACTICA CE: ESTUDIANTE CE: TUTOR_ACADEMICO

memoria_estudiante memoria_tutor_empresa memoria_tutor_academico

CE: MEMORIA CE: MEMORIA CE: MEMORIA

Tipos de datos: Id, estudiante, tutor_academico, memoria_estudiante, memoria_tutor_empresa y memoria_tutor_academico (int). Nota (float).

TUTOR_EMPRESA

id email nombre primer_apellido segundo_apellido

CE:USUARIO

tfno empresa cargo estado

CE: EMPRESA

Tipos de datos: Id, empresa (int). Email, nombre, primer_apellido, segundo_apellido, tfno, cargo y estado (varchar).


24

TUTOR_ACADEMICO

id email nombre primer_apellido segundo_apellido tfno

CE:USUARIO

Tipos de datos: Id (int). Email, nombre, primer_apellido, segundo_apellido, tfno (varchar).

ESTUDIANTE

id email dni nombre primer_apellido segundo_apellido

CE:USUARIO

curso tfno_movil tfno_fijo email_notificacion

Tipos de datos: Id (int). Email, dni, nombre, primer_apellido, segundo_apellido, curso, tfno_movil, tfno_fijo, email_notificacion (varchar).

SOLICITUD

estudiante plaza prelacion

CE:ESTUDIANTE CE:PLAZA_OFERTADA

Tipos de datos: Estudiante, plaza y prelación (int).

Tipos de datos: Usuario (int). Fecha (date). Codigo (varchar).

PLAZOS

curso inicio_oferta_practicas fin_oferta_practicas fecha_publicacion_ofertas

fecha_publicacion_asignaciones inicio_solicitud_practicas fin_solicitud_practicas

Tipos de datos: Curso (varchar). Inicio_oferta_practicas, fin_oferta_practicas, fecha_publicacion_ofertas, fecha_publicacion_asignaciones, inicio_solicitud_practicas y fin_solicitud_practicas (date).

Cabe señalar la importancia del campo “estado” en la tabla USUARIO.

Un estudiante sólo tendrá acceso a la aplicación durante el curso en el que vaya a realizar prácticas en empresa. Durante el mismo, su estado será “activo”. Al concluir el curso, su estado pasará a ser “eliminado”.

Además, se debe tener en cuenta que un representante de empresa, fuera del plazo durante el que se desarrollan las prácticas, puede eliminar sus tutores de empresa. Si se consideraría que

RECUERDO_CONTRASENIA

usuario fecha codigo

CE:USUARIO

SOLICITUD_REGISTRO

usuario fecha codigo

CE:USUARIO


25

esta acción conllevara el borrado de los registros de la tabla TUTOR_EMPRESA correspondientes al tutor que se va a eliminar, no podría consultarse al curso siguiente qué tutor de empresa tuvo asignado una práctica.

Con el campo “estado” se evita esta situación, puesto que, aunque la empresa tiene la sensación de que está eliminando un tutor de empresa, en realidad no se está borrando de la base de datos, sino que se está cambiando su estado a “eliminado”. No aparecerá, por tanto, si el representante de la empresa consulta sus tutores actuales ni estará disponible ese tutor para asignarlo a una práctica.

3.2. Diseño de la interfaz gráfica de usuario y navegabilidad

Todas las pantallas que compondrán la parte visual de la aplicación llevarán una cabecera con el logotipo de la Universidad de La Rioja y la frase “Gestión de Prácticas en Empresa”. Esta cabecera irá en color con código hexadecimal AC1A2F. Bajo ella se dispondrá un menú horizontal con color con código hexadecimal CCCCB8, siendo ambos los colores oficiales de la universidad. El resto de la pantalla irá en fondo blanco.

Figura 1. Aspecto de la cabecera de las pantallas.

3.2.1. Proceso de registro

Tal y como solicitó en la recogida de requisitos de la aplicación, el registro de los estudiantes y las empresas correrá a cargo de ellos mismos, mientras que el registro de los tutores académicos lo llevará a cabo el administrador/director de estudios y el de los tutores de empresa lo llevará a cabo el representante de esa empresa. Adicionalmente, el administrador también podrá registrar estudiantes, empresas y tutores de empresa. Los estudiantes representan, en número, el grueso de los usuarios de la aplicación. Podría darse el caso de que un estudiante ajeno a la Universidad de La Rioja se registre y acceda a la aplicación y solicite una plaza de prácticas en empresa. De igual modo, podría darse la situación de que un estudiante se registre más de una vez en la misma y desde cada una de sus cuentas solicite plazas. Esto degradaría considerablemente el uso de la aplicación y dificultaría el trabajo del administrador/director de estudios en su tarea de asignar plazas a los estudiantes.

Con el fin de evitar estas situaciones, se ha tomado la decisión de que la autenticación se realice por medio del email de la universidad y una contraseña. El proceso que se seguirá para el registro de un estudiante será el que se explica a continuación:

1. Un estudiante sin registrar accede la página de registro de la aplicación, selecciona el tipo de usuario “estudiante” e introduce su dirección de correo electrónico de la universidad, que será el de acceso a la aplicación.

2. El sistema comprueba si existe un registro en la tabla ESTUDIANTE con el email del usuario. Si no existe, añade un nuevo registro con el email, contraseña nula y estado “inactivo” y envía un email al estudiante con un enlace para confirmar la dirección de correo y completar su registro. Se añade también un nuevo registro en la tabla SOLICITUD_REGISTRO con el identificador del estudiante, la fecha actual y un código aleatorio. Si ya existe un registro con el email del usuario en la tabla ESTUDIANTE y su estado no es “activo” (podría darse el caso de que el estudiante se intente registrar varias veces pero aún no ha confirmado su correo), el sistema reenvía el email al estudiante. Si


26

por el contrario, existe en la tabla ESTUDIANTE pero su estado es “activo”, el sistema muestra un mensaje al usuario indicándole que ya existe el usuario en la aplicación y no se envía el email. Si se da el primero de los casos, se sigue como se indica en los siguientes pasos.

3. El estudiante accede a su correo electrónico de la universidad y pulsa en el enlace recibido. Este enlace contiene el código generado en el paso anterior. De este modo se sabe qué estudiante está confirmando su correo.

4. El sistema redirige al estudiante a una página que contiene un formulario con campos para introducir todos sus datos. Entre ellos figura la contraseña de acceso y una dirección de correo electrónico de notificaciones, adonde le llegarán los correos electrónicos de la aplicación y al que podrán escribirle su tutor académico y su tutor de empresa. Este correo podrá coincidir o no con el de acceso a la aplicación. Para finalizar, el estudiante pulsa el botón “Registrar”.

5. El sistema guarda la contraseña en la tabla USUARIO, cambia el valor del campo “estado” de la misma tabla a activo, guarda el resto de datos introducidos por el estudiante en las tablas ESTUDIANTE y DIRECCION e inicia la sesión del estudiante redirigiéndole al panel de estudiante.

De este modo, por medio del correo de la universidad se asegura que el estudiante pertenezca a la comunidad universitaria.

El registro de las empresas se realizará sin estas comprobaciones, puesto que no disponen de un correo electrónico del dominio de la Universidad de La Rioja.

En cualquier caso, cabe señalar que el administrador siempre podrá eliminar de la aplicación a cualquier usuario del tipo que sea, desde el panel de administración.

A continuación se muestra el diseño y la navegabilidad del proceso de registro de un estudiante. Los prototipos han sido realizados con la herramienta Balsamiq Mockups.

Figura 2. Pantalla de inicio de la aplicación.

Figura 3. Pantalla de registro – introducción del correo.

Figura 4. Pantalla de registro – introducción de datos personales y contraseña.


27

3.2.2. Menús de usuario

Los menús que aparecerán en la aplicación y que ofrecerán acceso a las diferentes funcionalidades de la misma serán los siguientes:

Cuenta de estudiante

Figura 5. Aspecto del menú de estudiante (el resto de menús del resto de roles son visualmente idénticos).

• Mi cuenta. Contendrá un submenú con tres opciones: o Mis datos personales. Permitirá consultar y editar los datos personales. o Cambiar contraseña. Permitirá modificar la contraseña. Solicitará introducir la

actual y dos veces la nueva.

• Oferta de prácticas. Permitirá consultar la oferta de prácticas de las empresas. Si aún no es pública, aparecerá un mensaje indicándolo. En este listado de prácticas aparecerán el nombre y la página web de la empresa, el número de la práctica, el número de horas de prácticas, la posibilidad de hacer el TFG, la posibilidad de incorporación a la empresa, las actividades a realizar, las tecnologías a emplear y la cuantía de la bolsa de ayuda.

• Mi solicitud de prácticas. Permitirá consultar la solicitud de plaza de prácticas del estudiante. Si no se ha realizado todavía y está dentro del plazo para ello, se le explicará y dispondrá de un botón de acceso a la pantalla de solicitud de prácticas. Si ya la ha realizado aparecerán las plazas que ha solicitado, los datos de las plazas y el orden de preferencia indicado. Si, además, está dentro de plazo para modificarla, podrá editarla. Tanto la creación de una nueva solicitud de prácticas del estudiante como su edición dentro de los plazos establecidos por el administrador, conllevarán el envío, por parte de la aplicación, de un email al estudiante y al administrador/director de estudios indicando los datos de la solicitud. Estos correos servirán como resguardo de la solicitud para que quede constancia de la misma para las partes implicadas.

• Mis prácticas. Permitirá consultar los datos de la plaza de prácticas, de la empresa, del tutor de empresa y del tutor académico que han sido asignados al estudiante y descargar, adjuntar y enviar su memoria de prácticas. Si no le ha sido asignada la plaza aún, aparecerá un mensaje indicándolo.

Cuenta de representante de empresa

• Mi cuenta. Será como ya se ha explicado para la cuenta de estudiante.

• Oferta de prácticas. Permitirá consultar las plazas de prácticas que la empresa ha ofertado y editarlas o eliminarlas si está dentro de plazo. Si el usuario pulsa sobre una de ellas, se muestra la descripción detallada de la misma y permite descargar, adjuntar y enviar la memoria de prácticas del tutor de empresa para calificar la práctica. Si aún no se ha ofertado ninguna práctica y está dentro del plazo para ello, se le explicará y dispondrá de un botón “Ofertar nueva práctica” que le redirigirá a un formulario para introducir los datos de la nueva plaza.

• Mis estudiantes. Permitirá consultar los datos de los estudiantes que han sido asignados a la empresa si ha ofertado plazas de prácticas.

• Mis tutores de empresa. Permitirá consultar y editar los datos de los tutores de la empresa, así como registrar nuevos tutores o eliminar existentes. Cuando se cree una nueva oferta de prácticas, estos tutores aparecerán en una lista desplegable para que el usuario seleccione a aquel encargado de tutelarla. La eliminación de un tutor de empresa


28

no se podrá hacer una vez que ha sido asignado a una práctica y esta práctica ha sido asignada a un estudiante.

Cuenta de tutor de empresa


• Mis prácticas. Será igual que la opción “Oferta de prácticas” de la cuenta de representante de empresa, salvo que no podrá gestionar la creación, eliminación o modificación de la oferta prácticas. Únicamente podrá ver y calificar (mediante la memoria del tutor de empresa) las prácticas que le han sido asignadas.

• Mis estudiantes. Permitirá consultar los datos de los estudiantes que le han sido asignados.

Cuenta de tutor académico


• Mis prácticas. Permitirá consultar las plazas de prácticas que han sido asignadas al tutor. Si el usuario pulsa sobre una de ellas, se mostrará la descripción detallada de la misma, incluyendo los datos de la empresa y del tutor de empresa. También permitirá descargar y adjuntar las memorias de prácticas del tutor académico, del tutor de empresa y del estudiante para calificar la práctica. Si no le ha sido asignada ninguna práctica aún, aparecerá un mensaje indicándolo.

• Mis estudiantes. Permitirá consultar los estudiantes que han sido asignados al tutor. Si el usuario pulsa sobre uno de ellos, se le muestran todos los datos del mismo.

Tanto en la cuenta de representante de empresa como en la de tutor académico, los listados de “Mis prácticas” y “Mis estudiantes” incluirán dos pestañas “Curso actual” y “Cursos anteriores” para filtrar las vistas por curso académico.

Cuenta de administrador/director de estudios


• Prácticas. Contendrá un submenú con cinco opciones: o Ofertas. Será como la opción “Oferta de prácticas” de la cuenta de estudiante, con

la diferencia de que se podrán ver a medida que las vayan creando los representantes de las empresas. También se podrán editar y eliminar las prácticas, así como crear nuevas prácticas.

o Solicitudes. Dispondrá de dos pestañas “Por estudiante” y “Por curso”. La primera mostrará un listado con los datos de las solicitudes enviadas por los estudiantes. La segunda mostrará una tabla matriz relacionando los estudiantes del curso con las prácticas y mostrando la prelación con la que las han solicitado. Esto permite tener una visión global de qué prácticas son las más solicitadas y facilita la posterior asignación de las mismas a los estudiantes.

o Asignaciones. Permitirá, en una única pantalla, asignar un estudiante y un tutor académico a una práctica.

o Mis prácticas. Permitirá consultar las plazas de prácticas de las que el administrador es tutor académico. Pulsando sobre una de ellas se mostrarán más detalles de la misma y permitirá descargar y adjuntar las memorias de prácticas del estudiante, del tutor de empresa y del tutor académico.

o Todas las prácticas asignadas. Tendrá la misma funcionalidad que “Mis prácticas” pero extendida a todas, no sólo aquellas de las que el administrador es tutor académico.

o Calificaciones. Permitirá consultar las notas finales de las prácticas del curso. El listado se podrá ordenar por varios campos.


29

• Estudiantes. Contendrá un submenú con tres opciones: o Mis estudiantes. Permitirá consultar los estudiantes asignados al administrador

para la tutela de sus prácticas. Pulsando sobre uno de ellos se mostrarán todos sus datos y se podrán editar y eliminar.

o Todos los estudiantes. Tendrá la misma funcionalidad que “Mis estudiantes” pero extendida a todos, no sólo aquellos de los que el administrador es tutor académico. También permitirá dar de alta nuevos estudiantes.

Los listados de “Mis prácticas”, “Todas las prácticas asignadas”, “Mis estudiantes” y “Todos los estudiantes” incluirán dos pestañas “Curso actual” y “Cursos anteriores” para filtrar las vistas por curso académico.

• Empresas. Permitirá consultar todas las empresas registradas en la aplicación y darles de alta y eliminarlas. Pulsando sobre una de ellas se mostrarán todos sus detalles y los datos de sus tutores de empresa, permitiendo editar cualquier campo, añadir o eliminar tutores de empresa e incluso eliminar la empresa.

• Tutores académicos. Permitirá consultar todos los tutores académicos y crearlos y eliminarlos. Pulsando sobre uno de ellos se mostrarán todos sus datos permitiendo editarlos o eliminar el tutor.

• Configuración. Permitirá configurar los aspectos de administración del sistema: plazos de oferta y de solicitud de prácticas, publicación de la oferta y la asignación de prácticas, realización de la copia de seguridad de la base de datos y cambio de la persona administradora de la aplicación. En todas las cuentas, el menú incluirá un enlace “Cerrar sesión” que estará siempre visible. Al pulsar sobre él, se cerrará la sesión del usuario y se le redirigirá a la página de inicio de la aplicación.

Figura 6. “Estudiantes” > “Todos los estudiantes”.

Figura 7. “Estudiantes” > “Todos los estudiantes".

3.2.3. Estudio de prototipos

Durante la fase de diseño de prototipos de pantallas de la aplicación se han estudiado múltiples posibilidades de navegabilidad y disposición de controles y contenidos en pantalla con el fin de garantizar una buena usabilidad y facilidad de uso de la aplicación, minimizando al máximo en todo momento el trabajo que deba realizar el usuario sobre la interfaz.

Algunas de las pantallas y funcionalidades para las cuales se ha realizado un estudio más exhaustivo de posibilidades han sido las de solicitudes de prácticas, asignación de prácticas e información sobre prácticas y usuarios.

Así, por ejemplo, en la primera de ellas, la de solicitudes de prácticas, se ha barajado la posibilidad (opción 1) de disponer a un lado los datos de las prácticas y al otro una lista desplegable con el orden de preferencia con el cual se solicita una práctica. Ésta opción


30

también se contempló a la inversa: a un lado los órdenes de preferencia y al otro, en lista desplegable, la práctica solicitada.

Otra opción (opción 2) para esta misma funcionalidad ha sido la de utilizar Drag&Drop para arrastrar a un contenedor las prácticas que se deseen solicitar.

Figura 8. Prototipo para la opción 1.

Figura 9. Prototipo para la opción 2.

La opción 1 ha sido desechada, puesto que requiere de múltiples comprobaciones para asegurar que un estudiante no solicita una misma práctica varias veces o que solicita varias prácticas con el mismo orden de preferencia. La opción 2 ha sido sustituida por una tercera opción similar, pero más sencilla de llevar a cabo e implementar, consistente en dos contenedores (uno para las prácticas ofertadas y otro para las solicitadas) y botones con forma de flecha para mover las prácticas entre controles, o en el mismo controlador para cambiar el orden de preferencia.

Figura 10. Prototipo para la opción finalmente elegida.

En cuanto a la funcionalidad de asignación de prácticas, se ha diseñado inicialmente una pantalla con la disposición, en tabla, de los datos de cada práctica y a su lado un botón para ampliar información de la práctica. Esto llevaría a una nueva pantalla con todos los datos ampliados de la práctica y un control para asignarle un estudiante y un tutor académico.

Esta opción ha sido sustituida por otra en la cual se puede realizar la asignación de todas las prácticas de forma más rápida en una única pantalla. Dicha opción presenta una lista desplegable con los estudiantes y otra con los tutores académicos al lado de cada práctica para efectuar las asignaciones.


31

Figura 11. Prototipo para la primera opción.

Figura 12. Prototipo para la opción finalmente elegida.

Por otro lado, también se han barajado diversas posibilidades para la consulta de los datos de las prácticas y los usuarios. Así, por ejemplo, la tabla de la pantalla de oferta de prácticas muestra, para cada una de ellas, sus datos, entre los cuales figuran el tutor de empresa, las actividades y las tecnologías. Del tutor de empresa aparecen su nombre y apellidos, pero no el resto de sus datos como el teléfono o el email de contacto. Para no tener que acceder al menú de tutores de empresa para poder consultar sus datos, se ha decidido que el nombre del tutor de empresa sea un enlace y al pulsar sobre él aparezca una ventana emergente con todos sus datos. De igual modo, la descripción de las actividades y tecnologías de una práctica puede ser muy extensa, por lo que habría demasiado scroll en la pantalla si se mostrasen dichas descripciones al completo. Para evitar esta situación se ha optado por mostrar en la columna correspondiente de la tabla los primeros 80 caracteres de la descripción junto con un signo (+), que es un enlace que muestra en una ventana emergente la descripción completa de las actividades o las tecnologías.

Así es como se ha actuado en todas las funcionalidades que contienen este tipo de datos, relativos a prácticas o usuarios.

Todas las opciones han sido presentadas al cliente y discutidas con él, poniendo en su conocimiento los pros y los contras de cada una de las alternativas y tomando la decisión más oportuna.

En cualquier caso, cabe la posibilidad de que sufran modificaciones a lo largo del desarrollo del proyecto para adaptarse correctamente a las necesidades y exigencias que puedan ir surgiendo. En caso de producirse estas modificaciones y no haber sido solicitadas por el propio cliente, se le expondrán y se llevarán a cabo si se cuenta con su aceptación y conformidad.


32


33

CAPÍTULO 4. IMPLEMENTACIÓN

Este capítulo recoge los aspectos más importantes de la implementación de la aplicación.

4.1. Estructura general de la aplicación

Tal y como se ha señalado anteriormente en el capítulo de planificación de esta memoria, la aplicación se ha desarrollado siguiendo el patrón de arquitectura de software MVC (Modelo-Vista-Controlador). La aplicación se ha desarrollado en tres capas: presentación, lógica de negocio y persistencia. Se han utilizado los lenguajes PHP, JavaScript y HTML, y el paradigma de la programación orientación a objetos.

Para la implementación de cada una de las tres capas se ha utilizado el editor de textos Notepad++ y para la depuración las herramientas “Consola JavaScript” y “Consola PHP” de Google Chrome.

Para efectuar las pruebas necesarias de la aplicación se ha instalado un servidor XAMPP en el equipo local. XAMPP es un servidor multiplataforma, software libre e incluye base de datos MySQL, servidor web Apache e intérpretes para el lenguaje PHP. Por sus características, que lo hacen adaptarse perfectamente a los requisitos tecnológicos que se habían establecido en este TFG, XAMPP ha sido el elegido para el uso por la aplicación web que se ha desarrollado.

4.1.1. Base de datos

La base de datos que da el soporte a toda la aplicación web ha sido creada en MySQL, siguiendo la estructura de tablas que se recoge en el modelo lógico del apartado 3.1.3 de la presente memoria. El script completo de creación de la base de datos que proporciona el soporte de la aplicación se puede encontrar en el Anexo I del CD que acompaña esta memoria.

4.1.2. Capa de persistencia

La capa de persistencia permite el acceso y modificación de los datos almacenados en la base de datos. En esta aplicación, la capa de persistencia está formada por una clase GestorBD.php que se ha implementado para realizar todas las operaciones necesarias sobre la base de datos: consultas, inserciones, modificaciones y eliminaciones.

Todas las gestiones de datos desde la clase implementada GestorBD.php se realizan utilizando el driver de PHP MySQLi (MySQL Improved), que proporciona una interfaz de comunicación con bases de datos MySQL.

Para establecer la conexión con la base de datos se crea una nueva instancia de MySQLi pasando como parámetros los datos del servidor, nombre, usuario y contraseña de la base de datos. Todos estos datos se han incluido en un fichero externo de propiedades, llamado parametros.ini, situado en el directorio raíz de la aplicación.

Figura 13. Script de conexión a la base de datos.

############### BASE DE DATOS ############### #Parámetros para conectar a la base de datos: DB_SERVER=127.0.0.1; DB_NAME=gestion_practicas; DB_USER=root; DB_PASS='';


34

Dado que estos parámetros son necesarios para establecer cualquier conexión, y que cualquier operación sobre la base de datos requiere de una conexión, en la clase GestorBD.php se han declarado constantes para estos datos:

Figura 14. Declaración de constantes de conexión en GestorBD.php.

Como puede verse en el código anterior, por medio de la función de PHP parse_ini_file, se lee el fichero de propiedades y se extraen (controlando la codificación en UTF-8) los valores DB_SERVER, DB_NAME, DB_USER y DB_PASS, almacenándolos en cuatro constantes con el mismo nombre.

Dichas constantes son utilizadas por todos los métodos implementados en GestorBD.php para conectarse a la base de datos y proceder a la manipulación de los datos que corresponda en cada situación.

Figura 15. Establecimiento de conexión con la base de datos desde GestorBD.php.

Figura 16. Código del método getUsuario de GestorBD.php.

Por otra parte, dentro de la capa de persistencia o gestión de recursos, se ha implementado la clase email.php. Dicha clase es la utilizada para el envío de correos electrónicos desde la aplicación y hace uso de otras dos clases PHPMailer.php y SMTP.php, que han sido descargadas de Internet. De estas clases se hablará más adelante en la descripción de la implementación de la funcionalidad de correos electrónicos.

En paralelo a la implementación de estas clases, que constituyen la capa de persistencia de la aplicación, se han implementado otras clases básicas que conforman la capa de lógica de negocio.

public function getUsuario($id){ //Método que devuelve un usuario pasado su id $usuario=null; $mysqli = new mysqli(DB_SERVER, DB_USER, DB_PASS, DB_NAME); $mysqli->set_charset("utf8"); if (mysqli_connect_errno()) { printf("Falló la conexión: %s\n", mysqli_connect_error()); exit(); } $consulta = "select id, email, contrasenia, estado, rol from usuario where id=?"; if ($sentencia = $mysqli->prepare($consulta)) { $sentencia -> bind_param("i", $id); $sentencia->execute(); $sentencia->bind_result($id, $email , $cont_codificada, $estado, $rol); while ($sentencia->fetch()) { $usuario=new Usuario($id, $email,$cont_codificada,$rol,$estado); }

$sentencia->close(); } $mysqli->close(); return $usuario; }

$mysqli = new mysqli(DB_SERVER, DB_USER, DB_PASS, DB_NAME);

$ini_array = parse_ini_file("../parametros.ini"); define('DB_SERVER',mb_convert_encoding($ini_array['DB_SERVER'], "auto", "UTF-8")); define('DB_NAME',mb_convert_encoding($ini_array['DB_NAME'], "auto", "UTF-8")); define('DB_USER',mb_convert_encoding($ini_array['DB_USER'], "auto", "UTF-8")); define('DB_PASS',mb_convert_encoding($ini_array['DB_PASS'], "auto", "UTF-8"));


35

4.1.3. Capa de lógica de negocio

La capa de lógica de negocio actúa como nexo de comunicación entre la capa de persistencia y la capa de presentación. Se encarga de interpretar las acciones llevadas a cabo por el usuario en su interacción con la interfaz gráfica de la aplicación y preparar las nuevas vistas de la interfaz.

En esta aplicación, la capa de lógica de negocio está formada por un amplio conjunto de ficheros PHP, estructurados en dos grupos: las clases básicas y los controladores de la aplicación.

Para entender mejor la forma en que se comunican los controladores y las vistas se muestra un fragmento de código del proceso de consulta de los datos de la práctica de un estudiante, en el que se puede ver cómo se envían los datos de un controlador a una vista.

Figura 17. Fragmento de código del controlador verDatosPractica.php.

Figura 18. Fragmento de código de la vista mis_practicas.php de la cuenta de estudiante.

Las clases básicas son aquellas que, siguiendo el paradigma de orientación a objetos, modelan conceptos del mundo real y permiten realizar operaciones con ellos.

<fieldset class="scheduler-border"> <legend class="scheduler-border">Datos del tutor de empresa</legend> <div class="control-group"> <div class="row"> <div class="col-md-4">

<p><strong>Nombre: </strong><?php echo $practica->tutor_empresa->nombre, ' ', $practica->tutor_empresa->primer_apellido, ' ', $practica->tutor_empresa->segundo_apellido ?></p>

</div> <div class="col-md-4">

<p><strong>Email: </strong><?php echo $practica->tutor_empresa->email?></p> </div> </fieldset>

$estudiante=$_SESSION['estudiante']; if(isset($estudiante)){ $gbd=new GestorBD(); $practica=$gbd->getPracticaAsignadaEstudiante($estudiante); $_SESSION['practica']=$practica; $_SESSION['cursoActual']=$gbd->getCursoActual(); header("Location: mis_practicas.php"); } else{ header("Location: ../index.php"); }


36

En concreto, se han implementado las siguientes clases básicas, estrechamente relacionadas con el esquema conceptual de la aplicación, recogido en el Diagrama Entidad-Relación del apartado 3.1.2 de la presente memoria:

• usuario.php: relativa a cualquier tipo de usuario de la aplicación, es clase base de las tres siguientes.

• estudiante.php: relativa a usuarios con rol de estudiante. Es herencia de usuario.

• tutor_academico.php: relativa a usuarios con rol de tutor académico. Es herencia de usuario.

• tutor_empresa.php: relativa a usuarios con rol de tutor de empresa. Es herencia de usuario.

37

• empresa.php: relativa a empresas.

• practica_ofertada.php: relativa a prácticas ofertadas que no han sido asignadas a estudiantes por el momento.

• practica_asignada.php: relativa a prácticas ofertadas que ya han sido asignadas a estudiantes y a tutores académicos. Es herencia de practica_ofertada.

• solicitud.php: relativa a solicitudes de prácticas en empresa que envían los estudiantes.

• memoria.php: relativa a las memorias de prácticas de estudiantes, tutores académicos y tutores de empresa.

• plazo.php: relativa a plazos de ofertas y solicitudes de prácticas.

4.1.4. Capa de presentación

He buscado en todo momento conseguir un diseño amigable a la vez que intuitivo y fácil de utilizar y, al mismo tiempo, un diseño adaptable a todos los dispositivos y navegadores desde los que pueda accederse a la aplicación.

Para el desarrollo de esta capa se ha elegido Bootstrap, un framework desarrollado por Twitter que permite crear interfaces web utilizando HTML5 y CSS3.

Para su uso se han descargado los archivos CSS y JavaScript que ofrece Bootstrap y han sido incluidos mediante las etiquetas html de enlace <link> en el código fuente de las diferentes pantallas de la aplicación.

Figura 19. Fragmento de código que incluye los archivos de Bootstrap.

Estos ficheros CSS y JavaScript de Bootstrap definen el aspecto visual y el comportamiento de los controles y componentes de la interfaz. En el fragmento de código anterior, estos son bootstrap.min.css y bootstrap.min.js. Además de estos ficheros, se puede observar que se ha utilizado otro fichero CSS llamado round-about.css. Este corresponde a la plantilla que se ha empleado para implementar las pantallas de la aplicación y define estilos propios que no definen los otros dos ficheros, como el color de la cabecera y el pie de página o el tamaño del logo de la Universidad de La Rioja, ente otros.

A continuación se muestra el resultado conseguido en la pantalla de inicio de la aplicación, junto al código correspondiente al formulario de acceso:

Figura 20. Pantalla de inicio de la aplicación.

 <link href="../css/bootstrap.min.css" rel="stylesheet">  <link href="../css/round-about.css" rel="stylesheet">  <script src="../js/bootstrap.min.js"></script>


38

Figura 21. Fragmento de código de la vista index.php.

Por otra parte, para la implementación de ciertas funcionalidades se han descargado plugins adicionales de Bootstrap.

Así, por ejemplo, las tablas han requerido de la incorporación, al proyecto, del plugin Bootstrap Table que permite añadir a las tablas ciertas funcionalidades exigidas en la aplicación, como los listados. Las tablas incluyen un menú con múltiples opciones de configuración (búsquedas, ordenaciones...). Además, para conseguir una mayor integración con la aplicación, y dado que por defecto el menú de la tabla está en inglés, se ha descargado e incorporado al proyecto un fichero de internacionalización de la tabla, bootstrap-table-es-SP.js, para su traducción al idioma español. A continuación se muestra un fragmento de código de cómo se ha utilizado Bootstrap Tables y el resultado que se ha conseguido.

Figura 22. Fragmento de código de creación de una tabla con Bootstrap Tables.

Figura 23. Aspecto de una tabla creada con Bootstrap Tables.

<link rel="stylesheet" href="../css/bootstrap-table.min.css"> <script src="../js/bootstrap-table.min.js"></script> <script src="../js/bootstrap-table-es-SP.js"></script> <div class="table-responsive"> <table class="table table-striped" data-toggle="table" data-search="true" data-show-toggle="true" data-show-columns="true" data-sort-name="stargazers_count" data-sort-order="desc"> <thead> ... </thead> <tbody> ... </tbody> </table> </div>

<form role="form" action="php/validarLogin.php" method="post"> <div class="row"> <div class="form-group" style="margin-left: 10px; margin-right: 10px"> <label for="email">Email de acceso:</label> <input type="text" class="form-control" id="email" name="email" placeholder="Email de acceso" required autofocus > </div> </div> <div class="row"> <div class="form-group" style="margin-left: 10px; margin-right: 10px"> <label for="contrasenia">Contraseña:</label> <input type="password" class="form-control" id="contrasenia" name="contrasenia" placeholder="Contraseña" required> </div> </div> <div class="row"> <div class="col-md-4"></div> <div class="col-md-2"> <button type="submit" class="btn btn-danger">Aceptar</button> </div> <div class="col-md-4"></div> </div> </form>


39

También ha sido necesario añadir un plugin para los campos de tipo fecha, necesario en el menú de configuración de plazos de la cuenta de administrador. Se trata de Bootstrap Datetimepicker.

Figura 24. Fragmento de código del fichero configuracion.php.

Figura 25. Aspecto del control Datetimepicker en el menú “Configuración” de la cuenta de administrador.

A estos dos plugins que se acaban de explicar hay que sumar un tercero para la consulta de datos de prácticas y usuarios (en la forma en que se ha comentado en la sección 3.2.3 Se trata del plugin de JQuery FancyBox.

Figura 26. Fragmento de código de oferta_practicas.php, de la cuenta de empresa.

<script type="text/javascript"> $(document).ready(function() { $("#fancybox").fancybox({ 'width' : '75%', 'height' : '75%', 'autoScale' : false, 'transitionIn' : 'none', 'transitionOut' : 'none', 'type' : 'iframe' }); }); </script> <table ...> <thead> ... </thead>

<tbody> <tr> ...

<td><a id="fancybox" href="../php/verDatos.php?id=<?php echo $practica->id ?>&us=tutor_empresa"><?php echo $practica->tutor_empresa->primer_apellido, ' ', $practica->tutor_empresa->segundo_apellido, ', ', $practica->tutor_empresa->nombre ?></a></td> ...

</tr> </tbody>

</table>

<script type="text/javascript"> $(function () { $('#inicio_oferta').datetimepicker({ locale: 'es' });

}); </script> ... <label for="lbNombre">Inicio del proceso de oferta de prácticas:</label> <input id='inicio_oferta_practicas' name='inicio_oferta_practicas' type='text' class="form-control" />


40

Al pulsar sobre los enlaces que usan FancyBox, se carga la página verDatos.php, con su estilo propio, en una ventana emergente. Este es el comportamiento definido para FancyBox en el fichero JavaScript del plugin que se ha descargado. Es decir, se visualiza una página completa con sus estilos propios en una ventana emergente.

Firgura 27. Aspecto de la consulta de los datos de un tutor de empresa con un FancyBox.

Por otro lado, se ha puesto un especial esfuerzo en el diseño adaptativo. Si bien es cierto que los ficheros CSS y JavaScript de Bootstrap hacen que los elementos HTML ajusten sus diseños y tamaños a la pantalla del dispositivo desde el cual se accede a la aplicación, también es cierto que se han definido otros elementos propios de la plantilla, como la cabecera de las pantallas. Estos elementos propios y sus estilos quedan definidos en el fichero round-about.css y en dicho fichero se ha tenido que controlar esa adaptación del diseño a los dispositivos mediante el uso de las Media Queries, de las que ya se ha hablado en la sección de tecnologías de esta memoria (sección 1.2). Así, por ejemplo, la anchura de la cabecera, el tamaño del logo de la universidad y el tamaño del título de la aplicación se varían en función de la pantalla del dispositivo.

Figura 28. Código de round-about.css que define el estilo para dispositivos con máximo ancho de pantalla de 768px.

4.2. Implementación de funcionalidades de la aplicación

Esta sección recoge una descripción de los mecanismos que se han seguido para implementar las funcionalidades más importantes de la aplicación y que han precisado de un mayor nivel de estudio.

4.2.1. Envío de correos electrónicos

Una de las funcionalidades de mayor importancia de la aplicación es el envío de correos electrónicos a los usuarios utilizando una cuenta externa al servidor de la aplicación, en concreto una de Outlook. Para su implementación, se han empleado las clases SMTP.php y PHPMailer.php, disponibles en Internet, y la clase Email.php, que usa las dos anteriores y que ha sido implementada desde cero tomando algunos ejemplos de foros de Internet.

@media (max-width: 768px){ .titulo { font-size: 20px; height: 100px; display: table-cell; vertical-align: middle; height: 80px; float: none; } .logo { width: 100px; } header { padding: 0px 20px; } }


41

Para el envío de los correos, se ha creado una cuenta en hotmail, gestion.practicas.empresa.gii @hotmail.com. Los datos de la cuenta se han incorporado en el fichero de propiedades parametros.ini de la aplicación.

Figura 29. Parámetros de correo electrónico del fichero de propiedades parametros.ini.

La clase Email.php tiene la siguiente estructura:

Figura 30. Estructura de la clase email.php.

Como puede verse, contiene cuatro atributos para configurar los datos necesarios para enviar el email: destinatario visible, destinatarios ocultos, asunto, cuerpo en formato HTML y cuerpo en formato de texto plano. Estos atributos son inicializados en el constructor de la clase. Además, contiene un método enviarEmail que lee, del fichero parametros.ini, los datos de la cuenta de correo electrónico a usar para el envío del email y procede al envío.

Adicionalmente, aunque no estaba establecido en los requisitos de la aplicación, se ofreció al cliente la posibilidad de incorporar un menú “Mensajes” en la cuenta de administrador con un formulario para enviar un mensaje a los usuarios, bien clasificados por rol o bien a todos. Esta oferta fue aceptada por el cliente y desarrollada durante la fase de implementación.

4.2.2. Descarga de plantillas de memoria

Otro aspecto vital que se ha buscado alcanzar en todo momento durante el diseño y el desarrollo de la aplicación, ha sido facilitar y simplificar al máximo el trabajo de los usuarios. Por ello, ya en la recogida de los requisitos, se fijó que las plantillas para los informes que se ofrecen a estudiantes, tutores de empresa y tutores académicos se rellenen de forma automática. Estas plantillas vienen dadas por la propia Universidad de La Rioja, en forma de formularios rellenables en formato Word.

Como puede apreciarse en la figura siguiente, estas plantillas se proporcionan de tal manera que los actores involucrados deben descargarlas manualmente y rellenar, cada vez, todos los campos de sus formularios, algo que, la aplicación podría hacer automáticamente ya que dispone de los datos de los usuarios almacenados en la base de datos. Por ello, se han implementado los mecanismos oportunos para conseguir que los usuarios únicamente deban rellenar los campos referentes a la descripción de actividades realizadas y calificaciones.

class Email{ var $destinatario, $destinatariosOcultos, $subject, $body, $altBody; function Email($destinatario,$destinatariosOcultos,$subject,$body,$altBody){...} function enviarEmail(){...}

}

############### CORREO ELECTRÓNICO ############### #Parámetros generales: username = [email protected] password = 97432i6770jgmdj86 fullname = Prácticas en Empresa UR #Parámetros para enviar email desde correo de Outlook: secure = tls host = smtp-mail.outlook.com port = 587


42

Figura 31. Plantillas de memoria de estudiante, tutor de empresa y tutor académico.

Inicialmente se buscaron posibles herramientas para conseguir el objetivo planteado, encontrando como sugerencia las librerías FPDF y FPDI. Sin embargo, estas librerías permiten rellenar PDFs mediante el uso de las coordenadas de cada campo, algo no deseable teniendo en cuenta que la longitud de los campos puede ser modificada si cambian las plantillas, y por tanto también sus coordenadas.

A continuación, se pasa a explicar el modo finalmente utilizado para implementar esta funcionalidad.

Las tres plantillas oficiales de memorias de estudiantes, tutores de empresa y tutores académicos han sido obtenidas de la propia Universidad de La Rioja y ubicadas en un directorio “plantillas_memorias” de la aplicación. Todas ellas han sido editadas incluyendo para cada campo rellenable un valor que actúa como identificador del campo.

Figura 32. Plantilla de memoria del estudiante con campos editados con identificadores.

Una vez hecho esto con todos los campos cuyo valor puede ser rellenado automáticamente por la aplicación, al estar almacenado en la base de datos, se ha guardado la plantilla en formato .rtf (originalmente su formato era .doc).

Cualquier usuario de la aplicación, en su menú de calificación de prácticas, dispone de un enlace para descargar la plantilla de memoria que debe enviar.

Figura 33. Enlace de descarga de la plantilla de memoria del estudiante.


43

Este enlace llama al controlador descargarPlantillaMemoria.php,

Figura 34. Fragmento de código del controlador descargarPlantillaMemoria.php.

Como puede verse en el ejemplo anterior, se extrae, de la variable sesión, el estudiante que se encuentra autenticado en el sistema. A continuación, se crea una copia de la plantilla de la memoria y se almacena en una variable “archivo”, y se van reemplazando todos los identificadores de los campos por el valor correspondiente tomado del objeto estudiante, que contiene los datos almacenados en la base de datos. Seguido, se crea un directorio temporal en el que se guarda el fichero modificado, se fuerza su descarga y se elimina el fichero y el directorio.

Este ejemplo muestra cómo se rellenan los datos principales de la plantilla de la memoria del estudiante, pero es aplicable al resto datos y de memorias.

Mediante este mecanismo que se acaba de explicar y, como muestra la figura siguiente, se ha conseguido que todos los datos del usuario y sus prácticas que se encuentran almacenados en la base de datos se rellenan de forma automática, eximiendo a éste de esta tarea.

Figura 35. Plantilla de memoria del estudiante con campos rellenados de forma automática.

4.2.3. Subida de memorias a la aplicación

La calificación de una práctica conlleva el envío de las memorias del estudiante, del tutor de empresa y del tutor académico. Para ello, todos los usuarios, desde su menú de calificación de prácticas, disponen de un formulario para el envío de sus memorias, el cual, tras pulsar el botón “Enviar memoria”, llama al controlador enviarMemoria.php.

Figura 36. Control para el envío de memorias.

$estudiante=$_SESSION['estudiante']; $archivo = file_get_contents('../documentos/plantillas_memorias/estudiante.rtf'); $archivo = str_replace('#dni#',iconv("UTF-8", "Windows-1252", $estudiante->dni),$archivo); $archivo = str_replace('#primer_apellido#',iconv("UTF-8", "Windows-1252", $estudiante->primer_apellido),$archivo); $archivo = str_replace('#segundo_apellido#',iconv("UTF-8", "Windows-1252", $estudiante->segundo_apellido),$archivo); $archivo = str_replace('#nombre#',iconv("UTF-8", "Windows-1252", $estudiante->nombre),$archivo); $aleatorio = rand(1, 10000000); $hash_is = md5($aleatorio); $carpeta = $hash_is; $directorio = '../documentos/temp/'.$carpeta; mkdir($directorio,0777); $enlace = '../documentos/temp/'.$carpeta.'/'.$estudiante->dni.'_memoria_estudiante.doc'; file_put_contents( $enlace,$archivo); header ('Content-Disposition: attachment; filename='.$estudiante->dni.'_memoria_estudiante.doc'); header ('ConTent-Type: application/octet-stream'); header ('Content-Length: '.filesize($enlace)); readfile($enlace); unlink($enlace); //ELIMINA EL ARCHIVO rmdir($directorio); //ELIMINA DIRECTORIO


44

Este formulario, en su código HTML, incorpora el atributo enctype, que sirve para indicar al navegador como debe enviar al servidor los datos del formulario, en nuestro caso multipart/form-data.

Figura 37. Código del formulario de envío de una memoria.

Las memorias enviadas se almacenan en la base de datos. Para ello, y como queda reflejado en la sección 3.1.3 de este documento, se ha creado una tabla llamada “memoria” con cinco campos:

• id (entero). Es el identificador único de cada memoria.

• nombre (carácter). Es el nombre del documento memoria.

• tipo (carácter). Es el tipo MIME de la memoria.

• tamanio. Es el tamaño, en bytes, de la memoria.

• contenido (mediumblob). Es el contenido de la memoria.

El controlador enviarMemoria.php extrae el nombre, el tipo, el tamaño y el contenido del archivo adjuntado. A continuación, comprueba que el tamaño no supera el tamaño máximo permitido de 16 MB y trata el contenido escapando los caracteres especiales mediante la función addslashes de PHP. Esta función es necesaria para que la inserción del contenido del fichero se realice correctamente en la base de datos y no surjan problemas al formar la sentencia SQL, por ejemplo, si el texto contiene comillas dobles. Finalmente, el controlador invoca el método “enviarMemoria” de GestorBD.php, que se encarga de insertar un nuevo registro en la tabla “memoria” de la base de datos, con el identificador (calculado de forma automática al ser un campo auto-incremental), el nombre, el tamaño, el tipo y el contenido de la memoria y actualizar la memoria de la práctica a la que corresponde.

Figura 38. Fragmento de código que sube una memoria a la base de datos.

Tal y como solicitó el cliente de la aplicación, los estudiantes y los tutores de empresa podrán enviar tantas veces como quieran su memoria hasta que el tutor académico haya emitido una nota para la práctica. Siempre que alguno de los usuarios acceda a su menú de calificación de prácticas se mostrará la última versión que han enviado de su memoria, disponiendo de un enlace para descargarla y consultarla.

$fileName = $_FILES['memoria']['name']; $tmpName = $_FILES['memoria']['tmp_name']; $fileSize = $_FILES['memoria']['size']; $fileType = $_FILES['memoria']['type']; if($fileSize>16777216){ //Tamaño del archivo adjuntado es mayor que lo permitido (16 MB) $_SESSION['tamanio_mayor']=1; header("Location: mis_practicas.php"); } else{ $fp = fopen($tmpName, 'r'); $content = fread($fp, filesize($tmpName)); $content = addslashes($content); //Escapa caracteres especiales fclose($fp);

if(!get_magic_quotes_gpc()) { $fileName = addslashes($fileName); //Escapa caracteres especiales }

$memoria=new Memoria(null, $fileName, $fileSize, $fileType, $content); $gbd=new GestorBD();

$enviada=$gbd->enviarMemoria($estudiante, $practica, $memoria); header("Location: mis_practicas.php");

}

<form role="form" action="enviarMemoria.php" method="post" enctype="multipart/form-data"> <input id="memoria" name="memoria" type="file" class="file"> <button name="enviar" id="enviar" type="submit" class="btn btn-default">Enviar

memoria</button> </form>


45

4.2.4. Descarga de memorias

Los usuarios podrán descargar la última versión que hayan enviado de su memoria. En concreto, los estudiantes podrán descargar su memoria del estudiante, los tutores de empresa su memoria del tutor de empresa y los tutores académicos podrán descargar las memorias del estudiante, del tutor de empresa y la suya propia del tutor académico.

Figura 39. Enlace de descarga de la última versión de la memoria de un estudiante.

Este enlace llama al controlador descargarMemoria.php, pasando como parámetros el identificador de la memoria y el de la práctica.

Figura 40. Código del enlace a la descarga de la memoria de un estudiante.

Figura 41. Fragmento de código del controlador descargarMemoria.php para la memoria del estudiante.

En la figura anterior, se puede ver el modo en que se realiza la descarga de una memoria de estudiante. El controlador comprueba que el estudiante está autenticado por el sistema, que el identificador de la práctica pasado como parámetro es el de la práctica del estudiante, y que el identificador de la memoria pasado como parámetro es el de la última memoria del estudiante enviada para esa práctica. Tras realizar dichas comprobaciones, se desencadena la descarga. La descarga de las memorias del tutor de empresa y del tutor académico se realiza de un modo muy similar.

4.2.5. Descarga de la copia de seguridad de la base de datos

Esta funcionalidad responde a una necesidad fundamental de la aplicación, cuya base de datos almacena información vital para la gestión de las prácticas en empresa.

El controlador backup.php es el encargado de exportar la base de datos. Para ello, lee los parámetros de conexión a la base de datos, ubicados en el fichero de propiedades parametros.ini, y los pasa como parámetros en la invocación a su método backup_tables. Este método recibe un parámetro adicional: un listado de las tablas de las cuales se realizará la copia de seguridad. Este listado contiene los nombres de las tablas, ordenadas de mayor a

$id=$_GET['id']; $gbd=new GestorBD(); $memoria=$gbd->getMemoria($id); $practica=$gbd->getPracticaAsignada($_GET['practica']); if(isset($_SESSION['estudiante'])){

$estudiante=$_SESSION['estudiante']; if($practica->estudiante->id==$estudiante->id && $practica->memoria_estudiante->id==$id){

header("Content-length: $memoria->tamanio"); header("Content-type: $memoria->tipo"); header("Content-Disposition: attachment; filename=$memoria->nombre"); echo $memoria->contenido; exit;

} else{ header("Location: ../estudiante/mis_practicas"); }

}

<a href="../php/descargarMemoria.php?id=<?php echo $practica->memoria_estudiante->id ?>&practica=<?php echo $practica->id ?>"><?php echo

$practica->memoria_estudiante->nombre ?></a>


46

menor dependencia, es decir, primero aquellas que contienen campos que son clave foránea a otras tablas, y después aquellas que no contienen estas restricciones. Seguidamente, para cada tabla, el controlador forma una consulta para consultar sus campos y los tipos de éstos, así como los contenidos de las tablas, y por cada resultado que va obteniendo escribe en un fichero las sentencias necesarias para formar el script de creación de la base de datos. Por último, fuerza la descarga del fichero resultado, que contiene el citado script.

La base del código de este controlador ha sido descargada de Internet, y se ha modificado y mejorado para controlar el respeto a las restricciones de integridad de la base de datos, algo que no cuidaba el código original descargado.

El código completo puede consultarse en el Anexo II del CD que acompaña a esta memoria.

4.2.6. Página de error de la aplicación

Se ha implementado una página para aquellas respuestas de error que se puedan recibir del servidor. Esta página desarrollada es error.php y a ella es redirigido ante situaciones de error. Para ello, se ha incluido en el fichero .htaccess, ubicado en el directorio raíz de la aplicación, las siguientes instrucciones:

Figura 42. Fragmento de código del fichero .htaccess.

De este modo, todas las respuestas de error que se obtengan, redirigirán, automáticamente, a la página error.php, que comprueba el código de error enviado por el servidor y forma un mensaje para mostrar al usuario.

Figura 43. Fragmento de código de error.php.

Figura 44. Aspecto de la página error.php ante un error 404.

<?php switch(getenv("REDIRECT_STATUS")){ # "400 - Bad Request" case 400: $error_code = "400 - Bad Request"; $explanation = "La sintaxis de la URL introducida en tu navegador no ha sido

entendida. Por favor, comrpuébala y vuelve a intentarlo."; $redirect_to = ""; break; # "404 - Not Found" case 404: $error_code = "404 - Not found";

$explanation = "La página solicitada no existe o no tienes permiso para acceder a ella.";

break; } ?> ...

ErrorDocument 400 /error.php ErrorDocument 401 /error.php ErrorDocument 403 /error.php ErrorDocument 404 /error.php ErrorDocument 500 /error.php


47

Como puede verse en la figura anterior, se ha incluido un botón “Volver a inicio”, que redirige al usuario a la página de inicio de la aplicación. Si el usuario está autenticado por el sistema, la página destino será la de inicio de su cuenta. Si, por el contrario, no está autenticado, la página destino será la de Login de la aplicación.

4.2.7. Manuales de usuario

Tal y como estaba recogido en los requisitos de la aplicación, se han redactado dos manuales de usuario con el fin de facilitar el uso y aprendizaje de la herramienta.

En concreto, se ha elaborado un manual de administrador, que recoge los aspectos más importantes de un correcto mantenimiento y administración de la aplicación, y un manual de empresa, que explica cómo utilizar las funcionalidades de la aplicación y cómo administrar la cuenta de empresa.

Estos manuales han sido entregados al cliente y quedan recogidos en los anexos III y IV del CD que acompaña a esta memoria.

4.3. Aspectos de seguridad

Cabe señalar que, especialmente por la naturaleza de los datos que alberga y gestiona la aplicación, principalmente datos personales y académicos, era un requisito indispensable desarrollar los mecanismos oportunos para garantizar unas condiciones óptimas de seguridad en todo momento.

Esta sección recoge una descripción de los principales mecanismos que se han seguido para garantizar la seguridad de la aplicación.

4.3.1. Tratamiento de contraseñas de usuarios

Un aspecto especialmente sensible en el ámbito de la seguridad es aquel referido a las contraseñas de los usuarios. Es evidente que la aplicación que se ha desarrollado gestiona contraseñas, puesto que son parte de las credenciales de los usuarios para acceder a sus cuentas.

Hay que tener en cuenta, además, que muchos usuarios utilizan la misma contraseña para todas sus cuentas en internet, por lo que supondría un riesgo muy elevado para la seguridad si no se almacenaran cifradas en la base de datos. Para ello, se ha hecho uso del método password_hash que ofrece PHP.

Figura 45. Fragmento de código que da de alta una contraseña de usuario.

Este código codifica la contraseña guardada en la variable $contrasenia utilizando el algoritmo predeterminado de cifrado bcrypt de PHP. La constante PASSWORD_DEFAULT está diseñada para cambiar automáticamente siempre que se añada un algoritmo de cifrado nuevo y más fuerte a PHP. Por este motivo, la longitud del resultado de usar esta función puede cambiar con el tiempo y es por ello que PHP recomienda almacenar las contraseñas en un campo de la base de datos que pueda ampliarse hasta los 255 caracteres, razón por la que se ha actuado de este modo al definir el campo contrasenia de la tabla USUARIO.

La comprobación de igualdad entre la contraseña introducida por el usuario en el formulario de login (pasada como parámetro) y la contraseña de almacenada en la base de datos se hace por medio de la función password_verify que ofrece PHP. Esto es necesario hacerlo así, puesto

$contrasenia=password_hash($contNueva, PASSWORD_DEFAULT); $usuario->contrasenia=$contrasenia; $gbd=new GestorBD(); $gbd->modificarUsuario($usuario);


48

que las contraseñas no se guardan en claro en la base de datos, sino que se guardan codificadas, para preservar la seguridad de los usuarios de la aplicación.

Figura 46. Fragmento de código que valida el login de un usuario.

En los ejemplos anteriores se han mostrado dos métodos de tratamiento de contraseñas, pero PHP proporciona una librería completa de métodos para garantizar su seguridad.

4.3.2. Tratamiento de datos de entrada

En lo relativo a los datos de entrada de la aplicación, se han controlado su longitud, tamaño máximo y tipo, adecuándolos a lo establecido en la definición de los campos de la base de datos y buscando garantizar en todo momento la disponibilidad de la aplicación web.

Para ello, en todos los campos de entrada de todos los formularios se ha utilizado el atributo maxlength de HTML5:

Figura 47. Fragmento de código de empresa/alta_practica.php.

Así mismo, se ha tenido un especial cuidado con el tratamiento de las memorias de los usuarios, sobre todo en el envío de las mismas. De no controlarse el tipo de archivo y su extensión, la aplicación sería vulnerable a ataques.

Figura 48. Fragmento de código de enviarMemoria.php, que controla el tipo y tamaño máximo del fichero adjunto.

4.3.3. Prevención de ataques de inyección SQL y XSS

Se han tomado las medidas necesarias para prevenir frente a ataques de inyección de código SQL y XSS. Cabe recordar que el primero de ellos aprovecha los campos de entrada de datos para introducir cadenas de caracteres que posteriormente ejecutan acciones sobre la base de datos, mientras que el segundo inyecta en las páginas visitadas por el usuario código JavaScript o en otro lenguaje script similar pudiendo robar información delicada y sesiones de usuario, entre otras amenazas.

Para evitar el primero de ellos, el ataque de inyección SQL, se han empleado Prepared Statements en la clase encargada de efectuar las acciones sobre la base de datos.

if($_FILES['memoria']['type']=="application/pdf" && $_FILES['memoria']['size'] <= 16777216){ ... }

<label for="actividades">Actividades a realizar por el alumno (Proyecto, Tecnología que utilizará en el proyecto y tareas que llevará a cabo el alumno en prácticas): * </label> <textarea class="form-control" maxlength="5000" rows="12" name="actividades"

id="actividades"/>

$contrasenia=$_POST[‘contrasenia’]; $cont_codificada=$usuario->contrasenia; if(password_verify($contrasenia, $cont_codificada)){ header("Location: estudiante/inicio.php"); }


49

Figura 49. Método de GestorBD.php que usa Prepared Statements.

Para evitar el ataque XSS se ha hecho uso de la clase de PHP “PHP Input Filter”, que permite filtrar código malicioso ingresado en los formularios para prevenir ataques XSS de manera sencilla.

Para utilizarla, se han descargado los archivos desde el web oficial e incluido el archivo class.inputfilter.php al inicio de las clases que contienen formularios de entrada de datos.

Figura 50. Fragmento de código que evita el ataque XSS.

Como puede verse en la figura anterior, se crea una instancia de la clase Input Filter y se invoca su método process sobre la variable $_POST, que contiene todos los datos introducidos en el formulario. Dicho método elimina etiquetas HTML de la variable procesada. Pero el constructor de la clase Input Filter también admite parámetros. Éstos son las etiquetas HTML que no se desean eliminar, algo útil, por ejemplo, para conservar saltos de línea en los campos actividades y tecnologías de los formularios de prácticas, y en el campo texto del formulario de mensajes del panel de administrador.

Figura 51. Fragmento de código que evita el ataque XSS permitiendo saltos de línea <br>.

require_once("class.inputfilter.php"); $ifilter = new InputFilter(array('br')); $_POST = $ifilter->process($_POST);

require_once("class.inputfilter.php"); $ifilter = new InputFilter(); $_POST = $ifilter->process($_POST);

public function getTodosEstudiantes(){ //Método que devuelve todos los estudiantes //registrados en la BD $estudiantes=array(); $mysqli = new mysqli(DB_SERVER, DB_USER, DB_PASS, DB_NAME); $mysqli->set_charset("utf8"); if (mysqli_connect_errno()) { printf("Falló la conexión: %s\n", mysqli_connect_error()); exit(); } $consulta = "select id, dni, curso, nombre, primer_apellido, segundo_apellido, calle, poblacion, provincia, cod_postal, tfno_movil, tfno_fijo, email_notificaciones from estudiante order by primer_apellido asc";

if ($sentencia = $mysqli->prepare($consulta)) { $sentencia->execute(); $sentencia->bind_result($id, $dni, $curso, $nombre, $primer_apellido,

$segundo_apellido, $calle, $poblacion, $provincia, $cod_postal, $tfno_movil, $tfno_fijo, $email_notificaciones);

while ($sentencia->fetch()) { $usuario=$this->getUsuario($id);

$estudiante=new Estudiante($usuario->id, $usuario->email, $usuario->contrasenia, $usuario->rol, $usuario->estado, $dni, $curso, $nombre, $primer_apellido, $segundo_apellido, $calle, $poblacion, $provincia, $cod_postal, $tfno_movil, $tfno_fijo, $email_notificaciones);

array_push($estudiantes, $estudiante); } $sentencia->close(); } $mysqli->close(); return $estudiantes; }


50

4.3.4. Protección de accesos

Otro aspecto importante de seguridad es controlar que un usuario sólo pueda acceder a aquellos recursos para los que tiene derecho de acceder. Esto es algo muy ligado a los roles de los usuarios de la aplicación, que determinan las acciones que les está permitido llevar a cabo.

Para implementar este mecanismo de seguridad, se han incluido comprobaciones en todos los ficheros .php, tanto controladores como páginas de la capa de presentación, que vigilan el rol del usuario que accede a ellas.

Figura 52. Fragmento de código del controlador mostrarPracticas.php de la cuenta de estudiante.

Como puede verse en la figura anterior, el controlador mostrarPracticas.php extrae de la sesión el usuario que está autenticado en el sistema, en este ejemplo un estudiante. Previamente, al autenticarse el estudiante en la aplicación, se coloca en la sesión una variable “estudiante” que contiene el objeto estudiante con los datos del usuario. El controlador comprueba si existe esa variable “estudiante” en la sesión y si no es nula (usa el método isset de PHP). En caso afirmativo, se prosigue con las acciones pertinentes. En otro caso, el usuario no goza de permisos para efectuar las acciones que intenta llevar a cabo y se le redirige a la página de inicio de la aplicación. Esta es una comprobación que tiene lugar en cualquier recurso que sea solicitado y requiera de un rol específico de usuario par su acceso, tanto en controladores como en vistas.

Por otra parte, existen una serie de recursos a los que se puede acceder pero para los que la comprobación enunciada en el párrafo anterior no es suficiente. Es el caso, por ejemplo, de la vista verDatos.php. En todas las tablas que aparecen en las diferentes funcionalidades de las cuentas de usuario aparecen enlaces para ampliar información sobre una entidad.

Figura 53. Vista de la página “Mis prácticas” de la cuenta de tutor académico.

En la figura anterior se puede observar que existe un enlace sobre el nombre del estudiante, de la empresa y del tutor de empresa. Estos enlaces abren una ventana emergente con todos los datos de estos usuarios, ampliando la información de los mismos.

Figura 54. Vista de la página “Mis prácticas” pulsando sobre un enlace de ampliación de información.

$estudiante=$_SESSION['estudiante']; if(isset($estudiante)){ $gbd=new GestorBD(); $practica=$gbd->getPracticaAsignadaEstudiante($estudiante); $_SESSION['practica']=$practica; header("Location: mis_practicas.php"); } else{ header("Location: ../index.php"); }


51

El enlace que desencadena esta acción es el siguiente:

Figura 55. Vista de la página “Mis prácticas” pulsando sobre un enlace de ampliación de información.

Un aspecto importante de seguridad a controlar en esta funcionalidad es que un usuario sólo pueda ver los datos para los que tiene permiso de consultar. En el caso del ejemplo anterior, tras invocar al controlador verDatos.php, se comprueba que el tutor académico que está autenticado en el sistema es tutor de una práctica cuyo tutor de empresa tiene el identificador pasado como parámetro (en el ejemplo, el identificador 9). En caso negativo, se deniega el acceso a dicha información.

4.3.5. Protección del fichero de propiedades

Como se ha explicado en anteriores apartados, el fichero de propiedades de la aplicación, parametros.ini, contiene información muy sensible de la aplicación. Es la relativa a datos de conexión con la base de datos y con la cuenta de correo electrónico de la aplicación.

Este fichero de propiedades se encuentra en el directorio raíz de la aplicación. Se han tomado las precauciones oportunas para garantizar que ningún usuario no autorizado pueda leer su contenido mediante acceso al mismo a través de URL.

Para ello, se ha establecido, en el fichero .htaccess de la aplicación, que sea denegado cualquier intento de acceso al fichero de propiedades a través de URL, utilizando la cláusula “files”.

Figura 56. Fragmento de código de .htaccess, que deniega el acceso a parametros.ini vía URL.

<Files "parametros.ini"> Deny from all </Files>

http://localhost/php/verDatos.php?id=9&us=tutor_empresa


52


53

CAPÍTULO 5. INTEGRACIÓN Y PRUEBAS

Durante la fase de desarrollo de la aplicación, se han realizado pruebas funcionales y de diseño, con el fin de asegurar una buena aceptación por parte del cliente y de los usuarios. Para su realización, en todas las reuniones con el cliente se ha probado el funcionamiento de la aplicación y se han discutido diversas cuestiones relativas al diseño de la interfaz, la navegabilidad, el control del usuario y la facilidad de uso y aprendizaje, entre otras cuestiones. Además del cliente, en estas pruebas han participado agentes externos al proyecto, como amigos y familiares, con diferentes niveles de conocimientos informáticos.

La versión final del producto apenas se ha desviado del diseño original que se había establecido para la aplicación.

Tras la finalización de la fase de desarrollo de la aplicación, ésta ha sido probada en diversos tipos de dispositivos y navegadores. En concreto, se ha verificado la correcta visualización y funcionamiento en los siguientes dispositivos: iPad 2 (9,7 pulgadas), iPhone 4S (3,5 pulgadas), iPhone 6 (4,7 pulgadas), Samsung Galaxy S4 (5 pulgadas) y PC Toshiba (17 pulgadas). También se ha empleado la herramienta Window Resizer de Google Chrome para la visualización en diferentes tamaños de pantalla.

La aplicación puede utilizarse sin ningún tipo de problema desde las versiones más recientes de los siguientes navegadores y plataformas:

5.1. Despliegue de la aplicación en el servidor

Tras el desarrollo completo de la aplicación, ésta ha sido desplegada en un servidor proporcionado por la Universidad de La Rioja, siguiendo los pasos que se indican a continuación:

• Creación de una copia de la estructura de la base de datos con MySQL Query Browser.

• Subida de la carpeta “giipe”, que contiene el proyecto completo, al directorio “htdocs” del servidor XAMPP.

• Descarga de la librería de PHP password.php, subida al directorio anterior e importación de la misma en todos los ficheros de la aplicación que hacen uso de las funciones de contraseña de PHP. Este paso ha sido necesario puesto que la versión de PHP que utiliza el servidor XAMPP en el que se ha desplegado la aplicación es la 4, y las funciones de contraseña de PHP están disponibles a partir de la versión 5. La librería password.php las hace compatibles con versiones anteriores instaladas.

La aplicación se encuentra accesible desde la URL https://yaiza.unirioja.es:1443/giipe/.


54


55

CAPÍTULO 6. CONCLUSIONES

Este Trabajo Fin de Grado ha sido desarrollado, como se ha comentado anteriormente, a propuesta del Director de Estudios del Grado en Ingeniería Informática.

Ha supuesto un reto personal al haberlo realizado por cuenta propia fuera del ámbito de una empresa. Este hecho ha exigido una mayor responsabilidad en la gestión de tiempos y horarios de dedicación, al no haber estado sujeto a unas condiciones de trabajo impuestas por otro agente, como lo es una empresa. Por tanto, esto ha servido para desarrollar unas mejores habilidades de auto gestión y auto dependencia en el trabajo.

Por otro lado, ante la libertad ofrecida por el director y cliente del proyecto sobre el lenguaje de programación a utilizar, se decidió emplear PHP, con el cual no se había tenido contacto anteriormente y se carecía de conocimientos. De igual modo, se decidió utilizar Bootstrap como herramienta para el diseño web. Estas tecnologías son unas de las más demandadas actualmente en el mercado laboral en el sector de las tecnologías de la información. Tras cuatro meses trabajando en ello, se han adquirido los conocimientos adecuados para poder enfrentar con éxito nuevos y futuros proyectos con estas tecnologías. Además, se han afianzado otros conocimientos ya existentes como los de seguridad, programación web, bases de datos y diseño de interfaces de usuario.

Este constituye el primer proyecto de grandes dimensiones al que me he enfrentado hasta el momento, habiéndolo concluido con la convicción y satisfacción de un trabajo que ha logrado todos sus objetivos establecidos, en funcionalidades y fechas de entrega, y la consiguiente aceptación del cliente.

El único requisito que finalmente no se ha cubierto ha sido la implementación de campos de tipo información para clarificar el significado de ciertos términos. Esto no ha sido llevado a cabo por falta de tiempo del cliente (que debía seleccionar esos términos) durante la fase de desarrollo del proyecto.

6.1. Tabla comparativa de horas previstas y horas reales

Código Tarea Horas

previstas Horas reales

Motivo de la desviación

T.1.0 Introducción 8 8 -

T.1.1 Contexto 2 2 -

T.1.2 Planificación 6 6 -

T.2.0 Gestión 50 55

T.2.1 Memoria 40 43 Necesidad de incorporar cambios y sugerencias del tutor.

T.2.2 Seguimiento y control 10 12

T.2.3 Defensa 10* -

T.3.0 Análisis 10 10

T.3.1 Requisitos funcionales

7 7 -

T.3.2 Requisitos no funcionales

3 3 -

T.4.0 Formación * -

T.5.0 Diseño 20 16 Menos tiempo necesario para realizar esta tarea.


56

Código Tarea Horas

previstas Horas reales

Motivo de la desviación

T.5.1 Diagrama de clases 6 3 Menos tiempo necesario para realizar esta tarea.

T.5.2 Diseño de base de datos

6 4 Menos tiempo necesario para realizar esta tarea.

T.5.3 Diseño de interfaces 8 9 Necesidad de plasmar con Balsamic Mockup varios de los

prototipos realizados para incorporarlos a esta memoria.

T.6.0 Implementación 200 212

T.6.1 Base de datos 40 32 Menos tiempo necesario para realizar esta tarea.

T.6.2 Presentación 110 100 Menos tiempo necesario para realizar esta tarea.

T.6.3 Lógica de negocio 50 80 Necesidad de mayor tiempo ante la complejidad de ciertas

funcionalidades como la exportación de plantillas, subida y descarga de memorias y copia

de seguridad de la base de datos.

T.7.0 Pruebas 4 8 Necesidad de mayor tiempo

T.8.0 Manual de usuario 8 10 Necesidad de realizar dos manuales de usuario (para administrador y empresa), habiéndose planificado la

realización de un sólo manual.

T.9.0 Despliegue en servidor

- 2 No se había planificado esta tarea.

TOTAL: 300 319

* Las horas de esta tarea no han sido contabilizadas en las 300 horas del TFG.


57

CAPÍTULO 7. BIBLIOGRAFÍA

• Manuales de aprendizaje de Bootstrap http://getbootstrap.com/

http://bootstrap-table.wenzhixin.net.cn/

http://librosweb.es/

• Manuales de aprendizaje de PHP

https://php.net/manual/es/index.php

• CSS3, HTML5 y JavaScript

http://api.jquery.com/

http://www.w3schools.com/

• Código abierto y librerías para envío de email, gestión de memorias y copia de base de datos

https://github.com/

• Foros para consulta y resolución de dudas y problemas

http://stackoverflow.com/

http://www.forosdelweb.com/

Aplicación de Gestión de Prácticas en Empresa – Manual de administrador

1

Aplicación de Gestión de Prácticas en Empresa


- MANUAL DE ADMINISTRADOR –


Trabajo Fin de Grado 2015


2


3

Introducción

Este documento forma parte del Trabajo Fin de Grado realizado por David Peso Llamazares y

tiene la finalidad de recoger los aspectos y conceptos necesarios para un correcto

mantenimiento y administración de la Aplicación de Gestión de Prácticas en Empresa del

Grado en Ingeniería Informática de la Universidad de La Rioja.

La administración de la Aplicación de Gestión de Prácticas en Empresa está diseñada para ser

llevada a cabo desde dos herramientas: una aplicación de administración de MySQL y la propia

aplicación.

Hay que tener presente que, cuando ha sido redactado este documento, la aplicación no se

había alojado aún en ningún servidor, y los datos de acceso relativos a nombres de usuarios y

contraseñas eran los utilizados durante la fase de desarrollo y pruebas. Es por ello que los

datos de acceso que recoge este manual son los utilizados durante las citadas fases.


4


5

1. Aplicación de administración de MySQL

Todos los datos con los que trabaja la aplicación han sido recogidos en una base de datos

MySQL, diseñada para tal fin. A través de una aplicación de administración de MySQL se

podrán manipular todos esos datos. Se deberá tener cuidado para que siempre se respeten las

restricciones de integridad y el esquema de la base de datos, que quedan recogidos en el

Capítulo de Diseño de la Memoria del TFG.

Siempre que se modifique el servidor, el nombre, el usuario o la contraseña de la base de

datos, deberán modificarse estos datos en el fichero de propiedades parametros.ini, ubicado

en el directorio raíz de la aplicación:


6

2. Interfaz de usuario de la aplicación

La aplicación está desarrollada de tal forma que permite llevar a cabo el máximo trabajo

posible de administración desde su propia interfaz de usuario. Para ello deberá accederse a la

página de inicio e introducir las credenciales de administrador.

Una vez autenticado correctamente por el sistema, la aplicación muestra las diferentes

opciones de administración a las que se puede acceder:

Pasemos a explicar, a continuación, las funcionalidades que ofrecen cada una de las opciones

del menú.

2.1. Mi cuenta

Esta es una opción disponible para todos los usuarios de la aplicación, indiferentemente de su

rol (recordar que los roles de usuario son: administrador, estudiante, tutor académico, tutor

de empresa y representante de empresa).


7

Se trata de una funcionalidad que permite consultar y modificar los datos personales del

usuario autenticado (en nuestro caso, del administrador) y modificarlos, así como modificar la

contraseña del usuario para acceder a la aplicación.

Nota importante: Si se desea modificar alguno de los datos que aparecen en los campos

de sólo lectura deberá hacerse desde el propio SGBD. Esto responde a una necesidad

recogida en los requisitos de la aplicación.


8

2.2. Prácticas

Esta opción proporciona acceso a todas las funcionalidades para la gestión de prácticas en

empresa:

2.2.1. Ofertas

Permite consultar las prácticas ofertadas por las empresas en el curso actual y en cursos

anteriores, editarlas, eliminarlas y ofertar nuevas prácticas.

Siempre que se vaya a eliminar una entidad, ya sea prácticas o usuarios (como se explicará más

adelante), la aplicación pedirá confirmación al usuario mediante una ventana emergente.

Nota importante: Las prácticas que se eliminan desde la interfaz de usuario, se eliminan

completamente de la base de datos. Una práctica que ya ha sido asignada a un

estudiante no puede eliminarse desde la aplicación. En este caso, no aparecerá el botón

“Eliminar” y se mostrará como “ASIGNADA”.


9

Para dar de alta una nueva oferta de prácticas en empresa, deberá rellenarse un formulario

indicando la empresa que la oferta y los datos descriptivos de las prácticas.

2.2.2. Solicitudes

Desde esta opción se pueden consultar las solicitudes de prácticas de los estudiantes. Estas

solicitudes pueden visualizarse de dos modos: “Por estudiante” y “Por curso”.

El primer modo, “Por estudiante”, permite consultar las estudiantes enviadas por cada

estudiante de cada curso académico. Estas solicitudes podrán editarse dentro del curso

académico actual.

Siempre que se edite la solicitud de un estudiante y se guarden los cambios, se enviará

automáticamente un correo electrónico al estudiante indicándole la forma en que queda su

solicitud.


10

Nota importante: Siempre que se modifique la cuenta de correo electrónico desde la

que se envían las notificaciones a los estudiantes, deberán editarse sus datos en el

fichero de propiedades parametros.ini, ubicado en el directorio raíz de la aplicación.

Esta nota es aplicable para todas las funcionalidades de la aplicación que conlleven el

envío de un correo electrónico a los usuarios.


11

2.2.3. Asignar prácticas

Permite asignar y desasignar las prácticas ofertadas en el curso actual a estudiantes y tutores

académicos. Para desasignar una práctica, habrá que modificar el valor actual de la lista

desplegables de “Estudiante” o “Tutor académico” por “- Seleccionar -“ y guardar los cambios.

2.2.4. Mis prácticas

Muestra las prácticas de las que el administrador es tutor académico en el curso actual y en

cursos anteriores. Permite también evaluar estas prácticas.


12

Esta funcionalidad permite descargar las plantillas de memoria de estudiante, tutor de

empresa y tutor académico. Estas plantillas se generar auto rellenando los documentos base

de las plantillas con los datos almacenados en la base de datos. Los documentos base de las

plantillas se encuentran en el directorio “documentos” de la aplicación.

Nota importante:

Si se cambia la ubicación o el nombre de los documentos base de las plantillas deberán

modificarse las líneas de los scripts estudiante/descargarPlantillaMemoria.php,

tutor_empresa/descargarPlantillaMemoria.php y

tutor_academico/descargarPlantillaMemoria.php:

Los documentos base de las plantillas deberán ser en formato RTF. Estos presentarán el

siguiente aspecto si se editan con Microsoft Office Word:


13

2.2.5. Todas las prácticas asignadas

Se trata de una funcionalidad que ofrece los mismos servicios que “Mis prácticas” pero

extendidos a las prácticas de todos los tutores académicos.

2.2.6. Evaluaciones

Permite consultar las evaluaciones numéricas de todos los estudiantes, por curso académico.

Si se modifican o añaden campos a las plantillas de memorias, deberán editarse con un

identificador entre símbolos #, como en la figura anterior, y añadirse o editarse en los

scripts estudiante/descargarPlantillaMemoria.php,

tutor_empresa/descargarPlantillaMemoria.php y

tutor_academico/descargarPlantillaMemoria.php:


14

2.3. Estudiantes

Esta opción permite consultar todos los estudiantes registrados en la aplicación, en el curso

actual y en cursos anteriores. Todos ellos se podrán editar y eliminar desde la propia pantalla.

De igual modo, podrán añadirse nuevos estudiantes.

Al añadir un nuevo estudiante deberán indicarse todos sus datos excepto la contraseña. Esta

acción conllevará el envío de un email al estudiante indicándole que el administrador lo ha

registrado en la aplicación y añadiendo un enlace al que acceder para dar de alta su

contraseña.

Nota importante: Un usuario puede estar en uno de tres estados posibles: activo,

inactivo o eliminado.

Un usuario está inactivo cuando no ha completado su proceso de registro en la

aplicación. En este caso, no tiene acceso a la aplicación.

Un usuario está activo cuando ya completado del todo su proceso de registro en la

aplicación. En este caso, sí tiene acceso a la aplicación.

Un usuario está eliminado cuando ha sido eliminado desde la aplicación. En este caso, no

tiene acceso a la aplicación, pero sigue estando almacenado en la base de datos.


15

2.4. Empresas

Permite ver, editar, eliminar y añadir empresas, así como ver, editar, eliminar y añadir sus

tutores de empresa.

Nota importante: El usuario añadido tendrá estado inactivo hasta que acceda al enlace

enviado y proceda a dar de alta su contraseña, momento en el cual pasará a estar activo

y tener acceso a la aplicación. A pesar de no estar activo hasta el momento indicado, el

administrador sí podrá gestionar todas las acciones de la aplicación relativas al usuario.

Esta nota es aplicable a todos los usuarios de la aplicación: estudiantes, empresas,

tutores de empresa y tutores académicos.


16

La funcionalidad de editar una empresa permite, entre otras cosas, cambiar el representante

de la empresa.

La acción de añadir una nueva empresa, al igual, que añadir un nuevo estudiante, conlleva el

envío de un email al representante de la empresa con un enlace para dar de alta su contraseña

de acceso a la aplicación.

2.4.1. ¿Qué hacer si un representante de empresa ha abandonado la empresa?

Podría darse la situación de que un representante de una empresa abandone la empresa y no

haya dejado en ella sus credenciales de acceso para futuras acciones de gestión de prácticas

por parte de ella. El manual de uso de la aplicación que ha sido redactado para las empresas ya

recoge un punto en el cual se pide contactar a quien vaya a ser el nuevo representante de la

empresa con el administrador de la aplicación.

Se pueden dar dos casos distintos dentro de esta situación:

1. Existen más tutores de la empresa y uno de ellos va a ser el nuevo representante. En este

caso, el administrador podrá realizar el cambio de representante desde el menú

“Empresas”>”Editar” y seleccionar el nuevo representante en la lista desplegable

“Representante de empresa”.


17

2. No existen más tutores de la empresa o existen más tutores de la empresa y el que va a

ser el nuevo representante no es uno de ellos. En este caso, el administrador podrá dar de

alta al nuevo representante de la empresa desde el menú “Empresas”>”Ver

tutores”>”Añadir nuevo tutor” y nombrarlo representante de la empresa como se ha

explicado en el párrafo anterior.

2.5. Tutores académicos

Permite ver, editar, eliminar y añadir tutores académicos.

La funcionalidad de añadir un nuevo tutor tiene el mismo comportamiento que añadir un

estudiante, un tutor de empresa o una empresa. Conlleva el envío de un email con un enlace

para dar de alta la contraseña de acceso a la aplicación.

Nota importante: No es necesario dar de alta a usuarios desde la interfaz de usuario.

Esto puede realizarse desde el propio SGBD, añadiendo en las tablas correspondientes

(usuario, estudiante, empresa, tutor_empresa y tutor_academico) los datos del nuevo

usuario. Esto puede ser especialmente cómodo cuando se vayan a dar de alta muchos

usuarios nuevos. En este caso, al realizarse desde la propia base de datos, no tiene lugar

el envío automático de un email con el enlace para dar de alta la contraseña de acceso a

la base de datos. Para darla de alta en esta situación, los nuevos usuarios deberán

acceder a la sección “¿Has olvidado tu contraseña?” de la página de inicio de la

aplicación e introducir su dirección de correo electrónico de acceso. Es en este momento

cuando se envía el enlace para proceder al alta de la contraseña.


18

2.6. Mensajes

Permite enviar un mensaje a un grupo determinado de usuarios de la aplicación: estudiantes,

representantes de empresa, tutores de empresa, tutores académicos o todos los usuarios.

2.7. Configuración

Permite gestionar todos los aspectos relativos a la configuración de la aplicación, los cuales se

detallan a continuación:

Plazos: Fechas y horas de inicio y fin del proceso de ofertas y solicitudes de prácticas, y fechas

de publicación de la oferta y asignaciones de prácticas.


19

Concluir curso: Necesario en el momento en que finaliza el período de prácticas en empresa

del curso actual. Conlleva la inactivación automática de todos los estudiantes del curso actual,

de modo que ya no podrán acceder a la aplicación.

Administrador: Permite modificar el administrador de la aplicación. Conlleva el cierre de

sesión del administrador actual y el cambio de rol. El administrador actual pasa a tener el rol

de tutor académico y el tutor académico seleccionado pasa a tener el rol de administrador.

Copia de seguridad: Permite descargar una copia completa de la base de datos. Esta copia

luego puede ser restaurada desde el propio SGBD.

Nota importante: Es necesario indicar las fechas de inicio y fin. En caso de que una de las

dos esté vacía, se entenderá que el plazo no está abierto, por lo que no se podrán ofertar

ni solicitar las prácticas.

Nota importante: El script que crea y descarga la copia de seguridad de la base de datos

se encuentra en administrador/backup.php de la aplicación.

Este script contiene una línea en la que se indican todas las tablas de la base de datos de

las que se realizará la copia de seguridad. Es muy importante que estas tablas se

indiquen por orden mayor a menor número de dependencias funcionales, es decir,

primero aquellas tablas que contienen restricciones de integridad hacia otras tablas, y

después aquellas tablas que contienen campos a los que se refieren otras tablas. Esto

debe ser así para preservar todas las restricciones de integridad de la base de datos y

evitar errores en el proceso de restauración.


20

Aplicación Web para la Gestión de Prácticas en Empresa – Manual de empresa

1

Aplicación Web para la

Gestión de Prácticas en Empresa


- MANUAL DE EMPRESA –


2


3

Introducción

Este documento tiene la finalidad de recoger los aspectos y conceptos necesarios para un

correcto uso de las cuentas de empresa de la Aplicación de Gestión de Prácticas en Empresa

del Grado en Ingeniería Informática de la Universidad de La Rioja.

En el ámbito de las empresas, deberán distinguirse dos roles distintos de usuario:

representante de empresa y tutor de empresa.

El primero de ellos, el representante de empresa, será aquél que disponga en su cuenta de

todos los permisos necesarios para la administración y gestión de las prácticas que oferta su

empresa.

El segundo, el tutor de empresa, dispondrá en su cuenta de permisos para gestionar

únicamente las prácticas que le sean asignadas a él para su tutela.

En las siguientes páginas se explica con más detalle las funcionalidades de cada uno de estos

roles, y los principales aspectos de uso de la aplicación para las empresas.


4


5

1. Interfaz de usuario del representante de empresa

La aplicación está desarrollada de tal forma que permite llevar a cabo trabajo de

administración desde su propia interfaz de usuario. Para ello deberá accederse a la sección de

registro, seleccionar el tipo de usuario “Empresa” e indicar una dirección de correo

electrónico. Tras pulsar “Aceptar”, llegará un email a la dirección indicada con un enlace al que

debe accederse para completar el proceso de registro en la aplicación.

Dicho enlace, llevará al representante de empresa una página para introducir los datos de la

empresa y los del representante de empresa.

Con los datos introducidos, y pulsado el botón “Aceptar”, el proceso de registro de la empresa

en la aplicación se habrá completado. A partir de este momento, se puede acceder a la cuenta

de empresa. Para ello, desde la página de inicio de la aplicación, se deberán introducir las

credenciales de acceso: la dirección de correo electrónico contraseña indicadas en el proceso

de registro.


6

Una vez autenticado correctamente por el sistema, la aplicación muestra las diferentes

opciones de administración a las que se puede acceder:

Pasemos a explicar, a continuación, las funcionalidades que ofrecen cada una de las opciones

del menú.


7

1.1. Mi cuenta


representante de empresa y los datos de la empresa, así como modificar la contraseña del

usuario para acceder a la aplicación.


de sólo lectura deberá contactarse con el administrador de la aplicación, que será el

Director de Estudios del Grado en Ingeniería Informática de la Universidad de La Rioja.

Para ello, se podrá utilizar el enlace disponible en el pie de página de la página de inicio

de la aplicación.


8

1.2. Prácticas

Esta opción proporciona acceso a todas las funcionalidades para la gestión de prácticas en

empresa:

1.2.1. Oferta

Permite consultar las prácticas ofertadas por las empresas en el curso actual y en cursos

anteriores, editarlas, eliminarlas y ofertar nuevas prácticas.

Siempre que se esté dentro del plazo de oferta de prácticas, el cual será establecido por el

Director de Estudios, aparecerá en esta funcionalidad del menú un botón para ofertar nuevas

prácticas . Además, dentro de este mismo plazo, si se ha ofertado alguna

práctica, aparecerán dos opciones en la fila de la tabla que muestra las características de la

práctica ofertada y para editar las características de la práctica o

eliminarla. Sólo se podrá eliminar una práctica dentro del plazo de oferta de prácticas.

Siempre que se vaya a eliminar una entidad, ya sea prácticas o usuarios (como se explicará más

adelante), la aplicación pedirá confirmación al representante de empresa mediante una

ventana emergente.

Para dar de alta una nueva oferta de prácticas en empresa, deberá rellenarse un formulario

indicando el tutor de empresa de la práctica (se deberá seleccionar uno de entre todos los


9

tutores de empresa registrados en la cuenta de empresa) y los datos descriptivos de la

práctica.

Todas estas características podrán editarse, como ya se ha comentado anteriormente, dentro

del plazo de oferta de prácticas. Si se desea modificar cualquier característica de la práctica

fuera del plazo de oferta de prácticas, ya sean datos propios de ella o el tutor de empresa, se

deberá poner en contacto con el Director de Estudios para proceder a la modificación. Para

ello, y como ya se ha explicado antes, se podrá utilizar el enlace disponible en el pie de página

de la página de inicio de la aplicación.

1.2.2. Todas las prácticas

Muestra todas las prácticas que ha ofertado la empresa y han sido asignadas a estudiantes.

Permite también calificar todas las prácticas de la empresa, independientemente de quién sea

su tutor de empresa.


10

Esta funcionalidad permite descargar la plantilla de memoria del tutor de empresa. Para

calificar la práctica, deberá rellenarse esta plantilla, firmarla, adjuntarla al formulario y

enviarla.


11

1.2.3. Mis prácticas

Se trata de una funcionalidad que ofrece los mismos servicios que “Todas las prácticas” pero

reducidos únicamente a las prácticas de las que el representante de empresa es tutor de

empresa.

1.3. Tutores de empresa

Permite ver, editar, eliminar y añadir tutores de empresa. Estos tutores luego podrán ser

asignados a una práctica en el momento de dar de alta la oferta (menú Prácticas->Oferta

->Ofertar nueva práctica).

Un tutor se podrá eliminar si en ese momento no es tutor de empresa de alguna práctica del

curso académico actual. En este caso, no aparecerá el botón “Eliminar”, pero sí el botón

“Editar”. Si se desea eliminar un tutor de empresa en este caso, se deberá contactar con el

Director de Estudios.

El representante de empresa, por el hecho de serlo, es también tutor de empresa. Si se desea

dar de alta a otros usuarios con el rol de tutor de la empresa, se podrá hacerlo desde la opción

“Añadir nuevo tutor”.

Al añadir un nuevo tutor de empresa deberán indicarse todos sus datos excepto la contraseña.

Esta acción conllevará el envío de un email al nuevo tutor indicándole que el representante de


12

su empresa lo ha registrado en la aplicación y añadiendo un enlace al que acceder para dar de

alta su contraseña.

Hasta que el nuevo tutor no complete su registro dando de alta su contraseña, no podrá

acceder a su cuenta de usuario, pero el representante de empresa sí podrá realizar cualquier

gestión de ese tutor de empresa mientras tanto, tanto edición de datos, como asignación del

tutor a una nueva oferta de prácticas.

1.4. Configuración

Permite modificar el representante de la empresa. Para ello, deberá elegirse el nuevo

representante de entre todos los tutores de empresa registrados hasta el momento por la

empresa.

Esta acción conllevará el cierre de sesión del representante actual y el envío de un correo

electrónico al nuevo representante informándole del cambio de rol que tendrá en la

aplicación. Desde este momento, el representante antiguo podrá acceder a la aplicación, pero

con las funcionalidades únicas de un tutor de empresa, no de un representante de empresa.


13

1.5. ¿Qué pasa si mi representante de empresa ya no es mi empleado

y no sé la contraseña de acceso a su cuenta de usuario?

Un aspecto que puede, a priori, preocupar a una empresa es qué se debe hacer si su

representante ha abandonado la empresa por alguna circunstancia y no ha cambiado el

representante de la empresa en la aplicación ni ha dejado sus credenciales para que otros

puedan hacerlo.

Si se produce esta situación, se deberá poner en contacto la persona que vaya a asumir la

representación de la empresa en la aplicación con el Director de Estudios del Grado en

Ingeniería Informática de la Universidad de La Rioja.


14

2. Interfaz de usuario del tutor de empresa

Como ya se ha indicado anteriormente en este manual, el representante de la empresa es

también tutor de la empresa. Las explicaciones de uso de la aplicación que se recogen a

continuación están orientadas a los usuarios que sean tutores de empresa pero no

representantes de ella.

El proceso de registro de un tutor de empresa deberá llevarlo a cabo el representante de la

empresa desde su cuenta de usuario, como se ha explicado en el apartado 1.3 de este

documento.

Una vez que se haya completado el proceso de registro de un tutor de empresa en la

aplicación, éste podrá acceder a su cuenta de usuario introduciendo en la página de inicio sus

credenciales de acceso: el correo electrónico que haya indicado el representante de la

empresa en el proceso de registro y la contraseña que haya indicado el tutor de empresa al

acceder al enlace que haya recibido en el email de registro.

Una vez autenticado por la aplicación, se mostrarán al tutor de empresa las diferentes

funcionalidades a las que puede acceder, las cuales se detallan a continuación:

2.1. Mi cuenta


tutor de empresa, así como modificar su contraseña para acceder a la aplicación.


de sólo lectura deberá contactarse con el administrador de la aplicación, que será el

Director de Estudios del Grado en Ingeniería Informática de la Universidad de La Rioja.


15

2.2. Mis prácticas

Se trata de una funcionalidad que permite consultar las prácticas que han sido asignadas al

tutor de empresa y a un estudiante, tanto en el curso actual como en cursos anteriores.

Esta opción del menú permite también calificar las prácticas del curso actual y ver las

calificaciones de las prácticas de cursos anteriores.


16

Esta funcionalidad permite descargar la plantilla de memoria del tutor de empresa. Para

calificar la práctica, deberá rellenarse esta plantilla, firmarla, adjuntarla al formulario y

enviarla.


17


18

aplicación web para la gestión de prácticas en empresadado que se desea que la aplicación que se...

Documents