Una experiencia de aprendizaje basado en proyectos utilizando

Una experiencia de aprendizaje basado en proyectos utilizando herramientas colaborativas de desarrollo de software libre Jose Emilio Labra Gayo, Daniel Fernández Lanvin, Jesús Calvo Salvador, Agustín Cernuda del Río Escuela Universitaria de Ingeniería Técnica Informática de Oviedo EUITIO Universidad de Oviedo

Entorno Escuela Universitaria Ingeniería Técnica Informática de Oviedo Unos 1200 alumnos 2 titulaciones: IT Informática de Gestión y Sistemas Reciente cambio de plan de estudios Guerra de optativas Muchas asignaturas optativas atractivas Intensificaciones Menos de 20 alumnos Desaparición de optativa

Asignatura Programación declarativa Optativa de 6 créditos (1 cuatrimestre), 25 alumnos aprox. Impartir paradigmas de programación declarativos Asignatura anterior: Programación Lógica y Funcional 2 meses de Programación funcional (lenguaje Haskell) 2 meses de Programación lógica (lenguaje Prolog…Curry) Esquema anterior de prácticas atractivo 10 entregables a lo largo del curso ! S E E E l e Cada entregable = pequeños ejercicios Resueltos previamente por el profesor Entorno y objetivos bien delimitado ( estudiantes contentos) Profundizar en características de los lenguajes Temática atractiva m a b stá n e os Vocabularios XML Gráficos en 2 -dimensiones (SVG) Mundos virtuales infinitos mediante octrees (WRML, X 3 D) e a ¡YAceptado en varios congresos (JENUI’ 03, WFLP’ 04, SINDI’ 05)

Algunas dudas en el paraíso Los alumnos estaban contentos, pero… Ejercicios un poco artificiosos (pocas posibilidades de fracaso) Fuerte auto-estima de los estudiantes (quizá excesiva? ) Algunos casos de plagio ¿Qué estaban aprendiendo? Los ejercicios atacaban diferentes características de los lenguajes No se planteaba un desarrollo software complejo ¿Y las competencias transversales? Trabajo en grupo, resolución de problemas, búsqueda de información… Falsa sensación de seguridad…¿y cuando salgan a la calle? ¿Y el profesor? Complejidad = definir ejercicios atractivos (con solución = artificiales) Trabajo completamente de docencia La línea de investigación del profesor va por otro lado Al año siguiente había que modificarlos… Repetición…¿aburrimiento? . . . ¿sensación de pérdida de tiempo?

La idea Resolver un proyecto real mediante técnicas de software libre Tema del proyecto: Intentar resolver un problema actual y real Que no esté resuelto Que sea atractivo y novedoso Que esté abierto para poder cambiar de rumbo Que el profesor conozca bien Que les guste a los estudiantes y al profesor Tema de investigación Sobre el desarrollo: Un proyecto único durante el curso para toda la clase Utilizando herramientas colaborativas (sourceforge) El profesor = un desarrollador más El desarrollo similar a la creación de software libre…muy libre

Elección del problema Un único lenguaje de desarrollo (Haskell, lenguaje funcional) La web semántica Campo muy reciente y que está de moda en Internet Línea de investigación del profesor Muchos problemas por resolver Mucha relación con la programación lógica La inclusión de reglas en lenguajes de web semántica equivale a incorporar un lenguaje de programación lógica Desarrollar herramientas para la web semántica en Haskell Problema abierto: no existe ninguna herramienta actualmente Un solo sistema desarrollado pero no activo Relacionado con interés de investigación del profesor

Metodología Un único equipo = Toda la clase (incluidos los profesores) 27 desarrolladores Exposición pública del proyecto Nombre: WESO (WEb Semántica Oviedo) Inclusión en almacen público de proyectos (Sourceforge) Página Web (http: //www. weso. sourceforge. net) Herramientas colaborativas de desarrollo Sourceforge Lista de correo, cvs, gestión de bugs, releases, etc. Canal IRC del proyecto Foro de discusión Pruebas unitarias (HUnit)

Source. Forge Plataforma más utilizada en desarrollo de software libre Más de 100. 000 proyectos y de 1 millón de usuarios

Grupos de trabajo El desarrollo se basó en grupos de trabajo auto-coordinados Objetivo = que los estudiantes aprendiesen a coordinarse Creación de actas de cada reunión Trabajos en periodos cortos Grupos creados por el profesor Se intentaron romper lazos de amistad previos al principio

Fases del Desarrollo (1) Identificación del problema Grupos de 4 ó 5 personas Componentes de cada grupo elegidos por el profesor Objetivo: mezclar a los estudiantes Cada grupo investigó una posible aplicación: EARL, RDF/RSS, FOAF, Open Directory, RDFCalendar y un grupo debía buscar “otras” Tiempo: 1 mes Exposición pública al resto de la clase de la investigación El profesor seleccionaría al ponente Votación sobre el tema más atractivo El desarrollo posterior sería por la línea elegida Se eligió FOAF y un tema propuesto por los alumnos NOTA: En esta fase, en las horas de prácticas fueron aprendiendo el lenguaje Haskell

Fases del Desarrollo (2) Primer prototipo Nuevo reparto en grupos intentando que no se repitan los miembros Se parte de un esqueleto de aplicación desarrollado por los profesores Consta de diversos módulos Cada grupo se encargará de un módulo Cada módulo contiene unas pruebas unitarias (HUnit) Objetivo: Obtener una primer release que haga algo Tiempo: 1 mes y medio (17 de diciembre, antes de navidad) Dicha versión sería publicada en Internet Motivación: exposición pública del código Solicitud del primer auto-informe de contribución al proyecto

Fases del Desarrollo (3) Corrección del prototipo Creación de nuevos grupos más reducidos (2 personas) Objetivo: Mayor control de la actividad intra-grupo Tareas más concretas: Mantenimiento de módulos Reparación de bugs Creación de ejemplos Banco de pruebas etc. Tiempo: 1 mes (Hasta mediados de Enero) Objetivo: Versión corregida del prototipo

Fases del Desarrollo (4) Ampliaciones Disminución de actividad durante la fase anterior Fechas: últimos 15 días de enero y principios de febrero Coincide con exámenes de muchas asignaturas Mayor estrés de los estudiantes Menos tiempo para que se coordinen Solicitud de segundo auto-informe de contribuciones Breve trabajo final individual Complemento al resto de contribuciones al proyecto Objetivo: distinguir mejores estudiantes

Evaluación de la asignatura Participación en el proyecto Participación en los diferentes grupos Implementación de soluciones Incorporación de mejoras al proyecto Otras colaboraciones: lista de correo, página web, etc. Auto-informes realizados por los estudiantes Indicarán cuál ha sido su contribución Se han solicitado 2 auto-informes El primer auto-informe sirvió para captar la evolución del proyecto Trabajo individual sobre el tema del proyecto

Evaluación del proceso Encuesta a los estudiantes Puntos positivos: El método es bueno, pero hay que mejorarlo Importante trabajar en proyecto real Les hubiese gustado dedicarle más tiempo Prefieren este método a uno más tradicional Aprendizaje de técnicas reales de software Pruebas unitarias, control de versiones, gestión de bugs, etc. Puntos negativos: Algunos se desmotivaron porque otros compañeros trabajaron mucho Falta de objetivos claros Excesivos cambios de grupos Poco tiempo para coordinarse

Conclusiones Método nuevo para los profesores ¿Qué aprendieron los estudiantes? Posiblemente, menos programación declarativa Pero más competencias transversales Trabajo en grupo, Desarrollo de software colaborativo, (control de versiones, módulos, etc. ), Gestión del tiempo, etc. Sobre el esfuerzo para el profesor… Mayor que con enseñanza tradicional…¡seguro! PERO es más divertido Mayor interacción con los estudiantes Se puede aprender de los estudiantes!!! Se puede investigar mientras se enseña OJO: Los estudiantes quedan con la sensación de que el profesor no conoce todas las respuestas ¿es éso malo? Diversas anécdotas…

Anécdotas Propuesta improvisada de un tema por parte de unos alumnos MACO: Mapa de titulaciones mediante web semántica Colaboración de un estudiante de la Universidad de Oxford Participación en la sala de Chat Hijo del desarrollador del Swish (el sistema anterior) Creación espontánea de líderes de grupo Problemática del manejo de grupos Roce entre 2 alumnos en una de las presentaciones 2 módulos debían comunicarse y tenían que ponerse de acuerdo en la interfaz Reciente artículo de unos estudiantes sobre la experiencia Enseñanza declarativa vs. Imperativa

Fin de la Presentación