Che cos’è il V-model?

Il modello a V è uti­liz­za­to per diversi processi di sviluppo, ad esempio nello sviluppo software. È stato svi­lup­pa­to nella sua forma originale negli anni '90, affinato nel tempo e adattato ai moderni metodi di sviluppo. L’idea di base, tuttavia, è nata negli anni '70 come una sorta di ulteriore sviluppo del modello a cascata.

Oltre alle ri­spet­ti­ve fasi di sviluppo di un progetto, il V-model definisce in parallelo le procedure di garanzia della qualità e descrive come queste singole fasi possono in­te­ra­gi­re tra loro. Il modello di sviluppo deve il nome alla sua struttura, che è simile alla lettera V.

In primo luogo, il V-model definisce lo svol­gi­men­to di un progetto in singole fasi che vanno sempre più nel dettaglio:

• all’inizio del progetto, il modello prevede un’analisi dei requisiti generali del sistema pia­ni­fi­ca­to.
• In seguito si ar­ric­chi­sce di requisiti fun­zio­na­li e non fun­zio­na­li per l’ar­chi­tet­tu­ra di sistema.
• Segue la pro­get­ta­zio­ne del sistema, in cui sono pia­ni­fi­ca­ti i com­po­nen­ti e le in­ter­fac­ce del sistema.
• Una volta com­ple­ta­te queste fasi, può essere pro­get­ta­ta nel dettaglio l’ar­chi­tet­tu­ra del software

Dopodiché segue l’effettivo sviluppo del software secondo gli schemi definiti e infine le fasi di garanzia della qualità, riferite alle varie fasi di sviluppo. Il modello prevede i seguenti compiti:

• Unit test
• Test d’in­te­gra­zio­ne
• In­te­gra­zio­ne di sistema
• Collaudo

La “V” indica la struttura di questo modello, che confronta le fasi di sviluppo con le fasi di garanzia della qualità cor­ri­spon­den­ti. Il braccio sinistro della lettera V contiene i compiti per l’ela­bo­ra­zio­ne iniziale e lo sviluppo del sistema, mentre il braccio destro mostra le relative misure per la garanzia della qualità. Al centro delle due braccia, tra le fasi dello sviluppo e della garanzia della qualità, si trova l’im­ple­men­ta­zio­ne del prodotto. Nel caso di un progetto software, questa con­si­ste­reb­be nella pro­gram­ma­zio­ne del software.

La corretta im­ple­men­ta­zio­ne dell’ar­chi­tet­tu­ra software pia­ni­fi­ca­ta viene ve­ri­fi­ca­ta mediante unit test, i quali con­sen­to­no di ve­ri­fi­ca­re nel dettaglio se i singoli moduli del software sod­di­sfa­no esat­ta­men­te le funzioni richieste e for­ni­sco­no realmente i risultati attesi. Ideal­men­te, per evitare errori, questi test dei moduli do­vreb­be­ro essere eseguiti il più possibile pa­ral­le­la­men­te allo sviluppo.

La pro­get­ta­zio­ne del sistema è con­trol­la­ta dai test di in­te­gra­zio­ne. Questi ve­ri­fi­ca­no se i singoli com­po­nen­ti in­te­ra­gi­sco­no come previsto, ad esempio, con­trol­lan­do che tutti i processi con­cor­ra­no a re­sti­tui­re i risultati attesi. Tra l’altro, risultati errati in questa fase possono indicare problemi con le in­ter­fac­ce.

Il testing di sistema verifica se i requisiti generali di sistema definiti al momento della pro­get­ta­zio­ne nell’ar­chi­tet­tu­ra del sistema sono stati sod­di­sfat­ti. Tali test si svolgono so­li­ta­men­te in un ambiente di prova che simula il più fe­del­men­te possibile le con­di­zio­ni reali del cliente.

Alla fine del progetto, l’analisi dei requisiti dell’intero sistema viene messa in relazione con il collaudo del prodotto finito. Al momento del collaudo finale, il cliente verifica se le spe­ci­fi­che sono ri­spet­ta­te durante il fun­zio­na­men­to. Di norma, viene testato solo il com­por­ta­men­to del software a livello di in­ter­fac­cia, in altre parole ciò che il cliente vede durante l’uso quo­ti­dia­no. Questo test viene anche chiamato test di ac­cet­ta­zio­ne.

Nel 2006, il modello a V è stato ag­gior­na­to per poter ri­flet­te­re principi più recenti, come ad esempio lo sviluppo agile. Ciò ha dato come risultato il V-model XT. XT sta per Extreme Tailoring e descrive la nuova pos­si­bi­li­tà di adattare il modello alle ri­spet­ti­ve esigenze del progetto.

Un’idea all’origine di questo ulteriore sviluppo è stata quella di fornire un modello che possa essere adattato in modo fles­si­bi­le alle diverse di­men­sio­ni del progetto. So­prat­tut­to per i progetti più piccoli, il vecchio metodo era spesso troppo complesso e quindi inef­fi­cien­te. Con il V-model XT, invece, è possibile annullare nei piccoli progetti alcune fasi che ri­chie­de­reb­be­ro uno sforzo elevato.

Inoltre, il modello più recente include anche blocchi di attività che fanno ri­fe­ri­men­to esplicito al cliente. Il vecchio modello coinvolge il cliente esclu­si­va­men­te nell’ese­cu­zio­ne del progetto, prima del collaudo finale. Nel nuovo modello il cliente è mag­gior­men­te coinvolto.

Il modello con­ti­nue­rà a essere ag­gior­na­to re­go­lar­men­te per tener conto delle in­no­va­zio­ni nel processo di sviluppo software e per renderlo sempre più adeguato all’uso pratico. La versione più recente del V-model XT è la versione 2.3.

Il V-model XT è un modello di sviluppo am­pia­men­te uti­liz­za­to nell’industria. Può essere uti­liz­za­to per progetti software di qualsiasi di­men­sio­ne, in ambito com­mer­cia­le, militare o pubblico. Serve come strumento per fa­ci­li­ta­re l’or­ga­niz­za­zio­ne e la rea­liz­za­zio­ne dello sviluppo, della ma­nu­ten­zio­ne e del mi­glio­ra­men­to dei vari sistemi IT.

Il modello a V può essere uti­liz­za­to anche per sistemi elet­tro­ni­ci o meccanici nella ricerca e nella scienza. Per questi settori di ap­pli­ca­zio­ne, esistono alcune versioni leg­ger­men­te adattate che ri­flet­to­no le fasi pro­ce­du­ra­li tipiche del ri­spet­ti­vo settore.

Il modello di sviluppo è così am­pia­men­te diffuso so­prat­tut­to perché ga­ran­ti­sce un elevato grado di tra­spa­ren­za e processi chia­ra­men­te definiti e com­pren­si­bi­li. Di seguito troverete una pa­no­ra­mi­ca sui prin­ci­pa­li vantaggi e punti critici.

• Ot­ti­miz­za­zio­ne della co­mu­ni­ca­zio­ne tra le parti coinvolte at­tra­ver­so termini e re­spon­sa­bi­li­tà chia­ra­men­te definiti
• Mi­ni­miz­za­zio­ne dei rischi e migliore pia­ni­fi­ca­zio­ne at­tra­ver­so la de­fi­ni­zio­ne di ruoli, strutture e risultati
• Mi­glio­ra­men­to della qualità del prodotto at­tra­ver­so misure di garanzia della qualità sal­da­men­te integrate
• Risparmio sui costi grazie ad una la­vo­ra­zio­ne tra­spa­ren­te dell’intero ciclo di vita del prodotto

Nel complesso il modello può aiutare ad evitare equivoci e lavori superflui Assicura inoltre che tutte le attività siano com­ple­ta­te al momento giusto e nel giusto ordine e che il tempo di inat­ti­vi­tà sia ridotto al minimo.

Il modello di sviluppo è talvolta troppo semplice per mappare com­ple­ta­men­te il processo di sviluppo dal punto di vista degli svi­lup­pa­to­ri. L’at­ten­zio­ne si concentra sempre più sulla gestione dei progetti. Inoltre, la struttura re­la­ti­va­men­te rigida non consente quasi mai una risposta fles­si­bi­le ai cam­bia­men­ti, pro­muo­ven­do così uno sviluppo piuttosto lineare. Tuttavia, se compreso e uti­liz­za­to cor­ret­ta­men­te, il modello a V può essere uti­liz­za­to per lo sviluppo agile.

Nello sviluppo software ci sono vari modelli di sviluppo che possono essere uti­liz­za­ti a seconda del progetto e della struttura del team. La scelta di modelli di sviluppo è piuttosto ampia; ad esempio il modello a cascata o il modello a spirale sono molto diffusi. Il modello a cascata è par­ti­co­lar­men­te adatto per piccoli progetti lineari, mentre il modello a spirale può essere uti­liz­za­to per progetti iterativi.