Aplicación de una Herramienta Web Síncrona en la Tutela de Prácticas de Programación Javier Macías, María P. Peinado, Juan D. Alarcón y María E. López Centro Asociado de la UNED en Guadalajara Guadalajara, 19003, España

RESUMEN La programación es una habilidad clave que deben dominar todos los alumnos de informática. Sin embargo, no es fácil ni su enseñanza ni su aprendizaje y requiere dedicación y esfuerzo continuado por parte de alumnos y profesores, en particular durante los primeros meses para así asentar buenos hábitos de programación. Para mejorar este proceso, especialmente en educación a distancia, se presenta la experiencia desarrollada con una herramienta web síncrona que se ha aplicado en la tutela de prácticas de programación, resaltando los puntos fuertes y débiles, la aplicabilidad en otros entornos y las posibilidades de mejora y futuro.

es necesario, pero no suficiente [4]. Un programa debe seguir un estilo adecuado y coherente, estar suficientemente comentado, usar las estructuras de datos y de control más apropiadas, etc. Un código de poca calidad suele presentar carencias respecto a la robustez y/o la eficiencia, es muy complicado de depurar, poco mantenible y propenso a errores de difícil localización y resolución. Por ello es preciso que los alumnos adquieran buenas prácticas de programación y desde el primer momento, ya que luego los malos hábitos son difíciles de eliminar.

Palabras Claves: Herramientas Web, Videoconferencia, Pizarra Virtual, Tutela de Prácticas, Enseñanza de la Programación, Educación a Distancia.

Por suerte, importantes voces como IEEE Computer Society y ACM apuntan la necesidad de incrementar el cuidado y la calidad en la enseñanza de la programación, incluyendo explícitamente la concienciación de los alumnos en problemas de seguridad dada la importancia de estos errores, de forma que presten especial atención en no crear agujeros de seguridad en los programas [1].

1. INTRODUCCIÓN

2. LA ENSEÑANZA DE LA PROGRAMACIÓN

Uno de los objetivos básicos que debe cubrir el proyecto docente de las carreras de informática es la enseñanza de la programación, dado que ésta es una habilidad clave que deben dominar todos los alumnos de informática [3]. Sin embargo, la programación es difícil de enseñar y requiere considerable tiempo y atención durante toda la carrera [3], tanto a alumnos como a profesores.

Como ya se ha dicho, la tarea de enseñar programación no es sencilla. De hecho, ni siquiera existe consenso en cuál es la mejor secuenciación: si bien es bastante común empezar a enseñar programación desde el primer momento (aún así no hay acuerdo en si es mejor comenzar por el paradigma imperativo, el orientado a objetos o el funcional), hay otras posibilidades como empezar por enfoques basados más en el hardware, en una visión amplia de la disciplina o en algorítmica antes que en la programación propiamente dicha [3].

Por otro lado, la fase de construcción, en particular la actividad de generación de código, ha sido descuidada en favor de otras fases del desarrollo del software [5] aduciendo que es un proceso relativamente mecánico y escasamente mejorable. Pero si tenemos en cuenta que la generación de código significa el 65% del esfuerzo en proyectos pequeños y el 50% en proyectos medios, y que los errores en esta fase suponen el 75% del total en los proyectos pequeños y entre el 50 y el 75% en los proyectos medianos y grandes, estamos ante una actividad que presenta claras oportunidades de mejora [5]. Es posible que esta dejadez haya sido debida a que los errores en las fases previas de análisis y diseño son mucho más costosos de solucionar. Pero que un error sea poco costoso de arreglar no significa que sea poco importante: algunos de los fallos más caros en el software han sido debidos a “pequeños” errores en la programación [5]. Más allá de la corrección, en el sentido de que un programa se comporte tal y como indican las especificaciones, la calidad del programa es una cuestión crucial. Que un programa sea correcto

Sea cual fuere el momento en que se introduce la programación, el primer paradigma elegido o incluso el lenguaje concreto a utilizar, lo que es común en todos los métodos de enseñanza de la programación es la realización de prácticas, imprescindibles para adquirir las competencias profesionales que precisará el futuro ingeniero. Existen variantes en la forma de organizar las prácticas: dentro de la propia asignatura de programación (tendrá, por tanto, una parte teórica y otra práctica, frecuentemente en el laboratorio), como asignatura de laboratorio específica o incluso prácticas autónomas como ocurre a veces en educación a distancia. En la realización de las prácticas, presenciales o a distancia, es posible que se presenten múltiples dificultades, como por ejemplo: irregular asistencia de los alumnos a las prácticas o asistencia a las prácticas pero no a las clases teóricas, laboratorios masificados, diferencias en los conocimientos iniciales de los alumnos y el ritmo de aprendizaje, profesores

distintos para teoría y práctica con distintas normativas o estilos de codificación, profesores más preocupados en que la práctica funcione o la interfaz de usuario que por la calidad del código, alumnos que escriben código sin pensar ni seguir un método, alumnos que compilan sin repasar y, cuando detectan errores en la compilación o en las pruebas, parchean el programa sin buscar las razones del fallo, etc. La solución a todos estos problemas no es sencilla. Se podría pensar que, simplemente con facilitar a los alumnos un documento detallando las buenas prácticas en programación, se adelantaría mucho. Sin embargo, no basta con que los alumnos tengan la información de cómo hacer las cosas bien; para un aprendizaje de calidad necesitan ser enseñados utilizando los fallos y defectos de su propio código. Como muestra de que una documentación no es suficiente, se presenta a continuación la experiencia negativa a este respecto de uno de los autores mientras impartía docencia en la Universidad de Alcalá. En el curso 2006/07 se proporcionó a los alumnos de “Metodología de la Programación” y al coordinador de los laboratorios de programación, al igual que en cursos anteriores, un documento denominado “Directrices de legibilidad y mantenibilidad”. Como se observó que los alumnos hacían poco caso de las directrices, en el curso 2007/08 se aplicó al documento una profunda transformación, añadiendo una introducción en la que se indicaba la utilidad y necesidad de seguir dichas directrices, se amplió y se mejoró su redacción (añadiendo además en muchas de ellas un ejemplo de lo que estaba bien y lo que estaba mal para facilitar su comprensión), y se adjuntó también un apartado donde se recordaba el método a seguir en la construcción de programas (que incluía la recomendación de leer el conocido documento “Cómo NO realizar una práctica de programación” [2]) y un apéndice donde se explicaba el uso correcto del punto y coma (;) en Pascal, que era el lenguaje usado en teoría y laboratorio. Para fomentar su lectura, cada semana los alumnos debían leer diez de las directrices y en clase se resolverían las dudas que les hubieran surgido. Los resultados: sólo un número mínimo de alumnos reconoció haberlas leído y la mayoría seguía cometiendo los mismos errores. Y ello a pesar de que se insistió reiteradamente en la importancia de dichas directrices y que su no seguimiento podría tener consecuencias muy negativas en su aprendizaje así como en la nota del examen.

3. PRESENTACIÓN DE LA EXPERIENCIA Contexto La experiencia aquí presentada se ha llevado a cabo en el curso 2008/09, en el Centro Asociado de la Universidad Nacional de Educación a Distancia (UNED) en Guadalajara, en la asignatura “Programación I”, del primer cuatrimestre del primer curso, que es común a las carreras Ingeniería Técnica en Informática de Gestión e Ingeniería Técnica en Informática de Sistemas de la UNED. El lenguaje de programación usado actualmente es Modula-2, aunque en un futuro próximo podría cambiar. Al tratarse de una enseñanza a distancia, la dificultad en el aprendizaje de la programación se acentúa. Por ejemplo, si bien los alumnos de “Programación I” disponen al finalizar cada unidad didáctica de una serie de prácticas y pruebas de evaluación a distancia voluntarias que sería importante que realizaran, no suelen hacerlas, posiblemente debido a que generalmente no son corregidas ni por su profesor-tutor del

centro asociado ni por los profesores de la Sede Central. Para intentar mejorar la situación, desde el curso 2001/02 el equipo docente añadió nuevas prácticas de programación con las siguientes características: •

Tres prácticas, una por cada unidad didáctica.

•

Un libro de prácticas con enunciados y guías para realizar las prácticas 1 y 2. Para facilitar la tarea al alumno, en los primeros capítulos presenta nociones básicas del sistema operativo (para los alumnos con menos conocimientos previos), cómo instalar el entorno de desarrollo para las prácticas y su uso, cómo hacer su primer programa, etc.

•

Un CD, incluido en el libro de prácticas, donde se encuentra el entorno de programación y aplicaciones correctoras de las prácticas 1 y 2. Estas aplicaciones comprueban en varios casos representativos que las salidas de los programas de los alumnos se ajustan a lo pedido en el enunciado (son, por tanto, pruebas de “caja negra”). Asimismo, proporcionan unas claves que sirven para saber que el alumno ha superado dichas prácticas.

•

Una práctica 3, distinta cada año y cuyo enunciado se proporciona en la Web de la asignatura, que precisa para su confección conocimientos de todo el temario, que tradicionalmente fomenta la reutilización de código de la práctica 2 y que es corregida por el profesor-tutor del alumno. Cada profesor-tutor es libre de decidir cómo corregir la práctica y si el alumno recibirá o no realimentación, aparte de su nota, de la corrección.

•

Para animar a los alumnos a hacer estas prácticas, aquellos que las superan con éxito tienen varias ventajas en el examen sobre aquellos que no las han hecho (se permiten más fallos en la parte eliminatoria de los test y se incrementa hasta un punto la nota final dependiendo de la calificación de la práctica 3).

Para fomentar en lo posible la realización de las prácticas por parte de los alumnos y conseguir el máximo aprendizaje posible, en las tutorías de “Programación I” del Centro Asociado de Guadalajara se han llevado a cabo durante estos años las siguientes acciones: •

Recalcar la importancia de realizar las prácticas a los alumnos tanto para aprender como para aprobar, animándoles a ello en las tutorías presenciales y en el foro del curso virtual (WebCT [8]) de la asignatura.

•

La mayoría de los cursos académicos se ha intentado dedicar al menos una tutoría a la realización de un laboratorio de prácticas supervisado por el tutor. Esto permite controlar la forma en que los alumnos afrontan la construcción del código y, en el caso de los alumnos con más problemas, aprenden a instalar el entorno de compilación y a probar el programa ejemplo.

•

Se han facilitado enunciados de otros ejercicios en varios de los temas, además de los existentes en el libro de teoría, para que los alumnos tengan más ejemplos con los que practicar la programación.

•

Se ha dedicado tiempo en las tutorías presenciales para explicar las partes más difíciles de las prácticas 1 y 2. Asimismo, se han incluido mensajes al respecto en el foro.

•

Se han resuelto las dudas surgidas en las prácticas, tanto presencialmente como en el foro y por correo, aunque hay que decir que los alumnos suelen recurrir poco al tutor.

•

Tras la entrega y corrección de la práctica 3 por parte del tutor, el alumno debe realizar la defensa de la misma presencialmente. Con esto se pretendía comprobar que el alumno era el autor, así como detallarle y explicarle los fallos principales que había cometido.

Situación Previa Con el transcurso de los años se ha comprobado que los alumnos que hacen las prácticas, aunque se desenvuelven generalmente mejor que quienes no las han hecho, presentan la práctica 3 con una codificación de una calidad bastante mejorable. Dado que la corrección de esta práctica se realiza justo antes de los exámenes, el alumno tenía poco tiempo y oportunidades para perfeccionar sus hábitos de programación. Era necesario, por tanto, buscar soluciones. Una primera idea consistía en que los autocorrectores de las prácticas 1 y 2 no sólo comprobaran que los programas de los alumnos hacen lo que se les pide, sino que el código tuviera una buena calidad. Aunque existen estudios y herramientas al respecto, por ejemplo [7], es muy complicado y no cubriría todos los casos. Otra posibilidad sería aumentar en las tutorías el número de horas de laboratorio a costa de horas de teoría, pero esto supondría que los alumnos se tendrían que preparar la mayoría de la teoría por sí mismos y en general no es lo que desean aquellos que asisten a las mismas. Además, el porcentaje de los alumnos que acuden a tutorías es bajo (un 20% de los matriculados aproximadamente), por lo que su alcance sería bastante restringido. Se decidió, como acción más sencilla de realizar y que era apta tanto para alumnos que asistían a las tutorías presenciales como aquellos que no, el plantear por cada tema un número suficiente de ejercicios para que fueran realizados por los alumnos y enviaran sus soluciones antes de una fecha dada. El tutor revisaría aleatoriamente algunos programas e informaría de los fallos más frecuentes y/o pondría a disposición de todos los alumnos la corrección del programa entregado por algún compañero.

para su posterior visionado. Destacar que aunque desde el año 2000/01 existía ya la posibilidad de usar en la UNED la pizarra virtual de WebCT (pero sin videoconferencia, aunque sí con chat), ni las funcionalidades que proporcionaba ni la velocidad de Internet de la mayoría de los usuarios en aquel momento permitieron realizar un uso extendido de la misma. Dadas sus funcionalidades, se estimó que la “Conferencia online” podría ser de gran utilidad en la tutela de prácticas para alumnos a distancia y se decidió hacer inmediatamente en el Centro un piloto a fin de valorar sus bondades y descubrir inconvenientes si los hubiera.

4. DESCRIPCIÓN DE LA EXPERIENCIA Previamente a la realización en sí de la experiencia y aunque ya habíamos recibido formación en el uso de la herramienta, los autores nos conectamos en varias ocasiones entre nosotros para aumentar nuestra destreza en el manejo de la misma y simular las interacciones que tendríamos con los alumnos. Esto nos sirvió, por ejemplo, para aprender a configurar correctamente los volúmenes del micrófono personal y del sonido de los participantes, descartar la posibilidad de usar simultáneamente el micrófono y altavoces internos de los equipos que los tienen (se producían ecos muy desagradables) o el formato que se debía dar al texto del código fuente para que al subirlo a la herramienta se visualizara con un tamaño de letra adecuado para su lectura. Una vez familiarizados con la herramienta, se contactó con tres alumnos de entre los que habían entregado alguno de los ejercicios propuestos por el tutor para ofrecerles la posibilidad de corrección de los mismos usando la nueva herramienta. La respuesta fue muy positiva ya que todos ellos la aceptaron gustosos. Se planificaron los momentos en los que realizar las tutorías con la nueva herramienta, buscando horas disponibles para profesor y alumno (incluyendo noches y fines de semana si venían bien a ambas partes) y se llevaron a cabo las mismas sin incidentes que reseñar (excepto en uno de los casos, que el sonido era muy pobre y se decidió usar el teléfono para la comunicación oral).

Sin embargo, enseguida se vio que esta acción no funcionaba. La primera semana sólo unos pocos alumnos mandaron soluciones y la segunda semana tan solo uno de ellos. Aunque se decidió seguir proponiendo los ejercicios que se estimaron necesarios, tras la segunda semana no se volvieron a poner a disposición de los alumnos las correcciones, ya que si no intentan por ellos mismos los ejercicios sirve de poco que vean las soluciones (además, ya disponen de ejercicios solucionados en el libro de teoría). Quizás una de las razones de este fracaso resida en que cada alumno tiene su ritmo de estudio, cuestión ésta mucho más acentuada en nuestro caso dado el perfil de nuestros estudiantes (disponen de poco tiempo porque suelen trabajar y/o tener cargas familiares).

Al terminar la sesión, que aproximadamente duraba media hora dependiendo, entre otros factores, de los errores que tuviera su código y las preguntas que el alumno realizara, se le pedía al alumno su opinión. Dado que la experiencia fue muy positiva (todos manifestaron estar satisfechos o muy satisfechos), se ofertó la posibilidad de la conferencia on-line a todos los alumnos. En especial, se solicitó por primera vez que todos los alumnos remitieran al tutor las prácticas voluntarias según las iban terminando y eran validadas por el programa autocorrector (o si se quedaban atascados en alguna parte) para ser revisadas mediante la conferencia on-line y así poder corregir sus fallos prontamente.

Aplicación de la Herramienta web Desde inicios del curso 2008/09 la UNED ha puesto a disposición de todo su profesorado una herramienta denominada “Conferencia on-line” (Figura 1). Esta herramienta web integra una pizarra virtual (en la cual se puede escribir y dibujar así como subir documentos y descargar lo escrito en ella), una videoconferencia y un chat, y es posible conectar a ella desde ordenadores con conexión a Internet y desde varios modelos de pizarras digitales. Asimismo, permite la grabación de sesiones

Desarrollo de las sesiones Previamente al inicio de la sesión y si había tiempo suficiente, el tutor repasaba el código a corregir, de forma que se pudiera ir más rápido y con una visión más general al empezar la conferencia. Después, al texto del código fuente se le aplicaba un formato adecuado al visualizador (aumentar el tamaño de la letra, cambiar a negrita y poner en orientación apaisada) y era convertido a PDF, que es el formato preferido de esta herramienta concreta. Todo ello llevaba un par de minutos a lo

Figura 1. Ejemplo de uso de la herramienta (conferencia on-line)

sumo. Después, el tutor entraba en la página web donde reside la herramienta, se identificaba, creaba una sala privada para conectar con el alumno, entraba en ella y cargaba el programa del alumno. Estos pasos se solían hacer unos minutos antes de la hora concertada para que estuviera todo dispuesto desde el primer instante en que el alumno se conectaba. Llegada la hora, generalmente se contactaba por teléfono con el alumno para dirigir sus pasos la primera vez que usaba la herramienta, aunque la entrada a la misma es muy sencilla. Además, se le daba unas pequeñas pautas para el manejo de la herramienta y se le explicaba cómo se desarrollaría la sesión. Una vez el alumno había entrado y ajustado el sonido y la disposición de los controles en la pantalla si era preciso, se pasaba a revisar la práctica. El tutor iba repasando el código dialogando con el alumno, actuando de guía e intentando que fuera el propio alumno quien se percatara de sus errores y de cómo solucionarlos. Si durante la sesión se detectaba que el alumno tenía problemas en alguna cuestión concreta, dependiendo de lo que se creyera más oportuno se aparcaba por un momento el código y se solucionaba la duda o se dejaba para el final. En cualquier caso, una vez terminada la corrección se preguntaba al alumno si tenía alguna cuestión más relativa a su programa o a la asignatura. Era bastante común que aprovechara la oportunidad para preguntar alguna duda, no sólo del temario

sino también de tipo administrativo (por ejemplo, si el examen de febrero “corre convocatoria”).

5. EVALUACIÓN DE LA EXPERIENCIA El número de alumnos participantes en las conferencias on-line fue de siete, con los que se realizaron un total de 12 sesiones repartidas de la siguiente forma: dos alumnos realizaron tres sesiones, otro dos, y el resto una. Dado que se trataba de una experiencia piloto y que el número total de alumnos matriculados en la asignatura en el Centro Asociado es de aproximadamente 30, de los cuales un porcentaje significativo (estimado entre un 40% y un 70%) abandona la asignatura antes de terminar el cuatrimestre, se puede considerar suficientemente representativa. Opinión de los alumnos Para conocer mejor la opinión de los alumnos, se les envió una pequeña encuesta a los siete con los que se mantuvo una conferencia on-line. A la pregunta de si les había resultado fácil la entrada a la herramienta, todos ellos respondieron afirmativamente, al igual

que a las preguntas de si les había resultado fácil el manejo de la misma y de si recomendarían su uso a los compañeros. Para la pregunta de la calidad del sonido, valorada de 0 a 10, las respuestas variaron en el entorno de 5 a 10, lo cual coincide con la apreciación de los tutores (en algunos casos el sonido fue algo pobre, incluyendo algún corte en la voz, y en otros fue bueno o muy bueno). Asimismo, se les pidió que valoraran de 0 a 10 la naturalidad de la interacción de la conferencia on-line. La media obtenida fue bastante alta, de 8.4, siendo las puntuaciones más bajas las de aquellos alumnos que habían calificado como menor la calidad del sonido. Pensando en posibilidades para ampliar el uso de la herramienta, se les plantearon las siguientes tres preguntas: si permitirían que las sesiones realizadas se grabaran para que otros alumnos pudieran aprender de su corrección; si les gustaría que pudieran usar la herramienta entre compañeros para ayudarse puntualmente; y si les parecería adecuado si uno o más alumnos fueran los encargados de corregir su práctica de forma on-line, participando el profesor de moderador. La respuesta a todas ellas fue un sí rotundo por parte de los siete alumnos. Por último se les preguntó por las ventajas y desventajas de usar la herramienta para correcciones a distancia. Todos describieron una o más ventajas en el uso de la herramienta, como por ejemplo la sincronicidad de la comunicación que permitía aclarar dudas al instante, el que ésta se pudiera hacer desde su propia casa y en horarios concertados y que además de corregir su práctica se le pudieran responder otras dudas que plantearan. Como ejemplo, se reproduce una de las respuestas a las ventajas del uso de la herramienta: “Todas. La interacción entre profesor y alumno permite la corrección de los ejercicios y preguntas al instante, es sencillamente genial”. Respecto a las desventajas, varios afirmaron no ver ninguna. Entre los que vieron alguna, se comentó la necesidad de buscar horarios apropiados con los del profesor, el tener que disponer de banda ancha y que debería facilitarse grabar la sesión para luego poder visualizarla si fuera necesario (aunque esta opción la soporta la herramienta, no llego a explicárseles cómo llevarla a cabo; por otro lado, actualmente estas grabaciones se guardan en un servidor remoto y todavía no hay una política firmemente establecida respecto a su acceso y tiempo de permanencia). Opinión de los tutores En nuestra opinión, la experiencia piloto ha resultado muy positiva. En primer lugar y como ventajas genéricas: •

•

Ha aumentado la cercanía del tutor al alumno, algo muy importante en educación a distancia, en especial para aquellos alumnos que no pueden asistir a las tutorías. Si además el tutor dispone de webcam (mejor si también dispone de ella el alumno), la sensación de cercanía es incluso más intensa. La herramienta les ha resultado motivadora y les ha permitido experimentar con las nuevas tecnologías: en varios casos, ha sido la primera oportunidad que ha tenido el alumno para usar la webcam que venía con su ordenador (como anécdota, comentar que un alumno supo que su ordenador portátil traía webcam cuando vio que su imagen aparecía en la conferencia on-line).

•

Les ha permitido avanzar más rápido en su aprendizaje, gracias a que podían resolver sus dudas en el momento.

•

En general, es más rápido explicar algo oralmente que escribirlo. Además, se puede pedir realimentación al alumno al instante (¿lo has entendido? o, visto lo que te he contado, ¿cómo resolverías este caso?, etc.) o preguntarnos él directamente si se pierde durante la explicación, con lo que se consigue una individualización de la enseñanza adaptándose a las necesidades particulares de cada alumno.

Centrándonos en la programación, la herramienta permitió detectar y corregir gran número de deficiencias en los programas de los alumnos (a pesar de que éstos habían pasado el corrector automático), entre ellas: •

Ausencia de comentarios de cabecera, de subprograma, de sección, etc.

•

Disposición del código inadecuada (mal tabulado, líneas muy largas, ausencia de líneas en blanco para separar secciones, etc.).

•

Nombres de identificadores poco significativos.

•

Uso de constantes literales en vez de constantes con nombre.

•

Uso de estructuras de control inadecuadas (por ejemplo, WHILE cuando procedía FOR o REPEAT, IF-ELSE cuando procedía IF-ELSIF, IF-ELSIF cuando procedía CASE, etc.).

•

Defectuosa modularización del código.

•

Uso de tipos de datos poco apropiados (por ejemplo, uso de enteros cuando procedía enumerados).

•

Redundancias en expresiones booleanas (por ejemplo, IF EsBisiesto(anno) = TRUE THEN).

Es de destacar que no solamente se corregía sin más el código presentado, sino que a veces se preguntaba por el proceso que habían seguido para realizarlo, en particular cuando se detectaba algo extraño en el programa, o se les pedía que indicaran cómo harían alguna corrección o mejora sobre el código presentado. Respecto a la evaluación de los resultados, es difícil generalizar dado que tan sólo se tuvo más de una conferencia con tres de los alumnos, pero se observó que los errores no los volvían a cometer o al menos lo hacían con menor frecuencia. Por otro lado y aunque no es estadísticamente significativo por la escasa cantidad de alumnos de la experiencia, destacar que los únicos dos alumnos que han aprobado la asignatura en la convocatoria de febrero son precisamente dos de los tres dichos anteriormente. Pasando ahora a aspectos relativos a la herramienta, decir que su uso es bastante intuitivo. Un pequeño problema, en especial para el profesor dado que dedica más tiempo a ella, lo constituye el dispositivo de entrada para dibujar en la pizarra. El ratón es el más común pero no es demasiado cómodo ni preciso para esta tarea. Por otro lado, la tableta digitalizadora, aunque más precisa, en general debe adquirirse y requiere de un periodo de aprendizaje para un uso correcto. Especialmente cómodo y natural resultó el uso de un tabletPC, gracias a su pantalla táctil, pero estos equipos son bastante caros. En cualquier caso, el uso del ratón no supuso un problema insalvable al menos para esta asignatura (sí lo puede llegar a ser en asignaturas que precisen escribir símbolos especiales, como sumatorios, exponentes, etc.,

dado que aunque la herramienta dispone de un editor para escribir texto en la pizarra, éste es muy simple).

si consigue solucionar por sí mismo la duda que tenía mientras esperaba a que se le atendiera.

Otro pequeño inconveniente está relacionado con la necesitad de disponer de auriculares para evitar ecos, tal y como se ha comentado anteriormente. Muchos alumnos (y tutores) suelen utilizar altavoces y pueden no tener a mano unos auriculares o incluso carecer de ellos, a pesar de que se trata de un dispositivo muy barato.

Por otro lado, se podría permitir en ciertos casos (enfermedad, viaje, etc.) o incluso a discreción del alumno, que su asistencia fuera virtual usando la herramienta. Habría una parte común tipo videoconferencia si, por ejemplo, al inicio del laboratorio el profesor explica la práctica o en algún momento posterior decide comentar algún fallo muy común que está viendo en los alumnos, y el resto del tiempo se accedería de forma individual siguiendo un turno.

Por otro lado, la herramienta utilizada podría mejorarse, por ejemplo añadiendo la posibilidad de deshacer, un puntero compartido, zoom, ajuste automático de los volúmenes de micrófono y auriculares, etc. En cualquier caso, se estima conveniente que se mantenga como principio la simplicidad, por lo que las nuevas funcionalidades deberían añadir con mesura. De gran utilidad para los profesores sería integrar la ficha del alumno con la herramienta, de forma que se pudiera obtener fácilmente información de interés, como su experiencia previa, si se ha tenido contactos anteriores en línea, si asiste a las tutorías presenciales, etc. y permitiera apuntar datos que pudieran ser de ayuda para el seguimiento del aprendizaje del alumno (por ejemplo, comprobar la siguiente vez si usa ya constantes con nombre si la vez anterior había fallado en esto). Destacar, por último, el problema del tiempo de dedicación que esto supone y cómo se remuneraría si se utilizan, como ocurrió en nuestro caso, horas extra no pagadas para no disminuir las horas de las tutorías presenciales. En cualquier caso, se tiene la ventaja de que la herramienta podría llevar el registro de horas dedicadas a tutelar a los alumnos si se decidiera pagar por este concepto.

6. USO EN ENSEÑANZA PRESENCIAL En primer lugar, destacar que la enseñanza presencial ha ido incorporando progresivamente herramientas que previamente se han utilizado con éxito en la enseñanza a distancia, por lo que no es descabellado suponer que con esta herramienta pueda suceder lo mismo. Centrándonos en las prácticas de programación, un ejemplo de aplicación de la herramienta en la enseñanza presencial sería en las tutorías. No es infrecuente que los horarios de tutorías queden lejos de los horarios en que el alumno tiene las clases o coincidan con horarios de clase del alumno (el profesor aprovecha los huecos en sus horarios para poner las tutorías y no tener que desplazarse en otros momentos ex profeso a la Universidad). Si se dispusiera de esta herramienta, el alumno podría tener la tutoría desde su casa si el horario no le es favorable. Es más, incluso el profesor podría estar interesado en poner alguna tutoría en un horario beneficioso para el alumno si se le permitiera realizarla desde su casa usando la herramienta. Se podría ir más lejos, aplicándola también a los laboratorios de prácticas. Aunque profesor y alumno estuvieran presentes en el laboratorio, el uso de esta herramienta facilita que los dos se encuentren cómodamente sentados y en frente del código, sin tener que desplazarse por los a veces abarrotados y estrechos pasillos que quedan entre los pupitres de los laboratorios (ya existen soluciones parecidas, como ClassPerfect [6]). Además, la herramienta podría gestionar la petición de turno y el alumno saber cuándo le va a tocar e incluso darse de baja para preguntar

7. CONCLUSIONES La experiencia piloto llevada a cabo indica que una herramienta como la aquí presentada tiene un gran potencial en la tutela de prácticas en la educación a distancia y posibilidades de ser aplicable en la educación presencial. Su uso resulta un complemento ideal, rellenando el hueco existente entre las clases y/o laboratorios presenciales y las herramientas de comunicación asíncronas en la atención del alumno, por lo que es muy probable que su uso se generalice en años venideros y sea incluso demandada por los alumnos. Quedan cuestiones que resolver, como la dedicación del profesor, las nuevas funciones que este tipo de herramientas le pueden suponer y la dotación de dispositivos adecuados para facilitar el trabajo.

8. REFERENCIAS [1] Association for Computer Machinery / IEEE Computer Science, “Computer Science Curriculum 2008: An Interim Revision of CS 2001”. [2] A. Cernuda, “Cómo NO hacer unas prácticas de programación”, Actas de las VIII Jornadas de Enseñanza Universitaria de la Informática (Jenui 2002). [3] IEEE Computer Society / Association for Computer Machinery, “Computing Curricula 2001”. [4] M. A.. Jackson, “Principles of Program Design”, Academic Press, 1975. [5] S. McConnell, “Code Complete, Second Edition”, Microsoft Press, 2004. [6] MiniCom Advanced Systems, “ClassPerfect”. [7] T. Schorsch, “CAP: an automated self-assessment tool to check Pascal programs for syntax, logic and style errors”, ACM SIGCSE Bulletin, Vol. 27, No. 1, marzo 1995, pp. 168-172. [8] Web Course Tools (WebCT). En el año 2006, WebCT fue adquirido por Blackboard (http://www.blackboard.com).