Qualcuno può spiegare il processo del modello V? Perché è diverso dal modello Waterfall?

Sembra che il modello V sia solo il modello Waterfall con la metà inferiore della cascata piegata verso l'alto per formare una V. Non vedo come aggiunge qualcosa di nuovo.

Dagli schemi, inoltre, non capisco il flusso. Ci sono frecce che puntano in tutte le direzioni e non riesco a capire cosa viene prima. Seguiamo la V da in alto a sinistra, in basso al centro in basso e poi di nuovo in alto a destra? Oppure avanziamo verso il basso facendo la V più in alto prima che l'elemento in basso?

In Internet manca una spiegazione sufficiente di questo modello. Sarebbe fantastico se qualcuno potesse spiegarlo nel vero modulo StackExchange :)

Il modello V è un'estensione del modello Waterfall, quindi non aspettarti che sia enormemente diverso.

Fondamentalmente, segui il modello V da sinistra a destra , proprio come nel modello Waterfall. In Waterfall, si eseguono requisiti, progettazione, implementazione, verifica e infine manutenzione. Allo stesso modo, nel modello V, si eseguono requisiti, progettazione, implementazione, verifica e manutenzione: stessi passaggi in entrambi i casi.

Le principali differenze con Waterfall sono il modo in cui viene presentato e l'enfasi sui test.

La rappresentazione del flusso come forma a V aiuta a fare la differenza tra tutto ciò che viene prima della codifica (requisiti, architettura e design) e tutto ciò che segue la codifica (essenzialmente test). Mentre i test sono solo uno dei cinque passaggi di Waterfall, sembra quasi la metà del processo nel modello V.

Il diagramma nella tua domanda è un po 'più complicato. Ciò che tenta di mostrare è che, ad esempio, la fase di progettazione del sistema porta non solo al documento di progettazione del sistema, come suggerirebbe il modello Waterfall, ma anche alla progettazione dei test di sistema, che in seguito aiuterà a scrivere test di sistema. Il diagramma pone ancora più enfasi sui test . Infine, la progettazione del test di sistema aiuta nella progettazione dell'architettura (sarebbe scomodo fare la progettazione dell'architettura indipendentemente dalla progettazione del test del sistema).

Cercando quali altre spiegazioni su Internet, non posso evitare di citare il seguente articolo di Bhakti Satalkar :

La differenza principale tra il modello a cascata e il modello a V è che nel modello a cascata, le attività di test vengono eseguite al termine delle attività di sviluppo. D'altra parte nel modello V, le attività di test iniziano con il primo stadio stesso. In altre parole, il modello a cascata è un processo continuo, mentre il modello V è un processo simultaneo. Rispetto a un software realizzato con il modello a cascata, il numero di difetti nel software realizzato con il modello a V è inferiore. Ciò è dovuto al fatto che ci sono attività di test, che vengono svolte simultaneamente nel modello V. Pertanto, viene utilizzato il modello a cascata, quando i requisiti dell'utente sono fissi. Se i requisiti dell'utente sono incerti e continuano a cambiare, allora il modello V è l'alternativa migliore.

Questa spiegazione è fuorviante . Sarebbe vero solo se si sostituisse "V-model" nel preventivo con qualsiasi metodo Agile.

A differenza dell'articolo afferma, nel modello V, i test vengono eseguiti dopo la codifica; per esempio, vedi Wikipedia :

una critica pratica comune al modello V è che porta a testare le finestre strette alla fine dello sviluppo quando le fasi precedenti sono state superate ma la data di implementazione rimane fissa.

Mentre, nel modello V, la progettazione dei test di sistema segue la progettazione del sistema senza attendere fino a quando non viene eseguita l'implementazione del prodotto, ciò non significa che i test stessi vengano eseguiti prima della codifica. L'autore confonde il modello V con approcci Agile come Test Driven Development (TDD) in Extreme Programming (XP).