Il cosiddetto modello a V è un’estensione del modello a cascata (con cui condivide gli ambiti ideali di utilizzo) che però prevede di associare direttamente una fase di test a ogni singola fase del ciclo di sviluppo. Si tratta di un modello sequenziale che richiede una rigida organizzazione e in cui una nuova fase inizia solo dopo il completamento della fase precedente, passando attraverso fasi di verifica, una fase di codifica e una serie di fasi di convalida.
Il vantaggio di questo approccio risiede nella sua facilità di applicazione, che si traduce in una maggiore semplicità gestionale, ma ha lo svantaggio di non essere flessibile rispetto ai cambiamenti: anche solo nel caso in cui venga modificato un requisito, circostanza molto comune nel mondo dinamico attuale, diventa costoso apportare la modifica.
Esistono anche approcci meno strutturati allo sviluppo. Per esempio, ci sono modelli che non prevedono di seguire alcuno sviluppo formale e che richiedono pochissima pianificazione. Persino il cliente finale non è sicuro di cosa esattamente vuole e le esigenze sono implementate “al volo” senza molta analisi.
Di solito, questo approccio caratterizza piccoli progetti poco rischiosi, con team di sviluppo molto piccoli (uno o due sviluppatori che lavorano insieme) oppure progetti accademici. È, quindi, adatto a situazioni in cui i requisiti del software finale non sono ben compresi e in cui la data di rilascio finale non è fissata in modo rigido. Il vantaggio risiede ovviamente nella semplicità che deriva dall’assenza di pianificazione e di procedure formali, nonché nella facilità di gestione.
Si tratta però di un approccio rischioso rispetto al conseguimento degli obiettivi finali, poiché le modifiche o le incomprensioni dei requisiti possono portare a una revisione totale se non addirittura alla cancellazione del progetto.