Copia la lección y pégala en tu chat para resolver dudas.

Pensamiento analítico: de la suposición a la evidencia

¿Por qué «lo probé una vez en mi pantalla y no dio ningún mensaje de error» es la frase más peligrosa del desarrollo de software? Porque que una operación parezca funcionar en un ejemplo sencillo no demuestra que las reglas del dominio se cumplan, ni que los datos hayan quedado íntegros, ni que el sistema resista un caso imprevisto. En la era del desarrollo asistido por IA, donde generar código plausible es inmediato, analizar consiste en sustituir la confianza ciega por preguntas precisas y evidencia observable.

Objetivos y conocimientos previos

Partiendo de los modelos construidos en los Cursos I a IV, aprenderás a distinguir entre observación verificada, inferencia lógica y suposición oculta, a descomponer una afirmación compleja en partes comprobables y a evitar el sesgo de confirmación al evaluar un sistema.

Qué significa analizar un sistema software

La palabra análisis significa literalmente descomponer un todo complejo en sus partes y relaciones fundamentales para comprender cómo funciona o por qué falla.

Cuando un agente de IA —o un miembro del equipo— te presenta una solución y afirma «el módulo de cobros y reembolsos ya está terminado y funciona», una mirada superficial ve una sola cosa: una pantalla donde aparece un botón que responde al hacer clic. En cambio, el pensamiento analítico descompone esa afirmación en cinco preguntas independientes:

Plano de la lógica (Curso I): ¿Las reglas aplicadas cubren todas las combinaciones de condiciones o tienen contradicciones?
Plano de los datos (Curso II): ¿Se conserva la identidad, la integridad referencial y la atomicidad de la transacción en la base de datos?
Plano de los sistemas (Curso III): ¿Se verifican los permisos en el servidor y la operación es idempotente si la red falla y se reintenta?
Plano de la ejecución (Curso IV): ¿El estado se guarda en almacenamiento persistente o en una variable volátil que desaparecerá al reiniciar?
Plano de la evidencia: ¿Qué prueba concreta demuestra cada uno de los cuatro puntos anteriores?

Hecho verificado, inferencia válida y suposición oculta

Para analizar con rigor cualquier diseño o informe técnico, clasifica cada afirmación en una de estas tres categorías:

Categoría	Definición	Ejemplo en un sistema de reservas o facturación	Cómo debes tratarla
1. Hecho observable (Evidencia)	Algo que se ha medido o comprobado directamente en el estado del sistema.	«Tras enviar dos peticiones simultáneas con el mismo `id_operacion`, consultamos la tabla `Pagos` y existe exactamente 1 registro».	Sirve como base sólida para deducir conclusiones dentro de las condiciones probadas.
2. Inferencia lógica válida	Una conclusión necesaria que se desprende de los hechos y de las garantías probadas de la arquitectura.	«Como la columna `codigo_factura` tiene una restricción de unicidad activa en la base de datos, ninguna transacción podrá insertar dos filas con el mismo código».	Válida siempre que la premisa (que la restricción está realmente activa en esa tabla) sea un hecho verificado.
3. Suposición no declarada (Hipótesis oculta)	Algo que damos por cierto sin haberlo especificado ni comprobado.	«Supongo que el usuario nunca pulsará dos veces seguidas el botón de pagar» o «supongo que el descuento nunca será mayor que el precio».	Fuente principal de errores graves. Debe sacarse a la luz y convertirse en una regla explícita o en una prueba de verificación.

La trampa del «camino feliz» y el sesgo de confirmación

Llamamos camino feliz (happy path) al escenario ideal en el que todo ocurre como nos gustaría: el usuario introduce datos perfectos, tiene saldo suficiente, su conexión a internet no se corta, nadie más compite por el mismo recurso en ese instante y el servidor responde al primer intento.

Cuando probamos un sistema recién creado, nuestro cerebro tiende de forma natural al sesgo de confirmación: hacemos una prueba suave para confirmar que nuestra idea funciona, en lugar de diseñar una prueba exigente para intentar descubrir dónde se rompe.

Contraste entre revisión por apariencia y análisis basado en evidencia

Un agente entrega una funcionalidad e informa: «Todo listo»
¿Cómo evalúas la entrega?
Por apariencia (Sesgo de confirmación)
1. Pruebas un único caso ideal en la interfaz y ves el mensaje «Éxito»
2. Falsa seguridad: los fallos de permisos, concurrencia o datos quedan ocultos hasta que ocurren con usuarios reales
Por análisis y evidencia
1. Examinas qué suposiciones ocultas hay y qué estado persistente cambió realmente
2. Certeza fundada: verificas tanto el caso normal como los rechazos obligatorios y los límites

Principio analítico fundamental: Una funcionalidad no está verificada cuando logras que acepte un caso válido, sino cuando demuestras también que rechaza todos los casos inválidos manteniendo intactas las invariantes del sistema.

Practica

Un agente ha implementado la función «Canjear cupón de descuento en una factura» y te presenta este informe: «Ya funciona perfectamente. He creado el cupón BIENVENIDA de 15 €, lo apliqué a una factura de 100 € de la clienta Ana y en pantalla apareció Total a pagar: 85 €».

Analiza ese informe aplicando la distinción entre hechos, inferencias y suposiciones ocultas:

¿Qué es lo único que demuestra como hecho observable la prueba que hizo el agente? (Fíjate en si siquiera comprobó qué quedó guardado en la base de datos o solo lo que apareció en la pantalla).
Enumera cuatro suposiciones ocultas que ese informe no ha verificado (piensa en qué ocurre si la clienta aplica el mismo cupón BIENVENIDA diez veces seguidas a la misma factura, si lo aplica a una factura de 10 €, si el cupón ya caducó o si la factura ya estaba en estado PAGADA).
Para una de esas suposiciones, redacta qué evidencia observable exigirías ver para darla por verificada.

Criterio de comprensión: debes señalar que ver 85 € en pantalla solo prueba el cálculo visual en el camino feliz de un caso concreto, y debes identificar las suposiciones sobre reutilización múltiple del cupón, tope para no generar importes negativos, vigencia del cupón y estado válido de la factura, exigiendo comprobar el estado persistido en el servidor.

Profundiza con IA

Aquí tienes mi análisis del informe sobre el canje de cupones de descuento: [tu respuesta]. Evalúa si he separado bien el hecho observado de las suposiciones no declaradas. Después, propónme tú un informe breve y muy convincente de otra funcionalidad (por ejemplo, «transferir saldo de regalo entre dos usuarios») que esconda tres suposiciones peligrosas para que yo las detecte.

Siguiente lectura

Una vez que sabemos destapar suposiciones ocultas, necesitamos un método sistemático para no olvidar ninguna al revisar un requisito. ¿Cómo se buscan de forma exhaustiva las fronteras y contradicciones de un problema? Continúa con Especificación, invariantes y análisis de casos límite.