ISO 12207 ha una distinzione piuttosto non standard (e molto sfumata!) tra verifica e convalida. Nella maggior parte delle cerchie, la verifica risponde alla domanda "l'abbiamo costruita correttamente?" (il nostro prodotto soddisfa i requisiti?), mentre la convalida significa "era questa la cosa giusta da costruire" (abbiamo il giusto insieme di requisiti?). La ISO 12207 menziona la verifica dei requisiti. Come si verificano i requisiti, in particolare i requisiti di massimo livello? Non lo fai. Tu li convalidi.
Il prodotto su cui trascorro la maggior parte del mio tempo utilizzato per distinguere la verifica dalla convalida. I problemi con questa distinzione sono saltati su una base fastidiosamente frequente. La distinzione mi era chiara, ma la mia interpretazione non era universalmente condivisa. È un test di convalida o un test di verifica? A chi importa? Perché stiamo avendo questa stupida battaglia? Una rosa con qualsiasi altro nome odora altrettanto dolce. L'obiettivo finale è rispondere alla domanda "È giusto?"
La nostra risoluzione a questo imbroglio in corso è stata quella di eliminare quella distinzione tra verifica e convalida. Pensiamo alla verifica & validazione come una parola che insieme rispondono alla domanda "È giusto?" Non dividiamo V & V in parti arbitrarie. Ciò che dividiamo in parti è come andiamo a rispondere a quella domanda singolare. Sia che tu stia guardando il nostro documento di alto livello o un documento modello dettagliato come il modo in cui modelliamo la gravità, il capitolo 5 è intitolato "Ispezioni, test e metriche". Il vecchio titolo "Verification and Validation": è sparito. Non dividiamo la verifica dalla convalida. Abbiamo invece diviso le cose in ispezioni, test e metriche. Il capitolo ha in genere quattro sezioni, ispezioni, test, tracciabilità (in genere automatizzata) e metriche (anche in genere automatizzate). A parte: l'analisi della tracciabilità è solo un tipo di ispezione specializzata (ma molto importante). È elevato come una sezione separata a causa della sua importanza. Abbiamo cercato un po 'se chiamare il capitolo "Ispezioni, test, tracciabilità e metriche". La risposta era no. Niente più guerre di religione sui nomi. La tracciabilità è una sorta di ispezione; il titolo si adatta ancora.
Le cose che rispondono alla domanda "è giusto" senza usare effettivamente il prodotto vanno sotto il titolo di "ispezioni". Analisi dei requisiti, analisi di tracciabilità, analisi che dimostrano che le ipotesi di semplificazione formulate dal modello sono accettabili per l'uso previsto del modello: Sono tutte ispezioni perché non abbiamo utilizzato il prodotto. La tracciabilità, mentre un'ispezione, ha una propria casa. Usando il prodotto per rispondere a questa domanda vai sotto la rubrica "test". Tutto, dai test unitari ai test rispetto ad alcuni setup artificiali con una soluzione analitica nota ai test integrati in cui stiamo confrontando i risultati del prodotto con i dati reali raccolti da un veicolo precedentemente pilotato: sono tutti test. Lungo la strada raccogliamo molte metriche, molte delle quali automatizzate. Diversi livelli di documenti hanno diversi tipi di numeri noiosi ma importanti. Conteggio SLOC, complessità, copertura del codice, numero di esenzioni concesse, numero di problemi nel sistema CM. Quei numeri noiosi ma importanti vanno sotto la rubrica "metriche".
I nostri sviluppatori e tester apprezzano questo cambiamento perché ora è chiaro dove vanno le cose. La gestione del progetto adora questo cambiamento perché è coerente e perché rimuove tutte quelle sciocche discussioni sulla nomenclatura. I nostri signori CMMI lo amano perché stiamo ancora rispondendo alla domanda giusta ("È giusto") e perché abbiamo un processo ben definito per arrivarci. I segnalini Bean lo adorano perché stiamo dando loro molti fagioli che sono molto facili da trovare e molto facili da contare.
