HACIA EL DISEÑO DE HERRAMIENTAS EDUCATIVAS DE PROGRAMACIÓN

BASADAS EN LA TAXONOMÍA DE BLOOM

Isidoro Hernán Losada, Carlos Alfredo Lázaro Carrascosa, J. Ángel Velázquez Iturbide
Universidad Rey Juan Carlos
i.hernan@escet.urjc.es, c.a.lazaro@escet.urjc.es, a.velazquez@escet.urjc.es

Resumen
Para la enseñanza de la programación, se usa una gran variedad de herramientas, desde simples tests a
entornos de programación, pasando por visualizadores de programas, depuradores, etc. Cada una de
estas herramientas es adecuada para objetivos educativos distintos. Nuestro objetivo es sistematizar el
diseño de estas herramientas en base al nivel de conocimiento esperado del alumno. Como marco de
referencia tomamos la jerarquía de Bloom. Proponemos herramientas de programación adecuadas a
cada nivel. A partir de ellas, pueden plantearse diversas formas de evaluación mediante tests,
resolución de problemas, etc.

1. Introducción
La enseñanza de la programación no es ajena a la informática educativa. Existen las mismas
razones para desarrollar aplicaciones educativas de programación que de cualquier otra disciplina
(Gallinari, Lázaro & Velázquez, 2002): reducción de errores humanos en la corrección, posibilidad de
detectar plagios, mayor motivación de los alumnos, apoyo a la autoevaluación, mayor facilidad para
trabajar en grupo, etc. Sin embargo, es necesario incorporar de forma planificada los elementos que la
pedagogía nos brinda a las herramientas de programación.
Nuestro interés se centra en el diseño sistemático de herramientas de programación para que el
alumno alcance el grado de conocimiento deseado. El grado de aprendizaje lo mediremos mediante una
escala de amplia aceptación, la taxonomía de Bloom (Bloom & Krathwohl, 1957).
La ponencia consta de los siguientes apartados. En el segundo, exponemos brevemente la
taxonomía de Bloom. El apartado tercero comenta algunos trabajos relacionados. El apartado cuarto
contiene nuestra propuesta para relacionar ambos conceptos, enumerando herramientas de programación
y estudiando su adaptación a varias formas de evaluar. Por último, damos nuestras conclusiones y lo que
falta por completar de nuestro trabajo.

2. Taxonomía de Bloom
En 1948 un grupo de educadores se reunió para clasificar los fines de la educación. Se pretendía
desarrollar una clasificación en tres dominios: cognitivo, afectivo y psicomotriz. Si nos centramos en la
programación, el factor más importante es el cognitivo. El trabajo en este dominio se terminó en 1956 y
se conoce comúnmente como taxonomía de Bloom (Bloom & Krathwohl, 1957).
La taxonomía establece una jerarquía de seis niveles con grado creciente de aprendizaje del
alumno. Cada nivel presupone la capacitación del alumno en los niveles precedentes (Bloom &
Krathwohl, 1957; Eisner, 2000). Según ascendemos por la jerarquía nos encontramos un mayor grado de
aprendizaje:
• Nivel 1 ó de conocimiento. El alumno es capaz de reconocer o recordar información sin que sea
necesario ninguna comprensión o razonamiento sobre lo que hay tras dicha información.
• Nivel 2 ó de comprensión. El alumno es capaz de entender y explicar el significado de la
información recibida.
• Nivel 3 ó de aplicación. El estudiante es capaz de seleccionar y usar datos y métodos para
resolver una nueva tarea o un problema.
• Nivel 4 ó de análisis. El alumno es capaz de distinguir, clasificar y relacionar hipótesis y
evidencias de la información dada, así como descomponer un problema en sus partes.
• Nivel 5 ó de síntesis. El estudiante es capaz de generalizar ideas y de integrarlas para resolver o
realizar algún problema que es nuevo para él.
• Nivel 6 ó de evaluación. El alumno está capacitado para comparar, criticar y evaluar métodos o
soluciones para resolver un problema o para discernir la mejor entre varias soluciones.

Se ha demostrado la bondad de esta taxonomía salvo en los dos últimos niveles. Se desconoce si la
síntesis es más compleja que la evaluación o viceversa, o si están al mismo nivel y se diferencian en los
procesos cognitivos usados. Algunos investigadores reducen esta jerarquía a cuatro niveles:
conocimiento, comprensión, aplicación y el cuarto y último de pensamiento crítico o de resolución de
problemas que engloba análisis, síntesis y evaluación de Bloom (Doménech y García, 1999).
En todo caso, es un marco comúnmente aceptado. Nosotros lo adoptamos, salvo el nivel de
evaluación que requiere una gran madurez, difícil de apoyar con herramientas de programación.

3. Trabajos relacionados
Tenemos interés en identificar herramientas adecuadas a cada nivel de Bloom para la enseñanza de
la programación y, en caso de que no existan, desarrollarlas. Un precedente es Amruth Kumar (2002), que
propone el uso de problets para el nivel de aplicación en materias bien delimitadas, en su caso conceptos
de programación. Son applets que generan problemas sobre un concepto y preguntas en forma de test.
Cada problet proporciona alguna clase de visualización o interacción para resolver el problema.
Fernández et al. (2002) asocian niveles de la jerarquía de Bloom con herramientas de
programación orientada a objetos:
• Conocimiento y comprensión: intérpretes con visualización.
• Aplicación: depuradores.
• Análisis: herramientas CASE e ingeniería inversa.
• Síntesis: entornos de programación.
• Evaluación: métricas.

Sin embargo, consideramos que su propuesta está insuficientemente justificada.

Naps et al. (2003) utilizan la jerarquía de Bloom como marco para evaluar la implicación
(engagement) de los alumnos en visualizaciones de programas. La importancia de la implicación para la
eficacia educativa de las visualizaciones se ha deducido de los resultados de experimentos controlados
(Hundhausen, Douglas & Stasko, 2002).
Sin embargo, Naps et al. (2003) señalan la dificultad de utilizar la jerarquía de Bloom para evaluar
el conocimiento de programación, ya que hay actividades que pueden afectan a varios niveles o cuya
ubicación es dudosa. Una cuestión problemática es que cierto conocimiento es tanto conceptual como de
implementación. Así, implementar un algoritmo puede verse como una forma de aplicar conocimiento
conceptual (nivel de aplicación), pero también es otra forma de reescribirlo (nivel de comprensión). El
diseño de un programa pertenece al nivel de aplicación si utiliza algoritmos y estructuras de datos
conocidos, mientras que pertenece al de síntesis si debe diseñarlos nuevos. También es problemática la
ubicación del análisis de complejidad, ya que puede concebirse en varios niveles, entre ellos aplicación y
análisis.

4. Propuesta sistemática
Existe una estrecha relación entre los niveles de aprendizaje de la taxonomía de Bloom y las
actividades planteadas a los alumnos, apoyadas en nuestro caso mediante herramientas de programación
adecuadas. Coincidimos con Ramón Pérez Juste en que “El gran medio que debe diseñar el profesorado
se concentra en las actividades que deberán realizar los alumnos para lograr los objetivos. Tales
actividades deberán ser adecuadas a la naturaleza de estos objetivos: no se alcanza del mismo modo un
objetivo como el de diseñar un proyecto como el de analizar datos o el de interpretar resultados” (Pérez,
2002).
En una primera aproximación, asociamos niveles de la jerarquía de Bloom con herramientas de
programación concretas. Después, nos centramos, entre la amplia gama de formas de evaluación
existentes (Brown, Bull & Pendlebury, 1997), en su combinación con dos fácilmente adaptables para
programación: tests y resolución de problemas.

5. Herramientas de pr ogramación
Según Herron (1971), podemos distinguir 5 niveles de experimentación:

Objetivo Materiales Método Respuesta

Demostración Fijo Fijo Fijo Fijo
Ejercicio Fijo Fijo Fijo Flexible
Indagación planific. Fijo Fijo en todo o parte Flexible o fijo en parte Flexible
Indagación abierta Fijo Flexible Flexible Flexible
Proyecto Flexible Flexible Flexible Flexible

No resulta difícil ver cierta relación entre estos niveles de experimentación y los niveles de
conocimiento de Bloom. Veamos una clasificación de herramientas de programación adecuadas para cada
nivel de Bloom, teniendo en cuenta los parámetros de la tabla anterior.

762
 Una primera dificultad es que los 4 conceptos de las columnas anteriores tienen una definición más
clara en ciencias que en programación. El objetivo es el enunciado del problema, que puede ser la
especificación de un programa o una pregunta sobre el comportamiento de un programa dado, sobre su
modificación, etc. Los materiales son los elementos del lenguaje de programación y herramientas de
programación que se pueden usar (bien operantes sobre el programa estático o en ejecución). El método
es el programa correspondiente al problema y quizá las restricciones que se puedan establecer sobre su
desarrollo o su forma final. La respuesta es la información pedida.
Una demostración de un programa es adecuada para el nivel de comprensión. Aunque en otras
disciplinas es frecuente usar simulaciones, no lo es en programación. Sin embargo, es fácil diseñar una
ejecución de un programa que, mediante un control del avance y una visualización adecuada, proporcione
una demostración. Es importante que, al menos, pueda avanzarse tanto hacia delante como hacia atrás
para que la actitud del alumno no sea totalmente pasiva (Naps et al., 2003).
Un ejercicio corresponde al nivel de aplicación. La herramienta puede permitir la manipulación o
el avance sobre el programa, lo que requiere un procesamiento del lenguaje de programación, al menos
restringido al concepto
Una indagación planificada corresponde al nivel de análisis. La herramienta permitirá crear,
modificar y borrar partes de un programa, de manera que pueda analizarse. Una herramienta de esta clase
son los editores de estructuras, que requieren un procesamiento completo del lenguaje.
Por último, una indagación abierta corresponde al nivel de síntesis. Es similar al apoyo
proporcionado por los entornos de programación, salvo que debe proporcionar las facilidades de niveles
inferiores, sobre todo análisis.

6. Tests
Los tests son un instrumento universal de evaluación, es decir, son independientes de la materia.
Su corrección es muy sencilla y automatizable. En su forma más simple, los tests permiten comprobar, sin
ninguna herramienta auxiliar, que el alumno tiene ciertos conocimientos. Algunos formatos son tests con
múltiples alternativas, con dos alternativas o problemas “de asociaciones”.
Utilizados de forma adecuada también sirven para evaluar los niveles superiores de comprensión,
aplicación y análisis. El nivel de comprensión puede alcanzarse mediante tests cuidadosamente diseñados
o con otras clases con un formato más adecuado: tests de múltiples respuestas permutacionales (Farthing,
Jones & McPhee, 1998), problemas “de rellenar espacios en blanco” o problemas “de rellenar espacios en
blanco” con opciones fijas para elegir.
También es posible alcanzar el nivel de aplicación si se plantean preguntas sobre problemas que
pueden resolverse aplicando conocimientos previos. En este caso, conviene disponer de una herramienta
auxiliar, dependiente de la materia, para resolver los problemas. Este enfoque se ha adaoptado, por
ejemplo, en Tutormap (Criado, Gallinari & Velázquez, 2000). El sistema propone tests cuya respuesta
exige resolver un problema de matemáticas con Maple. También se usa en los ya mencionados problets
de Kumar (2002).
No resulta muy difícil imaginar el uso de tests para el nivel de análisis: se pregunta qué sucedería
en ciertas situaciones, qué límites existen o cómo puede reestructurarse una solución.

7. Resolución de problemas
Quizá sea la forma más extendida para evaluar en programación. Se da la especificación de un
problema por resolver mediante el desarrollo de un programa parcial o completo con las herramientas
esbozadas anteriormente. Su problema principal es la evaluación automática.
En el nivel de aplicación, el alumno debe ser capaz de desarrollar el código pedido aplicando sus
conocimientos de programación. Su validación dependerá de cada caso, p.ej. puede probarse un
subprograma mediante pruebas o la cohesión de una clase mediante métricas. En el nivel de análisis, al
alumno deberá manejar, descomponer y reestructurar programas. En el nivel de síntesis, hay que diseñar
un programa nuevo con los elementos del lenguaje.

8. Conclusiones
Hemos realizado una propuesta sistemática, basada en la jerarquía de Bloom, de herramientas de
software que permitan ejercitar todos los niveles de conocimiento. También hemos estudiado la
evaluación mediante tests y resolución de problemas usando las herramientas anteriores.
Para comprobar la validez de este marco básico, falta completarlo y aplicarlo a una asignatura
completa. Por un lado, hay que completar el diseño realizado para una asignatura concreta de
programación, en nuestro caso de programación orientada a objetos. Por otro lado, hemos considerado
dos formas de evaluación, tests y resolución de problemas, pero falta por ver su adecuación a otras. Por

763
último, falta completar el diseño de las herramientas identificadas con elementos educativos importantes
para formación y evaluación, como generación de ejercicios, corrección automática, tutorización o
visualización de programas.

9. Agradecimientos
Este trabajo se ha financiado con el proyecto TIC-2001413 de la CYCIT.

10. Referencias
Bloom, B. & Krathwohl, D. R. (1956). Taxonomy of Educational Objetives: Handbook I, The Cognitive Domain.
New York: Addison-Wesley.
Brown, G., Bull, J. & Pendlebury, M. (1997). Assessing Student Learning in Higher Education, Londres: Routledge.
Criado Herrero, R., Gallinari, A. & Velázquez Iturbide, J. Á. (2001). Tutormap: Past, present and future of a
mathematics computer tutor. En Manuel Ortega y José Bravo (eds.), Computers and Education: Towards an
interconnected society, Kluwer, (pp. 103-111).
Doménech Betoret, F., & García Bacete, F. J. (1999). Guía didáctica del profesor universitario.
http://sic.uji.es/cursos/use/virtual/index.htm (consultado en Febrero 2003).
Eisner, E. W. (2000). Benjamin Bloom. Perspectivas: Revista Trimestral de Educación Comparada, XXX(3), 423-432
Farthing, D. W., Jones, D. M. & McPhee, D. (1998). Permutational multiple-choice questions: An objetive and
efficient alternative to essay-type examination questions. En Proceedings of the 3 rd Conference on Innovation
and Technology for Computer Science Education, ITiCSE 1998, ACM Press (pp. 81-85).
Fernández Muñoz, L., Peña Ros, R., Nava García, A. & Velázquez Iturbide, J. Á. (2002). Enfoque diacrónico para la
enseñanza de la programación imperativa. En Actas de las VIII Jornadas de la Enseñanza Universitaria de la
Informática, JENUI’02, Universidad de Extremadura (pp. 407-414).
Herron, M. (1971). The nature of scientific enquiry, School Review, 79, 171-212.
Gallinari, A., Lázaro Carrascosa, C. A. & Velázquez Iturbide, J. Á. (2002). Colecciones, correctores y generadores
automáticos de ejercicios de programación. En Actas de las VIII Jornadas de la Enseñanza Universitaria de
la Informática, JENUI’ 02, Universidad de Extremadura (pp. 21-28).
Kumar, A.N. (2002). Model-based animation of program visualization. En M. Ben-Ari (ed.), Proceedings of the
Second Program Visualization Worshop, DAIMI PB-567, University of Aarhus (pp. 37-44).
Naps T.L., Roessling G. y otros (2003). Exploring the role of visualization and engagement in Computer Science
Education. SIGCSE Bulletin, 35(3), pendiente de publicación.
Pérez Juste, R. (2002). Evaluación de programas en educación social. Guía Didáctica. Madrid: Universidad
Nacional de Educación a Distancia.

764