logo

Modello V SDLC – Ingegneria del software

Il modello V è un tipo di Modello SDLC dove il processo viene eseguito in sequenza a forma di V. È noto anche come modello di verifica e convalida. Si basa sull'associazione di una fase di testing ad ogni corrispondente stadio di sviluppo. Lo sviluppo di ogni passaggio è direttamente associato alla fase di test. La fase successiva inizia solo dopo il completamento della fase precedente ovvero ad ogni attività di sviluppo corrisponde un'attività di testing.

Tabella dei contenuti



Il modello V è un modello del ciclo di vita dello sviluppo software (SDLC) che fornisce una rappresentazione sistematica e visiva del processo di sviluppo del software. Si basa sull'idea di una forma a V, con le due gambe della V che rappresentano la progressione del processo di sviluppo del software da raccolta dei requisiti e analisi per la progettazione, l'implementazione, il test e la manutenzione.

Design del modello V

  1. Raccolta e analisi dei requisiti : La prima fase del V-Model è la fase di raccolta e analisi dei requisiti, in cui i requisiti del cliente per il software vengono raccolti e analizzati per determinare l'ambito del progetto.
  2. Progetto: Nella fase di progettazione vengono sviluppati l'architettura e il design del software, compresa la progettazione di alto livello e la progettazione dettagliata.
  3. Implementazione: Nella fase di implementazione, il software viene costruito in base al progetto.
  4. Test: Nella fase di test, il software viene testato per garantire che soddisfi i requisiti del cliente e sia di alta qualità.
  5. Distribuzione: Nella fase di distribuzione, il software viene distribuito e messo in uso.
  6. Manutenzione: Nella fase di manutenzione, il software viene mantenuto per garantire che continui a soddisfare le esigenze e le aspettative del cliente.
  7. Il modello V è spesso utilizzato in sicurezza: sistemi critici, come i sistemi aerospaziali e di difesa, per la sua enfasi su test approfonditi e la sua capacità di definire chiaramente le fasi coinvolte nel processo di sviluppo del software.

Modello V SDLC

L'illustrazione seguente mostra le diverse fasi in un modello V dell'SDLC.



Verifica Fasi :

Implica una tecnica di analisi statica (revisione) eseguita senza eseguire codice. È il processo di valutazione della fase di sviluppo del prodotto per verificare se i requisiti specificati sono soddisfatti.

Ci sono diverse fasi di verifica nel V-Model:

Analisi dei requisiti aziendali:



Questo è il primo passo della designazione del ciclo di sviluppo in cui i requisiti del prodotto devono essere soddisfatti dal punto di vista del cliente. in queste fasi includere una corretta comunicazione con il cliente per comprendere le esigenze dei clienti. queste sono le attività molto importanti che devono essere gestite correttamente, poiché la maggior parte delle volte i clienti non sanno esattamente cosa vogliono e non ne sono sicuri in quel momento, quindi utilizziamo un progettazione del test di accettazione la pianificazione effettuata al momento delle esigenze aziendali verrà utilizzata come file ingresso per le prove di accettazione.

Sistema di design:

converti il ​​numero intero in una stringa java

La progettazione del sistema inizierà quando nel complesso avremo chiari i requisiti del prodotto e quindi dovremo progettare il sistema completamente. Questa comprensione sarà all'inizio del completamento del processo di sviluppo del prodotto. questi saranno utili per la futura esecuzione dei casi di test.

Progettazione architettonica:

In questa fase vengono comprese e progettate le specifiche architettoniche. Di solito vengono proposti diversi approcci tecnici e la scelta finale viene fatta dopo aver considerato sia la fattibilità tecnica che quella finanziaria. L'architettura del sistema è ulteriormente suddivisa in moduli che gestiscono ciascuno una funzione distinta. Un altro nome per questo è High-Level Design (HLD).

A questo punto, lo scambio di dati e la comunicazione tra i moduli interni e i sistemi esterni sono ben compresi e definiti. Durante questa fase, è possibile creare e documentare test di integrazione utilizzando le informazioni fornite.

Progettazione del modulo:

Questa fase, nota come Low-Level Design (LLD), specifica la progettazione interna completa per ogni modulo del sistema. La compatibilità tra il progetto e altri sistemi esterni nonché altri moduli nell'architettura del sistema è fondamentale. I test unitari sono una componente cruciale di qualsiasi processo di sviluppo poiché aiutano a identificare ed eliminare la maggior parte degli errori e dei difetti in una fase iniziale. Sulla base dei progetti dei moduli interni, è ora possibile creare questi test unitari.

Fase di codifica:

La fase di codifica prevede la scrittura del codice per i moduli di sistema creati durante la fase di progettazione. I requisiti di sistema e di architettura vengono utilizzati per determinare quale linguaggio di programmazione è più appropriato.

Durante l'esecuzione della codifica vengono seguiti gli standard e i principi di codifica. Prima che la build finale venga archiviata nel repository, il codice viene sottoposto a numerose revisioni del codice e viene ottimizzato per prestazioni ottimali.

Validazione Fasi :

Implica tecniche di analisi dinamica (funzionali e non funzionali) e test eseguiti eseguendo il codice. La validazione è il processo di valutazione del software dopo il completamento della fase di sviluppo per determinare se il software soddisfa le aspettative e i requisiti del cliente.

Pertanto, il modello V contiene le fasi di verifica da un lato e le fasi di convalida dall'altro. Le fasi di verifica e validazione sono affiancate dalla fase di codifica a forma di V. Pertanto, si chiama V-Model.
Ce ne sono diversi Validazione fasi nel modello V:

Test unitario:

I piani di test unitario vengono sviluppati durante la fase di progettazione del modulo. Questi piani di test unitari vengono eseguiti per eliminare bug nel codice o a livello di unità.

Test d'integrazione:

Dopo il completamento del test unitario viene eseguito il test di integrazione. Nel test di integrazione, i moduli vengono integrati e il sistema viene testato. Il test di integrazione viene eseguito nella fase di progettazione dell'architettura. Questo test verifica la comunicazione dei moduli tra loro.

Test del sistema:

Il test del sistema testa l'applicazione completa con le sue funzionalità, interdipendenze e comunicazione. Testa i requisiti funzionali e non funzionali dell'applicazione sviluppata.

Test di accettazione da parte dell'utente (UAT):

tupla java

L'UAT viene eseguito in un ambiente utente che assomiglia all'ambiente di produzione. UAT verifica che il sistema consegnato soddisfi i requisiti dell'utente e che il sistema sia pronto per l'uso nel mondo reale.

Fase di progettazione:

  • Analisi dei requisiti: Questa fase contiene una comunicazione dettagliata con il cliente per comprenderne le esigenze e le aspettative. Questa fase è nota come raccolta dei requisiti.
  • Sistema di design: Questa fase contiene la progettazione del sistema e la configurazione completa dell'hardware e della comunicazione per lo sviluppo del prodotto.
  • Progettazione architettonica: La progettazione del sistema è ulteriormente suddivisa in moduli che assumono funzionalità diverse. Il trasferimento dei dati e la comunicazione tra i moduli interni e con il mondo esterno (altri sistemi) è chiaramente compreso.
  • Progettazione del modulo: In questa fase il sistema si scompone in piccoli moduli. Viene specificata la progettazione dettagliata dei moduli, nota anche come Low-Level Design (LLD).

Fasi di test:

  • Test unitario: I piani di test unitario vengono sviluppati durante la fase di progettazione del modulo. Questi piani di test unitari vengono eseguiti per eliminare i bug a livello di codice o unità.
  • Test d'integrazione: Dopo il completamento del test unitario viene eseguito il test di integrazione. Nel test di integrazione, i moduli vengono integrati e il sistema viene testato. Il test di integrazione viene eseguito nella fase di progettazione dell'architettura. Questo test verifica la comunicazione dei moduli tra loro.
  • Test del sistema: Il test del sistema verifica l'applicazione completa con le sue funzionalità, interdipendenza e comunicazione. Testa i requisiti funzionali e non funzionali dell'applicazione sviluppata.
  • Test di accettazione da parte dell'utente (UAT): L'UAT viene eseguito in un ambiente utente che assomiglia all'ambiente di produzione. UAT verifica che il sistema consegnato soddisfi i requisiti dell'utente e che il sistema sia pronto per l'uso nel mondo reale.

Sfida industriale:

Man mano che il settore si è evoluto, le tecnologie sono diventate più complesse, sempre più veloci e in continuo cambiamento, tuttavia, rimane una serie di principi e concetti di base applicabili oggi come quando l'IT era agli albori.

  • Definire e perfezionare accuratamente i requisiti degli utenti.
  • Progettare e creare un'applicazione in base ai requisiti dell'utente autorizzato.
  • Convalidare che l'applicazione creata rispettasse i requisiti aziendali autorizzati.

Importanza del modello V

1. Identificazione precoce dei difetti

Incorporando attività di verifica e validazione in ogni fase del processo di sviluppo, il modello V incoraggia i test iniziali. Ciò riduce i costi e gli sforzi necessari per risolvere i problemi nelle fasi successive del ciclo di vita dello sviluppo, favorendo il rilevamento precoce e la risoluzione degli errori.

2. determinazione delle Fasi di Sviluppo e Test

Il V-Model contiene una fase di test che corrisponde a ciascuna fase del processo di sviluppo. Garantendo che i processi di test e sviluppo siano chiaramente mappati, questa chiara mappatura promuove un approccio metodico e ordinato all'ingegneria del software.

3. Previene i test del Big Bang

Nei modelli di sviluppo tradizionali, i test vengono spesso eseguiti alla fine del ciclo di vita dello sviluppo, il che si traduce in un approccio Big Bang in cui tutte le operazioni di test vengono focalizzate contemporaneamente. Integrando le attività di test nel processo di sviluppo e incoraggiando un approccio ai test più progressivo e regolamentato, il Modello V impedisce che ciò accada.

4. Migliora la cooperazione

Ad ogni livello, il Modello V promuove la cooperazione tra i team di test e di sviluppo. Attraverso questa collaborazione, i requisiti del progetto, le scelte di progettazione e le metodologie di test vengono compresi meglio, il che migliora l'efficacia e l'efficienza del processo di sviluppo.

5. Migliore garanzia di qualità

La garanzia della qualità complessiva è rafforzata dal modello V, che incorpora operazioni di test a ogni livello. Prima che il programma raggiunga la fase di implementazione finale, si assicura di soddisfare i requisiti e passa attraverso un rigoroso processo di convalida e verifica.

Principi del modello V

  • Da grande a piccolo: Nel V-Model, i test vengono eseguiti in una prospettiva gerarchica, ad esempio, sui requisiti identificati dal team di progetto, creando le fasi di progettazione di alto livello e di progettazione dettagliata del progetto. Man mano che ciascuna di queste fasi viene completata, i requisiti diventano sempre più raffinati e dettagliati.
  • Integrità dei dati/processi: Questo principio afferma che la progettazione di successo di qualsiasi progetto richiede l’incorporazione e la coesione sia dei dati che dei processi. Gli elementi del processo devono essere identificati ad ogni requisito.
  • Scalabilità: Questo principio afferma che il concetto del modello V ha la flessibilità necessaria per accogliere qualsiasi progetto IT indipendentemente dalle sue dimensioni, complessità o durata.
  • Riferimenti incrociati: Una correlazione diretta tra i requisiti e la corrispondente attività di test è nota come riferimento incrociato.

Documentazione tangibile:

Questo principio afferma che ogni progetto deve creare un documento. Questa documentazione è richiesta e applicata sia dal team di sviluppo del progetto che dal team di supporto. La documentazione viene utilizzata per mantenere l'applicazione una volta disponibile in un ambiente di produzione.

Perché preferito?

  • È facile da gestire grazie alla rigidità del modello. Ogni fase del V-Model prevede risultati specifici e un processo di revisione.
  • Tracciamento proattivo dei difetti – ovvero i difetti vengono individuati in una fase iniziale.

Quando usare Di Modello V ?

  • Tracciabilità dei requisiti: Il modello V si rivela utile in situazioni in cui è imperativo creare una tracciabilità precisa tra i requisiti e i relativi casi di test.
  • Progetti complessi: Il V-Model offre un modo metodico per gestire le attività di test e ridurre i rischi legati a problemi di integrazione e interfaccia per progetti con un elevato livello di complessità e interdipendenze tra i componenti del sistema.
  • Progetti simili a cascate : poiché il modello V offre una struttura accessibile per organizzare, eseguire e monitorare le attività di test a ogni livello di sviluppo, è appropriato per progetti che utilizzano un approccio sequenziale allo sviluppo, proprio come il modello a cascata.
  • Sistemi critici per la sicurezza: Questi sistemi sono utilizzati nei settori aerospaziale, automobilistico e sanitario. Pongono una forte enfasi su rigide procedure di verifica e convalida, che aiutano a garantire che i requisiti essenziali del sistema siano soddisfatti e che i possibili rischi siano individuati ed eliminati nelle prime fasi del processo di sviluppo.

Vantaggi del modello V

  • Questo è un modello altamente disciplinato e le fasi vengono completate una alla volta.
  • Il modello V viene utilizzato per piccoli progetti in cui i requisiti del progetto sono chiari.
  • Semplice e facile da capire e utilizzare.
  • Questo modello si concentra sulle attività di verifica e validazione nelle prime fasi del ciclo di vita, aumentando così la probabilità di costruire un prodotto privo di errori e di buona qualità.
  • Consente alla gestione del progetto di monitorare accuratamente i progressi.
  • Processo chiaro e strutturato: il modello V fornisce un processo chiaro e strutturato per sviluppo software , rendendolo più facile da capire e da seguire.
  • Enfasi sui test: il modello V pone una forte enfasi sui test, che aiutano a garantire la qualità e l'affidabilità del software.
  • Tracciabilità migliorata: il modello V fornisce un chiaro collegamento tra i requisiti e il prodotto finale, semplificando il tracciamento e la gestione delle modifiche al software.
  • Migliore comunicazione: la struttura chiara del modello V aiuta a migliorare la comunicazione tra il cliente e il team di sviluppo.

Svantaggi del modello V

  • Rischio elevato e incertezza.
  • Non va bene per progetti complessi e orientati agli oggetti.
  • Non è adatto a progetti in cui i requisiti non sono chiari e contengono un alto rischio di cambiamento.
  • Questo modello non supporta l'iterazione delle fasi.
  • Non gestisce facilmente eventi simultanei.
  • Inflessibilità: il modello V è un modello lineare e sequenziale, che può rendere difficile l'adattamento a requisiti mutevoli o eventi imprevisti.
  • Richiede tempo: il modello V può richiedere molto tempo, poiché richiede molta documentazione e test.
  • Dipendenza eccessiva dalla documentazione: il modello V pone una forte enfasi sulla documentazione, il che può portare a fare affidamento eccessivo sulla documentazione a scapito del lavoro di sviluppo effettivo.

Conclusione

Un approccio scientifico e organizzato al ciclo di vita dello sviluppo del software (SDLC) è fornito dal modello V dell'ingegneria del software. L'esperienza del team con la metodologia selezionata, le caratteristiche uniche del progetto e la natura dei requisiti dovrebbero essere presi in considerazione quando si selezionano eventuali modelli SDLC, incluso il modello V.

Libro di consultazione:

Software Engineering: A Practitioner’s Approach di Roger S. Pressman, pubblicato da McGraw-Hill Education, 2017.