La strana coppia: Software e Normativa

Roberto Spagnuolo - Amministratore Unico Softing srl 13/03/2018 4262

Una opinione sugli effetti di una normativa cogente sullo sviluppo del software e della ricerca italiana nel settore della meccanica computazionale

Sintesi

L’oggetto di questa nota, è l’appiattimento della quasi totalità delle softwarehouse italiane impegnate nel settore della progettazione antisismica, sul solo soddisfacimento dei requisiti di norma (non tutte, ovviamente, e con i doverosi distinguo). Appiattimento cui sono costrette dal sistema normativo cogente. La conseguenza di ciò è una vocazione più “quantitativa” della produzione del software che “qualitativa” (le clausole della norma sono tante ma facili). Ciò porta ad uno scarso credito sia da parte del committente progettista che delle Pubbliche Amministrazioni verso le softwarehouse viste non tanto come detentrici della conoscenza computazionale, ma come semplici gestori di banali procedure “manuali” però “automatizzate”. 

Un prodotto si vende se soddisfa una necessità del cliente.

Se un prodotto soddisfa meglio queste esigenze, il prodotto si vende meglio. Ciò comporta una continua ricerca per migliorare il prodotto al fine di vendere di più. Questa è una legge economica ineludibile del libero mercato ed ha comportato lo sviluppo delle capacità di un prodotto di soddisfare il cliente, in una parola, del progresso tecnico applicato al prodotto commerciale. Si potrebbe aprire un dibattito politico su queste affermazioni, ma qui noi vogliamo essere pragmatici ne non idealisti.

Vediamo ora come – e se – questo criterio si applica al software per il progetto strutturale in regime di normativa cogente. La normativa ha il fine di garantire al cittadino la qualità del prodotto, cioè, in questo caso, di un edificio, ad esempio. Il software può allora essere visto come un prodotto in continua evoluzione per soddisfare questa esigenza secondo la legge suddetta? No, perché il cliente del software non è il cittadino, in questo caso il committente del progettista, ma il progettista stesso. L'esigenza del progettista, se la normativa è cogente, è quello di soddisfare al meglio i requisiti di normativa e quindi il software migliore non è quello che soddisfa al meglio il cittadino e la sua sicurezza, ma quello che soddisfa al meglio il rispetto letterale della norma, esigenza del progettista. La norma quindi è un obiettivo statico che blocca la dinamica dell'evoluzione tesa a conseguire il miglior soddisfacimento delle necessità del cliente, evoluzione messa in atto dalla aspirazione del produttore ad un miglior successo di mercato. La ricerca di chi produce software non è quindi remunerativa perché non aumenta le vendite, visto che l'obiettivo scientifico è definito in modo statico dalla norma. 

Scienza applicata o scienza evolutiva ?

La rivoluzione industriale ha portato dei cambiamenti sociali epocali e la scienza si è “abbassata” a servire la tecnologia. La scienza delle costruzioni, la matematizzazione dell’ingegneria, sta subendo lo stesso tipo di trasformazione, ma poiché non è il cittadino comune a governare il processo, tale processo è più tortuoso e meno limpido. Se non si vuole fare della ingenua ideologia del “tutto gratis”, occorre farsi una ragione che l’industrializzazione (nel caso del software la sua produzione) costa, e pertanto dalla cattedra si scende al mercato. Non si scappa. Occorre farlo con consapevolezza ed eleganza, ma alzare barricate non giova a nessuno. 

Facciamo un esempio. La GBT, la Generalized Beam Theory è una teoria squisitamente computazionale ed esaustiva del comportamento di una trave a pareti sottili (caldamente consigliamo di dare uno sguardo almeno su Wikipedia, ne vale la pena). Per essere implementata richiede degli investimenti perché è una teoria abbastanza complessa, ma di contro è una teoria unificante che evita i problemi che scaturiscono dalla “parcellizzazione” dei metodi. Può una softwarehouse investire in questo metodo per avere successo di mercato e quindi remunerazione dei suoi investimenti? No, perché il progettista deve poter dimostrare di aver ottemperato agli obblighi di normativa e può farlo solo se dimostra di aver seguito il procedimento dettato dalla norma e ciò può farlo solo esponendo i valori dei parametri contemplati dalla normativa. Se impiega un metodo diverso, magari migliore, la dimostrazione del suo ben operare è tutto a suo carico e quindi richiede per lui un maggior investimento in tempo e conoscenza. Quindi un software “migliore” non soddisfa al meglio le esigenze del suo cliente. La norma cogente produce questo controsenso che viola il principio economico generale con il quale abbiamo esordito. 

La coscienza professionale

Solo la coscienza professionale del progettista può portarlo a cercare strumenti migliori per il proprio lavoro (software basati su moderni principi di meccanica computazionale) perché tale qualità non può trasformarla in un fattore di marketing verso il proprio cliente che non è certo preparato a recepire questa qualità. Ne consegue che è solo la minima parte del “mercato” che spinge verso soluzioni software evolute per cui la produzione di software si appiattisce su soluzioni meno sofisticate. 

Del resto che la produzione software italiana sia “normocentrica” lo vedremo in questi giorni in cui le softwarehouse si faranno pubblicità dichiarandosi pronte alla recente revisione della normativa quando le modifiche nel DL sono minime mentre non si conoscono ancora le modifiche che saranno introdotte dalla circolare che saranno ben più invasive. Tutto questo per sottolineare come il “normocentrismo” tenda in tutti gli aspetti del progetto a schiacciare la qualità verso minimi che sarebbero forse anche sufficienti, ma che ostacolano ogni forma di evoluzione sia professionale che dei prodotti software.

L'Italia ha una grande tradizione sia nella ingegneria che nello sviluppo e nell'insegnamento dei metodi della scienza delle costruzioni. Eppure non si assiste ad uno sviluppo all'altezza della tradizione per quanto riguarda i metodi di meccanica computazionale. Ciò è quasi totalmente da attribuire all'effetto frenante del sistema normativo. Il sistema normativo infatti si basa su un assunto: la sfiducia dello Stato che deve garantire i cittadini, nei riguardi del cittadino che ai suoi concittadini offre un servizio. Il cittadino che offre tali servizi, nel nostro caso il progettista, si trova sempre sotto controllo e ciò tende a depauperare il principio di responsabilità individuale a favore del rispetto delle “regole”. Questo è un vizio italiano che vediamo ovunque. Un corso di guida sicura presso gli impianti dell'ACI costa poco rispetto a quanto costa un corso per conseguire la patente di guida, sarebbe utilissimo per far sperimentare al futuro guidatore i suoi limiti e i possibili pericoli, ma si preferisce insegnare le regole di circolazione, si scambia obbedienza con capacità. 

Del resto, siamo nel 1945, Pier Luigi Nervi scrive l’insuperabile e indispensabile “Scienza o arte del costruire?” (Città Studi Edizioni) ed a pagina 142 e segg. (Edizione Città Studi 1997) scrive:

Le norme […] presentano aspetti decisamente negativi e dannosi. In primo luogo perché anziché aggravare le responsabilità del progettista […], le riducono. Infatti qualora questi possano dimostrare di aver ubbidito alle prescrizioni delle norme di legge, cosa quasi sempre non molto difficile da raggiungere, troveranno nelle norme stesse la migliore e più autorevole delle difese.

[…]

Un altro aspetto negativo delle  regolamentazione è dato dalla possibilità che, attraverso pedantesche interpretazioni, fatte più o meno in buona fede, delle relative istruzioni, si favoriscano litigiosità o si ostacolino progressi e nuove applicazioni costruttive.

[…]

Le regole di buona costruzione, come i calcoli di stabilità, come le disposizioni planimetriche, come qualsiasi altro fatto progettistico o costruttivo, sono ribelli a qualsiasi classificaziione o forma di pedantesco inquadramento.

Vi è una resistenza verso la meccanica computazionale ?

Vi è un altro elemento di perplessità, esaminando la normativa con gli occhi di un “meccanico computista”. Le procedure per la verifica degli elementi strutturali sono dettagliatissime, invece sui metodi di analisi non vi è neanche un cenno di attenzione sulla qualità dei metodi. Usare un elemento finito che è formulato in modo da non superare un patch test può portare ad errori nella valutazione delle sollecitazioni talmente elevata da rendere risibile il rigore nella definizione dei valori decimali dei fattori di sicurezza. Perché questo? Perché i metodi di analisi sono materia ormai acquisita dalla meccanica computazionale, il cui controllo sfugge alla normativa, mentre le procedure di verifica degli elementi si ritengono fuori del campo della meccanica computazionale e pertanto ci si ritiene legittimati ed in dovere di definirli. Questo ci induce il sospetto che vi sia una resistenza da parte del sistema amministrativo verso la meccanica computazionale perché gli sottrae il controllo. Questo fenomeno a noi pare abbastanza evidente e genera una sorta di competitività, se non di aperto contrasto, tra informatici e meccanici in quanto la meccanica computazionale è un settore ormai accreditato appartenere all'informatica e se la meccanica accetta questo principio perde potere,e con esso chi lo rappresenta.. Per questo nella normativa troviamo una “parcellizzazione” estrema delle prescrizioni ridotte a semplici formule algebriche. Per questo il “foglio di calcolo” è amato dai progettisti più di strumenti software evoluti. E' sempre un problema di controllo e di potere. Se si accettasse l'entrata della meccanica computazionale nella normativa, quanto potere e quanto controllo passerebbero di mano? 

Questa situazione porta a non voler considerare le specificità informatiche alle quali invece ci si rivolge per ottenere una soluzione. Il software non ha natura materiale ed allora si percepisce come immune dall'errore, peccato che affligge la materia. Ovviamente non è così. Basti pensare alle conseguenze per la vita organica che hanno gli errori “informatici” nel DNA. Il cancro e la morte sono conseguenze di bug, dei difetto del sistema che gestisce le informazioni nell'organismo. Anche il software di Dio, non è immune dai bug, a meno, come crediamo non sia una obsolescenza programmata e ciò ci secca un po'....  

L'errore nel software è possibile come in ogni realizzazione umana, ma tale possibilità di errore cresce con la complessità. Una delle metriche più intuitive della complessità algoritmica è la “complessità ciclomatica” proposta nel 1976 da McCabe. Essa dipende dal numero di “percorsi” possibili tra ingresso ed uscita. Maggiore è il numero di tali percorsi maggiore è il numero di test necessari per validare il software e maggiore la possibilità di errore. Chi scrive ha dimostrato che la propagazione degli effetti dell'errore dipende anch'essa dalla complessità ciclomatica [Roberto Spagnuolo, Evoluzione dei sistemi complessi e regolamentazione, Franco Angeli Editore]. La struttura (cogente, non dimentichiamolo) della normativa ha un approccio classificatorio e ciò implica una complessità ciclomatica sempre elevatissima. Del resto, anche intuitivamente, avere una immagine chiara, immediata delle prescrizioni, ad esempio della normativa sulle costruzioni esistenti, è impossibile. Si possono ricordare a memoria le prescrizioni, ma unirle in una immediata percezione unitaria non è organicamente possibile perché anche la mente umana non è costruita per funzionare in questo modo. 

Chi scrive ha dovuto far redigere per esigenze professionali, si comprende, un diagramma di flusso di tali prescrizioni ed ha calcolato la complessità ciclomatica che è circa 14 mentre McCabe e lo stesso NIST (National Institute of Standard and Technology) consigliano di non superare 10. Chi redige la normativa dovrebbe avere come obiettivo quello di non superare mai una complessità ciclomatica così elevata. Immaginiamo, come corollario di alleggerimento, di essere alla guida di un veicolo e di dover valutare e conformarsi a una decina di prescrizioni contemporaneamente, andiamo fuori strada di certo!  

DIAGRAMMA SPAGNUOLO.jpg

Diagramma di flusso delle procedure del DM08 per le strutture esistenti [cortese concessione Ing. Cristiano Bilello per Softing]

Ma, facendo una analisi politica del problema, a chi gioverebbe un avvicinamento tra meccanica computazionale e normativa? Non alle softwarehouse in quanto le norme sono incongruenti dal punto di vista algoritmico ma facili da implementare in quanto si esprimono con una casistica sterminata che conduce però a semplici formule algebriche. Non è richiesta una gran specializzazione alle softwarehouse per assolvere a questa necessità. Cioè, il problema dello sviluppo del software le norme lo rendono più quantitativo che qualitativo. Dovrebbe essere invece interesse della pubblica amministrazione per dare maggiori certezze ai cittadini e consentire un ingresso realmente “moderno” dell'informatica per il progetto antisismico. Ma la pubblica amministrazione è un concetto, chi decide sono invece uomini e uomini non disposti a cedere un loro più che onorevole atteggiamento e una loro tradizione culturale per un ambito culturale innovativo ma che non gli appartiene. E' comprensibile.

Quando chi scrive era presidente dell'AIST, Associazione Italiana Software Tecnico, scrisse al Presidente Sessa e al ministro Delrio suggerendo, più che chiedendo, che l'unica associazione di softwarehouse fosse invitata a cooperare sulla stesura della revisione delle norme tecniche. Si trattava di suggerire delle precisazioni su punti che non fossero algoritmicamente definibili con chiarezza. Non ha ottenuto, chi scrive, non solo l'invito, ma neanche una risposta. Non abbiamo altre ipotesi a giustificare questo comportamento se non una evidente sfiducia verso i produttori di software che, ad avviso sempre di chi scrive, nasce dalla volontà di chi tradizionalmente detiene il potere e la custodia di una certa tradizionale conoscenza verso chi vorrebbe e potrebbe proporre una diversa visione di tale cultura e tradizione.