Desarrollo de un sistema de control de asistencia de profesorado guiado por pruebas

! ! ! ! ! ! ! ! ! ! ! ! ! Desarrollo de un sistema de ! control de asistencia de profesorado ! guiado por pruebas: Test Driven Development ! ! ! Grado en Ingeniería Informática Trabajo Fin de Grado Junio de 2014 ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Autor Rubén Díaz Martínez Tutores José Juan Hernández Cabrera. Dpto. Informática y Sistemas Francisco José Santana Pérez. Dpto. Informática y Sistemas ! ! ! ! ! ! ! ! ! ! ! ! ! ! 1. Objetivos!1!.............................................................................................. 2. Estado actual!3!....................................................................................... 3. Resultados!4!........................................................................................... 3.1. Propuesta de valor!4!............................................................................... 3.2. Requisitos!5!............................................................................................. 3.2.1. Casos de Uso!5!.................................................................................... 3.2.2.Normativa y legislación!7!....................................................................... 3.2. Diseño!9!.................................................................................................. 3.2.1. Diseño del sistema!9!............................................................................ 3.2.2. Diseño de la base de datos!10!............................................................. 3.2.3.Diseño del software!11!.......................................................................... 3.2.4.Diseño de la interfaz de usuario!17!....................................................... 4. Desarrollo!22!........................................................................................... 4.1.Método de desarrollo!22!........................................................................... 4.1.1.Desarrollo Guiado por Pruebas!23!........................................................ 4.1.2.Tests implementados!26!........................................................................ 4.2.Tecnología!27!........................................................................................... 4.3. Iteraciones!29!.......................................................................................... 4.3.1. Idea inicial!29!........................................................................................ 4.3.2. Iteración 1. Funcionalidades!31!............................................................ 4.3.3. Iteración 2. Interfaz de usuario!35!........................................................ 4.3.4.Iteración 3. Feedback y mejoras!39!...................................................... 5. Conclusiones!46!..................................................................................... 6. Trabajos futuros!48!................................................................................ 7. Fuentes de Información!50!.................................................................... Anexo A. Manual de instalación!51............................................................. ! 1. Objetivos! ! El presente documento detalla el desarrollo de una aplicación para el registro de la asistencia de profesorado a clase. ! El proyecto ha sido tutorizado por José Juan Hernández Cabrera y Francisco José Santana Pérez. En el resto del documento, para abreviar, cuando se haga referencia a José Juan se le nombrará como tutor y a Francisco José como product owner (propietario del producto), ya que actualmente ejerce como director de la Escuela de Ingeniería Informática de la Universidad de Las Palmas de Gran Canaria, por lo que, a efectos prácticos, se le considera como tal. ! Los objetivos que se persiguen con la realización de este trabajo se pueden separar en dos tipos: a nivel administrativo para el cliente interesado en el desarrollo del producto y a nivel personal/académico para el estudiante. ! A nivel administrativo, tenemos los siguientes objetivos clave: ! •Como la información estará digitalizada, tratar con ella sería mucho más fácil. En apartados siguientes comentaremos algunos de los trámites que permitirá agilizar esta herramienta. ! •A nivel del profesorado, el sistema notificará mediante correos electrónicos si se ha firmado su docencia. Esto sirve a los profesores como registro de la docencia que han impartido, o si les sustituye otro profesor, enterarse de que no ha habido ningún problema. ! A nivel personal y académico, se persiguen los siguientes objetivos: ! •Participar en el desarrollo de un producto software de principio a fin, algo que no se puede realizar en las distintas asignaturas de la carrera por motivos temporales. ! •Aplicar métodos de desarrollo ágil vistos en la carrera pero de un modo más “realista”, al poder contar con un cliente real interesado en el producto que se está desarrollando y del que se puede obtener feedback constante. ! •Aplicar el desarrollo guiado por pruebas (Test-Driven Development) en el desarrollo de un software completo, ya que durante la carrera, si bien se explica este proceso y se utiliza en algunas prácticas, solo se usaba para desarrollar características aisladas y no integrarlas en un software. ! ! !1 A continuación, se describe la situación actual del control de asistencia al profesorado en la Escuela de Ingeniería Informática así como las aportaciones del proyecto a dicho proceso. La parte central del documento la ocupa la documentación completa del producto, detallando los requisitos y diseño de la aplicación. Después de esto, se detalla el proceso de desarrollo desde la idea inicial del product owner, pasando por la elección de la tecnología para el desarrollo hasta la implementación del producto solicitado. Por último, se sugieren posibles trabajos futuros para mejorar el trabajo desarrollado o nuevas aplicaciones que se apoyen en los datos recogidos y las conclusiones obtenidas, así como las referencias bibliográficas.! !2 2. Estado actual! ! El desarrollo de este proyecto surge de una idea inicial presentada por el product owner como una de sus propuestas electorales para la dirección de la Escuela de Ingeniería Informática (a partir de ahora, EII). ! Cuando un profesor tiene una clase que impartir, debe firmar para acreditar que ha dado esa docencia. Actualmente en la EII, lo que se hace es poner a disposición de todos los profesores una lista con toda la docencia del día actual y los profesores deben firmarla antes de asistir a clase. Esto es una solución que a nuestro product owner no le termina de convencer porque tratar con la información es algo costoso o dado que se puede firmar todo de golpe, habrá profesores que firmen toda la docencia y luego puede surgir un imprevisto que no les permita impartir la docencia que han firmado. En reuniones con el Vicerrector del Profesorado también se comentó la situación actual en otras escuelas universitarias, donde muchas veces ni siquiera se llevaba dicho control a cabo. ! La solución que propone implementar el product owner es algo muy sencillo. Colocar en un punto del edificio un sistema por el que todos los profesores tengan que pasar antes de ir a clase, identificarse en él, mostrar la docencia que tienen asignada en la hora actual y marcarla como firmada de manera virtual. ! La idea de nuestro cliente es desarrollar el proyecto para la EII y, tras un período de prueba, comenzar la implantación en toda la Universidad de Las Palmas de Gran Canaria. ! Esta idea surge de un sistema similar que se utiliza actualmente en la UNED, según nos comenta el product owner. Cuando un profesor entra en la UNED, debe identificarse en un sistema mediante usuario contraseña para notificar que está en el centro y volver a pasar por ese sistema cuando va a irse. Esto se usa para que los alumnos que vayan a tutoría puedan consultar desde ese mismo sistema si el profesor al que quieren ver se encuentra en el edificio o no. ! !3 3. Resultados! ! A continuación, se describen los resultados obtenidos del desarrollo del sistema. Se detalla la propuesta de valor a la que se ha llegado finalmente, los requisitos y el diseño de la aplicación. ! 3.1. Propuesta de valor! ! El valor que aporta este producto se puede ver de dos formas distintas. Desde el punto de vista del product owner, el valor que le aportamos es facilitar las tareas administrativas a la hora de consultar datos como pueden ser los siguientes: ! •Detectar si una hora de docencia no se imparte. ! •En casos de huelga, la administración tiene que comprobar que todos los profesores que no han impartido clases sean aquellos que han hecho huelga. Haciendo una simple consulta al sistema se pueden obtener los profesores que no impartieron clase y comprobar con la lista de los que estaban apuntados a la huelga. ! En cambio, para los profesores, el valor lo aportan las notificaciones que mande la aplicación, para tener constancia de que se ha firmado su docencia, ya sea por ellos mismos o por otro profesor.! !4 3.2. Requisitos! ! En este apartado describimos los requisitos que cumple la aplicación, en forma de casos de uso y la normativa y legislación que nos concierne. 3.2.1. Casos de Uso ! ! Acreditar asistencia Para que un profesor acredite su asistencia a una clase, debe seguir una serie de pasos sencillos. ! •Identificarse en el sistema introduciendo su número de DNI. Una vez autentificado en el sistema tendrá la posibilidad de cerrar sesión en cualquier momento. Pasado un minuto de inactividad, la sesión se cerrará de forma automática. •Seleccionar la docencia que va a acreditar. Por defecto, se mostrarán seleccionadas las horas de docencia asignadas al profesor en la franja horaria actual, pudiendo deseleccionarlas o volverlas a seleccionar. Si el profesor detectase que no se muestra la docencia que debería tener ahora, puede enviar una notificación. •Para enviar una notificación, el profesor selecciona el tipo de notificación que quiere enviar y firme sobre la tableta e incluye algún detalle si fuera necesario. •Firmar la docencia. Una vez firmada la docencia, se cerrará la sesión. Si se realizara una firma y no se pulsará el botón de confirmación en la tableta, al cerrarse la sesión detectará que hay una firma y guardara la docencia firmada. ! Escenario típico: 1. El profesor se identifica introduciendo su DNI. 2. El sistema muestra la docencia que tiene el profesor en la franja horaria. 2.1. Si no hubiera docencia o ya estuviera firmada, el sistema muestra un mensaje de información. 3. El profesor firma sobre la tableta la docencia que se muestra en pantalla. ! ! ! !5 application ! ! ! ! ! ! ! ! ! ! ! ! ! •RuberApplication. Es la clase principal de la aplicación. Su función es crear la ventana de la aplicación con toda la información y los comandos necesarios. ! commands ! Para mejorar la legibilidad, este diagrama se ha separado en 2. El primero representa la herencia y dependencias comunes a todas las clases, y el segundo las dependencias que no son comunes. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !12 •ClearFrameCommand. Comando encargado de reiniciar la ventana de la aplicación al estado inicial, sesión cerrada y mostrando el teclado. Si se hubiese firmado docencia y no se hubiese guardado, se guardaría automáticamente antes de cerrar. •LoadProfessorCommand. Inicia sesión para el profesor asociado al DNI introducido. •SendNotificationCommand. Almacena la notificación que haya mencionado el profesor. •ShowReplacementProfessorListCommand. Muestra los profesores con docencia sin firmar en la franja horaria actual. •ShowReplacementTeachingListCommand. Muestra las asignaturas sin firmar para el profesor al que se va a sustituir. •SignTeachingsCommand. Firma las asignaturas seleccionadas y muestra un mensaje de confirmación. ! model ! ! ! ! ! ! ! •Observable y Observer. Clases para implementar el patrón de diseño Observer. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! •Professor. Representación de un profesor con su DNI, nombre y correo electrónico. •ProfessorList. •Schedule. Horario de la docencia, compuesto por la hora de inicio, fin y el aula. •Subject. Asignatura, compuesta por su nombre y la titulación a la que pertenece. •Teaching. Docencia, la cual se representa mediante un profesor que da una asignatura a un grupo en un horario concreto. •TeachingList. !13 ! notification ! ! ! ! ! ! ! ! ! ! •MailSender. Se encarga de enviar un correo al profesor que ha firmado la docencia para confirmar dicha firma. Si hubiese sustituido a otro profesor, también enviará un correo al otro profesor para notificarle que su docencia ha sido cubierta. ! persistence ! ! •NotificationSaver. Interfaz para guardar una notificación registrada por un profesor. •ProfessorListLoader. Interfaz para representar la carga de toda la lista de profesores mediante un método load(). •TeachingListLoader. Interfaz para la carga de la docencia del día actual. •SignedTeachingListSaver. Interfaz para guardar la lista de la docencia firmada por un profesor. ! ! !14 persistence_db ! ! ! ! ! ! ! ! ! ! ! •DatabaseNotificationSaver. Implementación para guardar una notificación en una base de datos. •DatabaseProfessorListLoader. Implementación para cargar la lista de profesores desde una base de datos. •DatabaseTeachingListLoader. Implementación para cargar la lista de docencia del día actual desde una base de datos. •DatabaseSignedTeachingListSaver. Implementación para almacenar la docencia firmada por un profesor. ! ! viewcontrollers ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! •RuberFrameController. Controlador principal de la ventana de la aplicación al cual acceden los comandos. ! ! !15 views ! ! ! ! ! ! ! ! ! •Command. Interfaz que implementan las clases del paquete commands para ejecutar acciones en el sistema. •Events. Contiene todos los tipos de eventos que pueden lanzarse durante la ejecución de la aplicación para que los capturen los controladores.! !16 3.2.4.Diseño de la interfaz de usuario ! Para mostrar el diseño de la interfaz de usuario, explicaremos el recorrido que habría que seguir para realizar cada uno de los casos de uso. Al iniciar la aplicación, la pantalla inicial es siempre la misma para solicitar el DNI del profesor. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Para el caso de uso de acreditar asistencia, el proceso sería el siguiente. Una vez introducido el DNI, se oculta el teclado y se muestra la foto y nombre del profesor, junto con las asignaturas que tiene en la franja horaria actual. Las asignaturas aparecen marcadas por defecto por comodidad, aunque pueden desmarcarse si el profesor no va a asistir a una de las clases. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !17 ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! En este momento el profesor debe firmar sobre la tableta digitalizadora y pulsar sobre el botón "Terminar" de la tableta una vez haya acabado de firmar. Cuando haga esto, aparecerá la siguiente pantalla: ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Este mensaje aparece durante 3 segundos, tras los cuales se cierra la sesión y volveríamos a la pantalla inicial. Si el profesor firmase y no pulsara el botón "Terminar" en la tableta, cuando se cerrase la sesión (por pulsar el botón "Cerrar" o por inactividad), se firmaría automáticamente. ! !18 ! Si el profesor quisiera enviar una notificación porque su docencia no aparece o un problema parecido, debería pulsar sobre el botón "Enviar notificación": ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !19 Para el caso de sustituir a un profesor no debe tener docencia sin firmar en la franja horaria actual, por lo que al iniciar sesión debería aparecerle esta pantalla. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Al pulsar "Sustituir profesor" verá una lista de los profesores con docencia sin firmar en la franja horaria actual, estando dicha lista paginada por el nombre del profesor, haciendo que la búsqueda sea más rápida. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !20 Una vez seleccionado el profesor, mostraríamos la docencia que tiene dicho profesor sin firmar, dando la posibilidad de cambiar de profesor si nos hubiésemos equivocado. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Por último, firmaríamos en la tableta igual que en el caso de acreditar asistencia.! !21 Pasando a la tecnología hardware, para ejecutar la aplicación se utiliza un ordenador muy básico (1 GB de memoria RAM, 1.8 GHz de procesador) con Windows, junto con un monitor táctil de 17 pulgadas y un tableta Wacom STU 500 para capturar la firma. ! !28 4.3. Iteraciones! ! El desarrollo del producto estará basado en iteraciones, con reuniones frecuentes con el cliente para recibir feedback de manera rápida. ! La primera iteración estará dedicada a implementar las funcionalidades que pide el product owner, es decir, los casos de uso detallados más arriba. Una vez validadas las funcionalidades, se hará una segunda iteración para mejorar aspectos de la interfaz de usuario. Cuando ésta haya acabado, se pondrá en funcionamiento la aplicación con algunos profesores para obtener feedback de los usuarios. Por último, se hará una tercera iteración para mejorar lo que hayan comentado los usuarios y algunos cambios en al interfaz gráfica. ! 4.3.1. Idea inicial ! La idea inicial del producto es que sea una página web a la que se accederá desde un equipo con pantalla táctil en la consejería de la EII. Desde ahí, los profesores se autentificarán con su usuario y contraseña de MiULPGC. Una vez autentificado, se muestra al profesor su próxima docencia. Este era el concepto que tenía el product owner: !29 ! Con esto en mente, comenzamos a buscar información sobre cómo obtener todos los datos necesarios a través de la ULPGC, es decir, horarios de docencia y un servicio para autentificar al profesorado. ! Para obtener los horarios de docencia, nos pusimos en contacto con el Servicio de Informática de la ULPGC, el cual nos comunicó que no existía aplicación o servicio para obtener esos datos, por lo que nos los debería proporcionar el director de la EII. Contactamos con el product owner, que nos proporciona un fichero Excel con todos los horarios de docencia que luego importamos a una base de datos MySQL proporcionada por la EII. ! Para la autentificación de profesorado el cambio tuvo que ser un poco más radical. Hace pocos meses la ULPGC implantó un nuevo sistema de autentificación, CAS (Central Authentication System), mediante el cual todos los servicios de la universidad que requieran el uso del usuario y contraseña de MiULPGC deben pasar por esa web para autentificarse. Anteriormente existía un servicio de autenticación, pero con este nuevo sistema todas las aplicaciones deben pasar por la web del CAS y trabajar con “tickets” en lugar de usuario/contraseña. ! Este cambio supone una problemática porque, dado que la aplicación que vamos a desarrollar esta pensada para que se ejecute en un ordenador compartido por todo el profesorado, estaríamos continuamente iniciando y cerrando sesión con el CAS, algo que no es lo que queremos. Únicamente necesitamos validar un usuario, no iniciar una sesión para luego cerrarla a los 10 segundos. Además, en conversaciones posteriores con el product owner, llegamos a la conclusión de que introducir diariamente varias veces el usuario y contraseña de MiULPGC en un monitor táctil es un proceso engorroso y peligroso para que otras personas descubran la contraseña. ! Con esto en mente, proponemos al product owner otros métodos para autentificar a los profesores. La idea de tener un PIN para cada profesor no gusta porque al ser una contraseña única para este sistema es más fácil que los profesores la compartan y firmen en nombre de otros. Otra idea planteada fue autentificar mediante una foto, al llegar al monitor se hace una foto y se registra quien firmó la asistencia. Al product owner tampoco le convenció está opción y al final se optó por utilizar una tableta digitalizadora, con la que los profesores firmen la asistencia como si fuera en papel, pero almacenando todo de manera digital. ! ! !30 4.3.2. Iteración 1. Funcionalidades ! Una vez a la semana, aproximadamente, se tenía una reunión con el cliente para validar lo que se iba implementando. De esta forma se iban haciendo cambios muy sencillos sobre la marcha, como por ejemplo el color de alguna parte de la interfaz o que se permitieran firmar asignaturas dentro de un rango de tiempo determinado. Si se hubiese seguido un enfoque de desarrollo en cascada, el cliente hubiese visto el producto terminado al final y probablemente se acumularían los cambios a realizar y no serían tan sencillos. ! Tras las reuniones con el product owner, se llegó a un primer prototipo funcional que tenía la siguiente interfaz. Al arrancar el programa se mostraba esta pantalla que solicitaba el DNI. El teclado se hizo similar al teclado numérico de un ordenador, añadiendo una X para los DNI de extranjeros. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Tras introducir el DNI, se muestra el nombre e imagen de perfil del profesor, junto con las dos opciones disponibles, ver la docencia del día o sustituir. En este caso, si pulsamos “Docencia del día” nos aparece una pantalla vacía porque no tenemos docencia y nos da la opción de volver atrás. ! ! ! ! ! ! ! ! !31 ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !32 ! Al volver a la página de inicio, si pulsamos en “Sustitución” nos aparece la docencia actual, que para nosotros significa que la clase haya empezado como mucho hace 2 horas o dentro de 2 horas. Tenemos un espacio vacío a la derecha que se dejó en blanco para apoyar el dedo en esa zona y realizar un desplazamiento táctil. ! ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Cuando seleccionamos asignaturas, nos permite la opción de firmar, la cual abre una cuadro de diálogo nuevo y activa la tableta digitalizadora. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !33 ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Por último, si hubiese iniciado sesión con un profesor que tuviera docencia en ese momento, la pantalla de “Docencia del día” hubiese tenido este aspecto. ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !34 4.3.3. Iteración 2. Interfaz de usuario ! Una vez creado el primer prototipo con todas las funcionalidades que quería el product owner, nos reunimos con el tutor para conocer su opinión y recibir feedback ya que, a fin de cuentas, el tutor también es un profesor que acabará usando este sistema. ! El tutor propone varios cambios en la interfaz a modo de hacerla más cómoda. Para empezar sugiere colocar el teclado a la izquierda, ya que nuestra forma de lectura es de izquierda a derecha, y colocar los números en orden normal como en una calculadora. También retiramos el concepto de “Control de firmas”, ya que la palabra “control” puede tener una connotación negativa. Añadimos también la hora y el día como información adicional junto con el edificio en el que se encuentra el dispositivo. En esta primera versión mostramos siempre “Edificio de Informática y Matemáticas”, pero cuando se implante en más escuelas universitarias se creará un diálogo que se muestre al iniciar el programa y permita elegir la escuela. ! La pantalla principal queda ahora de esta forma: ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Una vez se inicia sesión, parece lógico pensar que no deberíamos dar la opción de firmar la docencia del día o sustituir. Si el profesor que inicia sesión tiene docencia hoy, primero debe firmar esa docencia. Una vez firmada (o si no tuviese), daremos la opción de sustituir a otro profesor. De esta forma, si iniciamos sesión y tenemos clase nos aparece lo siguiente: ! ! ! ! !35 !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! En cambio, si ya hemos firmado o no tenemos docencia, nos dará la opción de sustituir. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !36 ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !37 Una vez se ha seleccionado al profesor, se muestra su nombre y su foto debajo del profesor que ha iniciado sesión, y se lista la docencia que tiene el profesor sin firmar: ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! En una de las reuniones finales con el product owner, uno de los profesores propuso que la aplicación permitiera enviar notificaciones, en el sentido de que a principio de curso se da mucho que hay problemas con los horarios de docencia y los profesores no tienen su docencia en la hoja. Al product owner le gustó la idea y vimos que incluso sobre la misma tableta digitalizadora se podía escribir un mensaje corto sin mucha complicación. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !44 De forma rápida implementamos esta funcionalidad, que quedó así: ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Al iniciar sesión nos aparece un botón de "Enviar notificación", al pulsar en él nos pide que escribamos nuestro mensaje sobre la tableta y al pulsar terminar, la notificación quedará registrada. ! ! !45 5. Conclusiones! ! La realización del trabajo ha sido bastante satisfactoria ya que se han podido cumplir todos los objetivos propuestos en un principio. ! Desde el punto de vista general del desarrollo de un producto, ha sido interesante ver como ha surgido la propuesta de valor para los usuarios a partir de ellos y no de los desarrolladores. En un principio partíamos de un producto que a los usuarios no aportaba nada; aportaba valor al product owner por los datos que recopilaba, pero no a las personas que usaban el producto. Sin embargo, la puesta en marcha de un primer prototipo y la recolección de feedback por parte de los usuarios hicieron posible descubrir una propuesta de valor que motiva a los usuarios a usar el producto. ! Pasando al desarrollo del producto software, ha sido enriquecedor el desarrollo de un producto real, en el que hemos tenido que ir cambiando las características que habíamos pensado en un principio para adaptarnos a los distintos problemas que aparecían. Además, se ha podido utilizar en parte la metodología de desarrollo guiado por pruebas (TDD) en el desarrollo del modelo de la aplicación. ! Desde un punto de vista de aportaciones administrativas que da el software, se han conseguido implementar las funcionalidades principales que pretendíamos, dando la posibilidad de registrar la asistencia de un profesor a una clase o la sustitución de un profesor a otro. ! El método de desarrollo elegido, basado en el agilismo, ha sido muy provechoso ya que es una manera muy cómoda de trabajar. No definimos en un inicio un conjunto rígido de requisitos y pasados 6 meses entregamos un producto final al product owner. En lugar de eso, el product owner iba viendo semanalmente lo que se iba haciendo y validando las decisiones que se iban tomando, lo que hacía el cambio más rápido que hacer muchos cambios cuando ya el producto está "terminado". ! Entrando en concreto con el desarrollo guiado por pruebas, el hecho de tener pruebas automáticas nos ha dado la seguridad para realizar cambios en el sistema sin miedo, puesto que teníamos los tests que nos detectarían si ha habido un fallo. A modo de resumen, y por relacionar un poco con la descripción que se dio en apartados anteriores, yo diría que hacer TDD me ha aportado: ! •Poder comprobar que todo funciona desde el principio, sin necesidad de tener un método main o una interfaz de usuario. •Poder refactorizar sin miedo algunas secciones de código que en principio eran menos "limpias". •Saber por donde empezar a trabajar y tener un ritmo de trabajo más o menos constante. ! ! ! ! !46 Me hubiese gustado poder aplicarlo al desarrollo de la interfaz, ya que había momentos en los que sí note que hacía cambios en la interfaz con más "miedo" porque tenía que hacer las pruebas a mano y acordarme de todo lo que tenía que probar cada vez que hacía un cambio ya que no tenía pruebas automáticas para validar. En futuros trabajos sería interesante aplicar esta metodología al desarrollo de los otros módulos de una aplicación (interfaz de usuario, control). ! Todo el diseño de la interfaz de usuario se debatió bastante con ambos tutores, y se puede ver como la interfaz tuvo muchas versiones distintas. A lo largo de todas estas versiones hemos intentado conseguir que el software sea lo más usable posible, sin necesidad de un manual de usuario. De hecho, cuando se puso en funcionamiento a modo de prueba, los profesores no tuvieron demasiada dificultad para utilizarlo, y las pocas dificultades que encontraron nos las comentaron para que las pudiéramos solucionar. ! A nivel del código desarrollado, se ha intentado conseguir una arquitectura limpia, con clases que muy rara vez superan las 100 líneas de extensión. Igualmente, no es nuestra intención llegar a una arquitectura y no volver a modificarla nunca. La arquitectura aún puede mejorarse con la intención de hacerla más fácil de entender para futuros desarrolladores que mantengan el programa. Esas es una de las aportaciones que nos da el TDD, poder cambiar el programa sabiendo que no hemos roto nada. ! !47 6. Trabajos futuros! ! ! El desarrollo de este sistema no acaba en el ámbito de este Trabajo de Fin de Grado. Aún faltarían por desarrollar una serie de módulos que hagan uso de la aplicación que se ha desarrollado. ! Para empezar, habría que crear una aplicación que, con los datos recogidos a lo largo de un día lectivo, genere un fichero PDF con las firmas de todos los profesores que han impartido docencia en el día actual. ! También podría ser interesante tener otro pequeño módulo que lo único que haga sea comprobar al final del día si ha habido alguna falta y notificar automáticamente al responsable. Esto también se podría hacer manualmente haciendo una consulta a la base de datos, pero esta forma podría estar automatizada por un lado la creación de PDF's para registrar la asistencia y el responsable del centro solo tiene que preocuparse cuando reciba un correo notificándosele de que ha habido alguna ausencia. ! Por último, de cara a integrar el sistema con toda la universidad, lo ideal sería que el Servicio de Informática de la ULPGC pudiera darnos acceso directo a las bases de datos de la universidad, ya que tendríamos la información actualizada en todo momento. Con el sistema actual, si hubiese un cambio en los horarios, el director de la escuela nos lo tendría que notificar para nosotros actualizar la base de datos interna a la aplicación. Si ya estamos conectados directamente a la universidad, la actualización es inmediata. ! Con respecto al trabajo realizado, también se podrían definir una serie de modificaciones futuras. ! Por ejemplo, el trabajo se ha realizado sobre un ordenador con sistema operativo Windows 7. Uno de los posibles trabajos sería probar la aplicación en otros sistemas operativos para evitar posibles problemas que puedan surgir si al implantarse el sistema en otra escuela universitaria no se usara el mismo sistema operativo. ! Por este mismo motivo también se podrían realizar pruebas con otras configuraciones software, como por ejemplo, modelos distintos de tabletas digitalizadoras, para buscar algunas soluciones hardware más baratas o que los controladores estén disponibles en más sistemas operativos. ! También podrían añadirse otras funcionalidades, como por ejemplo a la hora de sustituir a otro profesor, dar más opciones de filtrado, como el área de conocimiento o un histórico de profesores para que estén más cerca los profesores que son más probables para sustituir. ! Con respecto a las notificaciones, también se podrían hacer modificaciones para elegir el tipo de notificación y hacer un filtrado más efectivo para el responsable de revisar esos datos. De primeras se nos podría ocurrir notificaciones de "Fallo en la docencia" o "Problema en el aula". ! !48 ! Por último, habría que dedicar un tiempo a formar personal para administrar la aplicación si pasase a mantenerla el Servicio de Informática de la ULPGC. Se ha intentado que la arquitectura sea lo más limpia posible para que si el código lo coge otro desarrollador no tenga demasiados problemas, pero siempre es mejor si ese nuevo desarrollador tiene a mano al autor original para comentar dudas. Además, considero que es un proceso beneficioso también para el desarrollador original, ya que recibirá opiniones de otro programador y podrá aprender cosas nuevas para hacer su código más legible.! !49 7. Fuentes de Información! ! A continuación, se citan las fuentes de información utilizadas para el desarrollo del proyecto: ! Relativas al uso de JavaFX ! •Layout docs.oracle.com/javafx/2/layout/builtin_layouts.htm •CSS docs.oracle.com/javafx/2/api/javafx/scene/doc-files/cssref.html •Eventos docs.oracle.com/javafx/2/api/javafx/event/Event.html •Imágenes stackoverflow.com/questions/16990482/java-lang-illegalargumen •Cambios en la IU desde un hilo distinto al principal stackoverflow.com/questions/13784333/platform-runlater-and-taskjavafx •Controladores desde FXML stackoverflow.com/questions/12543487/javafx-nested-controllers-fxmlinclude •Eliminar barra superior de la ventana de la aplicación stackoverflow.com/questions/9861178/javafx-primarystage-removewindows-borders •Texto en varias líneas cuando no cabe en una sola stackoverflow.com/questions/20743668/word-wrapping-inside-atitledpane-that-is-inside-vbox •Capturar cualquier evento en la aplicación docs.oracle.com/javafx/2/events/processing.htm •Capturar evento al cerrar aplicación www.java2s.com/Code/Java/JavaFX/Stagecloseevent.htm ! Otras fuentes referentes al desarrollo ! •Envío de correo desde Java www.mkyong.com/java/javamail-api-sending-email-via-gmail-smtp-example/ •Cargar una DLL en Java blog.cedarsoft.com/2010/11/setting-java-library-path-programmatically/ ! Relativas a normativa y legislación ! •Control de asistencia ULPGC www.ulpgc.es/hege/almacen/download/18/18456/ normas_para_el_control_de_asistenci.pdf •Ley Orgánica de Protección de Datos http://www.agpd.es/portalwebAGPD/jornadas/dia_proteccion_2011/ responsable/index-ides-idphp.php! !50 Anexo A. Manual de instalación! ! La instalación del software en una máquina es un proceso muy sencillo y que se describe a continuación. ! Lo primero que recomendamos es que se desactiven las actualizaciones automáticas en el equipo con Windows, para evitar reinicios inesperados. También sería deseable desactivar el apagado de pantalla automático para que se muestre siempre la pantalla inicial de la aplicación y no se quede en negro. ! En Windows 7, para desactivar las actualizaciones automáticas, debemos ir al Panel de Control y entrar al menú de Windows Update, en la opción Activar o desactivar la actualización automática. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Para desactivar el apagado de la pantalla, también debemos ir al Panel de Control, en Opciones de energía. Desde ahí podemos cambiar la configuración del plan de energía y establecer que la pantalla no se apague nunca y que el equipo no entre en reposo. ! ! ! ! ! ! ! ! ! ! !51 ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! Como requisitos antes de poner en funcionamiento la aplicación, el equipo debe de tener instalado el STU SDK de Wacom en el directorio "C:\Program Files". Tampoco debemos olvidarnos de tener conectada en todo momento la tableta Wacom para realizar las firmas. ! !52 A la hora de arrancar la aplicación, ésta se encuentra dentro de la carpeta "dist" la cual contiene las librerías necesarias y las imágenes de perfil del profesorado. Haciendo doble click sobre el fichero Ruber.jar, la aplicación debería arrancar sin ninguna complicación. !53