El desarrollo de software con modelo en V es una forma secuencial de construir software en la que cada fase de desarrollo tiene una fase de pruebas correspondiente, y la prueba de cada fase se planifica al mismo tiempo que la propia fase. El modelo se dibuja como una letra V: el trabajo de diseño desciende por el brazo izquierdo, la codificación está en el fondo y las pruebas ascienden por el brazo derecho. Suena a idea de la década de 1990, y lo es. Sin embargo, en 2026 sigue sustentando las auditorías en automoción, productos sanitarios, aviónica y TI del sector público, porque los reguladores de esos campos quieren pruebas de que cada requisito fue probado.
Esa prueba es la razón por la que la V sobrevive. Un equipo moderno puede entregar en sprints de dos semanas, pero cuando llega un evaluador de ISO 26262 o un revisor de la FDA, piden una cadena que vaya de cada requisito a su diseño, su código y su resultado de prueba. Esa cadena es exactamente lo que produce la V. Es también la razón por la que la mayoría de los equipos que prestan servicios de desarrollo de software empresarial para sectores regulados siguen estructurando sus evidencias de pruebas en torno a la V, incluso cuando el trabajo diario se realiza en sprints.
Esta guía explica el modelo en V del desarrollo de software desde los primeros principios: qué hace cada lado de la V, un diagrama de texto que se puede copiar, un ejemplo resuelto de trazabilidad de requisitos, una lista sincera de ventajas y desventajas, una comparación con cascada, Agile y el modelo en W, y una visión práctica de cuándo es la V la elección adecuada y cuándo no.
¿Qué es el desarrollo de software con modelo en V?
El desarrollo de software con modelo en V es un ciclo de vida de desarrollo de software guiado por el plan en el que cada fase de desarrollo del lado izquierdo de la V está vinculada a un nivel de pruebas del lado derecho que la comprobará más tarde. El lado izquierdo es la verificación: ¿estamos construyendo bien el producto? El lado derecho es la validación: ¿estamos construyendo el producto correcto? La codificación se sitúa en el vértice, donde se encuentran los dos lados.
Por lo general, el modelo se describe como una extensión del modelo en cascada. La cascada ejecuta las fases una tras otra y deja las pruebas para casi el final. La V mantiene la misma secuencia de construcción, pero dobla la línea hacia arriba tras la codificación, de modo que cada nivel de pruebas queda frente a la fase de diseño que valida. Kevin Forsberg y Harold Mooz popularizaron la forma de V para la ingeniería de sistemas en un artículo de 1991. Desde entonces ha sido adoptado por la industria de productos sanitarios, utilizado en la guía de ingeniería de sistemas de la Administración Federal de Carreteras de EE. UU. y formalizado en el estándar federal alemán V-Modell XT para proyectos de TI del sector público.
Si desea situar la V entre otros enfoques, pertenece a la familia guiada por el plan del ciclo de vida del desarrollo de software, junto a la cascada y frente a la familia iterativa que incluye Scrum y Kanban. Nuestro resumen de otras metodologías de desarrollo de software las sitúa todas una junto a otra.
Verificación frente a validación en el modelo en V
La verificación y la validación responden a dos preguntas distintas, y el modelo en V sitúa cada una en su propio brazo. La tabla siguiente muestra cómo funciona la distinción en la práctica.
| Verificación (lado izquierdo) | Validación (lado derecho) | |
|---|---|---|
| Pregunta | ¿Estamos construyendo bien el producto? | ¿Estamos construyendo el producto correcto? |
| Actividad principal | Pruebas estáticas: revisiones, revisiones guiadas (walkthroughs), inspecciones, análisis estático de especificaciones y diseños | Pruebas dinámicas: ejecutar el software a nivel unitario, de integración, de sistema y de aceptación |
| Evidencias producidas | Especificaciones aprobadas, registros de revisión, planes de pruebas | Informes de pruebas, registros de defectos, conformidad de aceptación |
Diagrama del desarrollo de software con modelo en V: cómo se conectan los dos lados
Un diagrama del desarrollo de software con modelo en V muestra las fases de desarrollo bajando por el brazo izquierdo, la codificación en el fondo y los niveles de pruebas subiendo por el brazo derecho, con un enlace horizontal entre cada par. El enlace es lo importante. Significa que el plan de pruebas de la fase del lado derecho se escribe mientras se hace la fase del lado izquierdo, no después de que exista el código.
| ↘ Lado izquierdo: verificación | Plan de pruebas redactado aquí | Lado derecho: validación ↗ |
|---|---|---|
| 1. Análisis de requisitos de negocio | → plan de pruebas de aceptación → | 9. Pruebas de aceptación |
| 2. Diseño del sistema | → plan de pruebas de sistema → | 8. Pruebas de sistema |
| 3. Diseño de la arquitectura (HLD) | → plan de pruebas de integración → | 7. Pruebas de integración |
| 4. Diseño de módulos (LLD) | → plan de pruebas unitarias → | 6. Pruebas unitarias |
| 5. Codificación: el vértice de la V | ||
Lea el diagrama desde arriba a la izquierda, bajando hasta el vértice y subiendo después por la derecha. Las fases 1 a 4 acotan el alcance desde las necesidades de negocio hasta los módulos individuales. La fase 5 convierte los diseños de módulos en código. Las fases 6 a 9 amplían de nuevo el alcance, desde las unidades individuales hasta el sistema completo en manos del cliente. Cada par horizontal comparte un nivel de abstracción, de modo que la prueba siempre comprueba el trabajo realizado en el mismo nivel.
El mismo emparejamiento como tabla de referencia, con el artefacto que produce cada fase y el responsable habitual de la aprobación:
| Fase de desarrollo | Artefacto de salida | Nivel de pruebas asociado | Plan de pruebas creado | Quién lo aprueba |
|---|---|---|---|---|
| Análisis de requisitos de negocio | Especificación de requisitos de negocio / de usuario | Pruebas de aceptación | Durante el análisis de requisitos | Cliente, product owner |
| Diseño del sistema | Requisitos del sistema y especificación del diseño del sistema | Pruebas de sistema | Durante el diseño del sistema | Ingeniero de sistemas, responsable de QA |
| Diseño de la arquitectura (HLD) | Documento de arquitectura, especificaciones de interfaces | Pruebas de integración | Durante la arquitectura | Arquitecto de software |
| Diseño de módulos (LLD) | Diseño detallado por módulo | Pruebas unitarias | Durante el diseño de módulos | Tech lead, responsable del módulo |
| Codificación | Código fuente, registros de revisión | (alimenta todos los niveles de pruebas) | — | Revisores de código |
Las fases de verificación (lado izquierdo de la V)
Las fases de verificación del lado izquierdo de la V convierten una necesidad de negocio en un diseño lo bastante detallado como para codificarlo, y cada una escribe además el plan de pruebas de su pareja en el lado derecho. La verificación aquí es sobre todo estática: los documentos se revisan, se inspeccionan y se aprueban antes de que el trabajo descienda un nivel.
Análisis de requisitos de negocio (+ plan de pruebas de aceptación)
El análisis de requisitos de negocio recoge lo que el cliente y los usuarios necesitan que haga el sistema, en su propio lenguaje. Los analistas organizan talleres y entrevistas y después redactan una especificación de requisitos con requisitos funcionales y no funcionales, cada uno con un identificador único. Al mismo tiempo, el equipo redacta el plan de pruebas de aceptación: para cada requisito, ¿cómo confirmará el cliente más adelante que funciona? Escribir ahora ese criterio de aceptación saca a la luz con rapidez los requisitos vagos, como «el sistema debe ser rápido».
Diseño del sistema (+ plan de pruebas de sistema)
El diseño del sistema traduce los requisitos de negocio en requisitos del sistema y en una descripción del sistema completo: límites entre hardware y software, interfaces externas, flujos de datos y objetivos de rendimiento. En proyectos de automoción o médicos, aquí es donde se separan los requisitos de software y de hardware. El plan de pruebas de sistema se redacta junto a él y define los escenarios de extremo a extremo, los entornos y los datos necesarios para probar el sistema integrado frente a estos requisitos del sistema.
Diseño de la arquitectura / HLD (+ plan de pruebas de integración)
El diseño de la arquitectura, o diseño de alto nivel (HLD), divide el sistema en componentes y define cómo se comunican: API, formatos de mensajes, bases de datos, servicios de terceros y gestión de errores entre ellos. El plan de pruebas de integración se crea en paralelo y apunta exactamente a esas uniones. Especifica qué interfaces se prueban, en qué orden se combinan los componentes y qué stubs o simuladores sustituyen a las partes que aún no están construidas.
Diseño de módulos / LLD (+ plan de pruebas unitarias)
El diseño de módulos, o diseño de bajo nivel (LLD), describe la lógica interna de cada componente: clases, funciones, algoritmos, estructuras de datos y condiciones límite. Es el último paso antes del código. El plan de pruebas unitarias se redacta aquí y enumera, para cada módulo, las entradas, los casos límite y las salidas esperadas que debe cubrir una prueba unitaria. En el trabajo crítico para la seguridad, aquí es también donde se fijan los objetivos de cobertura estructural, como la cobertura de sentencias o MC/DC.
Codificación: el vértice de la V
La codificación es el punto de la V en que el diseño se convierte en software y empieza el lado derecho. Los desarrolladores implementan cada módulo según su diseño de bajo nivel, siguiendo estándares de codificación (MISRA C en automoción, por ejemplo) y superando la revisión de código y el análisis estático antes de que empiecen las pruebas unitarias. Como el plan de pruebas unitarias ya existe, los desarrolladores saben antes de escribir una línea exactamente qué comportamiento se comprobará.
Las fases de validación (lado derecho de la V)
Las fases de validación del lado derecho de la V ejecutan los planes de pruebas escritos antes, desde la unidad de código más pequeña hasta el sistema completo en el entorno del cliente. En el desarrollo de software con modelo en V, cada nivel prueba frente a la especificación de su fase pareja, no solo frente al código. Eso es lo que permite rastrear con facilidad una prueba fallida hasta su causa.
Pruebas unitarias
Las pruebas unitarias comprueban cada módulo de forma aislada frente a su diseño de bajo nivel. Los desarrolladores o probadores dedicados ejecutan el plan de pruebas unitarias, normalmente mediante un framework automatizado, con las dependencias sustituidas por mocks o stubs. Un fallo de una prueba unitaria apunta directamente a un error de codificación o a un defecto del diseño del módulo, que es el lugar más barato para corregirlo en el lado derecho de la V.
Pruebas de integración
Las pruebas de integración comprueban que los módulos funcionan juntos como dice la arquitectura. Los equipos combinan los componentes paso a paso, con una estrategia descendente, ascendente o mixta, y ejercitan las interfaces definidas en el HLD: formatos de datos, temporización, propagación de errores y transacciones. Los defectos típicos que se encuentran aquí son suposiciones incompatibles entre equipos, como las unidades, el tratamiento de valores nulos o el comportamiento de los reintentos.
Pruebas de sistema
Las pruebas de sistema evalúan el sistema completo e integrado frente a los requisitos del sistema. Cubren el comportamiento funcional y las cualidades no funcionales: rendimiento, seguridad, fiabilidad, usabilidad y, en el trabajo con sistemas embebidos, el comportamiento en el hardware objetivo o en un banco de hardware-in-the-loop. Un equipo de QA independiente suele ejecutarlas en un entorno lo más parecido posible al de producción.
Pruebas de aceptación (UAT)
Las pruebas de aceptación confirman que el sistema cumple los requisitos de negocio y está listo para el uso real. Los clientes o usuarios finales ejecutan el plan de pruebas de aceptación redactado al inicio del proyecto, a menudo como pruebas de aceptación de usuario (UAT), además de los pasos de aceptación contractuales o regulatorios que haya. Superarlas cierra la V: el requisito recogido en la fase 1 ha demostrado funcionar en la fase 9.
¿Cómo funciona la trazabilidad en el modelo en V? Un ejemplo resuelto
La trazabilidad en el modelo en V significa que cada requisito puede seguirse hacia abajo por el lado izquierdo hasta el código que lo implementa y hacia arriba por el lado derecho hasta las pruebas que lo demuestran, y de vuelta. La herramienta para ello es una matriz de trazabilidad de requisitos (RTM). Automotive SPICE 4.0, publicado por VDA QMC en noviembre de 2023, exige explícitamente la trazabilidad bidireccional: de los requisitos a las pruebas y de las pruebas de vuelta a los requisitos, de modo que ninguna prueba quede huérfana y ningún requisito quede sin probar.
He aquí un requisito rastreado a lo largo de toda la V. Tomemos un terminal de pagos cuyo requisito de negocio es REQ-017: «La aprobación de pagos debe bloquearse tras tres intentos fallidos de PIN».
- Requisito de negocio (fase 1). REQ-017 se redacta y se aprueba. Su criterio de aceptación: «Tras tres PIN erróneos en una tarjeta real, el terminal rechaza nuevos intentos y muestra el mensaje de bloqueo».
- Requisito de sistema (fase 2). SYS-042 especifica que el bloqueo debe persistir tras reiniciar el terminal y registrarse en el rastro de auditoría en menos de un segundo.
- Arquitectura (fase 3). ARC-09 asigna el contador al servicio de autorización y el estado de bloqueo al componente de almacenamiento seguro, con una interfaz definida entre ambos.
- Diseño de módulos (fase 4). MOD-AUTH-3 define la lógica del contador, incluido el reinicio al introducir correctamente el PIN y el comportamiento límite en exactamente tres intentos.
- Código (fase 5). El módulo
PinAttemptCounterimplementa MOD-AUTH-3. - Pruebas (fases 6 a 9). UT-311 comprueba el contador con 2, 3 y 4 intentos; IT-58 comprueba que el bloqueo llega al almacenamiento seguro; ST-120 reinicia el terminal en pleno bloqueo; AT-17 ejecuta el escenario del cliente con una tarjeta real.
El fragmento resultante de la RTM tiene este aspecto:
| ID de req. | Requisito | Ref. de diseño | Módulo de código | Prueba unitaria | Prueba de integración / de sistema | Prueba de aceptación | Estado |
|---|---|---|---|---|---|---|---|
| REQ-017 | Bloqueo tras 3 PIN fallidos | SYS-042, ARC-09, MOD-AUTH-3 | PinAttemptCounter | UT-311 | IT-58, ST-120 | AT-17 | Superada |
| REQ-018 | El evento de bloqueo se escribe en el registro de auditoría | SYS-043, ARC-11 | AuditWriter | UT-320 | IT-61, ST-121 | AT-18 | Superada |
| REQ-019 | El contador se reinicia tras un PIN correcto | SYS-042, MOD-AUTH-3 | PinAttemptCounter | UT-312 | ST-122 | AT-17 | Superada |
| REQ-020 | Mensaje de bloqueo localizado (EN/DE) | SYS-050, ARC-14 | UiMessages | UT-402 | ST-130 | AT-21 | Fallida (texto en DE) |
| REQ-021 | El bloqueo persiste tras reiniciar | SYS-042, ARC-09 | SecureStore | UT-330 | ST-120 | — (solo a nivel de sistema) | En curso |
Dos cosas hacen que la RTM sea útil y no burocrática. Primero, una fila fallida le indica de inmediato qué requisito está en riesgo y qué elemento de diseño revisar: REQ-020 falló a nivel de sistema, así que la corrección empieza en SYS-050, no con una búsqueda de código al azar. Segundo, una solicitud de cambio se convierte en un análisis de impacto. Si el negocio cambia REQ-017 a «bloqueo tras cinco intentos», la matriz enumera todos los elementos de diseño y pruebas que deben cambiar a ambos lados de la V.
Principios básicos del modelo en V
El modelo en V se apoya en un pequeño conjunto de principios que lo distinguen de un simple proceso secuencial. Todos se reducen a una idea: pensar en cómo se probará algo en el momento en que se decide cómo debe ser.
- Planificación de pruebas en paralelo con el desarrollo. Cada fase del lado izquierdo entrega su plan de pruebas correspondiente, de modo que las pruebas empiezan el primer día y no después de codificar.
- Prevención de defectos antes que detección. Escribir pruebas frente a una especificación saca a la luz ambigüedades y lagunas antes de que se conviertan en código. Los costes se disparan cuanto más tarde se encuentra un defecto, así que la prevención compensa.
- Requisitos claros y verificables. Un requisito sin criterio de aceptación no está terminado. La V obliga a esa disciplina.
- Puertas de fase y aprobación formal. Cada fase termina con una revisión y una aprobación antes de que empiece la siguiente, lo que crea puntos de auditoría naturales.
- Pruebas estáticas a la izquierda, pruebas dinámicas a la derecha. Las revisiones, inspecciones y el análisis estático verifican documentos y código; las pruebas basadas en ejecución validan el comportamiento.
- Correspondencia uno a uno entre fases y pruebas. Cada nivel de desarrollo tiene exactamente un nivel de pruebas que lo comprueba, al mismo nivel de abstracción.
Ventajas y desventajas del modelo en V
El modelo en V cambia flexibilidad por control. Produce excelentes evidencias y un diseño temprano de las pruebas, y sufre cuando los requisitos se mueven. Conviene leer las dos listas siguientes antes de elegirlo.
Ventajas
- Diseño temprano de las pruebas. Los planes de pruebas existen antes que el código, de modo que los probadores encuentran defectos de especificación cuando aún es barato corregirlos.
- Evidencias listas para auditoría. Las especificaciones, los registros de revisión, los planes de pruebas, los resultados y la RTM son subproductos naturales, justo lo que piden los evaluadores.
- Entregables claros por fase. Todos saben qué debe producir cada fase y quién la aprueba.
- Puertas e hitos predecibles. Es fácil informar del avance y vincularlo a pagos o a pasos de certificación.
- Menos sorpresas tardías. Los defectos hallados en cada nivel de pruebas remiten a una fase de diseño concreta, lo que acorta el análisis de causa raíz.
- Buen encaje con el alcance cerrado y los contratos. Los contratos a precio cerrado y los regulados se corresponden de forma natural con las fases con línea base de la V.
Desventajas
- Rígido cuando cambian los requisitos. Un cambio en la parte alta de la V se propaga por el diseño, el código y cuatro niveles de planes de pruebas.
- El software funcional llega tarde. Los interesados no ven un sistema en marcha hasta que terminan la codificación y las primeras pruebas.
- Retrabajo costoso. Un error de requisitos hallado en las pruebas de aceptación obliga a revisar todas las fases inferiores.
- Mucha carga documental. Las especificaciones, los planes y las matrices exigen un esfuerzo real para escribirlos y mantenerlos al día.
- Bucle débil de comentarios del cliente. Los usuarios validan el producto solo al final, a menos que el equipo añada prototipos o demostraciones.
- Mal encaje con productos en fase de descubrimiento. Si todavía no sabe qué construir, la V congelará la respuesta equivocada.
Modelo en V frente a cascada frente a Agile: ¿qué diferencia hay?
El modelo en V se diferencia de la cascada en que empareja cada fase de diseño con su propio nivel de pruebas y planifica esas pruebas pronto. Se diferencia de Agile en que es secuencial y guiado por la especificación, en lugar de iterativo. El modelo en W es un refinamiento adicional de la V que añade una actividad de pruebas paralela a cada fase. La comparación siguiente resume las contrapartidas.
| Criterio | Modelo en V | Cascada | Agile (Scrum) | Modelo en W |
|---|---|---|---|---|
| Momento de las pruebas | Planificadas con cada fase de diseño y ejecutadas tras la codificación | Una fase de pruebas tras la implementación | Continuas, dentro de cada sprint | Las actividades de pruebas se ejecutan en paralelo con cada fase |
| Flexibilidad ante el cambio | Baja; control formal de cambios | Baja | Alta; se reprioriza el backlog en cada sprint | De baja a media |
| Carga documental | Alta (especificaciones, planes de pruebas, RTM) | Alta | Ligera por defecto | Alta |
| Comentarios del cliente | En los requisitos y en la aceptación | Al principio y al final | En cada revisión del sprint | Al principio y al final, además de las revisiones |
| Mejor encaje | Crítico para la seguridad, regulado, alcance estable | Alcance pequeño, bien entendido y cerrado | Productos en evolución, alcance incierto | Proyectos críticos para la calidad que quieren pruebas más tempranas que en la V |
| Evidencias regulatorias | Fuertes; se corresponden directamente con ISO 26262, IEC 62304 y DO-178C | Medias; hay que añadir la trazabilidad | Débiles salvo que se añadan deliberadamente | Fuertes |
En la práctica, la V y el modelo en cascada son parientes cercanos: ambos están guiados por el plan, ambos usan puertas de fase y ambos encajan con requisitos estables. La ventaja de la V son las pruebas estructuradas y tempranas y la trazabilidad integrada. El desarrollo de software ágil es la filosofía opuesta, que optimiza el aprendizaje y el cambio. Normalmente la elección no es entre V o Agile, sino cuánto de cada una, algo que cubre la sección sobre híbridos más adelante.
¿Cuándo es el modelo en V para el desarrollo de software la elección adecuada?
El modelo en V para el desarrollo de software es la elección adecuada cuando los requisitos son estables, los fallos son costosos o peligrosos y alguien ajeno al equipo va a exigir pruebas de que se ha probado. Si la mayoría de las comprobaciones siguientes se aplican a su proyecto, la V, o un híbrido construido sobre ella, es un buen encaje:
- Los requisitos están bien entendidos y es poco probable que cambien mucho durante el desarrollo.
- El sistema es crítico para la seguridad o para la misión: un fallo podría causar lesiones, detener las operaciones o provocar grandes pérdidas económicas.
- Un regulador, un organismo notificado o una autoridad de certificación auditará sus evidencias de desarrollo y de pruebas.
- El software se desarrolla conjuntamente con el hardware, por lo que las interfaces y la temporización deben especificarse y probarse nivel por nivel.
- El contrato es de precio cerrado o de alcance cerrado, con la aceptación vinculada a criterios acordados.
- Los criterios de aceptación pueden redactarse con claridad al inicio.
- Varios proveedores construyen partes del sistema y necesitan puntos de integración definidos.
La V es una mala elección para un MVP en fase temprana, para una app de consumo cuyas funcionalidades dependen de los comentarios del mercado o para cualquier proyecto cuyo alcance aún no esté claro. En esos casos, la entrega iterativa encuentra más rápido el producto adecuado, y se puede añadir trazabilidad al estilo V más adelante si el producto entra en un mercado regulado.
¿Cómo se usa el modelo en V en los sectores regulados?
Los sectores regulados usan el modelo en V porque sus normas se estructuran ellas mismas en torno a actividades emparejadas de desarrollo y verificación. Seguir la V hace que las evidencias de cumplimiento sean un subproducto del trabajo normal y no un proyecto de documentación aparte al final.
Automoción: ISO 26262 y Automotive SPICE 4.0
El software de automoción es hoy el caso de uso más claro del modelo en V. ISO 26262 (segunda edición, 2018) organiza el trabajo de seguridad funcional desde el concepto, pasando por el diseño del sistema y la implementación, hasta la verificación y la validación, una secuencia que se corresponde directamente con la V, tal como describe SPEC Innovations en su documento técnico sobre el tema. Automotive SPICE 4.0 define áreas de proceso en el lado izquierdo, desde los requisitos y el diseño hasta la unidad de software, y pruebas de verificación en el lado derecho, desde la unidad hasta el sistema, con trazabilidad bidireccional. Aptiv describe su propia V de automoción como requisitos del sistema, diseño del sistema, requisitos de software, implementación y, después, pruebas de integración y de cualificación del software y del sistema. Consulte nuestra guía de desarrollo de software para automoción para ver el panorama más amplio.
Productos sanitarios: IEC 62304 y validación de software de la FDA
El software de productos sanitarios sigue IEC 62304 (con la Enmienda 1 de 2015), que exige planificación del desarrollo de software, requisitos, arquitectura, diseño detallado, verificación unitaria, pruebas de integración y pruebas de sistema, escalados según la clase de seguridad del software. Esa lista es la V con otro nombre. En EE. UU., la guía de validación de software de la FDA espera evidencias documentadas de que el software cumple las necesidades de los usuarios y los usos previstos, que es lo que aporta el nivel de aceptación de la V. Encontrará más detalle en nuestra guía de desarrollo de software para productos sanitarios.
Aeroespacial y defensa: DO-178C
El software aerotransportado se certifica con DO-178C, publicada en 2011. Exige requisitos de alto y de bajo nivel, trazabilidad entre requisitos, código y pruebas, y un análisis de cobertura estructural cuyo rigor aumenta con el nivel de garantía del diseño, hasta la cobertura MC/DC para el software más crítico. El emparejamiento de la V entre el diseño de módulos y las pruebas unitarias, junto con su RTM, ofrece a los equipos una forma natural de demostrar esas evidencias. Nuestro artículo sobre el software de aviación cubre el contexto de la certificación.
Administración y sector público: V-Modell XT e ingeniería de sistemas
El estándar federal alemán V-Modell XT prescribe un proceso adaptable en forma de V para proyectos de TI del sector público, que define roles, productos y puertas de decisión tanto para el cliente como para el proveedor. En EE. UU., la Administración Federal de Carreteras utilizó la V en su guía de ingeniería de sistemas para proyectos de transporte inteligente, incluido el concepto de operaciones Clarus de 2005. Los compradores públicos favorecen la V porque vincula cada paso de aceptación con un requisito contractual.
| Sector | Norma | Qué aporta la V |
|---|---|---|
| Automoción | ISO 26262, Automotive SPICE 4.0 | Requisitos de seguridad trazados hasta las pruebas, trazabilidad bidireccional, evidencias de pruebas por nivel |
| Productos sanitarios | IEC 62304, validación de software de la FDA | Planes documentados de verificación unitaria, de integración y de sistema, además de validación de las necesidades de los usuarios |
| Aeroespacial y defensa | DO-178C | Trazabilidad de requisitos a código y a pruebas, evidencias de cobertura estructural |
| Sector público | V-Modell XT, guía de ingeniería de sistemas | Puertas de aceptación contractuales vinculadas a los requisitos |
¿Puede el modelo en V funcionar con Agile? V híbrida, modelo en W y Agile V en 2026
Sí. En 2026, el modelo en V se utiliza con más frecuencia como marco de gobernanza y de evidencias en torno a una entrega iterativa, no como una secuencia estricta de una sola pasada. Los equipos conservan los niveles, los planes de pruebas y la trazabilidad de la V, y ejecutan iteraciones cortas dentro de ellos. Hay tres patrones comunes.
Sprints dentro de la V. Los requisitos y la arquitectura se fijan como línea base en la parte alta de la V para una versión o un incremento. Dentro de la banda de implementación, los equipos trabajan en sprints: cada sprint entrega funcionalidades diseñadas, codificadas y probadas a nivel unitario y de integración, con la RTM actualizada como parte de la definición de hecho (definition of done). Las pruebas de sistema y de aceptación se ejecutan a nivel de versión. Es el híbrido más común hoy en los programas de automoción y médicos.
El modelo en W. El modelo en W añade una actividad de pruebas en paralelo con cada fase de desarrollo: revisar los requisitos mientras se escriben, probar el diseño mientras se dibuja, y así sucesivamente. Dibujado, parece dos V superpuestas, lo que da nombre al modelo. Lleva las pruebas shift-left más lejos que la V clásica.
Agile V con agentes de IA. Un framework publicado en arXiv en febrero de 2026 por Koch y Wellbrock, llamado Agile V, incorpora la verificación independiente y la generación de artefactos de auditoría en cada ciclo de tareas ágil, con agentes de IA por etapa y puertas de aprobación humana. Su estudio de viabilidad sobre un sistema hardware-in-the-loop de unas 500 líneas de código, 8 requisitos y 54 pruebas comunicó una tasa de superación del 100% a nivel de requisitos y estimó una reducción de costes de 10 a 50 veces frente a una línea base COCOMO II. Es un único estudio de caso pequeño, no una referencia del sector, pero muestra hacia dónde va la V: la generación automatizada de evidencias dentro de iteraciones rápidas.
Los pipelines de integración continua son lo que hace viables los tres patrones. Cuando las pruebas unitarias y de integración se ejecutan en cada commit y los resultados se vinculan a los identificadores de los requisitos, el lado derecho de la V produce evidencias de forma continua y no en una única ráfaga tardía. La misma idea sustenta un ciclo de vida de desarrollo de software seguro y es práctica habitual en el desarrollo de software embebido, donde los bancos de hardware-in-the-loop se ejecutan cada noche.
Cómo implantar el modelo en V: 7 buenas prácticas
Un proyecto con modelo en V tiene éxito cuando el papeleo sirve a la ingeniería y no al revés. Estas siete prácticas mantienen el modelo útil y ágil.
- Adapte la V al riesgo del proyecto. Una función de frenado crítica para la seguridad necesita todos los niveles y una revisión independiente; una herramienta de informes interna puede fusionar HLD y LLD. Normas como V-Modell XT e IEC 62304 permiten expresamente la adaptación. Aprovéchela.
- Redacte planes de pruebas en cada puerta del lado izquierdo. No deje que una fase se cierre hasta que exista su plan de pruebas pareja y haya sido revisado. Es el corazón de la V; si se lo salta, está aplicando cascada.
- Mantenga una RTM viva en su herramienta de ALM. Mantenga la trazabilidad en una herramienta de gestión del ciclo de vida de las aplicaciones o en un gestor de incidencias (Jira, Polarion y codeBeamer son opciones habituales) y no en una hoja de cálculo, para que los vínculos se actualicen con cada cambio.
- Automatice las pruebas unitarias y de integración en CI. Las pruebas automatizadas vinculadas a los identificadores de requisitos convierten la parte inferior derecha de la V en evidencias continuas.
- Haga revisiones y análisis estático a la izquierda. Inspeccione los requisitos y los diseños con listas de verificación y ejecute análisis estático sobre el código antes de las pruebas unitarias. Aquí es donde se cumple la promesa de prevención de defectos de la V.
- Aplique el control de cambios con análisis de impacto en ambos lados. Cada solicitud de cambio debería enumerar los elementos de diseño afectados y las pruebas afectadas. La RTM convierte eso en una consulta, no en una conjetura.
- Use la verificación independiente en los niveles críticos para la seguridad. Para los niveles de integridad más altos, haga que personas que no escribieron el código ni el diseño realicen las revisiones y las pruebas, como esperan ISO 26262 y DO-178C.
Estas prácticas se solapan en gran medida con la disciplina general de garantía de calidad. La V simplemente da a cada actividad de QA un lugar fijo y una fase pareja.
Preguntas frecuentes
¿Qué es el desarrollo de software con modelo en V?
El desarrollo de software con modelo en V es un ciclo de vida de desarrollo de software guiado por el plan en el que cada fase de desarrollo se empareja con un nivel de pruebas correspondiente. El lado izquierdo de la V cubre la verificación: requisitos de negocio, diseño del sistema, diseño de la arquitectura y diseño de módulos. La codificación está en el fondo. El lado derecho cubre la validación: pruebas unitarias, de integración, de sistema y de aceptación, cada una de las cuales comprueba el trabajo de la fase opuesta. Es una extensión del modelo en cascada.
¿Por qué se llama modelo en V en el desarrollo de software?
Se llama modelo en V porque las fases forman la letra V al dibujarse. Las actividades de desarrollo descienden por el brazo izquierdo desde los requisitos hasta el diseño detallado de módulos, la codificación está en el vértice y las actividades de pruebas ascienden por el brazo derecho desde las pruebas unitarias hasta las de aceptación. Los enlaces horizontales a través de la V conectan cada fase de diseño con el nivel de pruebas que más tarde la verificará o validará, que es la idea que define el desarrollo de software con modelo en V.
¿Cuáles son las fases del modelo en V del desarrollo de software?
El modelo en V del desarrollo de software tiene nueve fases clásicas. Cuatro fases de verificación a la izquierda: análisis de requisitos de negocio, diseño del sistema, diseño de la arquitectura (de alto nivel) y diseño de módulos (de bajo nivel). La codificación en el vértice. Cuatro fases de validación a la derecha: pruebas unitarias, pruebas de integración, pruebas de sistema y pruebas de aceptación. Cada fase del lado izquierdo produce además el plan de pruebas de su pareja del lado derecho, de modo que el diseño de las pruebas empieza antes de escribir ningún código.
¿Cuál es la diferencia entre el modelo en V y el modelo en cascada?
Ambos son secuenciales y guiados por el plan, pero el modelo en cascada trata las pruebas como una única fase tardía tras la implementación, mientras que el modelo en V empareja cada fase de diseño con su propio nivel de pruebas y escribe esos planes de pruebas pronto. En cascada, los probadores suelen empezar cuando la build está terminada. En el modelo en V, las pruebas de aceptación se diseñan durante el análisis de requisitos y las pruebas unitarias durante el diseño de módulos. Eso adelanta la prevención de defectos y crea la trazabilidad que esperan los auditores.
¿Es ágil el modelo en V?
El modelo en V clásico no es ágil: es secuencial, con mucha documentación y presupone requisitos estables. Sin embargo, muchos equipos aplican en 2026 un híbrido. Conservan la trazabilidad y los niveles de pruebas de la V como marco de gobernanza y ejecutan sprints ágiles dentro de la banda de implementación, con integración continua que produce evidencias unitarias y de integración en cada iteración. Enfoques como el modelo en W y el framework Agile V publicado en 2026 formalizan esa combinación.
¿Qué sectores usan el modelo en V para el desarrollo de software?
El modelo en V para el desarrollo de software se utiliza sobre todo donde la seguridad, la regulación o los contratos exigen una verificación y una validación documentadas. Los equipos de automoción lo usan con ISO 26262 y Automotive SPICE 4.0, los fabricantes de productos sanitarios con IEC 62304 y la validación de software de la FDA, el sector aeroespacial y de defensa con DO-178C y la TI del sector público alemán con el estándar federal V-Modell XT. Los proyectos ferroviarios, energéticos y de control industrial lo usan por razones similares.
¿Qué muestra un diagrama del desarrollo de software con modelo en V?
Un diagrama del desarrollo de software con modelo en V muestra las fases de desarrollo descendiendo por el brazo izquierdo (requisitos, diseño del sistema, arquitectura, diseño de módulos), la codificación en el punto inferior y los niveles de pruebas ascendiendo por el brazo derecho (unitarias, de integración, de sistema, de aceptación). Líneas horizontales emparejan cada fase del lado izquierdo con el nivel de pruebas del lado derecho que la comprueba, a menudo etiquetado con el plan de pruebas redactado en esa etapa. El diagrama es tanto un mapa de trazabilidad como una línea temporal.
Última actualización: 2 de octubre de 2026. Fuentes: Wikipedia, V-model (software development) (en inglés); Aptiv, What Is the V-Model in Software Development? (en inglés); VDA QMC, Automotive SPICE PAM v4.0 (2023) (en inglés); Koch & Wellbrock, Agile V, arXiv 2602.20684 (2026) (en inglés); SPEC Innovations, ISO 26262 and the Systems Engineering V-Model (en inglés); Built In, What Is the V-Model in Software Development? (en inglés). Normas de referencia: ISO 26262:2018, IEC 62304 (Amd 1:2015), DO-178C (2011). El ejemplo de la RTM es ilustrativo.
