De la solución humana al algoritmo formal: puente hacia programar sin programar todavía

Capítulo 9

Tiempo estimado de lectura: 9 minutos

+ Ejercicio

Taller integrador: del escenario real a un algoritmo formal

En este taller vas a completar el “puente” entre una solución humana (lo que harías en la vida real) y un algoritmo formal (lo que otra persona podría ejecutar o implementar después). El objetivo no es programar, sino producir un resultado final preciso, verificable y legible: instrucciones sin ambigüedad, variables definidas, decisiones justificadas y pruebas con casos reales.

Elige 1 de estos escenarios (2–3 opciones)

  • Escenario A: Gestionar tareas del día con prioridades. Tienes una lista de tareas con duración estimada, prioridad, fecha límite y energía requerida (alta/media/baja). Debes planificar el día en bloques, respetando un horario disponible y descansos.
  • Escenario B: Preparar una comida para varias personas con restricciones. Debes planear un menú y una secuencia de preparación para N personas con restricciones (alergias, vegetariano, sin gluten), tiempo máximo y utensilios limitados (por ejemplo, 1 horno y 2 fuegos).
  • Escenario C: Planificar recados optimizando tiempo. Tienes una lista de lugares con horarios de apertura, duración de cada recado, tiempos de traslado aproximados y un punto de inicio/fin. Debes ordenar los recados para terminar antes de una hora límite.

Entrega esperada: (1) definición del problema, (2) entradas/salidas, (3) descomposición, (4) patrones, (5) abstracción, (6) pseudocódigo, (7) diagrama, (8) pruebas. Todo debe poder entenderse sin que la persona conozca tu contexto.

1) Definición del problema (en una frase + restricciones)

Escribe una frase que describa el objetivo y luego lista restricciones y criterios de éxito. Evita frases vagas como “organizar bien” y usa condiciones medibles.

Plantilla

  • Objetivo: “Quiero ____ para ____ de forma que ____.”
  • Restricciones: límites de tiempo, recursos, reglas, preferencias.
  • Criterio de éxito: cómo sabrás que el algoritmo “funcionó”.

Ejemplo (Escenario A)

  • Objetivo: “Quiero generar un plan de tareas para hoy que maximice el cumplimiento de tareas urgentes sin exceder 6 horas de trabajo efectivo.”
  • Restricciones: “Descanso de 10 min cada 50 min; no hacer tareas de energía alta después de las 17:00; algunas tareas requieren internet.”
  • Éxito: “Todas las tareas con fecha límite hoy quedan planificadas o justificadas como imposibles; el plan tiene horarios y duraciones.”

2) Entradas y salidas (contrato del algoritmo)

Define qué información entra y qué debe producirse al final. Esto evita que el algoritmo dependa de “cosas que asumes” pero no declaras.

Checklist de entradas

  • ¿Qué datos mínimos necesitas para decidir?
  • ¿Qué formato tienen (número, texto, lista, tabla)?
  • ¿Qué valores son válidos? (rangos, categorías)

Checklist de salidas

  • ¿Qué debe poder leer otra persona?
  • ¿Qué estructura tendrá? (lista ordenada, tabla, cronograma)
  • ¿Qué haces si no se puede cumplir el objetivo?

Ejemplo de contrato (Escenario C)

ElementoDefiniciónEjemplo
Entrada: lista_recadosLista de recados con lugar, duración y prioridad[{lugar:"Banco", dur:20, prio:3}, ...]
Entrada: horariosHorario de apertura/cierre por lugarBanco: 09:00–14:00
Entrada: trasladosTiempo estimado entre lugaresCasa→Banco: 15 min
Salida: rutaOrden de visitas con horas estimadas09:10 Casa→Banco, 09:25–09:45 Banco...
Salida: pendientesRecados no realizados + motivo“Farmacia: cerrada a la hora disponible”

3) Descomposición (lista de subproblemas con responsabilidad)

Convierte tu escenario en módulos con una responsabilidad clara. La clave aquí es que cada parte sea comprobable por separado.

Continúa en nuestra aplicación.
  • Escuche el audio con la pantalla apagada.
  • Obtenga un certificado al finalizar.
  • ¡Más de 5000 cursos para que explores!
O continúa leyendo más abajo...
Download App

Descargar la aplicación

Plantilla de módulos

  • Preparar datos: normalizar entradas, validar valores, completar faltantes.
  • Generar candidatos: posibles acciones/ordenaciones/menús.
  • Evaluar: puntuar candidatos según criterios.
  • Seleccionar: elegir el mejor bajo restricciones.
  • Construir salida: formatear el plan final y explicar decisiones.

Ejemplo de módulos (Escenario B)

  • Validar restricciones alimentarias por persona.
  • Generar opciones de platos compatibles.
  • Asignar porciones y lista de ingredientes total.
  • Planificar secuencia de cocción considerando utensilios (horno/fuegos).
  • Crear cronograma y lista de compras.

4) Patrones reutilizables (decisiones típicas del escenario)

Identifica 2–4 patrones que se repiten en tu problema y que puedas convertir en reglas. No expliques teoría; escribe reglas concretas.

Patrones sugeridos por escenario

  • Escenario A (tareas): “Primero urgentes”, “Agrupar por contexto (internet/calle)”, “Alternar energía alta y baja”, “Bloques de trabajo con descansos”.
  • Escenario B (comida): “Sustituciones por restricción”, “Paralelizar preparaciones”, “Cuellos de botella por utensilio”, “Preparar primero lo que tarda más”.
  • Escenario C (recados): “Ventanas de tiempo por apertura”, “Agrupar por zona”, “Prioridad vs distancia”, “Evitar idas y vueltas”.

Ejemplo de reglas (Escenario A)

  • Regla 1: Si una tarea vence hoy, su prioridad efectiva aumenta en +2.
  • Regla 2: No programar tareas de energía alta en el último bloque del día.
  • Regla 3: Si dos tareas requieren internet, agruparlas en el mismo bloque para reducir cambios de contexto.

5) Abstracción aplicada (qué ignoras y por qué)

Declara explícitamente qué detalles del mundo real vas a ignorar para que el algoritmo sea manejable, y justifica por qué no rompe el objetivo.

Ejemplos de abstracciones aceptables

  • Escenario C: usar tiempos de traslado aproximados en lugar de tráfico en tiempo real.
  • Escenario B: asumir que los ingredientes están disponibles en una sola compra (o declarar que no optimizas compras).
  • Escenario A: usar duraciones estimadas y permitir un margen de error del 10%.

Formato recomendado

Detalle realCómo lo simplificoJustificación
Tráfico variableTraslados fijos por pares de lugaresPermite planificar; el objetivo es ordenar recados, no predecir tráfico

6) Pseudocódigo (resultado principal: legible e implementable)

Escribe pseudocódigo con: variables definidas, pasos numerados o estructurados, y decisiones justificadas con comentarios breves. Evita “y así sucesivamente”.

Convenciones mínimas

  • Usa nombres claros: tiempo_disponible, lista_tareas, prioridad_efectiva.
  • Define unidades: minutos, horas, porciones.
  • Declara supuestos: “si falta duración, usar 30 min por defecto”.
  • Incluye manejo de casos imposibles: “si no cabe, enviar a pendientes con motivo”.

Plantilla de pseudocódigo (adaptable)

ALGORITMO Planificar(entradas) DEVUELVE (plan, pendientes)  1. Validar entradas (formatos, rangos, campos obligatorios)  2. Normalizar datos (convertir horas a minutos, completar valores faltantes)  3. Calcular métricas (p. ej., prioridad_efectiva, compatibilidad, ventanas de tiempo)  4. Inicializar plan vacío y lista pendientes vacía  5. Mientras queden elementos por asignar y haya tiempo/recursos:       5.1 Generar candidatos válidos (que respeten restricciones)       5.2 Puntuar cada candidato según criterios (explicar fórmula)       5.3 Elegir el candidato con mayor puntuación (desempate definido)       5.4 Añadir al plan y actualizar tiempo/recursos disponibles  6. Para cada elemento no asignado:       6.1 Añadir a pendientes con motivo (sin tiempo, incompatibilidad, fuera de horario, etc.)  7. Devolver plan y pendientes

Ejemplo concreto (Escenario A: tareas del día)

ALGORITMO PlanDia(lista_tareas, hora_inicio, hora_fin) DEVUELVE (cronograma, pendientes)  VARIABLES:     tiempo_total_min = minutos(hora_fin - hora_inicio)     bloque_trabajo = 50     bloque_descanso = 10     energia_max_tarde = "media"  # después de las 17:00     cronograma = []     pendientes = []  1. Para cada tarea en lista_tareas:       1.1 Si tarea.duracion_min no existe: tarea.duracion_min = 30       1.2 tarea.prioridad_efectiva = tarea.prioridad       1.3 Si tarea.fecha_limite == HOY: tarea.prioridad_efectiva += 2       1.4 Si tarea.requiere == "internet" y no hay internet: marcar como no_elegible con motivo  2. Ordenar lista_tareas por (prioridad_efectiva DESC, fecha_limite ASC, duracion_min ASC)  3. tiempo_actual = hora_inicio  4. Mientras tiempo_actual < hora_fin y existan tareas elegibles:       4.1 Seleccionar la primera tarea que:             - quepa antes de hora_fin             - si tiempo_actual >= 17:00 entonces tarea.energia != "alta"       4.2 Si no existe tarea que cumpla: SALIR del bucle  # justificación: evita forzar una tarea incompatible       4.3 Programar tarea en cronograma con (inicio=tiempo_actual, fin=tiempo_actual+duracion)       4.4 tiempo_actual += tarea.duracion_min       4.5 Si han pasado bloque_trabajo minutos desde el último descanso:             añadir descanso de bloque_descanso y actualizar tiempo_actual       4.6 Eliminar tarea programada de lista_tareas  5. Para cada tarea restante:       5.1 Añadir a pendientes con motivo: "no cupo" o "restricción de energía" o "no elegible"  6. DEVOLVER cronograma, pendientes

7) Diagrama (flujo de decisión mínimo)

Representa el flujo principal en un diagrama simple. Puedes usar un diagrama de flujo o una tabla de estados. Aquí tienes una versión textual en formato de diagrama de flujo (puedes copiarla y dibujarla):

INICIO → Validar entradas → Normalizar datos → Calcular métricas →  ¿Hay elementos elegibles y recursos/tiempo?    ├─ NO → Enviar restantes a pendientes → SALIDA (plan + pendientes)    └─ SÍ → Generar candidatos válidos → Puntuar → Elegir mejor → Actualizar recursos/tiempo → (volver a la pregunta)

8) Pruebas (casos que deben pasar + resultados esperados)

Define pruebas como si fueras otra persona verificando tu algoritmo. Cada prueba debe incluir: entradas, resultado esperado y por qué es importante.

Plantilla de caso de prueba

NombreEntradaEsperadoMotivo
Caso 1.........

Ejemplos de pruebas por escenario

  • Escenario A: “Tarea urgente larga que no cabe” → debe ir a pendientes con motivo “no cupo” y no bloquear el resto.
  • Escenario B: “Una persona con alergia a frutos secos” → el menú final no debe incluir ingredientes prohibidos; si no hay alternativa, debe marcarse como imposible con explicación.
  • Escenario C: “Un lugar cierra antes de llegar” → el recado debe reordenarse o quedar pendiente con motivo “fuera de horario”.

Requisitos de legibilidad (lista de verificación antes de entregar)

  • Variables definidas: cada variable tiene significado y unidad (minutos, porciones, prioridad 1–5).
  • Decisiones justificadas: cada regla de selección tiene una razón breve (comentario o nota).
  • Casos límite cubiertos: entradas vacías, tiempos insuficientes, restricciones incompatibles, empates.
  • Salida completa: incluye plan final y lista de pendientes con motivos.
  • Sin ambigüedad: no hay pasos como “organizar”, “optimizar”, “lo mejor”; todo se traduce a una regla o cálculo.

Criterios de evaluación del algoritmo (rúbrica)

CriterioQué se evalúaIndicadores observables
ClaridadQue otra persona pueda seguirlo sin preguntarteVariables definidas, pasos ordenados, decisiones explícitas, salida bien formateada
Cobertura de casosQue maneje situaciones normales y límitesPruebas con casos difíciles, manejo de imposibles, pendientes con motivos
SimplicidadQue no sea más complejo de lo necesarioReglas mínimas suficientes, abstracciones declaradas, sin pasos redundantes
Posibilidad de implementación futuraQue pueda convertirse en código sin reinventarloEntradas/salidas como contrato, pseudocódigo estructurado, criterios de desempate, unidades consistentes

Ahora responde el ejercicio sobre el contenido:

¿Qué elemento asegura que el resultado del algoritmo sea verificable cuando no puede cumplirse el objetivo con las restricciones dadas?

¡Tienes razón! Felicitaciones, ahora pasa a la página siguiente.

¡Tú error! Inténtalo de nuevo.

La salida debe incluir tanto el plan como los elementos no resueltos con una justificación. Esto permite comprobar qué se intentó, por qué no se pudo cumplir y evita ambigüedades en la verificación del algoritmo.

Portada de libro electrónico gratuitaPensamiento computacional desde cero: cómo pensar como programador
100%

Pensamiento computacional desde cero: cómo pensar como programador

Nuevo curso

9 páginas

Descarga la aplicación para obtener una certificación gratuita y escuchar cursos en segundo plano, incluso con la pantalla apagada.