Che cosa significa verificare il software
La verifica del software è l’insieme dei controlli volti a determinare se un prodotto o risultato ingegneristico è conforme ai requisiti e alle specifiche applicabili. La domanda pratica è: «è stato realizzato secondo quanto definito?». Nel quadro dell’ingegneria dei sistemi della NASA, la verifica confronta il prodotto con i suoi requisiti o le sue specifiche; questa distinzione aiuta a comprendere anche programmi, componenti e risultati di sviluppo software. NASA: verifica del prodotto
La verifica non è un’unica attività da svolgere necessariamente alla fine. Può essere applicata a diversi risultati durante lo sviluppo: una specifica può essere esaminata rispetto a esigenze concordate in precedenza, un progetto rispetto ai requisiti e un’implementazione rispetto al progetto o a criteri tecnici. Il riferimento deve essere esplicito: se non esiste un requisito identificabile, non è possibile indicare con chiarezza quale condizione è stata controllata. La sequenza concreta dipende dal progetto e non va confusa con una ricetta universale.
Verificare non equivale nemmeno a dichiarare che tutto il software sia corretto, sicuro o utile in qualsiasi situazione. Un controllo fornisce evidenze relative a un ambito definito, secondo criteri e condizioni specifici. Per esempio, l’esame di un particolare calcolo non dimostra automaticamente che tutte le funzioni, le versioni, i dati di input o gli ambienti si comportino in modo adeguato.
Che cosa si può verificare
Gli oggetti della verifica possono includere requisiti, progetto, codice eseguibile, componenti integrati e documentazione associata, purché esistano criteri applicabili con cui confrontarli. La pagina della NASA descrive la verifica di un prodotto finale come un controllo di conformità a requisiti o specifiche e sottolinea l’importanza di mantenere una configurazione di riferimento controllata. La stessa logica vale per l’ambito: ogni affermazione dovrebbe identificare l’elemento e la versione esaminati. NASA: verifica del prodotto
In un esempio semplice, un requisito potrebbe stabilire che un’applicazione calcoli un totale a partire da quantità e prezzi. La verifica può controllare che la formula implementata corrisponda alla regola specificata e che, nei casi esaminati, il risultato coincida con quello atteso. Se la regola stessa è formulata male — per esempio, omette uno sconto necessario nell’uso reale — il programma potrebbe rispettarla e tuttavia non soddisfare l’esigenza. Ecco perché verifica e validazione non vanno trattate come sinonimi.
Anche la documentazione è importante perché definisce che cosa si considera conforme e registra l’attività svolta. Un piano di verifica e validazione può riportare responsabilità, documenti applicabili, metodi e matrici che collegano i requisiti alle evidenze. Lo schema pubblicato dalla NASA include sezioni distinte per metodi di verifica e validazione, implementazione e matrici dei requisiti. La tracciabilità aiuta a individuare copertura e lacune, ma una matrice completa non dimostra di per sé che ogni risultato sia corretto. NASA: schema del piano di verifica e validazione
Come si svolge: revisione, analisi e test
La verifica può riunire diverse forme di esame. Una revisione umana confronta documenti o modifiche con criteri definiti; un’analisi può cercare proprietà o incoerenze senza eseguire il programma; un test osserva il comportamento del software eseguendolo in condizioni selezionate. Le informazioni del NIST sulle sue attività formative in verifica e validazione del software sottolineano la documentazione delle evidenze e l’uso di tecniche di entrambi i tipi, anche se gli esempi si concentrano su fogli di calcolo di laboratorio e non costituiscono un elenco esaustivo per ogni progetto. NIST: formazione sulla verifica e validazione del software
Un esempio di controllo rispetto a una specifica
Supponiamo che una specifica richieda a un sistema di rifiutare una richiesta se manca un campo obbligatorio. Una revisione potrebbe controllare che il requisito sia definito e che il progetto consideri il caso; un test potrebbe inviare una richiesta incompleta e confrontare la risposta osservata con il risultato atteso. Ogni metodo risponde a una domanda diversa: la revisione esamina artefatti e ragionamenti, mentre il test osserva un comportamento con input e condizioni specifici.
I test non esaminano tutti gli input possibili solo perché vengono eseguiti. Il risultato dipende dai casi selezionati, dalla versione sottoposta a test e dall’ambiente utilizzato. Di conseguenza, «ha superato i test» significa che nei controlli effettuati non è stata rilevata una discrepanza, non che sia stata dimostrata l’assenza di difetti. Le evidenze sono più facili da interpretare se si conserva il legame tra requisito, criterio di accettazione, caso eseguito, risultato e versione del prodotto.
Una pratica utile di registrazione
Per consentire ad altri di capire che cosa è stato verificato, è utile registrare l’elemento e la versione esaminati, il requisito associato, il metodo applicato, le condizioni pertinenti e il risultato. Quando contano i controlli o gli audit, tale registrazione permette di spiegare l’ambito e di riesaminare le modifiche successive. Il NIST presenta la documentazione delle evidenze e la valutazione continuativa del software tra gli obiettivi delle proprie risorse formative per i laboratori; il contenuto specifico di ogni registrazione va adeguato al contesto. NIST: formazione sulla verifica e validazione del software
Verifica e validazione rispondono a domande diverse
La verifica chiede se il prodotto è conforme ai requisiti o alle specifiche definiti. La validazione chiede se il prodotto soddisfa l’uso previsto e le esigenze pertinenti nel contesto in cui verrà utilizzato. La NASA esprime la differenza con due domande: se il prodotto è stato realizzato correttamente rispetto a quanto specificato e se soddisfa ciò che il cliente intendeva nell’ambiente d’uso. NASA: verifica del prodotto
| Aspetto | Verifica | Validazione |
|---|---|---|
| Domanda centrale | Il prodotto è conforme ai requisiti o alle specifiche? | Il prodotto è adatto all’uso previsto e alle esigenze del cliente? |
| Riferimento | Requisiti, specifiche e documentazione applicabili | Intento d’uso e contesto del cliente o dell’utente |
| Esempio illustrativo | Controllare che un calcolo implementi la formula specificata | Valutare se quel calcolo risolve l’attività che l’utente deve svolgere |
La tabella riassume la distinzione di obiettivo descritta dalla NASA; non implica che ogni attività utilizzi un metodo esclusivo o che esista un confine rigido tra le tecniche. NASA: verifica del prodotto
Consideriamo un’applicazione che calcola il costo di una spedizione. Se la specifica dice che deve sommare una tariffa base e un supplemento, controllare quel calcolo è verifica. Chiedersi se l’applicazione tiene conto delle esigenze reali — per esempio, se il flusso consente di indicare la destinazione e il tipo di consegna offerto dal servizio — riguarda invece la validazione. Il primo controllo può avere esito positivo mentre il secondo rivela che la soluzione definita non è adatta all’uso atteso.
Perciò non basta dire che un prodotto «è stato verificato» senza precisare il riferimento e l’ambito. La validazione non sostituisce tutti i controlli rispetto alle specifiche: entrambe le prospettive possono essere necessarie e complementari. I processi descritti dalla NASA distinguono gli obiettivi, pur riconoscendo che in pratica alcune attività possono sembrare simili. La denominazione dipende dalla domanda a cui si vuole rispondere, non solo dal fatto che l’attività si chiami test o revisione.
Quali evidenze produce e come interpretarle
Le evidenze possono consistere in risultati dei test, osservazioni delle revisioni, analisi documentate o matrici che collegano requisiti e controlli. Non tutte dimostrano la stessa cosa: il risultato di un’esecuzione supporta un’osservazione per determinati input e un ambiente specifico; una revisione può documentare che un artefatto è stato valutato rispetto a criteri. La conclusione non deve andare oltre le evidenze né estendersi a versioni o condizioni che non sono state esaminate.
La tracciabilità aiuta a seguire il collegamento tra un requisito e l’attività destinata a controllarlo. Lo schema di pianificazione della NASA propone sia una matrice di verifica dei requisiti sia una matrice di validazione, oltre alla documentazione di metodi e attività. Offre una struttura per organizzare le evidenze, non una garanzia automatica che i requisiti siano formulati bene, completi o rappresentativi delle esigenze degli utenti. NASA: schema del piano di verifica e validazione
Per esempio, se cambia una regola di calcolo, sapere quali requisiti, componenti e casi di controllo le sono associati consente di esaminare l’impatto della modifica. Tuttavia, un collegamento documentale può essere obsoleto o non coprire un comportamento importante. La gestione delle versioni e il riesame delle evidenze restano necessari; una lista di caselle spuntate è utile solo se descrive attività reali, risultati interpretabili e l’artefatto corretto.
Limiti, equivoci e uso pratico
La verifica è una pratica circoscritta, non una dimostrazione matematica di perfezione. Possono restare difetti perché alcuni casi non sono stati esaminati, i criteri erano incompleti o l’ambiente reale differisce da quello utilizzato. È anche possibile rispettare alla lettera una specifica che non rappresenta bene l’esigenza. Una dichiarazione responsabile indica quindi che cosa è stato esaminato, rispetto a quale riferimento e in quali condizioni, anziché affermare che il software è privo di errori.
Nei progetti ad alto rischio o soggetti a requisiti di controllo, può essere importante che la revisione sia indipendente. Il glossario del NIST descrive la verifica e validazione indipendenti come revisione, analisi e test svolti da una terza parte obiettiva per esaminare sia la definizione dei requisiti sia l’implementazione delle funzioni e dei requisiti di sicurezza. Questa definizione riguarda IV&V; non significa che ogni progetto abbia necessariamente bisogno di un gruppo esterno né che l’indipendenza elimini i limiti di copertura. NIST: glossario della verifica e validazione indipendenti
Per interpretare un’affermazione di verifica o pianificare un controllo, queste domande aiutano a precisarne l’ambito:
- Quale prodotto, componente, documento e versione sono stati esaminati?
- Rispetto a quale requisito, specifica o criterio è stato effettuato il confronto?
- Quale metodo è stato applicato e in quali condizioni?
- Quali evidenze sono state registrate e quali casi non coprono?
- La domanda riguardava la conformità a quanto specificato o l’adeguatezza all’uso previsto?
La norma ISO/IEC/IEEE 12207 offre un quadro di processi del ciclo di vita del software, ma le fonti raccolte per questo articolo non includono il testo ufficiale della norma. Per questo il glossario non attribuisce requisiti specifici a tale norma e non propone una ricetta normativa. Le indicazioni qui presentate si basano principalmente sulla documentazione della NASA relativa alla verifica e validazione dei prodotti e sulle risorse del NIST riguardanti evidenze e IV&V; le tecniche specifiche vanno scelte in base al sistema, ai suoi rischi e agli obblighi applicabili. NASA: verifica del prodotto NIST: IV&V