Actas XVIII JENUI 2012, Ciudad Real, 10-13 de julio 2012I.S.B.N. 10: 84-615-7157-6 | I.S.B.N. 13:978-84-615-7157-4Páginas 129-136

Una aproximación a la evaluación de laboratorio en programaciónde sistemas

C. Glez-Morcillo, F. Jurado , D. VallejoDepartamento de Tecnologías y Sistemas de Información

Universidad de Castilla-La ManchaPaseo de la Universidad, 4

13071 Ciudad Real{Carlos.Gonzalez, Francisco.Jurado, David.Vallejo}@uclm.es

Resumen

Tras la implantación del proceso de Bolonia en Es-paña, los nuevos planes de estudio asociados a lastitulaciones de Informática cuentan con asignaturasrelacionadas con la programación de sistemas (ej.Sistemas Operativos). La adquisición de determi-nadas competencias prácticas, específicas de dichasasignaturas, resultan esenciales para que el estudi-ante sea capaz de asimilar y manejar los conceptosfundamentales asociados a las mismas.

Los mecanismos de evaluación y calificaciónclásicos pueden plantean ciertas deficiencias a la ho-ra de validar la correcta adquisición de dichas com-petencias, especialmente en la parte vinculada a losaspectos prácticos. En este contexto, el presente tra-bajo describe una aproximación para la realizaciónde pruebas prácticas evaluables en el laboratorio, asícomo una descripción sobre la metodología emplea-da en la construcción de dichas pruebas.

La exposición y discusión de los resultados,obtenidos como consecuencia de su aplicación enlos últimos tres años en una asignatura obligato-ria vinculada al estudio de los Sistemas Operativosen Ingeniería en Informática, ha permitido obtenerconclusiones que contribuyen a afianzar la adquisi-ción de competencias por parte del estudiante.

Summary

After the implantation of the Bologne Process inSpain, the new undergraduate studies related toComputer Science integrate courses that cover Oper-ating Systems, Distributed Systems and ConcurrentProgramming. Acquiring and developing the specif-ic practical competences of these subjects is essen-tial so that the students are able to understand andapply the basic concepts.

Classical evaluation and grade methods may su-

ffer from some limitations when validating the ade-quate acquisition of the previously mentioned com-petences, specially those related to the practical as-pects. Within this context, this work discusses theemployed approach to carry out the practical asses-ment of the students in the laboratory and describesthe adopted methodology.

The obteined results, after having carried out thisapproach during the last three years in a requiredcourse of Operating Systems, show how this appro-ach has contributed to guarantee the acquisition ofessential competences on behalf of the students.

Palabras clave

Sistemas Operativos; Evaluación del aprendizaje;TIC en el proceso de enseñanza-aprendizaje.

1. Introducción

Los Sistemas Operativos resultan un componenteclave en cualquier sistema de cómputo. Es por estoque las titulaciones asociadas con estudios de Infor-mática deben garantizar que los estudiantes adquier-an aquellas competencias que les permitan no só-lo manipularlos, sino entender tanto sus mecanis-mos internos de funcionamiento como el diseño eimplementación de los mismos. Es más, muchas delas cuestiones abordadas en los Sistemas Operativostienen una amplia aplicación en otros campos de laInformática, como son la programación concurrentey distribuida, el diseño e implementación de algo-ritmos, el desarrollo de nuevos dispositivos de in-teracción, la construcción de entornos virtuales, laseguridad informática, etc. [1][2].

Las metodologías de enseñanza/aprendizajeusualmente empleadas para permitir a los estudi-antes adquirir los conceptos teóricos y desarrollarlas habilidades prácticas asociadas con estas com-

130 Evaluación del aprendizaje

petencias incluyen sesiones de laboratorio queposibiliten a los estudiantes experimentar conSistemas Operativos [1][2]. Es decir, emplean elmétodo de Aprendizaje Basado en Problemas [6] afin de promover el aprendizaje activo centrado enel estudiante, combinando actividades teóricas y delaboratorio [5][7][9].

Por su parte, el Espacio Europeo de EducaciónSuperior, con la introducción de los nuevos Estu-dios de Grado bajo las directrices del Tratado deBolonia1, promueve el uso de metodologías educa-tivas y técnicas de evaluación activas, potenciandoel empleo de mecanismos de calificación y certifi-cación de habilidades y competencias que eliminenlos exámenes finales como única fuente de evalu-ación del estudiante.

Por tanto, evaluar si los estudiantes son capacesde analizar, diseñar y construir aplicaciones de sis-temas de forma robusta, segura y eficiente, resultauna tarea fundamental en el proceso de enseñanzade las asignaturas asociadas con estas competencias.

Del mismo modo, dado que el objetivo decualquier metodología de enseñanza/aprendizaje espermitir a los estudiantes alcanzar niveles cognitivosde pensamiento altos, los mecanismos de evaluacióndeben tener en cuenta criterios que posibiliten laevaluación de dichos niveles cognitivos [3][4].

En este contexto, el presente trabajo describe unaaproximación para la realización de pruebas prác-ticas evaluables en el laboratorio llevada a cabo enla Escuela Superior de Informática de la Universi-dad de Castilla-La Mancha, exponiendo y analizan-do los datos recopilados de su aplicación durante losúltimos tres años en una asignatura obligatoria vin-culada al estudio de los Sistemas Operativos en In-geniería en Informática.

El resto del documento está estructurado de lasiguiente forma. La sección 2 describe el contextoen el que se ha aplicado la metodología propuesta,haciendo especial hincapié en los procesos de eval-uación y de implantación. A continuación, la sec-ción 3 expone, desde un punto de vista general, lasprimeras conclusiones relativas a la aplicación delenfoque discutido en este trabajo en términos de re-sultados finales en la evaluación de los estudiantes.La sección 4 discute en profundidad estos resulta-dos, prestando especial atención a su evolución du-

1ec.europa.eu/education/policies/educ/bologna/bologna.pdf

rante los cursos académicos en los que se ha aplica-do. Finalmente, en la sección 5 se concluye el traba-jo realizando una reflexión general sobre el enfoqueplanteado.

2. Descripción del método propuesto

En esta sección se comenzará con una descripción delas características del curso y los estudiantes sobrelos que se ha aplicado a fin de mostrar la problemáti-ca a abordar, para pasar a continuación a adentrarnosen describir el método de evaluación propuesto y elmodo en que ha sido implantado.

2.1. Curso y estudiantes

La propuesta que se describe en esta contribución hasido aplicada a la asignatura de Ampliación de Sis-temas Operativos de la Universidad de Castilla-LaMancha. Esta es una asignatura de tercer curso deIngeniería Informática e Ingeniería Técnica en In-formática de Sistemas. Antes de cursarla, los estudi-antes deben haber adquirido competencias asociadasa programación, algoritmos, estructuras de datos, yconocimientos previos sobre el funcionamiento, es-tructura y diseño de Sistemas Operativos.

En esta asignatura debe garantizarse la adquisi-ción de determinadas competencias prácticas. Así, elestudiante debe adquirir competencias específicas delas características, funcionalidades y estructuras delos Sistemas Operativos, destacando aspectos fun-damentales de la gestión de procesos de un núcleo,desarrollo de programas multiproceso empleando unlenguaje de programación de sistemas, manejo deherramientas de desarrollo de compilación, enlacey depuración de aplicaciones de sistemas y diseñoe implementación de aplicaciones que utilicen losmecanismos de gestión de concurrencia que propor-ciona el sistema operativo.

La acreditación y evaluación de las competenciasprácticas por parte del estudiante puede resultar unatarea complicada, atendiendo al volumen de estudi-antes y el tiempo requerido para la realización delseguimiento que debería realizarse según las direc-trices del Tratado de Bolonia.

La siguiente subsección detalla el procedimien-to propuesto para analizar el progreso y evaluar losavances de los estudiantes en materia de progra-mación de sistemas.

XVIII Jornadas de Enseñanza Universitaria de la Informática 131

2.2. Método y procedimiento de evaluación

Para analizar el progreso de los estudiantes se re-alizarán diversas sesiones evaluables de prácticasde una hora y media de duración, donde éstos de-berán resolver problemas acotados de programaciónde sistemas (sólo un problema por sesión). Para re-solver dichos problemas, deberán emplearse aque-llos mecanismos y estructuras específicos cuya ha-bilidad y manejo se desean evaluar.

Uno de los requisitos fundamentales exigidos alos problemas planteados a los estudiantes es queéstos deben proporcionar una salida determinista, esdecir, independiente del orden de ejecución de las in-strucciones y concurrencia de los procesos que inter-vengan en la solución implementada. Esto permiteagilizar el procedimiento de evaluación, dado queestudiantes y profesores conocen en el acto si se haalcanzado una solución al problema, ya sea óptimao no.

Además de la descripción del problema a resolvermediante el correspondiente enunciado, al estudi-ante se le proporciona gran parte del sistema a im-plementar (en torno al 75-80% de la codificacióntotal). Entender el comportamiento y la finalidaddel código proporcionado es otra de las habilidadesevaluables.

Durante toda la sesión, los estudiantes tienen asu disposición las páginas del manual del sistema(aplicaciones, funciones de biblioteca estándar, lla-madas al sistema, etc.). Al terminar la realización dela prueba práctica, los estudiantes anotan sus solu-ciones en papel con el objetivo de facilitar futurasconsultas y reclamaciones sobre dichas soluciones.

Con esto, se pretende que el procedimiento deevaluación considere diferentes niveles cognitivosde pensamiento. Así, tomando como referencia lataxonomía de Bloom [4], los niveles abordados son:

• Conocimiento y comprensión: el empleo delas páginas del manual del sistema implicaconocer o recordar determinadas funciones yllamadas al sistema de una manera aproxima-da. Saber manipularlas del modo idóneo para laresolución del problema implica haber alcanza-do el nivel de comprensión.

• Aplicación: para resolver el problema plantea-do, los estudiantes deben demostrar que sabenutilizar los conocimientos adquiridos aplicán-dolos a nuevas situaciones.

• Análisis: entender el código proporcionado,identificar las partes en las que se descomponeel problema, etc., también constituye un com-ponente evaluable. Ello supone que los estudi-antes están trabajando en el nivel de análisis dela taxonomía.

• Síntesis: añadir el código necesario para al-canzar una solución al problema, integrándolacon el resto del código proporcionado, implicahaber alcanzado este nivel cognitivo.

Para que todos los estudiantes tengan disponiblesun entorno de trabajo concreto y específico parala realización de las pruebas, así como el enunci-ado y el código necesarios, debe disponerse de unmecanismo que permita tener controlado tanto el en-torno de trabajo como la distribución del material.En la siguiente subsección se pasarán a describir losmecanismos, servicios y procedimientos necesariospara su implantación.

2.3. Implantación

La Escuela Superior de Informática de la Univer-sidad de Castilla-La Mancha cuenta con 207 or-denadores para las clases prácticas, repartidos en10 laboratorios docentes2. Cada aula cuenta con unhardware de ejecución específico, pero todos es-tán basados en arquitectura x86. Los requerimien-tos mínimos que debe tener cada computador parapertenecer al sistema son una memoria RAM de500 MB, una partición Swap de 1 GB, y tener unaconexión de al menos 100Mbits/s (todos los orde-nadores están conectados a la red utilizando switch-es de 100Mbits/s). La figura 1 muestra un esque-ma general de la configuración del sistema utilizadopara la gestión de los exámenes.

Para el desarrollo del examen se utiliza una ima-gen de GNU/Linux basada en Slackware sin servidorX, con las herramientas básicas de programación desistemas instaladas (make, gcc, gdb...), así como laspáginas del manual man. A esta versión del sistemaoperativo se le ha eliminado el soporte de red, de for-ma que una vez cargada la imagen del sistema oper-ativo no es posible acceder a la red (tanto a Internetcomo a la red local).

De esta forma no es posible que los estudiantescompartan ningún tipo de material por red. Por la

2http://webpub.esi.uclm.es/curso/actual/espacios-docentes

132 Evaluación del aprendizaje

Figura 1: Esquema general de implantación del sistema de distribución de exámenes de laboratorio.

misma razón, tampoco es apropiado instalar la ima-gen de forma permanente en las máquinas, de modoque la imagen del sistema operativo no utiliza ningu-na partición del disco duro del ordenador sobre elque se carga. Todo el sistema de archivos se montaen memoria RAM de modo que, cuando se finalizael examen y se apagan los ordenadores del aula, noqueda ningún resultado de la realización del mismo.

Cada nodo del sistema se configura para obten-er los parámetros de configuración de la red; em-pleando la extensión PXE (Pre eXecution Environ-ment) de la BIOS. En nuestro caso estos datos seencuentran en la imagen del sistema operativo queserá ejecutado. De esta forma, sin necesidad de in-stalar ningún tipo de software, se carga la imagendel sistema operativo (que está formada únicamentepor los servicios básicos, las herramientas de com-pilación, edición y depuración, las páginas del man-ual y la plantilla de código fuente correspondiente alexamen concreto que se va a realizar). Para garanti-zar que el sistema de archivos pueda montarse ade-cuadamente en los ordenadores de todas las aulas, laimagen del mismo una vez descomprimida debe serde un tamaño inferior a 512MB.

El servidor tiene dos procesos claves para atenderlas peticiones PXE; el DHCPD y el TFTPD. El pro-tocolo DHCPD (Dynamic Host Configuration Pro-

tocol Daemon) se utiliza para informar a cada clientede la IP que le corresponde y la imagen del sistemaoperativo que debe cargar. Por su parte, el TFTPD(Trivial Transfer Protocol Daemon) se encarga deenviar el archivo al nodo consultando las tablas deconfiguración correspondientes.

Como se ha comentado anteriormente, el sistemade archivos completo que usará el sistema operati-vo se encontrará montado en memoria. De esta for-ma es posible utilizar el disco RAM inicial (initrd)para que contenga el sistema de archivos completo(sin necesidad de una posterior carga del sistema dearchivos raíz).

En el sistema de arranque initrd, los archivos ac-cesibles por el núcleo en la etapa de arranque se en-cuentran en un sistema de archivos que puede mon-tarse como un dispositivo de bucle. En el caso de laimagen del sistema operativo utilizado para la eval-uación de prácticas (initrd.gz) tiene un tamaño basecomprimido de 88MB, al que hay que incorporarlas plantillas de código y datos de prueba concretospara cada examen (que habitualmente no superan los500KB).

Este proceso de actualización de cada examenpuede resumirse en los siguientes pasos (que son au-tomatizados empleando un script en bash):

XVIII Jornadas de Enseñanza Universitaria de la Informática 133

1. Descompresión de initrd.gz sobre un sistemade archivos local (máquina del profesor).

2. Montaje de la imagen descomprimida (initrd)sobre un directorio local del sistema en modobucle.

3. Copia de la plantilla del examen al directorio/home/alumno del sistema montado.

4. Desmontaje del directorio.5. Compresión de la imagen initrd.6. Subida de initrd.gz al servidor de arranque

PXE mediante sftp.7. Actualización de enlaces simbólicos para el ar-

ranque de la misma imagen del sistema operati-vo en todas las aulas de laboratorio (automatizaempleando un script del lado del servidor).

En la versión actualmente implantada de este es-quema, el arranque del núcleo del sistema operativose realiza de forma manual antes de proceder a larealización del examen de prácticas. Los profesoresde la asignatura deben arrancar cada máquina y se-leccionar en el menú de arranque el nombre de laimagen. Este proceso conlleva aproximadamente 5minutos por aula docente.

Actualmente se encuentra en pruebas un mecan-ismo automático para activar o desactivar los orde-nadores del sistema haciendo uso de una extensiónde las BIOS actuales llamada WOL (Wake On Lan),que ha sido exitosamente utilizada en otros proyec-tos de Rendering Distribuido realizados en la ESI[8]. Esta extensión se utiliza con la ayuda de la placamadre y el paquete software Ether-Wake. Incluso siun ordenador se encuentra apagado, la tarjeta de redcontinúa escuchando posibles peticiones. Cuando elpaquete generado por Ether-Wake llega a la tarjeta,el ordenador se enciende y, por medio de una peti-ción PXE, se carga la imagen del sistema operati-vo. Finalmente, para apagar por completo los orde-nadores es necesario configurar correctamente el in-terfaz ACPI. Para poder hacer uso de esta funcional-idad se implementó un sencillo script en el lado delservidor el cual establece una conexión ssh con cadanodo y les envía el comando shutdown para apagar-los.

3. Primeros datos de su aplicación

El mecanismo de evaluación de laboratorio descritoen el presente trabajo se ha utilizado en la asignatu-

ra de Ampliación de Sistemas Operativos desde elcurso 2008/2009. La evaluación de las competen-cias relativas a las prácticas de laboratorio en cur-sos anteriores se realizaba mediante la resolución deun examen escrito en aula de teoría, y un test deconocimientos previos sobre ANSI C y System V.

La figura 2 muestra las calificaciones obtenidaspor los estudiantes de la asignatura de ambas titula-ciones (Ingeniería en Informática e Ingeniería Téc-nica en Informática de Sistemas) en los últimos 4años.

Los datos correspondientes al curso 2007/2008son similares a los obtenidos en convocatorias de lostres cursos anteriores. Antes de la incorporación dela nueva metodología de evaluación de las prácticasde laboratorio, la tasa de rendimiento era del 23%de los estudiantes (con una tasa de abandono - nopresentados - del 37%).

El primer año de incorporación del mecanismo deevaluación de prácticas presentado en este trabajomejoró los resultados de aprobados (con una tasa derendimiento del 30%), aunque empeoró la tasa deabandono (casi un 50% sobre matriculados).

En los siguientes cursos (2009 y posteriores) con-tinua el crecimiento en el porcentaje de aprobadossobre matriculados, y se disminuye la tasa de aban-dono frente al curso 08/09.

Los exámenes completos compuestos por lasplantillas suministradas a los estudiantes (enunci-ado y código fuente), junto con las soluciones detodas las pruebas realizadas en el curso académico2010/2011 se encuentran disponibles3 para su estu-dio y evaluación.

4. Valoración de los resultados obtenidos

Una de las principales conclusiones obtenidas trashaber analizado los resultados detenidamente es queel número final de estudiantes que superan la asig-natura es mayor con respecto al método más clási-co, basado en pruebas escritas, utilizado durante loscursos 2007/2008 y anteriores. Además, la tenden-cia al alza respecto al número de aprobados se con-firma con el paso del tiempo. En este contexto, laadaptación de los estudiantes al nuevo método deevaluación supone un factor relevante.

También se puede apreciar cómo en el cur-

3www.esi.uclm.es/www/cglez/downloads/docencia

134 Evaluación del aprendizaje

Figura 2: Tasa de Rendimiento en Ampliación de Sistemas Operativos (Cursos 2007-2011).

so 2008/2009 los resultados no son especialmentebuenos según la tasa de rendimiento, probablementedebido a la propia adapción a la nueva metodoló-gia de evaluación en el laboratorio. La realizaciónde los exámenes delante de un ordenador supone uncambio importante con respecto a la realización deun examen escrito ya que, por ejemplo, el resultadocorrecto del proceso de compilación es un requisitonecesario para la posterior ejecución del problema.Sin embargo, en un examen escrito suele existir másflexibilidad respecto a aspectos de este tipo.

Es importante destacar cómo la tasa de abandonodel curso 2010/2011 creció. Este hecho se debe aque la asignatura de Sistemas Operativos, del curso2o, se impartía de manera presencial por última vezdebido al cambio de plan de estudios de la EscuelaSuperior de Informática de Ciudad Real. Así, huboun número importante de estudiantes que focalizósus esfuerzos en superar dicha asignatura, optandopor no presentarse en la asignatura de Ampliaciónde Sistemas Operativos del curso 3o. Sin embargo, latasa de estudiantes suspensos en esta última es con-siderablemente baja durante el curso 2010/2011.

Desde una perspectiva general, la realización

de pruebas presenciales en el laboratorio conllevauna mayor implicación del estudiante a la hora deafrontar problemas reales vinculados a la asignaturade Ampliación de Sistemas Operativos, típicamenterelacionados con la sincronización de procesos me-diante semáforos y paso de mensajes. El hecho detener que programar una solución que compile y seejecute correctamente, además de generar la solu-ción correcta, hace que los estudiantes se impliquendirectamente en el uso del computador como her-ramienta final, reforzando así la adquisición de lascompetencias básicas de la asignatura y planteandoun esquema fiable para su evaluación.

Por otra parte, y debido a la propia naturaleza delmétodo de evaluación, los estudiantes hacen especialhincapié en la implementación real de las solucionesplanteadas en la parte más teórica de la asignatura,normalmente discutidas en pseudocódigo, con el ob-jetivo de prepararse de una manera más adecuadapara las pruebas de laboratorio.

Desde el punto de vista del profesor, el enfoqueplanteado facilita la evaluación práctica de los es-tudiantes, ya que el modelo de evaluación es total-mente determinista. En otras palabras, una solución

XVIII Jornadas de Enseñanza Universitaria de la Informática 135

es correcta o no lo es. Si es correcta, entonces elprofesor evaluará la calidad de la misma. Sin em-bargo, y en función del número de estudiantes in-volucrados en este tipo de pruebas, la coordinaciónde las mismas se puede convertir en una desventajasi dicho número es elevado. En tal caso, son necesar-ios más recursos humanos para controlar el correctofuncionamiento de las pruebas.

5. Conclusiones

En el presente trabajo se ha descrito una aprox-imación para la realización de pruebas prácticasevaluables en el laboratorio de la Ampliación de Sis-temas Operativos, asignatura obligatoria para las tit-ulaciones Ingeniero en Informática e Ingeniero enInformática de Sistemas en la Escuela Superior deInformática de la Universidad de Castilla-La Man-cha. Así mismo, se ha discutido la metodología em-pleada para la construcción de dichas pruebas.

En el contexto de la Adaptación al Espacio Eu-ropeo de Educación Superior se promueve el usode metodologías educativas y técnicas de evaluaciónactivas, potenciando el empleo de mecanismos decalificación y certificación de habilidades y compe-tencias que eliminen los exámenes finales como úni-ca fuente de evaluación del estudiante.

La metodología planteada en este trabajo, basa-da en la evaluación práctica del estudiante, permiteevaluar y seguir de una manera más estrecha laevolución del mismo, ofreciendo mecanismos másfiables para llevar a cabo dicha evaluación y garanti-zar la adquisición de las competencias prácticas másimportantes.

Los resultados obtenidos muestran cómo elnúmero de estudiantes que superan la asignaturaha crecido en los tres cursos de aplicación de lametodología propuesta, demostrando así la viabili-dad de este tipo de esquemas y fomentando el apren-dizaje activo por parte del estudiante en los aspectosmás prácticos de asignaturas vinculadas a la progra-mación de sistemas.

Referencias

[1] ACM/IEEE, Computer Science Curriculum2008, An Interim Revision of CS 2001. Reportfrom the Interim Review Task Force, Techni-cal report, Association for Computing Machin-ery (ACM) IEEE Computer Society, 2008.

[2] ACM/IEEE, Curriculum Guidelines for Under-graduate Degree Programs in Information Sys-tems, Technical report, Association for Comput-ing Machinery (ACM) Association for Informa-tion Systems (AIS), 2010.

[3] Anderson, L., Krathwohl, D., et al, A Taxonomyfor Learning, Teaching, and Assessing: A Revi-sion of Bloom’s Taxonomy of Educational Ob-jectives, New York: Longman, 2001.

[4] Bloom, B. S., Taxonomy of Educational Objec-tives, Handbook I: The Cognitive Domain, NewYork: David McKay Co Inc., 1965.

[5] Bonwell, C., Eison, J., Active Learning: Creat-ing Excitement in the Classroom, ASHE ER-IC Higher Education Report No. 1 , Techni-cal report, The George Washington University,School of Education and Human Development,1991.

[6] Dewey, J., How We Think, A Restatement of theRelation of Reflective Thinking to the EducativeProcess, D.C. Heath and company, New York,1922.

[7] Eden, H., Einsenberg, M., Fischer, G. Repening,A., Making learning a part of life, Communica-tions of the ACM, 39(4), 40-42, 1996.

[8] González, C., Weiss G., Vallejo, D., Jiménez L.Albusac J; 3D Distributed Rendering and Opti-mization using Free Software, Upgrade (The Eu-ropean Journal for the Informatics Professional),Vol 9, 45-53, 2007.

[9] McConnell, J.J., Active learning and its use incomputer science, SIGCUE Outlook 24(1-3),52-54, 1996.

136 Evaluación del aprendizaje