Gestión de encuestas

GESTIÓN DE ENCUESTAS VALORACIÓN DOCENTE DEL PROFESORADO Trabajo Fin de Grado Autor: José María Suárez Peret Alumno de la Escuela de Ingeniería de la ULPGC Tutor: Dr. D. Abraham Rodríguez Rodríguez Profesor Titular de Universidad Departamento de Informática y Sistemas de la ULPGC Co-Tutor: Dr. D. Claudio Tascón Trujillo Profesor Titular de Escuela Universitaria Departamento de Psicología y Sociología de la ULPGC Director de Calidad de la ULPGC Las Palmas de Gran Canaria – Septiembre de 2014 TFG: José María Suárez Peret Trabajo Fin de Grado del Grado en Ingeniería en Informática (especialización en Tecnología de la Información) de la Universidad de Las Palmas de Gran Canaria: Alumno: José María Suárez Peret Título del Trabajo: Gestión de encuestas – Valoración docente del profesorado Tutor: Dr. D. Abraham Rodríguez Rodríguez Co-Tutor: Dr. D. Claudio Tascón Trujillo Director de Calidad de la Universidad de Las Palmas de Gran Canaria TFG: José María Suárez Peret “A mis padres por apoyarme y ayudarme durante todos estos años. En especial a mi mujer.” TFG: José María Suárez Peret AGRADECIMIENTOS Antes de comenzar quisiera mostrar mi más sincero agradecimiento a todas las personas que me han apoyado y animado desde que comencé los estudios de Informática hasta el momento actual. Quisiera dar las gracias sobre todo a mi mujer, Yessica L. Galindo Rodríguez quien con su infinita paciencia siempre ha estado ahí para apoyarme, ayudarme y aconsejarme en todo lo que fuera necesario. Como no, agradecer a mi tutor Abraham Rodríguez Rodríguez quién ha estado en todo momento indicándome la forma en que debía realizar el trabajo, así como ayudándome y animándome para hacerlo de la mejor manera posible. También quiero agradecer el apoyo y la colaboración de mi co-tutor Claudio Tascón Trujillo quién desde el principio me ha animado y ayudado con todas las dudas que le he ido planteando. Además, me ha motivado para realizar la adaptación al grado y es el artífice del enfoque de este proyecto. A mis padres y resto de familia, quienes en todo momento me han brindado su apoyo incondicional. Y de entre ellos a mi hermano mellizo Santiago Suárez Peret que realizó los estudios de Informática conmigo y siempre estuvo a mi lado en las largas noches de estudio. Por último, me gustaría mencionar a los profesores que me han formado a lo largo de todos los años de estudio, a mis amigos y compañeros sin cuyas aportaciones no habría enriquecido mi formación. A todos, muchísimas gracias. TFG: José María Suárez Peret RESUMEN En el ámbito del Espacio Europeo de Educación Superior (a partir de ahora EEES), la evaluación de la calidad docente del profesorado es un proceso que deben llevar a cabo fundamentalmente las propias universidades como elemento del sistema de garantía interna de calidad desarrollado en el marco del sistema europeo de calidad. A tal efecto, siguiendo el mandato de la conferencia ministerial de Berlín del año 2003, la European Association for Quality Assurance in Higher Education (a partir de ahora ENQA), en cooperación con la European University Association (a partir de ahora EUA), la European Association of Institutions in Higher Education (a partir de ahora EURASHE) y la National Unions of Students in Europe (a partir de ahora ESIB), propuso los criterios y directrices para la garantía de calidad en el EEES, que fueron adoptados por la conferencia ministerial de Bergen del año 2005. De acuerdo con los mismos, las instituciones de educación superior deben disponer de medios que garanticen que el personal docente esté capacitado y sea competente para su trabajo. Deben disponer de procedimientos de incorporación del profesorado que incluyan medios para verificar que las personas seleccionadas poseen un nivel mínimo de competencia. Deben proporcionar oportunidades a los profesores de bajo rendimiento para que mejoren sus habilidades de forma que alcancen un nivel aceptable, y deben disponer de los medios que permitan darles de baja de sus funciones docentes si continúan siendo ineficaces. Para favorecer esta evaluación de la docencia, la Agencia Nacional de Evaluación de la Calidad y la Acreditación (a partir de ahora ANECA) pone en marcha el Programa de Apoyo a la Evaluación de la Actividad Docente del Profesorado Universitario (a partir de ahora DOCENTIA) con el objeto de apoyar a las universidades en el diseño de mecanismos propios para gestionar la calidad de la actividad docente del profesorado universitario y favorecer su desarrollo y reconocimiento. Un pilar fundamental en este procedimiento son las encuestas que los estudiantes realizan para valorar la calidad docente de sus profesores. El Gabinete de Evaluación Institucional (a partir de ahora GEI) de la Universidad de Las Palmas de Gran Canaria (a partir de ahora ULPGC) es el encargado de gestionar todo el proceso de encuestación y por este motivo, surge la inmensa necesidad de disponer de una aplicación informática que permita hacer un seguimiento de dicho proceso. TFG: José María Suárez Peret 9.2.2.1. Consulta personal ............................................................... 66 9.2.2.2. Consulta general ................................................................ 67 10. PRUEBAS ..................................................................................... 68 10.1. Primera prueba - Boceto básico inicial ......................................... 68 10.2. Segunda prueba – Sistema definitivo ............................................ 70 10.3. Sistema en explotación ........................................................... 72 11. CONCLUSIONES Y TRABAJO FUTURO .................................................... 73 11.1. Conclusiones ........................................................................ 73 11.2. Trabajo futuro ..................................................................... 74 12. BIBLIOGRAFÍA Y REFERENCIAS ............................................................ 76 13. ANEXOS ...................................................................................... 78 13.1. Anexo A: Guía de utilización de la aplicación para los Vicedecanos/ Subdirectores de calidad y encuestadores ................................................ 78 13.1.1. Acceso a la aplicación ............................................................. 78 13.1.2. Listados profesor/asignatura ..................................................... 79 13.1.3. Imprimir listados profesor/asignatura evaluados o no evaluados ........... 81 13.2. Anexo B: Guía de utilización de la aplicación para el administrador ...... 85 13.2.1. Acceso a la aplicación ............................................................. 85 13.2.2. Consulta personal .................................................................. 85 13.2.3. Consulta general ................................................................... 87 13.2.3.1. Información de los profesores desglosada por centro ..................... 88 13.2.3.2. Información de los profesores desglosada por titulación .................. 89 13.2.3.3. Información profesores/asignaturas desglosada por centro .............. 90 13.2.3.4. Información profesores/asignaturas desglosada por titulación........... 91 13.2.3.5. Listado de todos los profesores no evaluados ............................... 93 13.2.3.6. Listado de profesores/asignaturas no evaluados ........................... 93 13.2.3.7. Listado de todos los profesores evaluados .................................. 94 TFG: José María Suárez Peret 13.2.3.8. Listado de profesores/asignaturas evaluados ............................... 95 13.2.3.9. Simulación del acceso de un Vicedecano/Subdirector de calidad o encuestador ................................................................................... 96 13.3. Anexo C: Script SQL de creación de la Base de Datos ........................ 98 TFG: José María Suárez Peret Página 18 de 99 1. INTRODUCCIÓN 1.1. Estado actual En el ámbito del Espacio Europeo de Educación Superior (EEES), la evaluación de la calidad docente del profesorado es un proceso que deben llevar a cabo fundamentalmente las propias universidades como elemento del sistema de garantía interna de calidad desarrollado en el marco del sistema europeo de calidad. A tal efecto, siguiendo el mandato de la conferencia ministerial de Berlín del año 2003, la ENQA, en cooperación con la EUA, la EURASHE y la ESIB, propuso los criterios y directrices para la garantía de calidad en el EEES, que fueron adoptados por la conferencia ministerial de Bergen del año 2005. De acuerdo con los mismos, las instituciones de educación superior deben disponer de medios que garanticen que el personal docente esté capacitado y sea competente para su trabajo. Deben disponer de procedimientos de incorporación del profesorado que incluyan medios para verificar que las personas seleccionadas poseen un nivel mínimo de competencia. Deben proporcionar oportunidades a los profesores de bajo rendimiento para que mejoren sus habilidades de forma que alcancen un nivel aceptable, y deben disponer de los medios que permitan darles de baja de sus funciones docentes si continúan siendo ineficaces. Siguiendo los acuerdos de las conferencia ministeriales y dado que la Ley Orgánica de Modificación de la LOU (LOMLOU) determinó que la garantía de calidad era un fin esencial de la política universitaria, la ANECA, la AQU y la ACSUG, a partir del año 2007, desarrollaron de forma conjunta el programa AUDIT, dirigido a orientar y apoyar a las universidades y a los centros universitarios en el diseño de sistemas de garantía interna de calidad, integrando las actividades relacionadas con la garantía de la calidad de las enseñanzas que ya se venían desarrollando. Por lo que respecta a la calidad de la actividad docente, las directrices incluidas en AUDIT especificaron que las universidades y los centros debían contar con mecanismos que aseguraran que el acceso, la formación, la evaluación, la promoción y el reconocimiento de su personal académico y de apoyo a la docencia se realizase con las debidas garantías para que cumpliera con las funciones que le son propias. La actividad docente es el conjunto de actuaciones que se realizan dentro y fuera de las aulas destinadas a favorecer el aprendizaje de los estudiantes con TFG: José María Suárez Peret Página 19 de 99 relación a los objetivos y competencias definidas en un plan de estudios y en un contexto institucional determinado. Actualmente, la normativa universitaria vigente en España permite que las universidades sean responsables de evaluar la capacitación docente de los candidatos en los procesos de selección del profesorado y de evaluar periódicamente la calidad de la actividad docente que desarrolla el profesorado ya en ejercicio. En el actual ordenamiento del sistema universitario español la garantía de la capacitación y competencia del profesorado descansa en las universidades. Del mismo modo, son las administraciones públicas las que, a través de las agencias de evaluación, aseguran el cumplimiento de unos estándares de calidad básicos entre los que solicitan participar en un proceso de contratación o acceso a la función pública (programas ACADEMIA y PEP) y en el diseño e implantación de las enseñanzas (programa VERIFICA). En la valoración de la garantía de la calidad del profesorado, un elemento que resulta fundamental es el desempeño de su actividad docente. Así, conocer el modo en que el profesor planifica, desarrolla, valora y mejora su enseñanza resulta clave para emitir un juicio sobre su competencia docente. Para favorecer esta evaluación de la docencia, ANECA pone en marcha el Programa de Apoyo a la Evaluación de la Actividad Docente del Profesorado Universitario (DOCENTIA) con el objeto de apoyar a las universidades en el diseño de mecanismos propios para gestionar la calidad de la actividad docente del profesorado universitario y favorecer su desarrollo y reconocimiento. El Programa DOCENTIA toma como referencia igualmente las recomendaciones para la Garantía de Calidad en las instituciones de Educación Superior elaboradas por la European Association for Quality Assurance in Higher Education (ENQA) en su documento Criterios y Directrices para la Garantía de Calidad en el Espacio Europeo de Educación Superior. Entre dichos criterios y directrices destaca el 1.4., Garantía de Calidad del Personal Docente, que establece que las instituciones deben dotarse de medios para garantizar que su personal docente está cualificado y es competente para la docencia. TFG: José María Suárez Peret Página 20 de 99 Asimismo, en el diseño del programa se han tenido en cuenta los estándares establecidos por organizaciones internacionalmente reconocidas en materia de evaluación del personal, como The Personnel Evaluation Standards, elaborados por el The Joint Commite of Standards for Educational Evaluation. Un pilar fundamental en el procedimiento DOCENTIA-ULPGC son las encuestas que los estudiantes realizan para valorar la calidad docente de sus profesores. El Gabinete de Evaluación Institucional (GEI) de la Universidad de Las Palmas de Gran Canaria (ULPGC) es el encargado de gestionar todo el proceso de encuestación y por ese motivo, surge la inmensa necesidad de disponer de una aplicación informática que permita hacer un seguimiento de dicho proceso. Solamente los profesores que tengan al menos una de sus asignaturas con valoración de sus estudiantes podrán optar a los grados de excelencia del Programa DOCENTIA-ULPGC, lo cual viene recogido en el Manual de Procedimiento que se ha aprobado el 16 de junio de 2014 en Consejo de Gobierno de la ULPGC. Por este motivo, es necesario un sistema que asegure, de alguna manera, que todos los profesores tengan al menos una de sus asignaturas con valoración docente de sus estudiantes. 1.2. Estructura del documento La estructura general del presente documento es la siguiente: • Introducción: se realiza una presentación sobre el estado actual de la valoración docente del profesorado. • Objetivos: se especifican los objetivos del Trabajo de Fin de Grado (TFG). • Competencias: se indican las competencias cubiertas con este trabajo especificando los apartados en las que éstas se ven realizadas. • Aportaciones: análisis de las contribuciones que el TFG aporta a nuestro entorno social, científico y técnico. • Normativa: se especifican las normativas y legislaciones que afectan al TFG. TFG: José María Suárez Peret Página 21 de 99 • Metodología: se expone la metodología seguida y la planificación llevada a cabo, a la hora de desarrollar el TFG, para cumplir los objetivos planteados inicialmente. • Análisis: se exponen los recursos y herramientas utilizadas, explicando su funcionamiento, las ventajas que presentan y argumentando su elección. • Requisitos: se especifican los requisitos hardware y software asociados al TFG. • Diseño: se especifican los detalles relativos al diseño de la aplicación desarrollada en este TFG. • Desarrollo: se indican los aspectos relacionados con el desarrollo de la aplicación implementada en este TFG. • Pruebas: especificación de las pruebas realizadas en las diferentes etapas de desarrollo. • Conclusiones: se exponen las conclusiones y posibles líneas de desarrollo futuro a partir del TFG realizado. • Anexos: se indica información adicional. 2. OBJETIVOS DEL TRABAJO 2.1. Objetivos académicos En la realización de este Trabajo de Fin de Grado (TFG), se ha intentado aplicar todos los conocimientos adquiridos en la titulación de Grado en Ingeniería Informática. El objetivo es poder desarrollar las competencias y los conocimientos adquiridos, teóricos y prácticos como culminación de los estudios y como preparación para el desempeño futuro de actividades profesionales en el ámbito correspondiente a la titulación cursada. Para ello se han puesto en práctica los conocimientos de asignaturas tales como: • Metodologías del Desarrollo Ágil • Desarrollo de Aplicaciones Web TFG: José María Suárez Peret Página 22 de 99 • Administración de Sistemas Operativos • Administración y Tecnologías de Seguridad • Bases de Datos • Tecnología Software para el Desarrollo de Sistemas de Información 2.2. Objetivos del trabajo El objetivo principal del Trabajo de Fin de Grado (TFG) es que el Gabinete de Evaluación Institucional (GEI) de la ULPGC, pueda disponer de una aplicación web para poder realizar el seguimiento del proceso de encuestación que se realiza para valorar la actividad docente del profesorado. Esto se debe a que solo los profesores que tengan al menos una de sus asignaturas con valoración de sus estudiantes, podrán optar a los grados de excelencia del Programa DOCENTIA-ULPGC. La aplicación dispondrá de las siguientes características: • Control de permisos de usuarios • Integración en la web institucional de la ULPGC • Acceso mediante MiULPGC • Gestión independiente según perfil de usuario • Informes estadísticos por pantalla • Histórico de resultados por curso académico y semestre • Impresión de listados La aplicación dispone de una interfaz amigable para agilizar y controlar el complicado proceso por el que pasa el Gabinete de Evaluación Institucional (GEI) a la hora de gestionar el proceso de encuestación. Asimismo permite que los Vicedecanos y Subdirectores de Calidad dispongan de una aplicación web donde poder llevar un control de la gestión del proceso realizado en su centro. TFG: José María Suárez Peret Página 23 de 99 3. COMPETENCIAS ESPECÍFICAS A CUBRIR A continuación, se indican las diferentes competencias específicas cubiertas en el presente trabajo. La definición de cada competencia se ha obtenido del proyecto docente de la asignatura “40866-Trabajo Fin de Grado”. 3.1. CII01 Capacidad para diseñar, desarrollar, seleccionar y evaluar aplicaciones y sistemas informáticos, asegurando su fiabilidad, seguridad y calidad, conforme a principios éticos y a la legislación y normativa vigente. Respecto a esta competencia el estudiante deberá: • Analizar: Clasificar e interpretar los hechos y requisitos, diagnostico de problemas y empleo de la información para implementar el sistema o aplicación. Es decir, especificar que es lo que el sistema o aplicación debe hacer. • Diseñar: Especificar las características del producto terminado y establecer cómo alcanzar el objetivo propuesto. • Desarrollar: Implementar el sistema o aplicación mediante el uso de los conocimientos adquiridos y herramientas utilizadas, investigar sobre las posibles debilidades del sistema para aumentar su seguridad y generar el código sometiéndolo a refactorización para asegurar su calidad. Esta competencia ha sido desarrollada a lo largo del documento en los capítulos de “Introducción”, “Objetivos”, “Análisis”, “Requisitos”, “Diseño” y “Desarrollo” (apartados 1, 2, 7, 8, 9 y 10, respectivamente). 3.2. CII02 Capacidad para planificar, concebir, desplegar y dirigir proyectos, servicios y sistemas informáticos en todos los ámbitos, liderando su puesta en marcha y su mejora continua y valorando su impacto económico y social. TFG: José María Suárez Peret Página 24 de 99 El proceso de gestión de un proyecto de software comienza con un conjunto de actividades que, globalmente, se denominan planificación del proyecto. No podemos pedir exactitud a la fase de planificación, es solo una idea de cómo van a transcurrir las cosas. Hay que planificar el trabajo, los recursos humanos y la tecnología. En informática, no podemos fiarnos de la intuición, una buena planificación acaba permitiendo abordar un proyecto y ayuda al proceso de refinamiento. Respecto a esta competencia, la buena planificación de este TFG ha dado lugar a que la aplicación se haya terminado y puesto en marcha en los plazos establecidos cumpliendo con los objetivos iniciales que se habían planificado. En el apartado 6 “Metodología” se especifica el sistema de organización utilizado para alcanzar los objetivos propuestos y en el apartado 4 “Aportaciones” se puede apreciar el impacto en el ámbito social y económico. 3.3. CII04 Capacidad para elaborar el pliego de condiciones técnicas de una instalación informática que cumpla los estándares y normativas vigentes. En un Pliego de Condiciones se indica cómo y con qué hay que hacer realidad los proyectos de obras y servicios que se contratan. El Pliego que se concuerda y firma, contiene las relaciones que existirán y que tienen que cumplirse, entre el propietario y el ejecutor de cualquier proyecto, servicio o concesión administrativa. El documento debe contener toda la información necesaria para que el proyecto llegue a buen fin, indicando las condiciones generales del trabajo, los términos de confidencialidad, los derechos, obligaciones y responsabilidades de las partes que lo suscriben. También hay que indicar como se desarrollará el trabajo, la duración del mismo, los requisitos técnicos y cualquier condición adicional que se considere pertinente. A continuación se indica un modelo a título de ejemplo de un pliego de condiciones: TFG: José María Suárez Peret Página 25 de 99 PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA CONTRATACIÓN DE LOS SERVICIOS PARA LA REALIZACIÓN DE UNA APLICACIÓN WEB CONCEBIDA PARA REALIZAR LA GESTIÓN DE ENCUESTAS DE LA VALORACIÓN DOCENTE DEL PROFESORADO PARA LA ULPGC. 3.3.1. OBJETO DEL PROCEDIMIENTO DE CONTRATACIÓN FINALIDAD DE LA CONTRATACIÓN El proceso de encuestación que se realiza para valorar la calidad docente de la ULPGC, es gestionado por el Gabinete de Evaluación Institucional y por los Vicedecanos y Subdirectores de calidad de los centros. La falta de aplicaciones web para poder realizar esta gestión hace que surja la necesidad de adquirir alguna. OBJETO El presente pliego tiene por objeto la contratación de los servicios del adjudicatario para comenzar con el desarrollo de una aplicación web que permita la gestión del proceso de encuestación de la valoración docente del profesorado. El pliego definirá las prescripciones técnicas para conseguirlo. CONFIDENCIALIDAD El adjudicatario quedará obligado al cumplimiento de lo dispuesto en la Ley orgánica 15/1999 de 13 de Diciembre, de Protección de Datos de Carácter Personal y sus disposiciones de desarrollo. Su aceptación implicará su obligación a mantener completa y absoluta confidencialidad y reserva sobre cualquier dato que pudiese llegar a conocer a lo largo del desarrollo del contrato, teniendo especial atención a los de carácter personal. Asimismo, se deberá abstener de copiar o utilizar dichos datos con un fin distinto al establecido en este pliego. TRANSFERENCIA DE DATOS Durante la ejecución de los trabajos objeto del contrato, el adjudicatario se compromete a facilitar en todo momento a las personas designadas por la ULPGC TFG: José María Suárez Peret Página 32 de 99 bases de datos de la ULPGC y la forma de programar para que la aplicación pueda integrarse dentro de la web institucional. Este proyecto ha despertado en mí un objetivo personal que me gustaría cumplir. Se trata de comprobar si realmente la solución planteada cumple, en el Gabinete de Evaluación Institucional (GEI) de la ULPGC, el objetivo buscado y si la aplicación proporciona la utilidad para la que ha sido desarrollada. Si esto se cumple, podría estudiarse la posibilidad de implantar mejoras en la aplicación, así como futuros proyectos fin de carrera. El TFG ha sido una gran oportunidad para poder poner en práctica los conocimientos adquiridos a lo largo de la carrera. Además, la experiencia en sí del proyecto, la oportunidad de tomar decisiones que afectan a un producto que será puesto en explotación en la ULPGC y que requerirá de un mantenimiento, es un reto importante que estoy dispuesto a asumir. 5. NORMATIVA Este capítulo expone la normativa y legislación que afecta al TFG a fin de satisfacer la competencia CII18. 5.1. Normativa La Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal tiene por objeto garantizar y proteger, en lo que concierne al tratamiento de los datos personales, las libertades públicas y los derechos fundamentales de las personas físicas y, especialmente, de su honor e intimidad personal y familiar. Principalmente afecta al presente proyecto los artículos que se enumeran a continuación. Artículo 4. Calidad de los datos: 1. Los datos de carácter personal sólo se podrán recoger para su tratamiento, así como someterlos a dicho tratamiento, cuando sean adecuados, pertinentes y no excesivos en relación con el ámbito y las finalidades determinadas, explícitas y legítimas para las que se hayan obtenido. 2. Los datos de carácter personal objeto de tratamiento no podrán usarse para finalidades incompatibles con aquellas para las que los datos hubieran sido TFG: José María Suárez Peret Página 33 de 99 recogidos. No se considerará incompatible el tratamiento posterior de éstos con fines históricos, estadísticos o científicos. 3. Los datos de carácter personal serán exactos y puestos al día de forma que respondan con veracidad a la situación actual del afectado. 4. Si los datos de carácter personal registrados resultaran ser inexactos, en todo o en parte, o incompletos, serán cancelados y sustituidos de oficio por los correspondientes datos rectificados o completados, sin perjuicio de las facultades que a los afectados reconoce el artículo 16. 5. Los datos de carácter personal serán cancelados cuando hayan dejado de ser necesarios o pertinentes para la finalidad para la cual hubieran sido recabados o registrados. No serán conservados en forma que permita la identificación del interesado durante un período superior al necesario para los fines en base a los cuales hubieran sido recabados o registrados. Reglamentariamente se determinará el procedimiento por el que, por excepción, atendidos los valores históricos, estadísticos o científicos de acuerdo con la legislación específica, se decida el mantenimiento íntegro de determinados datos. 6. Los datos de carácter personal serán almacenados de forma que permitan el ejercicio del derecho de acceso, salvo que sean legalmente cancelados. 7. Se prohíbe la recogida de datos por medios fraudulentos, desleales o ilícitos. Artículo 9. Seguridad de los datos: 1. El responsable del fichero, y, en su caso, el encargado del tratamiento deberán adoptar las medidas de índole técnica y organizativas necesarias que garanticen la seguridad de los datos de carácter personal y eviten su alteración, pérdida, tratamiento o acceso no autorizado, habida cuenta del estado de la tecnología, la naturaleza de los datos almacenados y los riesgos a que estén expuestos, ya provengan de la acción humana o del medio físico o natural. 2. No se registrarán datos de carácter personal en ficheros que no reúnan las condiciones que se determinen por vía reglamentaria con respecto a su integridad y seguridad y a las de los centros de tratamiento, locales, equipos, sistemas y programas. TFG: José María Suárez Peret Página 34 de 99 Artículo 11. Comunicación de datos: 1. Los datos de carácter personal objeto del tratamiento solo podrán ser comunicados a un tercero para el cumplimiento de fines directamente relacionados con las funciones legítimas del cedente y del cesionario con el previo consentimiento del interesado. 2. El consentimiento exigido en el apartado anterior no será preciso: a. Cuando la cesión está autorizada en una ley. b. Cuando se trate de datos recogidos de fuentes accesibles al público. c. Cuando el tratamiento responda a la libre y legítima aceptación de una relación jurídica cuyo desarrollo, cumplimiento y control implique necesariamente la conexión de dicho tratamiento con ficheros de terceros. En este caso la comunicación sólo será legítima en cuanto se limite a la finalidad que la justifique. d. Cuando la comunicación que deba efectuarse tenga por destinatario al Defensor del Pueblo, el Ministerio Fiscal o los Jueces o Tribunales o el Tribunal de Cuentas, en el ejercicio de las funciones que tiene atribuidas. Tampoco será preciso el consentimiento cuando la comunicación tenga como destinatario a instituciones autonómicas con funciones análogas al Defensor del Pueblo o al Tribunal de Cuentas. e. Cuando la cesión se produzca entre Administraciones públicas y tenga por objeto el tratamiento posterior de los datos con fines históricos, estadísticos o científicos. f. Cuando la cesión de datos de carácter personal relativos a la salud sea necesaria para solucionar una urgencia que requiera acceder a un fichero o para realizar los estudios epidemiológicos en los términos establecidos en la legislación sobre sanidad estatal o autonómica. 3. Será nulo el consentimiento para la comunicación de los datos de carácter personal a un tercero, cuando la información que se facilite al interesado no le permita conocer la finalidad a que destinarán los datos cuya comunicación se autoriza o el tipo de actividad de aquel a quien se pretenden comunicar. 4. El consentimiento para la comunicación de los datos de carácter personal tiene también un carácter de revocable. TFG: José María Suárez Peret Página 35 de 99 5. Aquel a quien se comuniquen los datos de carácter personal se obliga, por el solo hecho de la comunicación, a la observancia de las disposiciones de la presente Ley. 6. Si la comunicación se efectúa previo procedimiento de disociación, no será aplicable lo establecido en los apartados anteriores. Artículo 12. Acceso a los datos por cuenta de terceros: 1. No se considerará comunicación de datos el acceso de un tercero a los datos cuando dicho acceso sea necesario para la prestación de un servicio al responsable del tratamiento. 2. La realización de tratamientos por cuenta de terceros deberá estar regulada en un contrato que deberá constar por escrito o en alguna otra forma que permita acreditar su celebración y contenido, estableciéndose expresamente que el encargado del tratamiento únicamente tratará los datos conforme a las instrucciones del responsable del tratamiento, que no los aplicará o utilizará con fin distinto al que figure en dicho contrato, ni los comunicará, ni siquiera para su conservación, a otras personas. En el contrato se estipularán, asimismo, las medidas de seguridad a que se refiere el artículo 9 de esta Ley que el encargado del tratamiento está obligado a implementar. 3. Una vez cumplida la prestación contractual, los datos de carácter personal deberán ser destruidos o devueltos al responsable del tratamiento, al igual que cualquier soporte o documentos en que conste algún dato de carácter personal objeto del tratamiento. 4. En el caso de que el encargado del tratamiento destine los datos a otra finalidad, los comunique o los utilice incumpliendo las estipulaciones del contrato, será considerado también responsable del tratamiento, respondiendo de las infracciones en que hubiera incurrido personalmente. Articulo 16. Derecho de rectificación y cancelación: a) El responsable del tratamiento tendrá la obligación de hacer efectivo el derecho de rectificación o cancelación del interesado en el plazo de diez días. b) Serán rectificados o cancelados, en su caso, los datos de carácter personal cuyo tratamiento no se ajuste a lo dispuesto en la presente Ley y, en particular, cuando tales datos resulten inexactos o incompletos. TFG: José María Suárez Peret Página 36 de 99 c) La cancelación dará lugar al bloqueo de los datos, conservándose únicamente a disposición de las Administraciones públicas, Jueces y Tribunales, para la atención de las posibles responsabilidades nacidas del tratamiento, durante el plazo de prescripción de estas. Cumplido el citado plazo deberá procederse a la supresión. d) Si los datos rectificados o cancelados hubieran sido comunicados previamente, el responsable del tratamiento deberá notificar la rectificación o cancelación efectuada a quien se hayan comunicado, en el caso de que se mantenga el tratamiento por este último, que deberá también proceder a la cancelación. e) Los datos de carácter personal deberán ser conservados durante los plazos previstos en las disposiciones aplicables o, en su caso, en las relaciones contractuales entre la persona o entidad responsable del tratamiento y el interesado. 5.2. Base de datos La Base de Datos del TFG implementado almacena diversa información sensible de los distintos usuarios. Esta información es: DNIs, teléfonos, etc. Debido a esto, el Servicio de Informática (SI) de la ULPGC extrema la seguridad para que se cumpla el artículo 9 de la LOPDCP “El responsable del fichero, y, en su caso, el encargado de tratamiento deberán adoptar las medidas de índole técnica y organizativas necesarias que garanticen la seguridad de los datos de carácter personal y eviten su alteración, pérdida, tratamiento acceso no autorizado…”. La Base de Datos es proporcionada por el Servicio de Informática de la ULPGC y está alojada en sus servidores. Asimismo, este servicio es el encargado de realizar las copias de seguridad y de asegurar la privacidad de todos los datos impidiendo que un usuario, sin las credenciales ni permisos correspondientes, consiga conectarse deliberadamente al servidor, acto considerado como delito informático. TFG: José María Suárez Peret Página 37 de 99 6. METODOLOGÍA 6.1. Desarrollo incremental Harold S. Geneen1 Las metodologías de desarrollo de software son un conjunto de procedimientos, técnicas y ayudas a la documentación para el desarrollo de productos software. dijo: “Para leer un libro, se va del principio al fin. Para dirigir una empresa, se va exactamente al revés, se empieza por los fines y luego se hace lo necesario para conseguirlos”. En nuestro caso podemos pensar de forma parecida, para realizar un proyecto, empezaremos por ver cuáles son los objetivos que queremos alcanzar y luego pensaremos que cosas tenemos que hacer para alcanzar estos fines. Es como un libro de recetas de cocina, en el que se van indicando paso a paso todas las actividades a realizar para lograr el producto informático deseado. Es imprescindible considerar los riesgos, aunque habitualmente las empresas, no han sido concienciadas de los riesgos inherentes al procesamiento de la información mediante ordenadores, a lo que han contribuido, a veces, los propios responsables de informática, que no han sabido explicar con la suficiente claridad las consecuencias de una política de seguridad insuficiente o incluso inexistente. Por otro lado, debido a una cierta deformación profesional en la aplicación de los criterios de coste/beneficio, el directivo desconocedor de la informática no acostumbra a autorizar inversiones que no lleven implícito un beneficio demostrable, tangible y mensurable. En ingeniería del software aproximadamente cada década aparece un nuevo tipo de metodologías. En los 70 del siglo pasado, fue el desarrollo estructurado frente al tradicional. En los 80, el desarrollo dirigido por datos frente al tradicional. El los 90, el desarrollo orientado a objetos frente al tradicional y al dirigido por datos. Y a principios de los 2000, el ágil frente al desarrollo tradicional y el CMMI. La metodología a usar en el desarrollo de este proyecto partirá del modelo de desarrollo incremental, también conocido como iterativo y creciente. El modelo incremental es una evolución del modelo de cascada. Viene a suplir el problema de no poder retroceder en las fases de desarrollo del software. Es, por tanto, un modelo no secuencial. 1 Harold S. Gennen, fue presidente de la empresa transnacional ITT Corporation. TFG: José María Suárez Peret Página 38 de 99 El funcionamiento es sencillo. Se comienza con el análisis de los requisitos, tras el cual se prepara un primer diseño. La novedad de este modelo respecto del anterior, es la introducción de iteraciones para “bifurcar” diseños. Es decir, este modelo ofrece la posibilidad de comenzar un diseño, arquitectura, estructura, etc., del software, que de no convencer al cliente (o al propio programador) es rechazado y se comienza con una segunda iteración (o un segundo diseño), sin necesidad de realizar un nuevo análisis de requisitos. Pueden realizarse tantas iteraciones (también llamadas incrementos) como sean necesarias. Los pasos claves en el proceso son comenzar con una implementación simple de los requerimientos del sistema, e iterativamente mejorar la secuencia evolutiva de versiones hasta que el sistema completo este implementado. En cada iteración, se realizan cambios en el diseño y se agregan nuevas funcionalidades y capacidades al sistema. El proceso en si mismo consiste en crear una versión del sistema. La meta de esta etapa es crear un producto con el que el usuario pueda interactuar, y por ende retroalimentar el proceso. Para guiar el proceso de iteración, se crea una lista de control de proyecto y esta lista contiene un historial de todas las tareas que necesitan ser realizadas. Esta lista de control se revisa periódica y constantemente como resultado de la fase de análisis. El código puede, en ciertos casos, representar la mayor fuente de documentación del sistema. El análisis de una iteración se basa en la retroalimentación del usuario y en el análisis de las funcionalidades disponibles del programa. Involucra el análisis de la estructura, modularidad, usabilidad, confiabilidad, eficiencia y eficacia. 6.2. Plan de trabajo y temporización El Plan de Trabajo a seguir durante el desarrollo del TFG propuesto se desglosa en las siguientes etapas: 1. Organización y preparación Comenzaremos el proyecto afinando los detalles del mismo mediante la captación de requisitos. Para ello utilizaremos las entrevistas personales con los responsables del Gabinete de Evaluación Institucional. TFG: José María Suárez Peret Página 39 de 99 2. Análisis del sistema Se decidirá qué herramientas utilizar, así como el lenguaje de programación y se contactará con el Servicio de Informática de la ULPGC para inspeccionar los diferentes recursos de los que se dispone para implementar el sistema. 3. Diseño del sistema Se establecerán las estructuras de datos, la arquitectura general del software, las representaciones de la interfaz y los algoritmos. 4. Implementación del sistema En esta etapa implementaremos el código en base a la etapa anterior, usando las herramientas disponibles en la ULPGC. 5. Fase de pruebas Al finalizar la implementación de las funcionalidades requeridas, se procederá a realizar las pruebas pertinentes. 6. Documentación y defensa Se realizará el documento de trabajo de fin de grado a partir de toda la documentación recogida a lo largo de las diferentes etapas. Asimismo se preparará la defensa del trabajo con el tutor asignado. Temporización En este apartado se detalla el tiempo que se ha tardado en realizar el proyecto. El proyecto se puede dividir en cinco fases o procesos: a) Una primera fase de asimilación y selección de la información más importante, evitando repetir contenidos b) Una segunda fase de diseño de la aplicación. c) Una tercera fase donde se desarrolla la aplicación. d) Una cuarta fase en la que se realizan las pruebas. e) Una quinta fase en la que se ha confeccionado la memoria y toda la documentación. TFG: José María Suárez Peret Página 40 de 99 A continuación puede verse la imagen 1 donde se observa la duración de cada fase en el proceso de elaboración del proyecto. Imagen 1 – Temporización del proyecto La duración total del proyecto ha sido de diez meses. La primera fase se ha extendido desde septiembre hasta octubre del año 2013. La segunda fase desde septiembre hasta finales de noviembre del año 2013. La tercera fase desde octubre hasta finales de diciembre del año 2013. La cuarta fase desde noviembre del año 2013 hasta finales de marzo del año 2014 y la quinta fase desde marzo del año 2014 hasta finales de junio del año 2014. 7. ANÁLISIS Lo primero que debemos hacer para construir un proyecto es averiguar qué es exactamente lo que tiene que hacer el sistema. La etapa de análisis en el ciclo de vida del software corresponde al proceso mediante el cual se intenta descubrir qué es lo que realmente se necesita y se llega a una comprensión adecuada de los requerimientos del sistema (las características que el sistema debe poseer). • ¿Por qué resulta esencial la etapa de análisis? Simplemente, porque si no sabemos con precisión qué es lo que se necesita, ningún proceso de desarrollo nos permitirá obtenerlo. • ¿Por qué es tan importante averiguar exactamente cuáles son los requerimientos del sistema si el software es fácilmente maleable (aparentemente)? Porque el coste de construir correctamente un sistema de información a la primera es mucho menor que el coste de construir un sistema que habrá que modificar más adelante. Cuanto antes se detecte un error, TFG: José María Suárez Peret Página 41 de 99 mejor. Distintos estudios han demostrado que eliminar un error en las fases iniciales de un proyecto (en la etapa de análisis) resulta de 10 a 100 veces más económico que subsanarlo al final del proyecto. Conforme avanza el proyecto, el software se va describiendo con un mayor nivel de detalle, se concreta cada vez más y se convierte en algo cada vez más rígido. Durante los cursos académicos 2008/09, 2009/2010 y 2010/2011, el proceso de encuestación se realizó de manera online. Una vez analizados los datos por el Gabinete de Evaluación Institucional se pudo observar que, año tras año, la participación del alumnado era muy baja y por lo tanto los resultados de las encuestas muy poco significativos. Debido a esto, y siguiendo las recomendaciones de la ANECA, el Vicerrectorado de Calidad e Innovación Educativa decidió que el proceso de encuestación se llevara a cabo mediante encuestas presenciales que los alumnos deberían de cumplimentar en horarios de clase. Este acontecimiento hizo que el Gabinete de Evaluación Institucional trasladara a los Vicedecanos y Subdirectores de calidad de los centros la responsabilidad de gestionar todo el proceso de encuestación de su centro. Por este motivo, surge la necesidad de una aplicación web que permita la gestión del proceso de encuestación de tal forma que, los responsables del proceso puedan llevar un control del mismo y a su vez, los encuestadores, puedan acceder a toda la información que necesitan. Lo más importante es que tal y como recoge el Manual de Procedimiento del Programa DOCENTIA-ULPGC, solo los profesores que tengan al menos una de sus asignaturas con valoración de sus estudiantes podrán optar a los grados de excelencia de dicho programa. Por lo tanto, es necesario disponer de un sistema que intente asegurarlo. 7.1. Actores En la siguiente tabla se indican los actores que interactúan con el sistema y su descripción. TFG: José María Suárez Peret Página 48 de 99 • El diseño procedimental transforma los elementos estructurales en una descripción procedimental del software. Luego se genera el código fuente y, para integrar y validar el software, se llevan a cabo las pruebas. El diseño debe contemplar todos los requisitos explícitos obtenidos en la fase de análisis, debe ser una guía que puedan leer y entender los que construyen, prueban y mantienen el software y debe proporcionar una idea completa de la aplicación o del sistema. Desde el punto de vista de la gestión del proyecto, el diseño del software se realiza en dos etapas: el diseño preliminar y el diseño detallado. • El diseño preliminar se centra en la transformación de los requisitos en los datos y la arquitectura del software. • El diseño detallado se ocupa del refinamiento y de la representación arquitectónica que lleva a una estructura de datos refinada y a las representaciones algorítmicas del software. Además del diseño de datos, del diseño arquitectónico y del desarrollo procedimental, muchas aplicaciones modernas requieren un diseño de la interfaz. Imagen 4 – Relación entre los puntos de vista de gestión y técnicos El sistema desarrollado se trata de una aplicación web en la que se ha utilizado la arquitectura de tipo cliente-servidor y para el acceso a la aplicación se utiliza el sistema MiULPGC. TFG: José María Suárez Peret Página 49 de 99 8.2. MiULPGC Se trata de un proyecto puesto en marcha por la Universidad de Las Palmas de Gran Canaria en el curso 2002/03 para afrontar los avances en las tecnologías de la información y comunicación y facilitar las tareas administrativas en la ULPGC. Se trata de un instrumento que pretende unificar el acceso a todas las aplicaciones desarrolladas en los ámbitos de investigación, docencia, estudio y gestión. El acceso a MiULPGC está restringido a los miembros de la comunidad universitaria de la Universidad de Las Palmas de Gran Canaria, que para acceder a él deben utilizar un nombre de usuario y una contraseña personales. Por tratarse de una intranet en la que cada persona se identifica con su nombre de usuario y contraseña personales, MiULPGC ofrece los servicios según el perfil de cada usuario en la Universidad de Las Palmas de Gran Canaria Por defecto, MiULPGC dispone de tres perfiles diferentes: Estudiante, Personal Docente e Investigador (PDI) y Personal de Administración y Servicios (PAS). Un usuario puede estar autorizado a acceder a MiULPGC en más de un perfil, si procede. Dentro de su perfil, cada usuario puede disponer de algunas aplicaciones específicas 8.3. Arquitectura Cliente-Servidor La tecnología Cliente/Servidor es el procesamiento cooperativo de la información por medio de un conjunto de procesadores, en el cual múltiples clientes, distribuidos geográficamente, solicitan requerimientos a uno o más servidores centrales. Desde el punto de vista funcional, se puede definir la computación Cliente/Servidor como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información de forma transparente aún en entornos multiplataforma. Se trata pues, de la arquitectura más extendida en la realización de Sistemas Distribuidos. Un sistema Cliente/Servidor es un Sistema de Información distribuido basado en las siguientes características: TFG: José María Suárez Peret Página 50 de 99 • Servicio: unidad básica de diseño. El servidor los proporciona y el cliente los utiliza. • Recursos compartidos: Muchos clientes utilizan los mismos servidores y, a través de ellos, comparten tanto recursos lógicos como físicos. • Protocolos asimétricos: Los clientes inician “conversaciones”. Los servidores esperan su establecimiento pasivamente. • Transparencia de localización física de los servidores y clientes: El cliente no tiene por qué saber dónde se encuentra situado el recurso que desea utilizar. • Independencia de la plataforma HW y SW que se emplee. • Sistemas débilmente acoplados. Interacción basada en envío de mensajes. • Encapsulamiento de servicios. Los detalles de la implementación de un servicio son transparentes al cliente. • Escalabilidad horizontal (añadir clientes) y vertical (ampliar potencia de los servidores). • Integridad: Datos y programas centralizados en servidores facilitan su integridad y mantenimiento. Se denomina cliente al proceso que inicia el diálogo o solicita los recursos y servidor al proceso que responde a las solicitudes. El Esquema de funcionamiento de un Sistema Cliente/Servidor sería: a) El cliente solicita una información al servidor. b) El servidor recibe la petición del cliente. c) El servidor procesa dicha solicitud. d) El servidor envía el resultado obtenido al cliente. e) El cliente recibe el resultado y lo procesa. 8.4. Base de Datos La base de datos utilizada es la que el Servicio de Informática de la ULPGC ha proporcionado al Gabinete de Evaluación Institucional. Se trata por tanto, de una base de datos que contiene datos institucionales y cuya seguridad, copias de seguridad y protección de datos es responsabilidad de dicho servicio. TFG: José María Suárez Peret Página 51 de 99 8.5. Tablas Para cada curso que se valora, se crea una tabla de datos y una tabla de permisos. Esto se hace para poder mantener un histórico, en tablas, de los datos y permisos que se utilizan en un curso académico. El esquema general de las tablas utilizadas es el siguiente, donde XXYY son los últimos dos dígitos de los cursos académicos que se valoran: Imagen 5 – Tabla Permisos_Prof_Eva_Enc_XXYY Imagen 6 – Tabla Prof_Eva_Enc_XXYY A continuación se detallarán cada una de las tablas de la base de datos: • Permisos_Prof_Eva_Enc_XXYY: Tabla donde se almacenan todos los usuarios que tienen permisos para acceder a la aplicación web. Se distingue si se trata de un Vicedecano/Subdirector de calidad o de un TFG: José María Suárez Peret Página 52 de 99 encuestador. De esta forma, se tiene localizado quién es el responsable del proceso de encuestación en cada centro y a su vez en cada titulación • Prof_Eva_Enc_XXYY: Tabla donde se almacenan los datos de los profesores que se van a valorar y sus asignaturas. La información se encuentra almacenada por centro, titulación, asignatura que imparte el profesor y semestre en el que se imparte la asignatura. Además, esta misma tabla se utiliza para distinguir si un profesor ha sido valorado en alguna de sus asignaturas por sus estudiantes y quién es el responsable que ha indicado, en la aplicación web, que ha sido así. Al ser esta una aplicación web integrada en la página de la ULPGC, la base de datos y tablas que se utilizan para acceder a la intranet de la web de la Universidad, utilizando el sistema de acceso MiULPGC2 No obstante, hay que indicar que se utiliza el campo de identificación de las tablas del Servicio de Informática para comprobar si el usuario registrado es miembro de la comunidad universitaria y por lo tanto, si tiene los permisos adecuados, podrá acceder a la aplicación web desarrollada para este proyecto de fin de grado. , son propiedad del Servicio de Informática y por lo tanto, por seguridad, no es posible indicar la estructura de las mismas en este documento. 8.6. Estructura de la aplicación Al ser una aplicación integrada en la web de la ULPGC, la estructura general del sistema se encuentra almacenada en el servidor institucional. Todas las páginas desarrolladas en el lenguaje de programación php, se almacenan en un directorio específico del servidor y se utiliza el software Filezilla para realizar la “subida ftp” desde el ordenador local. Para almacenar las páginas en la web de la ULPGC de tal forma que estas queden integradas, se utiliza el sistema HEGE3 2 MiULPGC: Sistema de acceso restringido, a la intranet de la web de la ULPGC, propiedad del Servicio de Informática. ULPGC. 3 HEGE: es una HErramienta de GEstión de contenidos que permite publicar y gestionar contenidos en la Web institucional de la ULPGC. TFG: José María Suárez Peret Página 53 de 99 Por otro lado, la hoja de estilo “CSS” que se ha utilizado es la misma que utiliza la propia web de la institución. Esta se encuentra definida y custodiada por el Servicio de Informática de la ULPGC. 8.6.1. Arquitectura implementada La aplicación web se ha desarrollado mediante programación php integrada en código HTML utilizando una arquitectura en dos capas. La arquitectura en dos capas es conocida también como la arquitectura tradicional de cliente/servidor. Requiere una interfaz de usuario que se instala y corre en una PC o estación de trabajo y envía solicitudes a un servidor para ejecutar operaciones complejas. Por ejemplo, una estación de trabajo utilizada como cliente puede correr una aplicación de interfaz de usuario que interroga a un servidor central de bases de datos. Imagen 7 – Esquema de arquitectura Cliente/Servidor clásica. La principal ventaja de una arquitectura de dos capas es que permite que el software de terceros pueda acceder a la base de datos. La visualización y el software de proceso no necesitan ser incluidos con el sistema de gestión de base de datos. Esta configuración es común en las hojas de cálculo que leen los datos de una base de datos central, o donde el software de generación de informes de datos accede a través de puntos de vista pre-organizados en los datos. El sistema de dos capas permite que los datos de diferentes fuentes se agrupen y se fusionen, erradicando la redundancia de datos y permitiendo que los diferentes usuarios se beneficien de los datos agrupados. TFG: José María Suárez Peret Página 54 de 99 La principal desventaja es que las arquitecturas de dos capas requieren de un control excesivo de las versiones y demandan un esfuerzo de distribución de la aplicación cuando a esta se le hacen cambios. Por otro lado, la seguridad del sistema en un diseño de dos capas es compleja y a menudo requiere de una administración de las bases de datos, debido al número de dispositivos con acceso directo a ella. Además, las herramientas del cliente y de la base de datos, utilizadas en arquitecturas de dos capas, están cambiando constantemente por lo que la dependencia a largo plazo de cualquier herramienta puede complicar el escalamiento o implementaciones futuras. En la aplicación desarrollada, el cliente interactúa con la interfaz desarrollada mediante un explorador web y los datos se muestran mediante consultas a la base de datos que se encuentra alojada en el servidor institucional de la ULPGC. Los módulos implementados son los que se muestran a continuación: Administrador • indexsupgevadoc: Módulo que muestra la pantalla inicial del administrador para que seleccione el tipo de consulta que desea hacer. Estas pueden ser: Una consulta personal o una consulta general. • supgpevadoc: Módulo que permite que el administrador realice una consulta personal. En este tipo de consulta se pueden ver las encuestas realizadas, y no realizadas, de un profesor determinado. • supggevadoc: Módulo que permite que el administrador realice una consulta general. En este tipo de consulta se puede ver la cantidad de profesores evaluados, o no evaluados, en todos los centros y titulaciones. Además se puede simular la entrada al sistema de un usuario registrado como Vicedecano/Subdirector de calidad o encuestador. TFG: José María Suárez Peret Página 55 de 99 Imagen 8 – Módulos implementados. Rol administrador. Vicedecano/Subdirector de calidad o encuestador • indexapenc: Módulo que muestra la pantalla inicial de acceso a la aplicación. • profevaenc1: Módulo que permite seleccionar en qué titulación se quiere llevar el control del proceso de encuestación o imprimir un listado. • profevaenc2: Módulo que muestra todos los profesores y sus asignatura para poder llevar el control del proceso de encuestación. • listadosevaenc1: Módulo que permite seleccionar que listado se quiere imprimir. Profesores evaluados o profesores no evaluados y todos o algunos. • listadosevaenc2: Módulo que muestra el listado que se quiere imprimir. • insprofevaenc: Módulo que interactúa con la base de datos de la aplicación actualizando los datos de los profesores según se vaya indicando, en la aplicación, que ha sido evaluado o no en una asignatura. • errorevaenc: Módulo que muestra un error de acceso a los usuarios no registrados. • ayudaprofenc: Módulo que muestra una pequeña ayuda para interactuar con la aplicación. TFG: José María Suárez Peret Página 56 de 99 Imagen 9 – Módulos implementados. Rol Vicedecano/Subdirector de calidad o encuestador. 8.7. Interfaz Cuando se habla de Sitios Web, se denomina interfaz al conjunto de elementos de la pantalla que permiten al usuario realizar acciones sobre el Sitio Web que está visitando. Por lo mismo, se considera parte de la interfaz a sus elementos de identificación, de navegación, de contenidos y de acción. Todos ellos deben estar preparados para ofrecer servicios determinados al usuario, con el fin de que éste obtenga lo que vino a buscar cuando visitó el Sitio Web. Por lo anterior, cada uno de los elementos que sean integrados dentro de la TFG: José María Suárez Peret Página 57 de 99 interfaz debe estar pensado para causar un efecto sobre el usuario y deben ser utilizados con un propósito. En este sentido, es importante considerar que Jakob Nielsen4 i. Dejar claro el propósito del sitio: se refiere a que el sitio debe explicar a quién pertenece y qué permite hacer a quienes lo visitan; se entiende que debe hacerlo de manera simple y rápida. Por ejemplo, ayuda en este sentido el cumplimiento de las normas referidas a uso de URLs y logotipos oficiales. , uno de los autores más citados en cuanto a la usabilidad de los Sitios Web, destaca que los elementos más importantes de la portada de todo Sitio Web se pueden resumir en estos cuatro postulados generales: ii. Ayudar a los usuarios a encontrar lo que necesitan: implica que debe contar con un sistema de navegación visible y completo, pero que además deberá estar complementado por algún sistema de búsqueda que sea efectivo para acceder al contenido al que no se logra acceder o que no se encuentra a simple vista. iii. Demostrar el contenido del sitio: significa que el contenido se debe mostrar de manera clara, con títulos comprensibles por parte del usuario y con enlaces hacia las secciones más usadas que estén disponibles donde el usuario los busque. Ayudará en este sentido tener un seguimiento de las visitas para comprender qué es lo más visto y lo más buscado del Sitio Web. iv. Usar diseño visual para mejorar y no para definir la interacción del Sitio Web: se refiere a que los elementos gráficos del Sitio Web deben estar preparados para ayudar en los objetivos del sitio y no sólo como adornos utilizados para rellenar espacio. Aunque se trata de uno de los temas más debatibles, su alcance no es el de restringir el uso de imágenes y elementos gráficos, sino a que su uso sea adecuado para la experiencia de uso que se desea ofrecer. 4 Web de Jakob Nielsen: http://www.nngroup.com/people/jakob-nielsen/ TFG: José María Suárez Peret Página 64 de 99 de páginas web. Es un estándar que sirve de referencia para la elaboración de páginas web en sus diferentes versiones, define una estructura básica y un código (denominado código HTML) para la definición de contenido de una página web, como texto, imágenes, etc. Es un estándar a cargo de la W3C, organización dedicada a la estandarización de casi todas las tecnologías ligadas a la web, sobre todo en lo referente a su escritura e interpretación. Es el lenguaje de programación con el que se definen las páginas web. • Javascript: a veces abreviado como JS, es un lenguaje de programación ligero e interpretado, orientado a objetos, más conocido como el lenguaje de script para páginas web, pero también usado en muchos entornos sin navegador. El JavaScript tiene como estándar el ECMAScript. A partir de 2012, todos los navegadores modernos soportan completamente ECMAScript 5.1. Los navegadores más antiguos soportan por lo menos ECMAScript 3. A día de hoy, una sexta revisión del estándar está en proceso. 9.2. Funcionamiento de la aplicación En esta sección se describen las funciones principales del sistema implementado, de tal forma que se pueda concebir una idea general de cómo funciona dicho sistema. En el apartado de “anexos”, se incluye una sección donde se describe de forma más específica el funcionamiento de la aplicación. 9.2.1. Sistema de control de encuestas Los usuarios registrados pueden controlar que profesores que han sido valorados en sus asignaturas mediante la interfaz de control de encuestas. Para ello, deben marcar o desmarcar al profesor evaluado en la asignatura correspondiente. TFG: José María Suárez Peret Página 65 de 99 Imagen 13 – Interfaz de control de encuestas. Usuarios registrados. Además, los usuarios pueden visualizar o imprimir los listados de profesores evaluados y no evaluados mediante la interfaz de impresión de listados. Para imprimir un listado, deben indicar cuantos sobres con cuestionarios tienen los profesores que han sido evaluados o no evaluados, en las asignaturas correspondientes, e indicar cuales desean imprimir. TFG: José María Suárez Peret Página 66 de 99 Imagen 14 – Interfaz de impresión de listados. Usuarios registrados. 9.2.2. Sistema de gestión de encuestas El administrador del sistema dispone de dos tipos de consultas para controlar y gestionar los datos. 9.2.2.1. Consulta personal En este tipo de consulta el administrador puede especificar los datos de un profesor determinado para conocer en que asignaturas sus alumnos le han valorado y en cuales todavía no. Para ello se utiliza la interfaz de la consulta personal. TFG: José María Suárez Peret Página 67 de 99 Imagen 15 – Interfaz de la consulta personal. Administrador. 9.2.2.2. Consulta general En este tipo de consulta el administrador puede consultar los datos de manera general por curso académico y semestre o simular la entrada de un encuestador. Para ello se utiliza la interfaz de la consulta general. Los datos que puede consultar son los siguientes: • Información de todos los profesores agrupados por centro. • Información de todos los profesores agrupados por titulación. • Información de todos los profesores y las asignaturas agrupados por centro. • Información de todos los profesores y las asignaturas agrupados por titulación. • Listado de todos los profesores no evaluados en ningún grupo. TFG: José María Suárez Peret Página 68 de 99 • Listado de todos los profesores y asignaturas no evaluados en ningún grupo. • Listado de todos los profesores evaluados en algún grupo. • Listado de todos los profesores y asignaturas evaluados en algún grupo. • Simular la entrada de un encuestador. Imagen 16 – Interfaz de la consulta general. Administrador. 10. PRUEBAS 10.1. Primera prueba - Boceto básico inicial Durante el segundo semestre del curso académico 2012/2013, se pone en marcha un pequeño boceto de la idea inicial que el Gabinete de Evaluación Institucional tenía sobre la aplicación web que necesitaba. TFG: José María Suárez Peret Página 69 de 99 Para ello, se les dio de alta a algunos encuestadores de algunas titulaciones y se les dio permiso de acceso a los Vicedecanos o Subdirectores de calidad de los centros correspondientes para que probaran el boceto inicial de la aplicación web. Con esto se intentaba comprobar un funcionamiento básico de la aplicación y como se integraría en la web de la ULPGC. En el boceto inicial solo estaba implementada una funcionalidad básica para los usuarios registrados, es decir, responsables de calidad y encuestadores que solo podían indicar si un profesor estaba evaluado, o no, en alguna de sus asignaturas e imprimir algún listado muy básico. Además, la aplicación estaba programada para que fuera compatible con los principales navegadores web y no estaba implementado ningún sistema de administración de la propia aplicación. Los centros participantes fueron los siguientes: • Facultad de Economía, Empresa y Turismo. • Escuela de Ingeniería Informática. • Facultad de Geografía e Historia. La batería de pruebas que los usuarios registrados podían realizar eran las siguientes: • Acceder a la aplicación por MiULPGC. • Visualizar los listados de una o varias titulaciones. • Marcar o desmarcar a un profesor en una asignatura como evaluado o no evaluado. • Imprimir un listado muy básico de los profesores evaluados o no evaluados. La distribución de los roles de usuarios registrados, por centro, fue la siguiente: Rol Centros Responsable de calidad 3 Encuestador 6 Tabla 3 – Relación rol usuarios-centros. Primera prueba. TFG: José María Suárez Peret Página 70 de 99 Hay que destacar que, para facilitar a los usuarios de prueba la notificación de todos los errores y posibles mejoras detectadas, se habilitó un correo electrónico de reporte de incidencias. De esta primera prueba inicial se obtuvieron los siguientes resultados: • La aplicación se integró perfectamente en la web de la ULPGC, aunque hubo algunos errores de asignación de titulaciones a usuarios registrados. Básicamente el problema se debía a que el control de acceso por MiULPGC y la base de datos no se realizaba correctamente al no estar dado de alta el usuario correctamente. • La velocidad de respuesta se tendría que mejorar simplificando las consultas a la base de datos eliminando las titulaciones en las que no se debía realizar el proceso de encuestación por ser estas titulaciones en extinción. • Desde el Gabinete de Evaluación Institucional, se vio la necesidad de mejorar diversos aspectos de la aplicación así como desarrollar un apartado de administración de los datos recabados. Las mejoras están especificadas en el apartado 7.5 de este documento y básicamente eran las siguientes: o Mostrar el curso académico que se está valorando. o Permitir incluir observaciones en los listados impresos. o Permitir paginación en la pantalla de listados. o Desarrollar un sistema que permita al administrador gestionar las encuestas marcadas por los usuarios registrados. o Permitir que el administrador pueda simular la entrada de un encuestador. 10.2. Segunda prueba – Sistema definitivo Durante el primer semestre del curso académico 2013/2014, se pone en marcha el sistema con la implementación de las mejoras y corrección de los errores detectados en la prueba del boceto inicial. Para ello, se da de alta en el sistema a todos los Vicedecanos o Subdirectores de calidad de todos los centros (22) que imparten docencia en la ULPGC. Además, se TFG: José María Suárez Peret Página 71 de 99 les permite el acceso a todos los encuestadores que los centros han seleccionado para realizar el proceso de encuestación. Por otro lado, se ha implementado el sistema de administración de la aplicación y es el propio administrador el que realizó las pruebas sobre este mismo sistema. La batería de pruebas que los usuarios registrados podían realizar eran las siguientes: Rol responsable de calidad y encuestador • Acceder a la aplicación por MiULPGC. • Visualizar los listados de una o varias titulaciones. • Marcar o desmarcar a un profesor en una asignatura y en al menos un grupo como evaluado o no evaluado. • Imprimir un listado de los profesores evaluados o no evaluados e indicar cuantos sobres de cuestionarios cumplimentados por los alumnos tiene el profesor indicado. • Utilizar el sistema de paginación de los listados a imprimir. Rol administrador • Acceder a la aplicación por MiULPGC. • Visualizar los datos de un profesor determinado (Consulta personal) • Visualizar los datos por curso académico y semestre respecto a (Consulta general): o Información de los profesores agrupados por centro. o Información de los profesores agrupados por titulación. o Información de los profesores y las asignaturas agrupados por centro. o Información de los profesores y las asignaturas agrupados por titulación. o Listado de profesores no evaluados en ningún grupo. o Listado de profesores y asignaturas no evaluados en ningún grupo. o Listado de profesores evaluados en algún grupo. o Listado de profesores y asignaturas evaluados en algún grupo. TFG: José María Suárez Peret Página 72 de 99 • Simular la entrada de un encuestador. La distribución de los roles de usuarios registrados, por centro, fue la siguiente: Rol Centros Responsable de calidad 22 Encuestador 15 Administrador 22 Tabla 4 – Relación rol usuarios-centros. Segunda prueba. Al igual que se hizo en la primera prueba, para facilitar a los usuarios registrados la notificación de todos los errores y posibles mejoras detectadas, se habilitó un correo electrónico de reporte de incidencias. En esta segunda prueba se obtuvieron los siguientes resultados: • La aplicación se integró perfectamente en la web de la ULPGC, controlando perfectamente el acceso de los usuarios. • La velocidad de respuesta se mejoró al simplificar las consultas a la base de datos eliminando las titulaciones en extinción. • La aplicación del administrador mostró correctamente todos los datos de las encuestas marcadas por los usuarios registrados. • Los usuarios de la aplicación mostraron su satisfacción por las mejoras introducidas respecto al boceto básico inicial. 10.3. Sistema en explotación Una vez finalizadas todas las pruebas, durante el segundo semestre del curso académico 2013/2014, el sistema se pone en explotación con las correcciones y mejoras realizadas respecto a la segunda prueba realizada durante el primer semestre del curso académico indicado anteriormente. TFG: José María Suárez Peret Página 73 de 99 El Gabinete de Evaluación Institucional, quedó satisfecho con el sistema implementado aunque se proponen diversas mejoras la cuales se pueden leer en el apartado decimo primero de este documento “trabajo futuro”. 11. CONCLUSIONES Y TRABAJO FUTURO 11.1. Conclusiones El proceso de encuestación que se realiza en la ULPGC, para valorar la calidad docente, es muy complejo y presenta muchas dificultades para que pueda llevarse a cabo a todo el profesorado en todas sus asignaturas. Hay que tener en cuenta que la valoración se realiza por profesor en todas las asignaturas que imparte y en todos los grupos de alumnos diferentes que puedan existir en cada una de esas asignaturas. Por lo tanto, las complicaciones se deben básicamente a que el proceso se realiza en horas lectivas, a que no siempre se localiza al profesor o al grupo de alumnos, a la propia diversidad estructural de los centros y a los pocos recursos de personas disponibles para poder realizar todo el proceso de encuestación. En este sentido, según la instrucción procedimental definida por el Gabinete de Evaluación Institucional, es el propio centro el que debe proporcionar a los encuestadores y no siempre es posible contar con el número de personas suficientes para garantizar que el proceso se realice correctamente. Dentro de esta complejidad, el Gabinete de Evaluación Institucional decidió elaborar una aplicación web para que los responsables del proceso de encuestación (Vicedecanos/Subdirectores de calidad), y los propios encuestadores, pudieran llevar un control sobre los profesores que han sido valorados por sus alumnos y sobre los que no han sido valorados. De esta forma, se puede centrar el objetivo en valorar a aquellos profesores que no tienen ninguna valoración realizada por sus estudiantes y garantizar de alguna manera que todos los profesores de la ULPGC disponen al menos de una valoración de sus alumnos. Esto es así porque solamente los profesores que tengan al menos una de sus asignaturas con valoración de sus estudiantes podrán optar a los grados de excelencia del Programa DOCENTIA-ULPGC, lo cual viene recogido en el Manual de Procedimiento que se ha aprobado el 16 de junio de 2014 en Consejo de Gobierno de la ULPGC. Por este motivo, se necesita un sistema que asegure, de alguna manera, que todos los profesores tengan al menos una de sus asignaturas con valoración docente de sus estudiantes. TFG: José María Suárez Peret Página 80 de 99 Una vez seleccionado el título en el que se quiere ver el listado, el Vicedecano/Subdirector de calidad o el encuestador podrá marcar si el profesor ha sido evaluado por sus alumnos, en la asignatura correspondiente, seleccionando la opción “Evaluado”. En el caso de que el profesor no haya sido evaluado por sus alumnos, en la asignatura correspondiente, se seleccionará la opción “NP/Inc”. Visualmente, los profesores evaluados aparecerán en color azul y los profesores no evaluados en color rojo. Los profesores pendientes de evaluar aparecerán en color gris. Imagen 20 – Listado profesor/asignatura a evaluar del título seleccionado. TFG: José María Suárez Peret Página 81 de 99 13.1.3. Imprimir listados profesor/asignatura evaluados o no evaluados Para poder imprimir los listados de los profesores evaluados y no evaluados, en sus asignaturas correspondientes, que han sido seleccionados por los Vicedecanos/Subdirectores de calidad o encuestadores en la opción del punto 13.1.2, primero hay que seleccionar el título sobre el que se quiere imprimir los listados. Para ello hay que ir a la opción “Mostrar Listados”. Imagen 21 – Pantalla de acceso a los listados por centro y título. Una vez seleccionada la opción “Mostrar Listados”, aparece una pantalla donde se debe seleccionar el listado que queremos imprimir, esto es, profesor/asignatura evaluados o profesor/asignatura no evaluados. TFG: José María Suárez Peret Página 82 de 99 Imagen 22 – Pantalla para seleccionar el listado que se quiere imprimir. Una vez seleccionado el listado que se quiere imprimir, aparecerá una pantalla donde el Vicedecano/Subdirector de calidad o encuestador debe indicar que profesores/asignaturas quiere imprimir y cuantos sobres con cuestionarios cumplimentados tiene un profesor/asignatura. Esto es así porque un profesor en una asignatura tendrá un sobre con cuestionarios cumplimentados por cada grupo de alumnos que tenga la asignatura correspondiente. Es decir, si un profesor imparte una asignatura donde hay dos grupos de alumnos diferentes, entonces cada grupo de alumnos evaluará al profesor en esa asignatura por lo que existirán dos sobres con cuestionarios cumplimentados cada uno correspondiente al grupo de alumnos que ha realizado la evaluación. Una vez cumplimentados todos los datos que se desean imprimir, hay que seleccionar la opción “Preparado para Imprimir las Filas marcadas”. TFG: José María Suárez Peret Página 83 de 99 Imagen 23 – Pantalla para seleccionar los profesores/asignaturas a imprimir. Una vez indicados todos los datos que se desean imprimir, aparecerá una pantalla donde se puede indicar alguna observación adicional y un botón para imprimir los datos que se habían cumplimentado anteriormente (Imprimir). Al realizar estos pasos, se imprimirá el listado. TFG: José María Suárez Peret Página 84 de 99 Imagen 24 – Pantalla para imprimir el listado. TFG: José María Suárez Peret Página 85 de 99 13.2. Anexo B: Guía de utilización de la aplicación para el administrador 13.2.1. Acceso a la aplicación El acceso a la aplicación para el administrador se realiza desde una url que está en posesión del Gabinete de Evaluación Institucional y cuyo acceso está restringido por MiULPGC. Imagen 25 – Web de la ULPGC. Acceso a la aplicación del administrador. 13.2.2. Consulta personal Para acceder a la Consulta Personal, hay que seleccionar la opción que tiene ese mismo nombre. Al hacerlo, aparecerá una pantalla donde se podrá indicar el curso académico donde se quiere consultar los datos y el dni del profesor que se quiere consultar. También se puede seleccionar al profesor mediante una lista desplegable. TFG: José María Suárez Peret Página 86 de 99 Imagen 26 – Pantalla Consulta Personal. Una vez seleccionado el profesor que se quiere consultar, aparecerán por centro y titulación sus asignaturas del curso académico seleccionado y se podrá visualizar cuales han sido evaluadas (color azul), cuáles no (color rojo) y cuáles están pendientes de evaluar (color gris). Asimismo, se muestra el nombre del Vicedecano/Subdirector de calidad responsable del proceso de evaluación porque es una información muy importante para el Gabinete de Evaluación Institucional. TFG: José María Suárez Peret Página 87 de 99 Imagen 27 – Pantalla donde se muestran los datos del profesor consultado. 13.2.3. Consulta general Para acceder a la Consulta General, hay que seleccionar la opción que tiene ese mismo nombre. Al hacerlo, aparecerá una pantalla donde se podrá indicar el curso académico donde se quiere consultar los datos, el semestre y una serie de opciones de búsqueda de datos que se verán en los siguientes apartados de este documento. TFG: José María Suárez Peret Página 88 de 99 Imagen 28 – Pantalla Consulta General. 13.2.3.1. Información de los profesores desglosada por centro Si seleccionamos está opción en la búsqueda de datos, nos aparecerá un listado por centro donde se indica el número de profesores que imparten clase en el centro y respecto a este número, los profesores que se han evaluado y los que no. Leyendas de la pantalla: • N.Prof: Indica el número de profesores que imparten clase en el centro. • PE Algo: Indica el número de profesores que han sido evaluados en el menos una asignatura. • PNE Nada: Indica el número de profesores que no han sido evaluados en ninguna asignatura. TFG: José María Suárez Peret Página 89 de 99 Imagen 29 – Pantalla de información de los profesores por centro. 13.2.3.2. Información de los profesores desglosada por titulación Si seleccionamos está opción en la búsqueda de datos, nos aparecerá un listado por titulación donde se indica el número de profesores que imparten clase en cada titulación y respecto a este número, los profesores que se han evaluado y los que no. Leyendas de la pantalla: • N.Prof.: Indica el número de profesores que imparten clase en la titulación. • PE Algo: Indica el número de profesores que han sido evaluados en el menos una asignatura. • PNE Nada: Indica el número de profesores que no han sido evaluados en ninguna asignatura. TFG: José María Suárez Peret Página 96 de 99 Imagen 36 – Listado profesores/asignaturas evaluados. 13.2.3.9. Simulación del acceso de un Vicedecano/Subdirector de calidad o encuestador Si seleccionamos está opción en la búsqueda de datos, nos aparecerá una opción para simular la entrada de un Vicedecano/Subdirector de calidad o encuestador. Para ello, tendremos que seleccionar del desplegable que nos aparece, el centro en el que queremos simular la entrada. TFG: José María Suárez Peret Página 97 de 99 Imagen 37 – Simulación entrada Vicedecano/Subdirector de calidad o encuestador. Una vez seleccionado el centro, nos aparecerá por cada una de las titulaciones de ese centro, la visualización de lo que un Vicedecano/Subdirector de calidad o encuestador ha realizado hasta el momento, es decir, los profesores y asignaturas que ha señalado como evaluado o no evaluado. Imagen 38 –Simulación entrada Vicedecano/Subdirector de calidad o encuestador. Selección de un centro. TFG: José María Suárez Peret Página 98 de 99 13.3. Anexo C: Script SQL de creación de la Base de Datos En este anexo se indican los script SQL para la creación de las tablas de la Base de Datos. Se podrán visualizar los detalles de cada una de las tablas, sus campos, relaciones y tipos. • Estructura de tabla para la tabla `Permisos_Prof_Eva_Enc_XXYY` CREATE TABLE`bd_evaluacion`.`Permisos_Prof_Eva_Enc_XXYY` ( `id` BIGINT( 20)NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST, `Cod_Centro` text NOT NULL , `Centro` longtext NOT NULL , `Cod_Titu` text NOT NULL , `Titu` longtext NOT NULL , `DNI_Resp` text NOT NULL , `Responsable` longtext NOT NULL , `Perfil_Resp` text NOT NULL , `Telf` text NOT NULL , `Email` text NOT NULL , `Tipo` int( 1)NOT NULL )ENGINE =MYISAM DEFAULT CHARSET= latin1 COMMENT='Permisos acceso 2013/2014'; • Estructura de tabla para la tabla `Prof_Eva_Enc_XXYY` CREATE TABLE`bd_evaluacion`.`Prof_Eva_Enc_XXYY` ( `id` BIGINT( 20)NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST, `Cod_Centro` text NOT NULL , `Centro` longtext NOT NULL , `Cod_Titu` text NOT NULL , `Titu` longtext NOT NULL , `DNI_Prof` text NOT NULL , `Profesor` longtext NOT NULL , TFG: José María Suárez Peret Página 99 de 99 `Cod_Asigna` text NOT NULL , `Asigna` longtext, `Semestre` int( 1)NOT NULL , `Activada` int( 1)NOT NULL , `Evaluado` int( 1)NOT NULL default'0', `Check_Eva` int( 1)NOT NULL default'0', `DNI_Resp` text NOT NULL , `Responsable` longtext, `Perfil_Resp` text NOT NULL , `Fecha` text, `Hora` text NOT NULL )ENGINE =MYISAM DEFAULT CHARSET= latin1 COMMENT='Curso 2013/2014. Profesores Evaluados con Encuestas Estudiantes';