GRADO EN INGENIERÍA INFORMÁTICA

Ingeniería de Sistemas Móviles

UCO TOOLS
Autores: Fernando Fernández Martínez
Abraham Godoy Sánchez
Beatriz Illanes Alcaide
Maria Elena Pedrajas Perabá
Antonio Soto Montes

Profesor: Gonzalo Cerruela García

Córdoba, Diciembre de 2017

Índice general

Índice de figuras V

Índice de tablas VII

1. Visión y Ámbito 1
1.1. Requisitos de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1. Oportunidades de negocio y necesidades del cliente . . . . . . . . . 1
1.1.2. Objetivos de negocio y criterios de éxito . . . . . . . . . . . . . . . 1
1.1.3. Riesgos de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Visión de la solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1. Declaración de la visión . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2. Caracterı́sticas principales . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.3. Suposiciones y dependencias . . . . . . . . . . . . . . . . . . . . . . 2

2. Descripción Funcional 3
2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Identificación de los Actores . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Análisis de los Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4.1. Caso de uso Visualizar horario aula . . . . . . . . . . . . . . . . . . 5
2.4.2. Caso de uso Realizar encuesta . . . . . . . . . . . . . . . . . . . . . 6
2.4.3. Caso de uso Habilitar encuesta . . . . . . . . . . . . . . . . . . . . 7
2.4.4. Caso de uso Deshabilitar encuesta . . . . . . . . . . . . . . . . . . . 8
2.4.5. Caso de uso Firmar . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.6. Caso de uso Visualizar estadı́sticas asignatura . . . . . . . . . . . . 10
2.4.7. Caso de uso Login . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3. Especificación de Requisitos 13
3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Requisitos Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. Requisitos funcionales del caso de uso Visualizar horario aula . . . . 13
3.2.2. Requisitos funcionales del caso de uso Realizar encuesta . . . . . . . 13
3.2.3. Requisitos funcionales del caso de uso Habilitar encuesta . . . . . . 14
3.2.4. Requisitos funcionales del caso de uso Deshabilitar encuesta . . . . 14
3.2.5. Requisitos funcionales del caso de uso Firmar . . . . . . . . . . . . 14

i
ii ÍNDICE GENERAL

3.2.6. Requisitos funcionales del caso de uso Visualizar estadı́sticas asig-

natura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.7. Requisitos funcionales del caso de uso Login . . . . . . . . . . . . . 15
3.3. Requisitos no Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.1. Entorno operativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.2. Restricciones de implementación y diseño . . . . . . . . . . . . . . . 15
3.3.3. Suposiciones y dependencias . . . . . . . . . . . . . . . . . . . . . . 16
3.3.4. Otros requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . 16

4. Modelo de Datos 17
4.1. Análisis de Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1. Tipo de Entidad Persona . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2. Tipo de Entidad Profesor . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.3. Tipo de Entidad Estudiante . . . . . . . . . . . . . . . . . . . . . . 19
4.1.4. Tipo de Entidad Estudiante no contratado . . . . . . . . . . . . . . 20
4.1.5. Tipo de Entidad Estudiante contratado . . . . . . . . . . . . . . . . 20
4.1.6. Tipo de Entidad Asignatura . . . . . . . . . . . . . . . . . . . . . . 20
4.1.7. Tipo de Entidad Lugar . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.8. Tipo de Entidad Asistencia . . . . . . . . . . . . . . . . . . . . . . 23
4.1.9. Tipo de Entidad Encuesta . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.10. Tipo de Entidad Estadı́stica . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Diagrama Entidad-Relación . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3. Modelo Relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5. Primer Sprint 29
5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2. Estimación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.1. Estimación de la historia Diseño y creación de la base de datos . . . 30
5.2.2. Estimación de la historia Ver horario aula . . . . . . . . . . . . . . 30
5.2.3. Estimación de la historia Firmar . . . . . . . . . . . . . . . . . . . 31
5.2.4. Estimación de la historia Habilitar encuesta . . . . . . . . . . . . . 31
5.3. Seguimiento del Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4. Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.5. Estructura de ficheros resultante . . . . . . . . . . . . . . . . . . . . . . . . 33
5.5.1. Historia 0.1 - Diseño y creación de la Base de Datos . . . . . . . . . 34
5.5.2. Historia 1.1 - Ver Horario Aula . . . . . . . . . . . . . . . . . . . . 34
5.5.3. Historia 5.1 - Firmar . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5.4. Historia 3.1 - Habilitar Encuesta . . . . . . . . . . . . . . . . . . . 35
5.6. Pruebas unitarias de las historias . . . . . . . . . . . . . . . . . . . . . . . 35
5.6.1. Pruebas unitarias de la historia visualizar horario . . . . . . . . . . 36
5.6.2. Pruebas unitarias de la historia habilitar encuesta . . . . . . . . . . 37
5.6.3. Pruebas unitarias de la historia firmar . . . . . . . . . . . . . . . . 38

6. Segundo Sprint 43
6.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.2. Estimación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
ÍNDICE GENERAL iii

6.2.1. Estimación de la historia Realizar encuesta . . . . . . . . . . . . . . 43

6.2.2. Estimación de la historia Deshabilitar encuesta . . . . . . . . . . . 45
6.2.3. Estimación de la historia Visualizar estadı́stica encuesta . . . . . . 46
6.2.4. Estimación de la historia Login . . . . . . . . . . . . . . . . . . . . 46
6.3. Seguimiento del Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.4. Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.5. Estructura de ficheros resultante . . . . . . . . . . . . . . . . . . . . . . . . 48
6.5.1. Historia 2.1 - Realizar Encuesta . . . . . . . . . . . . . . . . . . . . 48
6.5.2. Historia 4.1 - Deshabilitar Encuesta . . . . . . . . . . . . . . . . . . 49
6.5.3. Historia 6.1 - Visualizar Estadı́sticas Encuesta . . . . . . . . . . . . 49
6.5.4. Historia 7.1 - Login . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.6. Pruebas unitarias de las historias . . . . . . . . . . . . . . . . . . . . . . . 50
6.6.1. Pruebas unitarias de la historia visualizar encuesta . . . . . . . . . 50
6.6.2. Pruebas unitarias de la historia realizar encuesta . . . . . . . . . . . 52
6.6.3. Pruebas unitarias de la historia deshabilitar encuesta . . . . . . . . 54
6.6.4. Pruebas unitarias de login . . . . . . . . . . . . . . . . . . . . . . . 55

7. Conclusiones 57
7.1. Matrices de trazabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2. Futuras mejoras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Bibliografı́a 61
Índice de figuras

2.1. Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

4.1. Diagrama Entidad-Relación . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2. Modelo Relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1. Burndown Chart Primer Sprint . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2. Estructura de la base de datos en PhpMyAdmin . . . . . . . . . . . . . . . 34
5.3. Pruebas unitarias de la historia visualizar horario . . . . . . . . . . . . . . 36
5.4. Comprobación de la prueba en la tabla Lugar . . . . . . . . . . . . . . . . 37
5.5. Comprobación de la historia visualizar horario en la tabla Lugar-Asignatura 37
5.6. Prueba unitaria de la historia habilitar encuesta . . . . . . . . . . . . . . . 38
5.7. Parte 3 de la prueba unitaria de la historia habilitar encuesta . . . . . . . . 39
5.8. Comprobación de la historia habilitar encuesta en la tabla EstudianteContratado-
Encuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.9. Comprobación de la historia habilitar encuesta en la tabla Asignatura . . . 40
5.10. Visualización del menú tras la prueba unitaria de habilitar encuesta . . . . 40
5.11. Parte 1 de la prueba unitaria de la historia firmar . . . . . . . . . . . . . . 41
5.12. Parte 2 de la prueba unitaria de la historia firmar . . . . . . . . . . . . . . 42
5.13. Parte 3 de la prueba unitaria de la historia firmar . . . . . . . . . . . . . . 42

6.1. Encuesta de calidad docente de la Universidad de Córdoba . . . . . . . . . 44

6.2. Burndown Chart Segundo Sprint . . . . . . . . . . . . . . . . . . . . . . . 48
6.3. Pruebas unitarias de escoger asignatura para visualizar sus estadı́sticas . . 51
6.4. Pruebas unitarias de la historia ver estadı́sticas asignatura . . . . . . . . . 51
6.5. Pruebas unitarias de la visualización de la información del estudiante al
realizar la encuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.6. Pruebas unitarias de la visualización de la información de la asignatura . . 52
6.7. Pruebas unitarias de la visualización de la encuesta docente de un profesor 53
6.8. Pruebas unitarias del error para no realizar múltiples veces una encuesta . 53
6.9. Pruebas unitarias del mensaje de error de la historia deshabilitar encuesta 54
6.10. Pruebas unitarias de la historia deshabilitar encuesta . . . . . . . . . . . . 54
6.11. Pruebas unitarias de la historia login . . . . . . . . . . . . . . . . . . . . . 55
6.12. Pruebas unitarias del error de la historia login . . . . . . . . . . . . . . . . 55

v
Índice de tablas

2.1. Caso de Uso Visualizar horario aula . . . . . . . . . . . . . . . . . . . . . . 5

2.2. Caso de Realizar Encuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Caso de Uso Habilitar Encuesta . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Caso de Uso Deshabilitar Encuesta . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Caso de Uso Firmar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6. Caso de Uso Visualizar estadı́sticas asignatura . . . . . . . . . . . . . . . . 10
2.7. Caso de Uso Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.1. Estimación de la historia Diseño y creación de la base de datos . . . . . . . 30

5.2. Estimación de la historia Ver horario aula . . . . . . . . . . . . . . . . . . 30
5.3. Estimación de la historia Firmar . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4. Estimación de la historia Habilitar encuesta . . . . . . . . . . . . . . . . . 31
5.5. Seguimiento de primer sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.1. Estimación de la historia Realizar encuesta . . . . . . . . . . . . . . . . . . 45

6.2. Estimación de la historia Deshabilitar encuesta . . . . . . . . . . . . . . . . 45
6.3. Estimación de la historia Visualizar estadı́stica encuesta . . . . . . . . . . . 46
6.4. Estimación de la historia Login . . . . . . . . . . . . . . . . . . . . . . . . 46
6.5. Seguimiento del segundo sprint . . . . . . . . . . . . . . . . . . . . . . . . 47

7.1. Matriz de trazabilidad requisitos funciones - casos de uso . . . . . . . . . . 58

7.2. Matriz de trazabilidad requisitos funciones - historias . . . . . . . . . . . . 59

vii
Capı́tulo 1

Visión y Ámbito

1.1. Requisitos de negocio

1.1.1. Oportunidades de negocio y necesidades del cliente
Actualmente se establece en la Universidad de Córdoba un control de la asistencia del
personal docente a través de un papel, en el que éstos tienen que firmar. Este sistema es
poco fiable, ya que todo el mundo tiene acceso a dicho papel. Además un administrativo
debe llevar a cabo la tediosa tarea de pasar a mano este control de asistencia a un sistema
informático. Por tanto, el desarrollo de un sistema que permita el control y gestión de
la información de asistencia de los profesores supondrı́a un gran beneficio en costes de
papel, tiempo del personal contratado y fiabilidad de los datos obtenidos, agilizando este
proceso.
Por otro lado, otro de los problemas que se presentan en la Universidad de Córdoba
es el proceso de evaluación de la calidad docente, en el cual se contrata a un estudiante
que se encarga de realizar las encuestas y pasar la información obtenida de forma manual
al sistema.
Nuestra propuesta permitirá también que los resultados obtenidos se inserten de forma
automática en el sistema, ahorrando de nuevo costes en material fı́sico, como son el papel
y los sobres, y tiempo de realización de dicho proceso.
Por último, también se llevará a cabo una propuesta de transparencia con una página
web en la que se puedan ver las estadı́sticas recabadas por el sistema a lo largo de los
procesos comentados anteriormente.

1.1.2. Objetivos de negocio y criterios de éxito

ON-1: Reducir el gasto de papel en un 50 % en la Universidad de Córdoba a los 6
meses después del lanzamiento inicial.

ON-2: Aumentar un 30 % la fiabilidad y consistencia de los datos sobre asistencia

del personal docente 3 meses después del lanzamiento inicial.

ON-3: Reducir en un 85 % el tiempo destinado a estos procesos manuales por parte

de los administrativos y estudiantes contratados desde el lanzamiento inicial.

1
2 1.2. VISIÓN DE LA SOLUCIÓN

1.1.3. Riesgos de negocio

RN-1: Que los usuarios a los que va destinado el sistema no lo usen por la necesidad
de disponer de la tecnologı́a NFC.

RN-2: Que el sistema no se use porque los usuarios a los que va destinado des-
conozcan el funcionamiento y uso de este por no tener una aplicación de uso de
referencia.

RN-3: Necesidad de mantener un sistema alternativo por si el usuario olvida/extravı́a

o tiene algún percance con el dispositivo que acredite su identidad para hacer uso
del sistema.

1.2. Visión de la solución

1.2.1. Declaración de la visión
Para que los administrativos y estudiantes contratados puedan trabajar más efectiva-
mente, con menos esfuerzo, se tenga un mayor control sobre el personal docente, y para
propiciar una mayor fiabilidad y consistencia de los datos, el sistema permitirá la confir-
mación y seguimiento de la asistencia y la realización de las encuestas de calidad docente.
A diferencia de la gestión administrativa actual realizada en papel, el uso del sistema no
solo permitirá que los usuarios sean más productivos, sino que también ahorrarán tiempo
independientemente del conjunto de perfiles de usuario al que pertenezcan.

1.2.2. Caracterı́sticas principales

El sistema tiene como objetivos fundamentales abarcar las tres caracterı́sticas princi-
pales siguientes:

CP-1: Poder visualizar los horarios de las asignaturas que se imparten en cada aula.

CP-2:Poder acreditar la asistencia a una clase de un profesor o alumno.

CP-3: Permitir a los estudiantes realizar las encuestas de calidad docente.

1.2.3. Suposiciones y dependencias

S-1: Suponemos que la red de la empresa funciona correctamente para que los
empleados lleven a cabo su función.

S-2: Suponemos que los sistemas de gestión de asistencia docente y control de

calidad funcionan correctamente.

D-1: Se deberá de llevar una concordancia en la base de datos entre los datos que
se recojan de forma manual y los emitidos por el sistema.
Capı́tulo 2

Descripción Funcional

2.1. Introducción
En este capı́tulo se exponen las funcionalidades necesarias para conseguir abordar las
tres caracterı́sticas principales expuesta en el primer capı́tulo.
Para ello, se definirán los distintos roles que pueden intervenir en los procesos ası́ como
las responsabilidades y caracterı́sticas de cada uno de estos.
Posteriormente se expondrán las diferentes funcionalidades que debe presentar el siste-
ma para permitir alcanzar los objetivos fijados y los criterios de negocio, teniendo siempre
en cuenta las restricciones de tiempo del proyecto y las limitaciones tanto software como
hardware.

2.2. Identificación de los Actores

En el sistema se han identificado 5 actores:

Profesor. Es una persona que solicita ser registrado en el sistema para poder con-
firmar su asistencia en las aulas pertinentes.

Administrativo.Es un trabajador de la organización que tiene entre sus tareas la

obligación de introducir los datos de asistencia docente.

Estudiante Contratado.En este sistema su función principal es realizar las en-

cuentras y enviar los resultados al sistema, por lo que deberá estar registrado en
este.

Estudiante.Es una persona que realiza las encuestas, firma su asistencia a las clases
y visualiza información sobre las aulas registradas en el sistema.

Tiempo. Durante la vida del sistema, es el encargado de activar alertas y de notificar

los distintos eventos que ocurren.

3
4 2.3. DIAGRAMA DE CASOS DE USO

2.3. Diagrama de Casos de Uso

Como se ha comentado, las funcionalidades generales a alcanzar para poder llevar a
cabo las tres caracterı́sticas o funcionalidades principales son los casos de uso que podemos
ver en el siguiente diagrama de casos de uso de contexto. Este se ha realizado siguiendo
la notación de UML 2 [1].

Figura 2.1: Diagrama de Casos de Uso

CAPÍTULO 2. DESCRIPCIÓN FUNCIONAL 5

2.4. Análisis de los Casos de Uso

A continuación se detallan los casos de uso, indicando el actor que los inicia, las precon-
diciones y postcondiciones y los flujos y excepciones que pueden ocurrir. El identificador
definido en estos se usará a lo largo de todo el documento para referenciarlos.

2.4.1. Caso de uso Visualizar horario aula

Tabla 2.1: Caso de Uso Visualizar horario aula

ID 1
Nombre caso de uso Visualizar horario aula
Actor Persona
La persona visualiza el horario de las asignaturas
Descripción
que se imparten en el aula.
Precondicion Ninguna
Visualizar horario de un aula
Paso Acción
Secuencia Normal La persona pasa su móvil por el TAG NFC y
1 solicita al sistema la información de los
horarios para ese.
El TAG NFC devuelve una URL con la
2
información del horario para ese aula.
El sistema permite a la persona visualizar
3
la información sobre el aula.
La persona visualiza la información de los
Postcondición
horarios del aula.
La persona puede acceder a la información del
Cursos alternativos
horario del aula conociendo la URL y el id del aula.
Excepciones Ninguna.
Includes Ninguno.
Extends Ninguno.
Prioridad Alta.
Frecuencia Esperada Varias veces por persona al dı́a.
Requisitos Especiales Ninguno.
Suposicicones Ninguna.
6 2.4. ANÁLISIS DE LOS CASOS DE USO

2.4.2. Caso de uso Realizar encuesta

Tabla 2.2: Caso de Realizar Encuesta

ID 2
Nombre caso de uso Realizar Encuesta
Actor Estudiante
Descripción El estudiante rellena la encuesta obtenida.
Precondicion El estudiante tiene que estar logueado en el sistema.
Realizar Encuesta
Paso Acción
Si el estudiante no ha iniciado sesión, el
1
estudiante realiza el caso de uso login.
Secuencia Normal La persona pasa su móvil por el TAG NFC y
2
solicita al sistema la encuesta.
El TAG NFC devuelve una URL con la
3 encuesta de la asignatura que se da en
el aula.
El sistema permite al estudiante visualizar la
4
encuesta de esa asignatura.
El estudiante rellena la encuesta
proporcionada por el sistema, con su
5 información personal y la valoración
docente de cada profesor que imparte la
asignatura.
6 El estudiante envı́a la encuesta rellenada.
El sistema comprueba que el estudiante se
7
encuentre en el lugar establecido.
Postcondición Se ha realizado una encuesta para ese usuario.
Paso Acción
Cursos alternativos Si el estudiante no está matriculado en esa
asignatura, ya ha realizado la encuesta ó la
4.1 encuesta no está habilitada, el sistema
muestra un mensaje de error y no deja
enviar la encuesta
Si el estudiante no se encuentra en el lugar
7.1
establecido, no podrá rellenar la encuesta.
Excepciones Ninguna.
Includes Login.
Extends Ninguno.
Prioridad Media.
Una vez al cuatrimestre por asignatura/estudiante
Frecuencia Esperada
matriculado.
Requisitos Especiales Ninguno.
Suposicicones Ninguna.
CAPÍTULO 2. DESCRIPCIÓN FUNCIONAL 7

2.4.3. Caso de uso Habilitar encuesta

Tabla 2.3: Caso de Uso Habilitar Encuesta

ID 3
Nombre caso de uso Habilitar Encuesta
Actor Estudiante contratado
Descripción El estudiante contratado habilita la encuesta.
El estudiante contratado tiene que estar logueado
Precondicion
en el sistema.
Habilitar Encuesta del sistema
Paso Acción
Si el estudiante no ha iniciado
1 sesión, el estudiante realiza el caso de uso
Secuencia Normal
login.
El estudiante contratado pasa su móvil por
2 el TAG NFC y solicita al sistema la encuesta
a gestionar.
El TAG NFC devuelve una URL con la
3
gestión de la encuesta.
El sistema muestra la información de la
4 encuesta a habilitar al estudiante
contratado.
El estudiante contratado habilita la
5
encuesta.
6 El sistema confirma la operación
Se ha habilitado una encuesta, y es visible para el
Postcondición
estudiante que solicite realizarla.
Cursos alternativos Ninguno.
E.1 La encuesta seleccionada ya está habilitada
Excepciones
Paso Acción
Si la encuesta ya está habilitada, el sistema
1 cancela la operación, a continuación este
caso de uso termina.
Includes Login.
Extends Ninguno.
Prioridad Media.
Frecuencia Esperada Una vez al año por asignatura.
Requisitos Especiales Ninguno.
Suposicicones Ninguna.
8 2.4. ANÁLISIS DE LOS CASOS DE USO

2.4.4. Caso de uso Deshabilitar encuesta

Tabla 2.4: Caso de Uso Deshabilitar Encuesta

ID 4
Nombre caso de uso Deshabilitar Encuesta
Actor Estudiante Contratado
Descripción El estudiante contratado deshabilita la encuesta.
El estudiante contratado tiene que estar logueado
Precondicion
en el sistema.
Deshabilitar Encuesta del sistema
Paso Acción
Si el estudiante no ha iniciado sesión, el
1
estudiante realiza el caso de uso login.
Secuencia Normal
El estudiante contratado pasa su móvil por
2 el TAG NFC y solicita al sistema la encuesta
a gestionar.
El TAG NFC devuelve una URL con la
3
gestión de la encuesta.
El sistema permite al estudiante contratado
4
visualizar la gestion de esa asignatura.
El estudiante contratado deshabilita la
5
encuesta.
6 El sistema confirma la operación
Se ha deshabilitado una encuesta, y no es
Postcondición
accesible para los estudiantes que soliciten realizarla.
Cursos alternativos Ninguno.
E.1 La encuesta seleccionada ya está
Excepciones deshabilitada
Paso Acción
Si la encuesta ya está deshabilitada, el
1 sistema cancela la operación, a
continuación este caso de uso termina.
Includes Login.
Extends Ninguno.
Prioridad Media.
Frecuencia Esperada Una vez al año por asignatura.
Requisitos Especiales Ninguno.
Suposicicones Ninguna.
CAPÍTULO 2. DESCRIPCIÓN FUNCIONAL 9

2.4.5. Caso de uso Firmar

Tabla 2.5: Caso de Uso Firmar

ID 5
Nombre caso de uso Firmar
Actor Persona
Descripción La persona firma para confirmar su asistencia.
La persona tiene que ser un profesor o un
Precondicion
estudiante registrado en el sistema.
Firmar en el sistema
Paso Acción
Si la persona no ha iniciado sesión, el
Secuencia Normal
1 sistema realiza el caso de uso iniciar
sesión.
El sistema muestra la hora, aula y
2
asignatura.
3 La persona pulsa sobre el botón firmar.
En el sistema queda almacenado la
4
asistencia.
Queda registrada la asistencia tanto de la persona
Postcondición
(tanto del profesor como del alumno).
Paso Acción
Cursos Alternativos
Si la persona no se encuentra en el lugar
3.1 donde se imparte la asignatura, el sistema
no permite que firme.
Excepciones Ninguna.
Includes Login.
Extends Ninguno.
Prioridad Media.
Frecuencia Esperada 1 vez al dı́a por persona en cada asignatura.
Requisitos Especiales Ninguno.
Suposicicones Ninguna.
10 2.4. ANÁLISIS DE LOS CASOS DE USO

2.4.6. Caso de uso Visualizar estadı́sticas asignatura

Tabla 2.6: Caso de Uso Visualizar estadı́sticas asignatura

ID 6
Nombre caso de uso Visualizar estadı́sticas asignatura
Actor Persona
La persona visualiza las estadı́sticas de una
Descripción
asignatura.
Precondicion Ninguna.
Visualizar el horario de un aula
Paso Acción
Secuencia Normal
La persona accede a la aplicación web y
1 selecciona la asignatura de la que quiere
ver las estadı́sticas.
El sistema devuelve la información sobre
2
las estadı́sticas de esa asignatura.
La persona visualiza la información de la estadı́stica
Postcondición
seleccionada.
Paso Acción
Cursos Alternativos
Si la encuesta de esa asignatura aún no ha
2.1 sido realizada el sistema muestra un
mensaje de error.
Excepciones Ninguna.
Includes Ninguno.
Extends Ninguno.
Prioridad Baja.
Frecuencia Esperada Varias veces por persona al dı́a.
Requisitos Especiales Ninguno.
Suposicicones Ninguna.
CAPÍTULO 2. DESCRIPCIÓN FUNCIONAL 11

2.4.7. Caso de uso Login

Tabla 2.7: Caso de Uso Login

ID 7
Nombre caso de uso Login
Actor Persona
Descripción La persona se loguea en el sistema.
Precondicion La persona debe estar registrada en el sistema.
Iniciar Sesión en el sistema
Paso Acción
La persona, introduce en el sistema sus
1
Secuencia Normal datos.
El sistema verifica los datos introducidos por
2
la persona.
La persona pulsa sobre el botón “Iniciar
3
sesión”
4 En el sistema crea una sesión.
5 La persona se encuentra activa en sesión.
Postcondición El usuario queda logueado en el sistema.
Paso Acción
2.1 El sistema muestra un mensaje de error.
Cursos alternativos
El sistema redirige a la persona, para que
2.2
introduzca de nuevo los datos.
2.3 El sistema vuelve a verificar los datos.
Excepciones Ninguna.
Includes Ninguno.
Extends Ninguno.
Prioridad Alta.
Frecuencia Esperada Una vez por asignatura que tenga la persona al dı́a.
Requisitos Especiales Ninguno.
Suposicicones Ninguna.
Capı́tulo 3

Especificación de Requisitos

3.1. Introducción
En este capı́tulo se exponen los requisitos funcionales y no funcionales que el sistema
debe cumplir para obtener la funcionalidad de las caracterı́sticas principales y objetivos
de negocio.
Como se va a seguir la metodologı́a ágil SCRUM [2], se hará referencia a este conjunto
también como Product Backlog en capı́tulos posteriores.
Para ello, estos requisitos se expondrán en función de los casos de uso de los que
derivan, facilitando ası́ su trazabilidad y posterior prueba, mantenimiento y calidad.

3.2. Requisitos Funcionales

Los requisitos funcionales se han ordenado en función de los casos de uso definidos en el
apartado 2.4. A estos requisitos se les ha añadido un identificador para poder referenciarlos
posteriormente.

3.2.1. Requisitos funcionales del caso de uso Visualizar horario

aula
RF 3.1.1.1. El sistema deberá permitir ver a una persona el horario de un aula ese
dı́a.

RF 3.1.1.2. El sistema deberá permitir a una persona seleccionar el aula de la que

desea consultar su horario.

3.2.2. Requisitos funcionales del caso de uso Realizar encuesta

RF 3.1.2.1. El sistema deberá permitir a un estudiante poder visualizar una en-
cuesta habilitada para una asignatura en la que esté matriculado.

RF 3.1.2.2. El sistema deberá permitir a un estudiante rellenar y enviar una en-

cuesta que esté habilitada para una asignatura.

13
14 3.2. REQUISITOS FUNCIONALES

RF 3.1.2.3. El sistema deberá almacenar los estudiantes que han realizado una
encuesta.

RF 3.1.2.4. El sistema deberá comprobar que el estudiante se encuentra en la

geolocalización correcta para poder enviar la encuesta.

3.2.3. Requisitos funcionales del caso de uso Habilitar encuesta

RF 3.1.3.1. El sistema deberá permitir al estudiante contratado visualizar la in-
formación de una encuesta para una asignatura.

RF 3.1.3.2. El sistema deberá permitir al estudiante contratado habilitar una en-

cuesta para una asignatura.

3.2.4. Requisitos funcionales del caso de uso Deshabilitar en-

cuesta
RF 3.1.4.1. El sistema deberá permitir que un estudiante contratado deshabilite
una encuesta que tenga asignada.

RF 3.1.4.2. El sistema deberá generar las estadı́sticas de una asignatura una vez
que esta esté deshabilitada.

3.2.5. Requisitos funcionales del caso de uso Firmar

RF 3.1.5.1. El sistema deberá comprobar que el estudiante se encuentra en la
geolocalización correcta para firmar la asistencia a una asignatura.

RF 3.1.5.2. El sistema deberá permitir a una persona visualizar el conjunto hora,

aula, asignatura cuando vaya a efectuar la firma de asistencia.

RF 3.1.5.3. El sistema deberá permitir a una persona firmar su asistencia en una

asignatura.

RF 3.1.5.4. El sistema deberá almacenar la asistencia de las personas a una asig-

natura.

3.2.6. Requisitos funcionales del caso de uso Visualizar estadı́sti-

cas asignatura
RF 3.1.6.1. El sistema deberá permitir a los usuarios de la aplicación la visualiza-
ción de las estadı́sticas de las asignaturas.

RF 3.1.6.2. El sistema deberá permitir a una persona que seleccione la asignatura

de la que desea ver las estadı́sticas.
CAPÍTULO 3. ESPECIFICACIÓN DE REQUISITOS 15

3.2.7. Requisitos funcionales del caso de uso Login

RF 3.1.7.1. El sistema deberá permitir logearse a las personas para poder acceder
a las principales funcionalidades.

RF 3.1.7.1. El sistema deberá permitir cerrar sesión a las personas cuando estas
lo deseen.

3.3. Requisitos no Funcionales

Para definir los requisitos no funcionales se exponen las consideraciones que se han de
tener en cuenta sobre el sistema, ası́ como su entorno operativo y restricciones a las que
se encuentra sujeto.

3.3.1. Entorno operativo

Se ha de tener en cuenta que el sistema ha sido desarrollado bajo las siguientes carac-
terı́sticas:

EO-1. Se ha usado un servidor de hosting gratuito [3] que tiene como caracterı́sticas
[4] soporte de PHP version PHP 7.1, MySqL versión 4.5.6, soporte FTP, WordPress
y 1000 MB de espacio en disco.

EO-2. Las pruebas sobre navegador web y el desarrollo se han realizado sobre un
dispositivo MSI con un intel core i7, 16 GB de RAM y sistema operativo Windows
10, y sobre los ordenadores de la Universidad de Córdoba.

EO-3. Las pruebas unitarias se han desarrollado sobre los dispositivos móviles Sam-
sung Galaxy A5, con 2 Gb de RAM y procesador Exynos 7580 y un dispositivo LG
G6 con 4Gb de Ram y procesador Snapdragon 821

EO-4. El sistema UCO-TOOLS podrá usarse en los navegadores Internet Explorer

versión 5.0 y 6.0 y en las versiones más recientes de Mozilla, Safari, Google Chrome
y Opera.

EO-5. El sistema deberá operar en un servidor corriendo con las versiones de Ubuntu
o CentOS y Apache HTTP.

3.3.2. Restricciones de implementación y diseño

RD-1. El proceso de implementación, diseño y análisis deberá de seguir los estánda-
res de W3C para la visualización en páginas web.

RD-2. Todo el código HTML se ajustará al estándar HTML 5.0.

RD-3. Todos los scripts se escribirán en Bash.

RD-4. Todos los dispositivos que usen el sistema deben contar con tecnologı́a NFC.
16 3.3. REQUISITOS NO FUNCIONALES

3.3.3. Suposiciones y dependencias

D-1. Se deberá de llevar una concordancia en la base de datos entre la información
recogida de forma manual y la introducida por el sistema.

D-2. Dado que el servidor es un host gratuito, este no se encuentra disponible en

la relación 24/7, pudiendo encontrarse deshabilitado en ciertas ocasiones.

D-3. La capacidad de mantenimiento y posteriores actualizaciones dependen del

host gratuito usado.

3.3.4. Otros requisitos no funcionales

RNF 3.2.4.1. El sistema deberá asegurar la confidencialidad de los datos de los
usuarios, como ası́ lo indica la Ley de Protección de Datos [5].

RNF 3.2.4.2. El sistema deberá estar disponible como mı́nimo 12 horas al dı́a, 7
dı́as a la semana, 365 dı́as al año.

RNF 3.2.4.3. El sistema deberá ser capaz de soportar, como mı́nimo, 20 peticiones
simultáneas.

RNF 3.2.4.4. El sistema deberá funcionar a pleno rendimiento mientras el número

de usuarios conectados no supere 300.
Capı́tulo 4

Modelo de Datos

4.1. Análisis de Entidades

4.1.1. Tipo de Entidad Persona
Descripción. El tipo de entidad Persona representa al objeto del mundo real “Ser
humano”.

Caracterı́sticas

• Nombre de la entidad: Persona.

• Atributo/s heredado/s: -
• Atributo/s identificador/es principal/es: correo.
• Atributo/s identificador/es alternativo/s: -
• Número de atributos: 4.

Atributos propios. El tipo de entidad Persona se compone de tres atributos, los

cuales se describen a continuación:

• correo
◦ Definición del atributo: representa el e-mail identificativo que se le asigna
a cada Persona dentro del sistema.
◦ Dominio: conjunto alfanumérico de longitud máxima 15 caracteres (inclu-
yendo ‘@’ como caracter especial).
◦ Tipo: atributo simple.
◦ Ejemplo: i42gosaa@uco.es
◦ Información adicional: es clave primaria o identificador principal del tipo
de entidad. Es de carácter obligatorio.
• password
◦ Definición del atributo: representa la contraseña asociada al correo de una
Persona.
◦ Dominio: conjunto alfanumérico de longitud máxima 8 caracteres.

17
18 4.1. ANÁLISIS DE ENTIDADES

◦ Tipo: atributo simple.

◦ Ejemplo: uco12345
◦ Información adicional: Es de carácter no nulo.
• nombre
◦
◦ Definición del atributo: representa el nombre completo de una Persona.
◦ Dominio: conjunto de caracteres de longitud máxima 50.
◦ Tipo: atributo simple.
◦ Ejemplo: Fernando Fernández Martı́nez.
◦ Información adicional: Es de carácter no nulo.
• rol
◦ Definición del atributo: representa el rol de una Persona.
◦ Dominio: conjunto de caracteres de longitud máxima 10.
◦ Tipo: atributo simple.
◦ Ejemplo: profesor.
◦ Información adicional: Es de carácter no nulo y sólo puede tomar dos
valores: “profesor” o “estudiante”.

4.1.2. Tipo de Entidad Profesor

Descripción. El tipo de entidad Profesor representa al objeto del mundo real “Per-
sona que imparte docencia o realiza labores de investigación en un departamento de
una universidad”.

Caracterı́sticas

• Nombre de la entidad: Profesor.

• Atributo/s heredado/s: correo, password, nombre.
• Atributo/s identificador/es principal/es: correo.
• Atributo/s identificador/es alternativo/s: -
• Número de atributos: 4.

Atributos propios.El tipo de entidad Profesor se compone de un atributo, el cual

se describen a continuación:

• departamento
◦ Definición del atributo: representa el departamento que tiene asignado para
desarrollar su labor docente y de investigación un Profesor.
◦ Dominio: conjunto de caracteres de longitud máxima 50 caracteres.
◦ Tipo: atributo simple.
◦ Ejemplo: Informática y Análisis Numérico.
◦ Información adicional: Es de carácter no nulo.
CAPÍTULO 4. MODELO DE DATOS 19

4.1.3. Tipo de Entidad Estudiante

Descripción. El tipo de entidad Estudiante representa al objeto del mundo real
“Persona que estudia un grado en una universidad”.

Caracterı́sticas

• Nombre de la entidad: Estudiante.

• Atributo/s heredado/s: correo, password, nombre.
• Atributo/s identificador/es principal/es: correo.
• Atributo/s identificador/es alternativo/s: -
• Número de atributos: 6.

Atributos propios. El tipo de entidad Estudiante se compone de dos atributos,

los cuales se describen a continuación:

• grado
◦ Definición del atributo: representa el grado o carrera universitaria que es-
tudia un Estudiante.
◦ Dominio: conjunto de caracteres de longitud máxima 50 caracteres.
◦ Tipo: atributo simple.
◦ Ejemplo: Ingenierı́a Informática.
◦ Información adicional: Es de carácter no nulo.
• curso
◦ Definición del atributo: representa el año que está cursando un Estudiante
para un grado.
◦ Dominio: conjunto numérico de longitud máxima 1 caracter.
◦ Tipo: atributo simple.
◦ Ejemplo: 3
◦ Información adicional: Es de carácter no nulo.
• contratado
◦ Definición del atributo: representa si un Estudiante está contratado o no
para supervisar las Encuestas.
◦ Dominio: conjunto numérico de longitud máxima 1.
◦ Tipo: atributo simple.
◦ Ejemplo: 0.
◦ Información adicional: El valor de este atributo valdrá ‘1’ si es un Estu-
diante contratado y ‘0’ en otro caso.
20 4.1. ANÁLISIS DE ENTIDADES

4.1.4. Tipo de Entidad Estudiante no contratado

Descripción. El tipo de entidad Estudiante no contratado representa al objeto del
mundo real “Estudiante que asiste a un conjunto de asignaturas”.

Caracterı́sticas

• Nombre de la entidad: Estudiante no contratado.

• Atributo/s heredado/s: correo, password, nombre, grado, curso.
• Atributo/s identificador/es principal/es: correo.
• Atributo/s identificador/es alternativo/s: -
• Número de atributos: 0.

Atributos propios. No dispone de atributos propios.

4.1.5. Tipo de Entidad Estudiante contratado

Descripción. El tipo de entidad Estudiante contratado representa al objeto del
mundo real “Estudiante que está contratado para supervisar las encuestas”.

Caracterı́sticas

• Nombre de la entidad: Estudiante contratado.

• Atributo/s heredado/s: correo, password, nombre, grado, curso.
• Atributo/s identificador/es principal/es: correo.
• Atributo/s identificador/es alternativo/s: -
• Número de atributos: 0.

Atributos propios. No dispone de atributos propios.

4.1.6. Tipo de Entidad Asignatura

Descripción. El tipo de entidad Asignatura representa al objeto del mundo real
“Materia que es objeto de estudio en un grado universitario, impartida por un
profesor y a la que asisten los estudiantes en un lugar determinado”.

Caracterı́sticas

• Nombre de la entidad: Asignatura.

• Atributo/s heredado/s: -
• Atributo/s identificador/es principal/es: id asignatura.
• Atributo/s identificador/es alternativo/s: -
• Número de atributos: 4.

Atributos propios. El tipo de entidad Asignatura se compone de cuatro atributos,

los cuales se describen a continuación:
CAPÍTULO 4. MODELO DE DATOS 21

• id asignatura
◦ Definición del atributo: representa el número identificativo que se le asigna
a cada Asignatura dentro del sistema.
◦ Dominio: conjunto de número naturales de longitud máxima 6 cifras.
◦ Tipo: atributo simple.
◦ Ejemplo: 101412.
◦ Información adicional: es clave primaria o identificador principal del tipo
de entidad. Es de carácter obligatorio.
• nombre
◦ Definición del atributo: representa el nombre de una Asignatura.
◦ Dominio: conjunto de caracteres de longitud máxima 50.
◦ Tipo: atributo simple.
◦ Ejemplo: Arquitectura de Computadores.
◦ Información adicional: Es de carácter no nulo.
• grado
◦ Definición del atributo: Definición del atributo: representa el grado o ca-
rrera universitaria al que pertenece una Asignatura.
◦ Dominio: conjunto de caracteres de longitud máxima 50 caracteres.
◦ Tipo: atributo simple.
◦ Ejemplo: Medicina.
◦ Información adicional: Es de carácter no nulo.
• curso
◦ Definición del atributo: representa el año al que pertenece una Asignatura.
◦ Dominio: conjunto numérico de longitud máxima 1 caracter.
◦ Tipo: atributo simple.
◦ Ejemplo: 2
◦ Información adicional: Es de carácter no nulo.
22 4.1. ANÁLISIS DE ENTIDADES

4.1.7. Tipo de Entidad Lugar

Descripción. El tipo de entidad Lugar representa al objeto del mundo real “Espacio
fı́sico donde una asignatura es impartida por un profesor a un conjunto de alumnos”.

Caracterı́sticas

• Nombre de la entidad: Lugar.

• Atributo/s heredado/s: -
• Atributo/s identificador/es principal/es: id lugar.
• Atributo/s identificador/es alternativo/s: -
• Número de atributos: 4.

Atributos propios. El tipo de entidad Lugar se compone de cuatro atributos, los

cuales se describen a continuación:

• id lugar
◦ Definición del atributo: representa el número identificativo que se le asigna
a cada Lugar dentro del sistema.
◦ Dominio: conjunto de número naturales de longitud máxima 6 cifras.
◦ Tipo: atributo simple.
◦ Ejemplo: 000500.
◦ Información adicional: es clave primaria o identificador principal del tipo
de entidad. Es de carácter obligatorio.
• coordenadas
◦ Definición del atributo: representa las coordenadas geográficas (ubicación)
de un Lugar.
◦ Dominio: conjunto de números reales de longitud máxima 50.
◦ Tipo: atributo simple.
◦ Ejemplo: 37.915876, -4.725346.
◦ Información adicional: Es de carácter no nulo.
• aula
◦ Definición del atributo: representa el nombre del aula donde se imparte
una Asignatura.
◦ Dominio: conjunto de caracteres alfanuméricos de longitud máxima 10 ca-
racteres.
◦ Tipo: atributo simple.
◦ Ejemplo: INF3.
◦ Información adicional: Es de carácter no nulo.
• edificio
◦ Definición del atributo: representa el nombre del edificio donde se imparte
una Asignatura.
CAPÍTULO 4. MODELO DE DATOS 23

◦ Dominio: conjunto de caracteres de longitud máxima 50 caracteres.

◦ Tipo: atributo simple.
◦ Ejemplo: Ramón y Cajal
◦ Información adicional: Es de carácter no nulo.

4.1.8. Tipo de Entidad Asistencia

Descripción. El tipo de entidad Asistencia representa al objeto del mundo real
“Asistencia de una persona a una asignatura en un lugar determinado”.

Caracterı́sticas

• Nombre de la entidad: Asistencia.

• Atributo/s heredado/s: -
• Atributo/s identificador/es principal/es: -
• Atributo/s identificador/es alternativo/s: -
• Número de atributos: 1.

Atributos propios. El tipo de entidad Asistencia se compone de un atributo, el

cual se describe a continuación:

• fecha
◦ Definición del atributo: representa la fecha en la que se produjo una Asis-
tencia.
◦ Dominio: conjunto de caracteres con longitud máxima 10.
◦ Tipo: atributo simple.
◦ Ejemplo: 11/12/2017.
◦ Información adicional: Es de carácter obligatorio.

4.1.9. Tipo de Entidad Encuesta

Descripción. El tipo de entidad Encuesta representa al objeto del mundo real
“Cuestionario de calidad sobre la labor del profesorado que imparte una asignatura”.

Caracterı́sticas

• Nombre de la entidad: Encuesta.

• Atributo/s heredado/s: -
• Atributo/s identificador/es principal/es: -
• Atributo/s identificador/es alternativo/s: -
• Número de atributos: 1.

Atributos propios. El tipo de entidad Encuesta se compone de un atributo, el

cual se describe a continuación:
24 4.1. ANÁLISIS DE ENTIDADES

• habilitada
◦ Definición del atributo: representa si una Encuesta se encuentra habilitada
o no.
◦ Dominio: conjunto numérico con longitud máxima 1.
◦ Tipo: atributo simple.
◦ Ejemplo: 0.
◦ Información adicional: El valor de este atributo valdrá ‘1’ si la Encuesta
está habilitada y ‘0’ en otro caso. Es de carácter no nulo.

4.1.10. Tipo de Entidad Estadı́stica

Descripción. El tipo de entidad Estadı́stica representa al objeto del mundo real
“Inferencias y cálculos matemáticos para valorar distintos aspectos sobre una deter-
minada asignatura”.

Caracterı́sticas

• Nombre de la entidad: Estadı́stica.

• Atributo/s heredado/s: -
• Atributo/s identificador/es principal/es: id estadistica
• Atributo/s identificador/es alternativo/s: -
• Número de atributos: 6.

Atributos propios. El tipo de entidad Encuesta se compone de un atributo, el

cual se describe a continuación:

• id estadistica
◦ Definición del atributo: representa el número identificativo que se le asigna
a cada Estadı́stica dentro del sistema.
◦ Dominio: conjunto numérico con longitud máxima 6.
◦ Tipo: atributo simple.
◦ Ejemplo: 101398.
◦ Información adicional: es clave primaria o identificador principal del tipo
de entidad. Es de carácter obligatorio.
• est asistencia
◦ Definición del atributo: representa la asistencia a clase por parte de los
estudiantes.
◦ Dominio: conjunto numérico con longitud máxima 1.
◦ Tipo: atributo simple.
◦ Ejemplo: 4.
◦ Información adicional: El valor de este atributo podrá tomar valores com-
prendidos en el rango [1:5]. Es de carácter no nulo.
• est dificultad
CAPÍTULO 4. MODELO DE DATOS 25

◦ Definición del atributo: representa la dificultad que los estudiantes estiman

que cuesta aprobar una asignatura.
◦ Dominio: conjunto numérico con longitud máxima 1.
◦ Tipo: atributo simple.
◦ Ejemplo: 0.
◦ Información adicional: El valor de este atributo podrá tomar valores com-
prendidos en el rango [1:5]. Es de carácter no nulo.
• est tutorias
◦ Definición del atributo: representa el uso que los estudiantes hacen de las
tutorı́as que imparten los profesores de una asignatura.
◦ Dominio: conjunto numérico con longitud máxima 1.
◦ Tipo: atributo simple.
◦ Ejemplo: 0.
◦ Información adicional: El valor de este atributo podrá tomar valores com-
prendidos en el rango [1:5]. Es de carácter no nulo.
• est interes
◦ Definición del atributo: representa el interés que los estudiantes sienten
por una asignatura.
◦ Dominio: conjunto numérico con longitud máxima 1.
◦ Tipo: atributo simple.
◦ Ejemplo: 0.
◦ Información adicional: El valor de este atributo podrá tomar valores com-
prendidos en el rango [1:5]. Es de carácter no nulo.
• completa
◦ Definición del atributo: representa si una Encuesta ha sido completada o
no, para ser deshabilitada.
◦ Dominio: conjunto numérico con longitud máxima 1.
◦ Tipo: atributo simple.
◦ Ejemplo: 1.
◦ Información adicional: El valor de este atributo valdrá ‘1’ si la Encuesta
esté completada y ‘0’ en otro caso. Es de carácter no nulo.
26 4.2. DIAGRAMA ENTIDAD-RELACIÓN

4.2. Diagrama Entidad-Relación

Figura 4.1: Diagrama Entidad-Relación

CAPÍTULO 4. MODELO DE DATOS 27

4.3. Modelo Relacional

Figura 4.2: Modelo Relacional

Capı́tulo 5

Primer Sprint

5.1. Introducción
Como se comentó anteriormente, este proyecto está regido por la metodologı́a ágil
SCRUM, por lo que se abordará la especificación a más bajo nivel, el diseño y las pruebas
del product backlog expuesto en el capı́tulo 3 en dos incrementos.
Este primer incremento da comienzo el 1 de Noviembre de 2017 con la reunión de
planificación en la que se exponen las historias a abordar y la estimación del sprint y sus
tareas.
En esta reunión se toman como base las prioridades y necesidades de la aplicación, se
determinan cuáles y cómo van a ser las funcionalidades que se incorporarán al producto
en el siguiente sprint.
Los requisitos más prioritarios se han escogido en este sprint en función de su simpli-
cidad, para que el equipo sea capaz de manejar con fluidez la tecnologı́a a usar para los
siguientes sprints.

5.2. Estimación
Para este sprint, cada integrante del equipo se compromete a dedicar 1 hora al dı́a,
durante 5 dı́as a la semana sin contar las reuniones en horario lectivo, por lo que el sprint
dura un total de 50 horas realizadas durante dos semanas.
En este primer sprint ha sido necesario incluir una historia inicial para el diseño y
creación de la base de datos, además se han seleccionado las historias de ver horario aula,
firmar y habilitar encuesta.
La prioridad dentro del sprint se ha establecido del 1 al 5, siendo lo máximo 5 y lo
mı́nimo 1.

29
30 5.2. ESTIMACIÓN

5.2.1. Estimación de la historia Diseño y creación de la base de

datos

Tabla 5.1: Estimación de la historia Diseño y creación de la base de datos

ID Historia 0.1
Nombre Historia Diseño y creación de la base de datos
Prioridad 5
Estimación 15
Comprobar que se puede realizar la inserción,
Como se prueba actualización y borrado de cualquier tupla en cualquier
tabla.
0.1. Diseño de la base de datos.
Tareas
0.2. Creación e implementación de la base de datos.

5.2.2. Estimación de la historia Ver horario aula

Tabla 5.2: Estimación de la historia Ver horario aula

ID Historia 1.1
Nombre Historia Ver horario aula
Prioridad 2
Estimación 5
Pasar el Tag NFC por la etiqueta NFC del aula. Comprobar
que los horarios de ese aula son correctos. Comprobar
Como se prueba
que, si no hay asignaturas ese dı́a en ese aula, el horario
muestre un mensaje indicándolo.
1.1.1 Diseño de la interfaz.
1.1.2 Diseño de la interfaz (index y mensaje de error).
Tareas
1.1.3. Consultas a la base de datos.
1.1.4. Pruebas unitarias.
CAPÍTULO 5. PRIMER SPRINT 31

5.2.3. Estimación de la historia Firmar

Tabla 5.3: Estimación de la historia Firmar

ID Historia 5.1
Nombre Historia Firmar
Prioridad 3
Estimación 20
Pasar el Tag NFC por la etiqueta NFC del aula. Comprobar
que la persona esté en el lugar determinado por el aula.
Como se prueba
Comprobar que, si no pertenece a esa asignatura ó no se
encuentra en la localización muestre un error.
5.1.1 Diseño de la interfaz.
5.1.2. Consultas a la base de datos.
Tareas 5.1.3 Obtener API Key para geolocalización.
5.1.4. Implementar geolocalización.
5.1.5. Pruebas unitarias.

5.2.4. Estimación de la historia Habilitar encuesta

Tabla 5.4: Estimación de la historia Habilitar encuesta

ID Historia 3.1
Nombre Historia Habilitar Encuesta
Prioridad 1
Estimación 5
Pasar el Tag NFC por la etiqueta NFC de la encuesta.
Comprobar que la persona esté en el lugar determinado
por el aula donde se va a realizar la encuesta. Comprobar
Como se prueba
que, si eres estudiante ó estudiante contratado. Si es
estudiante contratado se redirige a el menú de la encuesta,
si eres estudiante se redirige a rellenar la encuesta.
3.1.1 Diseño de la interfaz.
Tareas 3.1.2. Consultas a la base de datos.
3.1.3. Pruebas unitarias.

5.3. Seguimiento del Sprint

Para realizar el seguimiento del sprint, los componentes del grupo se identificarán a
través de sus iniciales.
Las iniciales A.G.S se corresponden con Abraham Godoy Sánchez, B.I.A hacen refe-
rencia a Beatriz Illanes Alcaide, A.S.M define a Antonio Soto Montes, las iniciales F.F.M
hacen referencia a Fernando Fernández Martı́nez y M.P.P a Marı́a Elena Pedrajas Perabá.
32 5.3. SEGUIMIENTO DEL SPRINT

La siguiente tabla permite a los desarrolladores repartirse las tareas y conocer el estado
de cada una de ellas, posibilitando ası́ realizar tareas de forma paralela.
Esta tabla será actualizable por cualquier miembro del equipo, y se mantendrán reunio-
nes diarias donde cada uno expondrá lo que hizo el dı́a anterior y en lo que va a continuar
trabajando.
Además guardar esta información tiene como objetivo poder realizar mejores estima-
ciones en un futuro, conociendo la velocidad del equipo.

Tabla 5.5: Seguimiento de primer sprint

HISTORIA TAREA PENDIENTE TRABAJANDO HECHO

Fecha Encargado Fecha Encargado Fecha Encargado
0 01/11/ 01/11/ 08/11/
0.1.1 - A.G.S A.G.S
2017 2017 2017
01/11/ 08/11/ 10/11/
0.1.2 - A.S.M A.S.M
2017 2017 2017
Fecha Encargado Fecha Encargado Fecha Encargado
01/11/ 01/11/ 03/11/
1.1.1 - F.F.M F.F.M
1 2017 2017 2017
01/11/ 06/11/ 09/11/
1.1.2 - B.I.A B.I.A
2017 2017 2017
01/11/ 10/11/ 13/11/
1.1.3 - F.F.M F.F.M
2017 2017 2017
01/11/ 13/11/ 15/11/
1.1.4 - F.F.M F.F.M
2017 2017 2017
Fecha Encargado Fecha Encargado Fecha Encargado
01/11/ 01/11/ 03/11/
3 3.1.1 - B.I.A B.I.A
2017 2017 2017
01/11/ 10/11/ 13/11/
3.1.2 - B.I.A B.I.A
2017 2017 2017
01/11/ 13/11/ 15/11/
3.1.3 - B.I.A B.I.A
2017 2017 2017
Fecha Encargado Fecha Encargado Fecha Encargado
01/11/ 01/11/ 06/11/
5.1.1 - A.S.M A.S.M
2017 2017 2017
5
01/11/ 10/11/ 13/11/
5.1.2 - A.S.M A.S.M
2017 2017 2017
01/11/ 01/11/ 08/11/
5.1.3 - M.P.P M.P.P
2017 2017 2017
01/11/ 13/11/ 15/11/
5.1.4 - M.P.P M.P.P
2017 2017 2017
01/11/ 13/11/ 15/11/
5.1.5 - A.G.S A.G.S
2017 2017 2017
CAPÍTULO 5. PRIMER SPRINT 33

5.4. Burndown Chart

La siguiente representación gráfica permitirá al equipo observar de forma visual el
trabajo que queda por realizar en el sprint, ası́ como el progreso en función de la estimación
realizada en el tiempo para dicho sprint.
En este podemos observar como hasta el 3 de Noviembre de 2017, el equipo no tenı́a
ninguna tarea completada, por lo que el esfuerzo a realizar supera al ideal, pero finalmente,
conforme se van acabando las historias, este vuelve a su curso normal, terminando el sprint
en la fecha especificada.

Figura 5.1: Burndown Chart Primer Sprint

5.5. Estructura de ficheros resultante

Después de la realización del Primer Sprint completando las historias seleccionadas,
se han obtenido la siguiente estructura de ficheros que satisface el Sprint Backlog:
34 5.5. ESTRUCTURA DE FICHEROS RESULTANTE

5.5.1. Historia 0.1 - Diseño y creación de la Base de Datos

Figura 5.2: Estructura de la base de datos en PhpMyAdmin

5.5.2. Historia 1.1 - Ver Horario Aula

funciones.php

Contiene las consultas y subconsultas a la base de datos.

Llama a BD/ModeloBD.php para realizar la conexión a la base de datos.

menuHorarios.php

Contiene la interfaz donde se permite seleccionar el Aula del que se quiere ver
el horario.
Contiene las librerias de CSS y js contenidas en la carpeta bootstrap.

error.php

Contiene la interfaz que muestra un mensaje de error común.

Contiene las librerias de CSS y js contenidas en la carpeta bootstrap.

verHorarioClase.php

Contiene la interfaz donde se muestra el horario para un determinado Aula.

Contiene las librerias de CSS y js contenidas en la carpeta bootstrap.

index.php

Contiene la interfaz donde se muestra la página principal para la aplicación.

Contiene las librerias de CSS y js contenidas en la carpeta bootstrap.
CAPÍTULO 5. PRIMER SPRINT 35

5.5.3. Historia 5.1 - Firmar

funciones.php

Contiene las consultas y subconsultas a la base de datos.

Llama a BD/ModeloBD.php para realizar la conexión a la base de datos.

firmar.php

Contiene la interfaz para que un usuario pueda firmar la Asistencia a una

Asignatura.
Contiene llamadas al fichero ajax/firmarAjax.php para asignar el evento al
pulsar en el botón y enviarlo a la base de datos.
Contiene la libreria modulos/libreria.php para la geolocalización.
Contiene las librerias de CSS y js contenidas en la carpeta bootstrap.

menuAsistencia.php

Contiene la interfaz para que un usuario elija la Asignatura en la que quiere

firmar la Asistencia.
Contiene las librerias de CSS y js contenidas en la carpeta bootstrap.

5.5.4. Historia 3.1 - Habilitar Encuesta

funciones.php

Contiene las consultas y subconsultas a la base de datos.

Llama a BD/ModeloBD.php para realizar la conexión a la base de datos.

habilitarEncuesta.php

Contiene las interfaz que permite a un Estudiante Contratado habilitar una

Encuesta.
Contiene llamadas al fichero ajax/habilitarAjax.php para asignar el evento al
pulsar en el botón y enviarlo a la base de datos.
Llama a BD/ModeloBD.php para realizar la conexión a la base de datos.

5.6. Pruebas unitarias de las historias

En este apartado se exponen las pruebas realizadas para comprobar que la funciona-
lidad se ha realizado correctamente, y que se ha finalizado el desarrollo de las historias
escogidas para este incremento.
36 5.6. PRUEBAS UNITARIAS DE LAS HISTORIAS

5.6.1. Pruebas unitarias de la historia visualizar horario

En primer lugar se ha probado que al pasar el TAG NFC en el Aula INF3: Leonardo
Da Vinci [6] para comprobar que los horarios de ese aula se muestran correctamente para
ese dı́a lectivo.
En la Figura 5.1 se muestra la correcta visualización de los tramos horarios reservados
para distintas asignaturas. Podemos observar en las Figuras 5.3 y 5.4 que se muestran
correctamente las asignaturas que corresponden a ese dı́a (Miércoles) en la geolocalización
correspondiente a ese Aula.

(a) (b)

Figura 5.3: Pruebas unitarias de la historia visualizar horario

CAPÍTULO 5. PRIMER SPRINT 37

Figura 5.4: Comprobación de la prueba en la tabla Lugar

Figura 5.5: Comprobación de la historia visualizar horario en la tabla Lugar-Asignatura

5.6.2. Pruebas unitarias de la historia habilitar encuesta

Cuando se va a habilitar una encuesta, se accede desde el menú de la encuesta. Para
empezar se establece en el TAG NFC la asignatura que se va a evaluar, que en nuestro
caso hemos elegido ISM [7].
Posteriormente se muestra la correcta visualización de la encuesta que se va a realizar,
junto con el grado al que pertenece. Podemos observar en las Figura 5.6 el botón para
habilitarla y tras ello los siguientes mensajes de que el proceso ha ido bien y la encuesta
ha sido habilitada, más abajo se ilustra en la Figura 5.7 y Figura 5.8 En la figura 5.9.
se muestra reflejada la base de datos con la encuesta de la asignatura activada y en la
figura 5.10 la tabla con las asignaturas que se encuentran registradas con sus respectivos
id. Una vez que está la encuesta habilitada, aparece el menú del estudiante como se puede
observar en la figura 5.11.
38 5.6. PRUEBAS UNITARIAS DE LAS HISTORIAS

(a) Parte 1 (b) Parte 2

Figura 5.6: Prueba unitaria de la historia habilitar encuesta

5.6.3. Pruebas unitarias de la historia firmar

En la Figura 5.12. se muestra la visualización del control de asistencia para realizar la
firma una vez nos hemos logueado [8]. Podemos observar que se muestran correctamente
los campos del aula que corresponde la hora, ası́ como la asignatura y el grado, debiendo
“Firmar” en esa clase, en la geolocalización correspondiente a ese Aula. Se mostrarı́a un
mensaje después de realizar la firma como se indica en la Figura 5.13, ası́ como un mensaje
si se vuelve a realizar la firma en la misma hora indicando que ya ha firmado hoy.
CAPÍTULO 5. PRIMER SPRINT 39

Figura 5.7: Parte 3 de la prueba unitaria de la historia habilitar encuesta

Figura 5.8: Comprobación de la historia habilitar encuesta en la tabla

EstudianteContratado-Encuesta
40 5.6. PRUEBAS UNITARIAS DE LAS HISTORIAS

Figura 5.9: Comprobación de la historia habilitar encuesta en la tabla Asignatura

Figura 5.10: Visualización del menú tras la prueba unitaria de habilitar encuesta
CAPÍTULO 5. PRIMER SPRINT 41

Figura 5.11: Parte 1 de la prueba unitaria de la historia firmar

42 5.6. PRUEBAS UNITARIAS DE LAS HISTORIAS

Figura 5.12: Parte 2 de la prueba unitaria de la historia firmar

Figura 5.13: Parte 3 de la prueba unitaria de la historia firmar

Capı́tulo 6

Segundo Sprint

6.1. Introducción
En este segundo incremento se abordará la especificación a más bajo nivel, el diseño
y las pruebas del Product Backlog restante del primer incremento.
Este da comienzo el 16 de Noviembre de 2017, con la reunión de planificación en la
que se exponen las historias a abordar y la estimación del sprint y sus tareas.
En esta reunión se priorizan las historias restantes y necesidades de la aplicación,
determinando cuáles y cómo van a ser las funcionalidades que se incorporarán.

6.2. Estimación
Para este segundo sprint cada integrante del equipo se compromete a dedicar 1 hora
al dı́a, durante 5 dı́as a la semana sin contar las reuniones en horario lectivo, por lo que
el sprint dura un total de 75 horas realizadas durante tres semanas. En este sprint se ha
tenido en cuenta la medida en la que se cumplió la estimación del sprint anterior, guiando
este proceso de una forma más precisa.
La prioridad dentro del sprint se ha establecido del 1 al 5, siendo lo máximo 5 y lo
mı́nimo 1.
En cada estimación de las historias se ha incluido la información necesaria para apro-
ximar lo máximo posible el número de horas de su realización a la realidad.

6.2.1. Estimación de la historia Realizar encuesta

Para la historia Realizar encuesta se ha de tener en cuenta que se ha de seguir el
modelo de formulario creado por la Universidad de Córdoba [9].

43
44 6.2. ESTIMACIÓN

Figura 6.1: Encuesta de calidad docente de la Universidad de Córdoba

CAPÍTULO 6. SEGUNDO SPRINT 45

Tabla 6.1: Estimación de la historia Realizar encuesta

ID Historia 2.1
Nombre Historia Realizar Encuesta
Prioridad 5
Estimación 30
Pasar el Tag NFC por la etiqueta NFC de la encuesta.
Comprobar que la persona esté en el lugar determinado
Como se prueba por el aula donde se va a realizar la encuesta. Comprobar
que, el estudiante pertenece a la asignatura, sino muestra
un mensaje de error.
2.1.1 Diseño de la interfaz.
2.1.2. Consultas a la base de datos.
Tareas
2.1.3. Implementar geolocalización.
2.1.3. Pruebas unitarias.

6.2.2. Estimación de la historia Deshabilitar encuesta

Tabla 6.2: Estimación de la historia Deshabilitar encuesta

ID Historia 4.1
Nombre Historia Deshabilitar Encuesta
Prioridad 3
Estimación 10
Pasar el Tag NFC por la etiqueta NFC de la encuesta.
Comprobar que la persona esté en el lugar determinado
por el aula donde se va a realizar la encuesta. Comprobar
Como se prueba
que, si eres estudiante ó estudiante contratado. Si es
estudiante contratado es el responsable de finalizar y
deshabilitar la encuesta.
4.1.1 Diseño de la interfaz.
4.1.2 Diseño de la interfaz del menú del estudiante contratado.
Tareas 4.1.3. Consultas a la base de datos.
4.1.4. Implementar geolocalización.
4.1.5. Pruebas unitarias.
46 6.3. SEGUIMIENTO DEL SPRINT

6.2.3. Estimación de la historia Visualizar estadı́stica encuesta

Tabla 6.3: Estimación de la historia Visualizar estadı́stica encuesta

ID Historia 6.1
Nombre Historia Visualizar estadı́sticas encuesta
Prioridad 1
Estimación 20
Comprobar que una estadı́stica se ha realizado, si no es
ası́ te muestra un mensaje de error y si se ha realizado
Como se prueba
debe mostrar la media de las calificaciones que ha
obtenido esa encuesta.
6.1.1 Diseño de la interfaz.
Tareas 6.1.2. Consultas a la base de datos.
6.1.3. Pruebas unitarias.

6.2.4. Estimación de la historia Login

Tabla 6.4: Estimación de la historia Login

ID Historia 7.1
Nombre Historia Login
Prioridad 5
Estimación 15
Se comprueba que un usuario cualquiera se puede loguear
Como se prueba en el sistema, si no es ası́ sale un mensaje de error en rojo
indicando los campos que faltan.
7.1.1 Diseño de la interfaz.
Tareas 7.1.2 Consultas a la base de datos.
7.1.3. Pruebas unitarias.

6.3. Seguimiento del Sprint

Para realizar el seguimiento del sprint, los componentes del grupo se identificarán a
través de sus iniciales al igual que en el sprint anterior.
Las iniciales A.G.S se corresponden con Abraham Godoy Sánchez, B.I.A hacen refe-
rencia a Beatriz Illanes Alcaide, A.S.M define a Antonio Soto Montes, las iniciales F.F.M
hacen referencia a Fernando Fernández Martı́nez y M.P.P a Marı́a Elena Pedrajas Perabá.
La siguiente tabla permite a los desarrolladores repartirse las tareas y conocer el estado
de cada una de ellas, posibilitando ası́ realizar tareas de forma paralela.
Esta tabla será actualizable por cualquier miembro del equipo, y se mantendrán reunio-
nes diarias donde cada uno expondrá lo que hizo el dı́a anterior y en lo que va a continuar
trabajando.
CAPÍTULO 6. SEGUNDO SPRINT 47

Además guardar esta información tiene como objetivo poder realizar mejores estima-
ciones en un futuro, conociendo la velocidad del equipo.

Tabla 6.5: Seguimiento del segundo sprint

HISTORIA TAREA PENDIENTE TRABAJANDO HECHO

Fecha Encargado Fecha Encargado Fecha Encargado
20/11/ 20/11/ 01/12/
2.1.1 - A.G.S A.G.S
2 2017 2017 2017
20/11/ 01/12/ 06/12/
2.1.2 - F.F.M F.F.M
2017 2017 2017
20/11/ 01/12/ 06/12/
2.1.3 - A.G.S A.G.S
2017 2017 2017
20/11/ 06/12/ 11/12/
5.1.5 - B.I.A B.I.A
2017 2017 2017
Fecha Encargado Fecha Encargado Fecha Encargado
20/11/ 20/11/ 27/11/
4.1.1 - F.F.M F.F.M
2017 2017 2017
4
20/11/ 20/11/ 27/11/
4.1.2 - A.S.M A.S.M
2017 2017 2017
20/11/ 27/11/ 06/12/
4.1.3 - B.I.A B.I.A
2017 2017 2017
20/11/ 27/11/ 01/12/
4.1.4 - F.F.M F.F.M
2017 2017 2017
20/11/ 06/12/ 11/12/
4.1.5 - A.G.S A.G.S
2017 2017 2017
Fecha Encargado Fecha Encargado Fecha Encargado
20/11/ 20/11/ 07/12/
6 6.1.1 - M.P.P M.P.P
2017 2017 2017
20/11/ 07/12/ 08/12/
6.1.2 - F.F.M F.F.M
2017 2017 2017
20/11/ 08/12/ 11/12/
6.1.3 - A.S.M A.S.M
2017 2017 2017
Fecha Encargado Fecha Encargado Fecha Encargado
20/11/ 20/11/ 27/11/
7 7.1.1 - B.I.A B.I.A
2017 2017 2017
20/11/ 27/11/ 07/12/
7.1.2 - A.S.M A.S.M
2017 2017 2017
20/11/ 07/11/ 11/12/
7.1.3 - M.P.P M.P.P
2017 2017 2017
48 6.4. BURNDOWN CHART

6.4. Burndown Chart

La siguiente representación gráfica permitirá al equipo observar de forma visual el
trabajo que queda por realizar en el sprint, ası́ como el progreso en función de la estimación
realizada en el tiempo para dicho sprint.

Figura 6.2: Burndown Chart Segundo Sprint

6.5. Estructura de ficheros resultante

Después de la realización del Segundo Sprint completando las historias seleccionadas,
se han obtenido la siguiente estructura de ficheros que satisface el Sprint Backlog:

6.5.1. Historia 2.1 - Realizar Encuesta

funciones.php

Contiene las consultas y subconsultas a la base de datos.

Llama a BD/ModeloBD.php para realizar la conexión a la base de datos.

menuElegirEncuesta.php

Contiene la interfaz donde se permite seleccionar la Asignatura de la que se

quiere realizar la Encuesta.
Contiene las librerias de CSS y js contenidas en la carpeta bootstrap.
CAPÍTULO 6. SEGUNDO SPRINT 49

menuEncuesta.php
Contiene la interfaz donde se le permite al Estudiante Contratado seleccionar
si quiere habilitad o deshabilitar la Encuesta de una Asignatura.
Contiene las librerias de CSS y js contenidas en la carpeta bootstrap.
formularioEncuesta.php
Contiene la interfaz donde se muestra la información referente a una Encuesta
para una Asignatura.
Contiene llamadas al fichero ajax/formularioAjax.php para asignar el evento al
pulsar en el botón y enviarlo a la base de datos.
Contiene la libreria modulos/libreria.php para la geolocalización.
Contiene las librerias de CSS y js contenidas en la carpeta bootstrap.

6.5.2. Historia 4.1 - Deshabilitar Encuesta

funciones.php
Contiene las consultas y subconsultas a la base de datos.
Llama a BD/ModeloBD.php para realizar la conexión a la base de datos.
deshabilitarEncuesta.php
Contiene las interfaz que permite a un Estudiante Contratado habilitar una
Encuesta.
Contiene llamadas al fichero ajax/habilitarAjax.php para asignar el evento al
pulsar en el botón y enviarlo a la base de datos.
Llama a BD/ModeloBD.php para realizar la conexión a la base de datos.

6.5.3. Historia 6.1 - Visualizar Estadı́sticas Encuesta

funciones.php
Contiene las consultas y subconsultas a la base de datos.
Llama a BD/ModeloBD.php para realizar la conexión a la base de datos.
menuEstadisticas.php
Contiene la interfaz donde se permite seleccionar la Asignatura de la que se
quiere ver la Estadı́stica.
Contiene las librerias de CSS y js contenidas en la carpeta bootstrap.
verEstadisticas.php
Contiene la interfaz donde se muestra las estadı́sticas para una determinada
Asignatura.
Contiene las librerias de CSS y js contenidas en la carpeta bootstrap.
50 6.6. PRUEBAS UNITARIAS DE LAS HISTORIAS

6.5.4. Historia 7.1 - Login

funciones.php

Contiene las consultas y subconsultas a la base de datos.

Llama a BD/ModeloBD.php para realizar la conexión a la base de datos.

login.php

Contiene la interfaz donde se permite a un usuario loguearse en el sistema.

Contiene llamadas al fichero ajax/loginAjax.php para asignar el evento al pulsar
en el botón y enviarlo a la base de datos.
Contiene las librerias de CSS y js contenidas en la carpeta bootstrap.

logout.php

Contiene la interfaz donde se permite a un usuario desloguearse en el sistema.

Contiene las librerias de CSS y js contenidas en la carpeta bootstrap.

6.6. Pruebas unitarias de las historias

En este apartado se exponen las pruebas realizadas para comprobar que la funciona-
lidad se ha realizado correctamente, y que se ha finalizado el desarrollo de las historias
escogidas para este incremento.

6.6.1. Pruebas unitarias de la historia visualizar encuesta

En primer lugar, desde el index se selecciona la asignatura que se desee visualizar
desde el index [10].
CAPÍTULO 6. SEGUNDO SPRINT 51

Figura 6.3: Pruebas unitarias de escoger asignatura para visualizar sus estadı́sticas

Una vez pulsado “Ver Estadı́stica” nos muestra la visualización de las estadı́sticas de las
encuestas de la asignatura seleccionada previamente [11]. Indicando el grado, y varios
apartados de la encuesta solicitada a los estudiantes (nivel de asistencia, de uso de las
tutorı́as. . . , etc) como se puede observar en la Figura 6.4.

Figura 6.4: Pruebas unitarias de la historia ver estadı́sticas asignatura

52 6.6. PRUEBAS UNITARIAS DE LAS HISTORIAS

6.6.2. Pruebas unitarias de la historia realizar encuesta

Cuando se va a realizar una encuesta, para empezar se establece en el TAG NFC la
asignatura que se va a evaluar, que en nuestro caso hemos elegido Fı́sica Aplicada [12].
En la Figura 6.11. se muestra el primer paso que hay que realizar que es loguearse
para la correcta visualización de la encuesta, pudiendo ası́ rellenarla y evaluar al profesor.
Podemos observar en las Figuras 6.5, 6.6 y 6.7 que se muestran correctamente los campos
que debe rellenar el alumno para la calificación del docente correspondiente a ese dı́a
(Miércoles) en la geolocalización correspondiente a ese Aula.

Figura 6.5: Pruebas unitarias de la visualización de la información del estudiante al realizar

la encuesta

Figura 6.6: Pruebas unitarias de la visualización de la información de la asignatura

CAPÍTULO 6. SEGUNDO SPRINT 53

Figura 6.7: Pruebas unitarias de la visualización de la encuesta docente de un profesor

Sin embargo, si quisiéramos realizar de nuevo esta encuesta, nos mostrarı́a el siguiente
mensaje de error:

Figura 6.8: Pruebas unitarias del error para no realizar múltiples veces una encuesta
54 6.6. PRUEBAS UNITARIAS DE LAS HISTORIAS

6.6.3. Pruebas unitarias de la historia deshabilitar encuesta

Cuando se va a deshabilitar una encuesta, el alumno contratado pasar el Tag NFC
por la etiqueta de la encuesta deseada [13].
En la Figura 6.11. se muestra el primer paso que se realiza, es el logueo del estudiante
contratado.
Si la encuesta ya se está deshabilitada nos mostrarı́a como se puede observar en la
Figura 6.9 que ya se encuentra deshabilitada.

Figura 6.9: Pruebas unitarias del mensaje de error de la historia deshabilitar encuesta

Si la encuesta se encuentra habilitada y somos un estudiante contratado, si que nos

permitirá deshabilitarla.

Figura 6.10: Pruebas unitarias de la historia deshabilitar encuesta

CAPÍTULO 6. SEGUNDO SPRINT 55

6.6.4. Pruebas unitarias de login

En la Figura 6.11 se muestran los campos a rellenar usuario y contraseña. Para acceder
a la plataforma bastarı́a con introducir los datos de un usuario existente y pulsar en
“Entrar” [14].

Figura 6.11: Pruebas unitarias de la historia login

Si no rellenamos los campos podemos observar en la siguiente figura como es obligatorio

para proceder a realizar el login:

Figura 6.12: Pruebas unitarias del error de la historia login

Capı́tulo 7

Conclusiones

A pesar de las restricción de tiempo con la que contaba el proyecto y con la poca
experiencia del equipo, tanto en la tecnologı́a utilizada como en el desarrollo de proyec-
tos con metodologı́as ágiles, se ha conseguido abarcar los 3 objetivos principales que se
expusieron en la visión y ámbito del proyecto, cubriendo ası́ las necesidades y objetivos
de negocio primarias.
Esta funcionalidad se ve reflejadas en las matrices de trazabilidad, necesarias para el
mantenimiento y seguimiento del proyecto, ası́ como guı́a para determinar que finalmente
se ha implantado toda la funcionalidad necesaria.
Sin embargo, el proyecto podrı́a aportar más información a los usuarios, mejorando
ası́ su experiencia a la hora de usar el sistema. Las posibles mejoras de este se exponen
en el apartado 7.2.
A pesar de esto, el equipo ha adquirido la destreza de poder repartir tareas para
aumentar la productividad, siguiendo el modelo de elementos y reuniones que propone
SCRUM, responsabilizando a cada miembro de las tareas que se auto-asignaba y motivan-
do un espı́ritu de equipo para poder desarrollar el sistema cumpliendo con la estimación
realizada anteriormente.
Además, la elaboración tanto de este documento como del proyecto, ha permitido
a los miembros la comparación de su experiencia previa con metodologı́as tradicionales
que se habı́an aplicado en proyectos anteriores, ampliando ası́ los conocimientos de sus
componentes para aplicarlos en un futuro laboral.

7.1. Matrices de trazabilidad

Para el mantenimiento del proyecto es necesario saber los antecedentes de cada ele-
mento utilizado, para poder determinar ası́ sus motivos de desarrollo e implantación y el
camino que hemos de seguir ante posibles cambios.

57
58 7.1. MATRICES DE TRAZABILIDAD

En primer lugar se expone la matriz de trazabilidad de los casos de uso con los requi-
sitos funcionales.

Tabla 7.1: Matriz de trazabilidad requisitos funciones - casos de uso

Requisitos
funcionales
CU 1 CU 2 CU 3 CU 4 CU 5 CU 6 CU 7
/ Casos de
Uso
RF 3.1.1.1 X
RF 3.1.1.2 X
RF 3.1.2.1 X
RF 3.1.2.2 X
RF 3.1.2.3 X
RF 3.1.2.4 X
RF 3.1.3.1 X
RF 3.1.3.2 X
RF 3.1.4.1 X
RF 3.1.4.2 X
RF 3.1.5.1 X
RF 3.1.5.2 X
RF 3.1.5.3 X
RF 3.1.5.4 X
RF 3.1.6.1 X
RF 3.1.6.2 X
RF 3.1.7.1 X X X X X
RF3.1.7.2 X
CAPÍTULO 7. CONCLUSIONES 59

En segundo lugar, podemos observar la matriz de trazabilidad de las historias desa-

rrolladas en los distintos sprints con los requisitos funcionales que estas cubren.

Tabla 7.2: Matriz de trazabilidad requisitos funciones - historias

Requisitos
funcionales H 0 H1 H2 H3 H4 H5 H6 H7
/ Historias
RF 3.1.1.1 X X
RF 3.1.1.2 X
RF 3.1.2.1 X
RF 3.1.2.2 X X
RF 3.1.2.3 X X
RF 3.1.2.4 X
RF 3.1.3.1 X
RF 3.1.3.2 X X
RF 3.1.4.1 X
RF 3.1.4.2 X X
RF 3.1.5.1 X
RF 3.1.5.2 X
RF 3.1.5.3 X X
RF 3.1.5.4 X X
RF 3.1.6.1 X
RF 3.1.6.2 X
RF 3.1.7.1 X X X X X X
RF 3.1.7.2 X

7.2. Futuras mejoras

Debido a las restricciones de tiempo del proyecto, no se ha podido incluir funcionalidad
de baja prioridad que mejore la experiencia del usuario en el sistema.
Algunas de las funcionalidades que se podrı́an incluir en futuros sprints:

Mostrar la información de una asignatura y sus profesores al seleccionarla en el

horario de un aula.

Permitir a los profesores ver las estadı́sticas de asistencia de los alumnos a las
asignaturas que imparten.

Generar estadı́sticas de asistencia.

Generar eventos cuando finalicen las estadı́sticas, como mensajes a los correspon-
dientes responsables.

Crear buscadores y/o filtros para facilitar las búsquedas de los usuarios.
60 7.2. FUTURAS MEJORAS

Además, serı́a necesario una integración más precisa de todos los componentes del
sistema y sus interfaces, incluyendo mensajes de error personalizados en función de los
eventos y mejorar la navegabilidad de la interfaz para que el usuario pueda visitar el
sistema de una forma sencilla.
Bibliografı́a

[1] Wikipedia, UML2. https://es.wikipedia.org/wiki/Lenguaje_unificado_de_

modelado/ [Último acceso: 9 Diciembre 2017].

[2] Proyectos Ágiles, SCRUM. https://proyectosagiles.org/que-es-scrum/ [Últi-

mo acceso: 9 Diciembre 2017].

[3] Web host App. https://es.000webhost.com/ [Último acceso: 9 Diciembre 2017].

[4] Web host App, Caracterı́sticas. https://es.000webhost.com/caracteristicas

[Último acceso: 14 Diciembre 2017].

[5] Portal Web Agencia Española de Protección de Datos. http://www.agpd.

es/portalwebAGPD/canaldocumentacion/legislacion/estatal/index-ides-
idphp.php [Último acceso: 9 Diciembre 2017].

[6] UCO TOOLS, Ver Horario Aula INF3. https://elenapedrajas96.

000webhostapp.com/nfc/verHorarioClase.php?idLugar=1 [Último acceso:
15 Diciembre 2017].

[7] UCO TOOLS, Habilitar Encuesta. https://elenapedrajas96.000webhostapp.

com/nfc/habilitarEncuesta.php?idEncuesta=2 [Último acceso: 15 Diciembre
2017].

[8] UCO TOOLS, Firmar asistencia. https://elenapedrajas96.000webhostapp.com/

nfc/firmar.php?idLugar=1 [Último acceso: 15 Diciembre 2017].

[9] Universidad de Córdoba, Encuestas de Calidad Docente. http://www.uco.

es/organizacion/calidad/actividades_propias/eval_prof/pdf/alumno_
encuesta.pdf [Último acceso: 10 Diciembre 2017].

[10] UCO TOOLS, Index. https://elenapedrajas96.000webhostapp.com/nfc/

index.php [Último acceso: 15 Diciembre 2017].

[11] UCO TOOLS, Ver estadı́sticas encuesta. https://elenapedrajas96.

000webhostapp.com/nfc/verEstadisticas.php?idEncuesta=2 [Último acce-
so: 15 Diciembre 2017].

[12] UCO TOOLS, Formulario Encuesta. https://elenapedrajas96.000webhostapp.

com/nfc/formularioEncuesta.php?idEncuesta=3 [Último acceso: 15 Diciembre
2017].

61
62 BIBLIOGRAFÍA

[13] Uco tools, deshabilitar encuesta. https://elenapedrajas96.000webhostapp.

com/nfc/deshabilitarEncuesta.php?idEncuesta=2 [Último acceso: 15 Diciembre
2017].

[14] Uco tools, login. https://elenapedrajas96.000webhostapp.com/nfc/login.php

[Último acceso: 15 Diciembre 2017].