Parte 15 — Arquitectura de sistemas e ingeniería de requisitos

← Parte 14 · Índice completo · Parte 16 →

📥 Descargar: Esta parte en PDF · Manual integral

Nivel: intermedio-avanzado · Clases: 12 · Duración sugerida: 6–8 semanas

Pasar de requisitos ambiguos a arquitecturas comprobables antes de elegir servicios cloud.

Resultados de la parte

Al completar esta parte podrás explicar el dominio con lenguaje independiente del proveedor, implementar sus mecanismos esenciales, diagnosticar fallos y defender decisiones mediante evidencia, costo, seguridad y objetivos de confiabilidad.

Modelo mental

Una arquitectura es un conjunto de decisiones sobre estructuras, interfaces y atributos de calidad, respaldadas por escenarios y evidencia.

Secuencia

Clases

ID	Clase	Laboratorio	Horas
181	Requisitos funcionales, restricciones y atributos de calidad	`architecture`	4
182	Contexto, contenedores, componentes y código con C4	`architecture`	4
183	Acoplamiento, cohesión, modularidad y fronteras	`architecture`	4
184	Arquitectura monolítica, modular y de microservicios	`decision`	4
185	Disponibilidad, confiabilidad y análisis de puntos de fallo	`reliability`	4
186	Capacidad, latencia, throughput y teoría de colas	`performance`	4
187	Consistencia, particiones, relojes y consenso	`distributed`	4
188	Contratos de API, eventos y compatibilidad evolutiva	`api`	4
189	Modelado de amenazas y arquitectura de confianza cero	`security`	4
190	ADRs, fitness functions y gobierno de decisiones	`architecture`	4
191	Architecture review y comunicación con stakeholders	`governance`	4
192	Proyecto: arquitectura completa de CloudShop	`capstone`	8

Evaluación de la parte

35 % laboratorios y evidencia reproducible.
25 % retos verificables.
20 % decisiones y ADR.
10 % seguridad, confiabilidad y costo.
10 % proyecto integrador de la parte.

Se aprueba con 80 % de clases en nivel B o superior y el proyecto integrador reproducible.

Pauta bibliográfica

Software Architecture in Practice — Bass, Clements y Kazman.
Fundamentals of Software Architecture — Richards y Ford.
Designing Data-Intensive Applications — Martin Kleppmann.