Sobre mis prácticas de evaluación

Para hablar de mis prácticas de evaluación, primero debería contarles que soy docente en varias asignaturas, una de las cuales es obligatoria y las demás son electivas. Todas las asignaturas pertenecen al programa de las carreras de Licenciatura en Análisis de Sistemas e Ingeniería en Informática.
La evaluación en las asignaturas electivas en las cuales trabajo, es continua, clase a clase, el número de estudiantes es bajo y se trabaja mucho con tareas que dejamos en el campus de la Facultad (campus de FIUBA) en el tipo de evaluaciones "para llevarse a casa". Hacia el final de las asignaturas cada uno de los estudiantes tiene que preparar un proyecto (en uno de los casos consiste en elaborar un producto de software) en el cual vuelque, para resolver un problema cuyo tema cada uno de los estudiantes elige y que tienen que resolver utilizando conocimientos de la asignatura en particular y, en algún caso, integrando conocimientos de otras asignaturas anteriores de la misma área. Si recordamos la clasificación de Ebel (“Diseño y construcción de una prueba”, En: Fundamentos de la medición educacional. Buenos Aires, Guadalupe, 1977) por un lado estaría relacionada con una prueba de composición y por otro lado con una prueba de problemas, digamos que al ser el desarrollo de un proyecto, es una composición aplicada a la resolución de un problema. El problema no es presentado por los docentes, sino que es propuesto por el estudiante en base a sus propios intereses y realidades.
Nuestro objetivo en las asignaturas, que están relacionadas con la temática de modelización matemática, es que los estudiantes aprendan los conceptos de modelización, no sólo para resolver ejercicios de entrenamiento didáctico, sino para aplicarlos a problemas de la vida real. Patrick Noonan (“Course Projects & Project Courses. Adopting Best Practices from the Consulting” ALIO-Informs Buenos Aires 2010.) define un Proyecto como “perteneciente a los problemas de “mundo real” que por lo tanto tienen consecuencias reales, en el cual los clientes son agentes de decisión, con datos reales, frecuentemente deben ser resueltos apelando a un equipo de personas, y en los cuales es difícil encontrar la mejor solución (incluso en ocasiones no se puede llegar a una solución)”.
La propuesta del proyecto compromete a los estudiantes y hasta en un primer momento pareciera que los desorienta porque la propuesta del tema no surge del grupo docente sino de ellos mismos, de tal forma que salen de la llamada “zona de confort” y pasan a una posición activa, mucho más acorde con el tratamiento de un problema real como profesionales. Al comienzo de la cursada, muchos estudiantes parecen aliviados de que, en lugar de rendir un parcial, puedan aprobar la cursada haciendo un proyecto de desarrollo de software, sin embargo, cuando empieza a avanzar el tiempo, cerca de la fecha de presentación, se produce una deserción de entre el 20 y el 25% de los estudiantes, porque no llegan con los tiempos a preparar el proyecto y dejarlo en condiciones.
Al comenzar con esta modalidad buscábamos que el trabajo estuviera listo al finalizar la cursada, pero esto implicaba perderse uno de los momentos más ricos del curso; cuando en el último mes los estudiantes trabajan en calidad de usuarios con el producto final de cada uno de sus compañeros. Asimismo comenzamos aceptando grupos de dos estudiantes, pero la participación de ambos integrantes frecuentemente no era pareja y algunos proyectos presentados no ameritaban que en el desarrollo trabajaran dos personas. Por lo tanto, decidimos que los trabajos fueran individuales. Esto fue beneficioso para el desarrollo de los trabajos pero también hizo aumentar el porcentaje de deserción (y aumentó también nuestro trabajo porque tenemos muchos más trabajos por cuatrimestre). Sin embargo, seguimos prefiriendo esta modalidad.
En algún otro post les hablaré de la evaluación de la asignatura obligatoria, por ahora les dejo esto para compartir.