Calculadora personal online de horarios para los alumnos

Escuela de Ingenier´ıa Inform´atica TRABAJO FIN DE GRADO Grado en Ingenier´ıa Inform´atica Menci´on Ingenier´ıa de Software Calculadora personal online de horarios para los alumnos Autor: Miguel Rojo Revenga 2 Escuela de Ingenier´ıa Inform´atica TRABAJO FIN DE GRADO Grado en Ingenier´ıa Inform´atica Menci´on Ingenier´ıa de Software Calculadora personal online de horarios para los alumnos Autor: Miguel Rojo Revenga Tutor: Dr. Joaqu´ın Adiego Rodr´ıguez A quienes creyeron. I II AGRADECIMIENTOS Agradecimientos A mi familia, porque sin su ayuda y confianza no habr´ıa llegado hasta aqu´ı. A mi pareja, Noelia, porque sin ella esto no ser´ıa posible. A los profesores y profesoras que me han ense˜nado tanto a lo largo de estos a˜nos en la universidad. A Yania y a Carmen, por haber confiado en m´ı y descubrirme el maravilloso mundo de la ense˜nanza, y por estar pendientes de que terminara este trabajo de manera continua. A mi tutor Joaqu´ın, por aguantar todas las idas y venidas de este proyecto y haberme ayudado y apoyado siempre. III IV AGRADECIMIENTOS Resumen Los estudiantes universitarios se matriculan todos los a˜nos en diferentes asignaturas, eligiendo entre los grupos de clase que se ofertan. A la hora de realizar esa elecci´on muchas veces no se analizan posibles coincidencias horarias, dando lugar a situaciones en las que los alumnos dejan de asistir a determinadas horas de clase desde el principio del curso. Esta ausencia a las clases presenciales es uno de los factores que influyen negativamente en el rendimiento acad´emico. El objetivo de este trabajo es desarrollar una aplicaci´on web que sirva de herramienta para evitar ese abandono de asignaturas. La herramienta se encargar´a de calcular todas las combinaciones posibles y los estudiantes obtendr´an un horario con el menor n´umero de horas solapadas y lo m´as compacto posible. V 5.2. Arquitectura en tres capas de la aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.3. Capa de presentaci´on de la aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.4. Capa de negocio de la aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.5. Capa de persistencia de la aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.6. StackdeSpringFramework.......................................... 51 5.7. Flujo de trabajo del procesamiento de peticiones en Spring Web MVC a alto nivel. . . . . . . . . . . 52 5.8. Relaci´on de componentes en el patr´on Modelo-Vista-Controlador. . . . . . . . . . . . . . . . . . . . . 53 5.9. Ejemplo de diagrama de patr´on DAO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.10. Ejemplo de funcionamiento del patr´on Template para Spring JdbcTemplate. . . . . . . . . . . . . . . 55 5.11. Diagrama de despliegue remoto de la aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.12. Diagrama de despliegue local de la aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.13. Modelo Entidad-Relaci´on de la aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.14. Modelo relacional de la base de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 6.1. Interfaz del usuario desde un navegador Firefox. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 6.2. Interfaz del usuario desde un iPad y un navegador Safari. . . . . . . . . . . . . . . . . . . . . . . . . 65 6.3. Interfaz del usuario desde un navegador de un smartphone Android. . . . . . . . . . . . . . . . . . . 65 6.4. Interfaz del usuario de la pantalla horario reducida horizontalmente. . . . . . . . . . . . . . . . . . . 66 6.5. Ejemplo de panel utilizado para operaciones habituales. . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.6. Ejemplo de panel utilizado para operaciones de edici´on. . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.7. Ejemplo de panel utilizado para operaciones de borrado. . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.8. C´odigo de ejemplo validaci´on de campos correspondiente al formulario de registro. . . . . . . . . . . 69 6.9. C´odigo de la b´usqueda din´amica en la tabla de Asignaturas. . . . . . . . . . . . . . . . . . . . . . . . 70 6.10. C´odigo para obtener los horarios en formato PDF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.11. Ejemplo de c´alculo del grado de compactaci´on de un horario. . . . . . . . . . . . . . . . . . . . . . . 72 6.12. Script de creaci´on de la base de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 A.1. P´agina de bienvenida de la aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 A.2. Panel de administraci´on de la aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 A.3. P´agina de gesti´on de titulaciones de la aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 A.4. Formulario de la p´agina de edici´on de titulaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 A.5. Formulario de la p´agina de borrado de titulaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 A.6. Formulario de la p´agina de vista de titulaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 A.7. P´agina de gesti´on de asignaturas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 A.8. Formulario de la p´agina de edici´on de asignatura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 A.9. Formulario de la p´agina de borrado de asignatura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 A.10.Formulario de la p´agina de vista de asignatura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 XII A.11.P´agina de gesti´on de grupos de la aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 A.12.Formulario de la p´agina de edici´on de grupo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 A.13.Formulario de la p´agina de borrado de grupo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 A.14.Formulario de la p´agina de vista de grupo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 A.15.Panel del estudiante en la aplicaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 A.16.Formulario de selecci´on de titulaci´on y periodo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 A.17.Formulario de selecci´on de asignaturas para el c´alculo de horarios. . . . . . . . . . . . . . . . . . . . 97 A.18.P´aginadehorariogenerado.......................................... 97 A.19.Operaciones adicionales de la p´agina de horario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 A.20.P´agina de horarios guardados del estudiante. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 A.21.Formulariodeajustesdeperfil. ....................................... 99 XIII XIV ´ INDICE DE TABLAS ´ Indice de tablas 2.1. Tabla resumen de la evoluci´on del n´umero de grupos en algunas asignaturas del Grado en Ingenier´ıa Inform´atica de la Universidad de Valladolid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Distribuci´on del horario de trabajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2. ProductBacklogdelproyecto......................................... 23 3.3. Planificaci´on temporal del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4. Sprint Backlog e informaci´on de seguimiento del primer sprint. ..................... 25 3.5. Sprint Backlog e informaci´on de seguimiento del segundo sprint. .................... 27 3.6. Sprint Backlog e informaci´on de seguimiento del tercer sprint....................... 28 3.7. Sprint Backlog e informaci´on de seguimiento del cuarto sprint. ..................... 29 3.8. Sprint Backlog e informaci´on de seguimiento del quinto sprint. ..................... 30 3.9. Sprint Backlog e informaci´on de seguimiento del cuarto sprint. . . . . . . . . . . . . . . . . . . . . . 31 4.1. Modelo de tarjeta para las historias de usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.2. HistoriadeusuarioHU01........................................... 41 4.3. HistoriadeusuarioHU02........................................... 41 4.4. HistoriadeusuarioHU03........................................... 41 4.5. HistoriadeusuarioHU04........................................... 42 4.6. HistoriadeusuarioHU05........................................... 42 4.7. HistoriadeusuarioHU06........................................... 42 4.8. HistoriadeusuarioHU07........................................... 43 6.1. Informaci´on del servidor Tomcat utilizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.2. Informaci´on del servidor Tomcat utilizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.3. Plantilla utilizada para documentar las pruebas realizadas. . . . . . . . . . . . . . . . . . . . . . . . . 74 XV XVI CAP´ ITULO 1. INTRODUCCI ´ ON Cap´ıtulo 1 Introducci´on 1.1. Contexto Hoy en d´ıa no es raro encontrar algunas titulaciones en la Universidad en las que en ciertas asignaturas hay una cantidad elevada de estudiantes matriculados. Independientemente de las causas de esta situaci´on, muchas facultades, centros y escuelas universitarias se ven obligadas a crear m´ultiples grupos, tanto de teor´ıa como de pr´acticas y/o laboratorios a la hora de configurar los horarios lectivos de cada curso y cuatrimestre. Esta situaci´on se debe, entre otros factores, a que muchos de los alumnos y alumnas que se matriculan en dichas asignaturas lo hacen porque no las superaron en cursos pasados y, adem´as de en estas, se matriculan de otras de cursos diferentes. El resultado es que muchos de esos estudiantes que se matriculan en asignaturas de diferentes cursos o que combinan grupos entre asignaturas del mismo curso, lo hacen renunciando desde el primer d´ıa a la asistencia a dichas clases sin detenerse a evaluar las alternativas que tienen para dise˜nar un horario en el que no se produzcan solapamientos de horas de clase o en el que los solapamientos sean m´ınimos. El hecho de no asistir a horas de clase se ha relacionado con el fracaso escolar y el rendimiento acad´emico, demostrando que la asistencia regular a clase favorece la obtenci´on de mejores resultados por parte de los estudiantes. 1.2. Motivaci´on La motivaci´on para desarrollar este proyecto surge de la experiencia personal dise˜nando m´ultiples combinaciones de horarios de clase antes de realizar la matr´ıcula en mis ´ultimos a˜nos como estudiante del Grado de Ingenier´ıa Inform´atica en la Universidad de Valladolid, en los que he compatibilizado estudios en asignaturas de diferentes cursos con otras actividades. De esa experiencia personal tambi´en he podido llegar a la conclusi´on de que la m´ıa no era una situaci´on excepcional, y que hab´ıa compa˜neros y compa˜neras que lidiaban con la misma problem´atica en cada per´ıodo de matr´ıcula. Adem´as, a todo ello se le une el hecho de que no se ha encontrado en el mercado ninguna herramienta que ofrezca la automatizaci´on en el proceso de elecci´on de grupos que aqu´ı se pretende desarrollar. 1 1.3. Objetivos El principal objetivo del presente Trabajo de Fin de Grado es desarrollar una aplicaci´on web que permita a los usuarios obtener de manera autom´atica los horarios de clase en los que se produzcan menos solapamientos de horas entre clases de diferentes asignaturas. A partir de ese objetivo principal surgen otros de car´acter secundario, como son: Ser capaz de analizar un problema real y de dise˜nar una soluci´on ´optima. Aprender a planificar un proyecto de desarrollo de software. Familiarizarse con la metolodolog´ıa de trabajo Scrum. Afianzar conocimientos de desarrollo en Java y aprender a utilizar uno de los frameworks existentes asociados a dicho lenguaje. Ampliar los conocimientos adquiridos de desarrollo web para dise˜nar una aplicaci´on cuya interaz sea f´acil de usar y su dise˜no sea adaptativo. Por ´ultimo se busca alcanzar los objetivos fijados en el apartado 3 del Proyecto Docente de Trabajo de Fin de Grado para la menci´on de Ingenier´ıa del Software [1] y que son los siguientes: Buscar, ordenar, analizar y estructurar la informaci´on para desarrollar una aplicaci´on inform´atica. Trabajar asumiendo diferentes roles. Elaborar una memoria del proyecto desarrollado que incluya el contexto en el que se realiza, los objetivos, la metodolog´ıa de trabajo, informaci´on sobre el proceso de an´alisis y dise˜no, conclusiones y l´ıneas de trabajo futuras. En ´ultimo t´ermino plantear y defender una presentaci´on p´ublica del trabajo realizado. 1.4. Estructura del documento La estructura de la memoria, a partir de este apartado, se detalla a continuaci´on. En el segundo cap´ıtulo se presenta el contexto actual desde dos puntos de vista. Por un lado analizando la relaci´on entre el rendimiento acad´emico y la asistencia a clase, y por otro, presentando un breve an´alisis que se ha realizado sobre algunas de las aplicaciones que se pueden encontrar hoy en d´ıa y que permiten calcular horarios de manera autom´atica. Tambi´en se incluye una breve rese˜na sobre desarrollo web. El tercer cap´ıtulo incluye todo lo relativo a la planificaci´on del proyecto, la metodolog´ıa utilizada y un apartado de seguimiento del proyecto. En el cuarto cap´ıtulo se puede encontrar informaci´on sobre la fase de an´alisis del problema al que se trata de dar una soluci´on y que constituye una de las partes m´as importantes de este trabajo. El quinto cap´ıtulo hace referencia a la fase de dise˜no de la aplicaci´on. El sexto cap´ıtulo detalla la implementaci´on de la aplicaci´on, incluyendo las tecnolog´ıas utilizadas y las pruebas realizadas. 2 En el s´eptimo cap´ıtulo se pueden encontrar las conclusiones obtenidas como resultado de la realizaci´on del Trabajo Fin de Grado respectivamente y algunas l´ıneas de trabajo futuro que se han planteado en relaci´on al presente proyecto. Por ´ultimo se encuentran un cap´ıtulo de referencias en el que se incluyen todos los recursos consultados y siguiendo la notaci´on IEEE, y los ap´endices, que son los siguientes: Ap´endice A Manual de usuario. Ap´endice B Contenido del CD-ROM. 3 4 CAP´ ITULO 2. CONTEXTO Cap´ıtulo 2 Contexto En este cap´ıtulo se describir´a el contexto actual en el que se plantea el desarrollo de una calculadora online de horarios para los alumnos. Se ha realizado primero un breve an´alisis sobre la relaci´on entre asistencia a clase y el rendimiento acad´emico prestando especial atenci´on a las situaciones de solapamiento de clases. En una segunda parte del cap´ıtulo se han buscado, probado y analizado algunas de las herramientas que se han encontrado en el mercado y que guardan similitudes con la aplicaci´on que se pretende desarrollar. 2.1. Asistencia a clase y rendimiento acad´emico Dado que uno de los objetivos marcados para el desarrollo de este trabajo era el de intentar facilitar a los alumnos la posibilidad de asistir al mayor n´umero de clases posibles de las asignaturas que est´en cursando, parece apropiado realizar un breve an´alisis de la asistencia a clase como factor a tener en cuenta en el rendimiento acad´emico de los estudiantes. Este tema se ha intentado explicar a trav´es de diferentes estudios, analizando multitud de conjuntos de datos y atendiendo a diferentes variables. La asistencia a clase aparece una y otra vez como una de esas variables, y lo hace como una de las m´as relevantes en muchos casos. Tal y como se explica en [2] el bajo rendimiento acad´emico es un problema social cuyos efectos podr´ıan mitigarse poniendo medios que redujesen el fracaso en la etapa universitaria. En dicha publicaci´on se analiza el impacto de diferentes variables en el rendimiento acad´emico universitario, y se llega a la conclusi´on de que para la aproximaci´on planteada, la asistencia regular a las clases es una de las primeras variables en importancia, por delante de otras como por ejemplo el nivel de satisfacci´on de los estudiantes ante la carrera elegida o el rendimiento acad´emico en cursos inferiores. En [3] se presenta la idea de que para una implantaci´on exitosa del EEES ser´a necesario el desarrollo de estrategias de motivaci´on para que aumente el porcentaje de asistencia a las clases. Todo ello para seguir las asignaturas a trav´es de una evaluaci´on continuada, siguiendo la estructura fijada en el EEES. En sus conclusiones constatan que la asistencia a clase influye en los resultados obtenidos por los estudiantes. Se puede concluir hasta este punto que el absentismo de los estudiantes universitarios es un problema relevante en la sociedad actual. Los motivos de ese absentismo son muy diversos y en [4] se plantean algunos como pueden ser que se considera que la clase presencial no aporta valor, el/la profesor/a de la asignatura, la proximidad de alguna entrega o examen, la posibilidad de seguir la asignatura mediante el uso de diapositivas y/o libros o el solapamiento de horarios con otras asignaturas. 5 Figura 2.8: Captura de pantalla de la vista de un horario con restricciones ignoradas de la herramienta ascHorarios. Free Timetabling Software Free Timetabling Software (FET) es un software de c´odigo abierto para planificar de manera autom´atica los horarios de colegios, institutos y/o universidades. En su p´agina web [12] informan de que la herramienta es capaz de generar horarios de complejidad normal en tiempos de 5 a 20 minutos. Para casos de extrema dificultad puede tener que estar ejecut´andose durante horas. Se trata de una aplicaci´on que se ejecuta de manera local y permite exportar los resultados a diferentes formatos como por ejemplo HTML, XML y CSV. La ´ultima versi´on del software (FET-5.37.5) fue lanzada el 10 de enero de 2019. A continuaci´on se muestran algunas capturas de pantalla obtenidas de la propia p´agina web del proyecto y que est´a accesible desde su p´agina web. Figura 2.9: Captura de pantalla del men´u principal de la herramienta FET. 12 Figura 2.10: Captura de pantalla del men´u para a˜nadir una actividad de la herramienta FET. Figura 2.11: Captura de pantalla del men´u de restricciones aplicables a alumnos de la herramienta FET. 13 Figura 2.12: Captura de pantalla de la vista de horarios de profesores de la herramienta FET. Figura 2.13: Captura de pantalla de la vista de horarios de estudiantes de la herramienta FET. 2.3. Desarrollo web Aunque es verdad que hoy en d´ıa la mayor´ıa de aplicaciones que se desarrollan son para entornos m´oviles, principalmente para dispositivos con sistema operativo iOS o Android, no es menos cierto que se siguen desarrollando muchas aplicaciones web. 14 El principal motivo de elegir este tipo de desarrollo es que se tiene la percepci´on de que los estudiantes formalizan su matr´ıcula en la universidad en ordenadores m´as que en dispositivos m´oviles. Adem´as las aplicaciones web cuentan con una serie de ventajas sobre las aplicaciones m´oviles: No requieren instalaci´on por parte de los usuarios, ya que est´a alojada en un servidor. Lo ´unico que necesita el usuario es un navegador. Se pueden ejecutar tanto en ordenadores como en otros dispositivos como tablets o smartphones. El desarrollo suele ser m´as r´apido que en aplicaciones m´oviles. Las actualizaciones se realizan m´as r´apido, ya que no se depende de versiones de dispositivos ni sistemas operativos. 15 16 CAP´ ITULO 3. PLANIFICACI ´ ON Cap´ıtulo 3 Planificaci´on 3.1. Prop´osito y alcance El principal prop´osito del proyecto es desarrollar un sistema que permita a los estudiantes universitarios obtener el horario con menos solapamiento de clases y m´as compacto posible a partir de las asignaturas que ellos o ellas elijan. La aplicaci´on permitir´a elegir la titulaci´on, el per´ıodo o semestre y las asignaturas para las que se quiere calcular el horario y generar´a la mejor opci´on posible priorizando que no haya conflictos horarios y que sea lo m´as compacto posible, es decir, que haya las menos horas libres posibles entre varias clases en una misma ma˜nana o tarde. Se plantea que la aplicaci´on permita diferentes operaciones, dependiendo del rol del usuario que acceda al sistema, as´ı tendremos: Administrador de la aplicaci´on •Gestionar las titulaciones, asignaturas y grupos de la aplicaci´on. Estudiante •Registrarse en el sistema y acceder a ´el. •Gestionar su perfil en la aplicaci´on. •Generar el mejor horario posible atendiendo a la selecci´on de asignaturas realizada. •Guardar los horarios generados. •Gestionar los horarios que tiene guardados. •Descargar en formato PDF los horarios generados. 3.2. Metodolog´ıa Desde un principio se consider´o la necesidad de darle al proyecto un enfoque de desarrollo ´agil que permitiese flexibilidad y facilidad de organizaci´on. Al tratarse de un producto del que no se tienen referencias previas, y que es muy posible que se introduzcan cambios durante el proceso de desarrollo, el hecho de elegir una metodolog´ıa de 17 este tipo nos permitir´a hacerlo sin que sea traum´atico para el desarrollo normal del trabajo. Adem´as, esto permitir´a al equipo desarrollar un producto que se parezca m´as a lo que el cliente necesita. De las estrategias de desarrollo ´agil la elegida ha sido Scrum por considerar que es f´acilmente adaptable a las necesidades del proyecto. No se utilizar´a de manera estricta, sino que se utilizar´an algunos de los elementos y t´ecnicas que establece para el desarrollo del proyecto. 3.2.1. Scrum En los pr´oximos apartados se presenta informaci´on relativa a Scrum y al final de cada uno se har´a un apunte sobre los elementos que se van tomando o descartando de este marco de trabajo. Qu´e es Scrum nace como una estrategia de desarrollo de producto ´agil en la que el equipo de desarrollo trabaja como una unidad para alcanzar un objetivo com´un [13]. A˜nos m´as tarde, en 1995, Ken Schwaber y Jeff Sutherland adaptan dicha estrategia como procedimiento de desarrollo de software y en la ´ultima gu´ıa que publican de Scrum ([14]) lo definen de la siguiente forma: “Scrum es un marco de trabajo a trav´es del cual las personas pueden abordar problemas complejos adaptativos, a la vez que se entregan productos de forma eficiente y creativa con el m´aximo valor”. Scrum plantea una forma de organizarse y trabajar cuyo principal elemento es el equipo que realiza el trabajo. Dot´andole de herramientas y libertad para autoorganizarse se busca promover al equipo, pero tambi´en a los individuos que lo integran y conseguir as´ı un trabajo final de calidad. Caracter´ısticas Tal y como se menciona en [15], para conseguir el ´exito en el desarrollo de productos Scrum propone una serie de principios que deben cumplir las personas que participan en el proyecto as´ı como el propio proyecto. Son los siguientes: Satisfacci´on del cliente: es lo que se busca en ´ultimo t´ermino, que el cliente est´e contento con el producto que recibe y que sea exactamente lo que desea. Respuesta al cambio: los eventos que propone Scrum, as´ı como sus artefactos y la forma de organizar el trabajo permiten responder a los cambios de manera normal y sin provocar grandes prejucios en el trabajo desarrollado. Equipos autoorganizados: se funciona como un equipo a todos los niveles, y esto permite que se pueda hacer frente a las diferentes tareas, asumiendo cada miembro los aspectos necesarios para completar el trabajo. Simplicidad: hace referencia a que s´olo es necesario centrarse en las posibles necesidades del cliente, sin pensar en funcionalidades o incrementos del producto que, aun aport´andole valor, no vayan a ser utilizados por el cliente. Desarrollo incremental: el desarrollo es incremental desde el primer momento permitiendo ofrecerle al cliente un producto m´ınimo viable desde las primeras iteraciones. Se trata de que al final de cada ciclo del proceso que se sigue, se le ofrezca al cliente un producto susceptible de desplegarse. 18 Trabajo enfocado en el producto: la finalidad es desarrollar un producto ´util de calidad por encima de los procesos o m´etodos empleados para hacerlo. El proceso El proceso se suele llevar a cabo en per´ıodos cortos de tiempo que van de 1 a 4 semanas y cuya duraci´on suele ser fija, aunque por necesidades del proyecto puede adaptarse. Al final de cada iteraci´on hay que disponer de un producto final susceptible de ser entregado al cliente y que incremente el valor sobre lo entregado anteriormente. Una representaci´on gr´afica del proceso puede verse en la Figura 3.1, obtenida de [16]. Figura 3.1: Diagrama del ciclo de vida de un proyecto en Scrum. Lo primero que tiene que producirse es la definici´on del Product Backlog por parte del product owner. Se a˜naden las historias de usuario, que vienen a representar funcionalidades que se desea que tenga el producto final. Despu´es se pasa a las fases denominadas sprints, en las que el equipo decide qu´e historias de usuario de las definidas en el Product Backlog se a˜naden al spring backlog. En ese momento el equipo de desarrollo define tareas para completar el sprint. Durante la duraci´on del sprint, y con frecuencia diaria, se llevan a cabo reuniones (daily meetings) en las que se analiza el estado de las tareas asignadas. Al final de cada sprint debe tenerse un producto con un incremento funcional con respecto a la anterior versi´on y que debe ser f´acilmente puesto en producci´on si as´ı se desea. Para el proyecto que se va a desarrollar se seguir´a el proceso marcado por Scrum con alguna de las caracter´ısticas adaptadas a las necesidades del proyecto: En primer lugar los sprints tendr´an una duraci´on de dos semanas. El trabajo no ser´a uniforme todos los d´ıas, ya que la situaci´on laboral del autor de este trabajo lo impide. S´ı se ha fijado un ritmo de trabajo de 25 horas semanales distribuidas de la siguiente manera: D´ıa de la semana Lunes Martes Mi´ercoles Jueves Viernes S´abado Domingo Horas de trabajo 5 2 2 3 3 5 5 Tabla 3.1: Distribuci´on del horario de trabajo. No se realizar´an los daily meetings ya que hay d´ıas en los que el trabajo va a ser escaso y no se considera que dichas reuniones vayan a ser muy productivas. 19 Roles Definen el conjunto de responsabilidades que es necesario asumir en un proyecto que siga el marco de trabajo Scrum. En su conjunto garantizan cubrir las necesidades del proyecto a nivel de informaci´on, desarrollo y comunicaci´on. Los roles propuestos son los siguientes: Product Owner: se trata de la persona que act´ua de itnermediario entre el equipo de desarrollo y el cliente. Es el responsable del ´exito o fracaso del proyecto en ´ultimo t´ermino. Sus principales funciones son: •Negociar con el cliente el alcance del proyecto. •Definir la estrategia y objetivos. •Definir y mantener el Product Backlog. •Ayudar al Scrum Master y al Development Team a resolver cualquier duda o problema que tenga que ver con el proyecto, el producto y su funcionalidad. Scrum Master: es el/la responsable de que los valores, reglas y pr´acticas de Scrum se lleven a cabo de manera adecuada. Tiene especial relevancia en gestionar las interacciones dentro del equipo para maximizar el valor creado. Aunque suele dar lugar a confusi´on hay que indicar que no es el project manager y no cumple sus deberes ni asume sus obligaciones. Puede darse el caso de que sea un desarrollador del Development Team, pero una persona nunca puede ser al mismo tiempo y en un mismo proyecto Scrum Master yProduct Owner. Development Team: es el equipo de desarrollo y lo componen las personas encargadas de trabajar en los incrementos de producto que se producen a lo largo del ciclo de vida de Scrum. Asume la responsabilidad de gestionar el spring backlog, determinando el detalle de cada elemento del Product Backlog y dividi´endolo en la tareas que considere. Es responsable de entregar el producto terminado y de que este cumpla con los criterios de aceptaci´on marcados. Se recomienda que est´e formado por entre tres y nueve personas. Para lograr el ´exito debe cumplir las siguientes caracter´ısticas: •Ser flexible: cada persona puede ocupar varios roles. •Estar autoorganizado: el mismo equipo define sus m´etodos de trabajo. •Ser multidisciplinario: el conjunto del equipo cuenta con la capacidad para hacer frente al proyecto con garant´ıas. Para el desarrollo del proyecto se ha decidido asignar los roles de la siguiente manera: Product Owner: estar´a representado por Joaqu´ın Nicol´as Adiego, tutor de este Trabajo de Fin de Grado y actuar´a como cliente. Scrum Master: ser´a Miguel Rojo y se encargar´a de intentar eliminar los obst´aculos que impidan alcanzar los objetivos de cada sprint, adem´as de velar por que se sigan las t´ecnicas y gu´ıas que se consideren de Scrum. Development Team: estar´a formado s´olo por una persona, Miguel Rojo, como el responsable de desarrollar el producto. Artefactos Representan las herramientas que propone Scrum para maximizar la transparencia de la informaci´on y que todo el equipo tenga una visi´on ´unica del producto que se quiere conseguir. Ayuda a los diferentes roles a coordinarse y trabajar juntos. 20 Hay diversidad de opiniones sobre lo que se consideran artefactos en Scrum, pero aqu´ı s´olo se detallan los m´as habituales y que aparecen en la Gu´ıa de Scrum ([14]) como artefactos propios del marco de trabajo: Product Backlog: es la lista de funcionalidades que deber´a tener el producto que se va a desarrollar y est´an representadas en forma de historias de usuario. Las caracter´ısticas que debe tener se pueden resumir en las siguientes (obtenidas a partir de [17]): •Detallado: las historias del Product Backlog tienen que estar descritas en lenguaje que el cliente entienda, pero con el suficiente nivel de detalle como para que se puedan estimar y priorizar. •Estimado: las historias de usuario tienen que est´ar estimadas de alguna forma que permita al equipo saber el esfuerzo que le requerir´a completarlas. •Priorizado: las historias de usuario tienen que est´ar priorizadas para determinar el orden en el que se completar´an. •Din´amico: las historias de usuario pueden eliminarse o a˜nadirse a medida que avance el proyecto. Adem´as son susceptibles de ser estimadas y priorizadas de nuevo en cualquier momento del ciclo de vida de Scrum. Sprint Backlog: se define al principio del spring y es la lista de funcionalidades que se saca del product backlog que se llevar´an a cabo durante el sprint. Tiene las mismas caracter´ısticas que se han indicado para el product backlog. La lista de funcionalidades elegidas tiene que adaptarse a la velocidad del equipo, y en caso de no se posible se pueden dividir esas funcionalidades. Incremento: est´a compuesto por las historias de usuario completadas durante un sprint y el valor del incremento de los sprints anteriores. Representa el estado mejorado del producto tras el sprint y debe est´ar en condiciones de utilizarse sin importar si se decide sacar a producci´on o no. Para el proyecto a desarrollar se decide utilizar los tres artefactos que se acaban de definir, un product backlog con la lista de funcionalidades del producto y que se definir´a al comienzo del proyecto, los sprint backlogs correspondientes a cada uno de los sprints del proyecto y que se definir´an al comienzo de cada uno, y los incrementos que ser´an las historias de usuario completadas en cada sprint, y adem´as se utilizar´a uno m´as denominado Sprint Burndown. Este artefacto consiste en una gr´afica que se actualiza diariamente y que tiene dos m´etricas: la previsi´on de horas que va a conllevar el sprint y la cantidad real de horas consumidas en dicho periodo. Eventos Son hitos o momentos en los que hay que ejecutar alguna acci´on relevante para el proyecto. Est´an predefinidos, tienen una duraci´on m´axima y el objetivo es crear cierta regularidad. Se trata de evitar tener que llevar a cabo reuniones que no est´en definidas. Es f´acil encontrar diferentes gu´ıas o manuales en los que aparecen unos eventos u otros. Aqu´ı se exponen los que aparecen en la Gu´ıa de Scrum ([14]): Sprint: es la unidad de tiempo que determina un ciclo de desarrollo en Scrum. Se debe crear un incremento sobre el producto que sea utilizable y potencialmente desplegable al final del sprint. Durante este intervalo de tiempo tienen lugar otros de los eventos m´as relevantes, como son el sprint planning, los daily scrums odaily meetings, el sprint review y un sprint retrospective. Sprint Planning: es la reuni´on de planificaci´on del sprint en la que se determina el trabajo a realizar y tiene lugar siempre al inicio del sprint. 21 capa de persistencia. Aunque no se ha incluido de manera expl´ıcita en la Tabla 3.6, la primera tarea de este sprint incluy´o el cambio de la p´agina de inicio de la aplicaci´on. Tras la reuni´on con el tutor previa al desarrollo del sprint, y teniendo en cuenta que el uso de la aplicaci´on implica estar registrado en el sistema, se decide incluir informaci´on en la propia p´agina de inicio que facilite dicha informaci´on al usuario. ID HU Tarea Estimaci´on (horas) Tiempo real (horas) Desviaci´on HU03 Programaci´on UI 10 8 -2 HU03 Programaci´on negocio 15 30 +15 HU03 Programaci´on persistencia 15 22 +7 HU03 Pruebas 5 6 +1 HU03 Documentaci´on 5 6 +1 Totales 50 72 +22 Tabla 3.6: Sprint Backlog e informaci´on de seguimiento del tercer sprint. Las estimaciones realizadas fueron muy malas, desvi´andose m´as de un 40 % al final del sprint. Los principales problemas que se encontraron fueron los que se preve´ıa, pero de mayor magnitud. La dificultad de la programaci´on de la l´ogica provoc´o que se reconsiderara el modelo planteado en la fase de an´alisis y se realizaron algunos cambios. Esto retras´o bastante el desarrollo, tal y como se puede ver en la Tabla 3.6. Lo recomendable hubiera sido negociar de nuevo el sprint con el product owner, pero se toma la decisi´on de invertir m´as horas en los ´ultimos d´ıas del sprint con el objetivo de completar todas las tareas. Esto se ve claramente en la Figura 3.4, donde a partir del d´ıa 8 se empieza a reducir dr´asticamente la diferencia entre horas estimadas restantes y horas reales restantes. Figura 3.4: Burndown del tercer sprint. Cuarto sprint En este sprint se van a completar las historias de usuario referentes a que el usuario guarde sus horarios y los exporte en diversos formatos. Como se puede ver en la Tabla 3.7 las tareas de programaci´on de la l´ogica de negocio 28 son las m´as relevantes, ocupando entre las dos la mitad del tiempo estimado para completar el sprint. El resto de tareas, teniendo en cuenta que algunas son similares a las de anteriores sprints y que hay cosas que se pueden reutilizar, tienen valores bajos, y como se puede ver en la misma tabla en varias de ellas el tiempo real empleado fue menor que el estimado inicialmente. ID HU Tarea Estimaci´on (horas) Tiempo real (horas) Desviaci´on HU04 Programaci´on UI 2 3 +1 HU04 Programaci´on negocio 10 12 +2 HU04 Programaci´on persistencia 5 3 -2 HU04 Pruebas 3 3 0 HU04 Documentaci´on 3 3 0 HU05 Programaci´on UI 2 1 -1 HU05 Programaci´on negocio 10 8 -2 HU05 Pruebas 2 2 0 HU05 Documentaci´on 3 2 -1 Totales 40 37 -3 Tabla 3.7: Sprint Backlog e informaci´on de seguimiento del cuarto sprint. La historia de usuario HU04, con peque˜nas desviaciones en algunas tareas, se completo tal y como estaba previsto. En cuando a la historia de usuario HU05 se complet´o en 4 horas menos de las 17 estimadas, es decir, aproximadamente se complet´o en un 75 % del tiempo que se hab´ıa previsto, haciendo de nuevo las estimaciones iniciales malas. Esto se debe a que al final el uso de librer´ıas externas para exportar los documentos a formato PDF no result´o tan complicado como se esperaba, y tras probar diferentes opciones se escogi´o la que mejor se adaptaba al proyecto. Figura 3.5: Burndown del cuarto sprint. La Figura 3.5 muestra que, hasta el momento, el cuarto sprint ha sido el que m´as se ha ajustado a las estimaciones iniciales, aunque terminara un d´ıa antes de lo previsto. 29 Quinto sprint En el quinto sprint se va a completar la historia de usuario HU07, que hace referencia a las tareas de administraci´on de la aplicaci´on web. Se hicieron estimaciones teniendo en cuenta que habr´ıa que hacer el trabajo para administrar titulaciones, asignaturas y grupos. ID HU Tarea Estimaci´on (horas) Tiempo real (horas) Desviaci´on HU07 Programaci´on UI 14 17 +3 HU07 Programaci´on negocio 20 24 +4 HU07 Programaci´on persistencia 5 3 -2 HU07 Pruebas 5 7 +2 HU07 Documentaci´on 5 3 -2 Totales 49 54 +5 Tabla 3.8: Sprint Backlog e informaci´on de seguimiento del quinto sprint. Como se desprende de la Tabla 3.8 en este quinto sprint tampoco fueron buenas las estimaciones, y terminaron dedic´andose m´as horas de las establecidas para completarlo, como ya sucediera en el segundo y tercer sprint. Tan solo se pudo recuperar parte del tiempo en tareas que fueron muy parecidas a las de sprints anteriores. Figura 3.6: Burndown del quinto sprint. La Figura 3.6 muestra lo comentado anteriormente sobre que es s´olo al final del sprint cuando se consigue igualar el trabajo restante estimado con el real. Para tener una visi´on global de lo que ha sido la evoluci´on del trabajo en horas y las variaciones que se produjeron sobre las estimaciones realizadas se presentan la Tabla 3.9 y la Figura 3.7. 30 NoSprint Estimaci´on (horas) Tiempo real (horas) Desviaci´on sprint Desviaci´on acumulada Sprint 1 50 42 -8 -8 Sprint 2 45 44 -1 -9 Sprint 3 50 72 +22 +13 Sprint 4 40 37 -3 +10 Sprint 5 49 54 +5 +15 Totales 234 249 - +15 Tabla 3.9: Sprint Backlog e informaci´on de seguimiento del cuarto sprint. En la tabla se puede observar que al final del proyecto se tiene una desviaci´on de 15 horas sobre lo estimado inicialmente, aproximadamente un 6 % de la duraci´on que se preve´ıa. Figura 3.7: Desviaciones sobre las estimaciones realizadas. Y en la figura se comprueba que s´olo hubo dos sprints de los cinco que se acercaron realmente al n´umero de horas estimadas, que son el segundo y el cuarto. Adem´as la desviaci´on acumulada del proyecto nunca se acerc´o a lo que deber´ıa haber sido la evoluci´on normal, pasando de un registro positivo de 9 horas a otro ya negativo de 13 entre el segundo y tercer sprint. A modo de conclusi´on sobre el apartado de planificaci´on cabe indicar lo siguiente: Se han utilizado algunos de los elemenos m´as relevantes del marco de trabajo Scrum. Las estimaciones realizadas no han sido buenas, teniendo en todos los sprints desviaciones, y en algunos bastante importantes. Dedicando horas adicionales de trabajo se ha conseguido completar todas las tareas marcadas para cada uno de los sprints. 31 32 CAP´ ITULO 4. AN´ ALISIS DEL SISTEMA Cap´ıtulo 4 An´alisis del sistema En este cap´ıtulo se presentar´an todas las actividades correspondientes de la fase de an´alisis del proyecto. Si bien es cierto que el problema aparentemente no tiene un grado de complejidad demasiado elevado, esta fase del trabajo revel´o que ten´ıa m´as peculiaridades de las aparentaba en un principio. Por todo ello se dedic´o una cantidad de tiempo razonable al an´alisis, con el objetivo de que las decisiones tomadas fueran adecuadas y no hubiera que hacer cambios posteriores que retrasaran el desarrollo del proyecto. 4.1. Especificaci´on de la aplicaci´on Lo primero y m´as importante que se ha tenido en cuenta a la hora de desarrollar esta aplicaci´on es la normativa existente en la Universidad de Valladolid con respecto a los horarios y su distribuci´on. Si bien es cierto que algunos centros, como por ejemplo la Facultad de Educaci´on y Trabajo Social, han cerrado acuerdos a nuvel de Junta de Facultad para aprobar su propia distribuci´on horaria, ´esta se ajusta siempre a lo marcado en el Reglamento de Ordenaci´on Acad´emica de la Universidad de Valladolid [20], que establece lo siguiente en su art´ıculo 15: “Art´ıculo 15. Distribuci´on de horarios 15.1. Los estudiantes podr´an matricularse de asignaturas de cursos distintos, siempre que lo permita el plan de estudios que est´en cursando. Se facilitar´a la asistencia de los estudiantes a las actividades presenciales de car´acter obligatorio evitando, en la medida de lo posible, el solapamiento de horarios entre cursos sucesivos de la misma titulaci´on. 15.2. Las actividades docentes presenciales se distribuir´an de lunes a viernes, de 8h a 15h en horario de ma˜nana y de 15h a 22h en horario de tarde. En ambos casos, las primeras y ´ultimas horas se consideran franjas de desbordamiento y ser´an empleadas s´olo en el caso en que sea imprescindible por coherencia interna de los horarios y por disponibilidad de recursos. Las actividades presenciales, por tanto, se situar´an normalmente dentro de la franja formada por las cinco horas restantes. Excepcionalmente, podr´an proponerse actividades presenciales docentes en s´abado siempre que se justifique adecuadamente dicha propuesta.” 33 De esta normativa se han obtenido las franjas en las que las clases podr´an tener lugar. Para el trabajo que aqu´ı se presenta se han obviado las posibles actividades presenciales docentes que pudieran tener lugar en s´abado, ya que el problema que se trata de resolver es el del solapamiento de horarios y la posibilidad de que esas actividades en s´abado se solapen es demasiado remota como para ser tenida en cuenta. As´ı pues, las horas consideradas en los posibles horarios que se generar´an ser´an las comprendidas en la franja de 8 de la ma˜nana a 10 de la noche en intervalos de una hora y de lunes a viernes. Adem´as de lo establecido en la normativa vigente, la primera fase del an´alisis centrada en la b´usqueda de informaci´on proporcion´o muchos datos que incrementaron la complejidad del problema y que ser´ıan tenidos en cuenta m´as adelante. La informaci´on recopilada se resume en los siguientes puntos: En los ´ultimos a˜nos han aparecido titulaciones que se denominan “Programas de Estudios Conjunto” y que son titulaciones que est´an compuestas por asignaturas de otras dos titulaciones diferentes. Existen asignaturas que se imparten en varias titulaciones y el curso en el que se imparten var´ıa de unas a otras. Esto sucede tambi´en con asignaturas de los “Programas de Estudios Conjunto”. En el caso del Grado en Ingenier´ıa Inform´atica y del Programa de estudios conjunto de Grado en Estad´ıstica y Grado en Ingenier´ıa Inform´atica sucede con varias asignaturas. Algunos ejemplos son: •Ingenier´ıa del Conocimiento: se imparte en el cuarto curso del programa de estudios conjunto y en tercer curso del Grado en Ingenier´ıa Inform´atica (s´olo para las menciones de Ingenier´ıa del Software y Computaci´on). •Fundamentos de Ingenier´ıa del Software: se imparte en segundo curso del Grado en Ingenier´ıa Inform´atica y en el tercer curso del programa de estudios conjunto. •Sistemas Distribuidos: aparece como asignatura de segundo curso del Grado en Ingenier´ıa Inform´atica y asociada al cuarto curso del programa de estudios conjunto. Existen asignaturas que se imparten en titulaciones que constan de varias menciones. Algunas de estas asignaturas aparecen en diferentes cursos dependiendo de la asociaci´on con la menci´on correspondiente. Por ejemplo, la asignatura “Arquitectura de Redes y Servicios” del Grado en Ingenier´ıa Inform´atica est´a relacionada con la titulaci´on a trav´es de dos menciones: •Menci´on de Ingenier´ıa del Software: aparece como optativa de cuarto curso. •Menci´on en Tecnolog´ıas de la Informaci´on: aparece como optativa de tercer curso. Las asignaturas que tienen car´acter de “anuales” pueden variar la carga lectiva entre semestres y su horario tambi´en. El Reglamento de Ordenaci´on Acad´emica diferencia entre docencia te´orica y pr´actica, aunque en los horarios consultados de diferentes facultades de la Universidad de Valladolid, la diferenciaci´on es mayor, encontrando clases de los siguientes tipos: •Te´orica •Pr´actica •Seminario Algunas horas lectivas de algunas asignaturas tienen lugar s´olo en determinadas semanas y/o d´ıas. Por lo general esta caracter´ısticas se suele indicar en los horarios que publican los diferentes Centros de la Universidad de Valladolid. Adem´as, en algunos de estos casos, las fechas en las que tienen lugar esas horas lectivas vienen indicadas en los correspondientes Proyectos Docentes. 34 Aunque el Reglamento de Ordenaci´on Acad´emica lo establece en su Art´ıculo 13, “Concepto de calendario de actividades docentes”, hay centros en la Universidad de Valladolid que no establecen unos horarios de manera clara antes del primer per´ıodo de matr´ıcula. Un ejemplo de ello es la Escuela de Ingenier´ıa Inform´atica de dicha Universidad, donde existen asignaturas para las que no se publican los horarios de manera completa. Un ejemplo de ello es la asignatura de Servicios y Sistemas Web. Se puede ver en las Figuras 4.1, 4.2, 4.3. c´omo el grupo de laboratorio X3 s´olo aparece en el horario de la menci´on de Tecnolog´ıas de la Informaci´on, cuando en realidad es accesible para estudiantes de las tres menciones del Grado en Ingenier´ıa Inform´atica. Se han indicado en rojo los grupos de laboratorio de dicha asignatura. Figura 4.1: Horario del segundo cuatrimestre del curso 2018/2019 del Grado en Ingenier´ıa Inform´atica de la Universidad de Valladolid, menci´on Ingenier´ıa del Software, tercer curso. 35 Figura 4.2: Horario del segundo cuatrimestre del curso 2018/2019 del Grado en Ingenier´ıa Inform´atica de la Universidad de Valladolid, menci´on Tecnolog´ıas de la Informaci´on, tercer curso. 36 Figura 4.3: Horario del segundo cuatrimestre del curso 2018/2019 del Grado en Ingenier´ıa Inform´atica de la Universidad de Valladolid, menci´on Computaci´on, tercer curso. 4.2. Modelo de dominio Para realizar el modelo de dominio se ha tenido en cuenta la naturaleza del problema que se pretend´ıa resolver, la normativa actual y se han tomado algunas decisiones para intentar que fuera lo m´as fiel posible a la realidad. 37 Programaci´on negocio: programar las clases involucradas en el inicio de sesi´on. Se decide ampliar el modelo con una clase Login para seguir de una manera m´as estricta la arquitectura elegida. Pruebas: comprobar que se cumplen los criterios de aceptaci´on. Documentaci´on: documentar el seguimiento del sprint y la memoria del proyecto. Historia de usuario HU03: Generar horario Programaci´on UI: incluye el desarrollo de los men´us de selecci´on de titulaci´on y per´ıodo, el de elecci´on de asignaturas y la salida del horario generado. Programaci´on negocio: programaci´on de todas las clases involucradas en el proceso de c´alculo de posibilidades y generaci´on del horario final. Programaci´on persistencia: ampliar la base de datos creada y poblarla con datos suficientes como para poder llevar a cabo las pruebas. Pruebas: comprobar que se cumplen los criterios de aceptaci´on. Documentaci´on: documentar el seguimiento del sprint y la memoria del proyecto. Historia de usuario HU04: Guardar horario Programaci´on UI: dise˜no de la vista “Mis horarios” adem´as de a˜nadir un formulario para guardar el horario a la vista del horario ya creada. Programaci´on negocio: programaci´on de las clases involucradas en el proceso de guardar horarios. Se modifican algunos servicios para guardar el horario en formato texto. Programaci´on persistencia: ampliaci´on de la base de datos con la tabla “Timetables”. Pruebas: comprobar que se cumplen los criterios de aceptaci´on. Documentaci´on: documentar el seguimiento del sprint y la memoria del proyecto. Historia de usuario HU05: Exportar horarios Programaci´on UI: programaci´on de formulario para descargar el fichero en formato PDF. Programaci´on negocio: programar en javascript la funci´on para descargar el fichero, lo que incluye documentarse sobre las librer´ıas que se utilizan para estas tareas. Pruebas: comprobar que se cumplen los criterios de aceptaci´on. Documentaci´on: documentar el seguimiento del sprint y la memoria del proyecto. Historia de usuario HU06: Funcionamiento de la aplicaci´on Programaci´on UI: dise˜no de la p´agina de inicio de la aplicaci´on. Configuraci´on despliegue remoto: creaci´on de cuenta en el servicio de alojamiento Heroku y puesta en marcha de una aplicaci´on de prueba para comprobar que funciona. 44 Configuraci´on despliegue local: instalaci´on de servidor local con Apache Tomcat y despliegue de una aplicaci´on de prueba para comprobar el buen funcionamiento. Pruebas: comprobar que se cumplen los criterios de aceptaci´on. Documentaci´on: documentar el seguimiento del sprint. Historia de usuario HU07: Administraci´on Programaci´on UI: creaci´on de los diferentes men´us de administraci´on. Programaci´on negocio: programaci´on de las clases involucradas. Aunque se espera que sea mucho trabajo se trata de algo repetitivo a la hora de gestionar asignaturas, grupos y titulaciones. Programaci´on persistencia: corregir errores en el dise˜no de la base de datos adem´as de programar las clases DAO que intervienen en la historia de usuario. Pruebas: comprobar que se cumplen los criterios de aceptaci´on. Documentaci´on: documentar el seguimiento del sprint. 45 46 CAP´ ITULO 5. DISE˜ NO DEL SISTEMA Cap´ıtulo 5 Dise˜no del sistema 5.1. Arquitectura 5.1.1. Visi´on global La aplicaci´on se ha construido siguiendo una arquitectura basada en capas. Sigue un modelo de desarrollo de software en el que el objetivo es desacoplar las partes que componen la aplicaci´on ya que ´estas est´an destinadas a operaciones muy diferenciadas. Se trata de separar roles y dividir responsabilidades entre la capa de presentaci´on, la de negocio y la de persistencia. Los componentes de las diferentes capas se comunican con los de otras a trav´es de interfaces y la mayor´ıa de la interacci´on s´olo ocurre entre capas contiguas, tal y como muestra la Figura 5.7. Figura 5.1: Representaci´on simplificada de una arquitectura de 3 capas. Aunque existen otras variantes, para el proyecto se ha elegido la de tres capas, cuyas caracter´ısticas son las siguientes: Capa de presentaci´on: es la capa con la que interacciona el usuario directamente. Se le presentan los resultados y se capturan sus acciones. S´olo se debe comunicar con la capa de negocio. Capa de negocio: es donde reside la l´ogica de los programas. Se reciben las peticiones procesadas en la capa de presentaci´on y, en caso de necesitarlo, se env´ıan las solicitudes correspondientes a la capa de persistencia. Una vez se ha procesado la solicitud se devuelve a la capa de presentaci´on el resultado. Capa de persistencia: es la capa encargada del acceso a datos. Recibe las peticiones desde la capa de negocio y las realiza al sistema gestor de la base de datos elegida. 47 A la hora de aplicar esta arquitectura se busca que el sistema construido cumpla con una serie de principios de desarrollo de software, entre los que est´an: Alta cohesi´on: cada una de las capas construidas tiene s´olo la funcionalidad correspondiente a esa capa. Reutilizaci´on: las capas de negocio y persistencia no tienen dependencia con la capa de presentaci´on, por lo que su contenido puede reutilizarse en otros entornos. Abstracci´on: se abstrae la vista del modelo, pero facilitando el suficiente nivel de detalle como para entender la comunicaci´on entre capas. Desacoplamiento: la comunicaci´on entre las tres capas se basa en la abstracci´on, lo que facilita que no exista acoplamiento entre ellas. En la aplicaci´on desarrollada la estructura es la siguiente: Figura 5.2: Arquitectura en tres capas de la aplicaci´on. A continuaci´on se presenta la estructura seguida en las diferentes capas que forman la arquitectura de la aplicaci´on. Con el fin de obtener una mayor claridad en los esquemas se ha prescindido de a˜nadir los atributos y/o m´etodos de cada una de las clases que aparecen. 48 En la Figura 5.3 se puede observar la estructura de la capa de presentaci´on. Se ve como la vista y el controlador hacen uso de los modelos desarrollados. Adem´as es el controlador el que act´ua de intermediario para atender peticiones y servir la informaci´on. Figura 5.3: Capa de presentaci´on de la aplicaci´on. En la siguiente figura, la 5.4 se muestra la estructura de la capa de negocio. Todas las clases implementadas tienen asociadas sus interfaces que es a trav´es de las cu´ales se entablar´an las comunicaciones con otras capas. 49 Figura 5.4: Capa de negocio de la aplicaci´on. Y la tercera capa de la arquitectura se muestra en la Figura 5.5. Al igual que en la capa de negocio las clases cuentan todas con una interfaz que es a trav´es de la que se accede desde el exterior. Figura 5.5: Capa de persistencia de la aplicaci´on. 5.1.2. Spring Web MVC Es el framework original para desarrollo web y se encuentra dentro de lo que se conoce como “Spring Framework”. En la p´agina oficial [21] se clasifica en el “Servlet Stack” tal y como muestra la Figura 5.6. 50 Figura 5.6: Stack de Spring Framework. El framework Spring hace uso del principio de dise˜no de software denominado inversi´on de control, a trav´es del cual se invierte el flujo de ejecuci´on de un programa. Se reciben las peticiones y se establecen las respuestas que hay que darlas, pero no se establece un orden de respuesta fijo. Spring Web MVC est´a dise˜nado en base al patr´on “Front Controller” donde un servlet central, que en este caso se denomina DispatcherServlet, proporciona la posibilidad de gestionar las peticiones que llegan, envi´andolas a los componentes que corresponda. Este modelo de trabajo ofrece mucha flexibilidad, permitiendo diferentes flujos de trabajo dentro de una misma aplicaci´on Referencia Docs Spring io. Entre sus caracter´ısticas cabe destacar las siguientes: Separaci´on de roles. Adaptable y flexible. Reutilizaci´on de c´odigo de negocio. Soporte para JSP y JSTL. Spring Web MVC es un marco de trabajo dirigio por peticiones, y en el centro se encuentra el ya mencionado DispatcherServlet. El flujo de trabajo que siguen las peticiones de manera habitual se puede ver en la Figura 5.7, extra´ıda de [22]. 51 Figura 5.7: Flujo de trabajo del procesamiento de peticiones en Spring Web MVC a alto nivel. Cualquier petici´on que llega se env´ıa al “Front Controller”, que decide a qu´e controlador le corresponde resolver la petici´on. El controlador encargado de la petici´on se la env´ıa a la clase de servicio que corresponda, y una vez que se han realizado las tareas correspondientes para procesar la petici´on, el propio controlador recibe, de la capa de servicio o de la de datos, el modelo que corresponda. Por ´ultimo el controlador env´ıa ese modelo al “Front Controller”, que se encarga de a˜nadir el modelo a la vista que corresponda y se la env´ıa al navegador para que se muestre al usuario. 5.2. Patrones de Dise˜no 5.2.1. Modelo Vista Controlador Se trata de un patr´on de arquitectura de software. Bas´andose en la idea de separaci´on de conceptos lo que hace es separar los datos de la l´ogica de negocio y de la presentaci´on de la informaci´on a los usuarios. Para ello propone la construcci´on de tres componentes que son el modelo, la vista y el controlador. En la Figura 5.8, obtenida de [23] se puede ver la relaci´on entre los componentes de este patr´on. 52 Figura 5.8: Relaci´on de componentes en el patr´on Modelo-Vista-Controlador. Las funciones que desempe˜nan son, de manera gen´erica, las siguientes: Modelo: representa la informaci´on que maneja el sistema y gestiona el acceso a la misma. Vista: es la encargada de presentar el modelo al usuario para que pueda interaccionar con la aplicaci´on. Controlador: es el encargado de “controlar”, en el sentido de que procesa las peticiones que el usuario realiza a trav´es de la vista y solicita datos al modelo para atender esas peticiones. 5.2.2. Data Access Object Es un patr´on que nos permite aislar la capa persistencia de la de negocio abstrayendo la forma de acceso a la base de datos. Los principales elementos son estos: Intefaz Data Access Object: define las operaciones est´andar que se realizar´an en el modelo de objeto. Clase Data Access Object: es la clase que implementa la interfaz DAO. Es la responsable del acceso a los datos y de la l´ogica de los m´etodos definidos. Modelo de objeto: objecto que tiene los m´etodos para almacenar los datos que se han obtenido utilizando la clase DAO. La siguiente figura muestra un ejemplo de c´omo se comunican las clases participantes en este patr´on [24]: 53 60 CAP´ ITULO 6. IMPLEMENTACI ´ ON Cap´ıtulo 6 Implementaci´on 6.1. Herramientas y tecnolog´ıas utilizadas En este apartado se dividen en diferentes categor´ıas y se describen brevemente las herramientas y tecnolog´ıas utilizadas durante el desarrollo de todo el Trabajo de Fin de Grado. Gesti´on del proyecto Git Software de control de versiones dise˜nado para que las tareas de mantenimiento del c´odigo fuente en proyectos de cierto calibre fuese m´as f´acil y eficaz. Se trata de un software libre distribuible bajo la Licencia P´ublica General de GNU. GitHub Plataforma online para almacenar proyectos utilizando el sistema de control de versiones Git. Se ha utilizado la cuenta personal del autor del presente trabajo y se crearon dos repositorios, uno para la aplicaci´on y otro para los scripts de creaci´on y poblaci´on de la base de datos. Dise˜no y desarrollo Eclipse IDE Es el Entorno de Desarrollo Integrado de Eclipse, que es una plataforma de desarrollo de software compuesta por multitud de herramientas de programaci´on de c´odigo abierto. En lugar de incluir todas las funciones por defecto, el entorno proporciona s´olo la que el usuario requiera a trav´es de la instalaci´on de m´odulos . En el proyecto se ha utilizado para desarrollar todo el c´odigo fuente de la aplicaci´on, tanto la parte del servidor como la del cliente. Los detalles de la versi´on utilizada se muestran en la siguiente tabla: 61 Versi´on 2018-12 (4.10.0) Build id 20181214-0600 Tabla 6.1: Informaci´on del servidor Tomcat utilizado. Astah UML Herramienta de modelado UML que tambi´en se conoce por el nombre de JUDE (Java and UML Developers’ Environment) que se ha utilizado para realizar los diagramas que aparecen en el presente documento. Se trata de la herramienta con la que ha trabajado el alumno durante sus estudios de Grado en Ingenier´ıa Inform´atica, y aunque no se dispon´ıa de licencia al haber terminado el acuerdo con la Universidad de Valladolid, se solicit´o una de car´acter temporal. Visual Studio Code Editor de c´odigo fuente gratuito y de c´odigo abierto. Se puede personalizar a trav´es de m´odulos para dar soporte a multitud de lenguajes de programaci´on. Permite la depuraci´on de c´odigo, control integrado de Git y refactorizaci´on de c´odigo, entre otras caracter´ısticas. JSFiddle Editor de c´odigo online que permite utilizar diferentes lenguajes y frameworks de programaci´on. Se ha utilizado para realizar pruebas del c´odigo javascript y de la parte de dise˜no de la interfaz con CSS. Draw.io Herramienta online para realizar dise˜nos y diagramas de todo tipo, entre los que se incluyen diagramas de clases, de casos de uso, de secuencia, de tipo entidad-relaci´on,etc. Draw.io referencia permite adem´as exportar los diagramas realizados en multitud de formatos. En este caso se utiliz´o para dise˜nar el modelo relacional porque ya se hab´ıa trabajado con dicha herramienta en ocasiones anteriores y, adem´as, para este tipo de diagrama es m´as sencilla y f´acil de usar que otras. Back-end Spring Web MVC Tal y como se indic´o en el apartado 5.1.2 del cap´ıtulo anterior se trata del framework de desarrollo web utilizado para la programaci´on de la aplicaci´on. Es el marco de trabajo original para desarrollo web, est´a construido sobre la API Servlet y se ha incluido desde un inicio en lo que se denomina Framework Spring. MySQL Sistema de gesti´on de bases de datos relacional. Es un sistema ideal para aplicaciones web, ya que habitualmente estas tienen una baja concurrencia en la modificaci´on de datos y la lectura de datos suele ser mucho m´as frecuente, 62 y es en la lectura de datos donde el entorno act´ua mejor. Se ha utilizado para implementar la base de datos de la aplicaci´on. Maven Es una herramienta para construir y gestionar proyectos en Java. Se ha utilizado apra gestionar las dependencias externas. Front-end Bootstrap Es un framework multiplataforma y de c´odigo abierto que se ocupa de la parte de desarrollo front-end. Cuenta con multitud de elementos de dise˜no basados en HTML y CSS, adem´as de extensiones JavaScript. Es compatible con la mayor´ıa de navegadores web y desde su versi´on 2.0 soporta dise˜nos adaptativos. Para el desarrollo de la aplicaci´on se utiliz´o la versi´on 3.3.7. JavaScript Es un lenguaje de programaci´on interpretado y orientado a objetos. Se suele utilizar en la parte del cliente y es interpretado por todos los navegadores web actuales. Se utiliza para obtener mejoras en el apartado de la interfaz de usuario y a˜nadir elementos din´amicos a las p´aginas web. En este trabajo se ha utilizado para validaci´on de formularios, b´usqueda din´amica en tablas y para generar ficheros PDF a partir de cierto contenido web. Otras herramientas Apache Tomcat Tambi´en conocido como Jakarta Tomcat o s´olo como Tomcat, es un contenedor web y no un servidor de aplicaciones. Puede funcionar como un servidor web y funciona en cualquier m´aquina que tenga un sistema operativo que disponga de la m´aquina virtual Java (JVM). En este caso se ha utilizado como servidor web para desplegar de manera local la aplicaci´on desarrollada. La informaci´on de la versi´on utilizada es la siguiente: Versi´on de Tomcat Apache Tomcat/9.0.4 Versi´on JVM 1.8.0 144-b01 Tabla 6.2: Informaci´on del servidor Tomcat utilizado. Heroku Es una plataforma de computaci´on en la nube que soporta diferentes lenguajes como Ruby, Java, Node.js o Python, entre otros. En este caso se utiliz´o para realizar pruebas de despliegue en un entorno real y probar la aplicaci´on fuera de la m´aquina local. 63 Microsoft Excel Aplicaci´on de hojas de c´alculo que se incluye dentro de la suite de aplicaciones Microsoft Office. Se utiliz´o solo para las tareas de poblaci´on de la base de datos, permitiendo introducir los datos en tablas y generar autom´aticamente las consultas SQL. Se utiliz´o la suscripci´on a Office 365 proporcionada por la Universidad de Valladolid y la versi´on utilizada fue la “15.38”. 6.2. Interfaz de usuario Aunque se ten´ıa una idea previa sobre lo que ser´ıa la interfaz del usuario y la manera de presentar la informaci´on no se realizaron bocetos previos, sino que se fue construyendo a medida que el proyecto avanzaba. Lo m´as destacable del dise˜no de la interfaz del usuario es que se ha realizado siguiendo algunas directrices para que dicho dise˜no fuese adaptativo. En la actualidad la gente accede a aplicaciones web desde multitud de dispositivos como ordenadores, tablets, smartphones, etc. Para que la experiencia de usuario a la hora de utilizar la aplicaci´on sea pr´acticamente id´entica independientemente del dispositivo en la que la est´e ejecutando es necesario que la interfaz se adapte a ese dispositivo. A continuaci´on se muestran ejemplo de c´omo se ve la aplicaci´on en diferentes dispositivos y navegadores: Figura 6.1: Interfaz del usuario desde un navegador Firefox. 64 Figura 6.2: Interfaz del usuario desde un iPad y un navegador Safari. Figura 6.3: Interfaz del usuario desde un navegador de un smartphone Android. Se han adaptado la mayor´ıa de elementos, y otros se han fijado para que la informaci´on sea de utilidad al usuario. Nos estamos refiriendo a la salida por pantalla del horario, que no se puede adaptar del todo cuando la pantalla es demasiado estrecha, ya que sino el usuario tendr´ıa casi que leer en vertical. En dicho caso se ajustar´a hasta un determinado momento y el usuario, para poder consultar todo el horario, tendr´a que desplazarse por la p´agina lateralmente, tal y como se puede ver en la Figura ??. 65 Figura 6.4: Interfaz del usuario de la pantalla horario reducida horizontalmente. Otra parte importante del dise˜no, y que se utiliza en multitud vistas de la aplicaci´on, son los paneles. Se trata de unos elementos que ofrece Bootstrap y que permiten presentar la informaci´on en formato de cajas, a las que se les puede a˜nadir un t´ıtulo, un cuerpo y un pie. No s´olo nos permite agrupar informaci´on relacionada, como por ejemplo todos los campos de un formulario, sino que adem´as se pueden presentar con diferentes estilos para darle al usuario, de una manera m´as visual, una referencia sobre la operaci´on que est´a llevando a cabo. En ese sentido se han configurado los paneles para que se mostrasen con un aspecto u otro dependiendo del tipo de operaci´on que el usuario o el administrador iban a hacer: Operaciones habituales: se refiere a los formularios de registro e inicio de sesi´on, o a los men´us principales. El panel que se muestra tiene color azulado. 66 Figura 6.5: Ejemplo de panel utilizado para operaciones habituales. Operaciones de edici´on: para las tareas de administraci´on en las que se va a modificar la informaci´on permitida de una titulaci´on, asignatura y/o grupo. Se han puesto paneles en color amarillo para identificarlos con una apariencia de “advertencia”. Figura 6.6: Ejemplo de panel utilizado para operaciones de edici´on. Operaciones de borrado: cuando el usuario va a borrar alguno de los horarios que tiene guardados o cuando el administrador va a eliminar una titulaci´on, asignatura y/o grupo. Para este caso se ha optado por un panel con apariencia de “peligro” que se identifica con el color rojo. 67 Figura 6.7: Ejemplo de panel utilizado para operaciones de borrado. 6.3. C´odigo de la aplicaci´on Cabe indicar que hay ciertas partes del c´odigo de la aplicaci´on que se han reutilizado de otras aplicaciones ya existentes y que se indican a continuaci´on. Clases involucradas en el registro e inicio de sesi´on de la aplicaci´on Por ser la primera vez que se utilizaba el framework Spring MVC se consultaron multitud de ejemplos de aplicaciones en las que se implementaba. La mayor´ıa de ellas eran simples y s´olo contaban con el c´odigo necesario para llevar a cabo el registro y el inicio de sesi´on, pero con eso result´o suficiente para obtener un ejemplo real de c´omo desarrollar la aplicaci´on utilizando el citado framework a la vez que se implementaba la arquitectura de tres capas. La aplicaci´on de referencia que se sigui´o se puede encontrar en [27]. M´etodos auxiliares para el c´alculo de probabilidades Uno de los problemas a la hora de calcular las posibles combinaciones entre grupos de asignaturas era obtener una visi´on global de esas combinaciones. No hay manera de reducir el n´umero de casos a evaluar, sino que hay que tenerlos en cuenta todos y despu´es ir analizando el n´umero de solapamientos de horas y el grado de compactaci´on de cada combinaci´on. Esto se realiza en el m´etodo “getValidCombinations” de la clase “TimetableService.java”. Este m´etodo hace uso de otros dos m´etodos auxiliares que se tomaron de [28], y que son “combinationUtil” y “printCombination”. 68 JavaScript JavaScript es un lenguaje de programaci´on que se ha utilizado para determinadas funciones y en partes muy concretas del proyecto. Aprovechando que se trata de un lenguaje interpretado se ha incluido en el c´odigo de las vistas, por lo que se ejecutar´a en los navegadores, es decir, en la parte del cliente. De esta manera se consigue disminuir algo la carga de trabajo del servidor donde est´e alojada la aplicaci´o. Por el contrario se depende de que el navegador donde se cargue la aplicaci´on pueda ejecutar javascript, aunque en la actualidad es lo m´as com´un. Se han utilizado algunas librer´ıas ya existentes y se han desarrollado porciones de c´odigo para estas partes de la aplicaci´on: Validaci´on de formularios Utilizarlo para la validaci´on de los formularios de la aplicaci´on permite que estos s´olo se env´ıen cuando se hayan cumplido las condiciones. En la mayor´ıa de los casos se evalua que los campos no estuvieran vac´ıos. Se ha utilizado en diferentes partes de la aplicaci´on, pero un ejemplo utilizado en el formulario de registro se muestra en la Figura 6.8. function validateForm(){ var a= document . forms ["RegisterForm"][" username " ]. value ; var b= document . forms ["RegisterForm"][" email " ]. value ; var c= document . forms ["RegisterForm"][" password " ]. value ; if (a == null || a=="" || b == null || b=="" || c== null || c=="") { alert (" Debe completar todos los campos "); return false ; } } Figura 6.8: C´odigo de ejemplo validaci´on de campos correspondiente al formulario de registro. B´usquedas din´amicas Estas b´usquedas se realizan como administrador de la aplicaci´on, y es muy importante que se realice de manera din´amica para que no haya que estar recargando la p´agina con el contenido todo el tiempo. Lo que se consigue con la funci´on es que s´olo se muestren las filas de la tabla que cumplan las condiciones de b´usqueda a la vez. 69 Condici´on inicial El usuario ha iniciado sesi´on con el rol de usuario normal. En la p´agina de inicio ha hecho clic en el bot´on “Generar nuevo horario” y se encuentra en la el formulario para elegir titulaci´on y per´ıodo. Acci´on del usuario El usuario deja sin elegir alguno de los dos campos disponibles y hace clic en el bot´on “Elegir asignaturas”. Resultado Correcto. Sale un mensaje emergente indicando al usuario que debe elegir una opci´on de los dos men´us. Adem´as, el primer campo que haya dejado sin elegir se marcar´a con el borde en color rojo para indicar al usuario donde se ha localizado su error. Este error se producir´a hasta que el usuario complete el formulario de manera correcta. Condici´on inicial El usuario ha completado satisfactoriamente el paso de elegir titulaci´on y curso. Ahora se encuentra en la pantalla con el formulario para elegir asignaturas. Acci´on del usuario Elige, al menos, una asignatura en el formulario de selecci´on de asignaturas y hace clic en “Calcular horario”. Resultado Correcto. Se genera un horario de acuerdo a las asignaturas elegidas. Condici´on inicial El usuario ha completado satisfactoriamente el paso de elegir titulaci´on y curso. Ahora se encuentra en la pantalla con el formulario para elegir asignaturas. Acci´on del usuario El usuario intenta enviar el formulario sin elegir ninguna asignatura. Resultado Correcto. Se muestra un mensaje emergente de error informando al usuario de que debe elegir al menos una asignatura. El sistema tiene que mostrar la mejor combinaci´on encontrada atendiendo a dos criterios: el menor n´umero de solapamientos de clase posibles y el mayor grado de compactaci´on. Condici´on inicial El usuario ha completado satisfactoriamente el paso de elegir titulaci´on y curso. En la siguiente p´agina, el usuario ha seleccionado una o m´as asignaturas. Acci´on del usuario El usuario env´ıa el formulario hacienco clic en el bot´on “Calcular horario”. Resultado Incorrecto. Se observa que si bien el horario geneerado tiene el menor n´umero de solapamiento de horas posible, no es el m´as compacto. Tras revisar el algoritmo se localiza el error, que consist´ıa en que se estaba generando el horario menos compacto en lugar de lo contrario. Se corrige el error y la salida es ahora la correcta. El sistema tiene que mostrar enlaces a otras posibles soluciones con las mismas caracter´ısticas de solapamientos y grado de compactaci´on. 76 Condici´on inicial El usuario ha completado satisfactoriamente el paso de elegir titulaci´on y curso. En la siguiente p´agina, el usuario ha seleccionado una o m´as asignaturas. Acci´on del usuario El usuario env´ıa el formulario hacienco clic en el bot´on “Calcular horario”. Resultado Correcto. Se le indica al usuario en un mensaje que aparece en la parte superior de la pantalla las opciones que se han encontrado con el mismo n´umero de solapamientos y el mismo grado de compactaci´on. Se muestran en la parte inferior de la pantalla botones de acceso a las dem´as versiones. Condici´on inicial El usuario ha completado satisfactoriamente el paso de elegir titulaci´on y curso. En la siguiente p´agina, el usuario ha seleccionado una o m´as asignaturas. Adem´as ha enviado el formulario hacienco clic en el bot´on “Calcular horario”. Acci´on del usuario Hace clic en alguna de las dem´as opciones generadas. Resultado Correcto. Se muestra de manera correcta el nuevo horario. Historia de usuario HU04: Guardar horario Al generar un horario nuevo abajo aparecer´a un formulario al usuario con la opci´on de guardar el horario. Condici´on inicial El usuario completa los pasos para generar un horario de selecci´on de titulaci´on, per´ıodo y asignaturas. Acci´on del usuario El usuario env´ıa el formulario hacienco clic en el bot´on “Calcular horario”. Resultado Correcto. En la p´agina donde se genera el horario aparece un formulario en la parte inferior para poder guardar un horario d´andole el nombre que desee el usuario. Si el usuario no rellena el formulario se informar´a del error al usuario. Condici´on inicial El usuario se encuentra en la p´agina en la que se muestra el horario que se acaba de generar. Acci´on del usuario No introduce ning´un nombre para guardar el horario y hace clic en “Guardar horario”. Resultado Correcto. Aparece una ventana emergenete informando al usuario de que debe darle un nombre al horario antes de guardarlo. El horario guardado aparecer´a en el listado de horarios del usuario. Condici´on inicial El usuario est´a en la p´agina donde se carga el horario. Ha introducido un nombre para guardarlo. Acci´on del usuario El usuario hace clic en el bot´on “Guardar horario”. Resultado Correcto. El horario se guarda correctamente y el usuario es redirigido a la p´agina de horarios, donde hay un listado de todos los horarios que tiene guardados. El horario que acaba de guardar aparece en la lista. 77 Condici´on inicial El usuario est´a en cualquier p´agina de la aplicaci´on. Acci´on del usuario El usuario accede hace clic en el enlace “Mis horarios” que aparece en la barra superior de navegaci´on. Resultado Correcto. Se muestra un listado de los horarios guardados. El usuario podr´a cargar cualquier horario de los guardados si as´ı lo desea. Condici´on inicial El usuario se encuentra en la p´agina donde se muestran sus horarios guardados. Acci´on del usuario El usuario hace clic en la opci´on “Ver” de alguno de ellos, que corresponde al icono del ojo. Resultado Correcto. Se carga el horario guardado correctamente. Historia de usuario HU05: Exportar horarios Al generar un horario nuevo abajo aparecer´a un formulario al usuario con la opci´on de exportar a PDF el horario. Condici´on inicial El usuario completa los pasos para generar un horario de selecci´on de titulaci´on, per´ıodo y asignaturas. Acci´on del usuario El usuario env´ıa el formulario hacienco clic en el bot´on “Calcular horario”. Resultado Correcto. En la p´agina donde se genera el horario aparece un formulario en la parte inferior para poder descargar el horario en formato de fichero PDF. El horario se descargar´a en formato PDF y contendr´a la tabla con el mismo estilo que el utilizado en la aplicaci´on. Condici´on inicial El usuario est´a en la p´agina donde se carga el horario. Acci´on del usuario Hace clic en el bot´on “Descargar como PDF”. Resultado Correcto. El fichero se descarga en formato PDF con el nombre “HorarioSchema.pdf” que es el que se ha especificado en la funci´on javascript. El PDF muestra el horario con el mismo aspecto visual que el que tiene en la aplicaci´on web. Historia de usuario HU06: Funcionamiento de la aplicaci´on La aplicaci´on se ejecuta con normalidad en los principales navegadores web (Chrome, Safari, Firefox, Internet Explorer). Condici´on inicial El usuario tiene un navegador Safari abierto. Acci´on del usuario El usuario introduce la URL de la aplicaci´on. Resultado Correcto. La aplicaci´on se visualiza de manera correcta. 78 Condici´on inicial El usuario tiene un navegador Google Chrome abierto. Acci´on del usuario El usuario introduce la URL de la aplicaci´on. Resultado Correcto. La aplicaci´on se visualiza de manera correcta. Condici´on inicial El usuario tiene un navegador Firefox abierto. Acci´on del usuario El usuario introduce la URL de la aplicaci´on. Resultado Correcto. La aplicaci´on se visualiza de manera correcta. Condici´on inicial El usuario tiene un navegador Internet Explorer abierto. Acci´on del usuario El usuario introduce la URL de la aplicaci´on. Resultado Correcto. La aplicaci´on se visualiza de manera correcta. La aplicaci´on es accesible desde dispositivos m´oviles (tablets y smartphones) y el dise˜no se ajusta a las pantallas de los dispositivos. Condici´on inicial El usuario tiene un navegador Safari abierto en un iPad. Acci´on del usuario El usuario introduce la URL de la aplicaci´on. Resultado Correcto. La aplicaci´on se visualiza de manera correcta ajust´andose a las dimensiones de la pantalla. Condici´on inicial El usuario tiene un navegador abierto en un smartphone con el sistema operativo Android. Acci´on del usuario El usuario introduce la URL de la aplicaci´on. Resultado orrecto. La aplicaci´on se visualiza de manera correcta ajust´andose a las dimensiones de la pantalla. Historia de usuario HU07: Administraci´on Al iniciar sesi´on como administrador aparecer´a un men´u de administraci´on para gestionar titulaciones, asignaturas y grupos. Condici´on inicial El usuario se encuentra en la p´agina con el formulario de inicio de sesi´on. Acci´on del usuario Completa los campos solicitados (nombre de usuario y contrase˜na) con unos datos v´alidos de usuario con rol de administrador. Resultado Correcto. Se inicia sesi´on en la aplicaci´on de manera correcta. Se carga el men´u de administraci´on. El usuario administrador podr´a realizar algunas modificaciones como cambios de denominaci´on a trav´es de los diferentes men´us de gesti´on, pero habr´a otras operaciones limitadas (por ejemplo el cambio de c´odigos de asignaturas y/o grupos). 79 Condici´on inicial El administrador se encuentra en el men´u de gesti´on de asignaturas. Acci´on del usuario Sobre una de las asignaturas hace clic en en el icono de editar asignatura. Resultado Correcto. Se carga un formulario con los datos de la asignatura, en el que s´olo es posible modificar algunos campos. Condici´on inicial El administrador se encuentra en la p´agina de edici´on de una asignatura. Acci´on del usuario Deja alguno de los campos vac´ıos que no sean el de “Menci´on/especialidad” y hace clic en “Actualizar asignatura”. Resultado Correcto. Se muestra una ventana emergente en la que se le indica al usuario que debe rellenar todos los campos del formulario. Condici´on inicial El administrador se encuentra en la p´agina de edici´on de una asignatura. Acci´on del usuario Cambia los campos que desea sin introducir un nombre de asignatura ya existente para esa titulaci´on y hace clic en “Actualizar asignatura”. Resultado Correcto. Se recarga el formulario con los datos de la nueva asignatura y abajo se muestra un mensaje indicando al usuario que se han guardado los cambios. Condici´on inicial El administrador se encuentra en la p´agina de edici´on de una asignatura. Acci´on del usuario Cambia los campos que desea e introduce un nombre de asignatura ya existente para esa titulaci´on y hace clic en “Actualizar asignatura”. Resultado Correcto. Se recarga el formulario con los datos y abajo se muestra un mensaje indicando al usuario que se ya existe una asignatura en esa titulaci´on y con ese nombre. No se produce ninguna actualizaci´on en la base de datos. Condici´on inicial El administrador se encuentra en el men´u de gesti´on de asignaturas. Acci´on del usuario Sobre una de las asignaturas hace clic en en el icono de eliminar asignatura. Resultado Correcto. Se carga un formulario con los datos de la asignatura, en el que no se puede modificar ning´un cambio y en el que se le informa al usuario de los grupos que se eliminar´an si elimina esa asignatura. 80 Condici´on inicial El administrador se encuentra en la p´agina de eliminaci´on de asignatura. Acci´on del usuario El administrador hace clic en “Eliminar asignatura”. Resultado Correcto. Se vuelve a cargar la p´agina de gesti´on de asignaturas, donde ya no aparece la asignatura que se acaba de eliminar. Condici´on inicial El administrador se encuentra en la p´agina de eliminaci´on de asignatura. Acci´on del usuario El administrador hace clic en “Volver a asignaturas”. Resultado Correcto. Se vuelve a cargar la p´agina de gesti´on de asignaturas. Condici´on inicial El administrador se encuentra en el men´u de gesti´on de asignaturas. Acci´on del usuario Sobre una de las asignaturas hace clic en en el icono de ver la asignatura. Resultado Correcto. Se carga un formulario con los datos de la asignatura, en el que no es posible editar nada. Condici´on inicial El administrador se encuentra en la p´agina de vista de asignatura. Acci´on del usuario El administrador hace clic en el bot´on “Editar asignatura”. Resultado Correcto. Se carga una p´agina con un formulario de edici´on de la asignatura. Condici´on inicial El administrador se encuentra en la p´agina de vista de asignatura. Acci´on del usuario El administrador hace clic en el bot´on “Volver a asignaturas”. Resultado Correcto. Se carga la p´agina de gesti´on de asignaturas. Condici´on inicial El administrador se encuentra en el men´u de gesti´on de asignaturas. Acci´on del usuario Sobre una de las asignaturas hace clic en en el icono de ver grupos de asignatura. Resultado Correcto. Se carga la p´agina de gesti´on de grupos, pero s´olo aparecen aquellos que corresponden a la asignatura elegida. Las tablas que se han mostrado en este ´ultimo apartado se refieren a los procesos de consulta, edici´on y borrado de asignaturas, pero estas pruebas son tambi´en v´alidas para el caso de las titulaciones y los grupos de asignaturas. 81 82 CAP´ ITULO 7. CONCLUSIONES Cap´ıtulo 7 Conclusiones 7.1. Conclusiones Se ha desarrollado una aplicaci´on web que permita a los estudiantes universitarios calcular sus horarios antes de matricularse, que era el objetivo principal de este Trabajo de Fin de Grado. Realizar un proyecto de estas dimensiones de forma individual ha puesto de manifiesto las dificultades que entra˜na, por lo que cabe imaginarse que proyectos m´as grandes y con m´as personas implicadas requieren de un esfuerzo elevado para ser bien gestionados. Adem´as considero de especial relevancia el hecho de haber podido aplicar los conocimientos obtenidos en multitud de asignaturas de la titulaci´on de Grado en Ingenier´ıa Inform´atica. Esto reafirma mi opini´on personal de que todas las asignaturas tienen cierta importancia, aunque a veces se antoje dif´ıcil la idea de aplicar los contenidos de esta o aquella asignatura. El hecho de trabajar con una metodolog´ıa ´agil utilizando algunos de los elementos que propone Scrum me ha servido para gestionar mejor el tiempo y adaptarme a un m´etodo de trabajo que muchas empresas ponen en pr´actica, por lo que lo considero de gran valor para mi futuro profesional. Lo que me ha resultado m´as dif´ıcil del proyecto ha sido la fase de an´alisis del problema, por la complejidad que entra˜naba y por la dificultad para modelarlo despu´es en la aplicaci´on. Una vez terminado el proyecto, y analizando los resultados obtenidos habr´ıa cambiado el tiempo de dedicaci´on tanto a la parte de administraci´on como a la interfaz gr´afica y lo hubiera dedicado a implementar algunas de las l´ıneas de trabajo futuro que se mencionan en el siguiente apartado. 7.2. Trabajo futuro 7.2.1. En la misma aplicaci´on Como estudiante del Grado en Ingenier´ıa Inform´atica en la Universidad de Valladolid, ha habido cursos en los que he tenido que compaginar mi actividad acad´emica con otras actividades, como por ejemplo el trabajo y/o clases de idiomas. Del desarrollo de este trabajo y de mi propia situaci´on personal se plantean algunas mejoras y complementos que podr´ıan introducirse a la aplicaci´on como son: 83 La posibilidad de que los usuarios, de forma previa a la elecci´on de asignaturas, puedan seleccionar franjas horarias para bloquearlas y que la aplicaci´on obtenga aquellas combinaciones horarias que no incluyan horas de clase de ning´un tipo, en la medida de lo posible, en esos periodos. Aunque en el desarrollo de la aplicaci´on no se ha contemplado ya que en las gu´ıas docentes de las asignaturas no aparece, es cierto que en la titulaci´on de Grado en Ingenier´ıa Inform´atica, existen algunas asignaturas en las que se permite conservar la nota obtenida en la parte de pr´acticas de cursos inmediatamente anteriores. Esto abre la posibilidad a que se pudiera modificar la aplicaci´on para que el estudiante pudiera elegir no s´olo las asignaturas, sino tambi´en la parte (te´orica y/o pr´actica) en base a la cual quiere calcular su horario. Como ampliaci´on ideal para la aplicaci´on desarrollada se plantea la inclusi´on de todas las titulaciones de la universidad. En este punto, y dado que en las distintas facultades se siguen unas pautas a la hora de clasificar asignaturas y grupos, se tendr´ıan que revisar los modelos propuestos, ya que en algunos casos pueden no ser del todo v´alidos. En la l´ınea de trabajo del an´alisis masivo de datos y tratamiento de grandes cantidades de informaci´on se plantea adem´as la posibilidad de que se permita a los usuarios guardar un horario por cuatrimestre. Partiendo de la idea de que los usuarios calcular´an sus horarios antes de completar el proceso de matr´ıcula, un an´alisis exhaustivo de esos datos permitir´ıa a la Escuela hacer una estimaci´on previa m´as aproximada de los recursos que debe proveer para el siguiente periodo lectivo. Como ya se expuso en el segundo cap´ıtulo de este trabajo, hay m´ultiples factores que influyen en la asistencia o falta de asistencia de los estudiantes a clase, por lo que se plantea la posibilidad de analizarlos en detalle y a˜nadir las heur´ısticas necesarias para ofrecer mejores horarios a los alumnos. Se propone tambi´en la adaptaci´on de la aplicaci´on al lenguaje de programaci´on adecuado para tratar de integrarlo en forma de plug-in a la plataforma Moodle de la Escuela de Ingenier´ıa Inform´atica. 7.2.2. En la l´ınea de aplicaciones complementarias Los estudiantes que pasan por la Universidad cursan multitud de asignaturas, participan en diversas actividades complementarias, trabajan en diferentes grupos de pr´acticas, etc. Siguiendo la idea original del proyecto de automatizar tareas que faciliten la asistencia a clase y mejoren el rendimiento acad´emico se propone la creaci´on de aplicaciones similares que permitan al usuario automatizar el tipo de tareas mencionadas anteriormente. Sirvan de ejemplo: Una aplicaci´on para permita gestionar los grupos en los que est´a matriculado el/la estudiante y que permita operaciones como: - Solicitar el cambio de grupo. - Apuntarse a grupos de pr´acticas de manera individual o colectiva. - Que el profesor o la profesora establezca fechas l´ımite para las operaciones anteriores. Esta aplicaci´on deber´ıa poder gestionar de manera autom´atica el trasvase de alumnos entre grupos teniendo en cuenta los tama˜nos, el orden de solicitud, la prioridad desde el punto de vista de solapamiento con otras clases, etc. Una aplicaci´on que permita gestionar la participaci´on en actividades complementarias con reconocimiento de cr´editos ECTS y que permita tanto al usuario como a la Universidad saber, en todo momento, el n´umero de cr´editos que tiene reconocidos cada alumno. 84 Referencias [1] U. de Valladolid. (2018) Proyecto Docente de Trabajo de Fin de grado, Menci´on Ingenier´ıa del Software. Fecha de ´ultimo acceso: 2019-04-17. [Online]. Disponible en: https://alojamientos.uva.es/guia docente/ uploads/2018/545/46976/1/Documento.pdf [2] M. E. H. Garc´ıa, S. N. Mart´ın, M. J. R. Conde, y M. C. S. G´omez, “Factores implicados en el rendimiento acad´emico de los alumnos Universidad de Salamanca,” Revista de investigaci´on educativa, vol. 17, no. 2, pp. 413–421, 1999. [3] D. Albalate del Sol, X. Fageda Sanjuan, y J. Perdiguero, “´ Exito acad´emico, caracter´ısticas personales y proceso de bolonia: una aplicaci´on econom´etrica,” Revista d’innovaci´o docent universit`aria, no. 3, pp. 11–25, 2011. [Online]. Disponible en: http://revistes.ub.edu/index.php/RIDU/article/view/105.000001655 [4] F. S´anchez Carracedo, C. ´ Alvarez Mart´ınez, A. Fern´andez Jim´enez, y J. F. Llosa Espuny, “¿Por qu´e faltan a clase los alumnos?” in JENUI 2017: XXIII Jornadas sobre la Ense˜nanza Universitaria de la Inform´atica: C´aceres, del 5 al 7 de julio de 2017: actas. Asociaci´on de Ense˜nantes Universitarios de la Inform´atica (AENUI), 2017, pp. 165–172. [5] I. Sanz, M. J. Aramburu, L. Museros, M. P´erez, y C. Barrachina, “En busca del estudiante perdido: caracterizaci´on de los ‘no presentados’,” JENUI 2011: XVIII Jornadas de Ense˜nanza Universitaria de la Inform´atica (2011), p 403-410, 2011. [6] E. G. Exp´osito y M. Villasol, “Absentismo entre los estudiantes de teor´ıa econ´omica. un an´alisis cuantitativo,” CD D´avila Quintana, & e. all., Investigaciones de Econom´ıa de la Educaci´on, pp. 231–240, 2007. [7] R. Rodr´ıguez Gonz´alez, J. Hern´andez Garc´ıa, A. M. Alonso Guti´errez, y E. D´ıez Itza, “El absentismo en la universidad: resultados de una encuesta sobre motivos que se˜nalan los estudiantes para no asistir a clase,” Aula Abierta, 82, 2003. [8] (2019) Escuela de ingenier´ıa inform´atica de valladolid. Fecha de ´ultimo acceso: 2019-05-26. [Online]. Disponible en: https://www.inf.uva.es [9] P. M´armol. (2018) 20 herramientas para elaborar los horarios del centro escolar. Fecha de ´ultimo acceso: 2019-03-02. [Online]. Disponible en: https://www.educaciontrespuntocero.com/recursos/ herramientas-elaborar-horarios/34971.html [10] (2019) Agenda del estudiante. Fecha de ´ultimo acceso: 2019-03-03. [Online]. Disponible en: https: //student-agenda-pro.es.aptoide.com [11] (2019) aschorarios. Fecha de ´ultimo acceso: 2019-03-03. [Online]. Disponible en: https://www.asctimetables. com [12] (2019) Free Timetabling Software. Fecha de ´ultimo acceso: 2019-03-02. [Online]. Disponible en: https://www.lalescu.ro/liviu/fet/ 85 Figura A.7: P´agina de gesti´on de asignaturas. En la parte superior de la p´agina dispone de campos de b´usqueda para filtrar las asignaturas que se muestran en la tabla. Los filtros de b´usqueda se aplican de manera conjunta. Para cada asignatura, igual que para las titulaciones, tendr´a cuatro opciones, representadas por iconos y que son las siguientes (en el orden en el que se muestran en la imagen): Editar asignatura: Figura A.8: Formulario de la p´agina de edici´on de asignatura. 92 Eliminar asignatura: se mostrar´a la p´agina para borrar asignaturas. En el formulario los campos no ser´an editables, y se le informar´a de los grupos afectados si finalmente decide eliminar la asignatura. Figura A.9: Formulario de la p´agina de borrado de asignatura. Si confirma la eliminaci´on de la asignatura ser´a redirigido a la p´agina de gesti´on de asignaturas, donde ya no aparecer´a la que acaba de eliminar. Ver asignatura: acceder´a a la p´agina de vista de la titulaci´on, que consiste en un formulario con la informaci´on de la titulaci´on pero que no se podr´a editar. Desde ese men´u podr´a acceder a la edici´on de la titulaci´on o volver a la gesti´on de titulaciones, tal y como muestra la siguiente figura. Figura A.10: Formulario de la p´agina de vista de asignatura. Ver grupos de la asignatura: al hacer clic en este enlace ser´a redirigido a la p´agina de gesti´on de grupos, donde ahora s´olo aparecer´an los grupos asociados a la asignatura seleccionada. 93 Gesti´on de grupos Cuando acceda al men´u “Grupos” acceder´a a la p´agina de gesti´on de grupos, que se muestra en la Figura A.11. Figura A.11: P´agina de gesti´on de grupos de la aplicaci´on. En la parte superior de la p´agina dispone de campos de b´usqueda para filtrar los grupos que se muestran en la tabla. Los filtros de b´usqueda se aplican de manera conjunta. Para cada grupo, igual que para las asignaturas y las titulaciones, tendr´a cuatro opciones, representadas por iconos y que son las siguientes (en el orden en el que se muestran en la imagen): Editar grupo: acceder´a al formulario de edici´on del grupo, donde podr´a cambiar s´olo algunos campos. Figura A.12: Formulario de la p´agina de edici´on de grupo. Eliminar grupo: se mostrar´a un formulario para eliminar el grupo en el que se informar´a al usuario de los grupos asociados que tambi´en se ver´an afectados por la operaci´on de borrado. 94 Figura A.13: Formulario de la p´agina de borrado de grupo. Si confirma la eliminaci´on de la asignatura ser´a redirigido a la p´agina de gesti´on de asignaturas, donde ya no aparecer´a la que acaba de eliminar. Ver grupo: acceder´a a la p´agina de vista del grupo, tal y como se muestra en la siguiente imagen. Los campos no podr´an editarse y podr´a acceder a la edici´on del grupo o volver a la gesti´on de grupos. Figura A.14: Formulario de la p´agina de vista de grupo. Ver grupos asociados: al hacer clic en este enlace ser´a redirigido a la p´agina de gesti´on de grupos, donde ahora s´olo aparecer´an los grupos asociados al grupo seleccionado, en caso de que los haya. Si no tuviera grupos asociados aparecer´ıa una lista vac´ıa. Otras operaciones Para realizar otras operaciones como puede ser la inserci´on de datos, el registro de m´as administradores, o algunas operaciones de edici´on se ha optado por que lo haga un administrador del sistema conect´andose directamente a la base de datos. 95 A.2.3. Estudiante Introducci´on Al iniciar sesi´on como estudiante en la aplicaci´on se le mostrar´a el men´u que se muestra en la Figura A.15. A trav´es de dicho men´u podr´a realizar las siguiente operaciones en la aplicaci´on: consultar sus horarios guardados, generar un nuevo horario, acceder y modificar su perfil. Tambi´en tiene un bot´on habilitado para salir de la aplicaci´on. Podr´a acceder en cualquier momento a este men´u a trav´es del enlace “Inicio” que se muestra en la barra de navegaci´on superior. Figura A.15: Panel del estudiante en la aplicaci´on. Generaci´on de horarios Para generar un nuevo horario tendr´a que completar dos formularios. El primero se muestra en la Figura A.16 y en ´el tendr´a que elegir la titulaci´on y el periodo para los que desea generar el horario. Despu´es acceder´a a la selecci´on de asignaturas. Figura A.16: Formulario de selecci´on de titulaci´on y periodo. Cuando se encuentre en la pantalla de selecci´on de asignaturas (Figura A.17) deber´a a˜nadir al menos una para calcular su horario. Puede a˜nadir y eliminar asignaturas de la lista. 96 Figura A.17: Formulario de selecci´on de asignaturas para el c´alculo de horarios. Cuando haya finalizado debe pulsar “Calcular horario” y ser´a redirigido a una pantalla en la que se mostrar´a el horario generado (Figura A.18). Figura A.18: P´agina de horario generado. Adem´as, en la parte inferior de la pantalla tendr´a disponibles las opciones para guardar el horario en la base de datos y para descargar el horario en formato PDF. Tambi´en encontrar´a disponibles el resto de opciones generadas, si las hay, con las mismas caracter´ısticas de solapamiento de horas y grado de compactaci´on. Ver´a algo similar a lo mostrado en la siguiente imagen. 97 Figura A.19: Operaciones adicionales de la p´agina de horario. Consulta de horarios guardados Podr´a acceder en todo momento a aquellos horarios que haya guardado accediendo al men´u “Mis horarios” que tendr´a accesible desde la barra de navegaci´on superior y desde el men´u principal de estudiante. Al acceder ver´a un listado con sus horarios (Figura A.20) y dos posibles acciones para cada uno. Si hace clic en la opci´on de visualizaci´on se cargar´a la p´agina de horario con los datos del horarios guardado. Si decide eliminar el horario pasar´a a un formulario de confirmaci´on del borrado del horario. 98 Figura A.20: P´agina de horarios guardados del estudiante. Perfil La consulta y gesti´on de su perfil estar´a accesible a trav´es del men´u principal o del enlace correspondiente en la barra de navegaci´on superior. Al acceder se mostrar´a un formulario como el que aparece en la siguiente figura. Figura A.21: Formulario de ajustes de perfil. En el caso de que quiera modificar alg´un campo podr´a hacerlo, y para que tenga efecto deber´a pulsar el bot´on “Actualizar perfil”. Si existe alg´un problema de duplicado de nombre de usuario y/o de cuenta de correo electr´onico se le informar´a al enviar el formulario. 99 100 Ap´endice B Contenido del CD El contenido del disco que acompa˜na a este trabajo es el siguiente: C´odigo fuente: carpeta que contiene el c´odigo fuente de la aplicaci´on desarrollada. Memoria: carpeta con la presente memoria en formato PDF. 101