Capítulo 38 — Infraestructura crítica y seguridad sectorial: validación
Mapa de la lección
Lección 38 publicada. Mapa, ejemplo, EX075.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["38.1 La verificación no es validación"]
N2["38.2 La trazabilidad como mapa de evidencia"]
N3["38.3 Validación con las partes interesadas"]
N4["38.4 Informar de resultados parciales"]
N5["38.6 Actividad práctica: laboratorio 14"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX075"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["38.1 La verificación no es validación"]
N2["38.2 La trazabilidad como mapa de evidencia"]
N3["38.3 Validación con las partes interesadas"]
N4["38.4 Informar de resultados parciales"]
N5["38.6 Actividad práctica: laboratorio 14"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX075"]
[Resultados de aprendizaje y conexión]
|
v
[38.1 La verificación no es validación]
|
v
[38.2 La trazabilidad como mapa de evidencia]
|
v
[38.3 Validación con las partes interesadas]
|
v
[38.4 Informar de resultados parciales]
|
v
[38.6 Actividad práctica: laboratorio 14]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX075]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted podrá (1) distinguir la validación (el sistema adecuado para la necesidad) de la verificación (el sistema construido conforme a su especificación); (2) validar con las partes interesadas mediante demostraciones, ensayos operativos y ejercicios; (3) usar la trazabilidad para mostrar qué necesidades están respaldadas por evidencia y cuáles no; y (4) informar con honestidad de los resultados de la validación, incluidos los resultados parciales. Se apoya en los capítulos 16, 24 y 30 y prepara los capítulos 40 y 48.
38.1 La verificación no es validación
Un sistema puede superar todas las pruebas frente a su especificación y aun así fallar a sus usuarios si la especificación era errónea o incompleta. La validación pregunta si el sistema satisface las necesidades de las partes interesadas en su entorno previsto: ¿pueden los operadores manejar de verdad el modo manual local de noche? ¿Recibe de verdad el hospital agua dentro de su reserva cuando se pierde PS4? La evidencia de validación procede del uso realista: ensayos operativos, demostraciones con las partes interesadas, ejercicios y primeros datos de operación.
Para el TMRP, el ejercicio nocturno del modo manual local es la actividad de validación que responde a la primera pregunta.
38.2 La trazabilidad como mapa de evidencia
Trace las necesidades hasta los requisitos, los requisitos hasta las pruebas y las pruebas hasta los resultados. Después, haga tres preguntas: ¿qué requisitos no tienen prueba (afirmaciones no probadas)? ¿Qué pruebas fallaron o no se ejecutaron (afirmaciones no respaldadas)? ¿Qué necesidades dependen solo de requisitos que aún no están verificados (necesidades no validadas)? El laboratorio 14 calcula estas respuestas para el expediente del TMRP. Para el TMRP, las preguntas son concretas. R4 no tiene prueba porque su demostración nunca se programó. R9, la alarma independiente de dosificación, no tiene ninguna prueba: la tabla de requisitos indica una prueba como método de verificación, pero nunca se escribió una prueba para él. La única prueba registrada de R3 es la que falló en v1, y la prueba de R8 no se ha ejecutado. N1 depende de R4, por lo que no puede declararse validada hasta que se realice el ejercicio nocturno. El laboratorio 14 imprime estas lagunas directamente.
38.3 Validación con las partes interesadas
Implique a las personas a las que sirve el sistema. Los operadores validan los procedimientos y las pantallas; el personal de mantenimiento valida la reparabilidad y los repuestos; el hospital valida que las disposiciones de suministro satisfacen sus necesidades; los reguladores validan el razonamiento de cumplimiento. Registre sus hallazgos como registraría los hallazgos de una revisión, con respuestas. Para el TMRP, los operadores validan el procedimiento manual local y las nuevas alarmas de seguridad, el personal de mantenimiento comprueba que las pasarelas pueden sustituirse con repuestos, y el hospital confirma que las disposiciones de suministro y su reserva de cuatro horas satisfacen sus necesidades. Sus hallazgos se incorporan al mismo registro de respuestas que los hallazgos de la revisión de diseño.
38.4 Informar de resultados parciales
Informe del estado de validación por necesidad: validada, parcialmente validada (con lo que falta) o no validada. No redondee al alza. «N1 parcialmente validada: el ensayo de pérdida de PS4 cumplió la reserva de 4 h; la pérdida combinada de PS4 y del alimentador F1 de la red aún no se ha ensayado». El mapa de evidencia del TMRP lo hace concreto: N1 depende de R4, que aún no se ha demostrado, por lo que N1 se declara no validada hasta que se realice el ejercicio nocturno, aunque la mayoría de sus demás requisitos hayan superado sus pruebas. El estado se actualiza después del ejercicio.
38.5 Ejemplo resuelto: mapa de evidencia del TMRP (sintético)
El laboratorio 14 muestra: R4 (operación manual local) no tiene prueba; se planificó como demostración y nunca se programó; R3 tiene una prueba fallida (en v1; la repetición de la prueba en v2 aún no se ha introducido en la matriz); la prueba T6 de R8 no se ha ejecutado. R9 (alarma independiente de dosificación) tampoco tiene prueba: su método de verificación es «Prueba», pero nunca se le asignó un identificador de prueba, de modo que la evidencia de que dispone es una intención de diseño, no un resultado. Verificados: 5 de 9 requisitos (55,6 %). Consecuencia para la validación: N1 (suministro al hospital) depende de R4, por lo que N1 no puede declararse validada; el ejercicio nocturno de operación manual local se programa como actividad de validación. La matriz también pone al descubierto una laguna administrativa (debe registrarse la repetición de T3 en v2), que es exactamente el tipo de incoherencia que encuentran los examinadores y los auditores.
38.6 Actividad práctica: laboratorio 14
# Lab 14 - requirements traceability: what is claimed but not shown? (synthetic TMRP dossier, offline)
REQS = ["R1 auth telemetry", "R2 replay reject", "R3 setpoint bounds", "R4 local manual", "R5 24h hold-up",
"R6 restore 8h", "R7 alarm 60s", "R8 log integrity", "R9 dosing alarm"]
TESTS = {"T1": ["R1"], "T2": ["R1", "R2"], "T3": ["R3"], "T4": ["R5"], "T5": ["R7"], "T6": ["R8"], "T7": ["R6"]}
RESULT = {"T1": "pass", "T2": "pass", "T3": "fail", "T4": "pass", "T5": "pass", "T6": "not run", "T7": "pass"}
ids = [r.split()[0] for r in REQS]
cov = {r: [t for t, rs in TESTS.items() if r in rs] for r in ids}
verified = [r for r in ids if cov[r] and all(RESULT[t] == "pass" for t in cov[r])]
print("untested:", [r for r in ids if not cov[r]])
print("tested but not passing:", [r for r in ids if cov[r] and r not in verified])
print(f"verified {len(verified)}/{len(ids)} = {100*len(verified)/len(ids):.1f}%")
Salida esperada:
untested: ['R4', 'R9']
tested but not passing: ['R3', 'R8']
verified 5/9 = 55.6%
La salida muestra que R4 y R9 no tienen prueba, que R3 y R8 están probados pero no superan las pruebas, y que cinco de los nueve requisitos están verificados. El estado de R3 está desactualizado más que realmente fallido: la repetición de la prueba en v2 se superó, pero nadie la introdujo en la matriz, que es exactamente la laguna administrativa sobre la que advierte el ejemplo resuelto. El EX075 actualiza el mapa. R9 es la lección más difícil: la alarma de dosificación aparece en el conjunto de requisitos, en la tabla de riesgos y en los controles de dosificación, así que parece cubierta, y sin embargo nunca se le asignó una prueba. Una versión anterior de esta matriz omitía R9 por completo de la lista, lo que elevaba la proporción verificada de cinco de nueve a cinco de ocho sin ninguna evidencia nueva. Una matriz debe enumerar todos los requisitos definidos, porque un requisito que omite no puede declararse como no probado.
38.7 Errores comunes y límites
- Llamar «validación» a un conjunto de pruebas superado.
- Partes interesadas consultadas solo al principio.
- Redondear una validación parcial al alza hasta «validada».
- Mapas de evidencia que no se actualizan tras repetir las pruebas.
El propio mapa del TMRP muestra el último error: la repetición de T3 en v2 se superó, pero la matriz nunca se actualizó. Las partes interesadas, como los operadores y el hospital, participan durante todo el proceso, no solo cuando se redactaron los requisitos, y el mapa de evidencia se actualiza cada vez que una repetición de prueba o una demostración produce un resultado, de modo que el estado de validación declarado nunca se adelanta a la evidencia.
Ejercicios — capítulo 38
EX075 — Actualizar el mapa. Objetivo: mantener la trazabilidad. Entradas: laboratorio 14. Pasos: (1) añada T3b (repetición de la prueba en v2) que cubre R3 con resultado «pass» y elimine el vínculo de T3 con R3 por quedar sustituido; (2) añada la demostración T8 que cubre R4 con resultado «pass»; (3) ejecute T6 con resultado «pass»; vuelva a calcular. Evidencia esperada: código y salida. Rúbrica: 3 = ocho de nueve verificados (88,9 %), R9 sigue figurando como no probado porque no existe una prueba de la alarma de dosificación, con una nota de que verificación ≠ validación; 2 = falta un cambio; 1 = no ejecutado; 0 = nada.
EX076 — Plan de validación para N1. Objetivo: planificar la validación con las partes interesadas. Entradas: N1 «el hospital no debe quedarse sin agua > 4 h». Pasos: proponga dos actividades de validación con partes interesadas, condiciones realistas, observaciones y criterios de éxito. Evidencia esperada: plan. Rúbrica: 3 = actividades realistas (ejercicio nocturno de operación manual local con la plantilla real; aislamiento planificado de PS4 con supervisión del hospital), criterios ligados a la reserva de 4 h, partes interesadas nombradas por su función; 2 = criterios vagos; 1 = pruebas rebautizadas como validación; 0 = nada.
Síntesis del capítulo
La verificación pregunta si el sistema se construyó bien; la validación pregunta si es el sistema adecuado. Use la trazabilidad como mapa de evidencia para encontrar afirmaciones no probadas, no respaldadas y no validadas, valide con las personas a las que sirve el sistema en condiciones realistas e informe de los resultados parciales como parciales.
Siga estudiando — capítulo 38 de 50
← Capítulo 37 · Índice de capítulos del curso · Capítulo 39 →
Continúe con la siguiente lección escrita.