- 1

Transición de programador empírico a arquitecto de software
02:46 - 2

Análisis de licitaciones con inteligencia artificial
08:48 - 3

Monorepositorios como herramienta de gestión de código fuente
13:00 - 4

Reglas de control de versiones en monorepositorio con trunk-based
05:58 - 5

Behavior Driven Development para alinear equipos técnicos y de negocio
09:25 - 6

Notación estándar C4 para diagramas de arquitectura
08:00 - 7

Generadores de sitios estáticos para documentación de proyectos
04:58 - 8

Uso de herramientas de IA para mejorar arquitectura de software
05:05 quiz de Creando Entornos de Software Saludables
Técnicas pre-mortem y cinco why para prevenir fallos en sistemas
Clase 11 de 29 • Curso de Arquitectura de Software Aplicada
Contenido del curso
- 9

Estructura del archivo Architecture.md para proyectos de software
12:00 - 10

Domain-driven design para sistemas de comercio exterior
06:50 - 11

Técnicas pre-mortem y cinco why para prevenir fallos en sistemas
03:58 - 12

Técnicas de conversación e intervención directa en arquitectura
02:49 quiz de Siguiendo una Arquitectura Limpia
- 19

Diferencias entre mensajes y eventos en arquitectura de servicios
03:36 - 20

Patrón productor consumidor vs fan-in y fan-out en microservicios
03:11 - 21

Manejo de excepciones en el patrón productor-consumidor
02:48 - 22

Patrón comparing consumers para procesamiento en tiempo real
02:28 - 23

Patrón Process Manager para integrar actividades humanas y sistemas
02:33 quiz de Patrones de integración
- 24

Patrones de persistencia: durable state vs event sourcing
08:15 - 25

Máquinas de estado finito en la capa de presentación de software
04:52 - 26

Técnicas SAST, DAST y pen testing para seguridad en software
01:36 - 27

Funciones fitness para evaluar arquitecturas de software
04:20 - 28

Observabilidad en sistemas con OpenTelemetry e ingeniería del caos
04:45
Analizar y anticipar posibles fallos antes de lanzar un sistema es clave para lograr soluciones sólidas y minimizar riesgos en proyectos tecnológicos. En este contenido se exploran técnicas como pre-mortem y cinco why para identificar excepciones, incluyendo aquellas no consideradas en la especificación inicial, con ejemplos prácticos en el contexto de documentación y exportación electrónica.
¿Cómo anticipar problemas no descritos en la especificación original usando pre-mortem?
En proyectos con límites y requisitos muy claros, aun así pueden surgir situaciones no previstas. Para ello, la técnica del pre-mortem ayuda a identificar fallos potenciales desde una fase temprana. Se realiza una reunión en la que participan tanto stakeholders técnicos como no técnicos, con el fin de abordar posibles problemas desde múltiples perspectivas.
En el caso presentado, se documentan las notas de la sesión pre-mortem dentro del repositorio principal. El objetivo va más allá de detectar fallos puramente técnicos. Es fundamental encontrar riesgos de negocio, como puede ser el fallo de una operación de exportación usando factura electrónica. Así, este enfoque interdisciplinario permite prevenir crisis antes de enfrentarlas.
¿Para qué sirve la técnica de los cinco why en la búsqueda de causas raíz en sistemas de exportación electrónica?
La técnica cinco why consiste en preguntar reiteradamente "¿por qué?" sobre un evento problemático, profundizando hasta encontrar la verdadera causa raíz. Por ejemplo, si una operación de exportación falló en aduana porque la factura electrónica fue rechazada, se investiga por qué ocurrió esa discrepancia entre la factura de exportación e importación.
Este proceso revela causas como interpretaciones distintas de las clasificaciones arancelarias, validaciones insuficientes o falta de controles sobre esquemas y datos clave. Gracias a este método, pueden surgir nuevos escenarios y necesidades de negocio no contempladas en el diseño inicial del sistema.
¿Cuáles son las acciones preventivas y aprendizajes derivados de los análisis pre-mortem y post-mortem?
El valor principal de un pre-mortem reside en las acciones preventivas y las lecciones aprendidas. Estas acciones deben documentarse claramente para evitar que las reuniones queden solo como ejercicios teóricos. Sugerencias como agregar validaciones previas, ajustar prioridades en el roadmap o reforzar los esquemas de datos pueden marcar la diferencia.
Además, los análisis post-mortem también permiten obtener aprendizajes explícitos a partir de errores reales ocurridos en producción. El ejemplo de la natación ilustra cómo la revisión de acciones pasadas o la simulación de escenarios incrementa el conocimiento y mejora el desempeño, ya sea previniendo incidentes o aprendiendo de ellos.
¿Has aplicado alguno de estos métodos en tus proyectos? Comparte tu experiencia y ayudemos a fortalecer la prevención de fallos en entornos tecnológicos.