Curso · Referencia · Repaso de las diapositivas

Repaso completo: sólo las diapositivas

Todo lo que dicen las diapositivas del Tema 1 y del Tema 2, en su orden y con sus palabras, sin ampliaciones. Cada bloque enlaza a su diapositiva (el número es el de la diapositiva).

Cómo usarlo

Léelo de arriba abajo una vez. Después tapa cada tarjeta e intenta decir su contenido antes de mirarla: las listas (viabilidades, restricciones, respuestas al riesgo, métricas DORA…) y las frases definitorias son lo que el profesor usa al corregir (ver L20). Al final hay una autocomprobación.

Tema 1 · Introducción

  1. Proyecto y gestión
  2. Restricciones, éxito y fracaso
  3. De la oportunidad al producto: RFP y definición
  4. Requisitos y trazabilidad
  5. Priorización
  6. Viabilidad
  7. Arquitectura y ADR
  8. Ciclos de vida
  9. Stakeholders
  10. Deuda técnica
  11. Planificación, ejecución y control
  12. Personal y cierre
  13. Mapa e ideas clave

Tema 2 · Aspectos transversales

  1. Terminología
  2. Riesgos
  3. Costes
  4. Calidad
  5. Personas
  6. Gobernanza y cumplimiento
  7. DevOps y DevSecOps
  8. Autocomprobación

Tema 1 · 1. Proyecto y gestión

Objetivos del tema: comprender qué implica gestionar un proyecto software; identificar las etapas y principales decisiones; relacionar requisitos, alcance, viabilidad, arquitectura y planificación; reconocer el papel de stakeholders y deuda técnica; comparar modelos de ciclo de vida.diap. 3

¿Qué es un proyecto?4

  • Esfuerzo temporal para crear un producto, servicio o resultado único.
  • Tiene objetivos, restricciones, recursos y partes interesadas.
  • No es lo mismo que una operación recurrente o repetitiva.

Particularidades del software5

  • El producto es principalmente intangible.
  • Requisitos y solución evolucionan con frecuencia.
  • Alta incertidumbre técnica y organizativa.
  • El progreso no siempre es visible.
  • El coste del cambio suele crecer con el tiempo.

Gestión de proyectos6

  • Aplicación de conocimientos, habilidades, herramientas y técnicas para cumplir los requisitos del proyecto…
  • …equilibrando/cumpliendo restricciones de alcance, tiempo, coste, calidad, riesgos y recursos.

Gestión ≠ programación7

  • Programar es una actividad del proyecto.
  • Gestionar = tomar decisiones sobre: qué hacer, por qué, cuándo, con qué recursos, quién participa, qué riesgos aceptar.
  • Gestionar = reaccionar para controlar: plazos y costes, personas/interacciones, imprevistos/desviaciones, cambios.

La gestión como sistema de decisiones8

  • Objetivos → requisitos → solución → plan → ejecución → resultados.
  • Cada decisión condiciona las siguientes.
  • La gestión debe mantener coherencia entre todas ellas.

Tema 1 · 2. Restricciones, éxito y fracaso

Restricciones del proyecto9

  • Alcance · Plazo · Coste · Calidad · Recursos · Riesgos.

La triada y su evolución10

  • Modelo clásico: alcance · tiempo · coste.
  • Pero calidad y riesgo no pueden tratarse como variables secundarias.
  • Hoy: múltiples restricciones y objetivos en tensión.

Definir el éxito11

  • ¿A tiempo y en presupuesto = éxito? No basta. También importan:
  • Valor para el negocio/usuario.
  • Calidad y sostenibilidad (seguridad, mantenibilidad…; deuda técnica).
  • Satisfacción de stakeholders.
  • Cumplimiento legal y organizativo.

¿Por qué fallan?12

  • Objetivos ambiguos · requisitos inestables o mal entendidos · estimaciones demasiado optimistas · riesgos ignorados o mal gestionados · problemas técnicos subestimados · comunicación deficiente · problemas del personal.

El coste de los errores13

  • Un error temprano puede ser barato de corregir; el mismo error puede ser muy costoso en integración o producción.
  • Por eso la gestión busca reducir incertidumbre cuanto antes.

Cuestiones clave en la práctica14

  • ¿Qué problema resolvemos? ¿Para quién(es)? ¿Qué se incluye y qué queda fuera? ¿Cómo sabremos que funciona? ¿Es viable? ¿Qué puede salir mal? ¿Cómo lo evitamos o mitigamos? ¿Qué necesitamos para ejecutarlo?

Tema 1 · 3. De la oportunidad al producto: RFP y definición

Idea / necesidad / oportunidad→RFP→Definición y viabilidad→Planificación y ejecución→Entrega y cierre

diap. 15

RFP · Request for Proposals16

  • Documento con el que una organización solicita propuestas.
  • Suele describir necesidad, objetivos, alcance esperado y condiciones.
  • Permite comparar alternativas de proveedores o soluciones.

Contenido habitual de una RFP17

  • Contexto y problema · objetivos y alcance esperado · requisitos · entregables · plazos e hitos · criterios de evaluación · presupuesto / condiciones contractuales.

Responder a una RFP18

  • Entender el problema antes de proponer la solución.
  • Identificar supuestos (asunciones) y ambigüedades.
  • Proponer alcance, solución, plan, equipo y costes.
  • Explicitar riesgos y exclusiones.

De la RFP a la definición19

  • La RFP describe una necesidad; el proyecto debe convertirla en un marco gestionable: objetivos verificables, alcance, requisitos, stakeholders, criterios de éxito.

Project Charter · Acta de constitución20

  • Documento que autoriza formalmente el proyecto.
  • Define propósito, objetivos, alcance inicial, stakeholders y responsabilidades.
  • Sirve como referencia para decisiones posteriores.

Elementos de una buena definición21

  • Problema / oportunidad.
  • Objetivos SMART cuando sea apropiado: Específicos, Medibles, Alcanzables, Realistas, De duración limitada.
  • Alcance y exclusiones · entregables · supuestos y restricciones · criterios de éxito.

Alcance: qué sí y qué no22

  • In scope: funcionalidades y entregables comprometidos.
  • Out of scope: elementos explícitamente excluidos.
  • El alcance no definido es una fuente frecuente de conflictos.

Tema 1 · 4. Requisitos y trazabilidad

Diapositivas 23-25 ("Situémonos"): viñetas de Dilbert sobre requisitos que no se saben o cambian.24

Requisitos26

  • Describen necesidades, capacidades o condiciones que debe satisfacer el sistema.
  • Deben ser comprensibles, verificables y trazables.
  • Tipos habituales: funcionales y no funcionales.
  • Sus relaciones son tan cruciales como los propios requisitos. La trazabilidad es esencial.

RF vs. RNF27

  • RF: capacidades, ¿qué hace? RNF: cualidades, ¿cómo hace lo que hace?
  • Ej.: «registrar pagos» vs. «procesar el 95 % de pagos en < 2 s».
  • Algunos mezclan ambos (p. ej., seguridad): se tratan como RNF.
  • Los RNF suelen influir más en la complejidad y son más difíciles de verificar.

Requisitos funcionales28-29

  • Describen los servicios y la funcionalidad del sistema.
  • Dependen del tipo de software, del sistema donde se usará y de los usuarios.
  • De usuario: declaraciones de alto nivel; de sistema: describen los servicios en detalle.
  • Ejemplos: buscar en toda la BD o en un subconjunto; visores para leer documentos; ID_PEDIDO único que el usuario puede copiar.

Requisitos no funcionales30

  • Definen propiedades y restricciones del sistema (fiabilidad, tiempo de respuesta, almacenamiento…).
  • Requisitos del proceso pueden obligar a usar estándares, una herramienta CASE o un lenguaje.
  • Pueden ser más críticos que los funcionales: si no se cumplen, invalidan el sistema; influyen mucho en la arquitectura.

Clasificación de RNF por objeto31-32

  • Del producto: comportamiento del producto (velocidad, tasa de fallos). Ej.: comunicación en UTF-16BE.
  • De la organización: políticas y procedimientos propios (estándares de proceso, métodos de diseño, lenguajes, documentación). Ej.: conforme a ISO-XXXX.
  • Externos: factores externos al producto y al proceso (legales —LOPD—, éticos). Ej.: no revelar datos personales a usuarios de nivel 3 o inferior.

Jerarquía de RNF por tipo (figura)33

  • Producto: usabilidad · eficiencia (rendimiento, espacio) · fiabilidad · portabilidad.
  • Organización: entrega · implementación · estándares.
  • Externos: interoperabilidad · éticos · legislativos (privacidad, seguridad física).

Criterios de aceptación34

  • Evitar requisitos vagos: «rápido», «seguro», «fácil de usar».
  • Requisito → condición verificable → necesita criterios de aceptación.
  • Los criterios de aceptación definen realmente el requisito: definen cuándo se considera satisfecho.
  • TDD aplica las pruebas como criterios de aceptación.

Trazabilidad35

  • Permite seguir la relación entre elementos del proyecto.
  • Necesidad → objetivo → requisito → diseño → implementación → prueba.
  • Ayuda a detectar requisitos sin cobertura y el impacto de los cambios.

Matriz de trazabilidad36

  • Ej.: OBJ-02 → REQ-07 → MOD-03 → TEST-21.
  • Preguntas: ¿todos los requisitos tienen origen? ¿Todos tienen quien los verifique? ¿Qué pruebas se ven afectadas por un cambio?

Tema 1 · 5. Priorización

Priorización de requisitos37

  • No todo puede hacerse primero.
  • La prioridad debe reflejar valor, urgencia, riesgo y coste.
  • Debe ser explícita y revisable.

Estrategias38

  • No existe una única estrategia.
  • Valor → lo que más aporta primero · Riesgo → lo más arriesgado primero · Coste de retraso → lo que más cuesta posponer · Dependencias → lo que desbloquea otras · Esfuerzo → quick wins · Aprendizaje → reducir incertidumbre primero.

Técnicas39

  • MoSCoW → clasificación por importancia.
  • WSJF → Cost of Delay / Job Size.
  • Value vs. Effort → valor frente a esfuerzo.
  • Risk-based → probabilidad × impacto.
  • Kano → satisfacción del cliente.
  • Cost of Delay → impacto económico/temporal de retrasar.
  • Opportunity scoring → importancia para el cliente vs. satisfacción actual.

MoSCoW40

  • No es una estrategia sino una semántica estándar para representar la prioridad de forma explícita.
  • Must imprescindible · Should importante, no imprescindible · Could deseable · Won't no se hará ahora.
  • Útil para negociar alcance y gestionar expectativas.

Tema 1 · 6. Viabilidad

Estudio de viabilidad41

  • Pregunta fundamental: ¿debemos hacer este proyecto?
  • Viabilidad técnica · económica · temporal · organizativa · legal/regulatoria.

Viabilidad técnica42

  • ¿Podemos construirlo con la tecnología disponible?
  • ¿Tenemos conocimientos y recursos?
  • ¿Existen integraciones, datos o restricciones críticas?
  • ¿Qué incertidumbres requieren un prototipo o prueba de concepto?

Viabilidad económica y temporal43

  • Beneficios esperados vs. costes; costes = desarrollo + operación + mantenimiento.
  • ¿Hay una fecha objetivo? Oportunidad de negocio (competencia, circunstancias objetivo), límites externos, límites internos.
  • ¿Es posible cumplirla? Una fecha fija puede obligar a reducir alcance o aumentar recursos.

Tema 1 · 7. Arquitectura y ADR

Concepto de arquitectura44-45

  • Garlan y Shaw (1994): al crecer los sistemas, el problema va más allá de algoritmos y estructuras de datos: diseñar la estructura global del sistema.
  • Garlan y Perry (1995): estructura de los componentes, sus interrelaciones, y los principios y reglas que gobiernan su diseño y evolución.
  • Bass, Clements y Kazman (1998): estructura(s) del sistema: componentes, sus propiedades observables y sus relaciones.
  • Fowler (2001): los elementos del núcleo, las piezas difíciles de cambiar; los cimientos.

Arquitectura y decisiones técnicas46

  • La arquitectura define la estructura fundamental del sistema.
  • Las decisiones técnicas deben responder a requisitos y restricciones.
  • No basta con elegir tecnologías "de moda"; los clientes tienden a pedirlas ("buzzwords").

ADR · Architecture Decision Record47

  • Documento que recoge una decisión importante junto con su contexto y sus consecuencias.
  • Registra y traza decisiones: contexto → decisión → alternativas → consecuencias.
  • Facilita la revisión, el mantenimiento y el aprendizaje del equipo.

Tema 1 · 8. Ciclos de vida

Modelos48

  • Predictivo / secuencial / cascada · Iterativo · Incremental · Ágil · Híbrido.

Elegir el modelo49

  • Decisión no trivial ni única; se adapta al contexto: estabilidad de los requisitos, tamaño del equipo, riesgo tecnológico, plazo disponible.
  • Un modelo inadecuado puede condenar el proyecto antes de la primera línea de código; el acertado es un habilitador del éxito.

Predictivo vs. adaptativo50

  • Predictivo: se intenta definir y planificar gran parte del trabajo al inicio.
  • Adaptativo: se aprende y ajusta progresivamente.

Tema 1 · 9. Stakeholders

Partes interesadas51

  • Entidades (personas, grupos u organizaciones) que pueden afectar o verse afectadas por el proyecto.
  • Ej.: cliente, usuarios, dirección, equipo, proveedores, reguladores.
  • Sus objetivos pueden ser opuestos e incompatibles.
  • En seguridad se consideran también las partes interesadas maliciosas.

Puntos de vista (viewpoints)52

  • Dos entidades pueden ver el mismo proyecto de forma diferente.
  • Identificar perspectivas ayuda a descubrir objetivos y conflictos.
  • El análisis de stakeholders debe influir en requisitos y decisiones.

Fase de definición del sistema53

  • Se identifican todos los stakeholders y se explicitan sus objetivos, expectativas y restricciones.
  • Se analizan conflictos y requisitos contradictorios antes de desarrollar: es más barato alinear en el papel que corregir con el código escrito.

Analizar stakeholders54

  • Interés: ¿qué esperan o necesitan?
  • Influencia: ¿pueden afectar decisiones?
  • Impacto: ¿cómo les afecta el resultado?
  • Estrategia: informar, involucrar, consultar, gestionar.

Tema 1 · 10. Deuda técnica

Qué es55-56

  • Coste futuro provocado por decisiones técnicas que priorizan una solución inmediata.
  • Puede ser deliberada o accidental. No toda deuda es mala: debe gestionarse conscientemente.
  • Coste acumulado por atajos o decisiones subóptimas: ralentiza la productividad, aumenta la fragilidad y consume recursos.
  • Como comprar a crédito: avanzas hoy, los intereses (bugs, complejidad, pérdida de velocidad) se pagan después; si no la amortizas, hipotecas el proyecto.

Tipos / fuentes57

  • Código/diseño · arquitectura · pruebas · infraestructura/dependencias · documentación · procesos y conocimiento.

Gestionarla58

  • Registrar · estimar impacto y riesgo · priorizar su tratamiento · planificar su reducción · evitar que sea deuda "invisible".

Deuda y gestión59

  • Presión de plazo → decisiones rápidas → deuda potencial → deuda acumulada → menor velocidad y mayor riesgo.
  • Gestión responsable → hacer explícito el compromiso (trade-off).

Tema 1 · 11. Planificación, ejecución y control

Planificación y seguimiento60

  • Planificación: define objetivos, tareas, recursos y cronogramas, alineando a todos.
  • Seguimiento: supervisa el progreso, detecta desviaciones y aplica medidas correctivas.
  • Ayudan herramientas, metodologías ágiles (Scrum, Kanban) y reuniones periódicas.
  • Objetivos: convertir objetivos en trabajo ejecutable · descomponer entregables y tareas · estimar esfuerzo y duración · asignar recursos · establecer dependencias, hitos y calendario.

Planificación e incertidumbre61

  • La incertidumbre es inherente; las metodologías actuales no la eliminan con planes rígidos, la integran: ciclos cortos, feedback continuo, ajustes.
  • Una estimación no es una promesa.
  • Cuanto más lejano el trabajo, mayor incertidumbre.
  • El plan se actualiza cuando cambia la información.
  • Planificar ≠ predecir perfectamente.

Ejecución y control62

  • No es verificar el plan inicial, sino inspección y adaptación continua.
  • Revisiones frecuentes (daily, sprints, revisiones) en vez de controles rígidos; el plan es una guía abierta a reescritura.
  • Ejecutar el trabajo · medir progreso y resultados · gestionar cambios, riesgos, problemas y decisiones · comunicar continuamente a los stakeholders.

Control: PDCA63-64

  • Bucle de mejora continua: cada desviación es una oportunidad de aprendizaje, no un fracaso del plan.
  • Plan planear · Do ejecutar · Check medir, comparar · Act decidir, ajustar.
  • Preguntas: ¿vamos tarde? ¿Qué ha cambiado? ¿Qué riesgo ha cambiado? ¿Qué decisión debemos tomar ahora?

Tema 1 · 12. Personal y cierre

Gestión de personal (I)65

  • El factor humano es el principal determinante del éxito o fracaso.
  • Dinámicas de equipo: modelo Tuckman: formación, «inboarding» (errata de la diapositiva: la fase es conflicto, storming), normalización, desempeño y disolución; equipos cohesionados rinden más que la suma; la diversidad cognitiva mejora la resolución de problemas pero requiere adaptación.
  • Conflictos: los de visión o tarea pueden ser creativos; los personales son destructivos y se abordan pronto; el líder es facilitador, no juez.
  • Comunicación: la ineficaz es la principal causa de retrasos y errores; canales claros, reuniones periódicas, documentación justa; equilibrar síncrona y asíncrona.

Gestión de personal (II)66

  • Personalidades (MBTI / DISC / Belbin): analíticos → detalle y calidad; creativos → innovación; ejecutores → cumplimiento y organización; comunicadores → stakeholders. La diversidad es una fortaleza.
  • Motivación y clima afectan a la calidad del código y la velocidad; equipos autoorganizados deciden mejor; el burnout es un riesgo real.
  • "Gestionar personas no es un soft skill menor, es el verdadero núcleo de la ingeniería de software."

Cierre del proyecto67-68

  • Va más allá de entregar: verificación final de requisitos, lecciones aprendidas, liberación de recursos, transferencia a operaciones, celebración del logro.
  • Se archiva ordenadamente y el conocimiento perdura.
  • En DevOps, el cierre marca el fin del desarrollo inicial.
  • Se trata de: verificar aceptación de entregables · cerrar contratos y documentación · transferir conocimiento y operación · registrar lecciones aprendidas · liberar recursos.

Tema 1 · 13. Mapa e ideas clave

RFP→Definición→Requisitos→Trazabilidad / priorización→Viabilidad→Arquitectura→Planificación→Ejecución / control→Gestión de personal→Cierre

En todo el ciclo: stakeholders + riesgos + calidad + deuda técnica.69

Ideas clave: ¡no olvidar!71

Tema 2 · 1. Terminología

Bloques: riesgos, costes, calidad, personas, gobernanza y cumplimiento, DevOps y DevSecOps.diap. 3

Terminología básica4

  • Actividades: divisiones del trabajo; por objetivo (planificación, riesgos, requisitos, calidad…) o por tamaño (subproyectos, paquetes de trabajo, tareas, subtareas).
  • Artefactos/entregables: productos tangibles; los entregables (deliverables) se entregan a los clientes.
  • Recursos: con lo que contamos; normalmente recurso = persona.
  • Hitos: puntos de control comprobables objetivamente.

Similitudes con otros proyectos5

  • Las actividades de gestión no son exclusivas del software.
  • Técnicas de ingeniería de proyectos o investigación de operaciones son aplicables.
  • Los proyectos de ingeniería complejos sufren los mismos problemas.

Tema 2 · 2. Gestión de riesgos

Objetivos: identificar y formular riesgos de forma útil; analizar probabilidad, impacto e incertidumbre; planificar respuestas y reservas; monitorizar como actividad continua; incorporar riesgos tecnológicos, humanos, organizativos, de seguridad y de IA.7

Del riesgo a la incertidumbre8

  • Riesgo: efecto de la incertidumbre sobre los objetivos.
  • Amenazas y oportunidades.
  • La incertidumbre incluye ambigüedad y complejidad.
  • Gestionar riesgo no es eliminar toda incertidumbre.

Cambio en la gestión moderna9

  • De un "registro de riesgos" estático → a una gestión continua de incertidumbre, integrada en decisiones, planificación y ejecución, conectada con stakeholders, producto, arquitectura y operaciones.

Proceso y artefactos10-11

  • 1. Identificación · 2. Análisis · 3. Planificación/tratamiento · 4. Seguimiento y control. Se repite durante todo el proyecto.
  • Artefactos: registro de riesgos · valoración/mapa · planes de respuesta · KRIs · decisiones, responsables y fechas de revisión.

Identificación12-13

  • Objetivo: descubrir incertidumbres que puedan afectar a los objetivos. No basta con listar "cosas malas".
  • Formular: causa → evento → consecuencia → acciones. Asignar propietario desde el principio.
  • Ej.: causa: dependencia de un proveedor · evento: retrasa la API · consecuencia: se retrasa integración y entrega · probabilidad alta · impacto medio.

Fuentes de riesgo14-15

  • Tecnología y arquitectura · personas y conocimiento · organización y proveedores · requisitos y stakeholders · planificación, estimaciones y dependencias · seguridad, privacidad y cumplimiento.
  • Nuevas: dependencias y software de terceros · cadena de suministro · cloud y concentración de proveedores · vulnerabilidades y exposición operacional · datos y modelos de IA · IA generativa en el desarrollo · IA generativa por adversarios.

Técnicas de identificación16

  • Brainstorming estructurado · checklists y taxonomías · entrevistas con expertos y stakeholders · premortem · revisión de arquitectura y dependencias · lecciones aprendidas de proyectos anteriores.

Análisis premortem17

  • Imaginar que el proyecto ha fracasado.
  • Identificar retrospectivamente las causas.
  • Convertir las causas plausibles en riesgos.
  • Útil para evitar el sesgo de exceso de confianza.

Seguridad, supply chain e IA18-19

  • Supply chain: dependencias vulnerables o abandonadas · compromiso de proveedores o artefactos · credenciales y secretos expuestos · ataques a CI/CD o repositorios · integridad y procedencia (NIST SP 800-161).
  • IA: calidad y representatividad de datos · drift · alucinaciones · privacidad, PI y datos sensibles · seguridad de modelos y prompts · dificultad de evaluación y monitorización (NIST AI RMF, AI 600-1).

Análisis20-21

  • Objetivo: estimar importancia para decidir: probabilidad/frecuencia · impacto/consecuencia · exposición o severidad · incertidumbre de la propia estimación.
  • Cualitativo: escalas muy bajo → muy alto, no más de 5 niveles; prioriza rápido; definir qué significa cada nivel; evitar falsa precisión ("3,7").

Matriz probabilidad-impacto22-23

  • Herramienta de comunicación y priorización; no sustituye al juicio profesional.
  • Un evento raro de impacto catastrófico puede requerir más atención que muchos menores.
  • Monitorizar todo es muy costoso: roja = los más importantes · amarilla = moderados · verde = probablemente se pueden ignorar.

Cuantitativo · individual vs. global24-25

  • Con información suficiente: EMV (Expected Monetary Value), Monte Carlo, distribuciones de esfuerzo/duración, análisis de sensibilidad, CORAS. Útil para reservas y decisiones de inversión.
  • Individual: eventos concretos. Global: efecto de la incertidumbre sobre el proyecto como sistema; las interacciones importan (retraso de proveedor + pérdida de personal + cambio de requisitos).

Tratamiento (amenazas)26-27

  • Evitar: cambiar el plan para eliminar la amenaza.
  • Mitigar/reducir: reducir probabilidad o impacto.
  • Transferir/compartir: trasladar parte de la exposición.
  • Aceptar: asumirla conscientemente y preparar respuesta.
  • Escalar cuando corresponda.

Oportunidades28

  • El riesgo no es sólo amenaza. Explotar → asegurar que ocurra · Mejorar → aumentar probabilidad o impacto positivo · Compartir → colaborar para capturar beneficio · Aceptar → aprovechar si ocurre.

Contingencia ≠ mitigación29

  • Mitigación: actuar antes del evento (prototipo temprano de una integración).
  • Contingencia: actuar si el evento ocurre (alternativa técnica preparada).

Reservas y tolerancias30

  • No todos los riesgos se pueden eliminar.
  • Reserva de contingencia: incertidumbre conocida.
  • Reserva de gestión: incertidumbre no asignada / cambios fuera de la línea base.
  • Definir tolerancias evita reaccionar tarde.

Propietario del riesgo31

  • Cada riesgo relevante debe tener un responsable. Responsable ≠ culpable.
  • Vigila señales, impulsa respuestas y actualiza el estado.
  • Sin propietario el riesgo queda "huérfano" y pasa a ser impredecible.

Seguimiento32

  • Revisar probabilidad e impacto · comprobar indicios (señales tempranas) · actualizar respuestas y reservas · cerrar los que ya no sean relevantes · identificar nuevos.

KRIs · Key Risk Indicators33

  • Un KRI es una señal que anticipa un aumento de exposición.
  • Ej.: rotación del equipo · defectos abiertos críticos · dependencias sin mantenimiento · retraso de hitos · incidentes de seguridad · cambios frecuentes de requisitos.

Risk burndown / tendencia34

  • Más importante que una foto estática es ver la evolución: ¿baja la exposición total? ¿Qué riesgos crecen? ¿Cuántos críticos siguen abiertos?
  • Las tendencias ayudan a decidir antes de que el problema se materialice.

Riesgo en Agile y en DevOps35-36

  • Agile: el riesgo no desaparece con Scrum; se integra en backlog, refinamiento, planificación y retrospectivas; spikes/prototipos reducen incertidumbre; priorizar riesgos técnicos adelanta aprendizaje.
  • DevOps: la exposición continúa tras el desarrollo. Observabilidad → detección temprana · automatización → menos error humano · despliegues pequeños → menor impacto · rollback/recuperación → limitar consecuencias.

Terceros, software seguro e IA37-39

  • Terceros: inventariar componentes y proveedores · evaluar criticidad · monitorizar vulnerabilidades y mantenimiento · verificar procedencia e integridad · preparar alternativas.
  • Software seguro: seguridad desde el diseño · threat modeling · requisitos de seguridad trazables · verificación continua en CI/CD · vulnerabilidades como riesgo, no sólo lista de fallos.
  • IA: gestionar todo el ciclo · usos, actores, impactos, límites · seguridad, robustez, privacidad, sesgos · monitorizar tras desplegar · reevaluar si cambian datos, modelo o contexto.

Ejemplo: riesgo de IA generativa40

  • Riesgo: el asistente genera código inseguro. Causa: confianza excesiva. Consecuencia: vulnerabilidad en producción.
  • Mitigación: revisión humana + análisis automatizado + tests de seguridad. KRI: vulnerabilidades detectadas en código generado.

Registro de riesgos41-42

  • ID · descripción · causa · consecuencia · probabilidad · impacto · exposición · propietario · respuesta · acciones · KRI/trigger · fecha de revisión · estado (abierto / en tratamiento / materializado / cerrado).
  • No es un inventario burocrático: cada riesgo importante lleva a una decisión: ¿qué hacemos? ¿Quién? ¿Cuándo? ¿Cómo sabremos que la exposición ha cambiado?

Integración y errores frecuentes43-44

  • Los riesgos conectan con requisitos, arquitectura, planificación y estimaciones, calidad y deuda técnica, stakeholders, operación y seguridad.
  • Errores: identificar una sola vez · sin propietario · confundir riesgo con problema ya ocurrido · matrices sin criterios · no actualizar · ignorar riesgos positivos · tratar riesgos técnicos como asunto exclusivo del equipo técnico.
Resumen de riesgos45

Tema 2 · 3. Gestión de costes

Qué es gestionar el coste48

  • Objetivo: usar los recursos económicos de forma sostenible para conseguir el valor esperado.
  • Estimar costes · presupuestar · asignar y controlar recursos · medir coste real y progreso · prever el coste final · decidir ante desviaciones.

¿Cuáles son los costes?49

  • Personas (principal coste) · infraestructura y herramientas (cloud, servicios externos) · pruebas, integración y despliegue · seguridad y cumplimiento · mantenimiento y operación · cambios y trabajo.
  • El coste de desarrollar una funcionalidad no es necesariamente su coste total de propiedad (TCO).

Estimación tradicional50

  • Predictivo: se estima el coste global antes de ejecutar. Trabajo → esfuerzo → recursos → coste.
  • Ej.: analista 120 h × 40 € = 4.800 € · desarrollador 600 h × 35 € = 21.000 € · tester 180 h × 30 € = 5.400 € · infraestructura 3.000 € · total 34.200 €.
  • Estimación ≠ presupuesto ≠ coste real: la incertidumbre se refleja con reservas y contingencias.

Control del coste51

  • El presupuesto sólo es útil si comprobamos la evolución: ¿cuánto trabajo hemos hecho? ¿Cuánto nos ha costado? ¿Cuánto deberíamos haber gastado? ¿Cuánto esperamos gastar al final?

Earned Value Management52

  • PV Planned Value · EV Earned Value · AC Actual Cost. (La diapositiva escribe "EMV", pero es EVM.)
  • CPI = EV / AC: eficiencia del coste. SPI = EV / PV: eficiencia respecto al calendario. (< 1 = peor de lo previsto.)
  • En software, interpretar con cuidado: el "% completado" puede dar falsa sensación de precisión.

Estimación Agile53

  • No se fijan a la vez alcance, plazo y coste. Se fija equipo + duración → capacidad/coste, y se adaptan alcance y prioridades.
  • Ej.: 6 personas, 30.000 €/mes → sprint de 2 semanas ≈ 15.000 €.
  • Cambio de pregunta: de "¿cuánto costará todo?" a "¿qué valor podemos obtener con los recursos disponibles?". El backlog decide qué va primero.
Coste y decisiones 54Tradicional / predictivoAgile / adaptativo
PresupuestoSe estima inicialmenteSe relaciona con equipo y horizonte
AlcanceIntenta fijarseSe prioriza y adapta
PlanificaciónDetallada inicialmenteRolling wave / iterativa
EstimaciónHoras, recursos, actividadesStory points, capacidad, velocidad
ControlCoste planificado vs. realCoste por iteración + valor entregado
CambiosAnalizar impacto en presupuesto/plazoRe-priorizar backlog
Pregunta clave"¿Nos ajustamos al presupuesto?""¿Estamos obteniendo suficiente valor?"

En ambos el coste es desarrollo + calidad + seguridad + infraestructura + operación + mantenimiento + deuda técnica. Gestionar el coste = tomar decisiones económicas informadas, no simplemente gastar menos.

Tema 2 · 4. Gestión de la calidad

Gestión de calidad56

  • Asegurar que se alcanza el nivel de calidad requerido en un producto software.
  • Definir normas (estándares internos) de calidad y procedimientos para que se sigan.
  • Crear una "cultura de calidad": la calidad es responsabilidad de todos.

Por qué importa la calidad del código57

  • Legibilidad · menos probabilidad de errores · facilita encontrarlos · mantenimiento y evolución · trabajo colaborativo · reusabilidad · seguridad.

Definición de calidad58

  • Simplificando: el producto debe cumplir con sus especificaciones. No es fácil en software:
  • Tensión entre requisitos de calidad del cliente (eficiencia, fiabilidad, privacidad) y de los desarrolladores (mantenimiento, reutilización).
  • Algunos son difíciles de especificar sin ambigüedad; las especificaciones suelen ser incompletas e incoherentes.

Actividades59

  • Aseguramiento/garantía: establecer procedimientos de organización y estándares de calidad.
  • Planificación: seleccionar los procedimientos y estándares para un proyecto y adaptarlos.
  • Control: garantizar que el equipo sigue los procedimientos y estándares.
  • La gestión de la calidad debe estar separada de la gestión del proyecto para garantizar su independencia.

Código de calidad en la práctica60-62

  • Puede ser subjetivo. Se supone que un código de calidad: hace lo que debe (negocio y seguridad) · estilo consistente · fácil de entender · bien documentado · se puede probar · sin vulnerabilidades · no puede usarse de formas no previstas.
  • Clean Code (citas): Stroustrup (elegante y eficiente, hace una cosa bien), Dave Thomas (lo puede leer y mejorar otro), Feathers (escrito por alguien a quien le importa).

Evolución histórica63

  • Empezó siendo sinónimo de falta de defectos.
  • Hoy: TQM (Total Quality Management), relacionada con la "percepción de la calidad"; surge en los 50, se populariza a mediados de los 80.
  • Los procesos de SQA se inspiran en TQM (concepto holístico).

Calidad y seguridad64

  • Calidad: grado en que un sistema cumple los requisitos funcionales y no funcionales (ISO/IEC 25010).
  • Seguridad: capacidad de proteger información y datos de acceso o modificación no autorizada.
  • La seguridad es una subcaracterística de la calidad en ISO/IEC 25010 → pertenece a "fiabilidad" y "protección de la información".
  • Un software no es de alta calidad si no es seguro, aunque cumpla su funcionalidad.

Calidad de proceso y de producto65-66

  • Hipótesis: la calidad del producto está influida por la del proceso (importante porque algunos atributos son difíciles de evaluar).
  • Pero la relación es muy compleja, y más aún en seguridad.
  • Ciclo: definir proceso → desarrollar producto → evaluar calidad → ¿OK? Sí: estandarizar. No: ¿influye el proceso? Sí: mejorar proceso; No: resolver problemas del producto.

Tema 2 · 5. Gestión de las personas

Personal del proyecto68-69

  • Puede ser imposible reclutar a las personas ideales: presupuesto, disponibilidad, o la organización prefiere formar a sus empleados. Hay que trabajar con esas limitaciones.
  • El software lo construyen personas; la IA sigue controlada por personas, que deciden si aceptan el código.
  • La planificación puede ser excelente y el proyecto fracasar por problemas de personas.

Qué gestiona el responsable70

  • Capacidad · Competencias · Coordinación · Motivación · Comunicación · Desarrollo del equipo.
  • El responsable está al servicio del equipo, no al contrario. Gestionar personas no es sólo asignar tareas.

Conocer al equipo: orientaciones71-72

  • A tareas: resultados (planificación, precisión, resolución, cumplimiento).
  • A interacción: relaciones (comunicación, coordinación, cohesión, mediación).
  • A sí mismo: necesidades propias (autonomía, influencia, reconocimiento, objetivos personales).
  • No son excluyentes. Sirven para: evitar equipos homogéneos · asignar responsabilidades · detectar desequilibrios · gestionar expectativas · observar conductas, no encasillar.

Carga de trabajo73

  • Capacidad disponible ≠ horas laborales totales (reuniones, coordinación, soporte, formación, incidencias…).
  • Evitar asignar el 100 %: dejar margen para imprevistos.
  • Repartir según capacidad, competencias y dependencias; revisar durante el proyecto.

Formas de equilibrar la carga74

  • Por horas (ojo: horas inciertas) · capacidad por iteración (no confundir velocidad con capacidad futura) · WIP limitado (puede requerir priorizar o esperar) · carga visible en tablero (la herramienta no sustituye la conversación).

Problemas de personal = riesgos75

  • Falta de perfiles críticos · rotación, bajas, pérdida de conocimiento · sobreasignación y multitarea · «bus factor» bajo (dependencia de una persona) · conflictos · curva de aprendizaje · desmotivación, agotamiento · reparto desigual.

Papel del responsable76

  • Prever · Visualizar · Priorizar (reducir trabajo simultáneo antes que saturar) · Redistribuir · Compartir conocimiento (revisión de código, pair programming, documentación, rotación) · Comunicar pronto · Escalar (recursos, calendario, alcance, expectativas).

Motivación, liderazgo, comunicación77

  • Objetivos claros · autonomía sin microgestión · feedback frecuente · seguridad psicológica (comunicar errores, dudas y riesgos sin temor) · reconocimiento · conflictos sobre hechos, necesidades y objetivos.
Resumen de personas78

Tema 2 · 6. Gobernanza y cumplimiento

Gobernanza ≠ gestión80

  • Gobernanza: quién tiene autoridad, qué decisiones deben tomarse y bajo qué reglas. Gestión: ejecuta el proyecto dentro de ese marco.
  • Define responsabilidades · autoridad y escalado · mecanismos de decisión · controles · transparencia y rendición de cuentas.
  • "La gobernanza define las reglas del juego; la gestión juega el partido."

Necesidad de gobernanza81

  • Decisiones que afectan a negocio y usuarios, presupuesto, seguridad y privacidad, datos, PI, proveedores, calidad y operación, cumplimiento normativo.
  • Sin gobernanza no hay responsabilidad: decisiones dispersas, responsabilidades difusas, difícil saber quién decidió y por qué.

Cinco piezas82

  • Autoridad → responsabilidades → decisiones → controles → información.
  • Ejemplos: cambio de alcance → sponsor/comité · decisión arquitectónica → equipo técnico · aceptación del producto → cliente/Product Owner · riesgo crítico → PM + responsable · tratamiento de datos → responsable designado.

No es burocracia83

  • Mala: "tres reuniones y cuatro firmas para cambiar una línea". Buena: las decisiones importantes tienen responsable, criterios, evidencia y trazabilidad.
  • Principios: proporcionalidad · claridad · transparencia · trazabilidad · responsabilidad · adaptación al riesgo.
  • Más controles ≠ mejor gobernanza.

Cumplimiento (compliance)84

  • Cumplir las obligaciones aplicables al proyecto y al producto. Origen:
  • Legales (datos, PI, normativa sectorial, IA) · de contrato (requisitos del cliente, SLA, licencias, proveedores) · de organización (políticas, procedimientos, estándares) · técnicas (estándares, seguridad, controles de calidad).
  • Cumplir no es simplemente "pasar una auditoría".

Cumplimiento desde el principio85-86

  • Requisito → diseño → implementación → evidencia → verificación. Ej. "los datos personales deben estar protegidos": ¿qué exige? ¿Qué decisión arquitectónica lo garantiza? ¿Cómo se implementa? ¿Qué evidencia? ¿Cómo se verifica?
  • Incumplir provoca retrasos, repetición de trabajo, costes, bloqueo de entregas, incidentes, problemas contractuales, daño reputacional → compliance es un riesgo del proyecto; no sólo al final.

Gobernanza en Agile y DevOps87-88

  • No desaparece, cambia de forma. Antes: plan → aprobación → desarrollo → auditoría. Ahora: planificación continua → desarrollo → controles automatizados → feedback → decisión.
  • Ej.: DoD con requisitos de seguridad · revisiones de código · controles de calidad automáticos · análisis de dependencias · CI/CD con gates · evidencias automáticas · auditoría y trazabilidad.
  • Normas citadas: ISO/IEC 38500, ISO 31000, ISO/IEC 27001, 27701; RGPD, NIS2 y AI Act.

Tema 2 · 7. DevOps y DevSecOps

¿Qué es DevOps?90

  • Desarrollo + operaciones: integrar personas, procesos y herramientas · automatizar build → test → release → deploy → operate · reducir el tiempo entre un cambio y su entrega fiable · feedback continuo · responsabilidad compartida sobre producción.
  • No es una herramienta ni un puesto: es una forma de organizar desarrollo y operación como un flujo continuo.

El ciclo DevOps91-92

  • Bucle infinito: plan · code · build · test · release · deploy · operate · monitor (y vuelta).
  • CI: integrar cambios frecuentemente y validarlos automáticamente.
  • CD: software siempre preparado para entregarse (delivery) o desplegado automáticamente (deployment).
  • IaC: infraestructura mediante código. Observabilidad: logs, métricas y trazas.

Métricas DORA93

  • Deployment Frequency → frecuencia de despliegue.
  • Lead Time for Changes → tiempo hasta entregar un cambio.
  • Change Failure Rate → cambios que provocan fallos.
  • Time to Restore → tiempo para recuperar el servicio.
  • Objetivo: entregar rápido sin sacrificar estabilidad ni calidad. Medir para mejorar el flujo, no para medir a las personas.

DevSecOps94

  • Integración proactiva de la seguridad en DevOps: actividades de seguridad intrínsecas, no fases separadas.
  • Shift left: seguridad desde el diseño y el desarrollo temprano. Automatización: escanear código, dependencias y configuraciones en cada etapa. Colaboración: desarrollo, operaciones y seguridad juntos.
  • CI automatiza construcción y pruebas; CD automatiza el despliegue.

Seguridad en el ciclo (DoD y UMA)95-96

  • Planificación: objetivos y requisitos de seguridad. Diseño: patrones, modelado y validación del diseño. Desarrollo: programación segura, estándares de código, revisiones.
  • Pruebas: SAST, escaneo de vulnerabilidades, DAST, pentesting, pruebas de seguridad. Entrega: entrega segura, seguridad de configuración, IAST.
  • Operación: monitorización, diagnosis, actualizaciones de seguridad, reconfiguración dinámica, auditoría, plan de contingencia, seguridad de uso.

Herramientas97

  • SAST: SonarQube, Checkmarx. SCA: Snyk, Dependabot. DAST: OWASP ZAP, Nessus.
  • Secretos: HashiCorp Vault, AWS Secrets Manager. IaC: Terraform + Terrascan.

Ejemplo y beneficios98-99

  • XSS: SAST lo detecta en el pull request → el desarrollador corrige → CI/CD bloquea el despliegue hasta resolverlo → no llega a producción.
  • Beneficios: detección temprana (ahorra ~80 % vs. post-producción) · cumplimiento (auditorías automatizadas: GDPR, HIPAA) · resiliencia (menos brechas por supply chain).
Conclusiones DevOps y DevSecOps100

Autocomprobación

Sólo con lo que hay en las diapositivas. Responde de memoria antes de mirar.

Enumera las cinco dimensiones del estudio de viabilidad y su pregunta fundamental.

¿Debemos hacer este proyecto? Técnica, económica, temporal, organizativa y legal/regulatoria. (T1, diap. 41)

Enumera las seis restricciones del proyecto y la triada clásica.

Alcance, plazo, coste, calidad, recursos y riesgos. Triada clásica: alcance, tiempo y coste; pero calidad y riesgo no son variables secundarias. (T1, diap. 9-10)

¿Cuáles son las cuatro actividades del proceso de gestión del riesgo y las cinco respuestas a una amenaza?

Identificación, análisis, planificación/tratamiento, seguimiento y control (el ciclo se repite). Respuestas: evitar, mitigar/reducir, transferir/compartir, aceptar y escalar cuando corresponda. (T2, diap. 10, 26)

Según las diapositivas, ¿qué diferencia la reserva de gestión de la de contingencia?

  1. La de gestión cubre riesgos conocidos y la de contingencia los desconocidos
  2. La de gestión cubre incertidumbre no asignada o cambios fuera de la línea base
  3. La de gestión la decide el equipo técnico y la de contingencia el sponsor
  4. La de gestión sólo existe en proyectos ágiles y la de contingencia en cascada
Contingencia = incertidumbre conocida; gestión = incertidumbre no asignada / cambios fuera de la línea base. (T2, diap. 30)

¿Qué tres actividades de la gestión de la calidad distinguen las diapositivas?

  1. Verificación, validación y certificación externa
  2. Diseño, implementación y pruebas de aceptación
  3. Inspección, auditoría y mejora continua del proceso
  4. Aseguramiento, planificación y control de la calidad
Aseguramiento (procedimientos y estándares de la organización), planificación (seleccionarlos y adaptarlos al proyecto) y control (que el equipo los siga). Y la gestión de la calidad, separada de la del proyecto. (T2, diap. 59)

Empareja cada herramienta con su categoría según la diap. 97.

SAST: SonarQube, Checkmarx · SCA: Snyk, Dependabot · DAST: OWASP ZAP, Nessus · Secretos: Vault, AWS Secrets Manager · IaC: Terraform + Terrascan.

EV = 40.000 €, AC = 50.000 €. Calcula el CPI.

CPI = EV / AC = 40.000 / 50.000 = 0,8: por cada euro gastado se obtienen 0,80 € de valor; peor de lo previsto. (T2, diap. 52)

¿Cuáles son las cinco piezas de la gobernanza y en qué se diferencia de la gestión?

Autoridad → responsabilidades → decisiones → controles → información. La gobernanza establece quién tiene autoridad, qué decisiones deben tomarse y bajo qué reglas; la gestión ejecuta el proyecto dentro de ese marco ("la gobernanza define las reglas del juego; la gestión juega el partido"). (T2, diap. 80, 82)

Fuente: diapositivas del Tema 1 (Introducción) y del Tema 2 (Aspectos transversales), curso 2026-27. Para las explicaciones a fondo, ve a las lecciones. Otras hojas: Tema 1 · Tema 2 · Fórmulas · Glosario.