Estratto dal volume "Validazione strutturale", di Paolo Rugarli, EPC Libri, 2014
4.1 Un concetto non banale
Cosa sia una validazione potrebbe sembrare cosa ovvia, ma non è così.
Si potrebbe sostenere che validare un programma o un modello significhi verificare che esso sia “valido” per qualche fine,
ovvero che i risultati che esso (modello o programma) fornisce siano corretti o utili per qualche fine.
In realtà una simile affermazione non si può fare se non con alcune ben precise restrizioni e specificazioni,
che però sembrano non essere presenti alla maggior parte delle persone che parlano di validazione.
La validazione è una attività tecnico-scientifica che non può che essere fatta in modo soggettivo ed in modo probabilistico.
In modo soggettivo perché chi afferma che qualcosa “è valido” o anche “affidabile” “pertinente”, “corretto”, “utile”, “in accordo alle leggi vigenti”,
e via discorrendo, non può fare questa affermazione se non sulla base delle proprie conoscenze e delle proprie opinioni professionali. Il giudizio tecnico
non può mai essere oggettivo ed assoluto, ma al massimo ampiamente condiviso. Ciò cozza con l’idea popolare che la scienza e la tecnica siano il regno delle
certezze, ma è pienamente in linea con la idea che della scienza e della tecnica ha chi su di essa ha ragionato approfonditamente e metodicamente.
In modo probabilistico perché non si può mai escludere che ulteriori prove o ulteriori test, fatti cambiando qualche cosa, possano portare a risultati
non più accettabili per quello stesso modello o programma.
Una campagna di test non può provare che un programma (o un modello) sia privo di difetti, ma può solo provare che questi non vi siano nei test eseguiti, e,
se si parla di ingegneria strutturale, in accordo alle opinioni professionali di chi ha eseguito quei test. Per gli studiosi di software testing,
ovvero per i veri esperti di software, è un fatto pacifico, assolutamente acclarato che una campagna di test non possa provare che un programma
sia privo di difetti.
A riguardo, se non dovesse bastare quanto sostengo io, cito alcuni testi classici sulla materia che sul punto sono estremamente chiari.
Ad esempio Beizer scrive ([86]):
Se lo scopo dei test fosse provare che un programma sia privo di errori, allora i test non solo sarebbero praticamente impossibili,
ma sarebbero anche teoricamente impossibili.[...] Ogni approccio porta alla conclusione che il test completo, nel senso di prova, è impossibile
sia teoricamente che praticamente
Mentre Morgan ([87]) afferma:
Eseguire un test su un software può solo provare che esistono uno o più difetti. I test non possono dimostrare che il software è privo di errori.
Con sistemi grandi e complessi non sarà mai possibile provare ogni cosa in modo esaustivo; in effetti è impossibile provare anche sistemi moderatamente
complessi in modo esaustivo
In [88] (un testo di base, per chi vuole imparare proprio i rudimenti) troviamo:
Principio di base dei Test. I test possono mostrare che sono presenti dei difetti, ma non possono provare che non ci siano difetti [...]
anche se non sono trovati difetti, questa non è una prova
Vedremo più avanti, quando tratterò i metaerrori e i metacontrolli, che vi è un orizzonte al di là del quale il singolo o,
l’insieme di singoli che fanno parte della organizzazione che ha eseguito i test, non possono andare, e tale orizzonte è quello della competenza
tecnica e teorica di chi esegue il controllo. Una competenza che è sempre incompleta e sempre anisotropa: c’è chi è più competente in una cosa,
chi in un’altra. Tutto ciò, a tacere di altri tipi di errori, che sono invece legati a distrazioni, qui pro quo, eccetera.
Dunque se da un lato non si può negare che qualsiasi affermazione che porti a dire che un modello o un programma è “adatto”, “affidabile”,
“attendibile”, “in accordo alla norma” e così via, è nei suoi intenti e nei suoi potenzialmente disastrosi effetti una “validazione”,
dall’altro va sin da subito detto che tali affermazioni, quando non corredate da opportuni delimitatori logici e semantici, è per definizione scorretta.
Particolarmente grave è il caso in cui affermazioni scorrette per ragioni teoriche e metodologiche sono fatte come affermazioni ufficiali, corredate da timbri, marchi,
o altro che possa suggerire una alta attendibilità.
Nessuno può affermare in senso assoluto che un programma o un modello è valido. Può solo affermare ciò in senso relativo (ovvero: soggettivo) e in senso probabilistico
(ovvero riferendosi a una ben precisa e definita campionatura, ovvero un certo insieme di test).
Nel caso dei programmi, ai due requisiti descritti si deve anche aggiungere un terzo requisito, il requisito storico. Infatti i test eseguiti
si riferiscono ad un ben preciso momento della vita del programma e dell’hardware su quale viene eseguito, e non è lecita la estrapolazione a tutte
le versioni del programma ed a tutti i sistemi operativi e hardware. Ciò vuol dire che non è possibile usare il presente indicativo ma solo il passato
prossimo, o quello remoto.
Non si può, a rigore, affermare “il programma X, a parere di chi scrive, esegue in modo affidabile questi 28 test e dà risultati in accordo alla
normativa”. Non basta. Occorre invece dire, con ben diversa carica semantica “il programma X nella versione Y, a parere di chi scrive, ha eseguito
in modo affidabile questi 28 test, in accordo alla normativa. Il calcolo è stato eseguito su computer Z, sistema operativo W, versione Q”.
Corollario di quanto sopra detto è che la “certificazione” (per definizione assoluta, almeno in senso etimologico) di un programma non può esistere.
Assoluta vuol dire ab soluta – slegata, disconnessa - dal criterio soggettivo, da quello probabilistico e da quello storico.
Il punto (non può esistere una validazione assoluta, ovvero definitiva e certa) è stato recentemente confermato anche da un parere del Consiglio
Superiore dei Lavori Pubblici, interpellato dalla Autorità Garante per la Concorrenza e il Mercato (AGCM), a sua volta attivatasi a seguito di una
mia segnalazione in merito a quella che consideravo una pratica commerciale scorretta. In merito il Consiglio Superiore dei Lavori Pubblici, dice:
______________________________________________________
Per quel che attiene al punto [della richiesta di chiarimento della AGCM al CSLLPP] “chiarimenti in merito alla possibilità di affermare,
in termini assoluti, che un determinato programma informatico (software), destinato al calcolo strutturale di edifici destinati ad essere realizzati
in area sismica, esegue in modo affidabile il calcolo della risposta della struttura come prescritto dalle suddette Norme Tecniche per le Costruzioni
(D.M. 14 gennaio 2008)”;
si osserva che, sulla base delle considerazioni sopra esposte, a prescindere dalla possibilità di asserire la affidabilità di un codice
di calcolo in senso “assoluto”, il progettista deve comunque controllare tale affidabilità e verificare i risultati ottenuti caso per caso.
Nello specifico della richiesta di informazione, si ritiene di osservare preliminarmente che la dizione “in termini assoluti” sia comunque
da leggersi come “in termini assoluti all’interno delle limitazioni e delle ipotesi dichiarate per il codice” e quindi non da riferirsi a
qualsiasi possibile e generale applicazione di calcolo strutturale.
Anche nel significato così precisato, si ritiene comunque di fatto impossibile affermare la affidabilità di un codice di calcolo in
termini assoluti, per due classi principali di motivazioni:
- Il livello di accuratezza delle soluzioni ottenute per via numerica in aritmetica finita tramite algoritmi automatici è intrinsecamente
affetto da approssimazioni la cui qualità va valutata caso per caso (il cosiddetto “condizionamento” del problema). Si citano a titolo
esemplificativo fra le più frequenti le soluzioni di sistemi lineari per l’analisi statica e l’estrazione di autovalori ed autovettori
per l’analisi modale con spettro di risposta.
- Se teoricamente possibile, il completo controllo della correttezza delle istruzioni di programmazione nelle quali vengono tradotti
i flussi logici e algoritmi in un codice di calcolo complesso richiederebbe lo sviluppo di una casistica tanto vasta da divenire di
fatto improponibile.
Una valutazione di affidabilità di un programma sarà tanto più possibile quanto più è ampia la casistica di esempi analizzati con
successo, oltre che dal giudizio di qualità degli algoritmi di soluzione adottati ove essi siano noti nel dettaglio, ma non potrà
quindi essere espressa in termini assoluti.
Si ritiene di aggiungere, quale informazione utile alla comprensione del quadro, che è nell’ambito delle argomentazioni esposte
che le NTC 2008, al citato Capitolo 10.2 e alla sua voce Validazione di Codici, prevedono la validazione tramite controlli
indipendenti della singola applicazione di un codice di calcolo e non la validazione del codice stesso in senso generale:
“…Nel caso in cui si renda necessaria una validazione indipendente del calcolo strutturale … i calcoli più importanti devono
essere eseguiti nuovamente da soggetto diverso da quello originario mediante programmi di calcolo diversi..”.
Parere CSLLPP – Prima Sezione, Adunanza del 17-9-2013, Prot. 59/2013
______________________________________________________
Per la cronaca, per questo e per altri motivi la Ditta che utilizzava la documentazione
della Università per asserire che il programma era stato “certificato” o “validato” fu sanzionata dalla AGCM per pubblicità
ingannevole.
Ma allora tutto il pletorico dibattito su riviste, articoli, forum e siti in merito alla necessità di imporre la
“certificazione del software”, intesa nel parlar comune come un pezzo di carta che dica che il programma è affidabile,
non ha alcuna base, è totalmente privo di qualsiasi fondamento. Nessuno potrà mai davvero certificare alcun che,
che non sia l’attività svolta. Io certifico di aver svolto queste indagini e certifico che io penso che
tali indagini portino a queste conclusioni, il che è ben diverso. Io non posso certificare un programma, nessuno
può farlo. Io certifico che ho svolto con diligenza questi lavori e che tali lavori mi hanno portato a ritenere con un certo
margine di (mia) incertezza che i risultati siano corretti. Chi mi legge potrà fare sue le mie argomentazioni, oppure rifiutarle,
in perfetta aderenza a quanto De Finetti spiegava in merito al calcolo delle probabilità.
Tutto questo non significa assolutamente che non si devono fare attività di validazione, al contrario: questo libro è
appunto dedicato alla validazione. Semplicemente, quanto detto delimita il senso e il fine di una sana attività di validazione,
e fa piazza pulita dei numerosi qui pro quo che sulla materia vengono involontariamente diffusi. Del resto, lo scopo
di questo lavoro è appunto spiegare un diverso punto di vista, condiviso dalla stragrande maggioranza dei veri addetti ai
lavori, un punto di vista che richiede qualche passo logico in più, facilmente alla portata di tutti quanti siano desiderosi
di farlo.
Lo sviluppo software è una meravigliosa disciplina, ma ben pochi se ne sono occupati per davvero. Quindi a me pare plausibile
che avendo io sviluppato software ininterrottamente per venticinque anni, nello specifico settore della ingegneria strutturale,
io mi adoperi per spiegare con umiltà ma anche con profonda convinzione, il mio motivato punto di vista.
A tutti noi piacerebbe tornare al tempo in cui, da bambini, i nostri genitori ci assicuravano di una certa verità,
alla quale noi credevamo ciecamente. Era bello essere sollevati dal gravoso compito di valutare, di decidere, dall’angoscioso
dubbio che invece, da adulti, ci troviamo spesso dinnanzi. Sarebbe bello poter usare solo i processi di tipo 1, meno faticosi.
Ma questo non è possibile.
E non è neppure possibile che un Ente ci sollevi dal compito di valutare con intelligenza e con serietà se
ciò che abbiamo di fronte deve essere creduto o no. Semmai, se vogliamo, possiamo demandare ad altri tale compito,
ma ben consapevoli che i giudizi dell’ipotetico Ente o Ministero o singolo, per quanto magari molto autorevoli,
non sono altro che giudizi che possono essere più o meno pregnanti, più o meno articolati e credibili.
E anche sbagliati.
da "La Validazione del calcolo strutturale" di Paolo Rugarli, EPC Libri (2014) (Validazione Strutturale)
Riproduzione consentita citando per esteso la fonte
Al seguente link sono disponbili molte schede di validazione a altri documenti e informazioni sul tema:
Ulteriori link utili:
