Una sola plataforma para entender y defender todo el proyecto: el enunciado, el SRS, el SAD con el modelo 4+1, el ATAM y los diagramas. Cualquier ID que veas en naranja (por ejemplo DA-ARQ-07) se puede tocar para ver qué significa en los documentos.

Las cinco responsabilidades esenciales (SRS 2.1)

Los números que tienes que saber de memoria

Cómo se conectan los documentos

La columna vertebral es la trazabilidad: cada decisión del SAD cita un atributo del SRS (RST-008) y el ATAM recorre esa cadena en sentido inverso. En la sección Trazabilidad puedes navegarla.

Todo lo que el jurado da por sabido. Cada concepto trae una analogía y dónde aparece en la PGDR.

Conceptos de arquitectura

Clasificación de criticidad: C1, C2 y C3

Es la idea más reutilizada del proyecto (SRS 5.1). No todo merece la misma protección: los umbrales, los compartimentos y el orden de degradación salen de aquí.

Patrones y tácticas que usa la PGDR

Estas tarjetas son tu glosario técnico. Si entiendes estas veinte ideas, entiendes el SAD.

Texto para decir, casi literal: decisiones, seguridad, resiliencia, escalabilidad y ATAM. Cada diapositiva trae las cifras que debes soltar y las preguntas obvias con su respuesta. Usa Modo lectura para ver solo el texto en letra grande y el cronómetro para ensayar a tiempo.

Plataforma para la Gestión de Desastres y Reconstrucción. El objetivo no es replicar Sahana Eden ni desarrollar un sistema completo de emergencias, sino diseñar y justificar una arquitectura que resuelva los desafíos del dominio.

§1–§3 Contexto, problema y objetivo

En escenarios de gran escala aparecen seis desafíos: interoperabilidad entre sistemas, disponibilidad en situaciones críticas, escalabilidad ante picos repentinos, procesamiento en tiempo real, tolerancia a fallos y trazabilidad de la recuperación y la reconstrucción.

La organización ya tiene ocho sistemas independientes, cada uno con su tecnología y su mecanismo de integración:

El ejemplo del enunciado: el sistema de emergencias sabe que una zona está afectada, el GIS conoce su ubicación, un hospital sabe cuántas personas atendió y otro sistema sabe qué recursos hay. Nadie tiene la visión unificada. Objetivo general: una arquitectura altamente disponible, escalable e interoperable para el ciclo completo del desastre. (IE-018, el proveedor de identidad, lo agregó el equipo en el SRS.)

§4 Alcance funcional

§5 Escenarios de funcionamiento

Reprodúcelos paso a paso en Simuladores.

§6 Atributos de calidad prioritarios

§8 Restricciones · §9 Soluciones existentes · §10 Entregables

Las nueve restricciones del §8 quedaron en el SRS como RST-001 a RST-009. La más importante para defender el formato de la entrega es la última: no se impone tecnología y esta entrega es agnóstica. El §9 pide analizar Sahana Eden (capacidades, componentes, tecnologías, integración, fortalezas, limitaciones, decisiones) y proponer una arquitectura alternativa o complementaria.

El SRS convierte el enunciado en 306 elementos verificables. Sigue la norma ISO/IEC/IEEE 29148 y el modelo de calidad ISO/IEC 25010.

Convenciones: cómo leer cualquier ID

Formato <TIPO>-<MÓDULO|ATRIBUTO>-<NNN>. Los identificadores son únicos, inmutables y no se reutilizan; si un requisito se elimina, queda marcado OBSOLETO.

Reglas de redacción: verbos normativos DEBE (obligatorio), DEBERÍA (recomendado; su omisión se justifica por escrito) y PODRÁ (opcional). Un requisito equivale a un comportamiento. Están prohibidos los términos no medibles (rápido, amigable, robusto). Cada requisito lleva criterio de verificación, prioridad A (Must), M (Should) o B (Could), y Origen: la sección del enunciado o "Derivado", indicando de qué deriva.

Alcance y exclusiones

Actores (13)

El ambiente operativo (AMB-01 a 05) incluye navegadores con conectividad estable, móviles con conectividad intermitente o nula, externos heterogéneos fuera de control, operación 24×7 con picos impredecibles y datos personales sensibles.

Diagrama de contexto

Muestra la PGDR como una caja negra con los 11 actores humanos y los sistemas externos. Las flechas indican la información que entra y sale. IE-013, IE-015 e IE-016 son bidireccionales; IE-017 y ACT-13 solo reciben.

Los 14 módulos funcionales y sus 184 requisitos

Explora cada requisito con su criterio de verificación. Filtra por módulo o busca texto:

Atributos de calidad (66)

Cada uno con métrica, umbral, condición de medición, método de verificación, prioridad y origen. Filtra por atributo:

Reglas de negocio, restricciones y supuestos

Reglas de negocio (15)

Las más preguntadas: RN-003 (el evento automático nace preliminar), RN-007 (nunca se sobrescribe el histórico), RN-008 (solo cuentan las evaluaciones validadas), RN-009 (no asignar dos veces la misma unidad), RN-013 (idempotencia por id de dispositivo) y RN-014 (auditoría inmutable).

Restricciones (12) con su impacto arquitectónico

Supuestos (8) y el riesgo si fallan

Interfaces externas

Nació en Sri Lanka tras el tsunami de 2004. Es un kit de desarrollo rápido de aplicaciones humanitarias, con licencia MIT, desplegado en Haití, Pakistán, Venezuela, Colombia, Japón y Chile. Desde mayo de 2025 la rama principal es Eden ASP, reducida a gestión de casos; la versión completa quedó como Sahana EDEN Legacy.

Componentes y tecnología

Integración en Eden

REST derivado del esquema de tablas (síncrono), S3XML con traducción por XSLT, sincronización por lotes entre instalaciones de Eden, mensajería multicanal con SAMBRO (CAP 1.2) y cliente móvil con sincronización posterior. Intentó adoptar la familia EDXL y el desarrollo se detuvo porque los clientes lo encontraron demasiado complejo; solo CAP logró adopción amplia. De ahí sale RF-INT-005: cada integración declara su formato en lugar de imponer uno solo.

Cobertura por módulo

Cobertura alta en GEO, GPA, GRE, NOT y SEG. Parcial en ADM (configuración en código), GDE (sin ciclo de vida configurable), EVD (sin versionado íntegro), MOV (sin política de conflictos), COR (sin vista consolidada), INT, REC (sin la cadena daño→proyecto→presupuesto), VIS (sin vista pública independiente) y AUD (sin inmutabilidad verificable).

Limitaciones y cómo responde la PGDR

Eden se diseñó como aplicación que una organización despliega por su cuenta; la PGDR es una capa de coordinación entre sistemas que ya existen. De esa diferencia salen casi todas las limitaciones.

Decisiones de Eden: qué adoptamos y qué descartamos

Comparación con otras plataformas

Las vistas lógica y de escenarios se derivan casi literalmente del SRS. Las de procesos, desarrollo y física contienen decisiones derivadas: propuestas que satisfacen los atributos, marcadas con D en la trazabilidad. Ningún diagrama nombra productos (RST-009).

Correspondencias entre vistas

Esto es lo que convierte cinco diagramas en un modelo 4+1. No hay correspondencia 1:1 entre lógica y desarrollo ni entre procesos y física, como anticipa el propio Kruchten.

Ocho diagramas del proyecto generados con Archify a partir de especificaciones JSON y validados con sus propias reglas: esquema, rutas sin cruces ni etiquetas encimadas y legibilidad en pantalla de escritorio. Cada uno es un visor completo, con recorridos guiados, búsqueda, foco por nodo, modo presentación y tema claro u oscuro.

Cómo intercambia la PGDR información con IE-010 a IE-018 y con los móviles: qué mecanismo usa cada uno, qué forma tienen los mensajes y qué pasa cuando el otro lado responde tarde, responde mal o no responde.

Principios (PRI-01 a PRI-06)

Estructura del borde de integración (diagrama 1)

Los 7 patrones de integración

El patrón se elige con dos preguntas: ¿quién inicia el intercambio? y ¿cuánta demora tolera el consumidor?

Matriz de integración: elige un sistema

Patrón, clase de criticidad, frescura máxima tolerable y comportamiento ante indisponibilidad (SAD cap. 6).

Modelo canónico y sobre de mensaje

El modelo canónico es un modelo del dominio y no una serialización del esquema de persistencia. Cubre solo lo necesario para coordinar; lo no traducido queda como bloque opaco. Todo mensaje del borde viaja en un sobre uniforme:

Recorrido del adaptador de entrada (diagrama 2)

Por qué en ese orden: autenticar primero evita trabajar para un emisor no autorizado; la idempotencia evita traducir lo ya procesado; la validación semántica va al final porque necesita el mensaje en el modelo del dominio. Nada se descarta sin rastro: lo rechazado queda con su motivo y es reprocesable.

Correspondencia de identificadores

Un mismo puente puede llegar del sistema de proyectos y del GIS con IDs distintos. La plataforma asigna un ID propio, único e inmutable, y mantiene el mapa: tipo de entidad, sistema e ID de origen, método (declarado, deducido por regla o confirmado por usuario) y trazabilidad para deshacer una unificación. Las correspondencias deducidas nunca se aplican solas sobre datos personales: se presentan como posible duplicado (RF-GPA-009).

Versionado de contratos

• Versión explícita: ningún consumidor la deduce del contenido.
• Cambio compatible (agregar un campo opcional): no cambia la versión mayor, y los consumidores ignoran lo que no conocen.
• Cambio incompatible (quitar un campo, volver obligatorio uno opcional, cambiar significados): versión mayor nueva que convive con la anterior.
• Periodo de transición con aviso de obsolescencia. Contrato primero: se acuerda antes de implementar el adaptador.

Salida hacia sistemas externos: bandeja de salida (diagrama 3)

Enviar fuera de la transacción puede perder el mensaje si el proceso cae entre escribir y enviar; enviar antes de confirmar puede anunciar algo que se deshace. Reglas: orden por entidad (no global), reintento con espera creciente y variación, clave del hecho en cada envío (si el externo no deduplica, el adaptador consulta antes de escribir y queda como riesgo aceptado), error permanente a mensajes fallidos con alerta, y reconciliación sin duplicados tras el restablecimiento (AC-RCP-006).

Resiliencia del borde (TAC-01 a TAC-11)

Seguridad de las integraciones (CSI-01 a CSI-10)

Observabilidad de las integraciones

Cada integración publica su estado en lugar de que alguien lo deduzca leyendo registros. Las señales son: disponibilidad, latencia en percentiles, tasa de error por tipo (distingue error del externo de error de contrato) y profundidad de colas cada 60 s; el estado del interruptor cuando cambia; la antigüedad de la caché de forma continua (es lo que muestra la interfaz); y la traza de correlación por operación.

Escenarios de integración

Los capítulos 1–10 definen cómo entra y sale información. Los capítulos 11–16 definen la otra mitad del contrato: qué operaciones expone la plataforma, quién puede invocarlas, qué publica cuando algo cambia y qué recibe un suscriptor.

Principios de las interfaces (PRI-07 a PRI-11)

Las cinco superficies

Cada superficie tiene base de ruta, autenticación y cupo de ejecución propios, y reproduce los compartimentos de la vista de procesos (AC-RES-006).

Convenciones

Modelo de error

Un solo formato: código estable, mensaje legible, correlación, campo afectado y versión. Nunca contiene datos personales.

Presupuesto de latencia por clase

Catálogo de las 13 APIs

Filtra por API, verbo o texto. Ojo con las operaciones con segundo factor: asignaciones y cambios de presupuesto.

Eventos de dominio

Un evento es la notificación de un hecho ya ocurrido. Nombre con formato modulo.entidad.hecho.vN, ID propio de la entidad, momento del hecho (distinto del de publicación), actor y organismo, estados anterior y nuevo, visibilidad (interna o externa) y sensibilidad.

Reglas de publicación

• Publicación transaccional: el cambio y el evento en la misma transacción, también para eventos internos (DA-API-04).
• Al menos una vez: todo consumidor es seguro de reejecutar.
• Orden por entidad, no global.
• Consistencia final acotada a 30 s hasta los tableros.
• Sin datos personales en la carga: referencia y clasificación; el contenido se obtiene por la API (DA-API-06).
• Retención de 7 días en el bus, alineada con TAC-05.

Matriz de operación, evento y efecto externo

Contratos y seguridad de las interfaces

Registro de contratos: componente vivo que publica la versión vigente, las versiones en transición y la obsolescencia de cada interfaz y evento (GET /suscripciones/v1/contratos). Una versión mayor cubre una superficie completa. La versión de API y la de evento evolucionan por separado. Hay prueba de conformidad antes de operar.

35 decisiones: 12 de integración (DA-INT), 10 de interfaces (DA-API) y 13 transversales (DA-ARQ). Por RST-008, todas citan atributos del SRS.

Mapa por atributo de calidad

Elige un atributo para ver qué decisiones lo sostienen. Sirve para evaluar el impacto de un cambio.

Decisiones transversales (DA-ARQ-01 a 13)

Fichas completas, con contexto, alternativa descartada, costo y verificación:

Decisiones del modelo de integración (DA-INT)

Decisiones del diseño de interfaces (DA-API)

La particularidad que condiciona todo: los usuarios necesitan la plataforma con más urgencia justo cuando el entorno es más hostil, con comunicaciones degradadas y personal de otros organismos que llega a última hora. Un control que bloquea sin alternativa en ese momento termina desactivado. Por eso cada control tiene una salida auditada, salvo los que protegen la integridad de la auditoría.

Activos y qué se protege de cada uno

Principios (PSE)

Modelo de amenazas

Se identificaron recorriendo EO-A a EO-E y preguntando en cada paso qué pasaría si interviniera un actor malintencionado o un error humano.

Zonas de confianza (Z0 a Z5)

Identidad, autenticación y autorización

Hay siete tipos de identidad, cada una con su mecanismo y su forma de revocarse: usuario federado (intermediario más segundo factor en operaciones críticas), usuario local (para organismos sin proveedor, SUP-002), ciudadano (no se autentica; solo SUP-C), dispositivo de campo (credencial vinculada al usuario, con borrado remoto), sistema externo (credencial propia, menos de 60 s para revocar), componente interno (identidad de servicio con rotación automática) y operador de plataforma (cuenta nominal con segundo factor).

Autorización en dos niveles: en la superficie (cada operación declara su permiso y se rechaza antes del dominio) y en el dominio (alcance por organismo derivado de la identidad). Ninguno sustituye al otro. Separación de funciones: quien solicita un cambio de presupuesto sobre el umbral no lo aprueba; el administrador de usuarios no lee datos personales ni toca la auditoría; el auditor solo lee; el operador de plataforma no tiene permisos de negocio.

Protección de los datos: 5 niveles

El cifrado por campo usa claves distintas a las del almacén: quien obtenga una copia del almacén o de un respaldo no puede leer datos personales sin la custodia de claves. La recuperación de claves forma parte del plan de recuperación, porque un respaldo cuya clave se perdió es inservible. La supresión se hace por borrado criptográfico (CSI-22), pendiente de validación jurídica.

Integridad, dispositivo e incidentes

• Integridad: auditoría encadenada y sellada; resumen de cada evidencia calculado en el dispositivo y verificado en el servidor; alertas firmadas cuando el canal lo permite; cambios de flujo o niveles aprobados por una segunda persona (decisión derivada).
• Dispositivo de campo: es el único componente fuera de toda zona controlada. Tiene almacenamiento cifrado, desbloqueo aunque no haya red, vinculación al usuario, caducidad local (bloquea la consulta de datos personales pero permite capturar), revocación con borrado remoto y minimización. El SRS no le asignó requisitos propios (OBS-14).
• Incidentes: eventos de seguridad en un almacén separado; anomalías detectadas en menos de 15 min; severidades crítica, alta y media; reporte a la Superintendencia de Industria y Comercio cuando se comprometen datos personales (CSI-33).
• Desarrollo seguro: análisis estático y de dependencias, artefactos firmados, inventario de componentes y secretos fuera del código; vulnerabilidades altas corregidas en 15 días (AC-SEG-005).

Controles de la plataforma (CSI-18 a CSI-33)

Dos preguntas que suelen mezclarse. Resiliencia: ¿cómo sigue operando la plataforma mientras algo falla? Recuperación: ¿cómo vuelve a la normalidad y qué información rescata después?

Objetivos

Modelo de fallas (MF-01 a MF-13)

Tácticas de la plataforma (TAC-12 a TAC-22)

Topología de continuidad (DA-ARQ-07)

Réplica frente a respaldo

La réplica protege frente a la pérdida de infraestructura, pero copia igual de rápido un borrado accidental o un cifrado malicioso. El respaldo conserva estados anteriores. La estrategia combina: réplica síncrona entre zonas; réplica asíncrona regional; registro continuo de transacciones con ventana de 35 días; respaldo completo diario; copia inmutable semanal aislada de las credenciales operativas; copia de la auditoría con sus sellos (5 años); evidencias replicadas entre regiones con versionado; configuración exportada en cada cambio; y réplica de la custodia de claves. Un respaldo que nunca se restauró se considera no verificado: la restauración se prueba al menos cada semestre (AC-RCP-004).

Niveles de contingencia (N1 a N4)

N3 se declara cuando la región no responde al monitoreo externo durante 5 minutos (valor de referencia) y operación no puede comprometer la recuperación dentro del RTO. Si la región vuelve a mitad de la conmutación, la conmutación continúa, porque revertirla dejaría a la plataforma sin ninguna región confiable.

Secuencia de restablecimiento N3: reprodúcela

Roles: responsable de continuidad (declara N3 y N4), de operación (ejecuta y confirma N2), de seguridad (N4 y evidencia), de datos (valida lo restaurado y dirige la reconciliación) y enlace con organismos. El retorno a la región principal es planificado, fuera de una emergencia y en orden inverso.

Reconciliación posterior

La PGDR pasa de la calma a la emergencia en minutos, y la carga no crece de forma uniforme: primero se dispara la consulta ciudadana, luego la ingesta de campo y semanas después la reconstrucción. Escalar la plataforma entera para cada pico sería caro e inútil.

Perfiles de carga

Principios (PES)

Dimensiones de escalado por componente

Elasticidad

Control de admisión: pruébalo

Escalabilidad de los datos

• Evidencias en dos niveles: acceso inmediato para eventos activos; menor costo tras el cierre (EVT-05), conservando la referencia y el resumen. Así se absorbe el crecimiento de 10 veces con política, sin tocar el negocio.
• Almacenes particionados por evento y fecha; versiones históricas separadas de la vigente; índices espaciales en GEO (AC-REN-006).
• Auditoría particionada por periodo e indexada por evento, lo que permite el histórico de 100.000 registros en menos de 10 s (AC-TRZ-003).
• Bus y proyecciones: el bus retiene 7 días; las proyecciones son derivadas y no se respaldan con la misma exigencia.

Modelo de capacidad (incompleto a propósito)

El SRS fija cargas pero no los datos para traducirlas a capacidad (OBS-13). 500 reportes por minuto son unos 8 por segundo sostenidos; se dimensiona para ráfagas de tres veces porque los equipos sincronizan juntos al volver a la base. Faltan cuatro datos: fotos por reporte, tamaño tras compresión, canales por organismo y factor de ráfaga. Juega con la calculadora:

Architecture Tradeoff Analysis Method. Responde tres preguntas: ¿las decisiones alcanzan los umbrales del SRS?, ¿dónde dependen de un valor concreto? y ¿qué se gana y qué se pierde en cada decisión? No produce una nota, produce un mapa.

Los 9 pasos

Controladores del negocio

Criterio de juicio: la arquitectura acierta si mantiene la coordinación viva cuando el entorno se degrada y si incorporar un sistema o un tipo de evento nuevo no obliga a rehacer el núcleo.

Tres restricciones condicionan la evaluación: RST-009 (sin tecnología, así que los valores de referencia se tratan como parámetros a validar), RST-008 (toda decisión justificada) y RST-011 frente a RST-012, que tiran en sentidos opuestos en el dispositivo móvil.

Enfoques arquitectónicos (EA-01 a EA-16)

Se identificaron leyendo el capítulo 17 del SAD al revés: partiendo de la forma repetida que comparten varias decisiones.

Tres encadenamientos que explican las respuestas

Árbol de utilidad

Pares (importancia, dificultad). A importancia: afecta C1. A dificultad: depende de varias decisiones o de supuestos externos. Se analizan en detalle los (A, A) y (A, M). Toca un escenario:

Fichas de análisis

Formato de seis partes más enfoques, razonamiento, riesgos, no riesgos, sensibilidad, compromisos y verificación.

Resultados

Cobertura

Lo más barato de verificar: la modificabilidad (contar componentes modificados) y la interoperabilidad (ejercicio de integración sin infraestructura). La escalabilidad queda bloqueada por falta del modelo de capacidad. ESC-14 no es verificable hasta que exista la política de conflictos. Quedaron sin escenario la usabilidad (AC-USA), AC-SEG-005, AC-SEG-006 y la observabilidad propia, por decisión de alcance.

Conclusión del ATAM

Insumos listos para la segunda entrega: los puntos de sensibilidad (parámetros que la tecnología debe fijar), los de compromiso (conversaciones pendientes con el cliente) y la tabla de cobertura (orden del plan de pruebas).

Observaciones registradas en el SAD (OBS)

Mecanismos de la arquitectura que puedes manipular. Úsalos para explicar con tus palabras qué pasa y por qué.

RST-008 obliga a que toda decisión cite un atributo; el ATAM recorre la cadena al revés. Aquí puedes hacer lo mismo: elige un atributo y verás sus requisitos, las decisiones que lo sostienen, las tácticas, los escenarios ATAM y los riesgos.

Decodificador de IDs

Escribe cualquier identificador (RF-EVD-018, AC-RES-006, CSI-24, EVT-P4, PS-04…) y verás su definición, el documento y quién lo menciona.

Un bloque por grupo de diapositivas, con tiempo objetivo, ideas clave y una frase para decir. Activa el cronómetro y practica en voz alta; el bloque actual se resalta según el tiempo.

Practica respondiendo en voz alta antes de abrir la respuesta. Marca las que ya dominas.

Puntos débiles y cómo defenderlos

Banco de preguntas