🌐 Español
Contacto Iniciar sesión Probar FoxPlan
← Volver a los artículos

Guía

Ciclo en V: etapas, ventajas y cuándo preferirlo al ágil

El ciclo en V asocia cada etapa de diseño con la prueba que la validará. Rígido donde los requisitos cambian, imbatible donde no deben cambiar.

El ciclo en V es un ciclo de desarrollo secuencial en el que cada etapa de especificación de la rama descendente se corresponde con el nivel de prueba que la verifica en la rama ascendente. Dibujado en forma de V, define al bajar lo que se construirá y demuestra al subir que se ha construido correctamente. Es un refinamiento del modelo en cascada, no una alternativa a él.

La rama descendente

Análisis de requisitos, especificación funcional, diseño arquitectónico, diseño detallado: cada nivel precisa el anterior y produce un documento que servirá de referencia a un nivel de prueba. Toda la disciplina del modelo está ahí: no se especifica un nivel sin saber ya cómo se verificará.

La rama ascendente

Las pruebas unitarias validan el diseño detallado, las de integración la arquitectura, las de sistema la especificación funcional y las de aceptación los requisitos iniciales. Cada prueba responde a un documento escrito en el lado opuesto de la V, lo que hace la cobertura trazable y auditable.

Ventajas y límites

El ciclo en V es fuerte donde los requisitos son estables y se exige prueba: industrias reguladas, sistemas embebidos, entregas críticas o contractuales. Su límite es simétrico: un cambio descubierto en la rama ascendente resulta caro, porque invalida documentos producidos meses antes. Presupone que se puede saber lo que se quiere antes de haberlo visto.

Elegir entre V, cascada y ágil

El criterio real no es la moda, sino la volatilidad del requisito y el coste de un cambio tardío. Requisitos estables, contractuales y certificables piden un ciclo en V; un producto exploratorio, cuyo usuario descubre la necesidad al usarlo, pide una entrega iterativa. La mayoría de las organizaciones acaban practicando ambos, a veces dentro de un mismo programa: una fase de validación en V, un incremento de producto en sprints.

Dirigir ambos en la misma cartera

FoxPlan no impone un método único: un proyecto puede planificarse en Gantt con fases, hitos y dependencias, o seguirse en un tablero Kanban, y ambos alimentan la misma carga de recursos, el mismo presupuesto y el mismo reporte de cartera. El método sigue siendo una elección del proyecto; la consolidación sigue siendo global.

Probar FoxPlan

Confían en nosotros