Comprenda el V-Model en Systems Engineering: necesidades, requisitos, arquitectura, integración, verificación, validación, V&V, FAT, SAT y criterios de aceptación.
¡Descúbrelo!
El V-Model en Systems Engineering es una representación del ciclo de desarrollo que relaciona la descomposición progresiva de necesidades y requisitos, en el lado izquierdo, con integración, verificación y validación en niveles correspondientes, en el lado derecho. Su valor está en mostrar que los criterios de prueba no deben surgir únicamente al final del proyecto: cada nivel de definición necesita una estrategia correspondiente para demostrar que el sistema fue construido correctamente y que satisface el uso previsto.
El modelo no es una metodología única ni un proceso rígido. Funciona como una estructura conceptual para organizar relaciones entre requisitos de stakeholders, requisitos de sistema, arquitectura, subsistemas, componentes, integración y evidencias de V&V. ISO/IEC/IEEE 15288:2023 no prescribe el V-Model, pero sus procesos de definición, realización, verificación y validación pueden organizarse de forma compatible con esta lógica.
En sistemas complejos, el principal beneficio del V-Model es preservar la trazabilidad entre lo definido durante la bajada del “V” y lo que debe demostrarse durante la subida. Esto reduce la tendencia a tratar commissioning y aceptación como actividades aisladas, desconectadas de las decisiones de ingeniería.
El V-Model conecta definición y evidencia
La lectura más útil del V-Model no es “diseñar primero y probar después”. La idea es que, mientras se definen requisitos y arquitectura, también deben planificarse los métodos de verificación y los criterios de validación.
Cada requisito debe formularse de forma que pueda demostrarse. Cada interfaz crítica debe tener una estrategia de prueba. Cada condición operativa relevante debe generar un escenario de validación.
Un V-Model típico avanza desde necesidades de stakeholders hacia requisitos de sistema, arquitectura y subsistemas, componentes e implementación y luego asciende mediante integración de componentes, verificación de subsistemas, verificación del sistema y validación operacional.
La representación puede variar entre organizaciones, pero el principio permanece: las decisiones de definición poseen actividades de demostración correspondientes.
Verificación y validación son diferentes
La verificación responde si el producto, subsistema o sistema cumple los requisitos especificados. La validación responde si el sistema satisface la necesidad y el uso previsto en su contexto operativo.
Un sistema puede superar todas las pruebas de verificación y aun así fallar en la validación. Esto ocurre cuando los requisitos eran incompletos, incorrectos o no reflejaban la operación real.
| Proceso | Pregunta central | Base de comparación |
| Verificación | ¿Fue construido según lo especificado? | Requisitos y especificaciones |
| Validación | ¿Resuelve la necesidad en el uso previsto? | Necesidades, misiones y escenarios operativos |
Confundir ambos procesos conduce a criterios de aceptación débiles. Demostrar que un equipo cumple su datasheet no prueba que el sistema integrado satisfaga el flujo operativo del usuario.
La bajada del V comienza con las necesidades
El lado izquierdo comienza con stakeholders, necesidades, restricciones y el concepto de operación. Antes de descomponer requisitos, el equipo debe entender qué resultados debe producir el sistema y bajo qué condiciones.
Systems Engineering organiza la transformación entre necesidad, requisito, arquitectura y validación. El V-Model ofrece una forma visual de relacionar esas definiciones con las actividades de demostración.
Las necesidades mal comprendidas propagan errores a todos los niveles inferiores. Pruebas eficientes no corrigen un sistema especificado para resolver el problema equivocado.
Concept of Operations como base de la validación
Concept of Operations (ConOps) describe cómo se utilizará el sistema en operación normal, degradada, mantenimiento, contingencia y otros escenarios relevantes.
Es importante porque la validación debe ocurrir contra el uso real, no solamente contra requisitos aislados. Un sistema de seguridad puede cumplir funciones unitarias y fallar ante pérdida de comunicación, múltiples alarmas simultáneas o cambio de operador.
Definir estos escenarios desde el inicio permite preparar criterios de validación antes de que el sistema esté implantado.
Requisitos de stakeholders y requisitos de sistema
Las necesidades de stakeholders se traducen en requisitos de sistema verificables. Esta transición exige eliminar ambigüedades y definir condiciones medibles siempre que sea posible.
Gestión de Requisitos en Ingeniería ayuda a estructurar identificación, trazabilidad, cambios y criterios de aceptación.
En el V-Model, cada requisito necesita una estrategia de verificación asociada. Si el equipo no puede responder cómo demostrará un requisito, probablemente la redacción sea vaga o el proyecto todavía no haya definido medios de observación adecuados.
Requisitos verificables desde el origen
Un requisito como “el sistema debe tener alta disponibilidad” es insuficiente para verificación. Deben definirse indicador, período de observación, exclusiones, criterios de falla y método de medición.
Lo mismo vale para desempeño, seguridad, interoperabilidad, autonomía, capacidad y recuperación.
Planificar la verificación durante la definición evita descubrir al final que un requisito importante no puede medirse con la instrumentación, arquitectura o datos disponibles.
Arquitectura en el V-Model
Después de los requisitos de sistema, la solución se descompone en arquitectura, subsistemas y componentes. Esta descomposición debe preservar trazabilidad con los requisitos de nivel superior.
System Architecture define funciones, elementos, interfaces y decisiones estructurantes que determinan cómo se realizará el sistema.
En la subida del V, la integración ocurre en niveles correspondientes. Los componentes se combinan en subsistemas; los subsistemas se combinan en el sistema; y el sistema se integra con el entorno operativo.
Descomponer no es solamente dividir el sistema en partes
Una descomposición útil distribuye responsabilidades, requisitos e interfaces. Cada subsistema debe saber qué debe entregar y cómo se demostrará su contribución.
Dividir un sistema únicamente por disciplinas o proveedores puede ocultar funciones transversales. Disponibilidad, seguridad y desempeño suelen depender de más de un paquete.
El V-Model recuerda que la descomposición debe permitir una recomposición verificable durante la integración.
Asignación de requisitos
Los requisitos de sistema se asignan a subsistemas y componentes. Algunos pueden satisfacerse mediante un único elemento; otros requieren contribuciones combinadas.
Una matriz de asignación puede relacionar requisito, elemento responsable, interfaz afectada, método de verificación y nivel de prueba.
| Requisito | Elemento responsable | Nivel de verificación | Método | Evidencia |
| Capacidad de procesamiento | Servidor/aplicación | Subsistema | Prueba | Informe de carga |
| Interoperabilidad | Sistemas A+B | Integración | Demostración/prueba | Logs y procedimiento |
| Autonomía | Energía/UPS | Sistema | Prueba/análisis | Curva y mediciones |
| Operación degradada | Múltiples subsistemas | Validación | Escenario | Informe operativo |
Esta estructura transforma el V-Model en un mecanismo de gobernanza y no solamente en una figura didáctica.
La base del V: implementación y realización
En la parte inferior del V se encuentran las actividades de implementación o realización de componentes. Dependiendo del dominio, esto puede significar fabricación, configuración, desarrollo de software, montaje, instalación o parametrización.
Estas actividades también necesitan controles propios. Inspecciones, pruebas unitarias, FATs y verificaciones de configuración reducen la probabilidad de llevar defectos básicos a niveles superiores de integración.
Cuanto antes se detecte un problema, menor tiende a ser el costo de corrección.
La integración comienza antes del campo
La integración no debe tratarse como una fase final que comienza cuando todos los proveedores terminan sus instalaciones. Necesita estrategia, secuencia, prerrequisitos y entornos definidos desde el diseño.
En sistemas digitales, las integraciones pueden anticiparse en laboratorio. APIs, autenticación, protocolos, flujos e interoperabilidad pueden probarse antes de disponer de la infraestructura definitiva.
En sistemas electromecánicos, FATs, mockups y pruebas de banco pueden validar interfaces antes de la movilización.
Estrategia de integración
La estrategia de integración define orden, dependencias, entornos, simuladores, datos de prueba y criterios de entrada y salida para cada etapa.
Un enfoque incremental suele ser más robusto que integrar todo de una vez. Cuando se incorporan pocos elementos en cada etapa, las fallas son más fáciles de aislar.
La arquitectura determina dependencias; la estrategia de integración transforma esas dependencias en una secuencia de ejecución.
Integración horizontal y vertical
La integración vertical combina niveles de descomposición: componente → subsistema → sistema. La integración horizontal combina elementos del mismo nivel que deben cooperar.
Un sistema de videovigilancia puede requerir integración vertical entre cámaras, red, servidores y VMS, pero también integración horizontal con control de acceso, detección de incendios y directorio corporativo.
El plan de V&V debe cubrir ambos tipos de relación.
Verificación en varios niveles
La verificación no ocurre únicamente en el sistema completo. Componentes, subsistemas, interfaces y el propio sistema pueden tener criterios específicos.
Verificar en niveles menores reduce la incertidumbre. Si una prueba integrada falla, el equipo debe saber si componentes e interfaces ya superaron verificaciones anteriores.
Sin esta disciplina, la prueba de sistema se convierte en un entorno de diagnóstico para problemas que deberían haberse resuelto antes.
Métodos de verificación
Los métodos habituales incluyen inspección, análisis, demostración y prueba. La elección depende de la naturaleza del requisito.
La inspección es adecuada para atributos observables. El análisis puede demostrar condiciones mediante cálculo o simulación. La demostración verifica comportamiento sin medir necesariamente todos los parámetros. La prueba aplica estímulos y compara resultados con criterios.
Puede requerirse más de un método para requisitos críticos.
Cuando requisitos y evidencias no están conectados desde el diseño, la aceptación tiende a depender de interpretación al final. Estructurar la matriz de verificación antes de la implantación permite identificar brechas de testabilidad y criterios incompletos mientras todavía hay tiempo para corregir la ingeniería.
Verification Cross Reference Matrix
La matriz de verificación relaciona requisitos con métodos, niveles, casos y evidencias. Funciona como puente entre el lado izquierdo y el lado derecho del V.
En proyectos grandes, la matriz permite acompañar la cobertura de V&V y detectar brechas antes de la ejecución.
Gestión de Requisitos, Evidencias y Criterios de Aceptación transforma esta lógica en gobernanza de aceptación basada en evidencia.
Criterios de entrada y salida
Cada nivel de integración y prueba debe tener condiciones para comenzar y para considerarse concluido.
Iniciar pruebas integradas con componentes no configurados, firmware no controlado o interfaces provisionales produce resultados difíciles de interpretar.
Los criterios de entrada pueden incluir revisión de configuración, aprobación de pruebas anteriores, disponibilidad del entorno y cierre de pendientes críticos. Los criterios de salida definen éxito, tolerancias y tratamiento de anomalías.
Test procedure y test case
Los casos de prueba describen condiciones y resultados esperados. Los procedimientos detallan secuencia de ejecución, preparación, instrumentos, datos, criterios y registros.
Esta documentación debe derivarse de los requisitos. Procedimientos basados únicamente en funcionalidades conocidas del proveedor pueden dejar requisitos contractuales sin cobertura.
La trazabilidad requisito → caso → resultado es central para el V-Model.
Evidencia de verificación
La declaración de que una “prueba fue realizada con éxito” no es evidencia suficiente en sistemas críticos. El registro debe permitir comprender configuración, condiciones, resultado y responsabilidad.
Los informes pueden incluir identificación del requisito, versión de software, equipos, parámetros, fecha, entorno, resultados medidos, desviaciones y anexos.
Fotografías, logs y archivos nativos complementan la evidencia cuando corresponda.
Defectos, anomalías y retest
Las fallas de prueba deben generar un registro controlado. El objetivo no es únicamente corregir el defecto, sino preservar trazabilidad entre problema, causa, cambio y retest.
Si una corrección modifica arquitectura o configuración, puede ser necesario repetir pruebas ya aprobadas. El análisis de impacto define el alcance de regresión necesario.
Cerrar una anomalía sin verificar efectos colaterales puede introducir fallas en requisitos previamente aprobados.
Validation: demostrar adecuación al uso
La validación se realiza contra la necesidad, misión y uso previsto. Debe involucrar condiciones representativas y stakeholders adecuados.
Un sistema de automatización puede cumplir todos los requisitos funcionales y aun así ser difícil de operar en una emergencia. Un sistema de seguridad puede cumplir desempeño a nivel de componente y fallar en el flujo de respuesta del equipo operativo.
La validación debe probar el sistema como sistema, no simplemente confirmar componentes.
Operational scenarios en la validación
Los escenarios representan recorridos reales: login, operación normal, falla de red, indisponibilidad de servidor, mantenimiento, recuperación, alarmas simultáneas, pérdida de energía u otras condiciones relevantes.
Ayudan a verificar comportamiento emergente, es decir, propiedades que aparecen únicamente cuando múltiples elementos interactúan.
Estos escenarios deben nacer en el ConOps y evolucionar durante el proyecto.
Validación progresiva
Algunas necesidades pueden validarse parcialmente antes de disponer del sistema final. Prototipos, simulaciones, mockups y pruebas de concepto permiten evaluar usabilidad, desempeño o flujos críticos.
Esta anticipación reduce el riesgo de descubrir tarde que un sistema técnicamente correcto no satisface el uso real.
El V-Model no exige que toda la validación ocurra únicamente en la parte superior del V.
V-Model iterativo
Una interpretación rígida del V-Model como secuencia waterfall es inadecuada para muchos proyectos actuales. Systems Engineering utiliza iteración, concurrencia y evolución de baselines.
ISO/IEC/IEEE 15288:2023 admite aplicación iterativa, concurrente y recursiva de procesos al sistema y a sus elementos. Por ello, el V-Model puede aplicarse en ciclos menores y repetidos.
Cada incremento puede tener su propia descomposición, integración y V&V.
V-Model y desarrollo ágil
Los métodos ágiles no eliminan la necesidad de requisitos, arquitectura y V&V. Modifican cadencia y granularidad.
En sistemas que combinan hardware y software, el software puede evolucionar en sprints mientras la infraestructura física sigue gates más largos. El desafío consiste en mantener interfaces y baselines compatibles.
El V-Model puede funcionar como mapa de trazabilidad de alto nivel mientras los equipos ejecutan ciclos iterativos dentro de cada componente.
V-Model y MBSE
MBSE — Model-Based Systems Engineering puede hacer explícitas las relaciones del V-Model en un modelo estructurado.
Los requisitos pueden conectarse con elementos de arquitectura, casos de verificación y evidencias. Los cambios pueden indicar qué pruebas necesitan repetirse.
El V-Model proporciona la lógica de correspondencia; MBSE puede proporcionar el entorno de trazabilidad.
V-Model y commissioning
Commissioning posee una relación fuerte con la subida del V porque verifica instalación, funcionamiento, integración y readiness del sistema.
Sin embargo, commissioning no sustituye toda la verificación. Muchos requisitos deben demostrarse en fábrica, laboratorio, análisis o inspección antes del SAT.
Si todo el V&V se pospone hasta commissioning, el proyecto transfiere problemas de ingeniería a una fase costosa y presionada por el cronograma.
FAT, SAT y pruebas integradas
Factory Acceptance Test (FAT) verifica elementos o subsistemas antes del envío o implantación. Site Acceptance Test (SAT) verifica el comportamiento en el entorno de instalación. Las pruebas integradas evalúan la interacción entre subsistemas.
Estos nombres no definen automáticamente el alcance. Cada contrato debe establecer qué requisitos están cubiertos, qué configuración se utiliza y qué evidencias serán aceptadas.
El V-Model ayuda a posicionar cada prueba dentro de la estrategia global de verificación.
Handover y aceptación
La aceptación debería ser consecuencia de requisitos demostrados, no una inspección subjetiva al final.
Cuando la matriz de V&V, resultados, pendientes y evidencias están organizados, el handover puede mostrar claramente qué fue verificado, qué fue validado y qué excepciones permanecen abiertas.
El Acta de Aceptación Técnica formaliza esta transición cuando se satisfacen los criterios contractuales.
En sistemas contratados mediante múltiples paquetes, cada proveedor puede demostrar su propio alcance y aun así permanecer una brecha de desempeño end-to-end. La coordinación del Owner debe conectar requisitos sistémicos, interfaces y pruebas entre contratos diferentes.
V-Model en contratos con múltiples proveedores
Cada proveedor puede tener su propio plan de pruebas, pero el Owner necesita una estrategia integrada. Los requisitos sistémicos no pueden desaparecer en las fronteras de los contratos.
Un proveedor prueba el equipo; otro prueba la red; un tercero prueba el software. Aun así, alguien debe demostrar que la función final funciona end-to-end.
Owner’s Engineering puede coordinar esta visión transversal y mantener trazabilidad entre requisitos y evidencias de los distintos paquetes.
Responsabilidad por la integración
Los contratos deben aclarar quién proporciona el entorno de prueba, simuladores, datos, accesos, herramientas y recursos necesarios para la integración.
También deben definir quién lidera las pruebas de interfaces y quién corrige los problemas cuando la causa está en la interacción entre dos proveedores.
Sin esta definición, el V&V sistémico puede transformarse en una disputa de fronteras.
V-Model y gestión de cambios
Un cambio en el lado izquierdo modifica obligaciones en el lado derecho. Si cambia un requisito, elemento de arquitectura o interfaz, también pueden necesitar actualización los casos de verificación y validación.
Engineering Change Management debe analizar también los impactos sobre V&V.
La pregunta no es únicamente “¿qué debe rediseñarse?”, sino “¿qué debe probarse nuevamente para demostrar que la nueva configuración cumple los requisitos?”.
Regression testing
Regression testing verifica que un cambio no haya comprometido funciones previamente aprobadas. En sistemas interdependientes, una corrección local puede afectar el comportamiento de otro subsistema.
La arquitectura y la trazabilidad de requisitos ayudan a seleccionar un conjunto de pruebas de regresión proporcional al impacto.
Repetir todas las pruebas puede ser costoso; repetir muy pocas puede dejar riesgo residual. La decisión debe ser técnica.
Baseline de configuración durante V&V
Los resultados de prueba son válidos únicamente para la configuración probada. Firmware, software, parametrización, hardware, topología y documentos deben identificarse.
Si el sistema cambia después de la prueba, la organización debe evaluar si el resultado anterior continúa siendo aplicable.
Este vínculo entre evidencia y configuración es esencial para auditoría y aceptación.
Independencia en la verificación
Los sistemas críticos pueden requerir algún grado de independencia entre quien desarrolla y quien verifica. El nivel depende del riesgo, contrato, normas y criticidad.
Independencia no significa excluir al equipo de desarrollo; significa asegurar una revisión objetiva y evitar que premisas no cuestionadas contaminen la evaluación.
Owner’s Engineering, QA/QC o un tercero independiente pueden desempeñar funciones de verificación en determinados contextos.
Readiness Reviews
Antes de pruebas relevantes, los Test Readiness Reviews pueden evaluar si sistema, documentación, configuración, entorno y equipo están preparados.
La revisión reduce desperdicio de ventanas de prueba y evita producir resultados inválidos por falta de prerrequisitos.
En proyectos con movilización costosa o indisponibilidad operativa restringida, este gate puede ser decisivo.
V&V como parte de la planificación del proyecto
Verificación y validación consumen recursos, entornos, equipos, personas y tiempo. Por ello, deben aparecer en el cronograma y presupuesto desde el inicio.
Las fechas de integración dependen de la disponibilidad de componentes y entornos. Las correcciones y retests requieren contingencia.
Los proyectos que reservan solamente “algunos días de pruebas” al final suelen subestimar la complejidad de V&V.
Indicadores de V&V
Cobertura de requisitos, tasa de aprobación en primera ejecución, cantidad de anomalías abiertas, antigüedad de pendientes, pruebas bloqueadas y requisitos sin evidencia son indicadores útiles.
La interpretación debe considerar criticidad. Una única falla en un requisito de seguridad puede ser más relevante que decenas de casos menores aprobados.
El objetivo del indicador es apoyar decisiones sobre readiness, no producir un porcentaje artificial de avance.
Errores frecuentes al aplicar el V-Model
Un error es tratar el modelo como waterfall inflexible. Otro es redactar requisitos y pensar en las pruebas únicamente cuando el sistema ya está terminado.
También son comunes las matrices de V&V sin evidencias reales, casos de prueba basados en funcionalidades del fabricante en vez de requisitos, ausencia de registros de configuración de los ítems probados y validación reducida a capacitación del usuario.
El V-Model pierde valor cuando se convierte únicamente en un gráfico dentro de un procedimiento corporativo.
Cuándo el V-Model aporta mayor valor
El enfoque es especialmente útil en sistemas con múltiples niveles de descomposición, gran número de requisitos, interfaces críticas, alta exigencia de trazabilidad y elevado costo de fallas tardías.
También ayuda en proyectos regulados o contractuales donde la aceptación debe sustentarse mediante evidencia objetiva.
Los proyectos menores pueden aplicar los mismos principios mediante una matriz simple de requisitos y verificación sin formalizar toda la estructura.
Consideraciones finales
El V-Model organiza una disciplina esencial de Systems Engineering: lo que se define debe poseer una forma correspondiente de ser demostrado. Las necesidades conducen a validación; los requisitos conducen a verificación; la arquitectura orienta integración; la configuración sostiene la validez de las evidencias.
Su uso más valioso no está en la forma gráfica, sino en la trazabilidad que crea entre definición y demostración. Cuando V&V se planifica desde el inicio, los problemas de requisitos, interfaces y testabilidad aparecen antes de la implantación.
En sistemas complejos, esta lógica transforma pruebas y commissioning de actividades finales en parte integral del proceso de ingeniería, mejorando previsibilidad, calidad técnica y objetividad de la aceptación.
Referencias técnicas
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; IEC; IEEE. ISO/IEC/IEEE 15288:2023 — Systems and software engineering — System life cycle processes. Geneva: ISO, 2023. Disponible en: https://www.iso.org/standard/81702.html
[2] NASA. NASA Systems Engineering Handbook. NASA/SP-2016-6105 Rev2. Washington, DC: NASA, 2016. Disponible en: https://www.nasa.gov/reference/systems-engineering-handbook/
[3] NASA. NASA-HDBK-1009A — NASA Systems Modeling Handbook for Systems Engineering. Washington, DC: NASA, 2025. Disponible en: https://standards.nasa.gov/standard/NASA/NASA-HDBK-1009
[4] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; IEC; IEEE. ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering. Geneva: ISO, 2018. Disponible en: https://www.iso.org/standard/72089.html
Preguntas frecuentes
¿Qué es el V-Model en Systems Engineering?
Es una representación que relaciona la descomposición de necesidades, requisitos y arquitectura con integración, verificación y validación en niveles correspondientes.
¿El V-Model es lo mismo que waterfall?
No. Aunque puede aplicarse de forma secuencial, sus principios también pueden utilizarse iterativamente y en ciclos incrementales. ISO 15288 admite procesos iterativos, concurrentes y recursivos.
¿Cuál es la diferencia entre verificación y validación?
La verificación confirma el cumplimiento de requisitos especificados; la validación confirma que el sistema satisface la necesidad y el uso previsto en su contexto operativo.
¿Cómo se relaciona el V-Model con MBSE?
El V-Model proporciona la correspondencia entre definición y V&V; MBSE puede representar estas relaciones en un modelo estructurado conectando requisitos, arquitectura, pruebas y evidencias.
¿FAT y SAT forman parte del V-Model?
Pueden formar parte de la estrategia de verificación según los requisitos y niveles de integración. El nombre de la prueba por sí solo no define qué requisitos están cubiertos.
¿Por qué planificar la verificación desde la etapa de requisitos?
Porque ayuda a redactar requisitos verificables, definir instrumentación y entornos necesarios y evitar descubrir al final que criterios importantes no pueden demostrarse.
Materiales técnicos complementarios
Contenidos principales sobre el tema
- Systems Engineering: requisitos, arquitectura, interfaces, integración y validación
- System Architecture para sistemas complejos
- MBSE — Model-Based Systems Engineering para sistemas complejos
Contenidos técnicos relacionados
- Gestión de Requisitos en Ingeniería
- Aceptación Técnica en Ingeniería
- Engineering Change Management (ECM)
Soluciones relacionadas
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
- Gestión de Contratos, Alcance y Entregables
