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)
| Elemento | Definición | Ejemplo |
|---|---|---|
| Entrada: lista_recados | Lista de recados con lugar, duración y prioridad | [{lugar:"Banco", dur:20, prio:3}, ...] |
| Entrada: horarios | Horario de apertura/cierre por lugar | Banco: 09:00–14:00 |
| Entrada: traslados | Tiempo estimado entre lugares | Casa→Banco: 15 min |
| Salida: ruta | Orden de visitas con horas estimadas | 09:10 Casa→Banco, 09:25–09:45 Banco... |
| Salida: pendientes | Recados 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.
- Escuche el audio con la pantalla apagada.
- Obtenga un certificado al finalizar.
- ¡Más de 5000 cursos para que explores!
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 real | Cómo lo simplifico | Justificación |
|---|---|---|
| Tráfico variable | Traslados fijos por pares de lugares | Permite 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 pendientesEjemplo 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, pendientes7) 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
| Nombre | Entrada | Esperado | Motivo |
|---|---|---|---|
| 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)
| Criterio | Qué se evalúa | Indicadores observables |
|---|---|---|
| Claridad | Que otra persona pueda seguirlo sin preguntarte | Variables definidas, pasos ordenados, decisiones explícitas, salida bien formateada |
| Cobertura de casos | Que maneje situaciones normales y límites | Pruebas con casos difíciles, manejo de imposibles, pendientes con motivos |
| Simplicidad | Que no sea más complejo de lo necesario | Reglas mínimas suficientes, abstracciones declaradas, sin pasos redundantes |
| Posibilidad de implementación futura | Que pueda convertirse en código sin reinventarlo | Entradas/salidas como contrato, pseudocódigo estructurado, criterios de desempate, unidades consistentes |