Modello a V nello sviluppo software: fasi, livelli di test e quando usarlo nel 2026

Marcus Chen Staff Engineer, Backend e Cloud, YuSMP Group · Realizza programmi plan-driven e ibridi per clienti regolamentati statunitensi ed europei

Il modello a V nello sviluppo software è un modo sequenziale di costruire software in cui ogni fase di sviluppo ha una fase di test corrispondente, e il test di ogni fase viene pianificato nello stesso momento della fase stessa. Il modello si disegna come la lettera V: la progettazione scende lungo il braccio sinistro, la codifica sta in basso e i test risalgono il braccio destro. Sembra un'idea degli anni Novanta, e lo è. Eppure nel 2026 sostiene ancora gli audit nell'automotive, nei dispositivi medici, nell'avionica e nell'IT pubblico, perché le autorità di questi settori vogliono la prova che ogni requisito sia stato testato.

Questa prova è il motivo per cui la V sopravvive. Un team moderno può rilasciare in sprint di due settimane, ma quando arriva un assessor ISO 26262 o un revisore della FDA, chiede una catena che colleghi ogni requisito alla progettazione, al codice e al risultato del test. Quella catena è esattamente ciò che produce la V. È anche il motivo per cui la maggior parte dei team che offrono sviluppo software enterprise per settori regolamentati struttura ancora le proprie evidenze di test attorno alla V, anche quando il lavoro quotidiano procede a sprint.

Questa guida spiega il modello a V dello sviluppo software partendo dai fondamenti: cosa fa ciascun lato della V, un diagramma testuale riutilizzabile, un esempio concreto di tracciabilità dei requisiti, un elenco onesto di vantaggi e svantaggi, un confronto con waterfall, Agile e modello a W e una visione pratica di quando la V è la scelta giusta e quando no.

Che cos'è il modello a V nello sviluppo software?

Il modello a V nello sviluppo software è un ciclo di vita plan-driven in cui ogni fase di sviluppo sul lato sinistro della V è collegata a un livello di test sul lato destro che la controllerà in seguito. Il lato sinistro è la verifica: stiamo costruendo il prodotto nel modo giusto? Il lato destro è la validazione: stiamo costruendo il prodotto giusto? La codifica si trova al vertice, dove i due lati si incontrano.

Il modello viene generalmente descritto come un'estensione del modello waterfall. Il waterfall esegue le fasi una dopo l'altra e colloca i test verso la fine. La V mantiene la stessa sequenza per la costruzione, ma piega la linea verso l'alto dopo la codifica, così ogni livello di test si trova di fronte alla fase di progettazione che valida. Kevin Forsberg e Harold Mooz resero popolare la forma a V per l'ingegneria dei sistemi in un articolo del 1991. Da allora è stata adottata dall'industria dei dispositivi medici, usata nelle linee guida di ingegneria dei sistemi della Federal Highway Administration statunitense e formalizzata nello standard federale tedesco V-Modell XT per i progetti IT del settore pubblico.

Per collocare la V tra gli altri approcci: appartiene alla famiglia plan-driven del ciclo di vita dello sviluppo software, accanto al waterfall e all'opposto della famiglia iterativa che comprende Scrum e Kanban. La nostra panoramica sulle altre metodologie di sviluppo software le mette tutte a confronto.

Verifica vs validazione nel modello a V

Verifica e validazione rispondono a due domande diverse, e il modello a V colloca ciascuna sul proprio braccio. La tabella seguente mostra come funziona la distinzione nella pratica.

Diagramma del modello a V: come si collegano i due lati

Un diagramma del modello a V mostra le fasi di sviluppo che scendono lungo il braccio sinistro, la codifica in basso e i livelli di test che risalgono il braccio destro, con un collegamento orizzontale tra ogni coppia. Il collegamento è la parte essenziale. Significa che il piano di test della fase di destra viene scritto mentre si svolge la fase di sinistra, non dopo che il codice esiste.

Leggi il diagramma partendo in alto a sinistra, scendi fino al vertice e poi risali a destra. Le fasi da 1 a 4 restringono l'ambito dalle esigenze di business ai singoli moduli. La fase 5 trasforma i progetti dei moduli in codice. Le fasi da 6 a 9 allargano di nuovo l'ambito, dalle singole unità fino al sistema completo nelle mani del cliente. Ogni coppia orizzontale condivide lo stesso livello di astrazione, quindi il test controlla sempre il lavoro svolto allo stesso livello.

Lo stesso abbinamento come tabella di riferimento, con l'artefatto prodotto da ogni fase e il responsabile abituale dell'approvazione:

Le fasi di verifica (lato sinistro della V)

Le fasi di verifica sul lato sinistro della V trasformano un'esigenza di business in un progetto abbastanza dettagliato da essere codificato, e ognuna scrive anche il piano di test della sua controparte a destra. Qui la verifica è soprattutto statica: i documenti vengono revisionati, ispezionati e approvati prima che il lavoro scenda di un livello.

Analisi dei requisiti di business (+ piano dei test di accettazione)

L'analisi dei requisiti di business raccoglie ciò di cui cliente e utenti hanno bisogno, nel loro linguaggio. Gli analisti conducono workshop e interviste, poi scrivono una specifica con requisiti funzionali e non funzionali, ciascuno con un ID univoco. Contemporaneamente il team prepara il piano dei test di accettazione: per ogni requisito, come confermerà il cliente in seguito che funziona? Scrivere subito questo criterio di accettazione fa emergere requisiti vaghi come “il sistema deve essere veloce”.

Progettazione di sistema (+ piano dei test di sistema)

La progettazione di sistema traduce i requisiti di business in requisiti di sistema e in una descrizione del sistema completo: confini tra hardware e software, interfacce esterne, flussi di dati e obiettivi di prestazione. Nei progetti automotive o medicali è qui che i requisiti software e hardware si separano. In parallelo si scrive il piano dei test di sistema, che definisce scenari end-to-end, ambienti e dati necessari per testare il sistema integrato rispetto a questi requisiti.

Progettazione architetturale / HLD (+ piano dei test di integrazione)

La progettazione architetturale, o high-level design (HLD), scompone il sistema in componenti e definisce come comunicano: API, formati dei messaggi, database, servizi di terze parti e gestione degli errori tra di essi. Il piano dei test di integrazione viene creato in parallelo e punta proprio a queste giunzioni. Specifica quali interfacce vengono testate, in quale ordine si combinano i componenti e quali stub o simulatori sostituiscono le parti non ancora costruite.

Progettazione dei moduli / LLD (+ piano dei test unitari)

La progettazione dei moduli, o low-level design (LLD), descrive la logica interna di ogni componente: classi, funzioni, algoritmi, strutture dati e condizioni limite. È l'ultimo passo prima del codice. Qui si scrive il piano dei test unitari, che elenca per ogni modulo gli input, i casi limite e gli output attesi che un test unitario deve coprire. Nei progetti critici per la sicurezza è qui che si fissano anche gli obiettivi di copertura strutturale, come la copertura delle istruzioni o MC/DC.

Codifica: il vertice della V

La codifica è il punto della V in cui il progetto diventa software e inizia il lato destro. Gli sviluppatori implementano ogni modulo secondo il suo progetto dettagliato, seguendo standard di codifica (MISRA C nell'automotive, per esempio) e superando code review e analisi statica prima dei test unitari. Poiché il piano dei test unitari esiste già, gli sviluppatori sanno prima di scrivere una riga quale comportamento verrà controllato.

Le fasi di validazione (lato destro della V)

Le fasi di validazione sul lato destro della V eseguono i piani di test scritti in precedenza, dalla più piccola unità di codice fino al sistema completo nell'ambiente del cliente. Ogni livello testa rispetto alla specifica della sua fase partner, non solo rispetto al codice. È questo che rende facile risalire da un test fallito alla sua causa.

Test unitari

I test unitari controllano ogni modulo in isolamento rispetto al suo progetto dettagliato. Sviluppatori o tester dedicati eseguono il piano dei test unitari, di solito tramite un framework automatizzato, con le dipendenze sostituite da mock o stub. Un test unitario fallito indica direttamente un errore di codifica o un difetto nel progetto del modulo, il punto più economico in cui correggere sul lato destro della V.

Test di integrazione

I test di integrazione verificano che i moduli lavorino insieme come previsto dall'architettura. I team combinano i componenti passo dopo passo, con strategia top-down, bottom-up o mista, ed esercitano le interfacce definite nell'HLD: formati dei dati, tempistiche, propagazione degli errori e transazioni. I difetti tipici sono assunzioni discordanti tra team, per esempio su unità di misura, gestione dei valori nulli o logica di retry.

Test di sistema

I test di sistema valutano il sistema completo e integrato rispetto ai requisiti di sistema. Coprono il comportamento funzionale e le qualità non funzionali: prestazioni, sicurezza, affidabilità, usabilità e, nei progetti embedded, il comportamento sull'hardware di destinazione o su un banco hardware-in-the-loop. Di solito li esegue un team QA indipendente in un ambiente il più vicino possibile alla produzione.

Test di accettazione (UAT)

I test di accettazione confermano che il sistema soddisfa i requisiti di business ed è pronto per l'uso reale. Clienti o utenti finali eseguono il piano scritto all'inizio del progetto, spesso come user acceptance testing (UAT), insieme agli eventuali passaggi di accettazione contrattuali o normativi. Un esito positivo chiude la V: il requisito raccolto nella fase 1 ha dimostrato di funzionare nella fase 9.

Come funziona la tracciabilità nel modello a V? Un esempio concreto

Nel modello a V tracciabilità significa che ogni requisito può essere seguito scendendo lungo il lato sinistro fino al codice che lo implementa e risalendo il lato destro fino ai test che lo dimostrano, e viceversa. Lo strumento per farlo è la matrice di tracciabilità dei requisiti (RTM). Automotive SPICE 4.0, pubblicato dal VDA QMC nel novembre 2023, richiede esplicitamente la tracciabilità bidirezionale: dai requisiti ai test e dai test ai requisiti, in modo che nessun test resti orfano e nessun requisito resti non testato.

Ecco un requisito seguito attraverso l'intera V. Prendiamo un terminale di pagamento con il requisito di business REQ-017: “L'autorizzazione al pagamento deve bloccarsi dopo tre inserimenti errati del PIN.”

1. Requisito di business (fase 1). REQ-017 viene scritto e approvato. Il suo criterio di accettazione: “Dopo tre PIN errati con una carta reale, il terminale rifiuta ulteriori tentativi e mostra il messaggio di blocco.”
2. Requisito di sistema (fase 2). SYS-042 stabilisce che il blocco deve persistere dopo un riavvio del terminale ed essere registrato nell'audit trail entro un secondo.
3. Architettura (fase 3). ARC-09 assegna il contatore al servizio di autorizzazione e lo stato di blocco al componente di archiviazione sicura, con un'interfaccia definita tra i due.
4. Progettazione dei moduli (fase 4). MOD-AUTH-3 definisce la logica del contatore, incluso l'azzeramento dopo un PIN corretto e il comportamento limite a esattamente tre tentativi.
5. Codice (fase 5). Il modulo PinAttemptCounter implementa MOD-AUTH-3.
6. Test (fasi da 6 a 9). UT-311 controlla il contatore a 2, 3 e 4 tentativi; IT-58 verifica che il blocco raggiunga l'archiviazione sicura; ST-120 riavvia il terminale durante il blocco; AT-17 esegue lo scenario del cliente con una carta reale.

L'estratto corrispondente della RTM è il seguente:

Due aspetti rendono la RTM utile invece che burocratica. Primo, una riga fallita indica subito quale requisito è a rischio e quale elemento di progetto controllare: REQ-020 è fallito a livello di sistema, quindi la correzione parte da SYS-050 e non da una ricerca casuale nel codice. Secondo, una richiesta di modifica diventa un'analisi d'impatto. Se il business cambia REQ-017 in “blocco dopo cinque tentativi”, la matrice elenca ogni elemento di progetto e ogni test da modificare su entrambi i lati della V.

Principi fondamentali del modello a V

Il modello a V si basa su pochi principi che lo distinguono da un semplice processo sequenziale. Tutti si riducono a un'idea: pensare a come testerai qualcosa nel momento stesso in cui decidi cosa deve essere.

• Pianificazione dei test in parallelo allo sviluppo. Ogni fase a sinistra consegna il proprio piano di test, così i test iniziano dal primo giorno e non dopo la codifica.
• Prevenire i difetti prima che rilevarli. Scrivere test a partire da una specifica fa emergere ambiguità e lacune prima che diventino codice. I costi crescono nettamente quanto più tardi si scopre un difetto, quindi la prevenzione ripaga.
• Requisiti chiari e testabili. Un requisito senza criterio di accettazione non è finito. La V impone questa disciplina.
• Phase gate e approvazione formale. Ogni fase si chiude con revisione e approvazione prima che inizi la successiva, creando punti di audit naturali.
• Test statico a sinistra, test dinamico a destra. Revisioni, ispezioni e analisi statica verificano documenti e codice; i test basati sull'esecuzione validano il comportamento.
• Corrispondenza uno a uno tra fasi e test. Ogni livello di sviluppo ha esattamente un livello di test che lo controlla, allo stesso livello di astrazione.

Vantaggi e svantaggi del modello a V

Il modello a V scambia flessibilità con controllo. Produce evidenze eccellenti e una progettazione precoce dei test, ma fatica quando i requisiti cambiano. Vale la pena leggere entrambi gli elenchi prima di sceglierlo.

Vantaggi

• Progettazione precoce dei test. I piani di test esistono prima del codice, così i tester trovano i difetti di specifica quando correggerli costa ancora poco.
• Evidenze pronte per l'audit. Specifiche, verbali di revisione, piani e risultati dei test e la RTM sono sottoprodotti naturali, esattamente ciò che chiedono gli assessor.
• Deliverable chiari per fase. Tutti sanno cosa deve produrre ogni fase e chi la approva.
• Gate e milestone prevedibili. L'avanzamento è facile da riportare e da collegare a pagamenti o passaggi di certificazione.
• Meno sorprese tardive. I difetti trovati a ogni livello di test rimandano a una fase di progettazione precisa, accorciando l'analisi delle cause.
• Adatto a scope fisso e contratti. I contratti a prezzo fisso e regolamentati si mappano naturalmente sulle fasi in baseline della V.

Svantaggi

• Rigido quando i requisiti cambiano. Una modifica in cima alla V si propaga su progetto, codice e quattro livelli di piani di test.
• Il software funzionante arriva tardi. Gli stakeholder vedono un sistema in esecuzione solo dopo la codifica e i primi test.
• Rilavorazioni costose. Un errore nei requisiti scoperto nei test di accettazione significa rivedere ogni fase sottostante.
• Carico documentale elevato. Specifiche, piani e matrici richiedono un impegno reale per essere scritti e aggiornati.
• Feedback del cliente debole. Gli utenti validano il prodotto solo alla fine, a meno che il team non aggiunga prototipi o demo.
• Poco adatto ai prodotti in fase di discovery. Se non sai ancora cosa costruire, la V congelerà la risposta sbagliata.

Modello a V vs waterfall vs Agile: qual è la differenza?

Il modello a V si distingue dal waterfall perché abbina ogni fase di progettazione a un proprio livello di test e pianifica presto questi test. Si distingue da Agile perché è sequenziale e guidato dalle specifiche anziché iterativo. Il modello a W è un'evoluzione della V che aggiunge un'attività di test parallela a ogni fase. Il confronto qui sotto riassume i compromessi.

In pratica, la V e il modello waterfall sono parenti stretti: entrambi plan-driven, entrambi con phase gate, entrambi adatti a requisiti stabili. Il vantaggio della V è un test strutturato e precoce con tracciabilità integrata. Lo sviluppo software Agile segue la filosofia opposta e ottimizza per l'apprendimento e il cambiamento. Di solito la scelta non è V o Agile, ma quanto di ciascuno, tema della sezione sull'ibrido più sotto.

Quando il modello a V è la scelta giusta per lo sviluppo software?

Il modello a V è la scelta giusta quando i requisiti sono stabili, i guasti sarebbero costosi o pericolosi e qualcuno esterno al team chiederà la prova dei test. Se la maggior parte dei punti seguenti si applica al tuo progetto, la V, o un ibrido costruito su di essa, è una buona scelta:

• I requisiti sono ben compresi e difficilmente cambieranno molto durante la realizzazione.
• Il sistema è critico per la sicurezza o per la missione: un guasto potrebbe ferire persone, fermare le attività o causare grandi perdite economiche.
• Un'autorità, un organismo notificato o un ente di certificazione verificherà le tue evidenze di sviluppo e di test.
• Il software viene sviluppato insieme all'hardware, quindi interfacce e tempistiche vanno specificate e testate livello per livello.
• Il contratto è a prezzo fisso o a scope fisso, con l'accettazione legata a criteri concordati.
• I criteri di accettazione possono essere scritti chiaramente all'inizio.
• Più fornitori costruiscono parti del sistema e hanno bisogno di punti di integrazione definiti.

La V è una cattiva scelta per un MVP in fase iniziale, un'app consumer le cui funzionalità dipendono dal feedback del mercato o qualsiasi progetto con scope ancora poco chiaro. In questi casi una delivery iterativa trova più velocemente il prodotto giusto, e la tracciabilità in stile V si può aggiungere in seguito se il prodotto entra in un mercato regolamentato.

Come si usa il modello a V nei settori regolamentati?

I settori regolamentati usano il modello a V perché le loro norme sono a loro volta costruite attorno ad attività di sviluppo e verifica abbinate. Seguire la V rende le evidenze di conformità un sottoprodotto del lavoro normale invece di un progetto documentale separato alla fine.

Automotive: ISO 26262 e Automotive SPICE 4.0

Il software automotive è oggi il caso d'uso più chiaro del modello a V. ISO 26262 (seconda edizione, 2018) organizza il lavoro di sicurezza funzionale dal concetto alla progettazione di sistema e all'implementazione, fino a verifica e validazione, una sequenza che si mappa direttamente sulla V, come descrive SPEC Innovations nel suo whitepaper sul tema. Automotive SPICE 4.0 definisce aree di processo scendendo lungo il lato sinistro, dai requisiti e dalla progettazione fino all'unità software, e test di verifica risalendo il lato destro, dall'unità al sistema, con tracciabilità bidirezionale. Aptiv descrive la propria V automotive come requisiti di sistema, progettazione di sistema, requisiti software, implementazione e poi test di integrazione e qualifica software e di sistema. Per il quadro generale vedi la nostra guida allo sviluppo software automotive.

Dispositivi medici: IEC 62304 e validazione software FDA

Il software dei dispositivi medici segue IEC 62304 (con l'Amendment 1 del 2015), che richiede pianificazione dello sviluppo, requisiti, architettura, progettazione dettagliata, verifica delle unità, test di integrazione e test di sistema, proporzionati alla classe di sicurezza del software. Quell'elenco è la V in tutto tranne che nel nome. Negli Stati Uniti la guida FDA sulla validazione del software si aspetta evidenze documentate che il software soddisfi le esigenze degli utenti e l'uso previsto, esattamente ciò che fornisce il livello di accettazione della V. Maggiori dettagli nella nostra guida allo sviluppo software per dispositivi medici.

Aerospazio e difesa: DO-178C

Il software avionico è certificato secondo DO-178C, pubblicato nel 2011. La norma richiede requisiti di alto e basso livello, tracciabilità tra requisiti, codice e test e un'analisi di copertura strutturale il cui rigore cresce con il design assurance level, fino alla copertura MC/DC per il software più critico. L'abbinamento tra progettazione dei moduli e test unitari della V, insieme alla sua RTM, offre ai team un modo naturale per dimostrare queste evidenze. Il nostro articolo sul software per l'aviazione descrive il contesto di certificazione.

Settore pubblico: V-Modell XT e ingegneria dei sistemi

Lo standard federale tedesco V-Modell XT prescrive un processo a V adattabile per i progetti IT del settore pubblico, definendo ruoli, prodotti e punti decisionali sia per il committente sia per il fornitore. Negli Stati Uniti la Federal Highway Administration ha usato la V nelle sue linee guida di ingegneria dei sistemi per i progetti di trasporto intelligente, tra cui il concept of operations Clarus del 2005. Gli acquirenti pubblici preferiscono la V perché lega ogni passaggio di accettazione a un requisito contrattuale.

Il modello a V funziona con Agile? V ibrida, modello a W e Agile V nel 2026

Sì. Nel 2026 il modello a V viene usato soprattutto come cornice di governance e di evidenze attorno a una delivery iterativa, non come sequenza rigida in un solo passaggio. I team mantengono i livelli, i piani di test e la tracciabilità della V e lavorano al loro interno con iterazioni brevi. Tre schemi sono comuni.

Sprint dentro la V. Requisiti e architettura vengono messi in baseline in cima alla V per una release o un incremento. All'interno della fascia di implementazione i team lavorano a sprint: ogni sprint consegna funzionalità progettate, codificate e testate a livello unitario e di integrazione, con l'aggiornamento della RTM come parte della definition of done. Test di sistema e di accettazione si svolgono a livello di release. È l'ibrido più diffuso oggi nei programmi automotive e medicali.

Il modello a W. Il modello a W aggiunge un'attività di test in parallelo a ogni fase di sviluppo: revisionare i requisiti mentre vengono scritti, testare il progetto mentre viene disegnato e così via. Disegnato, appare come due V sovrapposte, da cui il nome. Spinge lo shift-left testing oltre la V classica.

Agile V con agenti di IA. Un framework pubblicato su arXiv nel febbraio 2026 da Koch e Wellbrock, chiamato Agile V, integra la verifica indipendente e la generazione di artefatti di audit in ogni ciclo di attività agile, con agenti di IA per ciascuna fase e punti di approvazione umana. Il loro studio di fattibilità su un sistema hardware-in-the-loop di circa 500 righe di codice, 8 requisiti e 54 test ha riportato un tasso di superamento del 100% a livello di requisito e stimato una riduzione dei costi da 10 a 50 volte rispetto a una baseline COCOMO II. Si tratta di un singolo, piccolo caso di studio e non di un benchmark di settore, ma mostra dove sta andando la V: generazione automatizzata delle evidenze dentro iterazioni rapide.

Le pipeline di continuous integration rendono praticabili tutti e tre gli schemi. Quando test unitari e di integrazione girano a ogni commit e i risultati sono collegati agli ID dei requisiti, il lato destro della V produce evidenze in modo continuo invece che in un unico blocco tardivo. La stessa idea è alla base di un ciclo di vita dello sviluppo software sicuro ed è prassi comune nello sviluppo di software embedded, dove i banchi hardware-in-the-loop girano ogni notte.

Come adottare il modello a V: 7 best practice

Un progetto a V ha successo quando la documentazione serve l'ingegneria e non il contrario. Queste sette pratiche mantengono il modello utile e snello.

1. Adatta la V al rischio del progetto. Una funzione di frenata critica per la sicurezza richiede ogni livello e revisioni indipendenti; uno strumento di reporting interno può unire HLD e LLD. Norme come V-Modell XT e IEC 62304 consentono esplicitamente il tailoring. Sfruttalo.
2. Scrivi i piani di test a ogni gate del lato sinistro. Non chiudere una fase finché il suo piano di test non esiste ed è stato revisionato. È il cuore della V; se lo salti, stai facendo waterfall.
3. Mantieni una RTM viva nel tuo strumento ALM. Gestisci la tracciabilità in uno strumento di application lifecycle management o in un issue tracker (Jira, Polarion e codeBeamer sono scelte comuni) anziché in un foglio di calcolo, così i collegamenti si aggiornano a ogni modifica.
4. Automatizza test unitari e di integrazione nella CI. Test automatizzati collegati agli ID dei requisiti trasformano la parte bassa del lato destro della V in un'evidenza continua.
5. Esegui revisioni e analisi statica a sinistra. Ispeziona requisiti e progetti con checklist ed esegui l'analisi statica del codice prima dei test unitari. È qui che la V mantiene la sua promessa di prevenzione dei difetti.
6. Gestisci le modifiche con un'analisi d'impatto su entrambi i lati. Ogni richiesta di modifica dovrebbe elencare gli elementi di progetto e i test coinvolti. Con la RTM è una query, non un'ipotesi.
7. Usa la verifica indipendente per i livelli critici. Per i livelli di integrità più alti, fai eseguire revisioni e test a persone che non hanno scritto né il codice né il progetto, come si aspettano ISO 26262 e DO-178C.

Queste pratiche si sovrappongono molto alla disciplina generale della quality assurance. La V assegna semplicemente a ogni attività QA un posto fisso e una fase partner.

FAQ

Ultimo aggiornamento 2 ottobre 2026. Fonti: Wikipedia, V-model (software development); Aptiv, What Is the V-Model in Software Development?; VDA QMC, Automotive SPICE PAM v4.0 (2023); Koch & Wellbrock, Agile V, arXiv 2602.20684 (2026); SPEC Innovations, ISO 26262 and the Systems Engineering V-Model; Built In, What Is the V-Model in Software Development?. Norme: ISO 26262:2018, IEC 62304 (Amd 1:2015), DO-178C (2011). L'esempio di RTM è illustrativo.