SDLC - V-Model
Il modello a V è un modello SDLC in cui l'esecuzione dei processi avviene in modo sequenziale in una forma a V. È anche conosciuto comeVerification and Validation model.
Il V-Model è un'estensione del modello a cascata e si basa sull'associazione di una fase di test per ciascuna fase di sviluppo corrispondente. Ciò significa che per ogni singola fase del ciclo di sviluppo, esiste una fase di test direttamente associata. Questo è un modello altamente disciplinato e la fase successiva inizia solo dopo il completamento della fase precedente.
Modello V - Design
Nell'ambito del V-Model, la corrispondente fase di test della fase di sviluppo è pianificata in parallelo. Quindi, ci sono fasi di verifica su un lato delle fasi "V" e di convalida sull'altro lato. La fase di codifica unisce i due lati del modello V.
La seguente illustrazione illustra le diverse fasi in un modello V dell'SDLC.
V-Model - Fasi di verifica
Ci sono diverse fasi di verifica nel V-Model, ognuna di queste è spiegata in dettaglio di seguito.
Analisi dei requisiti aziendali
Questa è la prima fase del ciclo di sviluppo in cui i requisiti del prodotto vengono compresi dal punto di vista del cliente. Questa fase prevede una comunicazione dettagliata con il cliente per comprendere le sue aspettative e l'esatta esigenza. Questa è un'attività molto importante e deve essere gestita bene, poiché la maggior parte dei clienti non è sicura di ciò di cui hanno esattamente bisogno. Ilacceptance test design planning viene eseguita in questa fase poiché i requisiti aziendali possono essere utilizzati come input per i test di accettazione.
Sistema di design
Una volta che hai i requisiti del prodotto chiari e dettagliati, è il momento di progettare il sistema completo. Il design del sistema comprenderà e descriverà dettagliatamente la configurazione completa dell'hardware e della comunicazione per il prodotto in fase di sviluppo. Il piano di test del sistema viene sviluppato in base alla progettazione del sistema. Farlo in una fase precedente lascia più tempo per l'effettiva esecuzione del test in un secondo momento.
Progettazione architettonica
Le specifiche architettoniche vengono comprese e progettate in questa fase. Di solito viene proposto più di un approccio tecnico e in base alla fattibilità tecnica e finanziaria viene presa la decisione finale. Il design del sistema è ulteriormente suddiviso in moduli che assumono funzionalità diverse. Questo è anche indicato comeHigh Level Design (HLD).
Il trasferimento dei dati e la comunicazione tra i moduli interni e con il mondo esterno (altri sistemi) è chiaramente compreso e definito in questa fase. Con queste informazioni, i test di integrazione possono essere progettati e documentati durante questa fase.
Progettazione del modulo
In questa fase viene specificato il progetto interno dettagliato di tutti i moduli del sistema, denominato Low Level Design (LLD). È importante che il design sia compatibile con gli altri moduli nell'architettura del sistema e con gli altri sistemi esterni. Gli unit test sono una parte essenziale di qualsiasi processo di sviluppo e aiutano a eliminare i massimi difetti ed errori in una fase molto precoce. Questi test unitari possono essere progettati in questa fase sulla base dei progetti del modulo interno.
Fase di codifica
La codifica vera e propria dei moduli del sistema progettati in fase di progettazione viene ripresa nella fase di Codifica. Il linguaggio di programmazione più adatto viene deciso in base al sistema e ai requisiti architettonici.
La codifica viene eseguita in base alle linee guida e agli standard di codifica. Il codice viene sottoposto a numerose revisioni del codice ed è ottimizzato per le migliori prestazioni prima che la build finale venga archiviata nel repository.
Fasi di convalida
Le diverse fasi di convalida in un modello V sono spiegate in dettaglio di seguito.
Test unitario
I test unitari progettati nella fase di progettazione del modulo vengono eseguiti sul codice durante questa fase di convalida. Il test unitario è il test a livello di codice e aiuta a eliminare i bug in una fase iniziale, sebbene tutti i difetti non possano essere scoperti dal test unitario.
Test d'integrazione
Il test di integrazione è associato alla fase di progettazione architettonica. Vengono eseguiti test di integrazione per testare la coesistenza e la comunicazione dei moduli interni all'interno del sistema.
Test di sistema
Il test del sistema è direttamente associato alla fase di progettazione del sistema. I test di sistema controllano l'intera funzionalità del sistema e la comunicazione del sistema in fase di sviluppo con i sistemi esterni. La maggior parte dei problemi di compatibilità software e hardware possono essere scoperti durante l'esecuzione di questo test di sistema.
Test di accettazione
Il test di accettazione è associato alla fase di analisi dei requisiti aziendali e implica il test del prodotto nell'ambiente dell'utente. I test di accettazione rivelano i problemi di compatibilità con gli altri sistemi disponibili nell'ambiente utente. Rileva anche i problemi non funzionali come i difetti di carico e di prestazioni nell'ambiente utente effettivo.
Modello V ─ Applicazione
L'applicazione V-Model è pressoché identica al modello a cascata, poiché entrambi i modelli sono di tipo sequenziale. I requisiti devono essere molto chiari prima dell'inizio del progetto, perché di solito è costoso tornare indietro e apportare modifiche. Questo modello è utilizzato nel campo dello sviluppo medico, poiché è un dominio strettamente disciplinato.
I seguenti puntatori sono alcuni degli scenari più adatti per utilizzare l'applicazione V-Model.
I requisiti sono ben definiti, chiaramente documentati e fissi.
La definizione del prodotto è stabile.
La tecnologia non è dinamica ed è ben compresa dal team di progetto.
Non ci sono requisiti ambigui o indefiniti.
Il progetto è breve.
V-Model - Pro e contro
Il vantaggio del metodo V-Model è che è molto facile da capire e da applicare. La semplicità di questo modello lo rende anche più facile da gestire. Lo svantaggio è che il modello non è flessibile ai cambiamenti e, nel caso in cui ci sia un cambiamento dei requisiti, che è molto comune nel mondo dinamico di oggi, diventa molto costoso effettuare il cambiamento.
I vantaggi del metodo V-Model sono i seguenti:
Questo è un modello altamente disciplinato e le fasi vengono completate una alla volta.
Funziona bene per progetti più piccoli in cui i requisiti sono molto ben compresi.
Semplice e facile da capire e da usare.
Facile da gestire grazie alla rigidità del modello. Ogni fase ha risultati finali specifici e un processo di revisione.
Gli svantaggi del metodo V-Model sono i seguenti:
Alto rischio e incertezza.
Non è un buon modello per progetti complessi e orientati agli oggetti.
Modello scadente per progetti lunghi e in corso.
Non adatto a progetti in cui i requisiti corrono un rischio di cambiamento da moderato ad alto.
Una volta che un'applicazione è in fase di test, è difficile tornare indietro e modificare una funzionalità.
Nessun software funzionante viene prodotto fino a tardi durante il ciclo di vita.