Gestión de la logística de exámenes en la Universidad

Universidad Complutense de Madrid Trabajo de fin de grado del Grado en Ingenier ´ ıa del Software. Facultad de inform´ atica Gesti´on de la log´ıstica de ex´amenes en la Universidad Autores: Ignacio Domingo Mart ´ ın Julia Fern´ andez Reyes ´ Agata S´ anchez Andreu Director: Simon Pickin Curso 2018/2019 Resumen El presente Trabajo de Fin de Grado ha sido realizado por tres alumnos especializados en el Grado de Ingenier´ıa del Software y tiene como fin modernizar el proceso educativo mediante una mejora de la gesti´on de la log´ıstica de ex´amenes. Este proyecto se fundamenta en el estudio de necesidades y la implementaci´on de una tecnolog´ıa que facilite la organizaci´on y distribuci´on de las aulas y los alumnos para la realizaci´on de los ex´amenes. La soluci´on propuesta consiste en una aplicaci´on web que ofrece a la administraci´on la capacidad de gestionar aulas, fechas de ex´amenes y los respectivos modelos de examen de cada asignatura dentro de un solo sistema. Llegado el momento del examen, el proceso se llevar´ıa a cabo mediante el env´ıo a la aplicaci´on de las lecturas de las tarjetas de estudiantes, de tal modo que la aplicaci´on imprimiese y situase a los alumnos con el uso de un algoritmo de distribuci´on aleatoria dentro del aula de tal modo que se reducir´ıa la p´erdida de tiempo en la organizaci´on de las aulas en el momento del examen y evita posibles situaciones irregulares de copia. Para realizar el cometido y hacerlo posible, se han tenido en cuenta las distintas restricciones y riesgos con los que contar´ıa la aplicaci´on dentro de su potencial entorno de instalaci´on. Palabras clave: Gesti´on, Log´ıstica, Ex´amenes, Universidad, Software, Aplicaci´on Web, Arquitectura por capas, Node.js Abstract The main objective of the present end-of-degree project is to modernize the educational process by the study and development of a web application that pursues the facilitation of the examination logistics management. This project is based on the study of needs and the consequential implementation of a technology that facilitates the organization and distribution of classrooms and students for the realization of exams. The proposed solution consists of a web application that provides the administration with the possibility to manage classrooms, exam dates and the respective examination models of each subject within a single application. In the course of examinations, the process would be carried out by sending to the application the student card readings, in such a way that the application will print and place the students by means of a random distribution algorithm within the classroom, reducing the loss of time in the organization of the classrooms at the time of the examination and avoiding possible irregular situations of cheating. To carry out this task and make it possible, the different restrictions and risks with which the application would count within its potential installation environment have been taken into consideration. Keywords: Logistics, Management, Examinations, University, Software, Web Application, Multitier Architecture, Node.js 2 ´ INDICE ´ Indice 1 Introducci´on 8 1.1 Perspectiva hist´orica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2 Situaci´onactual............................... 8 1.3 Motivaci´on y alcance del proyecto . . . . . . . . . . . . . . . . . . . . . 9 1.4 Estructura del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2 Introduction 11 2.1 Historical perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Currentsituation .............................. 11 2.3 Project scope and motivation . . . . . . . . . . . . . . . . . . . . . . . 12 2.4 Projectstructure .............................. 12 3 Antecedentes y plan de trabajo 13 3.1 Introducci´on................................. 13 3.2 Gesti´on de los ex´amenes en la UNED . . . . . . . . . . . . . . . . . . . 14 3.3 Gesti´on de los ex´amenes en pa´ıses de nuestro entorno . . . . . . . . . . 15 3.4 Plandetrabajo............................... 17 4 An´alisis y especificaci´on de requisitos 19 4.1 Enumeraci´on ................................ 19 4.2 Procesos................................... 24 4.3 Modelodedominio ............................. 32 4.3.1 Restricciones ............................ 34 4.4 Tipos de actores o usuarios . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.5 Casosdeuso................................. 36 4 ´ INDICE 4.5.1 Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . . . 38 5 Verificaci´on y validaci´on 52 5.1 Unidad-Integraci´on-Sistema . . . . . . . . . . . . . . . . . . . . . . . . 52 5.2 Caja negra-Caja blanca . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6 Elecci´on de las tecnolog´ıas 54 6.1 Lenguajes de programaci´on . . . . . . . . . . . . . . . . . . . . . . . . 54 6.2 Requisitos exteriores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 7 Estudio del riesgo 55 7.1 Qu´e es el riesgo y tipos de riesgo . . . . . . . . . . . . . . . . . . . . . 55 7.2 Estrategias de la gesti´on del riesgo . . . . . . . . . . . . . . . . . . . . 56 7.3 Elecci´on de estrategia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.4 Identificaci´on de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7.5 An´alisisderiesgos.............................. 58 7.6 Priorizaci´on del riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 7.7 T´ecnicas de Reducci´on, Supervisi´on y Gesti´on del Riesgo . . . . . . . . 60 8 El sistema 61 8.1 Introducci´on................................. 61 8.2 Modelodelsistema ............................. 62 8.3 Vistasdelsistema.............................. 64 8.4 Funcionamiento del sistema . . . . . . . . . . . . . . . . . . . . . . . . 67 8.4.1 Basededatos............................ 67 8.4.2 Algoritmo de asignaci´on aleatoria . . . . . . . . . . . . . . . . . 69 9 Trabajo individual 70 5 ´ INDICE 9.1 Ignacio.................................... 70 9.2 Julia..................................... 72 9.3 ´ Agata .................................... 73 10 Resultado y conocimientos adquiridos 76 11 Conclusi´on y l´ıneas futuras 79 12 Conclusion and future development 80 Referencias 85 6 Repositorio p´ublico El c´odigo de la aplicaci´on web que se ha desarrollado a ra´ız de esta memoria puede encontrarse en el siguiente repositorio p´ublico: https://github.com/nachodm/TFG 7 1 INTRODUCCI´ ON 1 Introducci´on 1.1 Perspectiva hist´orica Desde el espectacular incremento en el n´umero de universidades a lo largo de Europa durante la ´epoca medieval, los m´etodos de estudio y evaluaci´on de los alumnos en las mismas han ido evolucionando a lo largo del tiempo. A comienzos de la Edad Media, el m´etodo de evaluaci´on m´as com´un era los conocidos como disputatio[1], que consist´ıan en la discusi´on oral de diversas materias destacando sus posibles aspectos a favor y en contra, con el objetivo de discernir lo que pudiera ser v´alido o verdadero y lo que no. Esta metodolog´ıa ir´ıa evolucionando con el paso del tiempo hasta convertirse en ex´amenes orales, y no ser´ıa hasta el siglo XVIII cuando las universidades europeas adoptar´ıan los ex´amenes estandarizados escritos que en China se llevaban utilizando desde tiempos de la dinast´ıa Sui (Siglo VI)[2]. Esta estandarizaci´on de los ex´amenes fue decisiva en el proceso de modernizaci´on de m´etodos de evaluaci´on y ense˜nanza en el que estaban inmersos la mayor´ıa de pa´ıses europeos, ya que consisti´o en el primer m´etodo equitativo y racional para la evaluaci´on de los estudiantes, as´ı como servir como el primer m´etodo de acceso reglamentario a este tipo de estudios1. Sin embargo, durante estos ´ultimos siglos la gesti´on log´ıstica de dichos ex´amenes en las universidades espa˜nolas apenas ha evolucionado; a pesar de estar ya inmersos en plena era digital, no se hace uso de las tecnolog´ıas a nuestro alcance, y la gesti´on de los ex´amenes sigue siendo en ocasiones sumamente ineficiente y sin estar ni mucho menos automatizada. 1.2 Situaci´on actual Se podr´ıa decir que la gesti´on actual de la log´ıstica de ex´amenes en la Universidad Complutense de Madrid y m´as concretamente en la Facultad de Inform´atica cuenta con un amplio margen de mejora. La no automatizaci´on de dicha log´ıstica resulta en la mayor´ıa de las ocasiones en un trabajo extra a realizar por el personal docente de la Universidad que se podr´ıa facilitar en muchos aspectos si se adaptase el proceso al entorno IT que actualmente nos rodea. Actualmente, el sistema se gu´ıa por las siguientes etapas: la publicaci´on del calendario de ex´amenes se lleva a cabo al comienzo del a˜no acad´emico, en el apartado Ex´amenes por curso y grupo de la secci´on de Estudiantes de la p´agina web de la Facultad. Esta asignaci´on de espacios se hace, en el caso de ex´amenes de teor´ıa, sobre el n´umero total de matriculados en la asignatura, y para los ex´amenes del laboratorio, teniendo en 1Hasta entonces, los alumnos ingresaban en las Universidades por medio de recomendaciones o impresionando a ciertos profesores con su conocimiento en diversas materias 8 3 ANTECEDENTES Y PLAN DE TRABAJO referente al calendario de ex´amenes. Adem´as, antes de iniciar la sesi´on, se realiza el descifrado de ex´amenes a trav´es de la tarjeta universitaria del integrante del tribunal. A la entrada al examen, la aplicaci´on permite asistir solo a los alumnos que tienen esa asignatura matriculada y que coincida con la hora y aula del examen. Un lector identifica el DNI o tarjeta del estudiante y una impresora imprime su examen. En la cabecera del examen, viene dado el puesto que debe ocupar cada estudiante y los materiales que puede usar para realizar la prueba. Para evitar colapsos, un sistema simula un sem´aforo, indicando cuando puede pasar el siguiente alumno. Durante la sesi´on, se realiza la identificaci´on de la persona que ocupa cada puesto, adem´as de controlar el tiempo que dispone cada estudiante con un sistema de avisos. Tambi´en se consultan las relaciones de ex´amenes pendientes de entrega de cada asignatura y se obtiene la lista de los estudiantes que se han presentado. Por ´ultimo, en la entrega de las pruebas, se necesita seleccionar la sesi´on del examen que est´a en curso. Mediante el escaneado de los ex´amenes, se registra la entrega y se env´ıa una copia cifrada a la Sede Central. 3.3 Gesti´on de los ex´amenes en pa´ıses de nuestro entorno Durante el estudio de la informaci´on disponible sobre la log´ıstica de ex´amenes en distintas Universidades, nos encontramos con que un gran n´umero de ellas que no hab´ıan publicado ning´un tipo de informaci´on al respecto; dentro de las que presentaban documentaci´on relativa al caso, las m´as completas para llevar a cabo la investigaci´on resultaron ser las siguientes: •Technical University of Denmark (Dinamarca) •University of Oulu (Finlandia) •University of Helsinki (Finlandia) •M¨almo University (Suecia) •Tallinn University (Estonia) •University of Bergen (Noruega) Todas las universidades estudiadas disponen de un plazo donde se exige al alumno realizar una preinscripci´on al examen que quiera realizar, “x” d´ıas antes del mismo. Si el alumno no se apunta a dicho examen dentro del horario establecido, ´este no puede presentarse y pierde la oportunidad, por lo que se le sancionar´ıa de una manera u otra. Por ejemplo, en la Universidad de Tallin [6], el alumno se marca como “ausente” en el examen. En el caso de la Universidad de Bergen [7], no correr´ıa convocatoria ni se sancionar´ıa al alumno, por lo que, registrarse en el examen no afectar´ıa. El registro para el examen tambi´en se puede cancelar en un plazo de tiempo concreto. En el caso 15 3 ANTECEDENTES Y PLAN DE TRABAJO de las Universidades en las que nos hemos centrado en la investigaci´on, la que tiene un plazo m´as amplio para registrarse/cancelar el registro en un examen es la Universidad de Tallin [6], donde se puede realizar la cancelaci´on hasta un d´ıa antes del examen. Al contrario que en la Universidad de Helsinki [8], donde el plazo m´aximo es hasta 10 d´ıas antes del examen. Por ´ultimo, si un alumno se registra para un examen y no se presenta, en la Universdidad de Tallin [6], ´este suspende la asignatura, sin derecho a realizar la recuperaci´on. En el resto de universidades citadas no se encuentra informaci´on para dicha situaci´on. Al igual que en estas universidades, nuestro objetivo es tambi´en incluir un m´etodo similar en nuestro proyecto. Esto contribuir´ıa a distribuir m´as eficientemente las aulas de examen con los alumnos que se han registrado para realizarlo. En cualquier caso, estudiaremos realizar las pruebas con previo registro y sin ´el. Teniendo estos datos, podr´ıamos juntar varios grupos con distintas asignaturas en una misma clase para realizar un examen. Adem´as, facilitar´ıa la asignaci´on de los puestos de cada alumno en el aula dado que sabemos el n´umero de personas que se presentar´ıan al examen de cada asignatura, por lo que ser´a necesario disponer de la tarjeta de la UCM e identificarse al entrar al aula del examen. Tras la identificaci´on, el alumno podr´a sentarse para realizar la prueba; si un alumno se registra para el examen y no se presenta, perder´ıa una convocatoria para el examen, mientras que si el alumno no se registra para el examen, no puede presentarse, por lo que ir´ıa directamente a recuperaci´on. Esto har´ıa que los alumnos solo se registraran si se fueran a presentar. No obstante, siempre habr´ıa excepciones por falta debido a enfermedad, etc que puedan ser justificadas. En estas universidades, los alumnos tambi´en tienen la obligaci´on de identificarse. En la Universidad de Malm¨o [9] es necesario presentar la documentaci´on para ingresar en el examen, mientras que en el resto de Universidades solo es necesario identificarse al final. Tambi´en nos hemos informado de que algunas de estas universidades, realiza los ex´amenes en aulas con una gran capacidad de puestos. Por lo que realizan el examen muchos alumnos a la vez, como es la Universidad de Dinamarca [10]. Esto tambi´en podr´ıa ser una ventaja para nosotros, puesto que, si podemos juntar varios grupos en un aula, los ex´amenes se realizar´ıan de una forma m´as r´apida y el periodo de ex´amenes se podr´ıa acortar. Tambi´en se podr´ıa prescindir de algunos profesores de guardia de examen en las aulas. En estas universidades, los ex´amenes suelen realizarse en aulas, en el caso de la Universidad de Oulu [11], los asientos est´an asignados antes de iniciar el examen. Los laboratorios solo se usan en casos puntuales. Dado que en la Universidad Complutense de Madrid muchos ex´amenes son realizados en laboratorios, esto nos ayudar´ıa mucho para distribuir a los alumnos, ya que, en muchas ocasiones se quedan laboratorios vac´ıos y hay que redistribuir a los alumnos de una misma clase para juntarlos a todos en el mismo laboratorio y este es el problema principal que evitar´ıamos. 16 3 ANTECEDENTES Y PLAN DE TRABAJO 3.4 Plan de trabajo En cuanto al plan de trabajo realizado, hay que mencionar que la organizaci´on del trabajo ser´a en todo momento un proceso iterativo, en el que nos permitir´a arreglar fallos o modificar implementaciones que podr´ıan estar mal. No obstante, se ha generado un Diagrama de Gantt [12] con las tareas que se van a ejercer y con el tiempo estimado que se va a tardar en hacer cada tarea. Hemos fragmentado el trabajo en dos partes: documentaci´on e implementaci´on. Tras esto, hemos indicado las tareas y subtareas correspondientes, as´ı como la realizaci´on, las revisiones y las correcciones que podr´ıan surgir. A continuaci´on, se muestra dicho diagrama, en el que se puede observar las distintas tareas, qui´en las ha realizado, las horas estimadas que se va a tardar en realizar cada tarea, el d´ıa de comienzo y fin estimado y por ´ultimo, el porcentaje que se va realizando hasta que se finaliza. En la figura, adem´as, se puede ver que hay tareas en verde, que estar´ıan finalizadas, en rojas, que van en retraso en funci´on de las horas estimadas; y en azul, que son las que a´un faltan por realizar y est´an a tiempo. 17 3 ANTECEDENTES Y PLAN DE TRABAJO Figura 1: Diagrama de Gantt 18 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS 4 An´alisis y especificaci´on de requisitos 4.1 Enumeraci´on En primer lugar, cabe diferenciar los dos modos que podr´a tener el proyecto: modelo din´amico y modelo est´atico, diferenciados ´unicamente por la posibilidad de una preinscripci´on al examen. Es decir, en el modelo din´amico no es necesario que los alumnos se preinscriban con antelaci´on puesto que se les asignar´a el puesto correspondiente al llegar al establecimiento. Esto producir´ıa problemas de optimizaci´on, que se podr´an abordar con distintos algoritmos, intentando que la optimizaci´on de los puestos sea la mejor posible y cumpliendo una serie de restricciones. Uno de estos algoritmos podr´ıa ser el algoritmo del Simplex [13], cuyo objetivo principal ser´ıa maximizar los puestos en un aula. Otro tipo de optimizaci´on es la heur´ıstica, la cual se basa en minimizar o maximizar cierta funci´on que contiene muchas variables a estudiar. No obstante, se pueden hacer estimaciones sobre el n´umero de alumnos que van a presentarse mediante los profesores. Esto ocurre cuando alguna asignatura tiene requisitos imprescindibles para poder presentarse a un examen. Por ejemplo, la falta de alguna entrega pr´actica o la falta de asistencia a clase en un porcentaje m´ınimo. En cuanto al modelo est´atico, ser´a necesario que los alumnos se preinscriban. Para ello ser´a necesario una plataforma para los alumnos que tenga los d´ıas de los ex´amenes y las asignaturas que tienen estos para poder presentarse. En el caso de que no haya restricciones en alguna asignatura para poder presentarse al examen, el n´umero de alumnos a presentar ser´a el total de la clase. No obstante, en ambos modelos habr´a alguna estimaci´on para poder especificar el n´umero de puestos por clase que puede tener un examen. Todo esto implica que los requisitos se deban adaptar seg´un la elecci´on del modelo a realizar, siendo de esta forma necesarios o no algunos requisitos espec´ıficos. Sin embargo, antes de distinguir los requisitos del proyecto hay que mencionar los distintos niveles de complejidad que se pueden desarrollar en la aplicaci´on, ya que por tiempo no va a ser posible realizarlos todos. No obstante, indicamos dichos niveles con su posible implementaci´on: •Grado de complejidad 1: Modelo est´atico. En este nivel se implementar´a la funcionalidad m´as simple, de modo que solo exista la posibilidad de realizar en un aula un ´unico examen de la asignatura, con un solo modelo, pero con la posibilidad de que efect´uen el examen varios grupos. •Grado de complejidad 2: Modelo est´atico. Este grado de complejidad abarca el primero, a˜nadiendo la posibilidad de poder realizar varios modelos de examen de una misma asignatura. De modo que se podr´a ubicar a los alumnos para que a su alrededor no tengan un compa˜nero con el mismo examen. •Grado de complejidad 3: Modelo est´atico. El tercer nivel contempla la 19 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS posibilidad de que en un aula se puedan ubicar dos o m´as grupos de asignaturas diferentes, pero con un solo modelo de examen en cada asignatura. •Grado de complejidad 4: Modelo est´atico. Este grado comprende el tercer nivel en su totalidad con la adici´on de m´as modelos de examen en cada grupo y asignaturas distintas. •Grado de complejidad 5: Modelo din´amico. En este nivel la implementaci´on ya experimenta una dificultad mayor, pues al ser din´amico, el algoritmo va incrementando m´as problemas al ubicar a los alumnos en el aula. As´ı mismo, se podr´ıa tener un examen ubicado en una aula y con uno o varios grupos de la misma asignatura. •Grado de complejidad 6: Modelo din´amico. En este grado de complejidad, la aplicaci´on permite ubicar a los alumnos de distintos grupos en un mismo aula con m´as modelos de examen, pero de la misma asignatura. •Grado de complejidad 7: Modelo din´amico. El pen´ultimo nivel consiste en tener en un mismo aula dos ex´amenes de distintas asignaturas, pero con un modelo de examen por asignatura. •Grado de complejidad 8: Modelo din´amico. Este ´ultimo grado de complejidad se corresponde con la idea de tener en un mismo aula alumnos que realizan distintos ex´amenes de distintas asignaturas, con distintos grupos y distintos modelos de examen por cada asignatura. A continuaci´on, veremos los distintos requisitos del proyecto seg´un el modo que se quiera implementar. Estos se dividir´an en: sistema, usuario, entorno y ex´amenes. No obstante, habr´a requisitos comunes para ambos modelos. El proyecto necesitar´a tener un sistema que organice los ex´amenes en la facultad, as´ı como las aulas/laboratorios donde se realizar´an y los puestos de cada alumno seg´un la asignatura y disponibilidad del aula. Por ello, los requisitos del entorno ser´an los siguientes: 1. Se podr´a realizar varios ex´amenes de distintas asignaturas en una misma ubicaci´on sin dejar huecos innecesarios, ya sea en el aula o en el laboratorio. 2. Juntar los alumnos de un aula con los de otra aula, una vez se viera que el n´umero de presentados lo permita. Lo mismo ocurre con los laboratorios. 3. La ubicaci´on de los alumnos en los puestos se har´a con el objetivo de satisfacer ciertos criterios. Por ejemplo, en el caso de programar distintos ex´amenes (o distintos modelos del mismo examen) en el mismo aula, el algoritmo de asignaci´on de puestos intentar´a asegurar que alumnos en puestos contiguos no tengan el mismo examen (o no tienen el mismo modelo del examen), sobre todo en el modelo din´amico, ya que en el est´atico se podr´a predefinir previamente. Con esto se podr´a garantizar el primer requisito. 20 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS Dado que los requisitos dependen tambi´en de la ubicaci´on de los ex´amenes, como se describe en el punto 6.2, hay que distinguir ambos casos. En cualquier caso, los requisitos comunes son los siguientes: 1. Necesidad de un lector de tarjetas en aulas y laboratorios. 2. La aplicaci´on tiene que tener acceso al sistema de la facultad para poder acceder a la informaci´on de los alumnos y las asignaturas de la facultad. 3. Disponer de impresoras r´apidas suficientes en aulas y laboratorios, y disponer de esc´aneres r´apidos en aulas. 4. Imprimir el examen de cada alumno, junto con las normas del examen. 5. El sistema deber´a permitir enviar un aviso al m´ovil, o en su defecto mediante la aplicaci´on, del profesor responsable del grupo de la asignatura si un alumno tiene alguna pregunta sobre el examen. Esto ocurre porque hay profesores de guardia en el examen que no imparten la parte te´orica o que, incluso, no imparten la asignatura de este. 6. La interfaz del sistema deber´a tener una representaci´on espacial del aula o laboratorio con una imagen del alumno, su nombre completo y la asignatura del examen que realizar´a. 7. La interfaz deber´a tener un apartado de “Notas” para que un profesor de guardia pueda indicar si ha habido alguna incidencia con alg´un alumno o para describir las dudas que pueda tener durante el examen, siempre y cuando est´e permitido hacer preguntas. De esta manera, quedar´a reflejado para que el profesor responsable que corrija dicho examen pueda tomar ciertas medidas o no. En cuanto a los requisitos espec´ıficos del sistema en los laboratorios, tenemos que: 1. El sistema deber´a poder interactuar con las aplicaciones correspondientes de entrega de ex´amenes que posee la Facultad de Inform´atica para permitir proporcionar ficheros a los alumnos al principio del examen y para permitir la entrega de ficheros al finalizar el examen. 2. El examen tiene un tiempo programado y se cerrar´a despu´es de este, pero el profesor de guardia tiene la posibilidad de posponer la entrega. No obstante, tendr´a que autenticarse al salir del laboratorio. Por otro lado, los requisitos espec´ıficos del sistema en las aulas ser´an los siguientes: 21 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS 1. La interfaz del sistema permitir´a al profesor de guardia indicar si el alumno ha decidido entregar o no el examen, aunque haya realizado los ejercicios. Esto es debido a que un alumno puede decidir si lo presenta para que se lo corrija el profesor responsable o, si por el contrario, no quiere gastar una convocatoria. Todo esto siempre y cuando est´e permitido “no entregar el examen”. 2. Al salir de un examen, el alumno tendr´a que autenticarse para indicar que se ha presentado y a qu´e hora ha salido del examen. Esto remplazar´ıa las firmas que piden algunos profesores en los ex´amenes, sobre todo en los que se realizan en los laboratorios. Los requisitos del usuario ser´an imprescindibles para que el sistema funcione correctamente. Por ello los requisitos son: 1. Los usuarios tendr´an que estar dados de alta en la base de datos del sistema, mediante su carn´e universitario. En el caso de que un alumno no tenga la tarjeta, el profesor de la asignatura decidir´a si se puede presentar ense˜nando su DNI. Si se da el consentimiento, el profesor a˜nadir´a a trav´es de la vista a dicho alumno e imprimir´a el examen desde un bot´on de la interfaz. 2. Necesidad de tener un carn´e universitario. En el caso de los alumnos Erasmus, se les proporcionar´a ese carn´e al igual que el resto. 3. El d´ıa del examen el alumno deber´a autenticarse, por medio del carn´e, en el aula correspondiente. De esta manera se le podr´a asignar su puesto. 4. En el caso del modelo est´atico, el alumno tendr´a que preinscribirse al examen antes del d´ıa en que se realice. 5. El alumno tendr´a que pasar la tarjeta al entrar en el examen y al salir para que quede registrada la hora de comienzo y fin. 6. Si el alumno tiene alguna duda y est´a permitido hacer preguntas durante el examen, este tendr´a que solicitar ayuda al profesor de guardia. 7. Si el alumno decide no entregar el examen y est´a permitido hacerlo, tendr´a que comunic´arselo al profesor de guardia. 8. El profesor de guardia deber´a comprobar el aula, as´ı como los puestos ocupados y la identificaci´on correcta de cada alumno. 9. Si durante el examen surge alguna duda de alg´un alumno y no puede resolverla el profesor de guardia, este se encargar´a de enviarle un mensaje al profesor responsable del grupo para que pueda acudir y resolver las dudas. Teniendo en cuenta que esta opci´on est´a permitida. 22 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS 10. Si durante el examen ocurre alguna incidencia deber´a escribir en la aplicaci´on, concretamente en el apartado de “Notas”, dicha incidencia y resolverla si fuese necesario. 11. Si la entrega se realiza en papel, al finalizar un alumno su examen, el profesor de guardia tendr´a que recoger dicho examen y anotar si ha entregado o no. Esta ´ultima parte solo ser´a necesaria si es posible “no entregar”. 12. El profesor responsable tendr´a que revisar que todos los ex´amenes han empezado, acudir a resolver las dudas que surgiese y, al finalizar, recoger los ex´amenes del aula o laboratorio. 13. En el modelo din´amico ser´a necesario que los alumnos se identifiquen dos veces en el lector de tarjetas, una antes de comenzar el examen y otra una vez que est´en los puestos asignados. Ya que la asignaci´on puede cambiar si se decide, por ejemplo, juntar varios aulas. Por ´ultimo, los profesores responsables de cada asignatura ser´an los encargados de cumplir con los requisitos de sus ex´amenes. Al igual que los requisitos del usuario, estos son imprescindibles, ya que, si se hacen mal el sistema no podr´a funcionar correctamente. Los requisitos son los siguientes: 1. El profesor deber´a indicar el n´umero de modelos que tendr´a el examen. 2. El examen tendr´a que ser un formato editable para que al imprimir los ex´amenes se a˜nada el nombre, los apellidos y el puesto del alumno correspondiente. Una buena elecci´on ser´ıa un PDF editable o un DOC/DOCX. 3. En el caso de la existencia de una preinscripci´on, habr´a que hacer un recuento de los alumnos que van a presentarse al examen. En el caso de sin preinscripci´on, el profesor responsable de un grupo tendr´a que facilitar la informaci´on del n´umero de alumnos que podr´an presentarse, as´ı como dar una estimaci´on a la alza de los presentados a dicho examen. 4. Para el correcto funcionamiento de la base de datos, es necesario que al crear un evento se le llame con el formato NombreDeLaAsignatura-MesA˜no, y para subir un examen a la plataforma, es necesario que siga el mismo formato pero a˜nadiendo el modelo del examen, NombreDeLaAsignatura-MesA˜no-ModeloX. Por ejemplo, evento: “Base de datos-Junio2019” y examen que se realiza en esa fecha: “Base de datos-Junio2019-Modelo1”. 5. En el modelo din´amico, ser´a necesario que los profesores responsables de un grupo informen del n´umero de alumnos que podr´an presentarse, realizando una estimaci´on a la alza. 23 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS 4.2 Procesos En este apartado se van a poder visualizar mejor los procesos que tiene que realizar cada actor. Hay dos procesos que se van a desarrollar: Proceso de preparaci´on de examen, realizado antes de que comience el d´ıa del examen, y el Proceso de examen que se realiza durante el d´ıa del examen. Seguidamente, se muestra el diagrama completo, con todas las relaciones y subprocesos que son necesarios. Luego, aparecer´an los distintos subprocesos desplegados para que se visualicen mejor y se pueda entender el proceso completamente. Cabe indicar que los procesos se podr´ıan haber hecho con un pool y varios swimlanes o varios pool. Sin embargo, tras un estudio de ambos casos, nos pareci´o m´as conveniente optar por la primera opci´on, la cu´al se compone de un pool, indicando el proceso que se va a realizar y dentro de ellos tres swimlanes con los actores que intervienen en dicho proceso.3 El proceso comenzar´ıa con un alumno pasando la tarjeta por el lector. En el caso de no tener tarjeta, se tiene que identificar mediante otro documento de identidad, ya sea el DNI o pasaporte, y el profesor de guardia lo verifica y lo ingresa en la aplicaci´on. Una vez hecho esto, si el alumno tiene examen ese d´ıa y no ha llegado tarde (ha pasado m´as tiempo del permitido), se le asigna el puesto, se imprime el examen y el alumno se sienta. El alumno comienza el examen (a la par, el profesor responsable comprueba si ha empezado el examen en las aulas) y el profesor de guardia lo vigila. Durante el proceso de realizaci´on del examen, al alumno le pueden surgir dudas, cuando esto pasa, el alumno avisa al profesor de guardia de su aula y ´este, si no puede resolver el problema y si no es el profesor responsable, env´ıa un mensaje al profesor responsable avis´andole sobre que un alumno tiene alguna duda o si ha surgido alg´un imprevisto. Si el profesor responsable decide cambiar la hora de finalizaci´on del examen, env´ıa un mensaje a los profesores de guardia y estos informan a los alumnos de su aula. Un alumno puede salir del examen si ha pasado X tiempo (donde X es mayor que el tiempo m´aximo de retraso de entrada permitido) desde la hora de comienzo del examen. Una vez un alumno entrega el examen, el profesor de guardia apunta si ha entregado y a la salida, el alumno, vuelve a pasar su tarjeta por el lector para que quede constancia de que ha finalizado su examen. Una vez todos los alumnos finalizan el examen, el profesor responsable los recoge (de una manera u otra dependiendo si la entrega es electr´onica o en papel) y el proceso finaliza. Todo este proceso se puede ver formalizado en los siguiente diagramas. Al final de dichos diagramas aparecen varias tablas explicando el significado de las se˜nales, ya que se dividen en varios tipos: S (Evento de Se˜nal), M (Evento de Mensaje), C (Evento condicional), T (Evento de Tiempo). Estas se˜nales son enviadas y recibidas por distintos procesos o actores. 3Esta representaci´on se ha dise˜nado por medio de el lenguaje est´andar BPMN [14] 24 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS Figura 15: Leyenda de eventos de mensaje Figura 16: Leyenda de eventos de condici´on Figura 17: Leyenda de eventos de tiempo 31 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS 4.3 Modelo de dominio El modelo de dominio es un artefacto de la fase de an´alisis que proporciona una visi´on abstracta de las entidades implicadas/involucradas en la aplicaci´on y las relaciones entre ellas. Suele estar muy relacionado con el modelo de datos, un artefacto de la fase de dise˜no de alto nivel que incluye algunas detalles de dise˜no, que a su vez est´a muy relacionado con el esquema de la base de datos, un artefacto del dise˜no de bajo nivel (que incluye datos detallados como cu´al es la clave primaria, etc.) En el Modelo de dominio[15] que hemos creado, se puede observar que hay varias entidades, no obstante, las que m´as relevancia tienen son las siguientes: Por un lado est´a el Actor Universitario, que se separa a su vez entre profesor y alumno. Por otro lado est´a el Registro docente, que se relaciona con todo lo que ello conlleva. Y por ´ultimo, est´a la entidad de Examen con sus respectivas relaciones. Todas ellas son necesarias vincularlas con m´as clases que hacen que el sistema tenga consistencia. En el caso de la entidad Aula ser´a necesaria para poder realizar las distintas interfaces para la aplicaci´on y para reflejar la relaci´on entre “ReservaAula” dirigida por un profesor y “Asiento” que ocupa un alumno. Adem´as, en la siguiente figura tambi´en se puede observar todas las multiplicidades que tienen las distintas entidades, as´ı se puede tener un concepto m´as amplio sobre la aplicaci´on. Cabe destacar que cuando la relaci´on no tiene un n´umero, la multiplicidad es 1. 32 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS Figura 18: Modelo del dominio 33 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS 4.3.1 Restricciones Tras haber dise˜nado el modelo de dominio de la aplicaci´on a desarrollar hay que tener en cuenta que no se pueden implantar ciertas restricciones de gran importancia. Por lo tanto, indicaremos a continuaci´on dichas restricciones. 1. En una asignatura coordinada, el examen de todos los grupos es com´un. 2. Si un profesor es responsable de una asignaci´on docente, supervisa el examen ordinario asociado a dicha asignaci´on. 3. El profesor de guardia que se encarga de supervisar un examen parcial tendr´a que ser el propio profesor que imparta dicha asignatura, o bien un sustituto si este no pudiese asistir o est´a en otro aula. 4. Quien se encarga de supervisar un examen final o extraordinario es el profesor responsable de una de las asignaciones docentes de dicho registro correspondiente, es decir, el responsable en el primer cuatrimestre , o bien el responsable en el segundo cuatrimestre. No obstante, si el responsable ha sido el mismo en ambos cuatrimestres, ser´ıa este quien supervisase. Si por alg´un casual uno de estos no pudiese asistir, lo supervisar´ıa un sustituto. 5. Si un alumno se presenta a un examen, su asistencia est´a vinculada a un asiento del aula d´onde se va a realizar. El “timeslot” asociado a dicha reserva, se comprende entre la verificaci´on de la hora de entrada y de salida. 6. Si un examen tiene varias reservas de aula, el “timeslot” es igual para todas ellas. 7. Si un alumno se preinscribe o se presenta a un examen, est´a matriculado en la asignatura (registro docente) asociada a este. 8. En el modelo est´atico, si un alumno se quiere presentar a un examen ser´a necesario que dicho alumno se haya preinscrito a un examen, siempre y cuando este est´e matriculado en la asignatura. Sin embargo, esta asociaci´on no existe en el sistema actual, aunque en nuestra aplicaci´on vamos a tratar ambas: con y sin preinscripci´on. 9. Si un alumno est´a matriculado en dos registros docentes id´enticos, es decir, en la misma asignatura, significa que son de distintos a˜nos. 10. Si un profesor imparte dos registros docentes id´enticos significa que son de a˜nos distintos. 11. Una asignatura se ofrece un a˜no dado si pertenece a alguna de las titulaciones de dicho a˜no. 12. Si el n´umero de aulas reservadas para un examen es 1, el profesor que vigila dicho aula es el responsable de la asignaci´on docente, y, por lo tanto, supervisa el examen. 34 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS 4.4 Tipos de actores o usuarios En nuestra aplicaci´on vamos a tratar con varios tipos de actores o usuarios, que tendr´an sus respectivas funcionalidades. En concreto existen: los profesores, encargados de todo lo relacionado con los ex´amenes, es decir, el que finalmente decide qu´e ex´amenes se hacen; los profesores de guardia, que realizar´an funciones sobre el d´ıa del examen, as´ı como indicar alguna incidencia producida en el examen; y los profesores responsables de un grupo, quienes se encargan de comprobar que todos los ex´amenes hayan comenzado a tiempo y de resolver las dudas a los alumnos, entre otras funcionalidades. No obstante, cabe destacar que el profesor responsable de un grupo puede ser a su vez el profesor, por lo que las funcionalidades de dicho profesor se fusionar´ıan con las del profesor. Adem´as de estos actores, tambi´en tienen especial importancia los alumnos y los administradores. Estos ´ultimos se distribuyen en dos m´as: administrador del sistema y administrador de ex´amenes, donde el primero se encargar´a de comprobar que todo el sistema funcione de manera adecuada, y el segundo de la parte de decidir qu´e d´ıa y en qu´e aula se realizan los ex´amenes. Todos ellos emplear´an la aplicaci´on de distinta manera. Aunque en el caso de los alumnos no sea exactamente as´ı, ya que estos no van a usar la aplicaci´on directamente, es necesario que interact´uen con ella a´un no siendo de forma impl´ıcita, como en el caso de pasar la tarjeta universitaria para poder saber en qu´e puesto est´an asignados y para salir del examen, por ejemplo. Figura 19: Tipos de usuarios 35 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS 4.5 Casos de uso Para ver con m´as detalle las funcionalidades que tienen cada uno de los distintos actores en la aplicaci´on hemos empleado diagramas de casos de uso [16]. Dado que hay varios tipos de actores como ya hemos comentado en el apartado anterior, cada tipo de actor tendr´a funciones espec´ıficas que podr´an realizar en la aplicaci´on. A continuaci´on, se muestran dichos diagramas 4. Figura 20: Casos de uso: Administrador del sistema y administrador de ex´amenes 4Todos los diagramas realizados en este apartado y en el siguiente se han hecho mediante la herramienta proporcionada por IBM Rational Software Architecture Designer [17] 36 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS Figura 21: Casos de uso: Alumno, profesor de guardia, profesor responsable y profesor 37 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS 4.5.1 Diagramas de secuencia La ejecuci´on de cada actor sobre la aplicaci´on se puede ver con m´as detalle en los siguientes diagramas de secuencia [18]. Estos diagramas tienen especial relaci´on con los casos de uso especificados en el apartado anterior, ya que muestran con un nivel m´as de detalle los pasos que realiza un actor en su caso de uso correspondiente. Los diagramas que se muestran en las p´aginas siguientes est´an realizados con UML 2.0 [19] y representan la parte de an´alisis, no de dise˜no, bas´andose en lo que hac´ıa Jacobson en su “use-case driven approach” [20]. Debido a esto est´an simplificados, ya que se muestra de forma general los pasos que se ejecutan internamente en la aplicaci´on cuando un profesor a˜nade o elimina uno o varios ex´amenes, por ejemplo. No obstante, para llegar a este ´ultimo paso, hay un proceso de Presentaci´on, Negocio e Integraci´on, es decir, una arquitectura basada en las tres capas [21] para obtener, comprobar e incluir los datos correspondientes a la base de datos. Por ejemplo, en el caso de uso de A˜nadir examen los pasos que se siguen en las distintas capas son: 1. En la capa de Presentaci´on lo ´unico que habr´ıa que hacer ser´ıa extraer los datos, en el caso de a˜nadir un examen ser´ıa coger los nombres de los modelos de ex´amenes que ha insertado el profesor correspondiente. Si todos los datos tienen nombres correctos los almacena y los pasa a la capa de negocio. 2. En la capa de Negocio se comprueba que no existan esos ex´amenes en la tabla de la BBDD de dicha asignatura. Una vez comprobado que todo es correcto los env´ıa a Integraci´on. 3. La capa de Integraci´on se encarga de a˜nadir todos los datos a la base de datos. Por consiguiente, las dos primeras figuras corresponden al caso de uso de login tanto de los profesores como de los administradores. Tras estas aparecen los casos de uso de ambos administradores con sus correspondientes casos particulares. Seguidamente, aparecen el resto de figuras como sigue: En primer lugar, aparecen los diagramas de un profesor con sus respectivas tareas, as´ı como subir, eliminar y/o mostrar ex´amenes. En segundo lugar, las acciones de un profesor de guardia sobre la aplicaci´on en el d´ıa del examen. En tercer lugar, se puede observar las acciones que tiene que realizar un alumno que implican la aplicaci´on cuando se realiza un examen. En cuarto y ´ultimo lugar, se muestran las acciones de un profesor responsable durante las horas correspondientes a la duraci´on del examen. Aunque se haya dividido as´ı, se puede observar que en los distintos diagramas act´uan varios usuarios, ya que los diagramas se hacen por casos de uso y varios actores pueden interactuar en un mismo caso. A continuaci´on, se muestran dichos diagramas para visualizar los procesos de cada usuario. 38 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS Figura 22: Diagrama de secuencia caso de uso “Login” de los administradores Figura 23: Diagrama de secuencia caso de uso “Login” de los profesores Figura 24: Diagrama de secuencia caso de uso “Indicar fecha, hora y aula examen” del administrador de ex´amenes 39 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS Figura 25: Diagrama de secuencia caso de uso “Controlar Aplicaci´on” del administrador de sistema Figura 26: Diagrama de secuencia caso de uso “Dar de alta” del administrador de sistema 40 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS Figura 39: Diagrama de secuencia caso de uso “Identificarse al salir” del alumno 47 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS Figura 40: Diagrama de secuencia caso de uso “Entrega electr´onica” del alumno 48 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS Figura 41: Diagrama de secuencia global de los casos de uso del profesor responsable 49 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS Figura 42: Diagrama de secuencia caso de uso “Consultar examen1” del profesor responsable Figura 43: Diagrama de secuencia caso de uso “Supervisar examen” del profesor responsable 50 4 AN´ ALISIS Y ESPECIFICACI´ ON DE REQUISITOS Figura 44: Diagrama de secuencia caso de uso “Consultar examen2” del profesor responsable Figura 45: Diagrama de secuencia caso de uso “Consultar examen3” del profesor responsable Figura 46: Diagrama de secuencia caso de uso “Recuperar soluciones” del profesor responsable 51 5 VERIFICACI´ ON Y VALIDACI´ ON 5 Verificaci´on y validaci´on La verificaci´on consiste en comprobar que el software cumple los requisitos funcionales y no funcionales de su especificaci´on, mientras que la validaci´on comprueba que el software cumple las expectativas que el cliente espera. Una de las t´ecnicas m´as empleadas en V&V es el testing[22], empleado para evaluar la calidad del software e identificar los problemas o mejoras que puede haber. La verificaci´on se har´a por medio de pruebas en un entorno. Con esto podremos observar si la implementaci´on es la adecuada y no da fallos al intentar conectarse con la base de datos, o al realizar la asignaci´on aleatoria de los puestos, entre otros. Para validar todos los requisitos propuestos anteriormente se tendr´an que hacer pruebas y ver que todo funciona correctamente. Por ello, tendremos que dise˜nar una interfaz de usuario y usar una base de datos de prueba, ya que no tenemos el acceso a los datos de la universidad. En este punto es necesario tratar varios aspectos sobre el testing, ya que ser´a una parte importante a la hora de comprobar que todo est´a realizado correctamente. 5.1 Unidad-Integraci´on-Sistema Para llevar a cabo la fase de testing ser´a necesario realizar un proceso que incluye pruebas de unidad, de integraci´on y de sistema, ya que as´ı aborda todas las partes del software. •Pruebas de unidad[23]: son aquellas que se hacen para comprobar que el c´odigo es correcto, es decir que una funci´on concreta devuelve el resultado esperado. Para estas pruebas se podr´a utilizar Mocha[24], que es un framework de Node.js. •Pruebas de integraci´on[25]: se llevan a cabo tras haber realizado todas las pruebas de unidad, de forma que se verifique que el software funciona correctamente en conjunto. Al igual que para las pruebas de unidad, estas pruebas tambi´en se podr´an realizar con Mocha. •Pruebas de sistema[26]: se realizan despu´es de haber ejecutado las pruebas de unidad e integraci´on, y el objetivo principal es probar que todo el software funcione correctamente en su entorno y en otros, de modo que pueda ejecutarse en distintas plataformas. En este caso, se podr´a emplear la Prueba de Aceptaci´on[27]. Dado que el proceso de testing es iterativo, cada vez que surja un fallo o alguna modificaci´on en cada una de las pruebas se volver´an a analizar de nuevo para que, al finalizar, todo est´e correcto y bien testeado. 52 5 VERIFICACI´ ON Y VALIDACI´ ON 5.2 Caja negra-Caja blanca Cabe decir que hay dos metodolog´ıas o estrategias que se emplean en el testing: caja negra y caja blanca. La primera consta en que dada una entrada de datos devuelva una salida, cuyo contexto viene dado por los requisitos. Aqu´ı se comprueba si esta es la esperada o no. Es decir, no se tiene consciencia del c´odigo, solo se comprueba que dado unos requisitos la salida es la correcta. En cambio, la segunda se realiza con conocimiento del c´odigo y de su estructura, por lo que no ser´a posible realizarla hasta que est´e la parte del c´odigo que se quiere probar. Una de las formas de hacer este tipo de pruebas es teniendo varias sentencias if, case, while, etc. para ir comprobando partes del c´odigo y ver que se ejecuta correctamente cada bloque. Sin embargo, estas pruebas han sido imposibles de realizar debido al tiempo que suponen y el tiempo empleado para estudiar correctamente estas herramientas. No obstante, a continuaci´on explicamos qu´e tendr´ıamos que hacer para realizar dichas pruebas en nuestra aplicaci´on: Por un lado, para los requisitos del sistema en los laboratorios, haremos una simulaci´on de un examen y observaremos los fallos o no que ocasione. Por otro lado, para los requisitos del sistema en el aula nos bastar´a con ver que la interfaz hace las funciones que se piden. Es decir, que se muestre la imagen del alumno en su puesto correctamente, su nombre y sus apellidos, la asignatura del examen que est´a haciendo y por ´ultimo la opci´on de entrega. En cuanto a los requisitos del usuario, se pueden validar por medio del lector de tarjetas, ya que, si no se tiene acceso a la universidad por medio de la tarjeta, no podr´a realizar el examen. Por ´ultimo, para los requisitos de los ex´amenes se deber´a hacer varias pruebas con la base de datos, subiendo varios ex´amenes y viendo que se han guardado correctamente. Adem´as, se comprobar´a que, una vez subido los ex´amenes y conociendo los asistentes al mismo, si corresponde con el modelo est´atico, se realizar´a la disposici´on de las aulas y la asignaci´on de los puestos de cada alumno. En el modelo din´amico, las disposici´on se har´a en el momento del examen. Todo esto se realizar´a mediante pruebas, observando que todo funcione correctamente. 53 6 ELECCI´ ON DE LAS TECNOLOG´ IAS 6 Elecci´on de las tecnolog´ıas 6.1 Lenguajes de programaci´on Una vez considerados los conocimientos, la experiencia y la habilidad de los miembros del equipo en los distintos entornos y lenguajes de programaci´on que se podr´ıan usar de cara a la realizaci´on de este proyecto, decidimos desarrollar la aplicaci´on web en el entorno de Visual Studio Code, ya que era un entorno familiar para todos y soportaba todos los lenguajes que consider´abamos m´as adecuados para la programaci´on. Por el lado del servidor, la aplicaci´on corre en el entorno multiplataforma de c´odigo abierto de Node.js junto con su framework Express.js, de f´acil instalaci´on gracias al Node Package Manager (npm). Los datos usados para el funcionamiento de la aplicaci´on se encuentran alojados en la base de datos relacional MySQL, por lo que las operaciones CRUD se realizan en el lenguaje SQL. Por el lado del cliente, la aplicaci´on se encuentra programada con el lenguaje de marcado HTML en su versi´on HTML5, el lenguaje de dise˜no gr´afico CSS para poder dar estilo al lenguaje de marcado anteriormente citado y con JavaScript implementado como parte del navegador para las mejoras, caracter´ısticas y dinamismo de la aplicaci´on; adicionalmente, hacemos uso de las bibliotecas de c´odigo abierto Bootstrap (basada en CSS) y JQuery (basada en JavaScript), as´ı como la versi´on Standard de DHTMLX Scheduler para la interfaz gr´afica de usuario de la funcionalidad del calendario de ex´amenes. 6.2 Requisitos exteriores Para garantizar el correcto funcionamiento de la aplicaci´on web, las aulas y los laboratorios deben contar con una serie de requisitos fundamentales. Para comenzar, es imprescindible la presencia de un lector de tarjetas para poder obtener la informaci´on de cada alumno. Sin este lector, la lectura de dicha informaci´on para poder completar la interfaz y garantizar el correcto funcionamiento de la aplicaci´on ser´ıa costoso en tiempo y mano de obra. Yuxtapuesto a este requisito podemos mencionar la necesidad de contar con un ordenador con acceso a internet; actualmente este requisito ya se encuentra garantizado en todas las aulas de la Facultad de Inform´atica, pero cabr´ıa se˜nalar la importancia de que el acceso a la red no estuviese activado durante las sesiones de examen. Esto es debido a que un profesor tiene la posibilidad de elegir entre distintos modos de red, deshabilitando completamente la conexi´on.No obstante, para nuestra aplicaci´on ser´ıa necesario que existiese un modo, el cual se pueda deshabilitar la conexi´on de red en los ordenadores de los alumnos, pero manteni´endola en los de los profesores. 54 7 ESTUDIO DEL RIESGO Asimismo, es necesaria la presencia de una una impresora r´apida para cada X alumnos, donde X es un par´ametro que se tiene que elegir basado en la experiencia, por ejemplo la de la UNED. As´ı se podr´a imprimir el examen de cada alumno de forma din´amica seg´un estos vayan fichando con su tarjeta inteligente al entrar al aula. 7 Estudio del riesgo En este apartado vamos a tratar el riesgo de nuestra aplicaci´on. Para ello habr´a que explicar qu´e es el riesgo, qu´e tipo de riesgos hay, c´omo los vamos a afrontar y qu´e posibles soluciones podremos aplicar. 7.1 Qu´e es el riesgo y tipos de riesgo Consideraremos el riesgo como todo lo que pueda afectar de forma negativa al desarrollo del software. Vamos a calificar dichos riesgos en funci´on de su probabilidad de aparici´on y del trabajo necesario para mitigarlo. En consenso, analizaremos los pros, contras y la prioridad que deber´ıamos asignarles. Mediante dicho estudio, podremos medir la calidad final del producto, adem´as de controlar los costes y los errores que nos vayan surgiendo. En la gesti´on de riesgos en proyectos software existen tres tipos, riesgos del proyecto, riesgos t´ecnicos y riesgos de negocio.[28] •Los riesgos del proyecto son cualquier acontecimiento futuro posible que puede afectar de forma negativa o positiva a nuestro proyecto. Por ejemplo, no disponer del hardware necesario para realizar nuestra aplicaci´on, p´erdida de un miembro del equipo o incluso, cambios inesperados sobre los requisitos del proyecto. •Los riesgos t´ecnicos ponen en peligro la calidad resultante del software. Si estos se cumplen el proyecto es m´as complejo de lo estimado. Tales como que los componentes de software elegidos no trabajan adecuadamente, lo que provoca fallos en el sistema, o algoritmos inadecuados que no cumplen las restricciones de tiempo de respuesta. •Los riesgos de negocio ponen en peligro la viabilidad del software que se construir´a, como podr´ıan ser la salida de un proyecto similar al nuestro. Si estos se cumplen el proyecto se cancelar´a. 55 7 ESTUDIO DEL RIESGO 7.2 Estrategias de la gesti´on del riesgo La gesti´on de riesgos puede definirse como el proceso sistem´atico de identificaci´on, an´alisis y respuesta a los riesgos que se presentan durante el ciclo de vida de un proyecto. Para identificar riesgos y afrontarlos debidamente en el proyecto existen dos tipos de estrategias. A continuaci´on vamos a realizar un estudio de ambas estrategias para poder determinar la m´as adecuada para nuestro proyecto. [29] •Estrategia reactiva: es una acci´on que se efect´ua en respuesta a algo que ya ha sucedido. Se realiza a posteriori, con la informaci´on del pasado disponible. El m´etodo que sigue este tipo de estrategia se basa en cinco pasos: 1. Buscar y analizar los riesgos. 2. Asignar recursos por si dichos riesgos se cumplen y se convierten en problemas reales. 3. El personal no se ocupa del riesgo hasta que se hace real. 4. Se intenta resolver el problema. 5. Por ´ultimo, comienza la gesti´on de crisis. •Estrategia pro-activa: significa prever, anticipar y planear para cambios y crisis. Se aplican antes de que el riesgo haya tenido lugar. Esta tambi´en se realiza en cinco pasos que se describen a continuaci´on: 1. Antes de la realizaci´on del proyecto, se estudian los riesgos conocidos y por conocer. 2. Se estima la probabilidad de que aparezcan dichos riesgos y se cuant´ıan los problemas que puedan surgir. 3. Se priorizan los riesgos detectados en una lista. 4. Se realiza el plan de gesti´on de riesgos, previamente definido. 5. Se realizar´an planes de contingencia si no da resultado el paso anterior. La gesti´on se llevar´a a cabo mediante tres fases distintas del plan RSGR (Reducci´on, Supervisi´on y Gesti´on del Riesgo). A continuaci´on, explicamos dichas fases: •En la fase de reducci´on se intentar´a evitar que los riesgos se conviertan en problemas reales, y se buscar´an soluciones por si esto sucediera. Esta fase tambi´en se denomina como identificaci´on del riesgo. •La fase de supervisi´on controlar´a si los riesgos se han hecho reales. Si esto sucede, se supervisar´a la efectividad de los planes de reducci´on de riesgos obtenidos en la fase anterior. Denominada tambi´en como an´alisis del riego. 56 8 EL SISTEMA •dao admin.js: Este archivo js contiene las funciones relativas a la administraci´on de los usuarios que contiene la BBDD tales como a˜nadir, eliminar, buscar o devolver uno o una lista de usuarios. •dao exams.js: el DAO ex´amenes sirve de conexi´on con la BBDD a la hora de manipular la informaci´on referente a los ex´amenes, tales como su subida a la base de datos (BBDD), su eliminaci´on de la misma o mostrar aquellos que est´an guardados, entre otras funcionalidades. •dao teachers.js: Este ´ultimo DAO contiene las funciones necesarias para realizar las operaciones CRUD relativas al profesorado, ente las que podemos citar el control de acceso de usuarios, la consulta de sus asignaturas en curso o la consulta sobre un posible examen en marcha al iniciar la aplicaci´on. Figura 52: Ejemplo de una funci´on del dao teachers, en este caso de la funci´on que controla el acceso a la aplicaci´on 63 8 EL SISTEMA Dada la falta de presupuesto para adquirir los elementos necesarios para el proyecto, como pueden ser el lector de tarjetas y las impresoras, se han tenido que simular algunos procesos. Para asignar puestos a los alumnos en un aula de examen se a˜naden aleatoriamente a partir de la informaci´on de la base de datos y se les asigna un puesto aleatorio que tiene a su vez asignado un modelo con la restricci´on de que un alumno no puede estar al lado de otro con el mismo modelo. Respecto a la falta de impresoras, se ha creado una funci´on donde para cada alumno que entra a una sala de examen, su modelo se a˜nade a una cola de impresi´on. 8.3 Vistas del sistema En cuanto a la ´ultima capa, relativa a la interfaz de usuario, las vistas del sistema se encuentran ubicadas dentro del directorio public/views, dentro del cual se pueden observar varios archivos del tipo “.ejs”. Este tipo de archivos consisten en plantillas de JavaScript que permiten procesar p´aginas HTML en el servidor antes de enviarlas al cliente. Es uno de los motores de plantillas m´as r´apidos cuando se usa junto a Node.js y Express.js. Como ha sido explicado anteriormente, dependiendo de si el usuario tiene el rol de administrador o el del profesor, la aplicaci´on permite el acceso a unas vistas u otras; a continuaci´on se enumeran y explican brevemente estas interfaces: •adminusers.ejs: Esta vista solo est´a disponible para el administrador del sistema. En ella se muestran todos los actores universitarios con toda su informaci´on (id, Nombre, Apellidos y Rol) junto con la opci´on de agregar, gestionar credenciales de acceso, gestionar supervisores de ex´amenes y borrar usuarios. Figura 53: Interfaz de la vista de administraci´on de usuarios. 64 8 EL SISTEMA •admin.ejs: Esta vista muestra un calendario para que el administrador de ex´amenes, ´unico usuario que puede acceder a ella, pueda establecer los d´ıas, horas y aulas para la realizaci´on de los ex´amenes de los distintos grados y cursos. Esta vista ofrece tambi´en al administrador la posibilidad de exportar dicho calendario en formatos PNG y PDF. Figura 54: Interfaz de la vista de administraci´on de ex´amenes. En la captura de pantalla podemos ver el momento justamente anterior a la introducci´on del examen en la base de datos. •hall.ejs: Esta interfaz representa la distribuci´on del aula o laboratorio en el que se est´a realizando el examen de la asignatura que imparte el profesor con la sesi´on iniciada. En la parte superior se indica el aula en el que se imparte el/los examen/es junto con el nombre de la/s asignatura/s. A continuaci´on se encuentra, en la parte izquierda, una imagen que representa el aula con el n´umero de filas y columnas y el n´umero de los puestos, y, a su derecha, aparece una tabla donde cada fila corresponde a la informaci´on de cada alumno que va llegando al aula; incluye su n´umero de asiento, su nombre completo y el modelo del examen que le ha asignado el algoritmo en funci´on de su puesto. Adem´as, al seleccionar una fila se despliega una ventana modal con la informaci´on del alumno que est´a realizando el examen en ese puesto. Dentro de ella, tambi´en se puede observar varios botones: uno con la opci´on de indicar la entrega del examen por parte del alumno, otro para indicar al profesor una posible situaci´on de copia que haya incluido a ese alumno en el transcurso del examen, otro para los alumnos que han decidido marcharse sin entregar si los estatutos as´ı lo permiten, y un ´ultimo para descartar la ventana modal. 65 8 EL SISTEMA Figura 55: Interfaz de la vista del aula para ex´amenes en curso. Al clicar en cualquier fila de la tabla de la derecha aparecer´ıa el modal con las distintas opciones. •exams.ejs: Esta vista es solo accesible para los profesores. Desde aqu´ı se pueden tanto subir ex´amenes a la plataforma como visualizarlos desde un visor de PDF o eliminarlos. A la izquierda de la pantalla, se puede observar tambi´en una columna con las asignaturas que imparte el profesor que tiene iniciada la sesi´on en ese momento. Figura 56: Interfaz de la gesti´on de ex´amenes 66 8 EL SISTEMA •login.ejs: Es la primera interfaz que se muestra cuando se inicia la aplicaci´on y a la que se redirige siempre que se intenta entrar en otra ruta sin haber antes iniciado sesi´on. En ella se da la opci´on de identificarse mediante un usuario y una contrase˜na, que deben haber sido otorgadas previamente por el administrador del sistema. Solo pueden acceder a la aplicaci´on los profesores, tanto de guardia como los profesores responsables, y los administradores, quedando exentos los alumnos. Dependiendo del tipo de actor universitario, se redirigir´a a una vista u otra, en funci´on del rol que desempe˜na cada uno. Figura 57: Interfaz de la vista de inicio de sesi´on. •error.ejs: La interfaz de error recoge todos los posibles casos en los que el servidor devuelva al usuario un c´odigo de estado de error 404. Este c´odigo de estado indica que alguna redirecci´on de la aplicaci´on o una ruta introducida por el usuario directamente en el navegador se trata de un enlace roto o que ya no existe y que, por lo tanto, no es posible navegar por ´el. 8.4 Funcionamiento del sistema 8.4.1 Base de datos Ya que la informaci´on del alumnado de la Universidad es confidencial y no se nos ha podido dar acceso a la base de datos de la UCM, para la realizaci´on de este proyecto se ha desarrollado una alternativa bas´andonos en la inclusi´on de la informaci´on que creemos necesaria. El sistema de gesti´on de base de datos elegido fue MySQL. En este 67 8 EL SISTEMA sistema se guarda toda la informaci´on que es necesaria en la aplicaci´on para la subida de ex´amenes, la administraci´on de fechas de ex´amenes, administraci´on de profesorado y alumnado y la informaci´on necesaria para la generaci´on de las vistas de las aulas con los alumnos. La estructura de la base de datos se ha realizado de la siguiente manera: en primer lugar, el sistema cuenta con una tabla donde se guardan los actores universitarios que juegan un rol en el funcionamiento de la plataforma; aquellos actores que necesiten credenciales de acceso a la misma, como el profesorado, pueden ser dados de alta, y su informaci´on se almacenar´a en la tabla “conectar”. Por otra parte, los profesores se relacionan con las asignaturas que imparten mediante una tabla llamada “imparte”, que contiene tanto el id del profesor como el de las asignaturas y el grupo en el que imparte cada asignatura (estando tanto la informaci´on de “grupo” como de “asignatura” alojadas en otras dos tablas) Asimismo, estos profesores est´an tambi´en relacionados con la tabla “aviso”, que contiene los mensajes de las posibles situaciones de copias que se han dado en los ex´amenes de su asignatura. Para organizar los ex´amenes y sus distintos modelos se tiene una tabla con la informaci´on de la capacidad de las aulas, que se relacionan con las tablas “examen” y “modelos” para que el algoritmo de asignaci´on aleatoria trabaje con todas las variables relativas a dichas tablas. Tambi´en se gestionan las entregas mediante el uso de una tabla donde se guarda la hora a la que entrega cada alumno el examen. Por ´ultimo, se tiene una tabla de eventos donde se guardan las fechas de los ex´amenes junto con el nombre de la asignatura de cada examen. Estos eventos est´an relacionados con la tabla “examen” mediante una clave ajena en esta ´ultima tabla. A continuaci´on se muestra un esquema con las diecisiete tablas que contiene la base de datos y sus relaciones: 68 8 EL SISTEMA Figura 58: Esquema de la Base de Datos. Para el correcto funcionamiento de la aplicaci´on, se tiene que tener en cuenta las restricciones mencionadas en el apartado 4.3.1. 8.4.2 Algoritmo de asignaci´on aleatoria Dentro del DAO que se encarga de garantizar el funcionamiento relativo a la gesti´on de ex´amenes podemos encontrar las funciones que permiten que la aplicaci´on sea capaz de garantizar una asignaci´on de puestos aleatorios, que disminuya las posibilidades de copia y automatice la labor del profesor a la hora de repartir los ex´amenes. Este sencillo algoritmo genera un n´umero de fila y un n´umero de columna aleatorios con valores entre uno y el n´umero total del que disponga el aula en el que se realiza el examen, hasta generar un conjunto de valores que no haya sido asignado con anterioridad. Una vez generados, se genera un array con los distintos modelos de examen de esa asignatura que hayan sido guardados en la base de datos. Este array se rota dependiendo de si la fila es par o impar, con el objetivo de que nunca haya dos ex´amenes iguales en dos puestos inmediatamente contiguos horizontal o verticalmente. Gracias a esta rotaci´on, se garantiza que tanto filas como columnas cumplan esta condici´on con independencia de cuantos modelos sean, y sin importar la capacidad del aula. Una vez se realiza este proceso, la aplicaci´on garantiza que no pueda volver a ser escogido de nuevo aleatoriamente gracias a una cookie de sesi´on que contiene todos los asientos que ya han sido ocupados. 69 9 TRABAJO INDIVIDUAL 9 Trabajo individual En este apartado se va a explicar el trabajo que ha realizado cada uno de los integrantes del equipo, especificando las tareas que se han llevado a cabo, c´omo se han realizado y si se produjo alg´un contratiempo. Para llevar a cabo la organizaci´on a lo largo de todo el trabajo, se ha seguido la metodolog´ıa Scrum, una metodolog´ıa ´agil. Dicha metodolog´ıa est´a caracterizada por el seguimiento del trabajo y por realizar cambios en cada iteraci´on, de manera que, si al finalizar una iteraci´on se descubren fallos imprevistos, se pueden corregir y volver a realizar pruebas sobre ellos m´as adelante. Escogimos Scrum[32] dado que, gracias a que nos proporciona dicha ventaja, nos facilita la mejora de implementaci´on o correcci´on de errores, ya que se podr´ıa cambiar en cualquier momento despu´es de la iteraci´on. 9.1 Ignacio Tras documentarnos a fondo sobre la tem´atica de nuestro Trabajo de Fin de Grado, mis compa˜neras y yo decidimos hacer en primer t´ermino un reparto inicial de tareas a partir de un ´ındice preliminar que cre´ıamos pod´ıa reunir las principales l´ıneas que seguir´ıa el proyecto en el futuro m´as inmediato. Dentro de este primer reparto, personalmente me toc´o encargarme de realizar la introducci´on y de su consecuente traducci´on. Para realizarla, tuve que investigar sobre el desarrollo a lo largo del tiempo del m´etodo de evaluaci´on de alumnos en los centros de aprendizaje hasta llegar al d´ıa de hoy, as´ı como informarme sobre el estado actual de la log´ıstica de ex´amenes tanto en la Universidad como en la Facultad m´as espec´ıficamente. Una vez realizado, me dispuse a explicar la motivaci´on y el objetivo de este proyecto y los problemas que pretend´ıamos erradicar, as´ı como detallar la estructura de esta memoria para que sirviese de gu´ıa para el lector y facilitase su lectura o b´usqueda de informaci´on. Una vez depurados los primeros errores, organizamos una segunda reuni´on grupal para decidir cu´ales ser´ıan los siguientes pasos a seguir. Con el objetivo de hacer una especificaci´on de requisitos lo m´as completa posible, decidimos que lo m´as adecuado ser´ıa realizar esa secci´on todos juntos, discutiendo las ideas y dudas que ´ıbamos planteando tanto yo como mis compa˜neras Julia y ´ Agata sobre las necesidades y limitaciones que supon´ıa el potencial entorno que iba a tener nuestra aplicaci´on. Fue entonces, tras terminar de definir dichos requisitos y al empezar a discutir los posibles riesgos y elaborar los primeros diagramas, cuando detectamos la necesidad de elaborar la memoria en un editor de textos m´as potente al que est´abamos acostumbrados. Una vez Simon nos introdujo en LaTeX[33], encontramos que el editor de textos en l´ınea Overleaf se ajustaba perfectamente a las necesidades de nuestro equipo. A continuaci´on me dispuse a realizar la elecci´on de tecnolog´ıas con las que desarrollar´ıamos la aplicaci´on; como se explica en esta memoria en el apartado 6.1, la decisi´on 70 9 TRABAJO INDIVIDUAL que se tom´o fue la de realizar la aplicaci´on en el entorno de Node.js, haciendo uso de lenguajes como HTML, JavaScript, CSS y bibliotecas como JQuery, que todos conoc´ıamos gracias a la asignatura de Aplicaciones Web. Tras terminar la configuraci´on inicial de los puertos y los paquetes de Node.js que son necesarios para su correcto funcionamiento, la primera parte de la aplicaci´on que me dispuse a desarrollar fue la vista correspondiente al acceso de usuarios y sus correspondientes funciones del Modelo (DAO usuarios) y los manejadores de ruta en la capa controlador (app.js). Este primer contacto con la aplicaci´on no me requiri´o demasiado esfuerzo en completar, puesto que hab´ıamos realizado ya otros controles de acceso similares durante la carrera. Cuando mi compa˜nera Julia tuvo terminada la estructura del dise˜no de la base de datos que previamente hab´ıamos ideado todos juntos, me dispuse a realizar la parte necesaria para la funcionalidad de administraci´on de ex´amenes, incluyendo de nuevo tanto la vista como las consecuentes funciones y manejadores del resto de capas. Tras mucha investigaci´on y a base de fallar en numerosas ocasiones a la hora de tratar de conseguir la implementaci´on desde el que consider´abamos el enfoque m´as oportuno para desarrollar esta parte, decid´ı hacer uso de la API Scheduler de DHTMLX. Este desarrollo me llev´o m´as tiempo del esperado por la aparici´on de peque˜nos errores que no supe solucionar hasta que realic´e una lectura m´as profunda de la documentaci´on de dicha herramienta. Al final, gracias a unos peque˜nos cambios en la BBDD, conseguimos que la funcionalidad acabase ejecut´andose tal y como dese´abamos. Prosegu´ı el desarrollo de la aplicaci´on con la implementaci´on de las aulas con la ayuda de Julia, funcionalidad a la que por desgracia no conseguimos darle todo el potencial que quer´ıamos (en un principio, planteamos la posibilidad de desarrollar un mapa din´amico de asientos similar al de aerol´ıneas o teatros, pero acabamos optando por la inclusi´on de una imagen est´atica y una tabla din´amica con la informaci´on de los alumnos y las acciones pertinentes al profesorado tales como entregar o notificar copias). Continu´e con la implementaci´on del algoritmo necesario para la disposici´on aleatoria de los alumnos en las aulas y la asignaci´on del modelo de examen correspondiente. Este peque˜no reto supuso tener que idear un algoritmo que fuera sencillo y que cubriese las necesidades que est´abamos buscando, pero finalmente conseguimos el objetivo, no sin haber probado varios enfoques incorrectos. El siguiente paso fue la inclusi´on de diferentes bibliotecas que inclu´ıan mejoras en el dise˜no de la aplicaci´on, as´ı como la finalizaci´on del DAO de administraci´on y los ´ultimos retoques a la hora de implementar, corregir y optimizar diversas partes de las capas controlador y vista. Una vez ten´ıamos la demo de la aplicaci´on ya operativa y funcionando correctamente, redact´e aquellos apartados del Sistema que me hab´ıa tocado desarrollar. Posteriormente, me dispuse a escribir junto a mis compa˜neras un ´ultimo apartado en la memoria en la que inclu´ıamos nuestras conclusiones y las l´ıneas futuras, intentando ofrecer nuestra visi´on del trabajo realizado y dejando la puerta abierta a diversas funcionalidades que creemos que encajar´ıan perfectamente en la aplicaci´on si se pudieran desarrollar 71 9 TRABAJO INDIVIDUAL en un futuro; estas funcionalidades incluyen aquellas que nos hubiera gustar incluir a nosotros desde un principio, pero que por falta de tiempo nos acab´o siendo imposible desarrollar. Con este cap´ıtulo terminado, repasamos la memoria completa con el objetivo de encontrar fallos de acuerdo con la normativa y poder corregirlos, as´ı como empezar a trabajar en nuestra presentaci´on y rematar los ´ultimos flecos en cuanto a la maquetaci´on de la misma. Entre los fallos m´as destacados se encontraba la no traducci´on de diversas secciones de la memoria, por lo que me encargu´e de traducirlas al ingl´es como se exig´ıa en la normativa para los trabajos de fin de grado. 9.2 Julia Primero organizamos el reparto de tareas inicial. Una vez distribuidas las tareas y puntos a realizar por cada miembro, mi aportaci´on fue hacer el apartado de Antecedentes y plan de trabajo. Para empezar a informarme sobre dicho punto, envi´e correos electr´onicos a diversas universidades de Europa, con el fin de obtener informaci´on sobre su m´etodo al realizar ex´amenes. Dadas las insuficientes respuestas obtenidas, tuve que tomar la decisi´on de investigar m´as profundamente y cambiar alguna universidad acordada con mis compa˜neros previamente. Tras la correcci´on del tutor, a˜nad´ı el apartado explicando la gesti´on de ex´amenes en la UNED, correg´ı errores y se dio por finalizado este punto. Una vez terminados la Introducci´on realizada por Ignacio y el modelo de dominio, organizamos una reuni´on para proponer y discutir los requisitos que quer´ıamos implantar en la aplicaci´on. Una vez establecidos, posteriormente yo me encargu´e de definir los grados de complejidad que se pueden desarrollar en la aplicaci´on y los incorpor´e a la memoria. M´as adelante entre ´ Agata, Ignacio y yo, fuimos corrigiendo errores en los diagramas que hab´ıa realizado ´ Agata en un principio con las correcciones y mejoras que nos iba sugiriendo el tutor. A la par de ir haciendo modificaciones en los diagramas e ir corrigiendo errores, empezamos a pensar los riesgos que podr´ıan aparecer al realizar la aplicaci´on. Tuvimos una reuni´on donde definimos los riesgos que podr´ıan surgir y realizamos un estudio de ´estos. En este apartado, mi aportaci´on fue, una vez hecho el estudio y haber dado las caracter´ısticas necesarias a cada uno, realizar las tablas. En la primera tabla (An´alisis de riesgos), puse los riesgos con su probabilidad y su efecto. Despu´es en las tablas del apartado Priorizaci´on del riesgo, realic´e una donde mediante las caracter´ısticas de la probabilidad con la que puede ocurrir y el efecto que puede tener, se le otorga un valor a cada uno de ellos. Habi´endoles dado dicho valor, por ´ultimo, hice la tabla de An´alisis y priorizaci´on del riesgo, donde se ordenan por gravedad. Despu´es de la revisi´on del tutor, se tuvo que cambiar un riesgo y realic´e el cambio reflej´andolo en las tablas. Cuando este apartado se termin´o, y con ellos, gran parte de la memoria, organizamos otra reuni´on para discutir y elegir las tecnolog´ıas que´ıbamos a usar en la aplicaci´on. Nos 72 11 CONCLUSI´ ON Y L´ INEAS FUTURAS 11 Conclusi´on y l´ıneas futuras En la actualidad, el m´etodo de realizaci´on de los ex´amenes en la facultad de inform´atica no es tan efectivo como creemos que podr´ıa ser. La investigaci´on y el desarrollo que hemos llevado acabo tienen como objetivo hacer m´as eficiente este proceso, optimizando las p´erdidas de tiempo y permitiendo tener una mejor organizaci´on dentro de las aulas. Ocasionalmente, optimizando la p´erdida de tiempo y tener una mejor asignaci´on de aulas. Adem´as, quer´ıamos desarrollar una tecnolog´ıa que ahorrara una gran cantidad de espacio, tiempo y posibles situaci´on de copia entre los alumnos examinados. Todo el software creado es libre y est´a bajo licencia GNU GPL. La aplicaci´on consta de un algoritmo que se encarga de que dos alumnos con el mismo examen en el mismo aula no puedan sentarse uno al lado del otro. Este problema, en la actualidad, al hacerse cargo el profesor de manera manual, crea una p´erdida de tiempo a la hora de comenzar un examen. Asimismo, si un alumno llega tarde, el profesor de guardia tiene que mirar los ex´amenes que est´an realizando los alumnos de alrededor del sitio en que se va a sentar el nuevo alumno y darle el modelo correspondiente, problema que se va a evitar´a con la nueva tecnolog´ıa que queremos implantar. La aplicaci´on web tambi´en consta de un apartado de incidencias en la interfaz de los profesores de guardia, para que si en el caso de que ocurra alg´un problema con un alumno o se quiera resolver una duda con el profesor responsable, el proceso sea m´as r´apido mediante el uso de unas notificaciones y se evite la p´erdida de tiempo tanto para el profesor como para los alumnos. Esto es una gran ventaja, dado que si ocurre alg´un problema grave, se puede resolver de manera m´as efectiva. En resumen, este proyecto nos ha dado la oportunidad de fijarnos unos objetivos y afrontar el reto de poder cumplir dichos objetivos, afrontando dificultades y valorando la importancia de una buena planificaci´on en la gesti´on de proyectos software. Con el fin de mejorar el proyecto en algunos aspectos que pensamos que son importantes para una mayor efectividad, consideramos que, a grandes trazos, como l´ıneas de desarrollo para el futuro se podr´ıan implementar los siguientes puntos, los cuales nos ha sido imposible desarrollar por falta de tiempo: •A˜nadir un lector de tarjetas para poder pasar la informaci´on del alumno mediante este elemento. •Implantar impresoras en las aulas para que se pudiese imprimir el examen de cada alumno en el momento en el que se presenta a dicho examen imprimiendo su puesto y datos en el enunciado. •Crear una interfaz de mantenimiento donde, por ejemplo, si uno o varios ordenadores del laboratorio donde se va a realizar un examen est´a estropeado o no actualizado, no se pueda seleccionar para que un alumno se siente. 79 12 CONCLUSION AND FUTURE DEVELOPMENT •Implantar un lector con pantalla o, en su defecto, un monitor o pantalla de ordenador, para que en el caso de que un alumno quiera acudir a un aula donde ya no haya asientos disponibles o se equivoque de aula, informe sobre el error y muestre una soluci´on. Por ejemplo, si un alumno tiene un examen donde van a usarse dos aulas y quiere acceder a un aula que est´a llena, en la pantalla se muestre que tiene que ir al otro aula disponible. •Paralelamente al punto anterior tambi´en se podr´ıa conseguir que al realizar ex´amenes en el laboratorio se pueda evitar la impresi´on en papel. En la pantalla del lector saldr´ıa el puesto asignado del alumno y podr´ıan descargarse el enunciado una vez sentados. •Activar inhibidores en las aulas para evitar copias y acceso a internet. •A˜nadir esc´aneres en las aulas para que los profesores puedan crear una copia de los ex´amenes de los alumnos y as´ı darles la oportunidad de poder corregir fuera de la Facultad y evitar casos de p´erdida. Otra ventaja que se tiene, es la posibilidad de que el profesor pueda enviar a los alumnos una copia electr´onica del examen para tener m´as facilidades a la hora de ir a la correcci´on. Y por ´ultimo, se podr´ıa generar una copia de seguridad de los ex´amenes de todos los a˜nos por si acaso en un futuro se necesitan. •Permitir que los alumnos de un examen puedan empezarlo en horas ligeramente distintas y notificar al profesor por medio de la interfaz cu´ando acaba cada alumno. •Implementar la opci´on de que el profesor responsable de cada asignatura pueda elegir el n´umero de puestos vac´ıos entre los alumnos (si lo deseara) para la realizaci´on del examen. 12 Conclusion and future development At the present time, the method of conducting exams in the Computer Science Faculty is not as efficient as we consider it could be. The research and development we have carried out have the aim to improve the effectiveness of this process, optimizing the loss of time and have a better classrooms allocation. Moreover, we wanted to develop a technology that would save enourmous amount of space, time and possible cheating situation among the examined students. All software developed is free software and is under GNU GPL License. The application contains an algorithm that ensures that two students with the same test model within the same classroom can not sit next to each other. This issue is currently solved by the teacher manually, wasting time when starting a test. Additionally, if a student is late, the teacher on duty has to take a look to the exams that are already being taken by the students around the place the new student is about to sit in, and 80 12 CONCLUSION AND FUTURE DEVELOPMENT give him the corresponding model, a problem that will be avoided with the system that we implemented. The web application also includes a section of incidents in the interface for the teachers on duty, so that if there is any problem with a student or if they need the main teacher for any matter, the process will be faster through some notifications and avoid the loss of time for both students and head teacher. This implies a great advantage, since if a serious issue takes place, it can be solved more effectively. Altogether, this project has given us the opportunity to set certain goals and face the challenge of being able to meet their deadlines, facing difficulties and letting us appraise the importance of planning within software projects. In order to improve the project in some aspects that we think are relevant for greater effectiveness, we consider that, in broad brushstrokes, some of the future development could consist in the following points, which we have been unable to develop due to lack of time: •Add card readers so the students information can be parsed through them. •Create an additional interface where, for example, if one or more computers in the laboratory where an exam is to be carried out is broken or not updated, it can not be selected by the algorithm as an allocation place. •Install card readers with screen or, alternatively, any other device with a display, so that in the event that a student wants to go to a classroom where there are no seats available anymore or the classroom he just entered is wrong, the screen would report the error and provide with a solution. For example, if a student is about to take an exam where two classrooms are going to be used, and he or she wants to access a classroom that is already full, the screen would show the classroom in which there is still room for more students. •In tandem with this last point, it could also be possible to avoid printing on paper when carrying out exams in the laboratories. The randomly assigned position of the student would appear on the reader’s screen, and the statement could then be downloaded once the student is seated. •Activate signal inhibitors in the classrooms when exams start to avoid copies and irregular access to the internet. •Introduce scanners in the classrooms so that teachers can print backup copies of the exams, given them the chance to correct those exams out of the Faculty and preventing possible cases of loss. •Allow students within the same exam to start taking it at slightly different times and notify the teacher through the interface when each student’s time finishes. 81 12 CONCLUSION AND FUTURE DEVELOPMENT •Deploy the functionality which would allow the responsible teacher for each subject to choose, if desired, the amount of empty spaces between the students when taking the exam. 82 Glosario Siglas BBDD base de datos. 22, 23, 32, 38, 52–54, 57, 60, 63, 64, 67, 68, 71, 73, 75–78 BPMN Business Process Model and Notation. 24, 74, 76, 78 CRUD Create, Read, Update and Delete. 54, 63 DNI Documento Nacional de Identidad. 15, 22, 24 GPL General Public License. 79 IBM-RSA IBM Rational Software Architecture Designer. 36, 74 IT Tecnolog´ıa de la Informaci´on. 8, 11 MVC Modelo Vista Controlador. 61 RSGR Reducci´on, Supervisi´on y Gesti´on del Riesgo. 56, 60 SQAS-SEI Software Quality Assurance Subcommittee. 58, 59 TFG Trabajo de Fin de Grado. 2, 9, 10, 70 UCM Universidad Complutense de Madrid. 8, 14, 16, 67 UML Unified Modeling Language. 38, 74, 78 UNED Universidad Nacional de Educaci´on a Distancia. 13, 14, 55, 72, 76 Glosario Bootstrap es una biblioteca multiplataforma o conjunto de herramientas de c´odigo abierto para dise˜no de sitios y aplicaciones web. 54, 78 CSS es un lenguaje de dise˜no gr´afico para definir y crear la presentaci´on de un documento estructurado escrito en un lenguaje de marcado, en este caso HTML. 54, 71, 78 Express.js es un marco de aplicaci´on web para Node.js, lanzado como software gratuito y de c´odigo abierto bajo la Licencia MIT. Est´a dise˜nado para construir aplicaciones web y APIs. 54, 64, 78 83 Glosario HTML (HyperText Markup Language en ingl´es) hace referencia al lenguaje de marcado para la elaboraci´on de p´aginas web. 54, 64, 71, 78 JavaScript (abreviado com´unmente JS) es un lenguaje de programaci´on interpretado, dialecto del est´andar ECMAScript. Se define como orientado a objetos, basado en prototipos, imperativo, d´ebilmente tipado y din´amico. 54, 64, 71, 75, 78 jQuery es una biblioteca multiplataforma de JavaScript que permite simplificar la manera de interactuar con los documentos HTML, manipular el ´arbol DOM, manejar eventos, desarrollar animaciones y agregar interacci´on con la t´ecnica AJAX a p´aginas web. 54, 71, 78 LaTeX es un sistema de composici´on de textos, orientado a la creaci´on de documentos escritos que presenten una alta calidad tipogr´afica. Por sus caracter´ısticas y posibilidades, es usado de forma especialmente intensa en la generaci´on de art´ıculos y libros cient´ıficos que incluyen, entre otros elementos, expresiones matem´aticas. 70, 78 mySQL es un sistema de gesti´on de bases de datos relacional desarrollado bajo licencia dual. 54, 67 Node.js es un entorno en tiempo de ejecuci´on multiplataforma, de c´odigo abierto, para la capa del servidor (pero no limit´andose a ello) basado en el lenguaje de programaci´on ECMAScript, as´ıncrono y basado en el motor V8 de Javascript. 2, 10, 13, 52, 54, 62, 64, 71, 78 SQL es un lenguaje espec´ıfico del dominio utilizado en programaci´on, dise˜nado para administrar, y recuperar informaci´on de sistemas de gesti´on de bases de datos relacionales. 54, 73, 78 84 REFERENCIAS Referencias [1] Alex Usher. A Brief History of Exams. Oct. de 2016. url:http://higheredstrategy. com/a-brief-history-of-exams/. [2] Professor Derk Bodde. Chinese ideas in the west. 2004. url:http://afe.easia. columbia.edu/chinawh/web/s10/ideas.pdf. [3] La Valija Virtual. UNED.url:http : / / portal . uned . es / portal / page ? _pageid=93,36662434&_dad=portal&_schema=PORTAL (visitado 05-2019). [4] La Valija Virtual. UNED Examenes.url:http://portal.uned.es/portal/ page?_pageid=93,53408118&_dad=portal&_schema=PORTAL (visitado 05-2019). [5] La Valija Virtual. UNED.url:http://www.dicub.es/p18/valija-virtual. aspx (visitado 05-2019). [6] Tallin University. Examinations and Assessments.url:https://www.tlu.ee/ en/taxonomy/term/90/examinations-and-assessments (visitado 05-2019). [7] University of Bergen. Exam registration on Studentweb.url:https://www.uib. no/en/student/49276/exam-registration-studentweb (visitado 05-2019). [8] Univerity Of Helsinki. Examinations.url:https://www.helsinki. fi/en/ open-university/studying/during-your-studies/examinations (visitado 05-2019). [9] Amanda Malmquist. Exams at Malm¨o University.url:https://www.mah.se/ english/Student/For-your-studies/Examination/ (visitado 05-2019). [10] Martin Jensen. Personal Communication. University of Denmark. 2 de nov. de 2018. [11] Univerity Of Oulu. General Exam.url:http://www.oulu.fi/university/ node/34979 (visitado 05-2019). [12] Marcial C´ordoba Padilla. Formulaci´on y evaluaci´on de proyectos. Ecoe ediciones, 2011. [13] Bangalore D Nagesh Kumar IISc. Optimization Methods: Linear ProgrammingSimplex Method-I.url:https :/ /nptel .ac .in / courses/ 105108127/ pdf/ Module_3/M3L3_LN.pdf (visitado 05-2019). [14] Bussiness Process Model y Notation. BPMN.url:https://www.omg.org/spec/ BPMN/2.0/PDF (visitado 05-2019). [15] IBM Community. Modelos de dominio.url:https://www.ibm.com/support/ knowledgecenter/es/SS9UM9_9.1.2/com.ibm.datatools.logical.ui.doc/ topics/cdommod.html (visitado 05-2019). [16] IBM Community. Casos de uso.url:https://www.ibm.com/support/knowledgecenter/ es/SSWMEQ_4.0.6/com.ibm.rational.rrm.help.doc/topics/c_uc.html (visitado 05-2019). 85 REFERENCIAS [17] IBM Community. IBM Rational Software Architect Designer.url:https:/ / www.ibm.com/us-en/marketplace/rational-software-architect-designer (visitado 05-2019). [18] IBM Community. Diagramas de secuencia y caso de uso de Rational DOORS. url:https://www.ibm.com/support/knowledgecenter/es/SSQQC5_6.0.0/ com.ibm.rational.sse.doc/topics/rhp_c_int_doors_uc_seq_diags.html (visitado 05-2019). [19] Unified Modeling Language 2.0. UML.url:https://www.omg.org/spec/UML/ 2.5.1/PDF (visitado 05-2019). [20] Ivar Jacobson. Object-oriented software engineering: a use case driven approach. Addison-Wesley, 1992. [21] Wayne W Eckerson. “Three tier client/server architecture: Achieving scalability, performance and efficiency in client server applications”. En: Open Information Systems 10.1 (1995). [22] Maximiliano Cristi´a. “Introducci´on al testing de software”. En: Recuperado el 14 (2009). [23] Per Runeson. “A survey of unit testing practices”. En: IEEE software 23.4 (2006), p´ags. 22-29. [24] Mocha Community. Mocha.url:https://mochajs.org/ (visitado 05-2019). [25] Martyn A Ould y Charles Unwin. Testing in software development. Cambridge University Press, 1986. [26] Manuel Cillero. Pruebas del Sistema.url:https://manuel.cillero.es/doc/ metrica-3/tecnicas/pruebas/sistema/ (visitado 05-2019). [27] Roy Miller y Christopher T Collins. “Acceptance testing”. En: Proc. XPUniverse 238 (2001). [28] Wikiversidad. Gesti´on de riesgos de proyectos software.url:https : / / es . wikiversity.org/wiki/Gesti%C3%B3n_de_riesgos_de_proyectos_software# Estrategia_reactiva (visitado 05-2019). [29] Scott Thompson. “Difference Between a Proactive & a Reactive Business Strategy”. En: Houston Chronicle (2015). [30] Judith A Clapp y col. Software Quality Control, Error, Analysis. William Andrew, 1995. [31] Ankunda R Kiremire. “The application of the pareto principle in software engineering”. En: Consulted January 13 (2011), p´ag. 2016. url:http://www2. latech.edu/~box/ase/papers2011/Ankunda_termpaper.PDF. [32] Ken Schwaber. “Scrum development process”. En: Business object design and implementation. Springer, 1997, p´ags. 117-134. [33] Leslie Lamport. LATEX: a document preparation system: user’s guide and reference manual. Addison-wesley, 1994. 86 REFERENCIAS [34] Bizagi Modeler: Software de modelamiento de procesos de negocios (BPM).url: https://www.bizagi.com/es/productos/bpm-suite/modeler. 87