CONSTRUCCIÓN – Semestre 01-2019

Fecha. Bucaramanga – Colombia

Developing software is not an easy matter

Desarrollar software no es una cuestión fácil

Autor1, Autor2, Autor3
1Afiliación. correo; 2Afiliación. correo; 3Afiliación. Correo.

INFORMACIÓN DEL ARTÍCULO ABSTRACT

Why is it so difficult to learn to develop software? This question has been trying to answer for
Tipo a long time, but has not yet found a solution to this issue. Moreover, it tends to confuse
Reflexión (Investigación, Revisión) development with programming, and this also creates problems to elucidate the question. In
an era in which urgently required improve the quality, and reliability, and safety of software
Disciplina ingenieril: (Revisar la lista it becomes urgent to potentiate or develop skills and abilities in professionals to meet these
en la página de la conferencia) needs. But students are not interested in making careers involving these concepts, they prefer
other less demanding and easier to achieve a certification. This article attempts to answer the
Historia question and present some suggestions for overcoming this difficulty.
Recibido: xx-xx-xxxx
Correcciones: xx-xx-xxxx RESUMEN
Aceptado: xx-xx-xxxx ¿Por qué es difícil aprender a desarrollar software? Este interrogante se ha intentado
responder desde hace mucho tiempo, pero todavía no se ha encontrado una solución a esta
Keywords cuestión. Además, se tiende a confundir desarrollo con programación, y esto también genera
Software development, problemas para dilucidar la pregunta. En una época en la que se requiere urgentemente
programming, programming tools. mejorar la calidad, la fiabilidad, y la seguridad del software se hace apremiante potencializar
o desarrollar habilidades y destrezas en los profesionales para atender estas necesidades.
Palabras clave Pero los estudiantes no están interesados en tomar carreras que involucren estos conceptos,
Desarrollo de software, prefieren otros de menos exigencias y con mayor facilidad para alcanzar una titulación. En
programación, herramientas de este artículo se intenta responder a la pregunta y se presentan algunas sugerencias para
programación. superar esa dificultad.
© 2016. IAI All rights reserved

1. Introducción sugiere que tal vez haya demasiados programadores hoy

La mayoría de personas tiene acceso, utiliza o depende de
un sistema software, y el desarrollo de la actual sociedad
está sometido a los productos desarrollados en software.
Con este panorama, ¿por qué el software no satisface
plenamente a los usuarios? ¿Por qué sus productos
presentan falencias en seguridad y fiabilidad? ¿Por qué las
legislaciones no le prestan suficiente atención a este
asunto? En general, se podría encontrar mejores formas de
desarrollar software, aminorar sus costos, y endurecer las
políticas de seguimientos a estos productos. Pero el hecho
de que la programación gire en torno a personas, y que lo
lleven a cabo personas, dificulta llegar a soluciones
rápidamente. Programar puede ser sencillo, al menos es la
creencia popular, pero desarrollar es una cuestión de
ciencia y conocimiento, por eso es difícil. Por esto es que
cada día menos estudiantes quieren ser desarrolladores.
Se necesitan más desarrolladores, y esto se ha convertido
en un punto de controversia mundial. La Oficina de
Estadísticas Laborales de los Estados Unidos predijo en
2008 una enorme demanda de profesionales en
informática [1]. De acuerdo con este informe, la demanda
de profesionales de TI de 2006 a 2016 será el doble de la
tasa de crecimiento del resto de la fuerza laboral. La
estimación actualizada en noviembre de 2009 [2] predecía
que las ocupaciones en Informática y Matemáticas eran el
grupo ocupacional de más rápido crecimiento dentro del
grupo principal de más rápido crecimiento. La estadística
de la cantidad de profesionales en TI desempleados
en día, pero muy pocos desarrolladores [3].
Para la mayoría ambas ocupaciones son lo mismo,
programadores y desarrolladores, pero un excelente
trabajo de la RedLatinaIS [4, p. 20] aclara esta cuestión y
determina las diferencias sustanciales entre ambas:
Los programadores escriben buen código. Hacerlo bien y
limpio es un factor importante, pero a menudo tienen
prioridad otras cuestiones. Las habilidades matemáticas
son opcionales, aunque poseerlas les ayuda a ser
conscientes de los problemas comunes y de las
soluciones relacionadas con el dominio, pero son
primordiales las relacionadas con la comunicación y la
interacción social. Son generalistas sin un tipo de
especialización verdaderamente profundo; son capaces
de encontrar caminos en torno a los problemas, y de
conectar diversos componentes para cumplir con una
serie de requisitos. Su trabajo consiste en aplicar el
conocimiento que poseen, del lenguaje de programación,
para escribir código eficiente y eficaz, a la vez que
respetan los conceptos de calidad y de seguridad, y
responden al diseño que se ha construido desde la
Ingeniería de Software.
Los desarrolladores escriben código de calidad. Hacerlo
limpio, claro, bien factorizado y libre de errores son
cuestiones importantes que tienen en cuenta, y además
conocen el significado de buen código dentro de un
dominio. Tienen adecuados conocimientos en
matemáticas y en cómo buscar buenas soluciones para
 los problemas; poseen amplios conocimientos en
algoritmia y buenas habilidades en su área de experticia
y las relacionadas; debido a que su trabajo se
desenvuelve al interior de equipos multi-disciplinares,
poseen buena capacidad de comunicación verbal y
escrita, y de interacción con otras personas. Son
profesionales que contribuyen de diversas maneras para
que el producto software tenga éxito, y su trabajo
consiste en aplicar principios científicos e ingenieriles
para comprender, abstraer y moldear un problema, que
se pueda resolver mediante un programa informático,
para luego aplicar una metodología con el objetivo de
llevar a la práctica la solución creada, tradicionalmente
soportada en código de lenguaje de programación. En
términos generales son responsables de aplicar procesos
de calidad en todo el ciclo de vida del software.
Aunque puede no estar claro si la industria necesita más
programadores o más desarrolladores, lo que sí es una
realidad es que muchos estudiantes comienzan por el
camino de la programación y se desaniman rápidamente.
Las cifras de las altas tasas de deserción en los cursos
introductorios de computación son comunes en la
literatura y en las discusiones en diferentes Congresos y
Conferencias. Jens Bennedsen y Michael Caspersen [5]
hicieron el primer intento razonable para averiguar lo que
realmente parecen las tasas de fracaso. Solicitaron datos a
profesores de todo el mundo a través de varias listas de
correo de Ciencias Computacionales (CS). Más de 60
instituciones presentaron sus tasas de fracaso en estos
cursos, lo que significa que estos datos son auto-
seleccionados y auto-reportados. Por ejemplo, escuelas
con resultados realmente embarazosos pueden haber
optado por no participar, o mentir, y los resultados pueden
estar sesgados debido a que el muestreo era no-aleatorio.
En general, el 35% de los estudiantes fracasan o se retiran
del primer curso. Por lo tanto, los indicios indican que
aproximadamente uno de cada tres estudiantes que inician
un curso CS, en todo el mundo, falla o se da por vencido.
¿Por qué pasa esto?
Aunque los resultados del estudio reportan el éxito o el
fracaso en tomar un curso en una universidad, para
algunos el criterio de asistir a un proceso de educación
formal no es la única definición posible de éxito. Hay
muchos programadores que nunca tomaron un curso
formal en toda su vida, pero tienen éxito en la vida laboral.
Nuevamente, persiste la confusión entre lo que es ser
programador y ser desarrollador, y lo peor, la industria
tampoco parece diferenciar.
Claro que se necesita un proceso formal de capacitación
para adquirir o potencializar las habilidades, destrezas, y
capacidades para desarrollar software. Así que primero
hay que establecer la razón por la que los estudiantes
tienen dificultades para este aprendizaje. Si fuera posible
establecer si es que desarrollar software es una actividad
anti-natural, se podrían buscar formas alternativas y
nuevas didácticas para hacerlo más fácil o diferente. Una
investigación liderada por el profesor colombiano Edgar
Serna [6-10] determinó que una característica necesaria
para este tipo de profesionales es que desarrollen su
capacidad lógico-interpretativa y abstractiva, porque,
como él mismo concluye, el desarrollo de software es un
proceso netamente abstracto, y se requiere una mente
lógica para interpretarlo, modelarlo, y simularlo. Al
parecer se debería comenzar por ahí para buscar que los
estudiantes no abandonen estas disciplinas.
2. Aprender a desarrollar/programar
En la década de 1980 en la Universidad de Yale se utilizaba
reiteradamente un ejercicio el curso de programación en
Pascal [11]: Escribir un programa que sume
repetidamente números enteros positivos, e imprimir su
promedio cuando lea el valor entero 99999. Conocido
como el problema de la precipitación, se convirtió en uno
de los más estudiados en los primeros años de la
investigación en informática educativa. En el artículo de
1983, del que se toma la formulación presentada, el equipo
de Yale estaba explorando cómo mejorar el rendimiento de
los estudiantes en la solución del ejercicio, y se lo
presentaron a tres grupos diferentes: 1) estudiantes de
primer semestre, que ya sabían utilizar los ciclos while,
repeat, y for, 2) estudiantes de segundo semestre, que ya
habían recibido por lo menos un curso de estructuras de
datos, y 3) estudiantes de tercer y cuarto año de
programación de sistemas.
En cada grupo la mitad de los estudiantes utilizó Pascal
tradicional y la otra mitad tenía la oportunidad de utilizar
otro lenguaje (C o Phyton). Los resultados, resumidos en la
Tabla 1, pueden sorprender: sólo el 14% de los estudiantes
de primer semestre pudo resolverlo en Pascal, y el 30% de
los estudiantes del segundo semestre no pudo resolverlo
en ningún lenguaje. Este estudio fue repetido en la
literatura varias veces [12, 13], formal e informalmente,
sorprendente con resultados similares cada vez.
Tabla 1. Rendimiento de los estudiantes de Yale
Grupo Con Pascal Con C o Phyton
Primer semestre 14% 24%
Segundo semestre 36% 61%
Tercer y cuarto año 69% 96%
La solución al ejercicio requiere un condicional
relativamente complejo que controle el ciclo: si la entrada
es negativa, la ignora y continúa con la siguiente; si la
entrada es positiva y diferente de 99999, la lleva a la suma,
incrementa el contador, y continúa con la siguiente; si la
entrada es 99999, la ignorar, sale del ciclo, y muestra la
suma. Es fácil cometer un error al tener en cuenta la
entrada 99999 en la suma.
Estos resultados se lograron en la Universidad de Yale.
Entonces, ¿podría ser que en Yale la enseñanza de la
programación fuera realmente mala? En esos años pocos
estudiantes podrían haber aprendido algo de
programación antes de entrar en la universidad, así que
cualquier instrucción que recibieran provenía de los
cursos del primer semestre. Durante muchos años los
investigadores se preguntaron cómo llevar a cabo un
estudio acerca de la programación de computadores en el
que se pudiera evitar el factor de una posible mala
formación en la institución.
En 2001, Mike McCracken [14] organizó un grupo de
investigadores para realizar un mismo estudio en cada una
de sus cursos: asignar el mismo ejercicio y darles a los
estudiantes 90 minutos para presentar una solución en
papel. Cuatro instituciones de tres países participaron en
este primer estudio multi-institucional, multi-nacional
(MIMN) de rendimiento de los estudiantes en informática.
Mediante una comparación de resultados a través de
fronteras institucionales y nacionales, los investigadores
esperaban obtener una imagen clara de lo que realmente
pueden hacer estudiantes en sus primeros cursos.
El problema fue evaluar expresiones aritméticas (prefijo,
infijo, o postfijo) sólo con números, operadores binarios (+,
-, /, *), o negación unaria (~ con el fin de evitar la
complicación de sobrecargar el signo menos). En total, 216
estudiantes presentaron respuestas. La puntuación media
sobre un una rúbrica de clasificación independiente del
lenguaje de 110 puntos fue 22,89 (21%). Los estudiantes
solucionaron terriblemente el ejercicio.
El grupo de trabajo realizó varias evaluaciones de los
datos, y encontraron que el rendimiento varía
dramáticamente entre cursos. También evidenciaron los
efectos joroba, que muchos profesores de informática han
señalado y que varios trabajos han tratado de explicar.
Algunos estudiantes simplemente hacen las cosas, y
funcionan bien, pero la mayoría no lo logra. ¿Por qué es que
algunos estudiantes simplemente consiguen programar y
otros no? Se ha investigado desde variables como la
experiencia previa en el área y los conocimientos
matemáticos [15], y todavía no hay explicación
convincente para este efecto.
Algunos estudiantes pueden no responder a un estilo
particular de enseñanza o profesor, pero ¿por qué tantos
estudiantes de diferentes instituciones lo hacen tan mal?
¿Estamos enseñando mal en todas partes? ¿Estamos sobre-
estimando lo que los estudiantes deben ser capaces de
hacer? O ¿no estamos midiendo las cosas correctas?
Raymond Lister [16] organizó otro grupo de trabajo en
2004 para explorar algunas de estas preguntas. La idea de
este equipo era que el grupo de McCracken pedía
demasiado de los estudiantes. Darles un problema
requiere un alto nivel de pensamiento para diseñar e
implementar una solución. Entonces decidieron centrarse
en las habilidades de bajo nivel para leer y trazar código.
Crearon un cuestionario de opción múltiple (MCQ por sus
siglas en inglés), en el que se les pedía a los estudiantes
llevar a cabo tareas como lectura de código e identificación
de resultados, o identificar el código correcto para llenar
los vacíos en un fragmento de programa. Las preguntas se
centraron en la manipulación de arreglos. Les pidieron a
los participantes de todo el mundo tratar la misma MCQ
con sus estudiantes. Los resultados fueron mejores, pero
aún decepcionante. Los 556 estudiantes tuvieron un
puntaje promedio del 60%. Aunque estos resultados
sugirieron que el grupo McCracken sobrestimó lo que los
estudiantes podían hacer, Lister y su grupo esperaban un
rendimiento mucho mejor en sus preguntas.
Los esfuerzos McCracken y Lister les enseñaron a los
investigadores que es difícil subestimar la cantidad de
estudiantes a entender cuando se trata de enseñar a
desarrollar software. Están aprendiendo claramente
mucho menos de lo que pensamos. Ahora, algunos
estudiantes están aprendiendo; pero la mayoría no.
Entonces, ¿qué tan difícil es aprender a desarrollar
software para que la mayoría de estudiantes no lo logren?
2.1 ¿Por qué es difícil?
Los lingüistas suelen coincidir en que los seres humanos
están cableados para el lenguaje. El cerebro ha
evolucionado para aprenderlo rápida y eficientemente. Es
decir, estamos conectados específicamente para el
lenguaje natural. Por el contrario, la programación es la
manipulación de un lenguaje artificial inventado para un
propósito relativamente poco natural: decirle a un
determinado agente no humano (computador)
exactamente qué hacer. Tal vez la programación no es una
actividad natural para los humanos, y sólo unos pocos son
capaces de realizar los ejercicios mentales complejos para
tener éxito en este acto anti-natural.
En este orden de ideas, ¿Cómo podemos responder esta
pregunta? Podemos intentar un enfoque similar a la
modificación de Lister al trabajo de McCracken: escoger
una parte más pequeña de la tarea y centrarse sólo en eso.
Programar es decirle a una máquina qué hacer en un
lenguaje no-natural. Y, si les indicamos a los participantes
del estudio que describan en lenguaje natural ¿cómo le
dirían a otro ser humano como llevar a cabo una tarea
determinada? ¿Cómo definirían sus programas? Si
quitamos el lenguaje artificial, ¿está programación sería
natural o de sentido común?
En 1981 Miller [17] les pidió a los participantes en sus
estudios crear instrucciones para que otros las siguieran.
Los participantes recibieron descripciones de varios
archivos (empleados, cargos, salarios), y tareas como:
hacer una lista, organizada por el nombre, de los
empleados que cumplan cualquiera de los siguientes
criterios: 1) tienen un cargo técnico y ganan 6 dólares o
más por hora, o 2) es soltero y gana menos de 6 dólares por
hora. Miller aprendió mucho acerca de qué era difícil y qué
era fácil para los participantes. En primer lugar, los sujetos
completaron sus tareas. En los resultados no dice que 1/3
abandonaron o fracasaron, como pasa todo el tiempo en
los cursos de programación. El reto fundamental de
especificar un proceso para que ejecute otra persona no
parece ser el problema.
Una diferencia clave entre las soluciones en lenguaje
natural a los problemas de Miller y los problemas de
programación estudiados por otros investigadores es la
estructura de la solución. Los temas de Miller no definieron
iteraciones, pero sí un conjunto de operaciones. Por
ejemplo, ellos no dijeron: tome cada carpeta y mire el
apellido; si comienza con S... En su lugar, hablaron de hacer
las cosas para todos los apellidos que empiezan con S...
Miller se sorprendió de esto: nadie especificó las
condiciones de finalización para este ciclo. Algunas
personas hablaron sobre condiciones IF-like, pero ninguno
utilizó un ELSE. Estos resultados puntualizan la posibilidad
de que definir un lenguaje de programación natural es más
fácil para los principiantes. Miller llevó a cabo otro
experimento separado donde les dio a otros participantes
las mismas instrucciones del primer experimento pero
definiendo vagamente los ciclos necesarios. Ninguno tuvo
problema con estas instrucciones. Era obvio cuando parar
al procesar los datos. Los sujetos procesaron el conjunto de
datos, pero se incrementaron un índice.
John Pane [18] tomó de nuevo esta exploración a finales de
1990 y principios de 2000, porque estaba interesado
explícitamente en la creación de un lenguaje de
programación que estuviera más cerca de cómo las
personas describen naturalmente procesos para que otros
utilicen. Replicó los experimentos de Miller, pero con
diferentes tareas y entradas. Le preocupaba que al
proporcionar archivos y solicitar listas, Miller pudo haber
direccionado los resultados. En cambio, Pane les mostró a
los participantes imágenes y películas de videojuegos, y
luego les preguntó cómo le indicarían al computador que
realizara lo mismo; por ejemplo, escribir una declaración
para que mueva a Pac-Man en relación con la presencia o
ausencia de otras cosas. Como Miller, encontró que las
personas no son explícitas acerca de los ciclos. Al ir más
allá de caracterizar los tipos de instrucciones que
escribieron en términos de paradigmas de programación,
encontró un montón de uso de restricciones (éste está
siempre haciendo eso), de programación orientada a
eventos (cuando Pac-Man se lleva todos los puntos se pasa
al siguiente nivel), y de programación imperativa. Nadie
habló de objetos ni una sola vez. Hablaron sobre las
características y los comportamientos de las entidades en
el videojuego, pero no las agruparon (por ejemplo, en
clases). Nunca hablaron de los comportamientos desde la
perspectiva de las propias entidades; todo estaba desde la
perspectiva del jugador o el programador.
Con base a los experimentos de Miller y Pane, se podría
afirmar que las personas pueden ser capaces de especificar
funciones para otro agente, pero los actuales lenguajes de
programación no les permiten programar la forma en que
piensan acerca de las tareas. Si los lenguajes de
programación fueron hechos más naturales, ¿podría la
mayoría de estudiantes aprender a programar? ¿Podrían
las personas resolver problemas complejos que implican
algoritmos significativos? ¿Sería bueno tanto para tareas
simples como para profesionales? Y si no, ¿podrían los
estudiantes en algún momento aprender un lenguaje
profesional?
Un grupo de investigadores que se hacen llamar
Commonsense Computing Group [19] ha estado
respondiendo algunas de estas preguntas. Les piden a
estudiantes de primer semestre resolver tareas
algorítmicas significativas, como la clasificación o la
paralelización de un proceso, en lenguaje natural y antes
de que hayan aprendido cualquier lenguaje de
programación. Han encontrado resultados sorprendente
en estas tareas. En un estudio [20] les pidieron a los
estudiantes crear un proceso para un teatro que decide
tener dos vendedores de billetes. Supongamos que
vendemos entradas telefónicamente para los conciertos de
la siguiente manera: cuando un cliente llama y pregunta
por un número (n) de asiento: 1) el vendedor encuentra los
n mejores asientos que están disponibles, 2) marca los n
asientos como no-disponible, y 3) le ofrece las opciones de
pago: tarjeta de crédito o débito, o la entrega en una
dirección. Supongamos que tenemos más de un vendedor
que trabaja al mismo tiempo, ¿qué problemas se podrían
encontrar, y cómo poder evitarlos? Unos 66 participantes
en cinco instituciones intentaron resolver este problema,
con sorprendente éxito. Como se ve en la Tabla 2, casi
todos los estudiantes reconocieron cuál era el verdadero
desafío del problema, y al 71% se le ocurrió una solución
funcional.
Tabla 2. Problemas y soluciones identificados
Logros % Estudiantes
Problemas identificados:
 Venta de entradas más de una vez 97%
 Otros 41%
Soluciones razonables a los problemas 71%
La mayoría de las soluciones eran ineficientes (porque
ellos mismos eran los solucionadores) así que todavía hay
mucho que estos estudiantes deben aprender. Los
estudiantes pueden ser más capaces de pensar
computacionalmente de lo que se cree. Sin embargo, el
hecho de que puedan resolver problemas de
procesamiento paralelo sugiere que el problema de lograr
que los estudiantes programen puede estar en las
herramientas.
3. Opciones de mejoramiento
3.1 Las herramientas de programación
¿Cómo hacer que las herramientas mejoren? Una posible
respuesta obvia es migrar hacia una notación más visual.
Desde el surgimiento del lenguaje de programación basado
en iconos de David Smith, Pygmalion [21], la teoría ha sido
que el razonamiento visual tal vez es más fácil para los
estudiantes. Ciertamente, ha habido gran cantidad de
estudios que muestran que en general las visualizaciones
ayudaron a los estudiantes en computación [22], pero
relativamente pocos de ellos son cuidadosos.
Thomas Green y Marian Petre [23] hicieron una
comparación entre un lenguaje de programación dataflow-
like y un lenguaje de programación textual. Crearon
programas en dos lenguajes visuales que se había
demostrado que funcionaban bien en estudios anteriores y
en un lenguaje textual que también se había probado. A los
participantes se les mostró un programa visual o un
programa textual por un corto tiempo, y luego se les hizo
una pregunta al respecto, por ejemplo, acerca de los datos
de entrada que se muestran o de los resultados de la salida.
Sin importar cuánta experiencia tuvieran los sujetos con
lenguajes visuales o textuales, o qué tipo de lenguaje visual
se usara, comprender el lenguaje gráfico siempre les tomó
más tiempo, y, en general, comprendieron los lenguajes
visuales más lentamente que los textuales. Green y Petre
publicaron varios trabajos sobre variaciones de este
estudio [24, 25], pero la verdadera prueba llegó cuando
Tom Moher y sus colegas [26] apostaron en favor de los
lenguajes visuales. Tom y sus estudiantes graduados
estaban utilizando una notación visual, Redes de Petri,
para enseñar programación a estudiantes de secundaria.
Consiguieron una copia de los materiales de Green y Petre
y crearon una versión en la que el único lenguaje visual
utilizado fue Petri Nets. Entonces, Tom volvió a ejecutar el
estudio personalmente con sus estudiantes como sujetos.
El sorprendente resultado fue que, de nuevo, los lenguajes
textuales eran más fácilmente comprendidos, sin importar
las condiciones.
¿Estamos equivocados acerca de los lenguajes visuales? En
realidad, ¿la visualización tiende a reducir el
entendimiento del software? ¿Qué pasa con estudios como
los de Naps et al [22]? ¿Estaban equivocados?
Hay un método estándar para comparar múltiples
estudios, llamado meta-estudio. Barbara Kitchenham
describe este procedimiento en su trabajo [27]. Chris
Hundhausen y sus colegas hicieron este tipo de análisis en
estudios sobre la visualización de algoritmos [28].
Encontraron que sí, hay una gran cantidad de estudios que
muestran beneficios significativos para los estudiantes, a
la vez que también hay una gran cantidad de estudios con
resultados no-significativos. Algunos que muestran
resultados significativos no hacen evidente cómo podrían
ayudar realmente (Figura 1). Encontraron que el hecho de
cómo se utilizan las visualizaciones importa mucho. Por
ejemplo, utilizándolas en demostraciones de lectura
tuvieron poco impacto en el aprendizaje del estudiante,
pero al hacer que los estudiantes construyeran sus propias
visualizaciones tuvieron un impacto significativo en su
aprendizaje.
12
10
8
6
4 para hacer el empalme digital. Mediante la eliminación de
2 ojos rojos en una imagen, sin estropear cualquier otro rojo
0 en la misma, se utilizó para iterar a través de un sub-rango
No-significativos Significativos Significativos en Significativos en
análisis visual otra dirección
Figura 1. Resumen de los 24 estudios [28]
Unos pocos estudios variaron el uso de la visualización
mientras mantienen todas las demás variables constantes,
por ejemplo, tipo de curso, tipo de estudiante, profesor,
asignatura. Aunque después de su análisis los autores
sospechan que la forma de visualización que se utilice es
importante, los resultados no son suficientes para probar
su sospecha. Una cosa que enseñan los estudios en
educación es que en realidad es bastante difícil predecir los
resultados. Los seres humanos no son tan predecibles
como un proyectil que cae o un cóctel químico. De hecho,
hay que probar toda sospecha e hipótesis, y, a veces
probarlas varias veces en diferentes condiciones, hasta
que estar convencidos de algún hallazgo.
3.2 ¿Existe otra forma, otras variables?
Lo que sabemos hasta ahora es que los estudiantes en
carreras de computación aprenden mucho menos acerca
de diseño y programación de lo que se podría predecir, y
que fallan el primer curso a un ritmo bastante alto.
Encontramos que el cambio de lo textual a las modalidades
visuales no ofrece consistentemente mejores resultados, lo
que sugiere que otra variable puede estar en juego. Pero,
¿qué otras variables se podrían manipular con el fin de
mejorar el éxito en el aprendizaje de la programación?
En 1999, Georgia Tech decidió exigir computación
introductoria para todos los estudiantes de pregrado.
Durante los primeros años, sólo un curso satisfacía este
requisito, y, en general, el porcentaje de aprobados fue del
78%, que es bastante bueno para el análisis de Bennedsen
y Caspersen [5]. Sin embargo, esa cifra no es tan buena
cuando se empieza a desagregar. La tasa de aprobación
para los estudiantes de Artes Liberales, Arquitectura y
Administración fue inferior al 50% [29]. Las mujeres
fracasaron en casi el doble de la tasa de los hombres. Un
curso dirigido a todos los estudiantes, en el que la mayoría
de hombres en carreras técnicas pasa, pone de relieve
problemas generales en la enseñanza de la computación.
Forte y Guzdial [30] iniciaron en 2003 un experimento
para enseñarles a los estudiantes un tipo diferente de
curso introductorio, contextualizado en torno a la
manipulación de los medios de comunicación. En esencia,
los estudiantes trabajaron los mismos tipos de programas
como en cualquier curso introductorio de Ciencias
Computacionales. De hecho, trataron de cubrir todos los
temas [31] que recomiendan los estándares de ACM e IEEE
vigentes. Sin embargo, para analizar todos los ejemplos de
los libros de texto, el código de ejemplo en las conferencias,
y las tareas los estudiantes debían manipular los medios
digitales. Aprendieron cómo recorrer los elementos de
una matriz, por ejemplo, mediante la conversión de todos
los píxeles de una fotografía en escala de grises. En lugar
de encadenar cadenas, concatenaron buffers de sonido
de una matriz. La respuesta fue positiva y dramática. Los
estudiantes encontraron el nuevo curso más relevante y
convincente, en particular las mujeres cuya tasa de
aprobación se elevó por encima de la de los hombres (pero
no con cualquier significación estadística) [32]. La tasa
media de aprobación en los siguientes tres años se elevó al
85%, incluso a las carreras técnicas en las que no llegaba al
50% por semestre [29].
Suena como un gran éxito, pero, ¿es realmente cierto lo que
dicen? ¿Ese nuevo enfoque es la única cosa que ha
cambiado? Tal vez esas instituciones de repente
comenzaron a aceptar estudiantes mucho más
inteligentes. Quizás Georgia Tech contrató a un nuevo
instructor carismático que hechizaba a los estudiantes con
el cuidado en el contenido. La investigación en las áreas
sociales se refiere a estos factores como una amenaza a la
validez del estudio. En este caso, los investigadores
incluyeron semestres con diferentes instructores y los
resultados abarcan tres años de valor, por lo que es poco
probable que de repente los estudiantes fueran muy
diferentes. ¿Podría ser entonces que el éxito en la
enseñanza de la programación se puede lograr al
introducir los medios en la computación?
La primera prueba de los medios en la computación en una
institución diferente se realizó en Gainesville State College,
en Georgia [33]. Este estudio también encontró mejoras
dramáticas en las tasas de éxito entre los estudiantes, los
cuales provenían de áreas como la informática y la
enfermería. Sin embargo, tanto en Georgia Tech como en
Gainesville los estudiantes eran predominantemente
blancos. ¿Cambiarían en algo los resultados si los
estudiantes fueran de las minorías étnicas? En la
Universidad de Illinois en Chicago (UIC), Pat Troy y Bob
Sloan introdujeron los medios en sus cursos de
computación [34]. Un curso ofrecido a estudiantes que
querían especializarse en Ciencias Computacionales, pero
que no tenían antecedentes en programación. Durante
varios semestres, la tasa de aprobación de estos
estudiantes también aumentó. UIC tiene una población
estudiantil étnicamente diversa, donde la mayoría
pertenece a grupos étnicos minoritarios. Con estos
resultados, ¿es posible generalizar que los medios en la
computación ayudan al aprendizaje de la programación? El
argumento puede ser que éstos siguen siendo casos
inusuales. Los estudios en Georgia Tech y Gainesville eran
adolescentes, mientras que en Chicago se trató de
estudiantes que quieren especializarse y el curso no hace
parte normal de sus carreras de pregrado. Bet Simon y sus
colegas de la Universidad de California (UCSD), en San
Diego, comenzaron a utilizar los medios en los cursos
introductorios de las carreras técnicas [35], y encontraron
que se incrementó el número de estudiantes que aprueban.
¿Eso es todo? ¿Los medios en la computación son la
solución? ¿Todo mundo debería utilizarlos? Aunque
diversos estudios lo han aprobado [36, 37], no están libres
de ambigüedades. En primer lugar, estos autores no han
dicho si los estudiantes aprenden lo mismo con los medios
en la computación que sin ellos. Si alguien afirma que lo ha
logrado con este enfoque es muy escéptico, porque
actualmente no se cuenta con métricas fiables y válidas
para hacer esa afirmación. Allison Tew y su equipo [29, 33]
trataron de responder a la pregunta de si los estudiantes
aprenden lo mismo en diferentes cursos introductorios.
Desarrollaron dos pruebas isomórficas con preguntas de
opción múltiple en cada uno de los lenguajes que querían
comparar: un problema destinado a evaluar un concepto
particular (una iteración sobre una matriz) era
esencialmente el mismo en ambas pruebas y en todos los
lenguajes. Aplicaron estas pruebas antes y después del
curso con el fin de medir la diferencia que había en el
aprendizaje del estudiante. Encontraron que los
estudiantes aprendieron nuevas y diferentes cosas en el
curso de nivel 1, pero que estas diferencias desaparecieron
en el curso de nivel 2. Eso es un gran hallazgo, lo que
sugiere que las diferencias en el nivel 1 no eran tan críticas
para el éxito futuro. Pero en pruebas subsiguientes nunca
encontraron el mismo resultado.
¿Cómo puede ser eso? Una posibilidad real es que las
pruebas no eran exactamente las mismas; los estudiantes
interpretaron de manera diferente; o puede ser que no
midieron exactamente el tipo de aprendizaje que se
pretendía probar. Por ejemplo, tal vez la respuesta a
algunas de las preguntas podría ser adivinada porque los
distractores estaban tan lejos de ser factibles que los
estudiantes los pasaban por alto sin realmente saber la
respuesta correcta. Una buena prueba para medir el
aprendizaje debe ser confiable y válida, en otras palabras,
medir lo correcto, y que los estudiantes la puedan
interpretar de la misma manera todo el tiempo. Por eso es
que hasta el momento no es posible determinar con
certeza que los estudiantes están aprendiendo las mismas
cosas bajo diferentes enfoques. Es muy bueno que los
estudiantes tengan mayor éxito con los medios, y es genial
que a los estudiantes de la UCSD les vaya mejor incluso en
el segundo curso, pero realmente no se puede decir con
seguridad que todos los estudiantes aprenden las mismas
cosas.
En segundo lugar, incluso aunque en Georgia Tech,
Gainesville, UIC, y UCSD fueron capaces de demostrar que
los estudiantes aprendieron lo mismo en el curso
introductorio, ¿qué podría probar todo eso? ¿Que el curso
se debe trabajar personalizado? ¿Que este tipo de curso es
mejor que el tradicional, sin importar el éxito que peste
alcance? ¿Qué funciona para cada tipo de estudiante sin
importar su preparación o interés? ¿Que no importa la
preparación y experiencia del profesor? Por supuesto, todo
esto es ridículo. Siempre se puede imaginar algo que
podría salir mal.
En general, los enfoques curriculares nos ofrecen modelos
prescriptivos, sino teorías predictivas. Los estudios de los
medios en la computación muestran evidencia de que, para
una variedad de estudiantes y profesores, la tasa de éxito
en un curso introductorio se puede mejorar, pero no que
inevitablemente se va a mejorar. Prometer algo así sería
como tener una receta mágica. No es una teoría predictiva
en el sentido de que puede predecir mejoras, pero sin
conocer muchas más variables que aún no han sido
probadas. Tampoco puede ser predictiva porque no es
posible decir que al no usar los medios se garantiza el
fracaso.
4. Conclusiones
La investigación en Educación en Informática, como un
campo de estudio, sigue siendo una disciplina incipiente
[38]. Sólo recientemente nos estamos dando cuenta de la
importancia de calcular la educación y la necesidad de
apoyar la enseñanza en esta área del conocimiento. La
organización Computer Science Teachers Association
(CSTA) de la ACM para el apoyo a los profesores en
Ciencias Computacionales, sólo se conformó en 2005.
Mientras que, por ejemplo, el National Council of Teachers
of Mathematics, se creó en 1920.
La mayoría de estudios en este sentido apuntan más hacia
lo complejo que es para que los humanos aprender a
programar. Seguimos maravillados con la inteligencia y la
creatividad de los seres humanos, y que incluso los
estudiantes sin formación en informática ya puedan
pensar en términos algorítmicos. Sin embargo, el
desarrollo de esa habilidad hasta el punto de que se pueda
utilizar para dar instrucciones a un dispositivo en un
lenguaje máquina se produce más lentamente de lo que se
podría esperar. Podemos lograr que los estudiantes lo
hagan a través del proceso, pero aún no tenemos medidas
efectivas de lo mucho que están aprendiendo. Lo que
realmente necesitamos como campo son teorías
predictivas, basadas en modelos de cómo las personas
realmente desarrollan su comprensión de la informática.
Desde esas teorías se podrían construir planes de estudio
en el que se pueda confiar. Tenemos pocos trabajadores, y
sólo se acaba de empezar en esta difícil tarea. Existen
pocos eventos científicos dedicados a este tipo de
discusiones. Pero, aun así, ya se han dado los primeros
pasos hacia la comprensión de por qué es que a los
estudiantes les resulta tan difícil aprender a programar [9,
10].
Como el mismo profesor Serna lo expresó en La Habana en
2013 [39]: “Somos una Sociedad Software-Dependiente, y
sino empezamos a profesionalizar el desarrollo de estos
productos podríamos avocarnos a una crisis peor que a la
falta de los mismos dispositivos que intentamos
programar”.
Referencias
[1] Vegso, J. (2008). BLS Predicts strong job growth and high
salaries for IT workforce through 2016. Computing
Research News 20(3), pp. 1-1.
[2] Lacey, A. & Wright, B. (2009). Employment outlook: 2008–
18 - Occupational employment projections to 2018.
Monthly Labor Review, November 2009, pp. 82-123.
[3] Rampell, C. (2010). Once a dynamo, the tech sector is slow
to hire. The New York Times, Sept. 7.
[4] Serna M. E. (Ed.). (2013). Manifiesto por la
profesionalización del desarrollo de software. Medellín:
Editorial IAI.
[5] Bennedsen, J. & Caspersen, M. (2007). Failure rates in
introductory programming. ACM SIGCSE Bulletin 39(2), pp.
32-36.
[6] Serna, M.E. (2013). Logic in Computer Science. Revista
Educación en Ingeniería 8(15), pp. 62-68.
[7] Serna, M.E. & Serna, A.A. (2013). Logic in Computer Science.
In Baralt, J. et al (Eds.), XII Conferencia Iberoamericana en
Sistemas, Cibernética e Informática: CISCI 2013. Orlando,
USA.
[8] Serna, M.E & Flórez, O.G. (2013). The logical reasoning as
functional requirement in engineering. In Larrondo, P.M.M.
et al. (Eds.), Eleventh LACCEI Latin American and Caribbean
Conference for Engineering and Technology. Cancún,
México.
[9] Serna, M.E. & Polo, J.A. (2014). Logic and abstraction in
engineering education: A necessary relationship. Revista
Ingeniería Investigación y Tecnología XV(2), pp. 299-310.
[10] Serna, M.E. & Zapata, A.L. (2014). Approach to logic and
abstraction in the engineering training. Revista
Internacional de Educacion y Aprendizaje 2(1), pp. 35-47.
[11] Soloway, E.; Bonar, J. & Ehrlich, K (1983). Cognitive
strategies and looping constructs: An empirical study.
Communications of the ACM 26(11), pp. 853-860.
[12] Johnson, W. & Soloway, E. (1987). PROUST: An automatic
debugger for Pascal programs. In Kearsley, G. (Ed.),
Artificial intelligence and instruction: Applications and
methods, pp. 49-67. Boston: Addison-Wesley.
[13] Spohrer, J. (1992). Marcel: Simulating the novice
programmer. Norwood: Ablex.
[14] McCracken, M. et al (2001). A multi-national, multi-
institutional study of assessment of programming skills of
first-year CS students. ACM SIGCSE Bulletin 33(4), pp. 125-
180.
[15] Bennedsen, J. & Caspersen, M. (2005). An investigation of
potential success factors for an introductory model-driven
programming course. Proceedings of the first international
workshop on computing education research, pp. 155-163.
October 1-2, Seattle, USA.
[16] Lister, R. et al [2004]. A multi-national study of reading and
tracing skills in novice programmers. ACM SIGCSE Bulletin
36(4), pp. 119-150.
[17] Miller, L. [1981]. Natural language programming: Styles,
strategies, and contrasts. IBM Systems Journal 29(2), pp.
184-215.
[18] Pane, J.; Myers, B. & Ratanamahatana, C. (2001). Studying
the language and structure in non-programmers’ solutions
to programming problems. International Journal of Human-
Computer Studies 54(2), pp. 237-264.
[19] Cambria, E. et al (2009). Common Sense Computing: From
the society of mind to digital intuition and beyond. Lecture
Notes in Computer Science 5707, pp. 252-259.
[20] Lewandowski, G., D.J. Bouvier, et al. 2007. Commonsense
computing (episode 3): Concurrency and concert tickets.
Proceedings of the third international workshop on
computing education research, pp. 133-144. September 15-
16, Atlanta, USA.
[21] Smith, D. (1975). PYGMALION: A creative programming
environment. PhD dissertation. Computer Science
Department, Stanford University.
[22] Naps, T. et al (2003). Evaluating the educational impact of
visualization. ACM SIGCSE Bulletin 35(4), pp. 124-136.
[23] Green, T. & Petre, M. (1992). When visual programs are
harder to read than textual programs. In Veer, G. et al (Eds.),
Proceedings Human-Computer Interaction: Tasks and
Organisation, pp. 167-180. July 2-5, Rome, Italy.
[24] Green, T.; Petre, M. & Bellamy, R. (1991). Comprehensibility
of visual and textual programs: A test of “superlativism”
against the “match-mismatch” conjecture. In Koenemann, J.
et al (Eds.), Empirical Studies of Programmers: Fourth
Workshop, pp. 121-146. Ablex.
[25] Green, T. & Petre, M. (1996). Usability analysis of visual
programming environments: A “cognitive dimensions”
framework. Journal of Visual Languages and Computing
7(2), pp. 131-174.
[26] Moher, T. et al (1993). Comparing the comprehensibility of
textual and graphical programs: The case of Petri nets. In
Cook, C.; Scholtz, J. & Spohrer, J. (Eds.), Empirical Studies of
Programmers: Fifth Workshop, pp. 137-161. Ablex.
[27] Kitchenham, B. (2011). What we can learn from systematic
reviews. In Oram, A. & Wilson, G. (Eds.), Making Software -
What really works, and why we believe it, pp. 35-54.
O’Reilly Media.
[28] Hundhausen, C.; Douglas, S. & Stasko, J. (2002). A meta-
study of algorithm visualization effectiveness. Journal of
Visual Languages and Computing 13(3), pp. 259-290.
[29] Tew, A.; Fowler, C. & Guzdial, M. (2005). Tracking an
innovation in introductory CS education from a research
university to a two-year college. ACM SIGCSE Bulletin 37(1),
pp. 416-420.
[30] Forte, A. & Guzdial, M. (2004). Computers for
communication, not calculation: Media as a motivation and
context for learning. Proceedings of the 37th Annual Hawaii
International Conference on System Sciences, pp. 1-10.
January 5-8, Hawaii, USA.
[31] Guzdial, M. (2003). A media computation course for non-
majors. ACM SIGCSE Bulletin 35(3), pp. 104-108.
[32] Rich, L.; Perry, H. & Guzdial, M. (2004). A CS1 course
designed to address interests of women. ACM SIGCSE
Bulletin 36(1), pp. 190-194.
[33] Tew, A.; McCracken, M. & Guzdial, M. (2005). Impact of
alternative introductory courses on programming concept
understanding. Proceedings of the first international
workshop on computing education research, pp. 25-35.
October 1-2, Seattle, USA.
[34] Sloan, R. & Troy, P. (2008). CS 0.5: A better approach to
introductory computer science for majors. ACM SIGCSE
Bulletin 40(1), pp. 271-275.
[35] Simon, B. et al (2010). Experience Report: CS1 for Majors
with Media Computation. ACM Innovation and Technology
in Computer Science Education Conference, pp. 214-218.
June 26-30, Ankara, Turkey.
[36] Guzdial, M. & Ericson, B. (2009). Introduction to Computing
and Programming in Python: A Multimedia Approach.
Pearson Prentice Hall.
[37] Guzdial, M. & Ericson, B. (2009). Problem solving with data
structures using Java: A multimedia approach. Pearson
Prentice Hall.
[38] Fincher, S. & Petre, M. (2004). Computer Science education
research. RoutledgeFalmer.
[39] Serna, M.E. & Serna, A.A. (2013). Fornal Specification in
context – Present and future. Ingeniare - Revista Chilena de
Ingeniería 22(2), pp. 243-256.