CESBA · Lógica de Programación con AlgoritmosLSC0102 · Ejecutivo · 1.er semestre
Progreso 0%

Sesión 05 · Metodología para resolver problemas I

Definición y análisis del problema

Antes de diseñar un algoritmo debes saber exactamente qué problema estás resolviendo. En esta sesión aprenderás a transformar una situación general en un planteamiento claro, delimitado y verificable, identificando objetivo, datos, restricciones, necesidades y resultados esperados.

Evidencia: formato de análisis del problema
Propósito de aprendizaje

Primero comprender, después resolver

01 · Definir

Expresar claramente qué situación necesita resolverse.

02 · Delimitar

Separar qué forma parte del problema y qué queda fuera.

03 · Analizar

Reconocer datos, necesidades y resultados esperados.

04 · Restringir

Identificar reglas, límites y condiciones que deben respetarse.

Conexión con E‑P‑S

Entrada–Proceso–Salida ayuda a organizar una solución, pero antes necesitas un planteamiento correcto. Si el problema está mal definido, puedes construir un algoritmo perfectamente ordenado que resuelva el problema equivocado.

Principio de la sesión: no empieces preguntando “¿qué código escribo?”. Empieza preguntando “¿qué necesita resolverse exactamente?”.
Recuperación

Conocimientos necesarios

Lectura de aprendizaje

Cómo analizar un problema antes de diseñar la solución

1. Situación problemática

Una situación problemática describe un contexto en el que existe una necesidad, dificultad o diferencia entre lo que ocurre actualmente y lo que debería ocurrir. Ejemplo: “En una biblioteca, los préstamos se registran manualmente y se producen errores al consultar qué libros están disponibles”.

2. Definición del problema

Definir el problema significa redactarlo de manera específica, evitando frases vagas. Una buena definición indica qué ocurre, a quién afecta, qué se necesita obtener y bajo qué contexto.

Vago

“La biblioteca funciona mal.” No indica qué falla ni qué necesita resolverse.

Definido

“Se necesita registrar préstamos y devoluciones para conocer con precisión la disponibilidad de cada libro.”

3. Problema, síntoma y solución no son lo mismo

Problema

Situación que requiere ser resuelta. Ej.: no se conoce con precisión qué libros están disponibles.

Síntoma

Manifestación observable. Ej.: aparecen registros duplicados o usuarios preguntan repetidamente por libros ocupados.

Solución propuesta

Una posible respuesta. Ej.: crear una aplicación. No debe confundirse con el problema mismo.

4. Delimitación

Delimitar significa decidir el alcance del problema. Debemos establecer qué sí será atendido y qué no. Por ejemplo, una primera versión puede gestionar préstamos y devoluciones, pero no compras de libros ni multas automáticas.

5. Objetivo

El objetivo describe el resultado principal que buscamos alcanzar. Debe ser concreto y relacionarse directamente con el problema. Un objetivo útil suele comenzar con un verbo: calcular, registrar, clasificar, convertir, controlar, consultar, determinar o generar.

6. Datos disponibles y datos faltantes

Los datos disponibles son aquellos que ya conocemos o que el usuario puede proporcionar. Los datos faltantes son información necesaria que todavía no tenemos. Detectarlos evita inventar valores o asumir condiciones que nunca fueron indicadas.

7. Necesidades o requisitos

Son acciones o comportamientos que la solución debe permitir. Ejemplos: registrar un préstamo, consultar disponibilidad, almacenar una fecha de devolución o mostrar una confirmación.

8. Restricciones

Una restricción es una condición que limita la solución. Puede indicar rangos válidos, reglas del negocio, capacidad disponible, permisos, tiempo, recursos o condiciones obligatorias. Por ejemplo: “un usuario no puede tener más de tres libros prestados”.

9. Resultado esperado

Indica qué debe obtenerse cuando la solución funciona correctamente. Debe poder verificarse. “Que funcione bien” no es un resultado verificable; “mostrar si el libro está disponible y registrar el préstamo” sí lo es.

10. Supuestos

Un supuesto es algo que aceptamos temporalmente como verdadero porque el problema no lo especifica. Los supuestos deben declararse y no esconderse. Ejemplo: “se supone que cada libro tiene un identificador único”. Más adelante puede ser necesario confirmar ese supuesto.

1. Leer

Comprender el contexto completo.

→
2. Definir

Redactar el problema real.

→
3. Delimitar

Establecer alcance.

→
4. Analizar

Datos, necesidades y restricciones.

→
5. Verificar

Confirmar el resultado esperado.

Evita saltarte etapas: todavía no estamos diseñando la solución técnica. La Sesión 6 abordará diseño, codificación y documentación. Aquí el producto es un análisis sólido del problema.
Ejercicio 1

Problema, síntoma, solución o restricción

Clasifica cada frase. El objetivo es aprender a no confundir lo que ocurre con la forma de resolverlo.

Regla práctica

Si describe lo que falla...

probablemente es problema o síntoma.

Si comienza con “hacer una app...”

probablemente ya estás proponiendo una solución.

Ejercicio 2

¿Qué información falta?

Los siguientes planteamientos están incompletos. Identifica qué pregunta deberíamos responder antes de diseñar cualquier algoritmo.

Ejemplo

Planteamiento: “Calcular el costo de un viaje”.

Información faltante: distancia, consumo o rendimiento del vehículo, costo del combustible y si deben considerarse peajes u otros gastos.

Práctica guiada

Laboratorio de análisis

Caso: Un gimnasio registra la asistencia en hojas de papel. A veces no puede determinar rápidamente cuántos días asistió cada socio durante el mes. Se desea contar con una forma más organizada de registrar y consultar la asistencia.

Autoevaluación del análisis

CriterioPregunta de verificación
Claridad¿Una persona externa entiende qué problema existe?
Neutralidad¿Definiste el problema sin imponer una solución antes de analizar?
Datos¿Identificaste qué información hace falta?
Restricciones¿Reconociste reglas que pueden cambiar la solución?
Resultado¿El resultado esperado puede comprobarse?
Evidencia oficial

Formato de análisis del problema

Trabaja con este caso: una cafetería universitaria recibe pedidos verbalmente y en horas de alta demanda algunos productos se duplican, se olvidan o se entregan a la persona incorrecta. Se necesita mejorar el control de pedidos.

Resumen del análisis

Completa el formato y genera el resumen.

Evaluación de aprendizaje

Comprueba tu comprensión

Reporte de la sesión

Resultados del estudiante

Resultado global
—
Completa las actividades obligatorias.

Perfil de aprendizaje

La evidencia principal es el formato completo de análisis del problema.
Sesión 5 · LSC0102 · Metodología para la solución de problemas I · Definición y análisis.