Extendiendo ABP con feedback ágil en la enseñanza de Ingeniería del Software

Extendiendo ABP con feedback ágil en la enseñanza de Ingeniería del Software Pablo Fernandez, José María García, José A. Parejo y Antonio Ruíz-Cortés. Departamento de Lenguajes y Sistemas Informáticos Universidad de Sevilla [email protected] Resumen El Aprendizaje Basado en Proyectos (ABP) ha sido aplicado con éxito en diversas áreas de la docencia de la informática en el ámbito universitario. A su vez, a nivel industrial en el contexto de la ingeniería del software, las metodologías ágiles se han instaurado como la opción más utilizada para el desarrollo de proyectos gracias en parte a su promoción de un feedback temprano y continuo que ayuda a enfocar y adaptar el desarrollo a las necesidades del cliente. Este artículo presenta una experiencia piloto que aúna ambos conceptos, extendiendo el enfoque ABP para incorporar el ciclo de feedback rápido y continuo de las metodologías ágiles en la docencia de ingeniería del software. Dicho ciclo se incorpora mediante la aplicación de una evaluación continua de las tareas realizadas por el alumno, en base a un backlog de tareas semanales y a listas de verificación que permiten evaluar el trabajo realizado de manera objetiva. Los resultados obtenidos son prometedores, tanto en términos de la distribución de notas de los alumnos como en cuanto a la motivación de los alumnos con asignatura. Finalmente, se ha realizado un análisis pormenorizado de las numerosas métricas recolectadas de las distintas plataformas utilizadas que ha permitido un estudio de las tipologías de alumnos y la obtención de un conjunto de lecciones aprendidas que pueden ser aplicadas en el diseño de experiencias docentes similares. Abstract Project Based Learning (PBL) has been successfully applied in a number of scenarios as part of the Computer Science teaching. Alternatively, from the software industry point of view, agile methodologies represent a first class citizen being the most suitable choice in several cases as they boost an early customer feedback so it can be adapted to its needs. This paper presents a first experience combining PBL and Agile methodologies in Software Engineering course. Specifically, our approach combines the usage of a weekly backlog with a peer-reviewing process based on checklists that allow an accurate continuous evaluation of students performance. The results analysis of our experience shows an appropriate distribution of scores and a significant improvement in the student motivation. Additionally, we detail the analysis of a number of metrics in order to characterize some students patterns that support a list of lessons learned to potentially improve the teaching in similar courses. Palabras clave Aprendizaje basado en proyectos, feedback, metodologías ágiles. 1. Introducción La aparición de nuevas herramientas pedagógicas en la educación de la informática ha sido muy fructífera en los últimos años y se pueden encontrar experiencias docentes con resultados prometedores en distintos ámbitos de actuación [7, 10, 11]. Entre estas herramientas destacan la aplicación del aprendizaje basado en proyectos (ABP) [3] como eje vertebrador de la adquisición de conocimiento y los cambios en el modelo de interacción profesor-alumnos aplicando técnicas como la enseñanza inversa (flipped classroom) [9] o la revisión por pares (peer instruction) [2]. Por otro lado, en el contexto de la Ingeniería del software, las metodologías ágiles se ha consolidado como uno de los modelos mas utilizados debido a su flexibilidad a la hora de acometer el desarrollo software. Este dinamismo es especialmente interesante en la industria debido a que permite maximizar la satisfacción del cliente con una secuenciación de las funcionalidades del producto final en base a un feedback continuo con el cliente y promover la transferencia de conocimiento del equipo de desarrollo con el análisis en retrospectiva del trabajo realizado. 1 En este artículo se presenta la experiencia docente en una asignatura de ingeniería del software donde se ha planteado un cambio diametral para pasar de un modelo clásico a un nuevo modelo que permita incorporar de manera personalizada las distintas herramientas de aprendizaje de forma adaptada aplicando un modelo ABP en el que se integran los principios del desarrollo ágil. De manera concreta, se ha realizado una transformación de las sesiones clásicas Teoría / Práctica a un modelo en el que se plantean, por un lado, sesiones de feedback continuas para evaluar de forma objetiva los conocimientos adquiridos y, por otro lado, clases integrales desarrollando conceptos teóricoprácticos de manera combinada. Este cambio de modelo se ha apoyado en un uso intensivo de herramientas TIC para descargar la carga de gestión por parte de los profesores y sistematizar el mecanismo de interacción entre profesor-alumno similar al de la relación clientedesarrollador en las metodologías ágiles. Los resultados de esta experiencia han sido muy satisfactorios a distintos niveles: por un lado se ha reducido el nivel de abandono y aumentado la tasa de participación activa; se ha desarrollado un mecanismo de evaluación que consigue una distribución de notas que refleja con precisión de manera cuantitativa las diferencias en el conocimiento de los estudiantes; por último, se han obtenido un conjunto de indicadores para desarrollar un plan de mejora continua en futuros cursos. El presente articulo está dividido en cuatros secciones: En la siguiente sección 2 se realiza un análisis de la literatura presentando el trabajo relacionado para enmarcar la presente experiencia docente; a continuación en la sección 3 , se detalla la propuesta metodológica desarrollada en la asignatura; en la sección 4 se presenta los resultados principales del análisis cuantitativo sobre las métricas recopiladas en la asignatura para identificar las lecciones aprendidas y posibles actuaciones de mejoras en futuros cursos; por último, en la sección 5 se desarrollan las conclusiones y trabajos futuros que se desprenden de este artículo. 2. Trabajo relacionado Las bases de la metodología docente que presentamos en este artículos son por un lado, las teorías de aprendizaje constructivistas o más concretamente el modelo de alineamiento constructivista de Biggs [4], el cual esencialmente considera que "lo que el estudiante hace es lo que cuenta". Por otro lado, las aproximaciones ágiles a la ingeniería del software han servido también como inspiración para el diseño de las actividades formativas y de evaluación. Tal y como enuncia el primer principio del manifiesto ágil [6], "nuestra mayor prioridad está en satisfacer al cliente a través de entregas tempranas y continuas de valor", donde para nosotros los clientes se corresponden con nuestros alumnos y consideramos el conocimiento como el principal valor generado. Asimismo, las metodologías ágiles de desarrollo de software, como Scrum, resultan de aplicación para la docencia en ingeniería del software [8], estando en nuestro caso detrás de la elección de ciclos de trabajo cortos para obtener feedback temprano, además de en la acumulación continua de puntos mediante evaluaciones por pares usando listas de control [2]. Este acercamiento permite un control empírico del proceso de aprendizaje, promoviendo la transparencia, inspección y adaptación [5]. La integración de técnicas como la enseñanza inversa o flipped classroom dentro de la metodología docente reporta también beneficios en el proceso de aprendizaje de los alumnos [10], proporcionando por ejemplo los vídeos de las sesiones de clase integral para que los alumnos puedan adquirir los conocimientos necesarios fuera de la clase y los apliquen en los ejercicios y proyectos programados para realizar y evaluar en el aula [1]. Finalmente, la aplicación de ABP en la docencia de la informática resulta en un aprendizaje más profundo de las competencias transversales y específicas de las asignaturas, además de servir como elemento motivador para el alumno [7]. 3. Propuesta metodológica Basándonos en el enfoque de Aprendizaje Basado en Proyectos (ABP), hemos desarrollado una propuesta metodológica de docencia en Ingeniería del Software que incorpora conceptos y prácticas de las metodologías de desarrollo ágiles. En concreto, la metodología docente que presentamos a continuación la hemos aplicado a una asignatura de tercer curso de grado orientada a desarrollar las competencias adecuadas que permitan el diseño y construcción de aplicaciones con enfoque orientado a servicios. Dadas las características de la asignatura, se abordó la docencia usando ABP por equipos formados por dos o tres personas, donde cada equipo debe desarrollar un proyecto diferente que ponga en práctica todos los conocimientos adquiridos en la asignatura aplicándolos de manera específica a su casuística. Siguiendo el paradigma de construcción de la programación ágil, el proyecto que se realiza corresponde con una aplicación que debe satisfacer un conjunto de requisitos funcionales y no funcionales que pueden abordarse en varios entregables y que se construyen siguiendo un desarrollo evolutivo. De esta forma, cada entrega siempre resulta en un software operativo que en los primeros entregables posee una funcionalidad escasa y a la que se van añadiendo componentes o funcionalidades en cada entregable posterior. Este enfoque constructivista permite al estudiante visualizar lo antes posible el resultado práctico de la aplicación de sus conocimientos y cómo se encadenan y vertebran los nuevos conceptos sobre conocimiento asentado; estos dos aspectos persiguen potenciar la motivación del alumno y premiar el trabajo continuo para desincentivar el abandono de la asignatura. Bajo este enfoque, la clásica distinción entre clases de teoría y clases de prácticas o laboratorio no es directamente aplicable, considerándose las distintas sesiones o actividades formativas como una mezcla entre aspectos teóricos y prácticos orientados a que los alumnos adquieran las competencias necesarias para llevar a cabo el proyecto. Todas los elementos empleados en la metodología docente (sesiones, actividades y entregables) están identificados de manera unívoca con un patrón definido por un prefijo y dos dígitos. En concreto, los tipos de elementos que se desarrollan en la asignatura son: Cxx (Clase Integral): Sesiones donde se presentan conocimientos y se hacen ejercicios sintéticos de baja complejidad. Fxx (Sesión de Feedback): Sesiones donde se realizan Micro-Tests y se verifica que se han realizado el trabajo y entregables planificados. MTx (Micro-test): Tests con un conjunto reducido de preguntas (normalmente 5 preguntas). Dxx (Entregable): Artefacto(s) que se debe presentar en una fecha específica (normalmente una aplicación operativa acompañada de documentación). RTx (Mesa redonda): Mesas redondas donde se realiza una reflexión y análisis conjunto sobre alguna temática. 3.1. Planificación de la docencia Las asignatura se ha desarrollado en un conjunto de 15 semanas, en cada una de las cuales existen 2 sesiones que, de manera general, corresponden con una sesión de Clase Integral (CXX) y una sesión de Feedback (FXX). Sin embargo, la planificación se realizó considerando que las dos primeras semanas de la asignatura son únicamente de clases integrales y las dos últimas son de feedback, ya que por un lado se necesita proporcionar un contexto completo al principio del curso, y por otro lado el final del curso se dedica a la evaluación detallada de los entregables finales. Es recomendable que la secuenciación habitual se estructure de forma que el tiempo entre la finalización de la clase integral y el comienzo de la sesión de feedback sea mayor que el que transcurre entre el fin del feedback y el comienzo de la clase integral. (Por ejemplo si las sesiones deben ser martes y miércoles, es recomendable que el martes se dedique a feedback y el miércoles a clase integral). Al final de cada semana, el material que se entrega a los alumnos es el siguiente: • Video de la sesión de clase integral (excluyendo las partes donde se comentan las soluciones a los micro-tests). • Presentación teórica utilizada durante las clases. • Nueva sección de backlog donde se abordan los aspectos que se van a requerir en la siguiente sesión de feedback. Inspirándonos en las metodologías ágiles como Scrum, el backlog consiste en un documento online en constante evolución durante el curso, en el que se van añadiendo todas las tareas que los alumnos deben ir realizando, incluyendo tareas opcionales que permitan obtener una puntuación extra para la evaluación final. 3.2. Actividades formativas Tal como enumeramos anteriormente, dentro de los elementos que empleamos en nuestra metodología, las actividades formativas que se proponen son: clases integrales, sesiones de feedback y mesas redondas. A continuación se indican las horas presenciales y no presenciales, junto con la metodología de enseñanza y aprendizaje para cada una de ellas. Clase integral Estas sesiones (CXX) requieren de 30 horas presenciales y 30 horas no presenciales de trabajo del alumno. Las clases integrales están orientadas a presentar el contenido teórico de manera interactiva mediante pequeños ejercicios que se intercalan durante la sesión. La proporción de tiempo dedicado a la presentación magistral y del tiempo dedicado a proponer y resolver los ejercicios es variable pudiendo existir, en un extremo, clases integrales equiparables a clases magistrales clásicas y clases eminentemente prácticas con una carga de contenidos muy reducida. Esta distribución variable responde a la premisa de que existen conceptos que son altamente complejos y deben ser interiorizados y afianzados de manera inmediata mediante un conjunto de ejercicios prácticos que aumenten su complejidad de manera gradual (por ejemplo: diferencias entre la programación síncrona y asíncrona). Por otro lado, existen bloques temáticos que exigen una presentación magistral clásica debido a que no comportan una complejidad elevada como los casos donde se presenta un panorama general de un determinado aspecto (por ejemplo: modelos de widgets de visualización de datos) donde se busca promover un análisis amplio de alternativas a modo de catálogo de referencias que permita dotar al alumno de las herramientas para realizar una búsqueda, análisis y selección de la mejor opción en el contexto concreto de su proyecto. Sesiones de feedback Estas sesiones (FXX), para las que se requieren 24 horas presenciales y 62 horas no presenciales, están orientadas a evaluar el conocimiento adquirido durante la última semana por parte del alumno a partir del trabajo realizado en casa y en la última sesión de clase integral. Además, cuando coinciden con la fecha de un entregable, sirven como una evaluación preliminar del mismo. De manera general las sesiones de feedback se dividen en distintos bloques que incluyen, en la mayoría de las ocasiones, un micro-test y una revisión por pares. Según esta estructura, la evaluación de los conocimientos adquiridos se plantea en dos ámbitos: • Conocimiento teórico (individual). Mediante un Micro-Test (MTX) compuesto por una distribución de 4 o 5 preguntas en las que la mayoría corresponden a conceptos desarrollados en la última sesión de clase integral, aunque se incluyen también algunas preguntas de clases anteriores. Los tests se generan de manera automatizada a partir de una base de datos de preguntas dividida por cada bloque temático correspondiente a una sesión de clase integral; el número de preguntas disponibles por bloque oscila entre 8 y 10 preguntas. • Conocimiento práctico / know-how (individual y grupo). Los aspectos que se revisan en este ámbi- to deben estar definidos detalladamente para que puedan ser revisados mediante una lista de verificación (explicitada con suficiente antelación en el backlog) que incluye un conjunto de controles cuyo cumplimiento se puede identificar de manera objetiva; este aspecto es clave para un desarrollo fluido de las sesiones de revisión por pares. La actividad que ocupa el mayor tiempo dentro de las sesiones de feedback es el bloque de revisión por pares. Este mecanismo permite a los estudiantes revisar a (y ser revisados por) compañeros de forma que obtienen un feedback inmediato sobre cada uno de los elementos de la lista de verificación definidos. Este bloque se estructura en dos partes de manera que en la primera parte la mitad de los estudiantes desarrollan el rol de “revisor” sobre el trabajo realizado por la otra mitad de los estudiantes (que adquieren el rol de “revisados”); de manera análoga en la segunda parte se invierten los roles en las dos mitades. Este formato de revisión garantiza que todos los estudiantes adquieren ambos roles en cada sesión de feedback. La revisión siempre se realiza por pares de forma que un estudiante revisa a otro estudiante. Cuando hay elementos que se desarrollan en grupo se deja libertad para que se haga una autodistribución de la revisión de controles de grupo. Mientras los alumnos están realizando la revisión por pares, el profesor realiza una verificación aleatoria de algunos puntos de la lista de verificación en los ordenadores de los revisores que están desocupados porque se han desplazado al ordenador del estudiante revisado. Esta tarea establece un mecanismo de revisión cruzada que permite detectar posibles fallos en las revisiones de los estudiantes durante el bloque de revisión por pares. Al final de la sesión, se realiza un feedback individualizado especialmente indicado a los alumnos que no han tenido un feedback positivo en su hoja de revisión, a fin de detectar las causas y posibles problemas o falta de conocimiento; esto permite dar unas directrices personalizadas a cada alumno que les permita solventar estas carencias y conseguir un próximo feedback positivo. Mesas redondas Estas sesiones (RTX), con un esfuerzo de 2 horas presenciales y 2 horas no presenciales, están orientadas a discutir de manera conjunta por parte de todo el grupo un aspecto transversal. El uso de este tipo de sesiones se ha empleado para realizar un análisis de aspectos complejos y se pueda desarrollar la capacidad de realizar una crítica comparativa sobre distintos casos reales. Con este fin, a modo de preparación los estudiantes deben hacer una búsqueda de campo previa a la sesión donde se localicen casos reales para ser analizados a posteriori. 3.3. Mecanismo de evaluación El modelo de evaluación de la asignatura se muestra en el Cuadro 1. En primer lugar, se puede ver que el número (N) de actividades evaluadas es bastante alto, resultando en un total de 23 puntuaciones distintas que los alumnos van acumulando continuamente durante el desarrollo de la asignatura. Así, tanto los microtests (MTX) como las evaluaciones de feedback (FXX) son notas que se obtienen semanalmente en las sesiones de feedback, mientras que los entregables (DXX) son notas que se obtienen puntualmente, coincidiendo con ciertos hitos de la asignatura. Salvo el entregable D04, todas estas evaluaciones se realizan por pares tal y como describimos anteriormente. Adicionalmente, se evalúa un trabajo de investigación y análisis individual que se debate posteriormente en una sesión de mesa redonda (MTX). Respecto a los entregables y la distribución de notas, pretendemos dar un peso mayor a éstos como resultados parciales y finales del proyecto desarrollado por los alumnos. Conforme la complejidad del proyecto va evolucionando, las notas van teniendo un peso creciente conforme avanza la asignatura, hasta llegar al último Item Peso Maximo Nota N Total MTX 0,2 1 0,2 7 1,4 FXX 0,1 1 0,1 12 1,2 D01 0,4 D02 0,8 D03 1 RT01 0,2 D04.A 0,05 5 0,25 1 0,25 D04.B 0,1 5 0,5 1 0,5 D04.C 0,2 5 1 1 1 D04.D 0,65 5 3,25 1 3,25 TOTAL 10 Cuadro 1: Modelo de evaluación de la asignatura. entregable (D04) que proporciona el 50 % de la nota final. Este último entregable, el cuál corresponde con el proyecto completado, se evalúa en función de distintos aspectos, incluyendo una defensa individual en la que los profesores evalúan las habilidades adquiridas por los alumnos para enfrentarse al tipo de proyectos que se proponen. 3.4. Herramientas utilizadas Con el fin de aligerar la carga de trabajo del profesor, se ha hecho un uso intensivo de herramientas TIC para dar soporte a la metodología docente de la asignatura. La combinación de este conjunto de herramientas con la aplicación intensiva de la revisión por pares entre alumnos en la sesiones de feedback permite la obtención de muchas evidencias y valoraciones sin incrementar en exceso la carga de trabajo del profesor. En el Cuadro 2 se muestra el uso específico de cada una de las herramientas utilizadas agrupadas en cinco áreas principales. La herramienta principal que se ha utilizado a la hora de coordinar los alumnos y grupos ha sido el portal ABP realizado en la propia universidad 1que permite la creación y composición de grupos de manera autónoma por parte de los alumnos así como la definición de un calendario de entregables y defensas para que cada grupo realice las entregas y reserve su slot específico en la defensa final. Este mecanismo de asignación permite gestionar de manera ágil las defensas y organizar a los profesores para poder secuenciar los esfuerzos y dedicar un tiempo específico a cada grupo de manera equitativa. Ademas de la herramienta de gestión de ABP, se ha utilizado la plataforma piazza 2para una coordinación puntual a la hora de organizar la investigación previa a las mesas redondas de forma que se dividiera el trabajo a realizar entre todos los alumnos. 1Disponible en http://opera.eii.us.es/sos 2Disponible en http://www.piazza.com Respecto a la publicación de contenidos, al final de cada clase integral se proporcionan dos tipos de contenidos a los alumnos: por un lado la presentación utilizada es publicada en una carpeta compartida a todos los alumnos dentro del sistema Google Drive que permite establecer permisos de acceso pormenorizados por cada elemento; por otro lado, durante el desarrollo de la clase se graba la pantalla y el audio del profesor para generar un vídeo que es desplegado en la plataforma Youtube y clasificado dentro de un canal que permite ordenar y categorizar los contenidos. El software de grabación que se ha utilizado para elaborar los videos ha sido la plataforma Screen-o-matic 3que permite la edición y montaje del material asi como su exportación a formato mp4. Para realizar las notificaciones a los alumnos de tareas, avisos y calificaciones se utilizan distintos medios, en base al tipo de elemento a comunicar. El medio principal de comunicación es el backlog de trabajo realizado en un documento compartido usando la plataforma Google Doc 4. Este backlog contiene la lista de verificaciones concretas que se relizará en la próxima sesión de feedback asi como las lista de verificación para los entregables previstos. Por otro lado, la herramienta de soporte al aprendizaje Blackboard5ha sido utilizada para ir registrando semanalmente la evaluación de los alumnos de forma que el propio alumno puede ver como su calificación va incrementando en base al trabajo realizado. Finalmente, a través de la herramienta piazza se avisa de los cambios en el backlog y aclaraciones sobre posibles ambigüedades que hayan sido detectadas y solventadas. A la hora de evaluar el conocimiento se establecen dos mecanismos. Por un lado, la plataforma Blackboard da soporte a la creación de los Micro Tests que pueden ser realizados en la propia clase; esta herramienta dispone de distintas facilidades a la hora de diseñar la base de datos de preguntas categorizadas de manera que se pueden establecer reglas generativas para que el test que se muestre a cada alumno sea individualizado en base a una muestra aleatoria. Por otro lado, el portal ABP permite la gestión de las defensas finales (D04) y la posterior calificación de los grupos de trabajo de forma conjunta. La principal herramienta de comunicación entre los profesores y los alumnos utilizada ha sido Piazza; esta plataforma permite la elaboración de preguntas de manera colaborativa entre los propios alumnos y la posterior respuesta entre ellos. En este contexto, el profesor puede establecer respuestas que son identificadas de manera singular dentro de la plataforma o, en su defecto, el docente puede resaltar una respuesta concreta 3Disponible en https://screencast-o-matic.com/ 4El backlog esta disponible en https://goo.gl/GlNj3K 5Disponible en http://www.blackboard.com Blackboard Google Drive Google Docs Youtube Screen-o-matic Piazza Portal ABP Coordinación de los alumnos y grupos 7 7 Publicación de contenidos de clases integrales 7 7 7 Notificaciones de tareas, avisos y calificaciones 7 7 7 Evaluación del conocimiento 7 7 Medio de comunicación Profesor →Alumno 7 Medio de comunicación Alumno →Profesor 7 7 Medio de comunicación Alumno →Alumno 7 Cuadro 2: Uso de herramientas de soporte a la metodología. realizada por un alumno en el caso de que considere que proporciona un conocimiento especialmente útil. Desde el punto de vista de los contenidos, los alumnos pueden utilizar las herramientas de comentarios y feedback previstos dentro de la plataforma Youtube para señalar los vídeos mas interesantes o útiles en el contexto de la asignatura de forma que el profesor sea notificado. Desde el punto de vista de las competencias específicas a adquirir en el marco de la ingeniería del software, durante la asignatura se ha empleado la combinación de tres herramientas integradas para la gestión del proceso de desarrollo software. Por un lado se ha utilizado la plataforma Github6para realizar la gestión del versionado del código de manera coordinada en el grupo. Por otro lado la plataforma Zenhub7, permite la elaboración de un tablero kanban de gestión de las tareas registradas en Github para que los miembros del grupo puedan organizarlas visualmente y dividir la responsabilidad del proyecto y planificarlas de manera adecuada. Por ultimo, la herramienta Toggle8, permite el registro del tiempo dedicado a cada tarea de Github a fin de mejorar en la estimación y reparto equilibrado de los esfuerzos. Cabe señalar que el uso integrado de estas herramientas ha permitido tener un conjunto extenso de evidencias que han posibilitado el posterior análisis detallado en la sección 4. 4. Análisis de resultados En esta sección se desarrolla un análisis de la experiencia desde dos perspectivas: por un lado se realiza un análisis comparativo del curso 2015-16 (donde se ha aplicado) frente al curso anterior 2014-15 donde se aplicaba una metodología tradicional de teoría con clase magistral y práctica en laboratorio. Por otro lado, se ha realizado un analisis del curso 2015-16 para extraer 6Disponible en http://github.com 7Disponible en https://www.zenhub.com/ 8Disponible en https://toggl.com/ 2014-2015 2015-2016 Mínimo 3,2 0 Media 6,3 6,6 Mediana 6,4 7,6 Máximo 8,4 10 Cuadro 3: Notas finales de los cursos. un conjunto de indicadores interesantes para mejorar la metodología y evaluar la satisfacción de los estudiantes. 4.1. Comparativa de metodologías Los resultados en cuanto a la nota final para los cursos 2014-15, y 2015-16 se muestran en la tabla 3. En esta tabla puede apreciarse como ha aumentado clara mente la nota media, pero especialmente la mediana (que no se ve afectada por los outliers con notas extremadamente bajas). Además, se aprecia como el rango de las notas es mucho más amplio, reflejando más fielmente la variabilidad el trabajo realizado y los conocimientos adquiridos por los estudiantes. La figura 1 muestra los gráficos de densidad de probabilidad de las notas en los cursos 2014-15 y 2015- 16; estos gráficos reflejan la distribución estadística de los datos más fielmente que los histogramas al no verse afectados por el numero de cajas. Puede apreciarse que con la metodología del curso 2016 se evidencian dos perfiles claros de alumnos claramente diferenciados, cada uno de los cuales sigue a su vez una distribución aproximadamente normal, y que la distribución de notas es más uniforme a lo largo de todo el rango. Existen diferencias estadísticamente significativas en los resultados obtenidos por los alumnos en un año y otro (a un nivel de significatividad de α= 0,1), por lo que podemos afirmar que los resultados del año 2016 son significativamente mejores. Para evaluar el impacto del cambio metodológico en la participación del alumnado y el abandono de la asig- 0 2 4 6 8 10 0.00 0.10 0.20 0.30 Nota Densidad 2014−2015 2015−2016 Figura 1: Gráfica de densidad de notas. natura usamos los datos recabados a través de la plataforma Piazza, y el número de no presentados respectivamente; la figura 2 muestra los diagramas de cajas de las distribuciones de visitas y preguntas para los cursos 2014-15 y 2015-16; en ellos, puede apreciarse un aumento de la implicación de los alumnos en ambos casos, siendo especialmente llamativo el aumento en las visitas a la plataforma. 2015 2016 0 20 40 60 80 100 Año Vistas 2015 2016 0 5 10 15 20 Año Preguntas Figura 2: Diagramas de cajas de las visitas / preguntas a la plataforma Piazza por alumno en cada curso. 4.2. Desarrollo del curso 2015/16 Gracias al conjunto de herramientas utilizadas, se generó un conjunto de datos que proporciona gran cantidad de información sobre el volumen de trabajo realizado, su intensidad y distribución temporal. En términos globales, se registraron 5119 commits (actualizaciones de código fuente) asociados a la asignatura, y se imputaron 3386 horas de trabajo, con una media de 96,3horas imputadas y 131,3commits realizados por alumno. Las estadísticas de satisfacción del alumnado respecto de la asignatura, obtenidos a través de un formulario web anónimo, se muestran en la figura 3 usando gráficos de barras (en una escala de 0 a 8). Concretamente, respecto del nivel de satisfacción general, se aprecia que el 71,5% de las respuestas presenta un valor muy alto (7 u 8). Respecto del nivel de satisfacción del alumnado con la metodología docente empleada, se aprecia que el 56,2 % de las respuestas presentan una satisfacción muy alta (7 u 8), y más del 70 % presenta una satisfacción positiva (superior a 4). Respecto del nivel de satisfacción con la metodología de evaluación, de nuevo más del 70 % de las respuestas presenta una satisfacción positiva (superior a 4). 12345678 Nivel de Satisfacción Frecuencia 0123456 General Met. Docente Met. Evaluación Figura 3: Diagrama de barras de la satisfacción (escala de 0 a 8). Se ha realizado además un estudio de correlación entre las siguientes variables: nota final obtenida en la asignatura, número total de commits realizados, número de horas totales invertidas, y duración media de las sesiones de trabajo realizadas por los alumnos. Comentaremos los resultados obtenidos mediante el coeficiente de correlación de Spearman, dado que intuimos que la relaciones entre las variables no serán necesariamente lineales (también se calcularon los resultados usando el coeficiente de Pearson obteniendo resultados menos concluyentes). Los resultados de dicho estudio se representan en la figura 4. Concretamente, en la diagonal de la matriz se muestran cada una de las variables, en las celdas concretas se representa el coeficiente de correlación obtenido para las variables en la fila y columna correspondiente (visual y numéricamente). Por ejemplo, el círculo azul de la primera fila y la segunda columna representa que existe una correlación positiva entre la nota obtenida por los alumnos y el número de commits totales que realizan (es decir, cuando la nota es mayor que la media para un alumno, en número de commits también tiende a ser también mayor que la media, y viceversa). Así, en la segunda fila de la primera columna está representado el valor numérico de dicha correlación (en este caso 0,34). Es interesante observar la mayor correlación obtenida para la nota con el número de commits que con el número total de horas invertidas, aún siendo ambas positivas y no despreciables. Esto nos lleva a pensar que el número total de commits refleja mejor la constancia en el trabajo realizado, factor que consideramos clave para obtener buenos resultados con la metodología empleada. Además, resulta sorprendente la aparente ausencia de correlación entre el número de commits y el número de horas y la duración de las sesiones de trabajo. Finalmente, la obtención de valores negativos de correlación entre la duración en horas de las sesiones de trabajo y la nota obtenida puede deberse a que dichas sesiones, a pesar de ser largas se han realizado de forma más esporádica y puntual, lo que refuerza nuestra consideración anterior sobre la constancia. −1 −0.8 −0.6 −0.4 −0.2 0 0.2 0.4 0.6 0.8 1 Nota Commits Tiempo total (h) Duración media (h) 0.34 0.25 −0.2 −0.05 −0.03 0.36 Figura 4: Diagrama de correlación de variables. 5. Conclusiones En esta ponencia presentamos una experiencia docente dentro del entorno de la ingeniería del software donde se ha enriquecido el enfoque de aprendizaje basado en proyectos con la aplicación de los principios de las metodologías ágiles para desarrollar un ciclo de feedback continuo que ha fomentado en gran medida la participación activa y la motivación de los estudiantes. En este contexto, a pesar de que se la experiencia se centra en el ámbito de una asignatura de Ingeniería del Software creemos que esta metodología podría llegar a ser adaptada a otras asignaturas con fuerte carga tecnológica dentro de los estudios de la Ingeniería Informática. En base al análisis cuantitativo y cualitativo de los resultados, se ha apreciado una mejora estadísticamente significativa en la calificaciones de los alumnos en comparación con el año anterior, y una distribución de calificaciones que consideramos refleja con mas precisión el conocimiento adquirido por los alumnos. Además, el grado de satisfacción de los alumnos ha sido bastante alto, y su participación a través de las plataformas TIC usadas también ha aumentado. Queremos resaltar la gran cantidad de evidencias que se han podido recoger en esta experiencia debido a la combinación de plataformas utilizadas que abran la puerta a la realización de distintos estudios en el futuro. En particular, creemos que tenemos el marco analítico apropiado para el estudio e identificación de indicadores predictivos de abandono que puedan ser calculados automáticamente en etapas iniciales del curso de forma que se pudieran abordar actuaciones especificas de apoyo individualizado. Referencias [1] Estefanía Argente, Ana García-Fornes, and Agustín Espinosa. Aplicando la metodología Flipped-Teaching en el Grado de Ingeniería Informática : una experiencia práctica. In JENUI 2016, pages 221–228, Almería, 2016. [2] Sandra Baldassarri and Pedro Álvarez. M-eRoDes: involucrando a los estudiantes en la creación y evaluación colaborativa de objetos de aprendizaje. In JENUI 2016, pages 195–202, Almería, 2016. [3] Stephanie Bell. Project-Based Learning for the 21st Century: Skills for the Future. The Clearing House: A Journal of Educational Strategies, Issues and Ideas, 83(2):39–43, 1 2010. [4] John Biggs and Tang; Catherine. Teaching for Quality Learning at University. Open University Press, 2007. [5] Andrew Cain and Muhammad Ali Babar. Reflections on applying constructive alignment with formative feedback for teaching introductory programming and software architecture. In ICSE 2016, pages 336– 345, New York, New York, USA, 2016. ACM Press. [6] Martin Fowler and Jim Highsmith. The agile manifesto. Software Development, 9(August):28–35, 2001. [7] María José García García, Juan José Escribano Otero, and Mª Cruz Gaya López. Experiencia de aplicación de ABP al Grado de Ingeniería Informática. In JENUI 2014, pages 125–132, Oviedo, 2014. [8] Alfredo Goñi, Jesús Ibáñez, Jon Iturrioz, and José Ángel Vadillo. Aprendizaje Basado en Proyectos usando metodologías ágiles para una asignatura básica de Ingeniería del Software. In JENUI 2014, pages 133–140, Oviedo, 2014. [9] Mercedes Marqués. Qué hay detrás de la clase al revés (flipped classroom). In JENUI 2016, pages 77–84, Almería, 2016. [10] Alberto Prieto, Beatriz Prieto, and Begoña del Pino. Una experiencia de flipped classroom. In JENUI 2016, pages 237–244, Almería, 2016. [11] Yvonne Sedelmaier and Dieter Landes. Active and Inductive Learning in Software Engineering Education. In ICSE 2015, pages 418–427. IEEE, 5 2015.