Premessa

Nell’articolo precedente sono stati presentati gli argomenti teorici analizzati per poter definire il progetto di realizzazione di un Technical Repository INAIL.

Partendo da una preliminare analisi della documentazione in nostro possesso, sono state analizzate:

• le funzionalità del modello proposto dall’Open Archive Iniziative, considerando di tale movimento l’importanza data alla realizzazione di sistemi software in grado di garantire l’interoperabilità tra sistemi, la condivisione e soprattutto la conservazione a lungo termine della documentazione;
• l’approccio adattativo dell’approccio agile allo sviluppo del software, ritenendolo più adatto a una attività di ricerca.

Pertanto in questo articolo viene presentata l’applicazione dei principi Agile impiegati nello sviluppo del Repository, enfatizzando i benefici che si sono ottenuti per lo sviluppo del Technical Repository Inail.

La documentazione tecnica dell’INAIL

Il ciclo di vita dello sviluppo Agile, rappresentato in figura 1, può essere scandito in quattro “fasi”; lo scopo di questo studio è di descrivere la prima (Iteration 0) relativa al progetto in esame, al fine di evidenziare le modalità e soprattutto i vantaggi ottenuti.

Iteration 0 per il caso di studio

La metodologia Agile concepisce le fasi di “analisi” tenendo in considerazione anzitutto l’adattabilità in futuro del Technical Repository in base alle necessità dell’utente; si tratta quindi di un approccio adattativo piuttosto che predittivo, aspetto particolarmente vantaggioso: trattandosi di un’attività di ricerca, infatti, il processo di progettazione ha una natura fortemente sperimentale.

Il team di sviluppo del Repository è costituito da diverse figure professionali, ognuna competente per i vari aspetti di progettazione e realizzazione.

In particolare, si è ritenuto necessario coinvolgere le seguenti figure:

• tecnici esperti nell’attività di certificazione e verifica INAIL, in grado di fornire le competenze specifiche per ogni settore di verifica dell’Ente;
• documentalisti esperti in biblioteconomia per gestire la fase di indicizzazione e catalogazione dei documenti, e della struttura contenutistica del Repository;
• informatici esperti in sviluppo software per la futura realizzazione del sistema;
• esperti in comunicazione.

Si è deciso di descrivere tramite un linguaggio di modellazione grafico le operazioni compiute per evidenziare la sequenza di esecuzione di queste ultime e, soprattutto, i feedback tra le varie azioni svolte durante le fasi iniziali di sviluppo.

Come è possibile osservare dal flow chart di figura 2, la presenza di diversi feedback rende evidente l’importanza del coinvolgimento dell’utente finale, cioè i tecnici interni, nella fase decisionale della struttura in diversi momenti di sviluppo, trascurando per il momento l’impatto che può avere una futura apertura del Repository a utenti esterni.

Per comprendere meglio le attività che sono state condotte verranno di seguito descritte i singoli elementi descritti nel diagramma.

Studio modello Open Access

Il movimento Open Access, al fine di garantire l’interoperabilità tra i repositories ha individuato un modello per l’organizzazione dei depositi di conservazione, il modello OAIS (Open Archival Information System) recepito e pubblicato come standard ISO 14721:2012.

Tale modello non impone alcun vincolo sulle tecnologie da utilizzare per l’implementazione lasciando molta flessibilità in questo ambito.

Negli anni sono stati sviluppati numerosi prodotti software open source per la gestione dei repositories secondo il modello OAIS, che permettono una configurazione e personalizzazione della piattaforma al fine di rispondere al meglio alle esigenze degli stakeholder. L’idea della ricerca è di adottare uno di questi prodotti software open source e configurarlo/modificarlo al fine di soddisfare tutti i requisiti funzionali individuati durante la fase di elicitazione.

Definizione dei requisiti e analisi dei documenti

Il modello OAIS impone alcuni requisiti funzionali e non funzionali che il prodotto software deve rispettare per essere conforme allo standard, pertanto una prima fase di specifica dei requisiti è desumibile dallo standard ISO 14721.

In sintesi, è possibile elencare alcuni elementi base come:

• la conservazione dell’informazione nel lungo periodo;
• l’accesso all’informazione archiviata, in una forma coerente con le esigenze degli utenti del sistema;
• possibilità di avere dati in formato digitale di qualsiasi tipo;
• uso di metadati standard come Dublin Core;
• supporto del protocollo OAI-PMH per l’esposizione dei metadati;
• supporto del full text search tramite Google;
• ricerca mediante Thesauri;
• possibilità di organizzare le risorse distinte per collezioni;
• processo di submissing automatizzato;
• possibilità di reperire statistiche di accesso al sistema;
• identificatori persistenti atti a garantire la preservazione;
• supporto dell’OpenURL linking;
• spazio riservato all’utente autorizzato in cui poter memorizzare percorsi di ricerca e documenti selezionati.

Per quanto concerne, invece, i requisiti strettamente legati al tipo di Repository che si vuole realizzare, è necessario analizzare attentamente la documentazione che dovrà essere archiviata.

Le attività di certificazione e verifica svolte dal Dipartimento Innovazioni Tecnologiche e Sicurezza degli Impianti, Prodotti e Insediamenti Antropici della Direzione Centrale Ricerca INAIL e dalle Unità Operative Territoriali delle Direzioni Regionali INAIL sono finalizzate a garantire la sicurezza di macchine, apparecchi, utensili e impianti utilizzati nei luoghi di lavoro mediante il rilascio di certificati a seguito della verifica di conformità del prodotto attraverso attività di collaudo, verifica e controllo.

Le attività più significative riguardano i settori: ascensori e montacarichi da cantiere, attrezzature di sollevamento, impianti di messa a terra e protezione dalle scariche atmosferiche, apparecchi a pressione e impianti di riscaldamento.

I documenti riguardanti ogni singolo settore e in particolare le singole apparecchiature sono molteplici e spesso correlati tra loro; pertanto, l’applicativo che si vuole realizzare deve essere uno strumento altamente usabile per permettere l’individuazione rapida del materiale ricercato ma anche altamente performante per offrire una panoramica esaustiva dell’argomento di interesse con correlazioni tra le varie tipologie di documentazione.

Questo richiede una personalizzazione del software per permettere la visualizzazione delle correlazioni e la creazione di un soggettario di termini tecnici legati all’attività di verifica.

Il lavoro preliminare ha riguardato innanzitutto il reperimento della documentazione, posseduta a livello centrale dal Dipartimento Innovazioni Tecnologiche e Sicurezza degli Impianti, Prodotti e Insediamenti Antropici, e a livello territoriale dai tecnici appartenenti alle Unità Operative Territoriali di Certificazione e Verifica, in particolare circolari, note e pareri dell’ISPESL/INAIL e ministeri, norme tecniche, decreti legislativi, riferimenti normativi pubblicati nel corso degli anni.

Successivamente, il lavoro ha previsto l’analisi del contenuto per comprendere la struttura di tali documenti e permettere un’accurata definizione dei metadati Dublin Core da usare per la catalogazione. E infine, prima della vera e propria creazione del software, è stato, comunque, necessario avvalersi di un database temporaneo per conservare l’informazione ricavata durante le fasi di selezione e analisi dei documenti.

Definizione comunità/collezioni

Dal punto di vista documentale, l’informazione deve essere descritta in modo puntuale mediante l’ausilio di metadati, ma l’usabilità dell’archivio e la semplicità nel reperire l’informazione sono fortemente legate alla comprensione delle esigenze dei tecnici per le loro attività di certificazione e verifica di impianti e attrezzature.

L’organizzazione che viene data all’informazione nel sistema dei depositi istituzionali parte dall’individuazione di raggruppamenti logici, identificati con i termini di “comunità” e “collezioni”.

Questo approccio è significativo, in quanto nel concetto di comunità sono impliciti i principi di interazione e di comunicazione. Le comunità definiscono le collezioni, sottocategorie che permettono una migliore organizzazione dell’informazione, decidono le politiche di accesso, i criteri di validazione dei contenuti e la loro tipologia.

Nei tradizionali repositories, generalmente, le comunità si identificano con le ripartizioni di un ente: dipartimenti, istituti o gruppi di ricerca. Le comunità presenti nel Technical Repository, invece, presentano differenti caratteristiche da quelli tradizionali proprio per la tipologia di documentazione da archiviare.

Il contesto di studio ha determinato la definizione di particolari comunità, partendo dalla organizzazione logica delle procedure di certificazione e verifica effettuate su apparecchiature/impianti. Tale organizzazione non è risultata per nulla scontata poiché, pur partendo dalla consapevolezza che l’utente finale, almeno in un primo momento, sarà un esperto del settore, e quindi capace di muoversi facilmente all’interno del Technical Repository, l’attenzione è stata rivolta a facilitare l’utilizzo del sistema da parte di un utente meno esperto.

Per questo, le comunità principali da cui verrà generato la struttura ad albero dell’archivio coincidono con i settori di verifica:

• impianti a pressione;
• impianti di sollevamento;
• impianti di messa a terra e scariche atmosferiche;
• impianti di riscaldamento.

Le sottocomunità/collezioni verranno strutturate in base all’attività svolta (omologazione, dichiarazione di messa in servizio, prima verifica periodica ecc.) sulle diverse apparecchiature appartenenti ai singoli settori.

La ramificazione dell’albero comunità\collezioni sarà determinata dal numero di documenti che popoleranno le singole unità logiche, prevedendo accorpamenti o suddivisioni delle stesse qualora si ritenga necessario.

Definizione schema metadati

Nel mondo bibliotecario e dell’informazione più in generale, l’aspetto descrittivo dei supporti e la loro valenza informativa in termini di contenuti hanno svolto da sempre un ruolo di centrale importanza; si sono così andate definendo regole e standard sia per quella che comunemente si chiama descrizione bibliografica sia per quella che si definisce genericamente descrizione analitica. Nel mondo digitale questi aspetti sono ancora più legati fra loro che per i supporti tradizionali. Ciò è dovuto soprattutto alla necessità di mantenere l’oggetto aggiornato e fruibile in termini tecnologici.

La definizione dei metadati, come schemi di riferimento per risolvere tali problemi, nasce da queste considerazioni. I metadati devono essere il più possibile standard; in questa attività di ricerca si è scelto di utilizzare i metadati Dublin Core, che definiscono un insieme di elementi per la descrizione di proprietà relative a risorse suddivisi in due livelli: Simple e Qualified, mediante i quali possiamo descrivere una risorsa come insieme di coppie elemento/valore in un linguaggio indipendente da una particolare implementazione.

DataBase di test

Prima di passare alla Fase 2, caratterizzata da una serie di iterazioni di sviluppo in cui si realizza il sistema in maniera iterativa e incrementale, si è deciso di effettuare un ulteriore testing delle scelte prese nella fase iniziale, prevedendo la realizzazione di un semplice database in cui indicizzare i primi documenti al fine di verificare l’efficacia delle scelte prese.

Tale database è stato utile per evidenziare alcuni aspetti basilari per la scelta dei metadati da usare. In particolare, è risultato importante salvare come informazione il riferimento ad altri documenti tecnici menzionati nel documento stesso, e soprattutto se la norma/circolare di riferimento è stata abrogata o sostituita da altra, con l’indicazione del metadato di quest’ultima. Solo in questo modo il tecnico che ricerca informazioni riguardanti una determinata apparecchiatura e relativa attività di verifica e certificazione può avere una panoramica completa dei riferimenti legislativi da seguire.

Inoltre questo strumento di test è stato utile per valutare la correttezza dell’organizzazione delle sottocomunità/collezioni individuate a livello concettuale; infatti, assegnando ad ogni documento la comunità e le relative collezioni, si è potuto valutare meglio il livello di ramificazione dell’albero per evitare di creare descrittori troppo generici o troppo specifici per la documentazione in nostro possesso.

Conclusioni

La fase di studio condotta fino ad oggi conferma l’efficacia dell’approccio agile descritto precedentemente, in quanto anzitutto il coinvolgimento diretto del fruitore dell’informazione, il tecnico dell’Istituto, ha permesso una accurata definizione dei metadati Dublin Core da utilizzare per descrivere la risorsa e una strategica organizzazione logica mediante l’organizzazione in Comunità e Collezioni.

La scelta accurata di tali elementi permette di soddisfare una serie di necessità legate alla correlazione della documentazione in un contesto dove può essere indispensabile considerare diversi riferimenti normativi per effettuare una corretta verifica dell’impianto/attrezzatura e soprattutto tener conto dell’evoluzione della normativa sulla sicurezza. La flessibilità adottata ha permesso una interazione e valutazione del soddisfacimento nella definizione dell’organizzazione dell’informazione, obiettivo principale da perseguire, in quanto il materiale di interesse deve essere facilmente rintracciabile e consultabile, oltre che fruibile, anche mediante navigazione dell’informazione sia dal tecnico esperto del settore sia dal neofita che si approccia alla materia.

Inoltre, partendo da una struttura di base proposta dai software open source sviluppati per un Repository, sono stati individuati nuovi requisiti funzionali del prodotto che dovranno essere implementati anche, eventualmente, in fase successiva.

La collaborazione stretta con gli stakeholder e gli altri membri del team ha garantito un soddisfacente risultato in tempi brevi; l’eventuale possibilità di avere una migrazione dei dati caricati sul database di test permette di ottimizzare il lavoro di indicizzazione da trasferire poi nel software Repository finito.

Lo stesso concetto di Open è strettamente legato ad uno sviluppo Agile del sistema; in una fase successiva alla catalogazione della documentazione nell’archivio, verranno definite le Policies di accesso alle varie risorse, che porteranno ad una riorganizzazione dei permessi di accesso alle varie comunità/collezioni del Repository.

Le politiche di apertura dei dati, promosse dal movimento Open Access, tengono conto degli aspetti relativi alla protezione della privacy, alla sicurezza nazionale e ai diritti di proprietà intellettuale, pertanto tali requisiti, non mettono in discussione eventuali necessità dell’Istituto di rendere riservati o protetti alcuni documenti, ma rende possibile l’interscambio della documentazione tra i tecnici/utenti interni e gli enti abilitati/utenti esterni.

I benefici di un approccio Agile si evidenziano nella possibilità di aver a disposizione fin da subito un prodotto software che implementi i requisiti individuati nelle fasi iniziali, ma lasciando l’opportunità di integrare, migliorare il sistema rispettando la specificità di un’attività di ricerca.