Secuencia didáctica: explorar, programar y depurar con herramientas open source

Área: Tecnología e Informática | Asignatura: Informática

Nivel: Secundaria, 12-15 años | Duración total: 3 horas, 180 minutos

Metodología: Aprendizaje cooperativo con roles rotativos

Producto final: Programa sencillo sobre el uso responsable de recursos tecnológicos en la escuela, elaborado, probado y depurado en un entorno de programación open source o de código abierto disponible en la sala.

Propósito de aprendizaje

Al finalizar la secuencia, los estudiantes, organizados en equipos de tres o cuatro integrantes, compararán al menos dos entornos de programación open source, identificarán sus posibilidades educativas, crearán un programa sencillo con secuencias, variables, condicionales y ciclos, y aplicarán una estrategia de lectura, prueba y depuración para corregir al menos dos errores, documentando los cambios realizados.

Objetivo de aprendizaje SMART

En una sesión de 180 minutos, cada equipo diseñará y presentará un programa funcional denominado Semáforo tecnológico responsable, utilizando un entorno open source disponible, que incluya una secuencia de instrucciones, una variable, un condicional y un ciclo; además, probará el programa con una lista de verificación, corregirá como mínimo dos errores de funcionamiento o de lógica y explicará qué cambios realizó y por qué.

Conceptos clave

• Entorno de programación: aplicación que permite escribir, organizar, ejecutar y revisar instrucciones.
• Open source o código abierto: software cuyo código puede ser estudiado, modificado y, según su licencia, redistribuido bajo determinadas condiciones.
• Instrucción: orden que el programa ejecuta.
• Secuencia: instrucciones organizadas en un orden.
• Variable: espacio que almacena un dato que puede cambiar.
• Condicional: estructura que permite tomar una decisión, por ejemplo: “si ocurre esto, entonces haz aquello”.
• Ciclo: estructura que repite instrucciones.
• Depuración: proceso de localizar, comprender y corregir errores en un programa.

Organización cooperativa

Se forman equipos de tres o cuatro estudiantes. Los roles deben rotar al menos una vez durante la sesión para evitar que una sola persona programe todo el tiempo.

Recursos y preparación

• Sala de computadores, idealmente uno por equipo.
• Entorno previamente instalado o disponible sin conexión: Scratch Desktop, Snap! descargado, o Python con Thonny. Se recomienda utilizar el mismo entorno en todos los equipos cuando sea posible.
• Instaladores guardados en una memoria USB o en una carpeta local para atender problemas de instalación.
• Ficha de comparación de entornos.
• Ficha de algoritmo y diseño del proyecto.
• Tarjetas o lista de errores frecuentes.
• Proyector o computador del docente para demostraciones.
• Cuaderno o documento local para registrar pruebas y depuración.
• Capturas o ejemplos previamente descargados, en caso de fallar la conexión.

Contingencia tecnológica: la actividad no debe depender de internet. Si no es posible instalar o abrir el entorno, los equipos pueden diseñar el algoritmo en papel, utilizar capturas de pantalla y simular la ejecución paso a paso. El docente puede trasladar el código al computador posteriormente para comprobarlo.

Actividad 1. Reconocemos y comparamos entornos de programación open source

Tiempo: 30 minutos

Objetivo parcial: Identificar las características básicas de distintos entornos de programación open source y seleccionar uno considerando facilidad de uso, instalación, accesibilidad y posibilidades educativas.

Materiales: computadores, ficha de comparación, capturas o versiones locales de Scratch Desktop, Snap! y Thonny con Python, proyector.

Pasos

1. Presentación del desafío, 5 minutos.

   Docente: plantea la pregunta: “¿Qué debería tener una herramienta de programación para que una persona que empieza pueda aprender, equivocarse y mejorar sin depender siempre de otra persona?”. Explica brevemente que un entorno open source permite estudiar y modificar su código, de acuerdo con la licencia correspondiente.

   Estudiantes: expresan ideas sobre facilidad de uso, accesibilidad, instalación, funcionamiento sin internet y posibilidades de aprendizaje.

2. Exploración guiada, 10 minutos.

   Docente: muestra o entrega tres opciones: Scratch Desktop, Snap! y Thonny con Python. Señala dónde se crean proyectos, dónde se escriben o ensamblan instrucciones, cómo se ejecuta un programa y dónde aparecen mensajes o resultados.

   Estudiantes: observan, abren el entorno disponible y localizan los botones o áreas principales sin intentar todavía crear el proyecto final.

3. Comparación cooperativa, 10 minutos.

   Docente: entrega una tabla con los criterios de análisis y acompaña a los equipos sin elegir por ellos.

   Estudiantes: completan la tabla y asignan una valoración de 1 a 3 en cada criterio.

4. Decisión argumentada, 5 minutos.

   Docente: solicita que cada equipo justifique qué entorno utilizará y qué dificultad anticipa.

   Estudiantes: seleccionan una herramienta y explican su decisión con dos razones concretas.

Transición: Antes de pasar a la siguiente actividad, verifica que cada equipo haya seleccionado un entorno, pueda abrirlo o tenga una alternativa local, haya identificado cómo ejecutar el programa y haya distribuido los roles.

Actividad 2. Del problema cotidiano al algoritmo y al programa

Tiempo: 50 minutos

Objetivo parcial: Transformar una situación cercana en un algoritmo y representarlo mediante secuencias, variables, condicionales y ciclos.

Situación contextualizada: En la escuela se desea promover el uso responsable de los computadores. El programa mostrará mensajes y recomendaciones según la cantidad de minutos de uso del equipo.

Materiales: computadores con el entorno seleccionado, ficha de diseño, lápiz, proyector y tarjetas con estructuras de programación.

Pasos

1. Comprensión del problema, 8 minutos.

   Docente: presenta el reto: “Crear un programa que reciba o establezca una cantidad de minutos de uso del computador y muestre una recomendación: pausa breve, uso moderado o cierre responsable”. Pregunta qué datos necesita el programa y qué decisiones debe tomar.

   Estudiantes: identifican entrada, proceso y salida. Proponen mensajes relacionados con pausas, cuidado del equipo, privacidad y cierre de sesión.

2. Diseño en lenguaje cotidiano, 12 minutos.

   Docente: orienta la elaboración de un algoritmo sin código. Modela un ejemplo parcial: “Inicio; establecer minutos; repetir la revisión; si los minutos son mayores que...; mostrar mensaje; finalizar”.

   Estudiantes: escriben instrucciones ordenadas y acuerdan al menos dos condiciones. Por ejemplo: si los minutos son menores o iguales a 30, mostrar “Puedes continuar”; si están entre 31 y 60, mostrar “Realiza una pausa”; si superan 60, mostrar “Cierra la sesión y descansa”.

3. Traducción al entorno, 20 minutos.

   Docente: realiza una demostración breve de cómo crear una variable llamada minutos, cómo asignarle un valor, cómo incorporar un bloque condicional y cómo repetir una acción mediante un ciclo. En Python, puede mostrar:

   minutos = 45

   if minutos <= 30:

       print("Puedes continuar cuidando el equipo")

   elif minutos <= 60:

       print("Realiza una pausa breve")

   else:

       print("Cierra la sesión y descansa")

   Estudiantes: construyen o escriben el programa, prueban inicialmente un valor de 20, 45 y 75 minutos y registran qué mensaje aparece.

4. Revisión entre equipos, 10 minutos.

   Docente: organiza una revisión cruzada. Cada equipo observa el algoritmo de otro equipo y responde: “¿Se entiende el orden?”, “¿La variable cambia o se mantiene fija?”, “¿Se prueban todos los casos?”.

   Estudiantes: explican su algoritmo, reciben una sugerencia y realizan un ajuste si es necesario.

Transición: Antes de pasar a la siguiente actividad, verifica que cada equipo tenga un programa que se ejecute al menos una vez, que incluya una variable y una decisión, y que haya sido probado con tres valores diferentes. Si un equipo no logra configurar el entorno, debe conservar su algoritmo y trabajar con una versión local o una simulación en papel.

Actividad 3. Probamos, interpretamos errores y depuramos

Tiempo: 40 minutos

Objetivo parcial: Aplicar una estrategia sistemática para leer mensajes de error, localizar su causa, corregir el programa y comprobar nuevamente su funcionamiento.

Materiales: computadores, ficha de depuración, lista de errores frecuentes y programas de los equipos.

Estrategia “LEE–LOCALIZA–CORRIGE–PRUEBA”

• Lee: observa el mensaje o el comportamiento inesperado sin borrar inmediatamente el código.
• Localiza: identifica la línea, bloque, variable o condición relacionada.
• Corrige: modifica una sola cosa cada vez y explica la razón.
• Prueba: ejecuta nuevamente con un caso conocido y con un caso diferente.

Pasos

1. Demostración docente, 8 minutos.

   Docente: muestra un error intencional. En un entorno de bloques puede quitar una instrucción, cambiar el nombre de una variable o invertir una condición. En Python puede mostrar un paréntesis faltante, una variable escrita de dos formas o una indentación incorrecta. Explica que un error no significa “fracaso”, sino información para revisar el programa.

   Estudiantes: predicen qué ocurrirá, señalan la posible causa y proponen una corrección.

2. Depuración por parejas dentro del equipo, 20 minutos.

   Docente: entrega o proyecta una lista de situaciones para probar: minutos igual a 0, 30, 31, 60, 61 y un valor negativo. Formula preguntas antes de intervenir: “¿Qué esperaban que ocurriera?”, “¿Qué ocurrió realmente?”, “¿En qué parte se separan ambas respuestas?”.

   Estudiantes: prueban el programa, registran dos errores o comportamientos inesperados, localizan la causa, efectúan una corrección y vuelven a probar. El controlador y el probador intercambian funciones.

3. Registro de depuración, 7 minutos.

   Docente: revisa que los equipos no se limiten a copiar una solución. Solicita que expliquen el razonamiento.

   Estudiantes: completan un registro como el siguiente:

   Prueba realizada	Resultado esperado	Resultado obtenido	Causa probable	Corrección
   minutos = 61	Mostrar mensaje de cierre	Mostrar mensaje de pausa	Condición escrita como menor que 60	Cambiar el límite y volver a probar

4. Explicación breve, 5 minutos.

   Docente: invita a dos equipos a compartir un error y la estrategia usada para corregirlo.

   Estudiantes: explican el error sin atribuir culpas y describen la evidencia que les permitió encontrarlo.

Transición: Antes de pasar a la actividad final, verifica que cada equipo haya registrado al menos dos pruebas, una corrección justificada y una nueva ejecución exitosa. También confirma que todos los integrantes puedan señalar dónde están la variable, el condicional y el ciclo.

Actividad 4. Proyecto colaborativo y comunicación del resultado

Tiempo: 50 minutos

Objetivo parcial: Mejorar el programa inicial y comunicar de manera clara su propósito, funcionamiento, errores corregidos y uso responsable del entorno open source.

Materiales: computadores, programa de cada equipo, ficha de presentación, lista de verificación y proyector.

Condiciones del producto final

• El programa debe abordar una situación cercana relacionada con el uso responsable de la tecnología escolar.
• Debe incluir una secuencia clara de instrucciones.
• Debe utilizar al menos una variable.
• Debe incluir una estructura condicional con dos o más posibilidades.
• Debe utilizar un ciclo o repetición con un propósito comprensible.
• Debe ejecutarse con al menos tres casos de prueba.
• Debe incluir una recomendación sobre privacidad, cuidado del equipo, pausas activas, cierre de sesión o uso responsable de recursos digitales.
• El equipo debe indicar el nombre del entorno utilizado y reconocer que se trata de una herramienta abierta o de código abierto, sin afirmar que todo software gratuito es necesariamente open source.

Pasos

1. Mejora del proyecto, 25 minutos.

   Docente: acompaña mediante preguntas y evita tomar el teclado. Sugiere que los equipos incorporen una segunda interacción, por ejemplo, pedir un nombre de usuario ficticio, mostrar una recomendación final o permitir que el programa se repita.

   Estudiantes: mejoran el programa, rotan los roles y agregan comentarios o anotaciones que expliquen las partes principales. No deben utilizar datos personales reales.

2. Prueba final, 10 minutos.

   Docente: entrega la lista de verificación y solicita que otro integrante que no programó originalmente ejecute las pruebas.

   Estudiantes: comprueban el programa con tres o más valores, revisan límites como 30, 31, 60 y 61 minutos, corrigen los últimos errores y guardan una copia local.

3. Presentación relámpago, 10 minutos.

   Docente: organiza presentaciones de un minuto por equipo o una galería de proyectos. Solicita que la explicación incluya problema, estructura utilizada, error corregido y razón para elegir el entorno.

   Estudiantes: presentan el programa y responden una pregunta de sus compañeros.

4. Retroalimentación, 5 minutos.

   Docente: destaca estrategias de cooperación, lectura de errores y mejora del algoritmo, no solamente el resultado visual.

   Estudiantes: ofrecen una fortaleza y una sugerencia respetuosa a otro equipo.

Cierre y evaluación formativa

Tiempo incluido en la actividad 4: 5 minutos finales.

Los estudiantes responden individualmente en su cuaderno o ficha:

• ¿Qué diferencia hay entre ejecutar un ejemplo y diseñar un algoritmo propio?
• ¿Qué mensaje de error o comportamiento inesperado apareció y cómo lo interpretamos?
• ¿Qué estructura de programación comprendí mejor: secuencia, variable, condicional o ciclo? ¿Por qué?
• ¿Cómo contribuyó mi rol al trabajo del equipo?
• ¿Qué debemos considerar para usar una herramienta open source de manera responsable?

Criterios de evaluación

Lista de verificación del producto final

• □ El programa abre y se ejecuta en el entorno elegido.
• □ Presenta una situación cercana a los estudiantes.
• □ Contiene instrucciones ordenadas.
• □ Usa una variable llamada o equivalente a minutos.
• □ Incluye una condición con diferentes respuestas.
• □ Incluye una repetición o ciclo funcional.
• □ Fue probado con al menos tres valores.
• □ Se corrigieron y registraron al menos dos errores.
• □ Todos los integrantes pueden explicar una parte del programa.
• □ El programa promueve un uso responsable de la tecnología.