Riesgos y calidad

📐 Fundamento

Categorías típicas de riesgos en TI:

Proceso de gestión de riesgos:

1. Identificar    → ¿qué puede salir mal?
2. Analizar       → ¿probabilidad? ¿impacto?
3. Priorizar      → ¿cuál atendemos primero?
4. Planificar     → ¿qué hacemos? (4 estrategias)
5. Monitorear     → ¿cambió la situación?
6. Cerrar         → riesgo desapareció o se materializó

Matriz de probabilidad x impacto:

              Impacto bajo    Impacto medio   Impacto alto
Prob. alta    │ Medio  │     │ Alto   │     │ CRÍTICO │
Prob. media   │ Bajo   │     │ Medio  │     │ Alto    │
Prob. baja    │ Mínimo │     │ Bajo   │     │ Medio   │

Atender CRÍTICO y Alto. Monitorear Medio. Aceptar Bajo y Mínimo.

4 estrategias de respuesta:

Risk Register (registro de riesgos):

ID  | Riesgo                          | Cat   | Prob | Imp | Score | Resp     | Acción
----+---------------------------------+-------+------+-----+-------+----------+--------------------
R01 | Migración a microservicios falla| Tec   | M    | A   | 6     | CTO      | POC primero, paralelo a monolito
R02 | Líder técnico renuncia          | Rec   | B    | A   | 3     | Director | Documentar, mentoría 2 personas
R03 | AWS sube precios 20%            | Ext   | M    | M   | 4     | CFO      | Negociar contrato anual fijo
R04 | Falla seguridad — data breach   | Seg   | B    | A   | 3     | CISO     | Pen test trimestral, MFA, cifrado
R05 | Competidor lanza app similar    | Ext   | A    | M   | 6     | CEO      | Acelerar features diferenciadores

Revisar y actualizar semanalmente o por sprint.

Risk burn-down: trackear cuántos riesgos críticos/altos quedan abiertos. Tendencia descendente = buena gestión.

📐 Fundamento

EMV (Expected Monetary Value):

Riesgo: "AWS sube precios 20%"
Probabilidad: 30%
Impacto si ocurre: $50,000/año extra
EMV = 0.30 × <span class="katex"><span class="katex-mathml"><math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mn>50</mn><mo separator="true">,</mo><mn>000</mn><mo>=</mo></mrow><annotation encoding="application/x-tex">50,000 = </annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.8389em;vertical-align:-0.1944em;"></span><span class="mord">50</span><span class="mpunct">,</span><span class="mspace" style="margin-right:0.1667em;"></span><span class="mord">000</span><span class="mspace" style="margin-right:0.2778em;"></span><span class="mrel">=</span></span></span></span>15,000

Decisión: vale la pena gastar hasta $15,000 en mitigar (ej: contrato fijo).

Análisis de Monte Carlo aplicado a riesgos:

Simular miles de escenarios para entender el rango de resultados posibles del proyecto.

import numpy as np

# Distribución de duración base
base_duration_days = np.random.triangular(60, 90, 150, 10000)

# Riesgos identificados
def aplicar_riesgos(duracion):
    # 30% prob: feature técnico complejo añade 20-40 días
    if np.random.random() < 0.30:
        duracion += np.random.uniform(20, 40)
    
    # 10% prob: persona clave se va, atrasa 10-30 días
    if np.random.random() < 0.10:
        duracion += np.random.uniform(10, 30)
    
    # 5% prob: cambio de scope mayor, +30-90 días
    if np.random.random() < 0.05:
        duracion += np.random.uniform(30, 90)
    
    return duracion

resultados = [aplicar_riesgos(d) for d in base_duration_days]

print(f"Probabilidad de terminar en 90 días: {(np.array(resultados) <= 90).mean():.1%}")
print(f"Probabilidad de terminar en 120 días: {(np.array(resultados) <= 120).mean():.1%}")
print(f"P50: {np.percentile(resultados, 50):.0f} días")
print(f"P90: {np.percentile(resultados, 90):.0f} días")

Permite comunicar a stakeholders: "P50: 95 días, P90: 145 días, presupuestar 145 días".

📐 Fundamento

Top 10 riesgos más comunes en proyectos de software:

Patrón importante: "decisiones reversibles":

Distinguir entre one-way doors (decisiones difíciles de revertir) y two-way doors (fácil revertir).

Para one-way doors: invertí mucho más tiempo en evaluar. Para two-way doors: decidí rápido, ajustá si hace falta.

📐 Fundamento

QA en agile vs tradicional:

Pirámide de testing (recap):

            ╱╲
           ╱E2E╲          ← pocos, lentos, frágiles
          ╱──────╲
         ╱ Integ. ╲       ← medianos
        ╱──────────╲
       ╱   Unit     ╲     ← muchos, rápidos
      ╱──────────────╲

(Ver TDD y Testing — capítulo 4 de Ingeniería de Software para detalle.)

Definition of Done (DoD) — el criterio claro:

Una historia está "Done" cuando:
[ ] Código implementado y revisado (PR aprobada por al menos 1 dev).
[ ] Tests unitarios escritos y pasando.
[ ] Tests de integración pasando.
[ ] Documentación actualizada.
[ ] Probada en ambiente de staging.
[ ] PO ha verificado los criterios de aceptación.
[ ] Deployed a producción (o lista para deploy).
[ ] Métricas de monitoreo configuradas.

Sin DoD claro → "casi done" se acumula → el proyecto siempre parece estar al 90%.

Quality gates:

Puntos en el pipeline donde el código debe cumplir criterios para avanzar.

Code commit
   ↓
[Gate 1: Lint + format]    → falla → rechaza commit
   ↓
[Gate 2: Unit tests + coverage > 80%]
   ↓
[Gate 3: Integration tests]
   ↓
[Gate 4: Security scan (SAST)]
   ↓
[Gate 5: Code review aprobado]
   ↓
Deploy a staging
   ↓
[Gate 6: E2E tests + performance tests]
   ↓
Deploy a production

Coste de un bug por fase de detección (recap del cap. 1 de Ingeniería de Software):

Conclusión: invertir más en prevención (revisión de diseño, pair programming) y testing temprano paga 100x.

📐 Fundamento

Defect Density: bugs / KLOC. Objetivo: < 1 bug crítico / KLOC.

Defect Escape Rate: bugs encontrados en producción / bugs totales encontrados. Objetivo: < 10%.

Mean Time To Detect (MTTD): cuánto tarda en detectarse un bug en producción.

Mean Time To Recover (MTTR): cuánto tarda en arreglarse.

DORA Metrics (referencia mundial):

(De "Accelerate" — Forsgren, Humble, Kim).

SLOs/SLIs/SLAs (Site Reliability Engineering):

• SLI (Service Level Indicator): la métrica (ej: latencia P99).
• SLO (Service Level Objective): el objetivo interno (ej: P99 < 200ms el 99.9% del tiempo).
• SLA (Service Level Agreement): lo prometido al cliente (con consecuencias si no se cumple).

Error budget: "podemos fallar el 0.1% del tiempo" → 43 minutos de downtime/mes. Si el equipo se "gasta" su error budget, frena features y se enfoca en confiabilidad.