Millenium Bug

Introduzione ¹

La misura del tempo è sempre stato per l’umanità un problema complesso. Il tempo di rivoluzione della terra intorno al sole non corrisponde ad un numero esatto di giorni, i cicli mensili della luna e il ciclo annuale del sole non sono esattamente uguali e coincidono solo ogni 19 anni, pertanto i calendari hanno bisogno di periodici aggiustamenti per essere sincronizzati con l’anno solare.

L’orologio atomico ² ed il sistema di coordinazione universale del tempo (UTC Coordinated Universal Time) ³ mantenuto dall’International Time Bureau ⁴ hanno reso il sistema di misurazione del tempo il più accurato di tutti i sistemi di misurazione conosciuti dalla specie umana (un secondo ogni milione di anni) ma i calcoli relativi alle date continuano ad essere problematici anche per i sistemi elettronici.

Con l’avvento dei computer i problemi di data e di calendario hanno improvvisamente assunto nuova rilevanza per le numerose ed importanti attività umane svolte con computer: errori di data possono causare gravi danni e conseguenze incalcolabili.

Sfortunatamente le potenzialità di velocità e prestazioni dei computer e del software non furono pienamente sviluppate fin dalle origini dell’era informatica e per motivi di risparmio, quali gli elevati costi delle memorie ⁵ venne riservato uno spazio insufficiente per la completa identificazione della data. I due metodi impiegati: il formato convenzionale di rappresentazione delle date (del tipo giorno-mese-anno) e l’accumulo progressivo del numero di secondi da un punto iniziale arbitrario sono stati adeguati sino ad oggi, ma non lo sono più per il prossimo futuro. Per la ridotta disponibilità di memoria, il campo a quattro cifre degli anni fu ridotto a due e l’accumulazione dei secondi limitata a quattro byte così il primo sistema entrerà in crisi entro la fine del corrente anno 1999, il secondo entro il 18 gennaio del 2038 ⁶.

Una ulteriore complicazione è dovuta al modo di rappresentazione a stampa delle date che è diverso da paese a paese: negli USA il formato è mese-giorno-anno, mentre in Europa è giorno-mese-anno, sempre con l’anno a due cifre.

Per facilitare gli scambi l’International Organization of Standard ⁷ ha fissato uno formato, sostenuto dall’ANSI (American National Standard Institute) ⁸ e dal NIST (National Institute of Standard e Technology) ⁹ del tipo anno-mese-giorno con l’anno a quattro cifre. È il ben noto ISO standard 8601:1988 ¹⁰ che tuttavia non è ancora il formato più comunemente usato ¹¹ e anch’esso risente di una comune debolezza dettata dallo sforzo inconscio di risparmio.

1. Il problema dell’anno 2000

Chi lavora quotidianamente con il progetto, la costruzione e il funzionamento dei computer è abituato continuamente a dover risolvere problemi nuovi e inattesi. Il problema nel cosiddetto Millennium Bug è così semplice da apparire talmente banale che chiunque è in grado di comprenderne la natura ed escogitare metodi per risoluzione ¹². Ancora più semplice è predisporre delle verifiche: basta spostare in avanti le date, inserire dei dati e vedere i risultati.

Eppure oltre l’80% dei responsabili Edp delle aziende dichiara che il problema non solo non è risolto, ma che in oltre il 50% dei casi non si arriverà in tempo nonostante la disponibilità di strumenti tecnici specifici per analizzare e risolvere il problema e di consulenti esperti. Tutto ciò non basta, non c’è abbastanza tempo. Infatti non basta scovare tutte le date e convertirle, occorre modificare le maschere di immissione dati, le colonne di output a video e a stampa e quanto a ciò correlato.

Il Millennium Bug, o Problema dell’Anno 2000 come è conosciuto, si riferisce all’incapacità di taluni sistemi elettronici di lavorare e gestire correttamente date posteriori all’anno 2000, ma molti dei problemi connessi al cambio di data verranno alla luce (ed alcuni hanno già fatto la loro apparizione) molto prima dell’inizio del nuovo millennio ¹³.

La serietà del problema non riguarda tanto il settore dell Information Technology ma piuttosto quello dell’industria, del commercio, dei servizi sociali e delle istituzioni, persino - paradossalmente - di chi non usa il computer. Un’organizzazione incapace di gestire efficacemente la produzione, gli ordini, le consegne, i pagamenti e i propri servizi nei tempi e nei modi necessari, subisce un grave danno, non solo economico, che poi ricade sulla società civile. Il cambio di millennio è un fatto tecnico con risvolti operativi che comportano un rischio per il business.

Il problema dell’Anno 2000 affonda le sue radici negli anni ‘60 quando i computer erano poco diffusi, le memorie erano assai limitate e costose e i programmatori dovevano confrontarsi con le ridotte risorse disponibili. La soluzione più ovvia per rappresentare la data (che nell’elaborazione dati aveva minore rilevanza che non oggi) fu, appunto, quella di usare solo due cifre per l’anno anziché quattro ¹⁴. Ne segue che al cambio di secolo, i computer così programmati potranno non essere in grado di interpretare correttamente l’anno 2000 ¹⁵. Il problema è grave specialmente per quelle applicazioni strettamente connesse con la precisione della data; il problema è globale perché riguarda potenzialmente ogni sistema basato su computer di ogni paese, cioè interessa tutta l’informatica e tutta l’azienda; infine esso è privo di una soluzione universale.

Il motivo di fondo, tanto elementare quanto incompreso fino ad ora, è che la data è presente nei processi di elaborazione dei sistemi informatici come una classe di informazioni molto più diffusa di quanto non si possa immaginare e che essa viene trattata alla stessa stregua di tutti gli altri tipi di informazione: le date si confrontano, si ordinano, sono operandi aritmetici, sono comunemente presenti nei codici identificativi dei prodotti, sono parametri di input/output. Pertanto la rappresentazione abbreviata dell’anno con le sole ultime due cifre non consente di eseguire correttamente operazioni di ordinamento, confronto e calcolo di intervalli temporali.

La risoluzione di questo problema è poi complicata da una serie di circostanze: la mancanza di conoscenza esatta dei punti di intervento per le intricate interazioni logiche tra dati e istruzioni, l’eterogeneità dei sistemi, la quantità ingente di interventi, la necessità, dopo gli interventi, di sottoporre l’intero sistema a vari livelli di test, le diverse implicazioni organizzative ed economiche connesse a tali operazioni.

Inoltre nel problema dell’anno 2000 sono coinvolti diversi livelli tecnologici, quali i sistemi informativi tradizionali basati su mainframe e terminali, tutti i personal computer così eterogenei per l’hardware, il software di base e applicativo, per le diverse finalità di utilizzo, l’elevato numero, la varia collocazione fisica e configurazione. Ad essi vanno aggiunti i cosiddetti sistemi embedded ¹⁶ (o embedded technology) cioè quella sterminata quantità di microprocessori presenti nella strumentazione tecnica, nell’elettronica di consumo ed in ogni apparecchio civile o industriale (elettromedicali, sistemi di controllo di processo e di produzione, robot, elettrodomestici, automobili, ascensori, distributori automatici, satelliti, centralini telefonici, fax, impianti antifurto e così via). Anch’essi sono dei veri e propri computer che eseguono specifici programmi dei quali, in molti casi, è praticamente impossibile sapere se e come facciano uso di parametri, collegati alla data, che possano risentire in maniera anomala, nello svolgimento dei loro processi, del cambio di secolo ¹⁷.

Stime effettuate dagli analisti individuano una quantità di tali sistemi compresa tra 25 e 40 miliardi, i laboratori di PcWeek hanno riscontrato errori sul 5% dei casi, ma i sistemi embedded sono nella quasi totalità dei casi hard-coded ¹⁸, precludendo la possibilità di un intervento diretto.

Un aspetto non molto evidenziato, ma di importanza strategica, è che nella società odierna sempre più coinvolta nel processo di globalizzazione, il problema anno 2000 non riguarda isolatamente chi utilizza sistemi informativi. L’interconnessione tra aziende esige un continuo e reciproco scambio di dati (effettuato per via telematica, o con mezzi più tradizionali come dischi, nastri) che richiede una comune modalità di gestione delle date e una coerente risoluzione del problema. Il problema anno 2000 è sistemico: un computer che diffonde dati errati o non coerenti può indurre anomalie in altri computer, seppur correttamente configurati, ad esso connessi con effetto "domino" a meno di isolare ogni computer "non 2000 compatibile", il che non è possibile. Il problema ha grande rilevanza a livello economico e sociale prima ancora di essere un problema tecnico, perché nessuno vive isolato dal resto del mondo e tutti noi abbiamo a che fare continuamente con strutture fortemente dipendenti dai computer. Paradossalmente, anche chi non utilizza direttamente i computer potrebbe essere coinvolto pesantemente in questo problema.

Il problema dell’Anno 2000 non è solo una questione tecnica, ma un problema economico di rilevanza internazionale e di potenziale gravissimo impatto a livello mondiale. Il cambio di data all’anno 2000 presenta un concreto rischio di recessione economica di proporzioni pericolose, per le potenziali anomalie o interruzioni nei sistemi di pagamento, di capitalizzazione, di calcolo finanziario, insomma il tessuto sociale ed economico a livello mondiale è ormai tutto computer-dipendente.

2. Sistemi Critici

I malfunzionamenti dei sistemi informativi relativi all’anno 2000 possono provocare disservizi nei cosiddetti sistemi critici che regolano la società civile. Essi sono: il sistema bancario e finanziario, le assicurazioni, i trasporti, l’energia, i servizi postali, i servizi di telecomunicazioni, la diffusione dell’informazione radio e televisiva, la sanità, la distribuzione delle merci, i sistemi automatici di produzione, i sistemi di controllo, la pubblica amministrazione. Secondo uno studio del governo inglese, i sistemi critici che regolano il funzionamento di un paese industrializzato, sono a loro volta costituiti da circa 60 processi di lavoro critici singoli tra loro interconnessi: tra questi alcuni sono essenziali perché condizionano tutti gli altri e ad essi va dedicato il massimo sforzo di adeguamento. Essi sono: l’approvvigionamento, la fornitura e distribuzione dell’elettricità (condizionano altri 56 processi), le telecomunicazioni (condizionano altri 48 processi), l’approvvigionamento e distribuzione di carburanti (condizionano altri 45 processi critici), la fornitura dei servizi e delle infrastrutture autostradali (condiziona 43 ulteriori processi critici), il sistema dei pagamenti e i mercati finanziari (condizionano 31 ulteriori processi critici), la fornitura di acqua potabile o per uso industriale (condiziona altri 26 processi critici).

Le aziende devono anche predisporre un piano di emergenza (contingency plain) teso ad assicurare comunque (in caso non si riesca a conseguire le necessarie conformità nei tempi stabiliti) la continuità di esercizio, cioè delle operazioni fondamentali alla sopravvivenza e allo sviluppo. Tale piano di emergenza si compone di più fasi: elaborazione del progetto teso ad assicurare la continuità delle operazioni (fase di inizializzazione); analisi dell’impatto sul servizio e sul business dei malfunzionamenti o del blocco totale dei sistemi critici relativi ai processi fondamentali, con analisi del rischio; pianificazione delle procedure di emergenza con i modi di sviluppo concreto, con le responsabilità di attivazione; verifiche e collaudi della strategia definita nella prima fase, sviluppo delle procedure di emergenza e dei piani di ripristino che si devono attuare in caso di disastro.

3. Implicazioni di Ordine Legale

Un problema tecnico come quello dell’anno 2000 presenta anche notevoli implicazioni di ordine legale non appena danneggia l’interesse degli azionisti di una società o mette a repentaglio la sicurezza delle persone. Potranno insorgere cause per danni intentate dalle aziende contro i propri dirigenti, che non hanno saputo affrontare (e risolvere) tempestivamente il problema; basti pensare al software di controllo della produzione, al software di controllo dei processi che possono essere interrotti aumentando i costi e riducendo i profitti; ai sistemi di pagamento e fatturazione che danneggiano i clienti e bloccano il flusso di cassa ¹⁹ (cash flow); ai sistemi controllo delle strumentazioni mediche ²⁰, degli aerei, a servizi essenziali come centrali elettriche e sistemi telefonici con potenziali a persone. Dato che tutta l’attività economica dipende dall’elettricità e dal telefono questa è chiaramente tra le più importanti aree a rischio La probabilità stimata che ciò accada è ben del 50%, mentre c’è una probabilità dell’85% che applicazioni non trattate possano causare abbastanza danni da provocare cause legali ²¹.

4. Le Indagini di Settore

Le recenti indagini e rilevazioni effettuate da università e società di ricerche di mercato evidenziano una situazione piuttosto seria. Secondo tali statistiche ²² (http://www.mediamente.rai.it/home/tv2/mm9899/settimanale/990115/s1_15.htm), un terzo delle aziende mondiali non ha neppure iniziato a prendere in considerazione il problema del Millennium Bug ed il nostro paese, al confronto dei partner europei risulta tra i più arretrati. La maggior parte delle aziende italiane sono a rischio, anche se utilizzano applicativi acquistati da terzi. Una attenta valutazione del rischio e degli interventi da effettuare non è affatto un esercizio facile e sono molto scarse e quindi costose le risorse tecniche capaci di intervenire. Per il ritardo accumulato, tutto ciò è inevitabilmente destinato a peggiorare fortemente nel tempo; occorrerebbe intervenire pesantemente, con priorità assoluta, e con notevole dispendio di mezzi: tutti aspetti questi che, purtroppo, sono tuttora sottovalutati e disattesi.

Secondo Meta Group il costo dell’anno 2000 per il settore pubblico e privato ammonta per l’Italia a 34 miliardi di dollari (cioè 58.000 miliardi di lire); una considerazione abbastanza diffusa e deleteria per non intraprendere nessuna seria azione sull’anno 2000 consiste nel fatto che molti dirigenti pensano che i costi di adeguamento all’anno 2000 saranno maggiori rispetto ai danni potenziali che il problema causerà alle loro aziende.

5. L’itinerario di Conversione e i metodi di Soluzione

L’attività di conversione al 2000 presuppone un processo di lavoro ben strutturato e controllato; ogni organizzazione deve intraprendere una serie di fasi: 1) inventory assessment, cioè la creazione della consapevolezza e l’inventario di tutti gli elaboratori, di tutto il software, di tutti i dispositivi con microprocessori incorporati: questa fase occupa circa il 10% del tempo e il 5% dei costi, può essere automatizzata solo per l’8% ²³. 2) Valutazione economica, tecnica e di rischio, scelte fondamentali e creazione dell’ambiente di conversione: revisione di tutti i computer e dei sistemi di rete per verificarne la conformità ed effettuare tutte le sostituzioni necessarie, verifica di tutti i sistemi operativi, dei linguaggi di programmazione, dei database, del software di comunicazione e delle utilities, consultando i relativi fornitori ed effettuando tutti i necessari aggiornamenti ²⁴. Questa fase richiede circa il 36% del tempo e il 30% dei costi, gode di un livello massimo di automazione del 60%. 3) Sviluppo del piano di intervento ed implementazione, che deve interessare anche Pc, sistemi embedded e supply chain, cioè la rete di approvvigionamento dove informazioni, ordini, fatture viaggiano sempre più spesso su supporti informatici o reti telematiche. Per tutti i programmi applicativi facenti riferimento ad una gestione non corretta della data, occorre risalire se possibile al fornitore ²⁵ o al programmatore che ne ha curato lo sviluppo. Nella impossibilità a ciò si può ricorrere a strumenti software di valutazione e di conversione che possano automatizzare in parte il lavoro, per i quali è comunque richiesto il supporto di personale tecnico specializzato con spese non indifferenti o alla soluzione estrema di sostituire i prodotti con altri alternativi valutando attentamente i tempi ²⁶ necessari per la riconversione e per la formazione del personale. Questa fase occupa il 10% del tempo il 30% dei costi e può godere al massimo di un livello di automazione del 50%. 4) Testing, cioè verifica con test singoli e globali della convalida delle applicazioni rese conformi all’anno 2000. Richiede circa il 39% del tempo, il 30% dei costi e può godere di un livello massimo di automazione del 40%. 5) Istallazione e messa in esercizio del sistema informativo così reso 2000 compatibile. Occupa circa il 5% del tempo, il 5% dei costi e può godere di un livello massimo di automazione del 20%.

Lo stesso discorso vale per i rapporti con clienti e distribuzione. Perché il business di un’azienda non subisca pesanti contraccolpi dopo il 31 dicembre 1999, insomma, non basta che il proprio sistema informatico sia Y2K compliant, occorre che lo siano anche quelli dei partner, dei fornitori di servizi, della pubblica amministrazione e di tutti quegli altri enti con cui si ha a che fare.

Non esiste poi solo un problema di Y2K compliance, ma esso genera anche un problema di standard, perché esistono diverse metodologie di conversione all’anno 2000 ²⁷. È chiaro che tutto ciò coinvolge due aspetti ostili, il tempo ed il costo.

6. La Fase di Testing

Superate queste difficoltà, occorre poi procedere, come si è detto, alla pianificazione delle attività di test ²⁸ che vanno a coesistere con le attività informatiche correnti e possono richiedere esigenze di capacità elaborativa aggiuntiva. Questi test vanno articolati in maniera assai attenta, perché la correzione del codice in chiave anno 2000 introdurrà errori in altre parti delle applicazioni ²⁹.

Pertanto occorre un test di regressione per verificare che il sistema informatico così aggiornato abbia almeno lo stesso livello ³⁰ di funzionalità preesistente (il che si ottiene posizionando la data del sistema al valore attuale con transazioni con date normali). Il test successivo si effettua ancora con data al valore attuale ma con transazioni oltre il 1-1-2000, quindi si passa al test della transizione 1999-2000, test particolarmente delicato perché il cambiamento della data di un sistema informativo centrale può avere conseguenze disastrose se effettuato in modo errato; quindi backup di tutti i dati, conoscenza approfondita del sistema operativo e delle applicazioni. Poi il test di operazioni con data nel 2000 e transazioni antecedenti e successive. Ogni test va effettuato per operazioni giornaliere, chiusure mensili, trimestrali etc. Infine occorre il test dell’anno 2000 come bisestile.

Come è evidente, sono test che richiedono molto tempo e la disponibilità degli apparati normalmente usati per le operazioni correnti, quindi sono da compiersi per lo più fuori del comune orario di lavoro; in molti casi richiedono la presenza degli utenti finali, i soli a conoscere bene come funzionano le procedure e in grado di giudicare e definire eventuali errori e modifiche da apportare.

Nel caso dei Personal Computer, la enorme eterogeneità dei sistemi rende più confusa la situazione. Il primo test da effettuarsi riguarda la funzionalità del BIOS e dell’RTC, (vedi app. A) poi si deve passare al test del sistema operativo e soprattutto delle applicazioni. Nel caso del sistema operativo più diffuso, Windows 95 (o 98). la stessa Microsoft riferisce di piccole imperfezioni ³¹ che difficilmente possono rappresentare un problema funzionale per gli utenti e che sono in via di risoluzione con apposite patch software; ma la messa a punto della suite Office richiede l’istallazione di patch per Word, Excel e Access, con circa un’ora di lavoro che moltiplicata, ad esempio, per 10.000 PC richiede circa 6 anni-uomo. Quindi la verifica sia degli applicativi di Office sia di Windows 98 ³² sta rappresentando per diverse aziende un costo crescente finora sottovalutato, mentre emergono nuovi problemi potenzialmente dannosi anche nei controlli di compatibilità su Windows NT 4.0 ³³.

Certamente il settore "embedded" è quello più enigmatico, tanto da poter essere estremamente grave per alcune organizzazioni e del tutto trascurabile per altre. Nel 1997 sono stati venduti oltre 12 miliardi di microprocessori (più del doppio dell’anno precedente) utilizzati praticamente ovunque: dagli orologi ai sistemi di controllo dei processi ad alta tecnologia. Qualsiasi componente di un dispositivo che ha a che fare con la data (cioè mantiene una data o dipende dalla data per compiere delle operazioni) è soggetto al rischio dell’anno 2000. Tuttavia se la programmazione del microprocessore è stata eseguita correttamente il problema non sussiste, ed è qui l’aspetto più inquietante: non si sa. L’utilizzatore, e spesso anche il produttore che ha assemblato l’apparecchio, non sa niente di ciò: la programmazione è completamente invisibile all’utilizzatore. Per avere informazioni al riguardo non resta che risalire al fornitore originario, operazione assai difficile, oppure eseguire dei complessi test, lavoro altrettanto complesso e costoso.

Come si è esposto, il problema dell’anno 2000 è di natura pervasiva; esso influenza la maggior parte delle organizzazioni che sono obbligate ad effettuare modifiche ai loro sistemi o ai loro processi; queste modifiche, a loro volta, potranno influenzare i partner commerciali, come i clienti e i fornitori e così via. Quindi un aspetto che va curato con particolare attenzione è quello relativo allo scambio di dati che, effettuato attraverso le reti telematiche o con il trasporto fisico di supporti comporta la convergenza di diversi algoritmi (una comune definizione del formato delle date rese conformi all’anno 2000, l’utilizzo di un comune sistema di codifica e conversione, la sincronizzazione temporale del passaggio ai nuovi standard, la verifica della funzionalità delle nuove modalità operative). Occorre così verificare con i partner commerciali il grado di compatibilità all’anno 2000 e la coerenza della transizione verso la conformità dei sistemi per consentire uno scambio di dati senza interruzioni, perché anche utilizzando computer e programmi anno 2000 compatibili è possibile introdurre errori con un trattamento ³⁴ non coerente delle date come numeri, in tal caso ogni documento prodotto (fogli di calcolo, database contenenti date etc.) deve essere verificato.

IL NETWORK YEAR 2000

La maggior parte delle preoccupazioni sugli effetti del cambio di millennio sono concentrate sull’invecchiamento delle applicazioni (scritte principalmente in Cobol) mentre si è prestata poca attenzione ai problemi delle reti.

Il N2K (Network Year 2000) riguarda tutti i dispositivi di rete, quali hub, switch, router, server e Pc che interpretano codici correlati a informazioni sulla data. Questi utilizzano normalmente le informazioni sulla data contenuti negli agenti di gestione e monitoraggio istallati al loro interno. Le applicazioni di gestione utilizzano le stesse informazioni per effettuare le analisi delle prestazioni delle reti e stabilire le correlazioni tra gli eventi. Attraverso hub e router queste informazioni vengono elaborate e registrate in centinaia di dispositivi interconnessi. Tutti i dispositivi possono essere interessati dal N2K, dai desktop alle dorsali di rete. Router e switch sono dipendenti dai sistemi operativi, come i Pc e i Server i cui Bios possono presentare problemi di compatibilità. Secondo Bell Atlantic Network Integration, uno dei maggiori system integrator mondiali, più di 800 tipi di dispositivi di rete sono vulnerabili e presenteranno problemi di performance o errori dovuti al millennium bug (da test effettuati i bridge token-ring cessavano completamente di inoltrare il traffico). Un’indagine effettuata da Cap Gemini America nell’aprile 1998 su 128 società Usa rivelava che le aziende le cui reti presentavano problemi relativi all’anno 2000 erano cresciute dal 7% (dic-97) al 37% (marzo 98) mentre Gartner Group fornisce una percentuale tra il 40 e il 50% a livello mondiale.

Lo scenario previsto dagli analisti non è quello di un completo shutdown delle reti ma piuttosto una serie di inconvenienti che causeranno comunque dei fermi delle reti: firewall negheranno l’accesso, sistemi di management forniranno dati errati, sistemi di posta elettronica subiranno inconvenienti ³⁵.

I problemi maggiori nelle reti sono dovuti alla loro complessità, essendo molti network costituiti da dispositivi e piattaforme misti.

ALCUNI CONTRIBUTI SULL’ARGOMENTO 

PETER DE JAGER

Consulente informatico canadese, fu il primo, nel 1993 a suonare l’allarme sul problema anno 2000. L’Ufficio americano del bilancio ha previsto per la revisione generale dei computer oltre 2.300 milioni di dollari, la Gartner Group, il più importante consulente al mondo per l’informatica ha stimato la spesa complessiva tra 1000 e 2000 miliardi di dollari, la banca americana Morgan, abbassa la cifra a "soli" 200 miliardi di dollari e altri la alzano a 1000 miliardi per le cause legali e i contenziosi giudiziari. In Europa alcune stime sono di 300.000 miliardi di lire di cui 30.000 in l’Italia per la revisione dei programmi delle aziende italiane. 

INDAGINE ELEUSI-HAL - Marzo 1998

Un’indagine ³⁶ sul Millennium Bomb condotta nel marzo 1998 dal Centro Eleusi (il centro ricerche dell’Università Bocconi di Milano) per conto della software house milanese HAL ³⁷, su un campione di 350 medie imprese italiane (99-499 addetti), rappresentativo di un universo di oltre 7300 realtà private emerse che quasi tutte (94,3%) conoscevano il problema anche se tardavano ad affrontarlo, ma un restante 5% (cioè ben 400 imprese) dichiarava di non saperne nulla. Inoltre, il 60% di queste aziende si dichiarava ottimista e fiducioso nel fatto che, o con l’intervento dei fornitori o con un intervento governativo (rottamazione del software non 2000 compatibile in cambio di software 2000 ready), la situazione si sarebbe risolta senza sforzi, mentre il restante 40% non aveva ancora pensato a nulla.

INCONTRO ANNO 2000 ED EURO 

- MARZO 1998

In un incontro su "Il conflitto tra l’Anno 2000 ed euro" ³⁸ ebbe come partecipante Capers Jones ³⁹ cui si debbono i più avanzati studi sulle metriche del software. Lo studioso nordamericano dichiarò che oltre il 55% delle applicazioni in produzione sarebbero state coinvolte nel problema Anno 2000 ed oltre il 15% dalla conversione all’Euro e che il 70% dei softwaristi si sarebbe trovato a dover lavorare u uno di tali problemi.

Egli usò termini come corsa al disastro e definì una delle più imprudenti e rischiose decisioni della Comunità Europea quella di pianificare il completamento della conversione delle monete nazionali in un’unica moneta europea senza riguardo al fatto che i problemi della conversione in euro e quelli relativi all’anno 2000 sarebbero stati in diretta competizione tra loro, data la limitata disponibilità di risorse da dedicare allo sviluppo del software. Una politica molto più accorta sarebbe stata quella di rimandare la conversione della moneta unica al termine del lavoro per l’anno 2000, pianificandola almeno per il 2003.

Il risultato più probabile di tale sovrapposizione (tra conversione in euro e soluzione del problema anno 2000), disse Capers Jones, che sarebbe stato che nel 1998 i Paesi dell’Europa occidentale avrebbero dedicato tutto il loro impegno al problema Euro e solo nel 1999 avrebbero cominciato a presagire il reale rischio legato all’anno 2000 varando in tutta fretta a piani di emergenza ⁴⁰. Ma non essendoci in Europa le sufficienti risorse per risolvere contemporaneamente i due problemi, egli previde che il 65% delle applicazioni informatiche non avrebbero raggiunto in tempo la conformità anno 2000.

Certamente mancare gli obiettivi di conversione all’Euro avrebbe creato notevoli problemi al mondo politico e finanziario, ma comunque sarebbero stati problemi minori rispetto a quelli che potrebbe causare l’Anno 2000 nei sistemi informativi europei.

La conversione all’Euro si può considerare un tipo di manutenzione evolutiva, quella all’anno 2000 una manutenzione correttiva. L’Euro è un problema di business con implicazioni tecniche, l’anno 2000 è un problema tecnico con risvolti di business.

Una valutazione dell’ordine di grandezza dei tempi e dei costi necessari per gli interventi anno 2000, ad esempio, usando il metodo dell’espansione del campo data, si può ottenere elevando alla potenza dello 0.3 il portfolio in function point ⁴¹ (100.000 function point danno circa 32 mesi). In Italia il software istallato ha una dimensione di circa 290 milioni di function point (circa un sesto del totale dei 15 paesi dell’unione europea) ⁴².

Considerando un costo orario del personale di 50 dollari, il costo per function point per le applicazioni scritte in Cobol è di 28 dollari per il Visual Basic 30 dollari, C, Pascal, Fortran etc, 35-40 dollari, assembler 80 dollari.

Per una piccola azienda con un staff dedicato al software di 5 persone e un portfolio di 6.000 function point occorre prevedere un impegno di 23 mesi con un costo totale di circa 200.000 dollari (oltre 3 miliardi di lire), ossia circa 33 dollari per function point. Questo rapporto rimane valido anche per le aziende con uno staff di 50 persone ed un portfolio di 50.000 function point. Il costo aumenta a 37 dollari per function point già per le aziende con 100 persone occupate nel software e un portfolio di 95.000 function point. Per le grandi aziende che hanno da 3 a 15 sedi, da 1000 a 20000 persone che si occupano del software ed un portfolio in function point da 900.000 a 18.000.000 il costo sale a 40 dollari per function point.

INDAGINE ELEUSI-HAL - Novembre 1998

Nel novembre 1998 un secondo studio "Osservatorio 2000" condotto dal centro Eleusi dell’Università Bocconi e dalla software house HAL sullo stato di salute delle medie imprese italiane rispetto al Millennium Bug riferisce che sulle 7300 aziende (tutta la media impresa, escluso il settore caccia e pesca e quello dell’industria estrattiva) che hanno tra 99 e 499 addetti il 18,7% saranno "2000 non compliant" allo scoccare del nuovo millennio.

Da marzo a novembre dunque le aziende che hanno affrontato il problema sono passate dall’80 al 96,4%; di esse il 44,1% dichiara di essere a posto, mentre ben 262 aziende non hanno ancora affrontato il problema e di queste l’11,3% (cioè 30 aziende) ha dichiarato che non intende occuparsene.

Per quanto riguarda i tempi, l’82% delle aziende ha un ritardo di 6 mesi, il 16,5% di 12 mesi e la maggior parte delle aziende ritiene che entro il marzo del 1999 dovrà già inserire nei propri computer date successive al 31 dicembre 1999.

LE INIZIATIVE GOVERNATIVE ESTERE

Il senato americano ha istituito da tempo un apposito comitato, il Primo Ministro olandese Wim Kok invitò il cancelliere tedesco Helmut Kohl a prendere concrete iniziative per evitare il deflagrare della bomba software. Il governo olandese con quello svedese e inglese sono stati i più attivi nel sostenere iniziative pubbliche e private per affrontare il problema anno 2000 ⁴³. Il Primo Ministro inglese Tony Blair è stato uno dei più sensibili al problema anno 2000; egli aveva reclutato oltre 20.000 tecnici (millenniun bug busters) stanziando l’equivalente di oltre 200 miliardi di lire. Lo stesso Primo Ministro britannico il 15 maggio 1998 a Birminghan ha voluto un summit del G-7 (Giappone, Stati Uniti, Canada, Gran Bretagna, Germania, Francia, Italia cui si è aggiunta la Russia) per definire un approccio globale al problema ⁴⁴. La società di trasporti DHL Worldwide Express ha investito (già ai primi del 1998) 25 milioni di dollari per adeguare i suoi sistemi informativi alla scadenza dell’anno 2000 (oltre 20 milioni di linee di codice, 1000 server e 25.000 utenti collegati alla rete) ⁴⁵.

Il presidente Clinton il 4 febbraio 1999 ha firmato un ordine esecutivo rivolto alle agenzie Federali, al Consiglio sulla conversione all’anno 2000 (Year 2000 Conversion Council) ai capi agenzia e a tutti i responsabili di settore, in cui si legge che il controllo del problema Y2K richiede un forte sforzo tecnologico e manageriale e pertanto ognuno ha la responsabilità nel proprio ambito che il problema Y2K abbia la massima priorità e che sia condotto alla risoluzione con rendiconti almeno trimestrali direttamente al presidente.

LE INIZIATIVE GOVERNATIVE ITALIANE

Il gruppo di lavoro 2000 la cui presidenza è affidata all’Aipa (che sottopose dal 1996 all’attenzione delle amministrazioni la problematica connessa all’anno 2000) ha calcolato in circa 108 miliardi la somma che lo Stato avrebbe dovuto sostenere per la revisione dei programmi di 21 amministrazioni centrali per un totale di 205 milioni di LOC (linee di codice) pari al 75% del patrimonio della Pubblica Amministrazione stimato in circa 273 milioni di LOC, ( consuntivo 1996).

La commissione governativa istituita il 6 agosto 1998 da Romano Prodi non è mai entrata in azione e si è riunita solo una volta nel settembre successivo poi è stata travolta dalla crisi di governo.

Il 14 gennaio 1999 il sottosegretario alla Presidenza del Consiglio Franco Bassanini ha presentato il "Comitato anno 2000" presso palazzo Chigi (e presieduto dall'ex sottosegretario alla Funzione Pubblica nel governo Prodi, Ernesto Bettinelli), ammettendo che "l'Italia è in grave ritardo ed è necessario accelerare i tempi" ed ha annunciato una conferenza nazionale per maggio ⁴⁶. Tra i compiti del Comitato si legge: "valutare gli effetti connessi al mancato adeguatamente dei sistemi informatici e delle apparecchiature... monitorare le realizzazioni e delle soluzioni tecniche disponibili... prevenire gli effetti negativi sull'Italia e delle possibili ripercussioni nei rapporti con gli altri Stati... evitare gli eccessivi aggravi finanziari sulle amministrazioni pubbliche e sulle imprese". Valutare, monitorare, prevenire, evitare, ma non decidere, ordinare o risolvere: purtroppo il Comitato non sembra essere una task force o un'unità di crisi, come in altri Paesi e, al momento, dispone di soli 5 miliardi stanziati dalla Finanziaria con i quali si deve costruire tutto. Pochi giorni dopo, lo stesso Bettinelli lancia un grido di allarme: "Io ho accettato di dirigere questo Comitato per pura responsabilità politica. Ma il Governo non si rende conto del problema... Non abbiamo nulla, ci mancano gli strumenti, i poteri... non ho nemmeno uno straccio di segreteria organizzativa... e il tempo sta passando" ⁴⁷ http://www.repubblica.it/quotidiano/newspdocs/19990206/basi.html.

Per altri riferimenti si può fare una ricerca su Repubblica on-line (http://www.repubblica.it) con chiave "millennium"

ALCUNE ALTRE INIZIATIVE IN ITALIA - CENNI

 L’Autorità per l’Informatica nella Pubblica Amministrazione (AIPA) ha diffuso alcuni documenti sull’adeguamento dei sistemi informativi automatizzati all’anno 2000 fin dal 1996 ⁴⁸. Essi riguardano varie "Indicazioni" sul problema dell’Anno 2000" ⁴⁹.

L’Associazione nazionale produttori tecnologie e servizi per l’informazione e la comunicazione (Assinform) ha sviluppato un’azione di sensibilizzazione sul tema orientata alle associazioni industriali e alle piccole e medie imprese con incontri in varie città italiane ⁵⁰.

La IBM Italia ha elaborato un documento molto dettagliato: "La piccola e media industria e il problema dell'Anno 2000 ⁵¹ disponibile gratuitamente, che è stata ripresa quasi integralmente dall’Assinform. Iniziative simili sono state intraprese da pressoché tutte le maggiori società di informatica.

CONCLUSIONE

 Per il Millennium Bug non mancano le soluzioni tecniche, quello che sembra mancare è la volontà di affrontare con serietà un problema conosciuto nei più piccoli particolari, forse sottovalutato perché scomodo o, peggio, deriso come trucco di industrie informatiche.

A differenza dell’Euro che nel corso del 1998 le banche e le altre strutture finanziarie avevano improntato simulazioni e si applicavano all’esercizio della nuova valuta per collaudare una transizione che si voleva fosse il più possibile indolore, il problema dell’anno 2000 rischia di venire affrontato solo a emergenza in atto con il tentativo disperato di gestirla; come sperimentare una nuova arma il primo giorno di guerra senza sapere se sarà in grado di sparare nella direzione voluta o se invece esploderà in mano a chi avrà la sfortuna di usarla.

L’insegnamento che ne viene è che, nell’era dei computer, le decisioni politiche determinanti massicci aggiornamenti di software non possono essere pianificate usando arbitrarie scadenze determinate solo da processi politici, trattati internazionali o decreti governativi, ma devono derivare primariamente dalla capacità di compiere tali aggiornamenti sul software e sui data base. La politica non ha più il controllo su molti eventi. 

Appendice A

Appendice B

NOTE 

¹ Quando si parla di nuovo millennio, abitualmente si fa riferimento al 1 gennaio 2000 come data di inizio, ma in realtà non si tratta del primo anno del terzo millennio, ma dell’ultimo anno del secondo millennio. È questa anche la posizione dell’Information services department del Royal Greenwich Observatory, l’ente che dal 1884 dopo la conferenza internazionale sul meridiano (Washington, DC, USA) certifica la nascita ufficiale di ogni giorno, e che rappresenta un punto di riferimento per le questioni riguardanti le date e le misure del tempo. Il nuovo millennio ufficialmente inizia il 1 gennaio 2001 a Greenwich e questa scelta deriva dal fatto che la successione degli anni tra quelli prima di Cristo e dopo Cristo non conobbe un anno zero (cioè all’anno 1 a.C. seguì immediatamente 1 d.C.) anche perché i romani non conoscevano un simbolo numerico per indicare il valore nullo e solo verso il sesto secolo divenne più comune accettare lo zero come un numero. (Cfr. http://millennium.greenwich2000.com/).

² Nel Sistema Internazionale (delle unità di misura) il secondo è definito come la durata di 9.192.631.770 cicli di una particolare transizione allo stato fondamentale della struttura iperfina del Cesio-133. Questo definisce un tempo atomico astratto; in pratica è necessario un dispositivo, detto orologio atomico; la media pesata degli orologi atomici di vari laboratori dislocati sulla terra definisce il Tempo Atomico Internazionale (TAI) che è la migliore realizzazione di una scala del tempo nel Sistema Internazionale. Esso ha una precisione relativa di ±2 10-14. Secondo la teoria della relatività generale il tempo misurato dipende dalla posizione sulla terra (più precisamente dall’altitudine) e anche dalla velocità dell’orologio, così il TAI si riferisce ad un punto, al livello del mare, che ruota con la terra ( cfr. http://www.maa.mhn.de/)

³ UTC (Coordinated Universal Time, definito in francese) ha sostituito il Greenwich Mean Time (GMT) come time-zone di riferimento. Il time-zone di riferimento è basato sull’ora locale al meridiano di Greenwich. Esso è distribuito pubblicamente dai radio trasmettitori DCF77.

⁴ Observatoire de Paris-Meudon-Nancay, ( http://www.obspm.fr).

⁵ Un megabyte di memoria nel 1963 costava 10.000 dollari, oggi ne costa 2.

⁶ Il sistema operativo UNIX memorizza le date in funzione del numero di secondi accumulatisi a partire dal 1 gennaio 1970 usando un’area di memoria di quattro byte che subisce un rollover dopo 232 (=4.294.967.296) secondi.

⁷ http://www.iso.ch/

⁸ http://web.ansi.org/default_js.htm

⁹ http://www.nist.gov/

¹⁰ Incidentalmente il formato ISO standard non è adeguato in ambito scientifico, perché non gestisce ere geologiche né tempi astronomici quindi non consente l’applicazioni di tecnologie come il data mining o l’on-line analytical processing (OLAP) a dati scientifici, perché le date oltrepassano i campi disponibili, mentre una sola cifra in più avrebbe potuto essere la chiave di riconoscimento del formato usato. (Cfr. http://www.roguewave.com/).

¹¹ I prodotti Microsoft supportano il formato ISO non lo adottano di default.

¹² È stato definito il più costoso problema semplice della storia dell’umanità per risolvere il quale occorre il più ambizioso e costoso progetto tecnologico.

¹³ Le carte di credito emesse agli inizi del 1998, e stock di prodotti alimentari (dei magazzini Marks and Spencer) avendo la data di scadenza nel 2000 vennero considerati già scaduti da 98 anni.

¹⁴ Ernesto Hoffman, (laureato in fisica presso l’Università di Roma), uno dei maggiori ricercatori e programmatori dell’Ibm ricorda che quando scriveva programmi abbastanza complicati già a partire dalla metà degli anni ‘60 uno dei vincoli fondamentali della programmazione di quel periodo era di scrivere programmi estremamente piccoli e compatti. La bravura del programmatore era quella di fare il programma più corto possibile con una forma quasi di virtuosismo e il contrarre la data da quattro posizioni a due non venne neppure considerato un problema tanto era lontano il 2000.

¹⁵ La cosa incredibile nella vicenda è che ci sono ancora programmi scritti in quegli anni che nessuno sa più come modificare.

¹⁶ L’industria dei semiconduttori ha prodotto finora circa 70 miliardi di chip, nel solo 1997 sono stati venduti 12 miliardi di microprocessori.

¹⁷ Tra gli aspetti problematici dei sistemi embedded vi è un utilizzo non convenzionale delle date effettuando la sincronizzazione non in modo assoluto ma come differenza rispetto a una data di riferimento, come nei sistemi che gestiscono i cicli di manutenzione. I problemi insorgono quando per il calcolo di un tali cicli vengono usate date assolute. Gli ascensori sono l’esempio più appropriato.

¹⁸ In genere un sistema embedded non dispone di pulsanti di avvio, né accetta input da un computer per poter eseguire delle simulazioni e svolgere dei test.

¹⁹ Studi del settembre 1998 (condotti da Sofware Productivity Research, ( http://www.spr.com) evidenziano che in assenza di azioni preventive c’è l’85% di probabilità di avere problemi abbastanza gravi da determinare cause legali. Negli Stati Uniti il 35% dei dirigenti sono in una cosiddetta classe anno 2000 attiva (cioè autorizzano in modo esecutivo strategie di adeguamento) ed il restante 65% nella classe passiva (quadri tecnici qualificati a segnalare i possibili danni anno 2000). Incrociando le percentuali, il 55% dei dirigenti passivi ed il 30% dei dirigenti attivi sarebbero esposti a cause legali. Inoltre molti contratti di outsourcing precedenti al 1995 non menzionavano neppure l'anno 2000 e l'assenza di clausole specifiche sull'anno 2000 può portare a forme di contenzioso. I clienti ritengono che il problema anno 2000 rientri negli obblighi di manutenzione del software, mentre gli outsourcer ritengono che debba essere considerato in clausole speciali. Per questo motivo già dal 1997 sono state intentate numerose cause legali.

²⁰ Recentemente (The Australian, 6 gennaio 1999) è emerso che su un test effettuato su 26761 sistemi degli ospedali in Australia 7042, oltre un terzo) si sono rivelati non compatibili e di conseguenza il governo ha stanziato la somma di 19 milioni di dollari. (Cfr. http://www.theaustralian.com.au/)

²¹ Si valuta cheil 20% delle applicazioni negli USA ed il 35% negli altri paesi non saranno adeguate in tempo.

²² Cfr. la trasmissione Mediamente in onda su Rai3 il 15-1-1999 alle ore 24.00," Millennium Bug: uno scenario italiano":

²³ Cfr. http://www.anno2000.it/temi.

²⁴ un problema a parte riguarda l’eventuale utilizzo di software non regolarmente licenziato.

²⁵ Nell’indagine del centro Eleusi (Cfr. avanti) nelle medie imprese italiane circa il 91% di esse dispone di software sviluppato ad hoc con una incidenza del 55% sulle attività della funzione Edp dell’azienda.

²⁶ Esiste una lunga casistica di progetti informatici (quasi tutti) che hanno richiesto tempi di realizzazione e di messa a punto assai più lunghi del previsto. Siamo oramai abituati agli annunci di nuovi prodotti da parte delle più importanti società di software che vengono progressivamente rinviati anche di anni.

²⁷ I METODI CI CONVERSIONE.
Il metodo di espansione del campo data consiste nel modificarne il formato da due a quattro cifre, ed è il metodo classico per risolvere il problema anno 2000, ma è costoso e difficoltoso per molte applicazioni, perché talvolta le date sono indirette e nascoste, ad esempio, nel numero seriale del prodotto. Tale metodo richiede tra i 36 e i 40 mesi. Il metodo Windowing o del "secolo finestra" fissa un particolare anno base, punto mediano della finestra, come "ponte" tra i due secoli ed utilizza la logica di programmi esterni per affrontare le date in questo periodo: (ad esempio le date tra 00 e 30 vengono attribuite al 2000 quelle tra 31 e 99 al 1900). Questo metodo può essere terminato approssimativamente in 18 mesi, cosicché è diventato uno dei metodi più popolare per chi ha iniziato tardi. In ogni caso, presuppone la conoscenza precisa dei punti sui quali intervenire. Una variante utilizza una finestra scorrevole e quindi prolunga la validità del sistema spostando in avanti l’anno di riferimento ogni anno. Il metodo Compression codifica la data entro due cifre, usando una rappresentazione binaria o esadecimale anziché decimale; i campi data possono gestire le date per almeno qualche tempo. Il lavoro richiede meno di due anni e una conoscenza della tecnica di compressione usata da tutte le applicazioni che accedono ai dati. Una variante consiste nel rappresentare la data con un numero di sei cifre che rappresentano i giorni a partire da una data arbitraria prefissata presa come origine (codifica). Un’altra variante, il sistema Stanley Mackintosh si basa sull’osservazione che un campo data di sei cifre consente teoricamente 106 combinazioni, mentre il normale formato ne usa solo 36625 (da 1 a 31 per i giorni, da 1 a 12 per i mesi da 0 a 99 per gli anni); pertanto con un’opportuna codifica si utilizza la capacità informativa disponibile nel campo mese per indicare i secoli futuri e quella disponibile nel campo giorno per indicare i secoli passati. Il metodo Encapsulation si basa su tools esterni e sposta la data indietro di 28 anni (perché mantiene la sincronizzazione dei giorni della settimana e del calendario). È abbastanza facile da usare e può essere completato in circa un anno, la difficoltà consiste nelle date indirette e nascoste. Il metodo del Bridging è un metodo ibrido usato per le applicazioni di database in cui un programma di utilità esegue la conversione da due a quattro cifre e viceversa con finestra fissa o scorrevole e encapsulation sullo stesso database. Richiede meno di due anni. Il metodo Data duplexing consiste nella creazione di archivi duplicati in cui la copia ha la data con l’anno a quattro cifre, richiede circa 36 mesi. Il metodo dell’Object-code date interception, usato in ambiente mainframe IBM, consiste nell’intercettazione delle date nei codici degli oggetti che stanno entrando nel mercato, ma non può gestire date nascoste nei numeri seriali di un prodotto. È il metodo più rapido e richiede meno di un anno, ma non è il "silver bullet" perché ci sono troppe date nascoste che sarebbero trascurate.

²⁸ Nella gestione di un progetto software le attività di test impegnano circa la metà delle risorse di tempo e denaro.

²⁹ Secondo Capers Jones, il 7% dei cambiamenti introdotti nell’attività di correzione del codice nei progetto anno 2000 genera nuovi errori che diventano un numero preoccupante quando si ha a che fare con un portafoglio applicativo di molti milioni di linee di codice come per una grande azienda.

³⁰ Ora è risaputo che tutti i sistemi in produzione contengono errori, alcuni conosciuti ma non ancora corretti, altri latenti e sconosciuti; nel caso dell’anno 2000 occorre effettuare un tipo di test oggi ancora relativamente nuovo, il "baseline testing" secondo il quale occorrerebbe ripetere tutti i test finora effettuati sull’applicazione (prima della modifica) per verificare che si ottenga lo stesso risultato anche dopo la modifica, cioè gli interventi per l’anno 2000 devono riprodurre, anche nelle loro componenti non corrette i comportamenti dei sistemi oggi in funzione.

³¹ Un’ulteriore bug riguarda il 1 aprile 2001 per un errore di programmazione della Msvcrt.dll di Windows 95/98 che regola il cambio dell’ora legale (appunto il 1-4-2001) e che andrà sostituita.

³² La confusione riguardo alla compatibilità di Microsoft Office rispetto all’anno 2000 riguarda soprattutto due punti, le diverse versioni della suite cambiano di volta in volta le cosiddette "date pivot" (che determinano in quale secolo calcolare il mese e l’anno dell’applicativo); e l’utilizzo di macro (soprattutto in Excel) create dagli utenti finali che non riescono ad interpretare correttamente le date e non possono utilizzare la finestra relativa al secolo su cui si basa Excel, specie nell’aggiornamento da Office 95 a Office 97 o nello scambio di dati tra le due versioni. Anche Windows 98 ha un errore, nel caso di un riavvio pochi secondi prima dell’aggiornamento della data, sposta il calendario di sistema di uno o due giorni avanti o indietro.

³³ Per Windows NT 4.0 non è vero quanto affermato da Microsoft secondo cui il sistema operativo impedirebbe l’accesso diretto al real-time-clock, in questo caso Microsoft consiglia di modificare le applicazioni critiche in modo da basarsi su altre fonti standard accurate, come i servizi pubblici che forniscono l’ora esatta.

³⁴ Anche sistemi operativi anno 2000 compatibili, possono generare incompatibilità se viene usata l’opzione di default con l’anno a due cifre e si gestisce male (occorre cioè impostare la data gg/mm/yyyy così ogni introduzione di data a due cifre viene immediatamente trasformata a quattro cifre in modo da poter verificare subito il corretto riferimento al secolo).

³⁵ La maggior parte dei gateway registrano automaticamente gli identificativi dei messaggi (Ids Internet) ogni 90 giorni.

³⁶ Cfr. Computerworld Italia, 11 maggio 1998, p.36, "Le medie aziende italiana una realtà sotto osservazione".

³⁷ La società milanese Hal Informatica, è stata una delle prime in Europa a predisporre rimedi al millennium bug iniziandone lo studio nel 1995, e dichiarò che la maggiore difficoltà era quella di dover rivedere quasi tutte le applicazioni software entro una certa data, perché il settore del software risente particolarmente del peso degli imprevisti: quasi nessun progetto viene portato a termine entro i tempi previsti ed ben il 40% dei progetti non arriva neppure alla fine.

³⁸ 18 Marzo 1998, Museo dei Navigli, Milano, organizzato da Logicasiel società del gruppo Telecom Italia-Finsiel.

³⁹ Capers Jones, fondatore e Chairman della Software Productivity Research ( http://www.spr.com) specializzata nella gestione di progetti software è considerato il padre dell’Analisi Funzionale ed un pioniere nell’uso dei Function Point, (una metrica di analisi del software, nata nel 1970 in casa IBM) che consente una valutazione più ricca e profonda della semplice quantità di linee di codice (LOC). Essa fornisce degli indicatori atti a valutare un’attività di sviluppo e manutenzione del software, l’efficienza dei programmatori e sviluppatori. Ricco di un tale bagaglio di primo ordine nelle problematiche di programmazione, il suo parere è di grande valore nella valutazione dell’effettiva consistenza del problema dell’anno 2000.

⁴⁰ Il General Accounting Office (GAO) americano ha preparato una pubblicazione di guida per lo sviluppo di un piano di emergenza (contingency plans and business continuity plans) http://www.gao.gov/

⁴¹ Cfr. Computerworld Italia del 14 aprile 1998, p.33.

⁴² Ricordiamo pure che l’adeguamento del piano applicativo dell’INPS per l’anno 2000 ed euro richiede il riesame di ben 12.5 milioni di linee di codice ed è stato dato in appalto a Finsiel per soli 10 miliardi di lire e che la gara d’appalto andò quasi deserta.

⁴³ Cfr. Computerworld Italia del 4 maggio 1998, p.33.

⁴⁴ Cfr. Computerworld Italia del 11 maggio 1998, p.37.

⁴⁵ Ibidem, p.37.

⁴⁶ Cfr La Repubblica: Duemila, la via italiana per sconfiggere l'insetto di Annalisa Usai (14 gennaio 1999): http://www.repubblica.it/

⁴⁷ Cfr. La Repubblica: Millennium Bug: il capo del Comitato anno 2000 di Palazzo Chigi lancia un grido d'allarme. "E' in gioco l'intero sistema e il Governo non l'ha capito" Bettinelli: sono a rischio gli ospedali, i trasporti e la sicurezza dei cittadini di Annalisa Usai (5 febbraio 1999) http://www.repubblica.it/
Cfr. La Repubblica: Disarmati di fronte al Millennium bug. Il cambio di data dei computer: il governo stanzia 5 miliardi, ma è polemica (6 febbraio 1999).

⁴⁸ Cfr. http://www.aipa.it/11/index.asp11/index.asp

⁴⁹ Cfr. Indicazioni per il dimensionamento dei progetti Anno 2000 (http://www.aipa.it/[11/ind_all8.asp[11/ind_all8.asp),

Indicazioni per l'acquisizione di servizi relativi ai progetti Anno 2000 (http://www.aipa.it/[11/ind_all10.asp[11/ind_all10.asp).

⁵⁰ Cfr. http://www.assinform.it.

⁵¹ Cfr. http://www.ibm.it/, http://www.ibm.it/anno2000.