Una experiencia en el diseño y la impartición de una asignatura en torno a la metodología del aprendizaje basado en proyectos

Una experiencia en el diseño y la impartición de una asignatura en torno a la metodología del aprendizaje basado en proyectos José Miguel Cañete Valdeón, Octavio Martín Díaz Departamento de Lenguajes y Sistemas Informáticos Universidad de Sevilla ETS de Ingeniería Informática. Avenida de la Reina Mercedes, S/N, 41012, Sevilla [email protected], [email protected] Resumen En este artículo presentamos nuestra experiencia en la creación e impartición de una asignatura sobre Arquitecturas Software que aplica la metodología del aprendizaje basado en proyectos. La asignatura pertenece a una joven titulación de Máster Oficial creada bajo los principios del Espacio Europeo de Educación Superior (EEES) y actualmente ofrecida por la Universidad de Sevilla como parte de su oferta de estudios de postgrado. Las decisiones tomadas en el diseño de la asignatura en torno a una metodología activa y las conclusiones extraídas de su impartición pueden ser de ayuda a otros profesores durante el proceso de adaptación de las diferentes titulaciones al EEES. 1. Introducción El aprendizaje basado en proyectos (ABP) considera al estudiante como un elemento activo en la enseñanza, pasando de ser un mero receptor del conocimiento a descubrirlo por sí mismo. El objetivo no consiste en que el alumno “reinvente la rueda”, sino en conseguir que su acercamiento al conocimiento sea activo y a la vez apasionante. Los orígenes de esta metodología se remontan a los años setenta, cuando se fundaron varias universidades en el norte de Europa que practicaban nuevas formas de enseñanza centradas en los estudiantes [5] como la Universidad de Maastricht en Holanda, la Universidad de Linköping en Suecia y el Centro Universitario de Roskilde y la Universidad de Aalborg, ambos en Dinamarca. El actual proceso de convergencia al Espacio Europeo de Educación Superior (EEES) nos brinda una excelente oportunidad para revisar los métodos tradicionales. Con esto no queremos decir que haya que enterrar los “viejos métodos”, ya que el olvido del conocimiento (sobre didáctica en este caso) nunca conduce a ningún avance. Por el contrario, pensamos que las metodologías clásicas se pueden enriquecer en aspectos tales como la motivación de los estudiantes, la aplicación de la teoría a la práctica, la toma de decisiones y el autoaprendizaje. Sin embargo, el cambio que exige el ABP supone un esfuerzo importante que afecta a múltiples elementos didácticos más allá de las dimensiones tradicionales “estudiante”, “profesor” y “asignatura”. Según Kolmos [5] el modelo didáctico ABP consta de varios elementos interrelacionados: objetivos y competencias; expectativas y actitudes de los participantes; trabajo de proyecto (incluyendo grupos, extensión, duración, papel del profesor); formas de evaluación; elección del material y preparación profesional; y, afectando a todos los anteriores, organización, cultura, recursos y marcos físicos. Todos estos elementos deben tener una concordancia entre sí (Biggs [3] habla de “alineación”). Conscientes de estas dificultades, en este artículo pretendemos aportar una pequeña contribución a esta tarea presentando nuestra experiencia relativa al diseño de una asignatura sobre Arquitecturas Software, a nivel de Máster Oficial, y a su impartición durante un cuatrimestre. El hecho de que la titulación fuese de nueva creación nos ha permitido diseñar una asignatura con total libertad, exentos de ataduras metodológicas heredadas de anteriores planes de estudios. Los dos profesores implicados contamos con diez años de experiencia previa en docencia universitaria basada en métodos tradicionales: clases magistrales, prácticas de laboratorio y atención al estudiante en tutorías. Por otro lado hemos recibido formación previa XV JENUI. Barcelona, 8-10 de julio de 2009 ISBN: 978-84-692-2758-9 http://jenui2009.fib.upc.edu/ 396 Métodos pedagógicos innovadores en ABP por parte de nuestra universidad. Estos factores constituyen las herramientas con las que partimos a la hora de elaborar esta nueva asignatura. El resto del artículo se estructura de la siguiente manera: en la Sección 2 exponemos los principios teóricos del ABP. En la Sección 3 describimos el diseño de la asignatura y en la siguiente exponemos los resultados de su impartición. Por último, la Sección 5 resume brevemente las conclusiones. 2. Principios teóricos del ABP y el modelo de Aalborg Desde el punto de vista teórico, la metodología ABP no se comenzó a estudiar formalmente hasta los años noventa. En las dos décadas anteriores el ABP había estado sustentado sobre una base eminentemente pragmática, realizándose ajustes a pequeña escala a partir de la prueba y el error. 2.1. Principios teóricos Kolmos [5] recopila los principios teóricos de esta metodología: (1) la formulación de una problemática es el punto de partida de los procesos de aprendizaje; (2) los procesos de aprendizaje son dirigidos por los participantes; (3) las problemáticas pueden estar vinculadas a la experiencia de los participantes; (4) el aprendizaje se basa en una actividad, y ésta consta de los procesos de búsqueda, toma de decisiones y escritura; (5) se reconoce el valor de la interdisciplinaridad para solucionar el problema planteado; (6) la ejemplaridad, que supone que los estudiantes adquieren una comprensión más profunda de algunas problemáticas seleccionadas y complejas; (7) los estudiantes aprenden a relacionar la experiencia empírica con la teoría; y (8) el aprendizaje se basa en el trabajo en grupo. Estos principios se concretan en los modelos didácticos. Kolmos considera dos: el de Maastrich y el de Aalborg. Nos centraremos en éste último por ser el más empleado en el ámbito de las ingenierías. 2.2 El modelo de Aalborg Este modelo se caracteriza por la realización de un proyecto propiamente dicho a partir de un problema. Su desarrollo fomenta las competencias de dirección de proyectos y de colaboración, entre otras. Existen dos variantes: el proyecto por disciplinas y el proyecto por problemáticas. En la primera, las disciplinas y los métodos profesionales han sido elegidos de antemano por el tutor. Dentro de este marco los estudiantes tienen la libertad de encontrar y formular el problema. En el proyecto por problemáticas el tutor proporciona el problema pero es dicho problema el que dirige la elección de disciplinas y métodos profesionales, lo cual queda en manos de los estudiantes. 3. Diseño de la asignatura El diseño de la asignatura sigue la propuesta de López Ruiz [6,7] sobre organización de asignaturas basadas en ABP, considerando objetivos, redes de problemas y de contenidos, metodología y evaluación. El tiempo invertido fue superior al de una asignatura tradicional, debido en parte a nuestra inexperiencia en ABP. 3.1. Objetivos El primer paso consiste en plantearnos qué pretendemos con esta asignatura. Organizamos nuestros objetivos en cuatro categorías (Tabla 1): los teóricos (relacionados puramente con el saber), los prácticos o procedimentales (concernientes al saber hacer), los actitudinales (relativos al comportamiento, al saber ser) y los orientados al cambio (cultivar la capacidad para aprender). A partir de la formulación de objetivos nos resulta mucho más sencillo identificar las competencias genéricas, mostradas en la Tabla 2. Teóricos Conocimientos sobre arquitecturas software, estilos, líneas de productos, la interrelación requisitos-arquitectura, atributos de calidad y tácticas de diseño Prácticos Saber reconocer las diferentes tácticas de diseño en arquitecturas de sistemas software reales; saber extraer la arquitectura de un sistema a partir de la documentación existente y su código A ctitudinales Respetar las ideas y argumentos de los compañeros, ser capaces de aceptar críticas y también de hacer autocrítica Orientados al cambio Saber analizar, criticar y en su caso adoptar nuevas arquitecturas Tabla 1. Objetivos de la asignatura XV Jornadas de Enseñanza Universitaria de la Informática 397 Cognitivas Orientación al aprendizaje Creatividad Instrumentales Resolución de problemas Aplicar los conocimientos a la práctica A ctitudinales Habilidades para trabajar en equipo Capacidad de crítica y autocrítica Tabla 2. Competencias de la asignatura 3.2. Red de problemas y red de contenidos A continuación nos planteamos cuáles son las preguntas a las que da respuesta nuestra asignatura. Estas preguntas se enlazarán en una red de problemas que determinarán los contenidos de la asignatura. Como propone López Ruiz [7, p. 254]: “es conveniente que en esta web de preguntas se diferencien unos pocos interrogantes claves que conformen los nodos básicos y a partir de ahí se desplieguen en conexión con los correspondientes subproblemas”. En la Figura 1 pueden verse los nodos básicos de la red. Las flechas representan los posibles itinerarios en la formulación de estas preguntas. Figura 1. Red de problemas a primer nivel Heimlich y Pittelman [4] proponen organizar los contenidos en forma de un mapa semántico, que es una red de conceptos donde se interrelacionan las distintas nociones clave que se van a desarrollar. La Figura 2 muestra la red de contenidos para la asignatura mientras que la Tabla 3 relaciona los conceptos de la red con los distintos núcleos de problemas. Aunque casi todos los conceptos aparecen en varios problemas hemos preferido indicar en la Tabla 3 sólo los núcleos en los que cada concepto es especialmente relevante. 3.3. Metodología Técnicas docentes. En primer lugar debemos seleccionar la técnica docente más adecuada para cada problema de la red. En las estrategias de enseñanza universitaria podemos encontrar, entre otras, la exposición interactiva (clase magistral), los estudios de casos, la dinámica de grupos y el aprendizaje basado en proyectos. Figura 2. Red de contenidos. Notación: UML Conceptos Núcleos A rquitectura software N1 Estilos arquitectónicos N1 A tributos de calidad N2 Tácticas de diseño N2 Problema software N2, N4 Líneas de productos N3 Método ADD N2, N4 Ciclo de vida N4 Tabla 3. Matriz de trazabilidad de conceptos El núcleo N4 se presta a la exposición interactiva ya que contiene una extensa carga teórica que abarca el método ADD [2] y su integración en el proceso Rational Unified Process. No tendría sentido que los alumnos iniciasen un proyecto de investigación para descubrir estos resultados metodológicos por sí mismos en unos pocos meses, ya que dicho conocimiento es el fruto de muchos años de trabajo por reconocidos investigadores en Ingeniería del Software. Para el núcleo N3 optamos por el análisis de casos, estudiando las arquitecturas de algunas líneas de productos a nivel industrial. Dado que esta información es de muy difícil acceso (restricciones de las propias empresas, derechos de propiedad intelectual), plantear proyectos en este núcleo hubiera resultado inadecuado ya que los estudiantes no hubieran podido acceder a las fuentes. Los núcleos N1 y N2 encajan de manera natural en la filosofía del ABP. Si proponemos como proyecto la investigación de un sistema 398 Métodos pedagógicos innovadores software real y de código abierto, los alumnos pueden descubrir los estilos en torno a los cuales se ha organizado la arquitectura del sistema (N1) así como las tácticas [2] empleadas en el diseño de la misma en función de los atributos de calidad deseados en el problema software para el cual el sistema es solución (N2). En concreto, el proyecto propuesto tiene los siguientes objetivos: (1) reconstrucción racional de la arquitectura del sistema, con identificación de estilos; (2) estudio del problema software para el cual el sistema es solución, prestando especial atención a los atributos de calidad críticos en dicho problema; y (3) identificación de las tácticas de diseño empleadas en la ingeniería de la arquitectura del sistema. Por tanto, seguimos el modelo de Aalborg con proyectos por disciplinas. Proporcionamos a los estudiantes las disciplinas y métodos profesionales pero serán ellos los que determinen la problemática (el sistema software sobre el que versará el proyecto). Cubrimiento de competencias. La realización de un proyecto de investigación [8] fomenta el desarrollo de competencias que no se podrían conseguir meramente con el aprendizaje memorístico. La reconstrucción racional de una arquitectura a partir de la documentación de un sistema software y de su código fuente estimula la creatividad, así como la capacidad de aprender y el análisis de información desde distintas fuentes. El estudio del problema software estimula igualmente el análisis de la información. La identificación de tácticas de diseño fomenta el aprendizaje, la aplicación de los conocimientos a la práctica (ya que las principales tácticas se han explicado previamente en un seminario), pero también la capacidad de crítica (ya que los estudiantes pueden llegar a la conclusión de que determinadas tácticas empleadas en la construcción de un sistema no fueron acertadas para la satisfacción de un atributo de calidad). El proyecto fomenta las habilidades para trabajar en equipo. Su naturaleza compleja, propia de un trabajo de investigación, enfrenta a los alumnos con situaciones nuevas a las que deben adaptarse y resolver sobre la marcha (por ejemplo, como sucede al encontrar en la documentación versiones contradictorias sobre los módulos que componen el sistema). Apoyo teórico mediante seminarios. Decidimos añadir varios seminarios en los que ir facilitando a los alumnos las herramientas teóricas que necesitarán a medida que avancen en el proyecto. En concreto planificamos cuatro seminarios: estilos arquitectónicos, relación entre el problema software y la arquitectura, atributos de calidad y un catálogo de tácticas de diseño para dichos atributos. Seguimiento semanal de los proyectos. Pensamos que es necesario un seguimiento continuo del desarrollo de los distintos proyectos debido a la complejidad de los mismos, lo que además nos permite determinar si los estudiantes están adquiriendo las competencias de manera adecuada. Para ello disponemos de dos tipos de mecanismos: las reuniones con los alumnos en la propia aula (unos 20 minutos por grupo) y las tutorías (unos 60 minutos por grupo). Ambos tipos de sesiones se alternan semanalmente. Los alumnos deben exponer el trabajo realizado durante la semana, pero también sus dudas y sus errores. La labor del profesor no es resolverles el problema sino orientarles, avisarles de riesgos potenciales que pudieran existir en su distribución del trabajo, proponer fuentes de información que no hayan considerado, indicar la existencia de errores graves (si los hubiera) en lo que llevan del proyecto, e incluso hacer de mediador en posibles conflictos o discusiones entre los integrantes del grupo. Planificación según el modelo de Aalborg. Nuestra asignatura consta de 5 créditos ECTS lo que equivale a 150 horas de trabajo del alumno. Decidimos seguir el modelo de Aalborg para la distribución temporal y por tanto dedicar aproximadamente el 50% del tiempo total del alumno al desarrollo del proyecto (exactamente un 53.3%). Este tiempo se divide en horas de clase dedicadas al proyecto, horas de tutorías y trabajo personal del alumno en el proyecto (aprendizaje investigativo). El otro 50% se reparte entre las exposiciones interactivas (en el aula), los análisis de casos (en el aula), las tutorías (para comprobar la asimilación de los conocimientos) y por supuesto el tiempo que el alumno debe dedicar al estudio. La Tabla 4 muestra el reparto porcentual del esfuerzo del alumno y se ha obtenido a partir de una distribución previa de las 150 horas totales. Las XV Jornadas de Enseñanza Universitaria de la Informática 399 clases de exposiciones interactivas incluyen: cuatro seminarios de proyecto, una clase magistral sobre metodología, las exposiciones de proyectos y las conclusiones finales. Las clases de proyecto se refieren al trabajo del alumno sobre el proyecto en el aula. Estas clases se alternaron semanalmente con las exposiciones interactivas y la clase del análisis de casos. Clases Tutorías Estudiar Total Proyecto 5.3 6.7 41.3 53.3 Exp.interactiv. 10 4 27.4 41.4 A nálisis casos 1.3 0.7 3.3 5.3 Total 16.6 11.4 72 100 Tabla 4. Esfuerzo del alumno (en porcentajes) Evaluación continua. La correcta realización de los proyectos de investigación requiere que los alumnos deban estudiar de manera continuada los contenidos teóricos ofrecidos en las exposiciones interactivas. Para medir el grado de asimilación de estos conocimientos establecimos tres exámenes, repartidos a lo largo del curso, una o dos semanas después de cada seminario. Por otra parte, las reuniones con los alumnos en tutorías nos permiten observar el grado de desarrollo de las competencias. Consideramos interesante anotar en el portafolio un seguimiento del alumno, centrándonos en los siguientes aspectos: asistencia del alumno; si el alumno tuvo una participación activa durante la sesión; si es capaz de resolver los problemas que le van surgiendo; si está aplicando al proyecto los conocimientos impartidos en los seminarios; y la coordinación entre miembros del grupo. Quevedo y Montañés [9] exponen un interesante método para la estimación del rendimiento de un alumno en un grupo. La técnica requiere que el alumno realice rotaciones por diferentes grupos, estimando su aportación individual en función del rendimiento de los grupos en los que va participando. Sin embargo, dada la complejidad de los proyectos de investigación que tratamos y las grandes diferencias entre los mismos, consideramos difícil poder aplicar este método aquí. La capacidad de crítica y autocrítica se puede evaluar directamente sobre la memoria entregada ya que requerimos expresamente que los alumnos incluyan esta información (véase la Figura 3). Para la evaluación del proyecto seguimos varios de los criterios propuestos por López Ruiz [6]: pertinencia de las fuentes consideradas, rigor y precisión en el análisis de los datos, coherencia entre los distintos apartados del trabajo y adecuación de las conclusiones. Ponderamos los resultados de los exámenes al 20% de la calificación final. El 80% restante se reparte entre la memoria del proyecto y la evolución de las 6 competencias en el alumno según se ha observado en las tutorías, ponderando cada una al 4%. Una buena referencia para la evaluación de las competencias la constituyen los indicadores y descriptores propuestos por Villa y Poblete [11]. Memoria a modo de artículo científico. Consideramos fundamental el que los alumnos se habitúen a exponer sus resultados según el estilo científico: formulación de hipótesis de partida, exposición de datos, análisis razonado de los datos y obtención de conclusiones que respalden las hipótesis. Para ello proporcionamos una plantilla de documento a la que los grupos deben ajustarse. La Figura 3 muestra un breve resumen de la plantilla. Figura 3. Esquema para la memoria del proyecto Publicación y exposición de resultados. Mediante ABP el aula se convierte en un escenario de generación de conocimiento. Los proyectos contienen resultados de investigación (aunque estén sólo parcialmente correctos). Pensamos que es esencial compartir este conocimiento generado entre todos los estudiantes de la asignatura. Para ello disponemos de dos mecanismos: la publicación de los resultados en la web de la asignatura y la 400 Métodos pedagógicos innovadores exposición por parte de cada grupo de su trabajo. Las exposiciones se pueden organizar como ponencias científicas, con una duración limitada tras la cual tanto los alumnos como los profesores pueden realizar sus preguntas a los ponentes. De este modo conseguimos favorecer la democratización de la escuela [7] donde la información fluye de manera horizontal. Es conveniente que el profesor haya estudiado y corregido las memorias de los alumnos antes de las exposiciones, de manera que sus preguntas sean más precisas. Así mismo resulta fundamental incluir una sesión donde el profesor exponga las conclusiones obtenidas de los proyectos, indicando los logros conseguidos por los estudiantes pero también alertando de los errores comúnmente cometidos. Se debe indicar a los alumnos que los proyectos publicados pueden contener errores y deben ser considerados como versiones no finales. Se pueden tener reuniones posteriores con los alumnos interesados donde el profesor les explique los errores que contiene la memoria de su proyecto. 4. Impartición de la asignatura La asignatura se ha impartido por primera vez en el primer cuatrimestre del curso 2008/09 contando con 24 alumnos matriculados. Este número muestra el enorme interés despertado por la asignatura ya que supone más del 90% de los alumnos totales del Máster Oficial. Uno de los alumnos nunca llegó a asistir y otro abandonó la asignatura por causas ajenas a la misma. Por ello, en adelante, consideraremos que el número de alumnos es de 22. Se formaron seis equipos de trabajo. Cuatro se constituyeron con cinco miembros; dos alumnos optaron por formar grupos unipersonales, pese a nuestras recomendaciones. Los sistemas elegidos para los proyectos fueron Sesame, Jena, OpenLaszlo, Hibernate, Apache Geronimo y Apache Tomcat. A continuación describimos las conclusiones obtenidas de la impartición de la asignatura. Dificultad de adaptación del alumnado. En las primeras sesiones de tutorías observamos que los estudiantes no estaban comprendiendo el objetivo del ABP ya que consideraban el proyecto como un mero trabajo de recopilación de información a partir de libros y artículos. Sin embargo los sistemas software de código abierto rara vez cuentan con una buena documentación sobre el diseño arquitectónico. Incluso en aquellos casos en los que la arquitectura aparece descrita, los estilos no suelen estar correctamente identificados ni tampoco se determinan cuáles son las tácticas empleadas. Por tanto el trabajo a realizar por los alumnos es un verdadero proyecto de investigación. Los estudiantes sólo comprendieron esta circunstancia a partir de la tercera semana de trabajo en el proyecto. Desigualdad de compromiso entre los miembros del grupo. Otro de los problemas que detectamos en todos los grupos es la existencia de alumnos que no se implicaban en el proyecto, siendo su papel durante las tutorías completamente pasivo. Para resolver esta situación optamos por indicarles que cada miembro del grupo debía encargarse del análisis de las tácticas en un módulo arquitectónico de su elección. En las sesiones de tutorías realizábamos preguntas a cada uno de los miembros del grupo acerca de sus averiguaciones sobre el módulo escogido. De esta manera conseguimos igualar el nivel de compromiso ya que los alumnos más desmotivados no podían ocultarse tras el trabajo realizado por otros. Por otra parte, cada alumno del grupo elegía el módulo que más le interesara, aumentando su motivación. El hecho de tener asignado un módulo también aumentó la responsabilidad de los alumnos y mejoró su autoestima (al sentirse como parte integrante de un equipo). Es decir, se estableció un paralelismo entre los módulos de la arquitectura y los miembros del grupo que los analizaban. Buenos proyectos de investigación. Consideramos que los resultados descritos en las memorias de proyectos fueron buenos. En promedio, el 75% de las tácticas identificadas estaban bien justificadas y eran correctas. A modo indicativo la Tabla 5 muestra una selección de los resultados extraídos de la corrección de las memorias. A fin de respetar la privacidad de los alumnos se han codificado los nombres de los sistemas. La primera columna indica el número total de tácticas identificadas mientras que la segunda expresa el número de XV Jornadas de Enseñanza Universitaria de la Informática 401 tácticas correctas y que además estaban bien justificadas. Las tres últimas columnas muestran, en este orden: eficacia (porcentaje de tácticas correctas y bien justificadas frente al número total de tácticas), existencia de críticas al sistema y existencia de autocrítica. Tácticas Correc. y Justif. E C A Sistema A 35 23 66 √X Sistema B 19 13 68 √ √ Sistema C 45 33 73 √ √ Sistema D 8 7 88 X X Sistema E 42 29 69 √ √ Sistema F 32 27 84 √X Tabla 5. Selección de resultados obtenidos de la evaluación de las memorias Poca autocrítica. Una competencia que no conseguimos fomentar fue la capacidad de autocrítica. Habíamos percibido esta circunstancia durante las sesiones de tutorías, por lo que creímos conveniente indicarlo de manera conjunta en una de las sesiones de proyecto realizadas en la propia aula. Sin embargo sólo tres de los seis grupos incluyeron una pequeña autocrítica en sus memorias (Tabla 5) y la justificaron por la falta de documentación existente. En el seminario donde expusimos las conclusiones finales hicimos referencia a este hecho. Pensamos que una posible razón a la ausencia de autocrítica es el temor de los alumnos a que ésta pudiera ser usada en su contra durante la evaluación. En cualquier caso, reiteramos que es una competencia que no hemos conseguido fomentar y en la que debemos trabajar más en el futuro. Éxito de las exposiciones de trabajos. Consideramos que el plantear una sesión de exposición de trabajos fue un elemento motivador para los estudiantes ya que pudieron mostrar el trabajo realizado durante meses. Opinión favorable de los estudiantes. El último día de clase realizamos una encuesta a los estudiantes presentes en el aula. Recibimos 19 respuestas, ausentándose sólo 3 estudiantes. La Tabla 6 muestra una selección de los resultados cuantitativos. La tabla está basada en la utilizada en el proyecto de innovación presentado por Reverte Bernabeu y otros [1, 10]. Las columnas indican dificultad percibida (D), interés (I) y satisfacción (S), estando valoradas del 1 (poca dificultad, ningún interés, nada satisfecho) al 5 (dificultad máxima, mucho interés, muy satisfecho). Como se aprecia, la labor de los profesores ha sido puntuada en torno al 3.5, al igual que la asignatura en su conjunto. Del trabajo de los alumnos destaca que valoraron con más de 4 el hecho de poder trabajar con el proyecto en horas de clase (recordemos que esto se planificó en semanas alternas). La labor de los profesores: D I S Clases teóricas 3.47 3.05 Profesor como guía en proyecto 3.42 3.11 Solución de dudas 3.58 3.53 A signatura en WebCT 4.21 4.26 Vuestro trabajo en grupo: D I S Planificación de tiempo e hitos 2.95 3.79 3.63 Comunicación en clase 2.68 4.00 3.79 Comunicación fuera de clase 2.84 3.74 3.79 División del trabajo 2.44 3.58 3.79 El poder trabajar en el proyecto dentro de la propia aula 2.53 4.16 4.05 A signatura en su conjunto 2.88 3.53 3.41 Tabla 6. Selección de resultados obtenidos en las encuestas finales a los alumnos Los alumnos pudieron escribir libremente sobre la metodología docente empleada. En la Tabla 7 hemos recopilado todas las opiniones, agrupando aquéllas similares entre sí y clasificándolas por su tipo (negativas, positivas y recomendaciones). Junto a cada una hemos indicado el número de estudiantes que las secundaron. En general los estudiantes han valorado muy positivamente la metodología empleada. Llama la atención que la mitad de los encuestados opina que existe un salto muy grande entre la teoría y la práctica y por tanto recomienda impartir más teoría para llevar a cabo los proyectos. Pensamos que esto responde a una concepción tradicional de la enseñanza universitaria, en cuyo seno se ha instruido a estos alumnos durante los cinco años de carrera previos al Máster Oficial, y donde el profesor debe proporcionar todo lo que el alumno tiene que estudiar. Por el contrario, el aprendizaje activo requiere del estudiante su propia búsqueda de conocimiento en las fuentes bibliográficas. Como profesores, impartimos las pinceladas básicas de la teoría necesaria pero esto no exime a los estudiantes del trabajo de 402 Métodos pedagógicos innovadores recurrir a los libros para ampliar el conocimiento explicado en clase. Creemos que esta competencia debe ser ejercitada desde el primer año de carrera. Opiniones negativas: Salto muy grande entre la teoría y la práctica 9 El tiempo consumido por el proyecto es excesivo 7 Exige nivel de sacrificio excesivo para un Máster 1 Opiniones positivas: La metodología me parece buena 10 Positivo el papel del alumno para su formación 1 Práctica y realista, mejor que metodolog. tradicional 3 No se memoriza a la fuerza, se aprende mucho más 3 Satisface las expectativas de la materia 1 Diferente de otras asignaturas 1 Los alumnos se enfrentan a situac. reales de invest. 1 Recomendaciones: Necesaria más teoría para llevar a cabo el proyecto 10 La temática del proyecto debe ser de programación 6 Tabla 7. Opiniones vertidas por los estudiantes sobre la metodología empleada En cuanto a la valoración de las tutorías, 10 de los encuestados opinan que les han resultado útiles. Respecto a la duración de las mismas hay diversidad de respuestas: 6 alumnos opinan que es adecuada mientras que otros tantos la consideran excesiva. Amplio uso de herramientas de trabajo colaborativo. Según los resultados de la encuesta, la mayoría de los estudiantes emplearon herramientas de trabajo colaborativo como Google Docs, Microsoft Office Groove, y páginas wiki. Los alumnos recurrieron a estas aplicaciones ya que la plataforma utilizada en la asignatura, WebCT, carece de tales funcionalidades. Los foros que creamos en WebCT (uno por grupo) prácticamente no se usaron (sólo 14 mensajes en total). 5. Conclusiones Hemos presentado un análisis del diseño de una asignatura a nivel de Máster Oficial y de su impartición durante un cuatrimestre. En la sección anterior hemos detallado las conclusiones fundamentales, que no repetimos aquí por razones de espacio. Pensamos que la metodología docente empleada (aprendizaje basado en proyectos) y la orientación hacia el EEES hacen de esta experiencia un recurso útil para el diseño de asignaturas en los nuevos planes de estudio. Referencias [1] Arques Corrales, P. y otros. Nuevas metodologías docentes ante el EEES. Proyectos de innovación tecnológicaeducativa. Universidad de Alicante, 2006. [2] Bass, L., Clements, P., y Kazman, R. Software Architecture in Practice (2nd ed). Addison Wesley, 2003. [3] Biggs, J. Teaching for Quality Learning at University (2nd ed). Open University Press, 2003. [4] Heimlich, J.E. y Pittelman, S.D. Los mapas semánticos. Estrategias de aplicación en el aula. Aprendizaje Visor/MEC, 1990. [5] Kolmos, A. Estrategias para desarrollar currículos basados en la formulación de problemas y organizados en base a proyectos. Educar, 33, págs. 77-96, 2004. [6] López Ruiz, J.I. La docencia basada en proyectos de investigación: una experiencia en la Educación Superior. En Zabalza, M.A. (Ed.). La calidad de la docencia en la Universidad. Ágora, 2000. [7] López Ruiz, J.I. Construir el currículum global. Otra enseñanza en la sociedad del conocimiento. Ediciones Aljibe, 2005. [8] Pozuelos, F.J. y Travé, G. Aprender investigando, investigar para aprender: el punto de vista de los futuros docentes. Investigación en la Escuela, 54, 5-25, 2004. [9] Quevedo, J.R. y Montañés, E. Estimación del rendimiento individual a partir del rendimiento de trabajo en grupo. Actas de las XIV Jornadas de Enseñanza Universitaria de la Informática, 2008. [10] Reverte Bernabeu, J.R., Gallego Sánchez, A.J, Molina Carmona, R. y Satorre Cuerda, R. El aprendizaje basado en proyectos como modelo docente. Experiencia interdisciplinar y herramientas groupware. Actas de las XIII Jornadas de Enseñanza Universitaria de la Informática, 2007. [11] Villa, A. y Poblete, M. Aprendizaje basado en competencias. Una propuesta para la evaluación de las competencias genéricas. Ediciones Mensajero, 2007.