¿Alguien puede explicar el proceso del Modelo V? ¿Por qué es diferente al modelo de cascada?

Parece que el Modelo V es solo el Modelo Cascada con la mitad inferior de la Cascada doblada hacia arriba para formar una V. No veo cómo agrega algo nuevo.

De los diagramas, tampoco entiendo el flujo. Hay flechas que apuntan en todas las direcciones y no puedo entender lo que viene primero. ¿Seguimos la V desde la esquina superior izquierda, hacia el centro inferior y luego hacia la esquina superior derecha? ¿O progresamos por la V haciendo todo más alto antes de que el elemento baje?

Internet carece de una explicación suficiente de este modelo. Sería increíble si alguien puede explicarlo en forma verdadera de StackExchange :)

El modelo V es una extensión del modelo Waterfall, así que no esperes que sea muy diferente.

Básicamente, sigues el modelo V de izquierda a derecha , al igual que en el modelo Waterfall. En Waterfall, usted realiza los requisitos, el diseño, la implementación, la verificación y finalmente el mantenimiento. Del mismo modo, en el modelo V, usted realiza los requisitos, el diseño, la implementación, la verificación y el mantenimiento: los mismos pasos en ambos casos.

Las principales diferencias con Waterfall son la forma en que se presenta y el énfasis en las pruebas.

Representar el flujo como una forma de V ayuda a marcar la diferencia entre todo lo que viene antes de la codificación (requisitos, arquitectura y diseño) y todo lo que sigue a la codificación (esencialmente pruebas). Si bien las pruebas son solo uno de los cinco pasos en Waterfall, parece que prácticamente la mitad del proceso en el modelo V.

El diagrama en su pregunta es un poco más complicado. Lo que intenta mostrar es que, por ejemplo, el paso de diseño del sistema conduce no solo al documento de diseño del sistema, como sugeriría el modelo Waterfall, sino también al diseño de las pruebas del sistema, que más tarde ayudará a escribir las pruebas del sistema. El diagrama simplemente pone aún más énfasis en las pruebas . Finalmente, hacer el diseño de prueba del sistema ayuda en el diseño de la arquitectura (sería difícil hacer el diseño de la arquitectura independientemente del diseño de la prueba del sistema).

Buscando otras explicaciones en Internet, no puedo evitar citar el siguiente artículo de Bhakti Satalkar :

La principal diferencia entre el modelo en cascada y el modelo V es que en el modelo en cascada, las actividades de prueba se llevan a cabo una vez finalizadas las actividades de desarrollo. Por otro lado, en el modelo V, las actividades de prueba comienzan con la primera etapa. En otras palabras, el modelo en cascada es un proceso continuo, mientras que el modelo V es un proceso simultáneo. En comparación con un software hecho usando el modelo en cascada, la cantidad de defectos en el software hecho usando el modelo V es menor. Esto se debe al hecho de que hay actividades de prueba, que se llevan a cabo simultáneamente en el modelo V. Por lo tanto, se utiliza el modelo en cascada, cuando los requisitos del usuario son fijos. Si los requisitos del usuario son inciertos y siguen cambiando, entonces el modelo V es la mejor alternativa.

Esta explicación es engañosa . Sería cierto solo si reemplaza el "modelo V" en la cita por cualquier método ágil.

A diferencia del artículo, en el modelo V, las pruebas se realizan después de la codificación; por ejemplo, ver Wikipedia :

Una crítica práctica común del Modelo V es que conduce a que las pruebas se compriman en ventanas estrechas al final del desarrollo cuando las etapas anteriores se han desbordado pero la fecha de implementación sigue siendo fija.

Si bien, en el modelo V, el diseño de la prueba del sistema sigue el diseño del sistema sin esperar hasta que se complete la implementación del producto, esto no significa que las pruebas en sí mismas se realicen antes de la codificación. El autor confunde el modelo V con enfoques ágiles como Test Driven Development (TDD) en Extreme Programming (XP).