Curso · Temas 1 y 2 · Lección 19 de 19

Simulacro de examen: todo mezclado

Cuarenta y dos preguntas intercaladas de las lecciones 1 a 18, en el formato del parcial: respuesta única, múltiple, emparejar, verdadero/falso, cálculo y respuesta corta. Sin contenido nuevo: aquí se entrena la recuperación.

Cómo hacerlo para que sirva
  1. En condiciones de examen: sin mirar las lecciones ni las referencias, de una sentada (unos 60 minutos).
  2. Las preguntas están mezcladas a propósito: el examen no te avisa de qué tema es cada pregunta, y tener que reconocerlo es parte de la habilidad (práctica intercalada).
  3. En las de respuesta corta, escribe la respuesta completa antes de ver la modelo, y autoevalúate con honestidad.
  4. Al terminar, apunta las que fallaste. Cada explicación indica la lección (→ Ln): repasa esa sección y vuelve a hacer el simulacro dentro de dos o tres días. Recordar con esfuerzo, espaciado en el tiempo, es lo que fija el conocimiento a largo plazo.
Qué se parece al examen y qué no

El formato imita el de los exámenes de Moodle de años anteriores (respuesta única y múltiple, emparejar, V/F) y lo que dice la motivación del curso: preguntas cortas de aplicar, no de memorizar definiciones. El contenido cubre los Temas 1 y 2 completos, incluidas las ampliaciones universales. No es un examen real del profesor: úsalo para detectar huecos, no para predecir preguntas.

Parte A · Test

Un banco encarga "rediseñar la app de clientes para cumplir la nueva normativa de accesibilidad antes de junio". ¿Qué es esto?

  1. Una operación, porque la app de clientes ya existe y se mantiene
  2. Un proyecto, porque es temporal y produce un resultado único
  3. Un programa, porque afecta a varios departamentos del banco
  4. Un portfolio, porque responde a un objetivo estratégico del banco
Tiene fin (junio) y un resultado único (la app rediseñada): proyecto. Mantener la app día a día sí sería operación. → L1

Empareja cada concepto con su definición.

  • Proyectos relacionados gestionados de forma coordinada para un beneficio común
  • Proyectos y programas, no necesariamente relacionados, alineados con la estrategia
  • Documento que autoriza formalmente el proyecto
  • Documento que justifica si merece la pena hacer el proyecto
  • Documento con el que un cliente solicita propuestas a proveedores
Programa = coordinación para un beneficio que por separado no se lograría. Portfolio = selección y alineamiento estratégico. Charter autoriza; business case justifica; RFP solicita. → L2, L3

Un riesgo de TusBus: "Debido a que dependemos del ayuntamiento, podría retrasarse el acceso a la API de GPS". El equipo crea un simulador de la API para que la app avance sin ella. ¿Qué es esa acción?

  1. Una contingencia, porque sólo se usa si la API se retrasa
  2. Una transferencia, porque traslada el riesgo a otra pieza
  3. Una mitigación, porque reduce el impacto antes del evento
  4. Una evitación, porque elimina por completo la dependencia
Se construye antes y reduce el impacto de un posible retraso (la app no se bloquea): mitigación. Contingencia sería, por ejemplo, "si en la semana 3 no hay API, lanzar con horarios teóricos". → L13

¿Qué afirmaciones sobre la estimación son correctas?

  1. Una estimación no es una promesa ni un compromiso
  2. La estimación PERT coincide siempre con el valor más probable
  3. Al inicio del proyecto el error puede ir de 0,25× a 4×
  4. La estimación ascendente necesita una EDT detallada
  5. Si el cliente pide menos plazo, hay que bajar la estimación
PERT pondera O, M y P y suele quedar por encima de M. La estimación no se negocia; se negocian alcance, recursos o fecha. → L10

Verdadero o falso: "En el PMBOK, los procesos de Planificación terminan antes de que empiecen los de Ejecución y los de Monitoreo y Control".

  1. Verdadero
  2. Falso
Los grupos de procesos se solapan e iteran durante todo el proyecto: se replanifica mientras se ejecuta y se controla. → L2, L11

¿A qué área de conocimiento del PMBOK 6 pertenece cada acción?

  • Hacer una matriz de trazabilidad de los requisitos
  • Revisión entre pares del documento de arquitectura
  • Enviar el informe de estado a todos los implicados
  • Redactar un pliego de condiciones para externalizar una parte
  • Reunirse porque la tecnología es compleja y no la conocemos
  • Controlar que no se supera el presupuesto definido
Preguntas de este tipo salieron en exámenes antiguos. Trazabilidad = alcance; revisión entre pares = calidad; informe de estado = comunicaciones; RFP/pliego = adquisiciones; incertidumbre tecnológica = riesgos; presupuesto = costes. → L2

¿Cuál de estos requisitos no funcionales es verificable?

  1. La aplicación será muy segura frente a cualquier tipo de ataque
  2. La aplicación responderá con rapidez incluso en horas punta
  3. La aplicación será intuitiva para usuarios de todas las edades
  4. El 95 % de las consultas responderá en menos de 300 ms con 500 usuarios
Sólo (d) tiene una condición medible que una prueba puede comprobar. → L4

En MoSCoW, ¿qué indica que un requisito esté en "Could"?

  1. Que es imprescindible y sin él la entrega no tiene sentido
  2. Que es importante pero existe una alternativa temporal
  3. Que es deseable y se hará sólo si hay tiempo y recursos
  4. Que se ha decidido no hacerlo en la entrega actual
Must = imprescindible; Should = importante con alternativa; Could = deseable si hay margen; Won't = no en esta entrega. → L5

Un proyecto tiene CPI = 1,15 y SPI = 0,85. ¿Cómo va?

  1. Con sobrecoste y adelantado respecto al plan
  2. Por debajo de coste y retrasado respecto al plan
  3. Con sobrecoste y retrasado respecto al plan
  4. Por debajo de coste y adelantado respecto al plan
CPI > 1 = gastamos menos de lo presupuestado por el trabajo hecho; SPI < 1 = hemos hecho menos de lo previsto. Típico de un equipo con menos gente de la planificada. → L14

¿Qué ciclo de vida recomendarías en cada caso?

  • Adaptar un sistema a una norma técnica oficial cerrada, con tecnología conocida
  • Una startup que aún no sabe qué funciones querrán sus usuarios
  • Hardware con fechas contractuales fijas y una app cuyo diseño evolucionará
  • Un sistema crítico con un riesgo tecnológico muy alto que hay que reducir por etapas
La elección depende del contexto: estabilidad de requisitos, incertidumbre, riesgo, restricciones contractuales. → L7

Al revisar el registro, el JP ve: "El servidor de integración lleva dos días caído". ¿Qué error se ha cometido si figura como riesgo?

  1. Le falta la probabilidad expresada en porcentaje exacto
  2. Es un problema ya ocurrido, no un riesgo; va a otro registro
  3. Debería estar formulado como una oportunidad del proyecto
  4. No tiene ningún error, porque los fallos técnicos son riesgos
"Confundir riesgo con problema ya ocurrido" es uno de los errores frecuentes. Si ya pasó, es un problema (issue). → L11, L12

¿Cuáles son métricas DORA de las diapositivas?

  1. Frecuencia de despliegue
  2. Líneas de código por persona
  3. Tasa de fallo de cambios
  4. Porcentaje de cobertura de pruebas
  5. Tiempo de recuperación del servicio
  6. Tiempo de entrega de un cambio
Deployment frequency, lead time for changes, change failure rate, time to restore. Medir el flujo, no a las personas. → L18

El cuadrante de Fowler: un equipo sin experiencia escribe un diseño enrevesado sin saber que existe una forma mejor. ¿Qué deuda es?

  1. Deliberada y prudente
  2. Deliberada e imprudente
  3. Inadvertida y prudente
  4. Inadvertida e imprudente
No lo saben (inadvertida) y no aplican buenas prácticas básicas ("¿qué es el diseño por capas?"): imprudente. La inadvertida prudente es "ahora sabemos cómo deberíamos haberlo hecho". → L8

¿Cuál es la diferencia entre la reserva de contingencia y la reserva de gestión?

  1. La de contingencia cubre riesgos identificados; la de gestión, lo no identificado
  2. La de contingencia la controla la dirección; la de gestión, el jefe de proyecto
  3. La de contingencia está fuera de la línea base; la de gestión, dentro de ella
  4. La de contingencia se usa en ágil; la de gestión, en proyectos predictivos
Contingencia: known unknowns, dentro de la línea base, la usa el JP. Gestión: unknown unknowns, fuera de la línea base, la controla la dirección. → L13, L14

¿Aseguramiento, planificación o control de la calidad?

  • Definir los estándares de codificación de toda la empresa
  • Elegir qué estándares aplican a este proyecto y adaptarlos
  • Comprobar que el equipo sigue los estándares acordados
Aseguramiento = establecer (organización); planificación = seleccionar y adaptar (proyecto); control = garantizar que se siguen. → L15

El sponsor está muy ocupado y apenas sigue el proyecto, pero puede cancelarlo. Según la matriz poder/interés, ¿qué estrategia aplicas?

  1. Gestionar de cerca, con reuniones semanales
  2. Mantener informado con todos los detalles
  3. Mantener satisfecho, sin saturarle de información
  4. Monitorizar con el mínimo esfuerzo posible
Poder alto + interés bajo → mantener satisfecho. Si su interés sube (p. ej., por un riesgo grave), pasa a gestionar de cerca. → L8

A mitad del proyecto, un desarrollador añade por su cuenta una animación que nadie pidió. ¿Cómo se llama?

  1. Scope creep
  2. Gold plating
  3. Fast tracking
  4. Rolling wave
Gold plating: el equipo añade lo no pedido. Scope creep: el alcance crece sin control por peticiones (normalmente del cliente). → L3

Empareja cada técnica de análisis de seguridad con lo que analiza.

  • El código fuente propio, sin ejecutarlo
  • La aplicación en ejecución, atacándola desde fuera
  • Las dependencias de terceros y sus licencias
  • La aplicación instrumentada por dentro mientras se prueba
Static (código) / Dynamic (ejecución) / Composition (dependencias) / Interactive (instrumentación). → L18

Ante el retraso, el JP añade tres programadores nuevos a un módulo muy acoplado a dos semanas de la entrega. ¿Qué es lo más probable?

  1. El módulo se termina en un tercio del tiempo previsto inicialmente
  2. El módulo se termina antes, aunque con algo más de coste
  3. El módulo se retrasa más por la incorporación y la coordinación
  4. El módulo no cambia, porque el plazo ya estaba fijado de antes
Ley de Brooks: incorporación, más canales de comunicación, tareas no divisibles. → L16

¿Qué actividades forman parte del cierre del proyecto?

  1. Verificar la aceptación de los entregables
  2. Cerrar contratos y documentación
  3. Identificar a los stakeholders del proyecto
  4. Transferir conocimiento y operación
  5. Crear la estructura de desglose del trabajo
  6. Registrar las lecciones aprendidas
Identificar stakeholders es de inicio; la EDT, de planificación. Cierre: aceptación, contratos, transferencia, lecciones aprendidas, liberar recursos, celebrar. → L11

¿Qué distingue la gobernanza de la gestión?

  1. La gobernanza se ocupa de la tecnología; la gestión, de las personas
  2. La gobernanza define quién decide y con qué reglas; la gestión ejecuta
  3. La gobernanza sólo existe en la administración pública; la gestión, en empresas
  4. La gobernanza se hace al inicio; la gestión, al final del proyecto
"La gobernanza define las reglas del juego; la gestión juega el partido." → L17

El estudio de viabilidad de TusBus concluye: técnicamente posible, pero el ayuntamiento no tiene a nadie para publicar incidencias ni mantener la app. ¿Qué viabilidad falla?

  1. La técnica
  2. La económica
  3. La temporal
  4. La organizativa
Organizativa (operativa): ¿la organización puede adoptarlo y operarlo? → L6

¿Qué técnica de identificación de riesgos está pensada específicamente para vencer el exceso de confianza?

  1. Checklists y taxonomías
  2. Análisis premortem
  3. Matriz probabilidad-impacto
  4. Análisis de sensibilidad
El premortem imagina que el proyecto ya ha fracasado y busca por qué. La matriz y la sensibilidad son de análisis, no de identificación. → L12

Verdadero o falso: "Según la investigación DORA y las diapositivas, desplegar con más frecuencia supone necesariamente sacrificar estabilidad".

  1. Verdadero
  2. Falso
Velocidad y estabilidad no son un trade-off: los mejores equipos tienen ambas. → L18

Un ADR aprobado hace un año ya no refleja la arquitectura porque se cambió la base de datos. ¿Qué se hace?

  1. Editar el ADR antiguo con la nueva decisión
  2. Borrar el ADR antiguo porque ya no aplica
  3. Escribir un ADR nuevo que sustituye al antiguo
  4. Nada, los ADR sólo valen al inicio del proyecto
Los ADR son inmutables: el nuevo sustituye al antiguo, que queda marcado. Así se conserva el porqué de cada momento. → L6

¿Qué afirmaciones sobre ISO/IEC 25010 y la calidad son correctas?

  1. En ISO 25010 la seguridad es una característica de calidad propia
  2. Calidad del software significa únicamente ausencia de defectos
  3. Un buen proceso influye en la calidad del producto, pero no la garantiza
  4. La versión de 2023 añade la característica "safety"
  5. La verificación comprueba si el producto satisface al usuario real
La seguridad (security) es característica propia; calidad hoy es TQM, no sólo ausencia de defectos; proceso y producto tienen una relación compleja; 2023 añade safety; satisfacer al usuario es validación. → L15

Un equipo de soporte con peticiones continuas tiene a cada persona con seis tareas abiertas a la vez. ¿Qué recomienda el temario?

  1. Planificar por horas con un diagrama de Gantt semanal
  2. Limitar el trabajo en curso (WIP) por persona y equipo
  3. Asignar a cada persona el 100 % de su capacidad disponible
  4. Añadir personas hasta que el número de tareas abiertas baje
WIP limitado: terminar antes de empezar. Asignar el 100 % genera atascos. → L16

¿A qué norma pertenece cada obligación?

  • Protección de datos desde el diseño y por defecto
  • Responsabilidad de la dirección en ciberseguridad de entidades esenciales
  • Clasificación de los sistemas de IA por niveles de riesgo
  • Sistema de gestión de la seguridad de la información certificable
RGPD (datos personales), NIS2 (ciberseguridad de sectores críticos), AI Act (IA por riesgo), ISO/IEC 27001 (SGSI, voluntaria y certificable). → L17

¿Qué significa que un proyecto sea "temporal" según la definición del PMI?

  1. Que dura poco tiempo, normalmente menos de un año
  2. Que tiene un inicio y un final definidos
  3. Que su resultado también es temporal y desaparece
  4. Que su equipo trabaja a tiempo parcial en él
Temporal = termina, no "corto". El resultado puede durar décadas. → L1

Parte B · Cálculo

Red para las dos preguntas siguientes (semanas, dependencias fin-inicio): A 3 (—) · B 2 (A) · C 6 (A) · D 4 (B) · E 1 (C, D).

¿Cuál es la duración mínima del proyecto?

Caminos: A-B-D-E = 3 + 2 + 4 + 1 = 10; A-C-E = 3 + 6 + 1 = 10. Ambos son críticos: 10 semanas. → L9

¿Cuánta holgura tiene la actividad B?

Los dos caminos duran 10: hay dos caminos críticos y B está en uno de ellos → holgura 0. Cualquier retraso en B retrasa el proyecto. → L9

Estimación de tres puntos de una tarea: O = 6, M = 11, P = 22 días. ¿Cuál es la estimación PERT?

(6 + 44 + 22) / 6 = 72 / 6 = 12 días. σ = (22 − 6)/6 ≈ 2,67. → L10

Un riesgo tiene una probabilidad del 30 % y un impacto de 15.000 € si ocurre. ¿Cuál es su EMV? (Amenaza, en negativo.)

0,30 × (−15.000) = −4.500 €. → L13

Datos para las tres preguntas siguientes: BAC = 80.000 €. A fecha de hoy, PV = 40.000 €, EV = 36.000 €, AC = 45.000 €.

¿Cuál es el CPI?

36.000 / 45.000 = 0,8. → L14

¿Cuál es la variación del cronograma (SV)?

SV = EV − PV = 36.000 − 40.000 = −4.000 € (retraso: SPI = 0,9). → L14

¿Cuál es la EAC si la eficiencia de coste actual se mantiene?

EAC = BAC / CPI = 80.000 / 0,8 = 100.000 €. VAC = −20.000 €. → L14

¿Cuántos canales de comunicación hay en un equipo de 10 personas?

10 · 9 / 2 = 45. → L11, L16

Parte C · Respuesta corta

Formula un riesgo con la estructura causa → evento → consecuencia para una app de citas médicas que depende de un proveedor externo de SMS, e indica una mitigación, una contingencia y un KRI.

Causa: el envío de recordatorios depende de un único proveedor externo de SMS. Evento: el proveedor sufre una caída prolongada o cambia sus condiciones. Consecuencia: los pacientes no reciben recordatorios → aumentan las citas perdidas, objetivo de negocio incumplido, quejas. Mitigación: acuerdo con SLA y penalizaciones, abstraer el envío tras una interfaz para cambiar de proveedor fácilmente, notificaciones push como canal adicional. Contingencia: proveedor alternativo contratado y configurado; disparador: caída de más de 1 hora. KRI: tasa de SMS fallidos o latencia de entrega (umbral: > 2 % en un día). → L12, L13

Un proyecto lleva el 40 % del plazo, CPI = 0,9, SPI = 0,8. Interprétalo y propón qué decisiones llevarías al sponsor.

Va por encima de coste (por cada euro gastado se obtiene 0,90 € de trabajo; si sigue así, EAC = BAC/0,9 ≈ +11 %) y con retraso (se ha hecho el 80 % de lo previsto a esta fecha). Es el peor cuadrante. Primero, buscar la causa (estimación optimista, retrabajo, dependencias, falta de personas). Decisiones a plantear: reducir alcance priorizando (Must primero, Could fuera), usar reserva de contingencia si la causa es un riesgo identificado, aprobar una nueva línea base con control de cambios si el plan era irreal, o mover la fecha. No añadir gente sin más (ley de Brooks) ni recortar calidad en silencio. Y decidirlo de forma explícita con el sponsor. → L14, L11, L1

Una administración pública quiere una sede electrónica: requisitos legales cerrados y estables, pero el diseño de la experiencia de usuario es incierto. ¿Qué ciclo de vida propondrías y cómo gestionarías el cumplimiento?

Híbrido: la parte regulada (requisitos legales, integración con sistemas existentes, seguridad) con planificación predictiva e hitos fijos; la experiencia de usuario de forma iterativa/ágil, con prototipos validados con ciudadanos reales. Cumplimiento desde el principio: identificar obligaciones (RGPD, ENS, accesibilidad RD 1112/2018, contratos), convertirlas en requisitos verificables y trazables (requisito → diseño → implementación → evidencia → verificación), y automatizar controles y evidencias en el pipeline (gates, análisis de seguridad, pruebas de accesibilidad). Gobernanza clara: quién aprueba cambios de alcance y quién acepta. → L7, L17

Explica la diferencia entre DevOps y DevSecOps y por qué "shift left" ahorra dinero. Pon un ejemplo.

DevOps organiza desarrollo y operación como un flujo continuo y automatizado (build → test → release → deploy → operate, con feedback y responsabilidad compartida). DevSecOps integra la seguridad como parte intrínseca de ese flujo (no como fase final): shift left, automatización de escaneos en cada etapa y colaboración con seguridad. Shift left ahorra porque el coste de corregir un defecto crece cuanto más tarde se detecta. Ejemplo: SAST detecta un XSS en el pull request, el desarrollador lo corrige en minutos y el pipeline bloquea el despliegue hasta entonces; descubierto en producción supondría parche urgente, posible brecha, notificación RGPD en 72 h y daño reputacional. → L18

Un compañero dice: "Lo importante es cumplir plazo y presupuesto; lo demás es secundario". Rebátelo con lo visto en el curso.

El éxito moderno incluye valor para el negocio y el usuario, calidad y sostenibilidad (incluida la seguridad), la deuda técnica que se deja, la satisfacción de los stakeholders y el cumplimiento legal y organizativo. Un proyecto en plazo y presupuesto que nadie usa, que guarda datos sin consentimiento o cuyo código nadie se atreve a tocar es un fracaso. Además, las restricciones compiten (alcance, plazo, coste, calidad, recursos, riesgo): blindar plazo y coste suele sacrificar calidad en silencio y generar deuda imprudente, cuyo coste (TCO, mantenimiento) aparece después. Lo correcto es equilibrarlas de forma explícita. → L1, L8, L14

Después del simulacro

Qué hacer con los fallos
  • Cada explicación indica la lección (→ Ln). Repasa esa sección, no la lección entera.
  • Para lo que falles de concepto, usa las hojas de repaso: Glosario · Fórmulas · Fundamentos (Tema 1) · Aspectos transversales (Tema 2).
  • Vuelve a hacer el simulacro en dos o tres días, y también los bloques de "Repaso espaciado" de cada lección.
¿Dudas?

Pide a un asistente un simulacro nuevo "con el estilo de esta página" sobre los temas en los que más hayas fallado, o que te plantee escenarios de proyecto (startup, consultora, administración pública, open source, equipo con IA) para decidir qué harías. Y lleva a tutoría cualquier duda sobre qué espera exactamente el profesor (p. ej., las discrepancias de las diapositivas señaladas en las lecciones 15 y 16).