1.02 · Pensamiento Computacional y Resolución de Problemas

🎯 Objetivo de aprendizaje

Al terminar este tema vas a poder:

1. Definir qué es el pensamiento computacional y por qué es la skill más importante de un programador, por encima de cualquier lenguaje.
2. Aplicar los 4 pilares del pensamiento computacional (descomposición, patrones, abstracción, algoritmos) a problemas de la vida cotidiana, no solo de programación.
3. Descomponer un problema complejo en subproblemas más pequeños y resolubles.
4. Reconocer patrones que se repiten en problemas aparentemente distintos.
5. Aplicar la abstracción para ignorar los detalles irrelevantes y concentrarte en lo esencial.
6. Resolver 5 problemas de la vida real usando un proceso explícito de 4 pasos (sin escribir una sola línea de código).

Este tema no tiene código. Es deliberado. La programación sin pensamiento es copiar; el pensamiento sin programación es el cimiento. Hoy cimentamos.

🧠 Teoría y conceptos — 1.2.1 — ¿Qué es el pensamiento computacional?

Una definición que no requiere computadora

Pensamiento computacional es el proceso mental que usamos para resolver problemas de manera sistemática, descomponerlos en partes reconocibles, identificar patrones, descartar lo irrelevante y construir una solución paso a paso.

Lo creó y lo popularizó la científica computacional Jeannette Wing en 2006, en un artículo que se volvió clásico. Su tesis era simple: el pensamiento computacional no es solo para programadores. Es una forma de pensar que debería enseñarse a todos, igual que leer o hacer cuentas.

Wing lo define así:

*"El pensamiento computacional es el proceso de pensamiento involucrado en formular problemas y sus soluciones de manera que las soluciones se representen de forma que pueda ser ejecutada por un procesador de información (humano o máquina)."* — Jeannette Wing, "Computational Thinking", Communications of the ACM, 2006

Traducción: pensar como si le fueras a explicar el problema a alguien (o algo) que sigue instrucciones al pie de la letra, sin asumir nada.

Las tres ideas equivocadas más comunes

Antes de entrar en materia, limpiemos tres confusiones:

Idea equivocada 1: "Pensamiento computacional = programar" Realidad: es al revés. Programar es la forma de expresar el pensamiento computacional, pero puedes pensar computacionalmente sin escribir una línea de código (hoy lo vas a comprobar).

Idea equivocada 2: "Es solo para gente de sistemas o ingeniería" Realidad: cocineros, abogados, médicos, biólogos, economistas lo usan todos los días. Un cocinero que sigue una receta descompone el platillo en pasos; un médico que diagnostica busca patrones en síntomas; un abogado que prepara un caso abstrae los hechos relevantes.

Idea equivocada 3: "Es una habilidad con la que se nace" Realidad: es una habilidad que se entrena, como un músculo. Algunos tienen más facilidad inicial, pero todos pueden mejorarla con práctica deliberada. Este tema es tu primer gimnasio.

Los 4 pilares del pensamiento computacional

Wing identificó 4 procesos mentales que, juntos, componen el pensamiento computacional:

Estos pilares no se usan en orden estricto. En la práctica se entrelazan: descompones un poco, reconoces un patrón, abstraes, escribes unos pasos, vuelves a descomponer, etc. Es un proceso iterativo, no lineal.

Por qué este tema es el más importante del curso

Si solo pudieras aprender una cosa de este manual, que fuera pensamiento computacional. Por encima de C++, por encima de Java, por encima de Python. ¿Por qué?

• La sintaxis se memoriza en 1 semana y se olvida en 1 año si no se usa.
• El pensamiento computacional se queda para siempre, y se aplica a cualquier lenguaje, framework o tecnología que aparezca en los próximos 30 años.
• Las empresas lo evalúan más que la sintaxis. En una entrevista, te van a dar un problema y van a ver cómo piensas, no si recuerdas el orden de los parámetros de una función.
• La IA no lo puede hacer por ti. Copilot, ChatGPT, Claude: todos pueden escribir código, pero ninguno sabe qué problema real tienes que resolver. Esa parte es tuya, y se llama pensamiento computacional.

1.2.2 — Pilar 1: Descomposición: partir el problema hasta que sea trivial

Qué es y por qué es el pilar más básico

Descomponer es dividir un problema grande en subproblemas más pequeños, hasta que cada subproblema sea tan simple que se pueda resolver con una o dos acciones obvias.

MUDARSE DE CASA

├── 1. Planificar la mudanza

│ ├── 1.1. Definir fecha

│ ├── 1.2. Hacer lista de qué se va

│ ├── 1.3. Comprar cajas

│ └── 1.4. Avisar a servicios (luz, agua, internet)

├── 2. Empacar

│ ├── 2.1. Ropa

│   ├── 2.2. Cocina

│ ├── 2.3. Libros

│ ├── 2.4. Electrónicos

│ └── 2.5. Documentos importantes

├── 3. Transportar

│ ├── 3.1. Cargar el camión

│ └── 3.2. Conducir

└── 4. Instalar

├── 4.1. Bajar cajas

├── 4.2. Colocar muebles

└── 4.3. Conectar servicios

Cada subproblema sigue siendo trabajo, pero ninguno es abrumador. Eso es la descomposición.

La regla de "hasta que sea trivial"

Un buen criterio para saber cuándo dejar de descomponer: cuando el subproblema se pueda resolver con una acción que no requiere pensar. En programación, eso se llama función o procedimiento: una pieza de código que hace una sola cosa y la hace bien.

Ejemplo aplicado: planear una cena para 8 personas

Problema grande: "cocinar una cena para 8". Descomposición:

COCINAR CENA PARA 8

├── 1. Decidir menú

│   ├── 1.1. ¿Qué sé cocinar bien?

│ ├── 1.2. ¿Algún invitado tiene restricciones (vegetariano, alergias)?

│ ├── 1.3. ¿Cuánto tiempo tengo?

│ └── 1.4. ¿Cuál es el presupuesto?

├── 2. Hacer lista de compras

├── 3. Comprar ingredientes

├── 4. Preparar con anticipación

│ ├── 4.1. Lo que se puede hacer el día antes (postre, adobos)

│ └── 4.2. Lo que se hace el mismo día (ensaladas, cocción final)

├── 5. Servir

│ ├── 5.1. Poner la mesa

│ ├── 5.2. Servir en orden

│ └── 5.3. Recoger

└── 6. Evaluar

└── 6.1. ¿Qué salió bien? ¿Qué mejoro la próxima vez?

La trampa del "ya lo descompuse suficiente"

El error más común de los principiantes es descomponer solo una vez y decir "listo". Casi siempre, los subproblemas resultantes siguen siendo demasiado grandes. La regla es: si todavía no sabes cómo empezar, sigue descomponiendo.

Una técnica útil es preguntarte: "¿qué necesito saber para empezar esto?" Si la respuesta es "depende de varias cosas", aún no es trivial.

Ejercicio rápido (sin código)

Problema: quieres sacar 7 en el examen final de Algoritmia.

Descomposición:

Sacar 7 en el examen de Algoritmia

├── 1. Diagnosticar mi nivel actual

│ ├── 1.1. ¿Cuánto saqué en los parciales?

│ ├── 1.2. ¿En qué temas me fue mal?

│ └── 1.3. ¿Cuánto tiempo llevo en el curso?

├── 2. Planificar estudio

│ ├── 2.1. Calcular horas necesarias

│ ├── 2.2. Distribuir horas en la semana

│ ├── 2.3. Definir material (libro, videos, apuntes)

│ └── 2.4. Definir técnicas (subrayado, mapas, práctica)

├── 3. Ejecutar

│ ├── 3.1. Repasar teoría

│ ├── 3.2. Resolver ejercicios fáciles

│ ├── 3.3. Resolver ejercicios difíciles

│ └── 3.4. Simulacro de examen

└── 4. Revisar

├── 4.1. ¿Me siento listo?

└── 4.2. ¿Qué tema me falta reforzar?

¿Ves cómo cada subproblema es más pequeño y manejable que el original? Esto es descomposición.

1.2.3 — Pilar 2: Reconocimiento de patrones: ver lo que se repite

Qué es

Reconocer patrones es identificar similitudes entre problemas, o entre partes de un mismo problema, para aplicar la misma solución en lugar de inventar una nueva cada vez.

En programación, los patrones son clave. Si resuelves 100 problemas de "dado un número, decir si es par o impar", el problema 101 te sale solo: ya reconoces el patrón. La operación se llama módulo (% 2 == 0).

Tipos de patrones que vas a encontrar

Cómo se reconoce un patrón: 3 preguntas

Cuando te enfrentes a un problema nuevo, hazte estas 3 preguntas antes de empezar a resolverlo:

1. ¿Esto se parece a otro problema que ya resolví? Si sí, probablemente la misma solución (o parecida) funcione. Ajusta los detalles.
2. ¿Qué partes de este problema se repiten? Si identificas una repetición, probablemente puedas usar un bucle en vez de escribir el mismo código 10 veces.
3. ¿Hay un "tipo" de problema conocido que coincida? Por ejemplo: "necesito procesar varios datos hasta encontrar uno" → es un patrón de búsqueda. "Necesito sumar varios números" → patrón de acumulación.

Ejemplo: tres problemas, un mismo patrón

Problema A: En una lista de 10 calificaciones, ¿cuántos aprobaron (calificación ≥ 7)?

Problema B: En una lista de 20 empleados, ¿cuántos ganan más de $20,000?

Problema C: En una lista de 50 productos, ¿cuántos cuestan menos de $100?

Patrón común: "contar cuántos elementos de una lista cumplen una condición".

Solución general (pseudocódigo):

contador = 0

para cada elemento de la lista:

si elemento cumple la condición:

contador = contador + 1

imprimir contador

Mismo patrón, tres problemas distintos. Cuando reconoces esto, ya no resuelves 3 problemas, resuelves 1 patrón y lo aplicas 3 veces. Eso es lo que hace a un programador eficiente.

La trampa del "parecido pero no igual"

A veces dos problemas parecen iguales pero no lo son. La condición, el rango, el tipo de dato cambia. Hay que validar que el patrón realmente aplica, no solo "más o menos".

Por ejemplo: "contar cuántos números son primos" parece igual que "contar cuántos son pares", pero requiere una sub-verificación adicional (cada número hay que probar si es primo). Es parecido, no idéntico.

1.2.4 — Pilar 3: Abstracción: ignorar lo que sobra

Qué es

Abstracción es identificar y conservar la información esencial de un problema, descartando los detalles irrelevantes para la solución.

Lo mismo pasa con los programas: usas funciones de una librería sin necesidad de saber cómo están implementadas internamente. La función print("Hola") es una abstracción de un proceso muy complejo (que incluye manejo de buffers, codificación de caracteres, drivers de pantalla, etc.).

Por qué la abstracción es difícil al principio

Porque requiere saber qué es importante y qué no, y eso solo se aprende con experiencia y con práctica. El error típico del principiante es incluir TODOS los detalles en su solución, lo que la vuelve ilegible e inmantenible.

Ejemplo: te piden "calcular el promedio de 3 calificaciones". Tu primera solución podría ser:

1. Pedir al usuario la primera calificación
2. Validar que esté entre 0 y 10
3. Verificar que sea un número
4. Guardar el valor en la variable nota1
5. Pedir al usuario la segunda calificación
6. Validar que esté entre 0 y 10
7. Verificar que sea un número
8. Guardar el valor en la variable nota2
9. Pedir al usuario la tercera calificación
10. Validar que esté entre 0 y 10
11. Verificar que sea un número
12. Guardar el valor en la variable nota3
13. Sumar nota1 + nota2 + nota3
14. Dividir entre 3
15. Imprimir el resultado

Eso funciona, pero está mezclando 3 niveles de abstracción:

• Detalles de implementación (líneas 1-12): cómo conseguir los datos.
• Cálculo (líneas 13-14): la esencia del problema.
• Salida (línea 15): cómo mostrar el resultado.

Una versión abstraída sería:

1. Obtener 3 calificaciones del usuario
2. Calcular su promedio
3. Mostrar el promedio

Los detalles de "cómo" se resuelven después. La abstracción te deja ver el qué sin perderte en el cómo.

El arte de nombrar bien

La abstracción se apoya mucho en buenos nombres. Si nombras bien tus variables, funciones y procedimientos, el código se lee solo. Si nombras mal, ni tú lo vas a entender en 6 meses.

En el Tema 1.8 entraremos a fondo en nomenclatura. Por ahora, recuerda: si tienes que explicar qué hace una variable, el nombre es malo.

La abstracción también se aplica a los problemas

Cuando recibes un problema del mundo real, tu primer paso es abstraerlo: ¿qué información me importa? ¿qué detalles puedo ignorar?

Ejemplo: "Ayudo a mi mamá a elegir un plan de celular más barato".

Información esencial:

• Cuánto consume al mes (minutos, datos, mensajes).
• Cuánto paga actualmente.
• Qué planes hay disponibles y sus precios.

Información irrelevante (por ahora):

• El color del celular.
• La marca.
• Si tiene 5G o 4G (a menos que ella lo necesite).

1.2.5 — Pilar 4: Algoritmos: diseñar la solución paso a paso

Qué es un algoritmo (definición formal)

Un algoritmo es una secuencia finita, ordenada y no ambigua de instrucciones que, partiendo de unos datos de entrada, produce unos datos de salida en un tiempo finito.

Las 5 propiedades obligatorias:

Dato histórico: la palabra "algoritmo" viene del matemático persa Al-Juarismi (s. IX), cuyo libro *Al-Kitāb al-mukhtaṣar fī ḥisāb al-jabr wa-l-muqābala* dio origen a la palabra "álgebra" y cuyo nombre latinizado (*Algoritmi*) dio origen a "algoritmo".

Un algoritmo cotidiano: hacer un sándwich

ALGORITMO: Hacer un sándwich de jamón y queso

ENTRADAS: 2 rebanadas de pan, 2 rebanadas de jamón, 2 rebanadas de queso, mantequilla

SALIDA: 1 sándwich armado

PASOS:

1. Sacar la mantequilla del refrigerador
2. Tomar un cuchillo
3. Untar mantequilla en una cara de cada rebanada de pan
4. Colocar una rebanada de pan (con mantequilla hacia arriba) en el plato
5. Poner 2 rebanadas de jamón sobre el pan
6. Poner 2 rebanadas de queso sobre el jamón
7. Poner la otra rebanada de pan (con mantequilla hacia abajo)
8. Cortar el sándwich por la mitad (opcional)

¿Ves? Es un algoritmo. No tiene código, no tiene computadora, pero es programación. Es un procedimiento. Si se lo pasas a otra persona, lo puede ejecutar. Si lo cambias un paso, el resultado cambia.

La diferencia entre un algoritmo y un programa

Un programador profesional siempre escribe el algoritmo ANTES de escribir el programa. El programa es el último paso, no el primero.

El pseudocódigo: el puente entre el algoritmo y el programa

El pseudocódigo es una forma de escribir el algoritmo usando palabras en español (o inglés) pero imitando la estructura de un programa. Es la forma estándar de "explicar el código sin usar código".

Ejemplo del sándwich en pseudocódigo:

INICIO

// Pedir datos al usuario

ESCRIBIR "¿Tienes pan, jamón, queso y mantequilla? (sí/no)"

LEER respuesta

SI respuesta == "no" ENTONCES

ESCRIBIR "Ve a comprar antes de continuar"

TERMINAR

FIN SI

// Preparar ingredientes

mantequilla = sacar_del_refrigerador()

pan1 = tomar_rebanada_de_pan()

pan2 = tomar_rebanada_de_pan()

jamon1 = tomar_rebanada_de_jamón()

jamon2 = tomar_rebanada_de_jamón()

queso1 = tomar_rebanada_de_queso()

queso2 = tomar_rebanada_de_queso()

// Untar

untar(mantequilla, pan1)

untar(mantequilla, pan2)

// Armar

colocar_en_plato(pan1)

colocar_sobre(pan1, jamon1)

colocar_sobre(jamon1, jamon2)

colocar_sobre(jamon2, queso1)

colocar_sobre(queso1, queso2)

colocar_sobre(queso2, pan2)

// Cortar

ESCRIBIR "¿Cortar por la mitad? (sí/no)"

LEER cortar

SI cortar == "sí" ENTONCES

cortar_por_la_mitad()

FIN SI

ESCRIBIR "Tu sándwich está listo"

FIN

Este pseudocódigo lo puedes traducir a C++, Java, Python o cualquier lenguaje. El algoritmo es el mismo; cambia la sintaxis.

1.2.6 — El proceso 4P: una receta para cualquier problema

Los 4 pasos para resolver un problema computacional

Después de estudiar los 4 pilares por separado, los reunimos en un proceso explícito de 4 pasos. Este proceso lo vas a aplicar en CADA práctica de laboratorio del curso, así que memorízalo.

PROCESO 4P para resolver un problema

=====================================

1. PR (Problema): Lee el problema 3 veces. Identifica las entradas y las salidas.
2. DE (Descomposición): Divide el problema en subproblemas más pequeños.
3. PA (Patrón + Abstracción): Identifica si hay un patrón conocido. Decide qué detalles ignorar.
4. AL (Algoritmo): Escribe el pseudocódigo. Traza con datos de prueba. Recién entonces, codifica.

Ejemplo aplicado: "calcular el promedio de N calificaciones de un grupo"

Paso 1 — PR (Problema):

• Leer el problema: "el usuario ingresa N calificaciones de un grupo de alumnos. El programa calcula el promedio general, el número de aprobados (≥ 7) y el número de reprobados (< 7)."
• Entradas: N (cantidad de calificaciones) y luego las N calificaciones (números entre 0 y 10).
• Salidas: promedio, número de aprobados, número de reprobados.
• Casos borde: ¿qué pasa si N = 0? ¿qué pasa si una calificación no está entre 0 y 10?

Paso 2 — DE (Descomposición):

Calcular estadísticas de N calificaciones

├── 1. Pedir N al usuario

├── 2. Validar que N > 0

├── 3. Para i desde 1 hasta N:

│ ├── 3.1. Pedir la i-ésima calificación

│ └── 3.2. Validar que esté entre 0 y 10

├── 4. Calcular el promedio (suma / N)

├── 5. Contar aprobados (cal ≥ 7)

├── 6. Contar reprobados (cal < 7)

└── 7. Imprimir los 3 resultados

Paso 3 — PA (Patrón + Abstracción):

• Patrón: "procesar N elementos uno por uno" → es un patrón de iteración. Usaremos un bucle for o while cuando codifiquemos.
• Abstracción: no nos importa cómo se almacenan las calificaciones internamente. No nos importa si son enteros o decimales. Lo esencial es la lista de números.

Paso 4 — AL (Algoritmo en pseudocódigo):

INICIO

// Paso 1: pedir N

ESCRIBIR "¿Cuántas calificaciones vas a ingresar?"

LEER N

// Paso 2: validar N

SI N <= 0 ENTONCES

ESCRIBIR "N debe ser mayor que 0"

TERMINAR

FIN SI

// Paso 3: pedir las calificaciones

suma = 0

aprobados = 0

reprobados = 0

PARA i DESDE 1 HASTA N HACER

ESCRIBIR "Calificación " + i + ":"

LEER cal

// Validar

SI cal < 0 O cal > 10 ENTONCES

ESCRIBIR "Calificación inválida. Debe estar entre 0 y 10."

i = i - 1 // Reintentar

CONTINUAR

FIN SI

// Acumular

suma = suma + cal

// Clasificar

SI cal >= 7 ENTONCES

aprobados = aprobados + 1

SINO

reprobados = reprobados + 1

FIN SI

FIN PARA

// Paso 4: calcular promedio

promedio = suma / N

// Paso 5: imprimir resultados

ESCRIBIR "Promedio: " + promedio

ESCRIBIR "Aprobados: " + aprobados

ESCRIBIR "Reprobados: " + reprobados

FIN

Trazar con datos de prueba (sin código, a mano en tu cuaderno):

• N = 3, calificaciones: 8, 5, 9.
• Suma: 22. Promedio: 22/3 = 7.33.
• Aprobados: 2 (8 y 9). Reprobados: 1 (5).
• Salida: "Promedio: 7.33 / Aprobados: 2 / Reprobados: 1".

⚠️ Errores típicos — ❌ Errores típicos del razonamiento

Como este tema no tiene código, los errores son errores conceptuales que se van a manifestar más adelante cuando programes. Reconocerlos aquí te va a ahorrar horas de frustración.

Error 1: "Decomponer una sola vez es suficiente"

Idea equivocada: "Dividí el problema en 3 partes, ya está descompuesto, ya puedo programar."

Realidad: casi siempre la primera descomposición es insuficiente. Los subproblemas resultantes siguen siendo demasiado grandes. Hay que descomponer hasta que cada parte sea trivial.

Cómo evitarlo: pregúntate "¿sé cómo empezar este subproblema?". Si la respuesta es "no sé", sigue descomponiendo. Si es "sí, se hace tal cosa", ya es trivial.

Error 2: "Reconocer patrón = copiar la solución anterior sin pensar"

Idea equivocada: "Esto es parecido al problema 3, entonces le copio la misma solución."

Realidad: parecido no es idéntico. Siempre hay que validar que las condiciones del patrón aplican: ¿el rango de valores es el mismo? ¿la condición de término es la misma? ¿el tipo de dato es el mismo?

Cómo evitarlo: antes de aplicar un patrón conocido, hazte 3 preguntas: ¿qué tiene en común? ¿qué tiene diferente? ¿qué parte de la solución original hay que ajustar?

Error 3: "Abstraer es ignorar los detalles importantes"

Idea equivocada: "La abstracción es quitar todo, quedarme con la idea general y ya."

Realidad: la abstracción es quitar lo irrelevante, no lo importante. Si quitas algo esencial, tu solución no va a funcionar. La habilidad está en distinguir lo esencial de lo accesorio.

Cómo evitarlo: antes de descartar un detalle, pregúntate: "¿afecta el resultado de la solución?". Si sí, no es descartable.

Error 4: "Diseñar el algoritmo es opcional, mejor lo hago directo en código"

Idea equivocada: "Para qué escribir pseudocódigo si ya sé programar. Mejor abro el IDE y empiezo a teclear."

Realidad: el pseudocódigo es 5 veces más rápido que el código para detectar errores lógicos. Un error en pseudocódigo se arregla en 10 segundos; un error en código puede tomarte 30 minutos depurando.

Cómo evitarlo: sigue siempre el proceso 4P. El pseudocódigo no es opcional, es obligatorio en este curso.

Error 5: "Si el problema es difícil, debo pensar más, no descomponer más"

Idea equivocada: "Llevo 2 horas atorado en un problema. Voy a seguir pensando más fuerte."

Realidad: si llevas más de 20 minutos atorado, probablemente no has descompuesto suficiente. Vuelve atrás, divide el problema en pedazos más chicos, y ataca los pedazos.

Cómo evitarlo: pon un cronómetro. Si llevas 20 minutos sin avanzar, regresa al paso 2 del proceso 4P (descomposición), no al IDE.

🤖 IA como copiloto — 🤖 AI Mission 1.2 — Resolución asistida con prompts sugeridos

Regla de los 3 minutos (obligatoria): antes de preguntarle a la IA, intenta resolverlo por tu cuenta. Si después de 3 minutos no avanzas, primero relee la teoría, luego consulta tu cuaderno, luego mira ejemplos similares en este manual, luego consulta la IA con los prompts sugeridos.

Lo que la IA NO debe hacer por ti en este tema

• ❌ No debe inventar la descomposición de tus problemas.
• ❌ No debe escribir el pseudocódigo de tu LAB.
• ❌ No debe resolver el cuestionario.
• ❌ No debe corregir tu cuaderno (¡es a mano!).

Lo que SÍ debe hacer

• ✅ Explicarte un concepto que no entendiste con analogías.
• ✅ Ayudarte a verificar si tu pseudocódigo está completo.
• ✅ Darte ejemplos adicionales de un patrón.
• ✅ Criticar tu descomposición (sin darte la respuesta, solo señalando huecos).

Prompts sugeridos

Prompt 1 — Explicar un concepto con analogía:

"Explícame la diferencia entre descomposición y abstracción con una analogía de la cocina. No uses código. Máximo 150 palabras."

Prompt 2 — Verificar pseudocódigo (sin reescribirlo):

"Te voy a pegar mi pseudocódigo de un problema. NO me lo corrijas ni me lo reescribas. Solo dime: (1) ¿tiene pasos ambiguos que un niño de 10 años no entendería? (2) ¿falta algún caso borde? (3) ¿el orden de los pasos es lógico? Sé concreto, máximo 200 palabras."

Prompt 3 — Encontrar el patrón de un problema:

"Te voy a describir un problema de la vida real. NO me des la solución. Solo dime: ¿qué patrón conocido (búsqueda, acumulación, transformación, decisión, repetición) se parece más a este problema? Y ¿qué información es esencial y cuál es irrelevante? Máximo 150 palabras."

Prompt 4 — Crítica de descomposición:

"Te voy a pegar una descomposición que hice de un problema. NO me des la tuya. Solo dime: ¿qué subproblema se queda grande y debería descomponerse más? ¿Cuál se queda demasiado pequeño y sobra? Máximo 100 palabras."

🧪 Laboratorio — 🧪 LAB 1.2 — 5 problemas de la vida real, sin código

Tiempo total: 2 h 30 min | Entregable: cuaderno con 5 problemas resueltos con el proceso 4P.

Regla de oro: no abras la computadora para este LAB. Todo es a mano, en tu cuaderno. La programación sin papel es pilotear sin brújula.

Ejercicio 1 — Hacer un presupuesto mensual (básico, 25 min)

Enunciado. Eres un estudiante que quiere hacer un presupuesto mensual. Tienes $5,000 al mes. Tus gastos fijos son: transporte $800, comida (fuera de la escuela) $1,500, renta (compartida) $1,200. El resto lo repartes entre ahorro, salidas y materiales de estudio. Escribe un proceso 4P que:

• Calcule cuánto te queda después de gastos fijos.
• Te sugiera una distribución del sobrante en 3 categorías (ahorro 50%, salidas 20%, materiales 30%).
• Imprima cuánto le toca a cada categoría.

Pasos sugeridos:

1. Lee el problema 3 veces.
2. Identifica entradas (ingreso, gastos fijos, % de distribución) y salidas (sobrante, monto por categoría).
3. Descompón en 3-4 subproblemas.
4. Identifica el patrón (es transformación aritmética).
5. Escribe el pseudocódigo.
6. Traza con datos: ingreso $5,000, fijos suman $3,500, sobrante $1,500, categorías 750/300/450.

Criterio de éxito: pseudocódigo claro, traza correcta, salida esperada coincide.

Rúbrica (10 pts): descomposición (3 pts) + pseudocódigo completo (4 pts) + traza correcta (3 pts).

Ejercicio 2 — Decidir si comprar o no un producto (intermedio, 30 min)

Enunciado. Un producto cuesta $1,500. Tú tienes $2,000 ahorrados pero también tienes otros compromisos: un examen que requiere material ($300), una salida con amigos ($400) y un fondo de emergencia que quieres mantener en al menos $500. Escribe un proceso 4P que:

• Calcule si puedes comprar el producto.
• Calcule cuánto te quedaría después de la compra.
• Te diga si la compra es "segura", "arriesgada" o "imposible" según te quede más de $500, entre $0 y $500, o menos de $0 respectivamente.

Pasos sugeridos:

1. Lee el problema 3 veces.
2. Identifica entradas y salidas.
3. Descompón.
4. Identifica el patrón (decisión con condiciones múltiples).
5. Escribe el pseudocódigo.
6. Traza con datos.

Criterio de éxito: pseudocódigo maneja los 3 casos correctamente.

Rúbrica (10 pts): 3 pts por cada caso (segura, arriesgada, imposible) + 1 pt por pseudocódigo bien estructurado.

Ejercicio 3 — Encontrar al alumno con mejor promedio (avanzado, 40 min)

Enunciado. Una maestra tiene 5 alumnos. Cada alumno tiene 3 calificaciones. La maestra quiere saber quién tiene el mejor promedio. Escribe un proceso 4P que:

• Lea los 5 alumnos con sus 3 calificaciones.
• Calcule el promedio de cada uno.
• Determine quién tiene el mejor promedio.
• Imprima el nombre del ganador y su promedio.

Pasos sugeridos:

1. Lee el problema 3 veces.
2. Identifica entradas (lista de alumnos y sus calificaciones) y salidas (ganador, promedio).
3. Descompón: pedir datos → calcular promedios → comparar → imprimir.
4. Patrón: acumulación + comparación (similar a "encontrar el máximo").
5. Pseudocódigo.
6. Traza con datos inventados de 5 alumnos.

Criterio de éxito: el pseudocódigo funciona con cualquier cantidad de alumnos (no solo 5).

Rúbrica (10 pts): generalización correcta (no hardcoded a 5) (4 pts) + comparación correcta del máximo (3 pts) + pseudocódigo claro (3 pts).

Ejercicio 4 — Patrón de búsqueda en un problema propio (intermedio, 30 min)

Enunciado. Inventa un problema de tu vida cotidiana donde tengas que buscar un elemento en una lista. Ejemplos válidos:

• Buscar un contacto en la agenda por nombre.
• Buscar un libro en la mochila.
• Buscar la canción con más reproducciones en una playlist.
• Buscar el precio más bajo entre 5 productos.

Aplica el proceso 4P completo a tu problema.

Pasos sugeridos:

1. Elige un problema real (no inventado).
2. Aplica 4P.
3. Traza con datos reales.
4. Pega tu pseudocódigo en el cuaderno y enséñaselo a un compañero o familiar que no sepa programar. Si puede explicarte qué hace, está bien. Si te pregunta "¿y eso qué hace?", hay que mejorar.

Criterio de éxito: la persona no técnica entiende qué hace tu pseudocódigo.

Rúbrica (10 pts): problema real (2 pts) + 4P completo (5 pts) + explicación exitosa (3 pts).

Ejercicio 5 — Explica sin código (avanzado, 25 min)

Enunciado. Sin escribir nada de código ni pseudocódigo, explica con palabras y un dibujo cómo le explicarías a un niño de 10 años los 4 pilares del pensamiento computacional. Usa analogías de su mundo (escuela, videojuegos, deportes, comida).

Pasos sugeridos:

1. Elige 4 analogías (una por pilar).
2. Escríbelas en el cuaderno, una por página.
3. Haz un dibujo simple para cada una.
4. Pide a alguien menor de 12 años que las lea y te diga si las entendió.

Criterio de éxito: las 4 analogías son del mundo de un niño (escuela, juego, comida) y no técnicas.

Rúbrica (10 pts): 2.5 pts por analogía (claridad + pertinencia + dibujo).

🎯 Cierre del tema

Lo que aprendiste hoy:

• El pensamiento computacional es la skill #1, no la sintaxis.
• Los 4 pilares: descomposición, patrones, abstracción, algoritmos.
• El proceso 4P: Problema → Descomposición → Patrón+Abstracción → Algoritmo.
• La diferencia entre algoritmo, pseudocódigo y programa.
• 5 errores conceptuales que te van a ahorrar horas después.

Lo que sigue: en el Tema 1.3 — Algoritmos: concepto, características, tipos y diseño, vas a llevar la teoría a la práctica. Vas a diseñar 10 algoritmos en tu cuaderno, vas a aprender los 3 tipos de algoritmos (secuencial, condicional, repetitivo), y vas a usar la regla de los 3 minutos con la IA para validar tus diseños.

Antes de seguir, asegúrate de tener en tu cuaderno:

• [ ] 5 problemas resueltos con el proceso 4P (LAB 1.2).
• [ ] Pseudocódigo de al menos 3 algoritmos cotidianos.
• [ ] Reflexión: ¿en qué pilar eres más débil? ¿Cuál es tu plan para mejorarlo?
• [ ] Glosario con los términos: descomposición, patrón, abstracción, algoritmo, pseudocódigo, programa, 4P.

XP obtenida al completar este tema: 100 base + 20 por LAB + 20 por Quest = 140 XP. Insignia desbloqueada al cerrar el capítulo: Logic Alchemist (parcial).

*"Un programa sin algoritmo es un grito en el vacío. Un algoritmo sin programa, una idea esperando su hora."* — De la introducción de este manual.

Fin del Tema 1.2

📝 Quest · Cuestionario — 📝 Quest — Reactivos para autoevaluación

Sección A · Opción múltiple

Elige la opción correcta (A, B, C o D). Las respuestas están en la sección Respuestas modelo.

1. ¿Cuáles son los 4 pilares del pensamiento computacional?
   • If, for, while, switch
   • Descomposición, patrones, abstracción, algoritmos
   • Input, output, proceso, memoria
   • HTML, CSS, JS, PHP
2. Si divides un problema grande en partes pequeñas, ¿qué pilar aplicas?
   • Abstracción
   • Patrones
   • Descomposición
   • Algoritmos
3. ¿Qué es la abstracción?
   • Eliminar detalles irrelevantes para enfocarse en lo esencial
   • Escribir código abstracto
   • Clases abstractas
   • Interfaces
4. Identificar que dos problemas se resuelven con la misma estrategia se llama:
   • Descomposición
   • Reconocimiento de patrones
   • Abstracción
   • Refactorización
5. ¿Qué pilar se enfoca en diseñar la secuencia de pasos para resolver un problema?
   • Abstracción
   • Descomposición
   • Algoritmos
   • Patrones
6. La torre de Hanoi se resuelve con:
   • Descomposición
   • Recursión (patrón)
   • Abstracción
   • Iteración simple
7. ¿Por qué es importante el pensamiento computacional?
   • Solo para programadores
   • Para resolver problemas en cualquier disciplina
   • Solo para matemáticos
   • No es importante
8. Un mapa de metro es un ejemplo de:
   • Descomposición
   • Reconocimiento de patrones
   • Abstracción
   • Algoritmos
9. La receta de cocina es similar a:
   • Un programa de computadora
   • Un algoritmo
   • Una abstracción
   • Una clase
10. ¿Cuál es el primer paso para resolver un problema complejo?
    • Programar
    • Descomponerlo en partes
    • Compilar
    • Ejecutar

Sección B · Preguntas abiertas

Desarrolla tu respuesta en al menos 3 líneas. Compara con la respuesta modelo después de escribir.

1. Aplica los 4 pilares del pensamiento computacional para resolver: "Encontrar la ruta más corta entre dos puntos de una ciudad con calles y tráfico variable".
   → Escribe tu respuesta aquí (en tu cuaderno o mentalmente)…
2. ¿Por qué el pensamiento computacional es valioso fuera de la programación? Da 2 ejemplos concretos.
   → Escribe tu respuesta aquí (en tu cuaderno o mentalmente)…
3. Diseña un algoritmo en pseudocódigo para encontrar la palabra más larga de un texto. Aplica descomposición.
   → Escribe tu respuesta aquí (en tu cuaderno o mentalmente)…