Il blog di Vincenzo Masotti



I testi


I link

Accomazzi.net

Sito RTSI


Valid XHTML 1.0!

Sar-At 6.1
Powered by Sar-At


Torna alla Home

Il testo di Vincenzo:

Ultimamente mi è capitato che l'elaboratore testi che uso di solito e che non cito per carità, si è chiuso per ben due volte, inaspettatamente, come affermava con un antipatico eufemismo l'antipatica finestra apparsa al posto del documento sul quale stavo lavorando. Che sia una specie di vendetta? Non so. So che ho dovuto cambiare software.
Ora sentite una delle barzellette più vecchie della rete che però continua a girare da un indirizzo di posta elettronica all'altro.

Un pezzo grosso dell'industria del software - immaginate pure chi, e avrete ragione, ma può essere chiunque - un pezzo grosso del software si riempie la bocca di parole come: "Se il settore automobilistico si fosse sviluppato come l'industria informatica, guideremmo automobili da venticinque dollari che fanno cinquecento chilometri con un litro".  La facile replica di un dirigente dell'industria dell'auto fu la seguente: "Sì, e se le auto fossero come i programmi, si bloccherebbero due volte al giorno senza motivo e l'assistenza direbbe che l'unica soluzione è reinstallare il motore".
La battuta riassume uno dei più grandi problemi della tecnologia contemporanea. In un tempo sorprendentemente breve il software, poche decine di anni, è diventato cruciale per quasi ogni aspetto della vita moderna. Dai caveau delle banche ai semafori delle città, dalle reti telefoniche ai lettori dvd, dagli airbag delle automobili ai sistemi di controllo del traffico aereo, il mondo intorno a noi è regolato da linee di codice. Eppure gran parte dei programmi è semplicemente inaffidabile.

Volete qualche dato? Qualche anno fa avevo fatto una ricerchina e avevo appuntato, tra gli altri, Peter Neumann, ricercatore di informatica nel Menlo Park della California, che diceva:  "Man mano che aumenta l'importanza del software saranno più gravi le conseguenze eventuali di un codice scadente". Ed ecco che negli ultimi venti anni a causa di errori di programmazione – cito a memoria da altri programmi che avevo realizzato - è saltato il lancio di un satellite europeo, è stata ritardata di un anno l'apertura del costosissimo aeroporto di Denver, una missione della Nasa su Marte è stata cancellata, quattro soldati sono morti per lo schianto di un elicottero, una nave della marina statunitense ha abbattuto un aereo passeggeri e i sistemi per le chiamate delle ambulanze a Londra si sono bloccati causando la morte di almeno trenta persone. Centinai di metri quadrati di vetri di un grattacelo, sono scoppiati. Mi sembra a Boston.

Oggi, vista la crescente dipendenza dalla rete, direi che stiamo peggio di prima. I rischi sono aumentati, i sistemi di difesa no. Anche perché purtroppo non è esagerato dire che i problemi del software sono unici. Avete mai sentito dire da un ingegnere automobilistico che le macchine di oggi hanno gli stessi difetti di dieci o quindici anni fa? E nessun ingegnere aeronautico sostiene che Boeing o Airbus facciano aerei scadenti. Né gli ingegneri elettronici si lamentano di chip e circuiti. Gli ingegneri del software invece, quelli seri, non fanno che lamentarsi del loro prodotto.
Inoltre, mentre la continua messa a punto è regola normale e abitudinaria per la tecnologia tradizionale...  Voglio dire, gli ingegneri trovano sempre dei punti deboli nei loro progetti e un po' alla volta li correggono cosicché i prodotti migliorano in continuazione… Per il software è tutta un’altra faccenda. Prendiamo Windows XP, il sistema operativo della Microsoft vecchio di qualche anno, ma – a mio parere (non fidatevi del tutto, io sono un macintosiano...) - ancora il migliore tra quelli costruiti da MS. Da un programma come questo, con 45 milioni di linee di codice, ci si aspettava qualche errore. Ma quanti? Secondo uno studio compiuto su ben 13.000 programmi da un ricercatore dell’università di Pennsylvania, Watts Humphrey, i programmatori di professione compiono in media tra i 100 e i 150 errori ogni mille righe di codice. In base a queste stime, Windows XP, con le sue 45 milioni di righe di codice, dovrebbe aver avuto tra i cinque e i sei milioni di errori. Nella maggior parte saranno stati troppo piccoli per provocare delle conseguenze negative, ma alcuni – certamente molte migliaia – hanno causato problemi seri.

Naturalmente la Microsoft ha testato a lungo Windows XP prima di immetterlo sul mercato, ma, secondo gli esperti, in ogni fase di test si scoprono in genere meno della metà dei difetti. Così, se la Microsoft avesse effettuato quattro serie di test – cosa che non è avvenuta, perché si tratta di una procedura lunga e molto costosa - avrebbe scoperto al massimo 15 errori su 16. Sarebbero restati comunque cinque errori ogni mille linee di codice che potrebbe sembrare molto poco, ma che significa che il software avrebbe avuto ancora altri 225mila errori.  Ora va detto che non è che i programmi della Microsoft siano particolarmente difettosi; spesso i critici prendono a esempio i suoi prodotti perché sono i più conosciuti e non perché siano peggiori della media. Il problema evidente è che le tecniche per scrivere programmi non sono riuscite a tenere il passo dell'aumento esplosivo della loro complessità.

Questo a noi utilizzatori non interessa. A noi interesserebbe piuttosto che il software funzioni, tanto è vero che mi sono sempre meravigliato, finora, del fatto che siamo così tolleranti.

Il fatto è che nel mondo vengono distribuiti programmi così pieni di errori che sono una vera vergogna. E questo capita non solo perché i programmatori di professione, in un programma di una certa consistenza, compiono dai cento ai centocinquanta errori ogni mille righe di codice. Ma anche perché è cambiato il modo di lavorare. Quasi sempre – per esempio - manca un piano di programmazione. Le cose stanno così: i programmatori scrivono il codice dei programmi in linguaggi come Java, o C, o C++. Poi dei programmi specializzati chiamati “compilatori” rendono questo codice leggibile dai calcolatori, trasformandolo nelle stringhe di uno e di zeri comprensibili dai computer. I compilatori, normalmente, rifiutano il codice che ha problemi banali e si bloccano emettendo messaggi di errore.  Adesso che i computer sono molto diffusi e sono molto più potenti di anni fa, invece di pianificare meticolosamente il codice, come si faceva allora, i programmatori aspettano i messaggi di errore del compilatore. Se ci sono difetti e il compilatore non li rileva, ecco che il programma può funzionare anche molto male, specialmente se è molto corposo.

Sapendo che un codice è pieno di lacune, gli informatici hanno cercato delle tecniche per prevenire i guasti. La più nota è quella di progettare per componenti, un po’ come si costruiscono le  case con componenti prefabbricati e moduli intercambiabili. Purtroppo, dicono i critici, spesso le componenti sono messe insieme senza nessun disegno centrale, come se un costruttore cercasse di tirar su una casa senza un progetto.  L’esempio più evidente è lo stesso sistema operativo Windows. In una seduta del processo antitrust amricano di qualche anno fa Bill Gates aveva ammesso che il sistema operativo non funzionerebbe se gli utenti eliminassero delle singole componenti come i browser, i file manager o il programma di posta elettronica.

Windows è l’esempio più citato perché è anche il più venduto, ma sappiate che secondo la società di consulenza Standish, anni fa un quarto dei progetti di software commerciale è stato cancellato perché aggiustarlo sarebbe stato troppo oneroso. L’80 per cento dei budget per la costruzione di software impegnativo è – udite udite – dedicato alla correzione degli errori…   Ora succede che gli ingegneri delle società informatiche scelgano talvolta di ignorare i difetti, facendo finta di niente. Allora ci sono un mucchio di recensori, esperti, hacker, o utenti comuni pronti a rivelare i difetti, attraverso i canali dell’Internet. Purtroppo le aziende cercano sempre di più di scoraggiare le discussioni pubbliche e clausole poco visibili di molte licenze per il software vietano in certi casi di pubblicare delle prove comparative.   Per acquistare il popolare McAfee VirusScan, per esempio, i clienti dovevano promettere di non pubblicare recensioni senza il consenso del produttore, una condizione così assurda che lo Stato di New York ha citato in giudizio l’azienda per aver creato un patto “illegale e costrittivo che limita la libertà di parola”. E fortunatamente l’azienda ha perso la causa e ha cambiato atteggiamento.

I nodi verranno al pettine? Cambierà l’atteggiamento dei produttori di software? Vediamo di concludere questo discorso che sta diventando un po’ troppo lungo.

Il fatto più importante è che l’ingegneria del software è molto diversa dall’ingegneria tradizionale. Si sa che se un ponte resiste ad un peso di cinquecento chili, o anche ad un peso di cinquantamila, gli ingegneri possono dedurre che il ponte sopporterà tutti i valori intermedi. Con il software ipotesi del genere non si possono fare. Se inoltre è praticamente impossibile che un’automobile del 2011 sia meno affidabile di un’auto di dieci anni prima, non è raro che invece il software nuovo sia meno efficiente di quello vecchio.
Dicono i produttori del software che questo avviene perché lavorano sotto l’assillo di richieste straordinarie da parte degli utenti, mentre i produttori di automobili fabbricherebbero sempre lo stesso prodotto, una scatola con quattro ruote e un motore a combustione interna, da decenni.

Ora questo sarà anche vero. Ma appare evidente che spesso i programmi sono troppo complicati, e non ho l’impressione che la maggior parte degli utenti sia poi così contenta di questo. Inoltre nell’industria del software non c’è un metodo di indagine definito da applicare sulle prove fallite e non esiste un meccanismo che garantisca la divulgazione delle informazioni. A questo punto le vie d’uscita sono forse due. Una dipende dai produttori ed è quella di sviluppare il nuovo software per componenti. Allo stesso modo nel quale per costruire le case ormai si usano materiali standardizzati, dei moduli, si dovrebbero costruire i grandi programmi di software con elementi modulari intercambiabili ben collaudati. (Qui lo potete ben immaginare, ci saranno problemi di brevetti e di proprietà dei vari moduli con conseguenti liti tra i produttori di software...)

L’altra via, forse più importante, dipende dagli utenti, dai consumatori, che non dovrebbero più accettare, o subire, gli errori più macroscopici, e dovrebbero o evitare di acquistare software notoriamente difettoso, o unirsi per sviluppare grandi cause giudiziarie, costosi procedimenti penali, che obblighino i produttori a scrivere codice a prova di bomba.  Dicono gli stessi scienziati che si occupano del collaudo dei programmi: “o ci sarà una grande vertenza per la responsabilità del prodotto, o il governo dovrà intervenire a regolamentare l’industria. Qualcuno dovrà cedere. Non sarà carino, ma quando avranno una pistola puntata alla testa, le aziende troveranno il modo per migliorare il software”. Sarà vero?

 

 


I commenti dei visitatori:


Caro Vincenzo, bell'articolo. Credo che ci conosciamo. Bardonecchia,\r\nconvegno di relativit, molti anni fa. Cari saluti, Letterio


Letterio Gatto - 01-08-2011

Could you write about Physics so I can pass Scenice class?


KTMboDhaUxjfyBDDi - 29-09-2011

Salve sig. Masotti,\r\nun saluto dall'Italia.\r\nSull'esempio dell'automobile non sono daccordo...e per colpa dei software che ci girano dentro, nelle varie parti, dalla centralina elettronica di controllo e regolazione della combustione, alle tantissime altre funzioni di bordo.\r\nNon raramente accade che auto moderne e di marchi blasonati possano tradire di punto in bianco!\r\nSaluti e a presto.


Francesco - 23-04-2012

@letterio: certo che mi ricordo. Era stato un incontro simpatico. Ne passata di acqua sotto i ponti, eh?


vincenzo - 23-04-2012

@letterio: certo che mi ricordo. Era stato un incontro simpatico. Ne passata di acqua sotto i ponti, eh?


vm - 23-04-2012

@letterio: certo che mi ricordo. Era stato un incontro simpatico. Ne passata di acqua sotto i ponti, eh?


vm - 23-04-2012

@letterio: certo che mi ricordo. Era stato un incontro simpatico. Ne passata di acqua sotto i ponti, eh?


vm - 23-04-2012

oh cielo, gie0 la prima!!!! mi ricordo arcona quando nel tuo blog con le matite colorate ci desti la magnifica notizia: l'INP non sarebbe pif9 stata sola senti, non metterti l'ansia che poi la passi alla PBF. tranquilla, lasciala vivere in serenite0 questo momento magico, che8 la seconda elem e8 gie0 altra cosa. e goditi pure tu questo momento che non ritornere0. la prima e8 la classe pif9 faticosa ma la pif9 bella in assoluto. fidati, ne so qualcosa. baci.


dbnyxVwhO - 27-10-2012

I needed to thank you for this good read!! I certainly enjoyed every little bit of it. I've got you bookmarked to check out new stuff you post ckfakedafdcd


I needed to thank you for this good read!! I certainly enjoyed every little bit of it. I've got you bookmarked to check out new stuff you post ckfakedafdcd - 17-12-2014

If inofrmation were soccer, this would be a goooooal!


CdgbL5tYmGZ - 09-11-2016

If inofrmation were soccer, this would be a goooooal!


CdgbL5tYmGZ - 09-11-2016

Hai qualcosa da dire anche tu? Scrivi un commento