en busca de una nueva forma de enseñar a …...en busca de una nueva forma de enseñar a programar....

En busca de una nueva forma de enseñar a programar. Yolanda Martínez Treviño

Departamento de Computación Básica Tecnológico de Monterrey

26 de Octubre de 2005

Resumen En el verano de 2003 se diseñó una nueva materia de Computación I que se enfoca

principalmente a la enseñanza de la lógica de programación; en esta materia se utilizó una técnica de solución de problemas que se basó en el uso de algoritmos. Esta versión de la materia se impartió durante 2 semestres; después se sustituyó el uso de algoritmos por el uso de un software para realizar y ejecutar diagramas de flujo y se impartió durante otros 2 semestres.

Como resultado de la investigación que se realizó se puede mencionar que el uso del software de diagramas de flujo ha mejorado el desarrollo de algunas habilidades de programador en los estudiantes. Es importante comentar que lo que ayuda no es el uso de los diagramas de flujo por sí mismos, sino el hecho de poder diseñar una solución a un problema de manera gráfica y sin enfrentarse a la sintaxis de un lenguaje de programación como C++.

Palabras Clave Enseñanza, Computación I, Programación Gráfica, Algoritmos, Programación

Estructurada. Antecedentes En el verano de 2003 el director de carrera de IMT solicitó que se cambiara la materia

Computación I para los alumnos de su carrera, la solicitud específica era que los alumnos que aprobaran el curso fueran capaces de realizar programas con un grado de dificultad mayor al que eran capaces de resolver en ese momento.

Entonces se realizó el diseño de una nueva materia Computación I (C++) en la que se eliminó la parte de programación orientada a objetos y se enfocó la materia al desarrollo de la lógica de programación. La nueva materia sería dirigida también a los alumnos de IFI, IEC e IMD.

También, se realizó una investigación con el fin de saber si el nuevo método de dar la clase realmente conseguía que los alumnos desarrollaran más sus habilidades de programadores comparado con el método que se utilizaba antes.

El estudio se puede estructurar en 2 partes, en la primera parte, que son los primeros 2 semestres, se aplicó el diseño original de la materia, durante el verano del 2004 se incorporó una herramienta automatizada para apoyar el aprendizaje y se aplicó los siguientes 2 semestres, estos últimos 2 semestres se considerarán la segunda parte del estudio.

La intención de este trabajo es presentar los métodos utilizados en la materia, así como los resultados del estudio que se ha realizado durante los últimos 2 años.

Objetivos Los objetivos de la primera parte del estudio son:

• Definir si hay una diferencia entre las calificaciones finales que obtienen los estudiantes al utilizar esté método de enseñanza con respecto a quienes no lo utilizaron, es decir, quienes llevaron la materia antes.

• Verificar si hay diferencia entre los puntajes que obtienen los estudiantes que utilizaron este método con respecto a quienes no lo utilizaron. Esta comparación se hace utilizando una prueba estandarizada que mide ciertas habilidades necesarias para ser programador.

El objetivo de la segunda parte del estudio es:

• Definir si hay diferencia entre los puntajes que obtienen los estudiantes que recibieron la primera versión del método de enseñanza, en el que se utilizaban algoritmos; comparados con los estudiantes que recibieron la segunda versión del método; en el que se utiliza una herramienta que permite realizar y ejecutar diagramas de flujo.

Marco Teórico Al empezar a investigar acerca de cómo mejorar la enseñanza de la programación se

encontró que escribir un programa de computadora es a final de cuentas: escribir en instrucciones específicas una solución que ya se tiene elaborada y las herramientas que tradicionalmente se han utilizado para diseñar la solución que son los algoritmos y diagramas de flujo sirven para clarificar el plan de solución antes de escribir el programa; pero no son útiles para hacer el plan de solución (Lamey, 2002); o sea primero se tiene que diseñar un plan para resolver el problema y después se puede escribir el algoritmo o el programa. Desde mi punto de vista, el grado de dificultad de escribir un programa es equivalente al de escribir el algoritmo o el diagrama de flujo correspondiente, porque es “escribir” en algún lenguaje, un plan de solución que ya se tiene definido.

En base a lo anterior se consideró que se debería trabajar en “La solución de problemas” en general. Al investigar sobre ello se encontró el método de solución de problemas planteado por George Poyla (1965) en el que se habla de los pasos generales para resolver un problema; que son: comprender el problema, diseñar un plan de solución, ejecutar el plan y examinar la solución obtenida.

Otro enfoque que se encontró es el de aprender el concepto primero (DuHadway, 2002); ellos proponen utilizar al inicio del semestre pseudocódigo y algoritmos para que los alumnos primero comprendan los conceptos necesarios para programar y después pasar a la etapa de enseñar el lenguaje de programación en donde se aplican los conceptos aprendidos para resolver problemas.

Un problema que se identificó en base a la experiencia de las maestras que realizamos este diseño es que los alumnos que cursan materias básicas de programación generalmente escriben el programa y lo prueban solamente con 1 juego de datos (generalmente los del ejemplo que viene en la descripción del problema). Y si el programa funciona suponen que el programa ya es correcto.

Método La primera parte del estudio. Las maestras rediseñadoras del curso, la Ing. Yolanda Martínez Treviño y la Ing. Delia

Castro Rojas decidimos que para esta clase nos enfocaríamos en: • Que los alumnos sean capaces de entender y resolver problemas del tipo necesario para

nuestra clase.

• Elaborar ejercicios para que les quede bien claro el funcionamiento de las herramientas computacionales antes de aplicarlas, ya que no es posible utilizar de manera correcta una herramienta si no sabe bien como funciona.

• En reforzar la parte de las pruebas, pidiendo a los estudiantes que diseñaran casos de prueba y prueben el programa de una manera más amplia.

Para poner en práctica los puntos mencionados y como parte del rediseño se desarrolló la

Técnica de Análisis y Diseño (ver anexo 1), en la que el enfoque era ir un paso antes de escribir la solución del problema para tratar de desglosar lo más posible la forma en que se resolverá.

Como parte de la técnica se hizo énfasis en diseñar casos de prueba para el programa y posteriormente probar el programa con dichos casos de prueba.

Al inicio del semestre se pidió a los alumnos seguir al pie de la letra la Técnica, pero conforme avanzó el curso se fue dejando pasos de la técnica de manera opcional hasta llegar a dejar que toda la técnica fuera opcional (excepto hacer los casos de prueba a mano para poder probar el programa al final). Se hizo de esta forma porque aprender a programar es desarrollar una habilidad, y conforme se va desarrollando la habilidad se requiere menos seguir la técnica de manera consciente.

La segunda parte del estudio Durante el verano de 2004 se consiguió un libro que contiene un software llamado “Visual

Logic” que permite realizar diagramas de flujo y ejecutarlos (Crews, 2004). Un diagrama de flujo es una forma gráfica de representar la solución computacional a un problema, con la ventaja de que casi no hay que conocer cuestiones de sintaxis.

Durante los siguientes 2 semestres se utilizó dicho software para realizar el diseño del problema; es decir, se sustituyó el uso de algoritmos por el uso de diagramas de flujo. La enorme ventaja es que los alumnos pudieron ejecutar el diagrama de flujo y ver si lo que plasmaron en el diagrama es lo que pensaron que iba a suceder al ejecutarlo.

Nuestra hipótesis era que al utilizar el software de diagramas de flujo se ganaría mucho más en el desarrollo de las habilidades de solución de problemas y esperábamos encontrar mejores resultados en las pruebas que se aplicaran a partir de ese semestre.

Además de este cambio al curso, se modificó la técnica de análisis y diseño en base a los comentarios de los alumnos y a las observaciones de las maestras tratando de hacerla más clara y fácil de utilizar por los alumnos. La nueva versión de la técnica se puede ver en el anexo 2.

El resto del curso permaneció exactamente igual. Datos de la investigación cuantitativa. Durante los 4 semestres en los que se ha impartido la materia se ha aplicado a los alumnos

3 secciones de la prueba estandarizada “Aptitudes Básicas para Informática“ (De la Cruz, 1992), que mide algunas habilidades para ser programador.

Las secciones que se han aplicado son:

• Completar diagramas de flujo en los que se muestra las habilidades de utilizar instrucciones de decisión y repetición en un lenguaje de programación (sección 6).

• Identificar la ecuación necesaria para dar solución a un problema en base a una descripción (sección 2).

• Encontrar el siguiente número de una serie (sección 4).

La aplicación de la prueba se realizó de esta forma:

Al inicio del semestre Agosto de 2003 se aplicó la prueba a los alumnos de:

• Computación I (C++) • Computación II (C++) que habían tomado el curso Computación I con el método anterior.

Al final del semestre Agosto de 2003 se aplicó la prueba a los alumnos de: • Computación I (C++)

Durante los semestres Enero de 2004, Agosto de 2004 y Enero de 2005 se ha aplicado la prueba al inicio y al final del semestre a los alumnos de la materia Computación I (C++).

Resultados Resultados cuantitativos de la primera parte del estudio Al analizar los datos de la prueba estandarizada (ver anexo 4) se encontró que:

• Los alumnos que tomaron el curso Computación I (C++) mejoran la puntuación obtenida en las 3 secciones de la prueba al final del semestre con respecto al inicio del semestre.

• Los alumnos que aprobaron el curso Computación I (C++) en el semestre Agosto-Diciembre del 2003 obtuvieron mejor puntuación en las 3 secciones de la prueba con respecto a la puntuación que obtuvieron los alumnos de Computación II al inicio del mismo semestre.

Se puede comentar que estos resultados no son concluyentes porque los alumnos con los

que se hace la comparación son los que se inscribieron en la materia de Computación II; sin embargo, estos alumnos no necesariamente llevaron el curso Computación I el semestre anterior y se pudiera argumentar que pudieron haber olvidado el contenido de la materia anterior al llegar al inicio del semestre Agosto 2003.

Con respecto a las calificaciones de los alumnos no se pudo concluir nada; esto se puede explicar porque las calificaciones dependen de una serie de factores durante el semestre y están sujetas al grado de dificultad de los exámenes y ejercicios que los maestros manejen.

Observaciones de la primera parte del estudio Al ir avanzando el semestre nos percatamos de que los alumnos usaban la técnica, pero

preferían no hacerlo, en encuestas o conversaciones con las maestras mencionaban que al inicio les servía para aprender pero después la utilizaban solo porque era un requisito.

También notamos que cuando la técnica se dejó de manera opcional y los alumnos se topaban con un problema complejo (en el que era lógico pensar que la técnica podría ayudarlos) no la trataban de utilizar, mas bien, trataban de encontrar las instrucciones para resolver el problema directamente, y al ir a asesorías si las maestras sugerían utilizar la técnica, ellos prefieren no hacerlo de esa forma.

Discusión de la primera parte del estudio Lo que podemos suponer es que si los alumnos no están utilizando la técnica como es

debido entonces las mejorías encontradas se pueden deber a que en la nueva clase se tiene más

tiempo para dedicar a cada tema, por lo que los alumnos desarrollan mejor las habilidades para resolver problemas de cada tipo.

Resultados cuantitativos de la segunda parte del estudio Con respecto a la prueba estandarizada aplicada durante los semestres Agosto 2004 y Enero

2005 hemos encontrado (ver anexo 5) que los alumnos que toman el curso Computación I (C++):

• Mejoran la puntuación obtenida en la prueba al final del semestre con respecto al inicio del semestre.

• Obtienen mejores resultados en las secciones 4 y 6 con respecto a los resultados obtenidos por los alumnos en los semestres AD03 y EM04. Es importante mencionar que lo que se compara es la mejora de puntuación obtenida al final del semestre con respecto al inicio del semestre.

• No hay diferencia entre la mejoría de los alumnos en la sección 2 de la prueba. Observaciones en cuanto al uso de la técnica Desde mi punto de vista, la técnica de solución de problemas no ha tenido mucho éxito

debido a la falta de interés por parte de los alumnos, esta opinión se generó de platicas informales con los alumnos, en donde, hasta los alumnos que obtienen mejores calificaciones han mencionado que primero realizan el algoritmo o el diagrama de flujo y después llenan el formato de la técnica de Análisis y Diseño porque lo tienen que entregar, y no porque les sea útil.

En los semestres que se utilizaron los algoritmos, a los alumnos no les gustaba la técnica, pero la tenían que utilizar ya que era obligatoria; durante esos semestres se observó que los alumnos que conocían ya algún lenguaje de programación primero desarrollaban el algoritmo y después llenaban el formato; pero había alumnos que no tenían conocimientos previos de programación quienes seguían mejor los pasos de la técnica.

En los semestres en los que se ha utilizado el software “Visual Logic” ha empeorado el uso de la técnica ya que ahora la mayoría se va directamente a realizar el diagrama de flujo y cuando lo terminan toman del diagrama de flujo los datos necesarios para llenar el formato del análisis y el diseño.

Observaciones en cuanto al uso del software Al utilizar el software de diagramas de flujo se observaron las siguientes ventajas:

1. Al usar algoritmos los alumnos muchas veces tenían problemas para entender el pseudocódigo (ver anexo 3) y escribían instrucciones que no eran correctas ya sea porque no existían, porque abrían una instrucción y no la cerraban, porque por ejemplo colocaban varios “else” para un solo “if”, porque cerraban una instrucción que nunca fue abierta, etc. Al utilizar el “Visual Logic” los alumnos no pueden utilizar instrucciones incorrectas ya que el software no lo permite.

2. Los alumnos pueden verificar si su diagrama de flujo funciona o no antes de entregarlo, por lo tanto entregan mejores tareas al tener oportunidad de corregir sus errores; y además su grado de satisfacción con el curso se incrementa, porque ahora pueden ver claramente la razón por la obtienen una cierta calificación.

3. Los alumnos están más motivados a utilizar la herramienta porque pueden ver lo que hace su “programa” y en general prefieren trabajar en la computadora que hacerlo a mano.

4. Es más fácil para el maestro revisar los problemas ya que se puede ejecutar el diagrama y verificar si hace lo que debe hacer; antes se tenía que revisar a mano y hacer los comentarios muy detallados para poder explicar a los alumnos los errores.

Capitalización En base a los resultados de la segunda parte del estudio se puede comentar que el uso del

software “Visual Logic” como herramienta para el aprendizaje de la programación ha incrementado el nivel de las habilidades de programador desarrolladas por los alumnos con respecto a quienes utilizaron algoritmos.

Es importante mencionar que lo que hace la diferencia no es el uso de los diagramas de flujo en sí mismos, sino todo el ambiente que permite primero hacer el diagrama sin preocuparse de la sintaxis ni de tener un ambiente de desarrollo real y después de poder ejecutar el diagrama paso a paso y ver que valores van tomando las variables.

Finalmente se puede comentar que no se ha notado mejoría en los promedios de calificaciones finales de los grupos ni en los porcentajes de alumnos aprobados; lo que se puede deber a que la calificación final de un alumno depende de una serie de instrumentos de evaluación que varían de semestre a semestre y de profesor a profesor.

Fuentes Citadas Crews, Thad and Murphy, Chip. “Programming right from the start with Visual Basic

.NET”, Pearson Prentice Hall. 2004. DuHadway, Linda P, Clyde, Stephen W., Recker, Mimi M. and Cooley, Donald H., "A

Concept-First Approach for Introductory Computer Science Course", Diciembre 2002, The Journal of Computing in Small Colleges , Volume 18 Issue 2

De La Cruz López, Ma Victoria, “Aptitudes Básicas para Informática”, TEA Ediciones, Publicaciones de Psicología Aplicada, 1992.

Lamey, Robert, "Logical Problem Solving, before the flow chart with C++ and Visual Basic Applications", Prentice Hall, 2002

Poyla, George, "Como plantear y Resolver problemas", Trillas, 1965

Anexo 1

Técnica de Solución de Problemas

Análisis del problema

1. Leer y entender el problema o ¿hay alguna palabra o parte del problema que no entienda?

2. Identificar o resultados o meta del problema (subráyalos) o datos constantes (enciérralos en un círculo) o datos a pedir

3. Hacer a mano al menos 2 casos de prueba (detallando cómo se hacen los cálculos).

4. Verificar si se ha resuelto algún problema similar y si se puede utilizar el mismo método para este.

Diseño de la solución

1. Identificar fórmulas/cálculos necesarios: o cálculos que siempre se hacen o cálculos que dependen de una condición

2. Identifica repeticiones o cálculos que se repiten o de qué depende la cantidad de veces que se repite o datos que tengan que ser inicializados antes de la repetición

3. Pensar si existe otra forma de hacer los cálculos, las condiciones o las repeticiones. o ¿es más eficiente?

4. Generalizar los casos de prueba para hacer un plan de solución. o Debes obtener la serie de pasos detallados (con las fórmulas necesarias) para

llegar a la solución a partir de los datos que se piden. 5. Escribir el algoritmo, utilizando los estándares del pseudocódigo, a partir del plan de solución. 6. Probar el algoritmo para los casos de prueba del paso 3 del análisis.

o trata de encontrar algún caso para el que no funcione. Si lo encuentras corrige el algoritmo.

AAnnáálliissiiss ddeell PPrroobblleemmaa Resultados solicitados (Si tienes la redacción subráyalos sino apúntalos)

Datos del problema Datos constantes (Enciérralos en un círculo) Datos a pedir (variables)

Casos de Prueba a mano (detallando cómo se hacen los cálculos)

DDiisseeññoo ddee llaa ssoolluucciióónn Datos a calcular

Cálculos que dependen de una condición

Cálculos que siempre se hacen

Cálculos que se repiten De que depende la cantidad de veces que se repite Datos que tengan que

ser inicializados antes de la repetición

Plan de solución Algoritmo

Prueba del algoritmo:

Anexo 2

Técnica de Solución de Problemas

Análisis del problema

1. Leer y entender el problema o ¿hay alguna palabra o parte del problema que no entienda?

2. Identificar o resultados o meta del problema (subráyalos) o datos a pedir

3. Hacer a mano al menos 2 casos de prueba (detallando cómo se hacen los cálculos).

4. Verificar si se ha resuelto algún problema similar y si se puede utilizar el mismo método para éste.

Diseño de la solución

Generalizar los casos de prueba para realizar los siguientes pasos:

1. Identificar fórmulas/cálculos que dependen de una condición.

2. Identifica repeticiones o fórmulas/cálculos que se repiten o de qué depende la cantidad de veces que se repite (condición de la repetición). o verificar si hay datos que tengan que ser inicializados antes de la repetición.

3. Pensar si existe otra forma de hacer los cálculos, las condiciones o las repeticiones. o ¿es más eficiente?

4. Diseñar la solución, utilizando los diagramas de flujo, a partir de los pasos 1 y 2. 5. Probar el diagrama de flujo para los casos de prueba del paso 3 del análisis.

o verifica que los casos de prueba que estés utilizando sean suficientes para asegurar el buen funcionamiento de tu solución para todos los casos.

11.. AAnnáálliissiiss ddeell PPrroobblleemmaa Resultados solicitados (Si tienes la redacción subráyalos sino apúntalos)

Datos del problema (datos a pedir) Casos de Prueba a mano (detallando cómo se hacen los cálculos)

22.. DDiisseeññoo ddee llaa ssoolluucciióónn Datos a calcular

Cálculos que dependen de una condición

Cálculos que se repiten (escribe las fórmulas)

Condición para la repetición

Verificar si hay variables que inicializar antes de la repetición

3. Diagrama de Flujo 4. Prueba del diagrama de flujo (verificando que las pruebas sean suficientes).

Anexo 3

Formato para el Pseudocódigo Programa Inicio Para indicar el inicio del programa. Fin Para indicar el final del programa. Guardar información Temporalmente Constantes Usar nombres de constantes que contengan

solamente letras mayúsculas. Variables Usar nombres de variables que contengan

solamente letras y números, sin espacios. Recibir información Lee lista donde lista puede ser una o varias variables

separadas por comas. Enviar información Escribe lista donde lista son letreros, variables,

constantes y/o cálculos. Coloca los letreros entre comillas.

Hacer cálculos variable = cálculo Operadores aritméticos:

+ suma - resta * multiplicación / división si son 2 enteros, el resultado es entero si alguno es real, el resultado es real ( ) para indicar el orden de evaluación % residuo de la división entera

Tomar decisiones Si (condición) instrucciones sino instrucciones Fin si

Operadores de relación: > mayor que < menor que >= mayor o igual que <= menor o igual que

NOTA: La parte sino es opcional.

== igual a != diferente de Una condición puede formarse uniendo otras condiciones utilizando las letras y/o. La letra y se usa cuando se desea que ambas condiciones sean verdaderas. La letra o se usa cuando se desea que con cualquiera que sea verdadera se realicen las instrucciones.

Repetir Procesos Repite mientras (condicion) instrucciones Fin repite

Se evalúa la condición, si es verdadera se ejecutan las instrucciones que están después del Repite y antes del Fin Repite. Después se vuelve a revisar la condición y se seguirán ejecutando estas instrucciones mientras la condición sea verdadera. Si la primera vez la condición es falsa nunca se ejecutan las instrucciones que están dentro del ciclo.

Repite instrucciones Mientras (condición)

Se ejecutan las instrucciones, después se evalúa la condición y si es verdadera regresa a ejecutar las instrucciones que están después del Repite. Siempre se ejecutan las instrucciones al menos una vez.

Anexo 4

Comparación de resultados del Test “Aptitudes Básicas para Informática” y calificaciones finales de los cursos Computación I y

Computación II A) Computación I (inicio) vs Computación I (final), SEM2004 Ho: La diferencia promedio entre las puntuaciones obtenidas en el Test por los alumnos de

Computación I al final y al inicio del curso es de 10 puntos. Ha: La diferencia promedio entre las puntuaciones obtenidas en el Test por los alumnos de

Computación I al final y al inicio del curso es mayor a 10 puntos.

Sección Conclusión Figura

Sección 2 La diferencia promedio entre las puntuaciones obtenidas en el Test por los alumnos de Computación I al final y al inicio del curso es mayor a 10 puntos.

A.1

A1. Sección 2 Computación I (Inicio) Computación I (Final)

0 10 20 30 40 50 60 70 80 90 100

Mean 41.427673 Median 40.00 Std Dev 23.35593 Std Err Mean 1.8522458 N 159

0 10 20 30 40 50 60 70 80 90 100


Paired t-Test data: x: s2f in datillos , and y: s2i in datillos t = 2.0657, df = 158, p-value = 0.0202 alternative hypothesis: true mean of differences is greater than 10 95 percent confidence interval: 10.7423 NA sample estimates:

mean of x - y 13.72956

Ho: La diferencia promedio entre las puntuaciones obtenidas en el Test por los alumnos de

Computación I al final y al inicio del curso es de 8 puntos. Ha: La diferencia promedio entre las puntuaciones obtenidas en el Test por los alumnos de

Computación I al final y al inicio del curso es mayor a 8 puntos.



A.2


A.3


0 10 20 30 40 50 60 70 80 90 100


0 10 20 30 40 50 60 70 80 90 100


Wilcoxon signed-rank test data: x: s4f in datillos , and y: s4i in datillos signed-rank normal statistic with correction Z = 1.8838, p-value = 0.0298 alternative hypothesis: true mu is greater than 8


0 10 20 30 40 50 60 70 80 90 100


0 10 20 30 40 50 60 70 80 90 100


Paired t-Test data: x: s6f in datillos , and y: s6i in datillos t = 1.9502, df = 158, p-value = 0.0265 alternative hypothesis: true mean of differences is greater than 8 95 percent confidence interval: 8.492 NA sample estimates: mean of x - y 11.24528

B) Computación I (final – que aprobaron el curso) SEM2004 vs Computación II (Inicio)

SAD2003 Ho: La diferencia promedio entre las puntuaciones obtenidas en el Test por los alumnos de

Computación I (Final – que aprobaron el curso) y las puntuaciones obtenidas por los alumnos de Computación II (Inicio) es de 10 puntos.

Ha: La diferencia promedio entre las puntuaciones obtenidas en el Test por los alumnos de

Computación I (Final – que aprobaron el curso) y las puntuaciones obtenidas por los alumnos de Computación II (Inicio) es mayor a 10 puntos.


Sección 2 La diferencia promedio entre las puntuaciones obtenidas en el Test por los alumnos de Computación I (Final – que aprobaron el curso) y B.1

las puntuaciones obtenidas por los alumnos de Computación II (Inicio) es mayor a 10 puntos.

Sección 4

La diferencia promedio entre las puntuaciones obtenidas en el Test por los alumnos de Computación I (Final – que aprobaron el curso) y las puntuaciones obtenidas por los alumnos de Computación II (Inicio) es mayor a 10 puntos.

B.2

B.1 Sección 2 Computación I (Final – que aprobaron el curso)

Computación II (Inicio)

0 10 20 30 40 50 60 70 80 90 100


0 10 20 30 40 50 60 70 80 90 100


Wilcoxon rank-sum test data: x: S2 with COMPU2 = 1 , and y: S2 with COMPU2 = 2 rank-sum normal statistic with correction Z = 1.7691, p-value = 0.0384 alternative hypothesis: true mu is greater than 10 B.2 Sección 4 Computación I (Final – que aprobaron el curso)


0 10 20 30 40 50 60 70 80 90 100


0 10 20 30 40 50 60 70 80 90 100


Wilcoxon rank-sum test data: x: S4 with COMPU4 = 1 , and y: S4 with COMPU4 = 2 rank-sum normal statistic with correction Z = 2.1122, p-value = 0.0173 alternative hypothesis: true mu is greater than 10 Ho: Las puntuaciones obtenidas en el Test por los alumnos de Computación I (Final – que

aprobaron el curso) son iguales a las puntuaciones obtenidas por los alumnos de Computación II (Inicio).

Ha: Las puntuaciones obtenidas en el Test por los alumnos de Computación I (Final – que

aprobaron el curso) son más altas a las puntuaciones obtenidas por los alumnos de Computación II (Inicio).


Sección 6 Las puntuaciones obtenidas en el Test por los alumnos de Computación I (Final – que aprobaron el curso) son más altas a las puntuaciones obtenidas por los alumnos de Computación II (Inicio).

B.3

B.3 Sección 6 Computación I (Final – que aprobaron el curso)


0 10 20 30 40 50 60 70 80 90 100


0 10 20 30 40 50 60 70 80 90 100


Wilcoxon rank-sum test data: x: S6 with COMPU6 = 1 , and y: S6 with COMPU6 = 2 rank-sum normal statistic with correction Z = 3.3072, p-value = 0.0005 alternative hypothesis: true mu is greater than 0

Anexo 5 I. Computación I, Puntaje Final menos Inicial, análisis de los cambios agrupando la

información por semestres de interés. En este apartado se presentan los resultados para cada una de las secciones, considerando por un lado los resultados obtenidos durante los semestres AD2003 y EM2004; y por el otro, los resultados obtenidos en los semestres AD2004 y EM2005. 1.1 Sección 2 del Test.

321312N =

AD04-EM05AD03-EM04

Pun

taje

Fin

al m

enos

Pun

taje

Inic

ial

100

80

60

40

20

0

-20

-40

-60

Figura 7. Diagramas de caja, de la diferencia en puntaje al Final e Inicio del curso, por semestres

de interés, sección 2 del Test. Tabla 1. Estadística Descriptiva de la diferencia en el puntaje al Final e Inicio del curso.

Sección 2 Estadístico AD03-EM04 AD04-EM05 Mínimo -40.0 -45.0 Máximo 86.0 80.0 Media 14.5 15.4 Mediana 15.0 15.0 Desv. Est. 22.3 22.2 N 312 321

Wilcoxon rank-sum test data: x: S2Dif with GruSem = 1 , and y: S2Dif with GruSem = 2 rank-sum normal statistic with correction Z = -0.4209, p-value = 0.3369 alternative hypothesis: true mu is less than 0

Conclusión No existe diferencia estadística significativa entre los resultados obtenidos en la sección 2 del Test por los alumnos de Computación I de los semestres AD03 y EM04, respecto a los resultados obtenidos por los alumnos en los semestres AD04 y EM05. 2.2 Sección 4 del Test.

321312N =

AD04-EM05AD03-EM04

Pun

taje

Fin

al m

enos

Pun

taje

Inic

ial

100

50

0

-50

-100


de interés, sección 4 del Test. Tabla 2. Estadística Descriptiva de la diferencia en el puntaje al Final e Inicio del curso.

Sección 4 Estadístico AD03-EM04 AD04-EM05 Mínimo -82.0 -65.0 Máximo 70.0 80.0

Media 10.5 13.8 Mediana 7.0 10.0 Desv. Est. 21.2 22.6 N 312 321


Conclusión Sí existe diferencia estadística significativa entre los resultados obtenidos en la sección 4 del Test por los alumnos de Computación I de los semestres AD03 y EM04, respecto a los resultados obtenidos por los alumnos en los semestres AD04 y EM05. Los alumnos de los dos semestres más recientes obtuvieron mejores resultados. 2.3 Sección 6 del Test.

321312N =

AD04-EM05AD03-EM04

Pun

taje

Fin

al m

enos

Pun

taje

Inic

ial

100

50

0

-50

-100


de interés, sección 6 del Test. Tabla 3. Estadística Descriptiva de la diferencia en el puntaje al Final e Inicio del curso. Estadístico Sección 6

AD03-EM04 AD04-EM05 Mínimo -89.0 -65.0 Máximo 80.0 81.0 Media 11.4 14.6 Mediana 11.0 12.0 Desv. Est. 23.4 21.9 N 312 321


Conclusión Sí existe diferencia estadística significativa entre los resultados obtenidos en la sección 6 del Test por los alumnos de Computación I de los semestres AD03 y EM04, respecto a los resultados obtenidos por los alumnos en los semestres AD04 y EM05. Los alumnos de los dos semestres más recientes obtuvieron mejores resultados.

en busca de una nueva forma de enseñar a …...en busca de una nueva forma de enseñar a programar....

Documents