Il Modello V è anche denominato Modello di Verifica e Validazione. In questo, ciascuna fase dell'SDLC deve essere completata prima dell'inizio della fase successiva. Segue un processo di progettazione sequenziale identico al modello a cascata. Il test del dispositivo è pianificato parallelamente alla corrispondente fase di sviluppo.
Verifica: Implica un metodo di analisi statica (revisione) eseguito senza eseguire codice. È il processo di valutazione del processo di sviluppo del prodotto per verificare se i requisiti specificati sono soddisfatti.
Convalida: Implica il metodo di analisi dinamica (funzionale, non funzionale), il test viene eseguito eseguendo il codice. La convalida è il processo per classificare il software dopo il completamento del processo di sviluppo per determinare se il software soddisfa le aspettative e i requisiti del cliente.
Quindi il V-Model contiene le fasi di verifica da un lato e le fasi di convalida dall'altro. Il processo di verifica e validazione è affiancato dalla fase di codifica a forma di V. Pertanto è noto come modello V.
Ci sono le varie fasi della Fase di Verifica del V-model:
| Analisi dei requisiti aziendali: | Questo è il primo passo in cui i requisiti del prodotto vengono compresi dal lato del cliente. Questa fase contiene una comunicazione dettagliata per comprendere le aspettative del cliente e i requisiti esatti.
| Sistema di design: | In questa fase i sistemisti analizzano e interpretano il business del sistema proposto studiando il documento dei requisiti utente.
| Progetto di architettura: | La linea di base nella selezione dell'architettura è che questa dovrebbe comprendere tutto ciò che tipicamente consiste nell'elenco dei moduli, breve funzionalità di ciascun modulo, le loro relazioni di interfaccia, dipendenze, tabelle del database, diagrammi dell'architettura, dettagli tecnologici, ecc. Viene portato avanti il modello di test di integrazione fuori in una fase particolare.
| Progettazione del modulo: | Nella fase di progettazione dei moduli, il sistema si scompone in piccoli moduli. Viene specificata la progettazione dettagliata dei moduli, nota come progettazione di basso livello
| Fase di codifica: | Dopo la progettazione viene avviata la fase di codifica. In base ai requisiti viene deciso il linguaggio di programmazione adatto. Esistono alcune linee guida e standard per la codifica. Prima di archiviare il repository, la build finale viene ottimizzata per prestazioni migliori e il codice viene sottoposto a numerose revisioni del codice per verificarne le prestazioni.
Ci sono le varie fasi della Fase di Validazione del V-model:
| Test unitario: | Nel modello V, i piani di test unitari (UTP) vengono sviluppati durante la fase di progettazione del modulo. Questi UTP vengono eseguiti per eliminare errori a livello di codice o di unità. Un'unità è l'entità più piccola che può esistere in modo indipendente, ad esempio un modulo di programma. Il test unitario verifica che l'entità più piccola possa funzionare correttamente quando isolata dal resto dei codici/unità.
| Test d'integrazione: | I piani di test di integrazione vengono sviluppati durante la fase di progettazione architettonica. Questi test verificano che i gruppi creati e testati in modo indipendente possano coesistere e comunicare tra loro.
| Test del sistema: | I piani di test del sistema vengono sviluppati durante la fase di progettazione del sistema. A differenza dei piani di test di unità e integrazione, i piani di test di sistema sono composti dal team aziendale del cliente. System Test garantisce che le aspettative di uno sviluppatore di applicazioni siano soddisfatte.
| Test di accettazione: | Il test di accettazione è correlato alla parte di analisi dei requisiti aziendali. Include il test del prodotto software nell'atmosfera dell'utente. I test di accettazione rivelano i problemi di compatibilità con i diversi sistemi disponibili nell'ambiente dell'utente. Scopre inoltre i problemi non funzionali come i difetti di carico e di prestazioni nell'ambiente dell'utente reale.
Quando utilizzare il modello V?
- Quando il requisito è ben definito e non ambiguo.
- Il modello a V dovrebbe essere utilizzato per progetti di piccole e medie dimensioni in cui i requisiti sono chiaramente definiti e fissi.
- Il modello a V dovrebbe essere scelto quando sono disponibili risorse tecniche campione con competenze tecniche essenziali.
Vantaggio (pro) del modello V:
- Facile da capire.
- Metodi di test come la pianificazione e la progettazione dei test avvengono molto prima della codifica.
- Ciò consente di risparmiare molto tempo. Quindi una maggiore possibilità di successo rispetto al modello a cascata.
- Evita il deflusso dei difetti verso il basso.
- Funziona bene per progetti di piccole dimensioni in cui i requisiti sono facilmente comprensibili.
Svantaggio (contro) del modello V:
- Molto rigido e meno flessibile.
- Non va bene per un progetto complesso.
- Il software viene sviluppato durante la fase di implementazione, quindi non vengono prodotti i primi prototipi del software.
- Se si verificano modifiche nel frattempo, è necessario aggiornare i documenti del test insieme ai documenti richiesti.
