UNIONE EUROPEA
REPUBBLICA ITALIANA - REGIONE SICILIANA
ASSESSORATO BILANCIO E FINANZE
POR SICILIA – MISURA 6.05
LINEE GUIDA
“RETI E SERVIZI PER LA SOCIETÀ DELL’INFORMAZIONE”
AZIONE 3
P.O.R. SICILIA 2000/2006
V.2402051
1
In rosso le parti modificate rispetto alla versione 310105.
INDICE
INTRODUZIONE ....................................................................................................................................3
SEZIONE I – IL PROGETTO ESECUTIVO .......................................................................................4
A.
LE RETI CIVICHE......................................................................................................................4
B.
PROGETTAZIONE DEL SITO INTERNET: ACCESSIBILITA’ ED USABILITA’...................................7
C.
W3C ......................................................................................................................................10
D.
PROTOCOLLO INFORMATICO ..................................................................................................11
E.
INDICE DELLA PUBBLICA AMMINISTRAZIONE E POSTA CERTIFICATA.....................................17
F.
FIRMA ELETTRONICA .............................................................................................................19
G.
INTEROPERABILITÀ E COOPERAIONE APPLICATIVA .................................................................20
H.
LA QUALITÀ DEI BENI E DEI SERVIZI ICT ................................................................................21
I.
ADOZIONI INTERNAZIONALI ...................................................................................................23
P.
SERVIZI DI ANAGRAFE ...........................................................................................................24
A) SERVIZI INFORMATICI ......................................................................................................................27
B) SVILUPPO SOFTWARE E AQUISTO LICENZE ........................................................................................27
C) BANCHE DATI ..................................................................................................................................27
D) HARDWARE .....................................................................................................................................28
D.1 Attrezzature e Strumentazioni ad ammortamento pluriennale .........................................28
D.2 MATERIALI DI CONSUMO ............................................................................................29
E) RETI ...............................................................................................................................................30
F) CONSULENZE SPECIALISTICHE ..............................................................................................32
F.1) Personale dipendente (NON APPLICABILE)........................................................................32
F.2. Personale esterno con rapporto assimilabile a lavoro dipendente: (NON APPLICABILE) ..32
F.3) Prestazioni esterne (Prestatori d’opera non soggetti a regime IVA)......................................32
F.4 Professionisti soggetti al regime IVA ...............................................................................32
F.5 Società ..............................................................................................................................33
G – CONNETTIVITÀ INTERNET ..............................................................................................................34
H – ADDESTRAMENTO PERSONALE ......................................................................................................34
I- DIREZIONE LAVORI E PROGETTAZIONE ............................................................................................34
I.1) Personale dipendente (NON APPLICABILE).........................................................................35
I.2. Personale esterno con rapporto assimilabile a lavoro dipendente: (NON APPLICABILE)....35
I.3) Prestazioni esterne (Prestatori d’opera non soggetti a regime IVA).......................................35
I.4 Professionisti soggetti al regime IVA ...............................................................................35
I.5 Società ..............................................................................................................................36
SEZIONE III – LA PROCEDURA DI RENDICONTAZIONE DELLA SPESA ............................37
SEZIONE IV - SCADENZARIO DEGLI ADEMPIMENTI..............................................................40
SEZIONE V - NORMATIVA DI RIFERIMENTO ............................................................................41
GLOSSARIO ..........................................................................................................................................43
2
INTRODUZIONE
Il presente documento contiene le linee guida per la realizzazione dei progetti a valere
sull’Azione 3 “RETI E SERVIZI PER LA SOCIETÃ DELL’INFORMAZIONE” Misura 6.05
del P.O.R. SICILIA 2000/2006, la determinazione dei costi eleggibili, nonchè le modalità e la
tempistica connessa alla rendicontazione della spesa e relativo monitoraggio.
In particolare, il documento riporta alcune indicazioni di tipo generale per la predisposizione,
dal punto di vista tecnico, dei progetti di dettaglio richiesti dal Dipartimento Bilancio e Tesoro,
nonchè alcuni riferimenti di norme, circolari, guide e documentazione tecnica da tenere in
considerazione nella stesura del progetto.
Il progetto esecutivo da presentare al Dipartimento Bilancio e Tesoro é composto dalle seguenti
sezioni:
•
Allegato A.1 Descrizione del progetto
•
Allegato A.2 Riepilogo dei costi
•
Allegato B Servizi sviluppati
L’importo delle singole voci di costo, per tipologia di spesa, riportate nell’apposito allegato
dovranno essere quelle approvate .
E’ ammessa la variazione di tali importi, nei limiti indicati nel disciplinare se tale variazioni
sono funzionali ad una rimodulazione di alcune attività del progetto orientate a:
1) Supporto delle attività relative alle adozioni internazionali
2) Interoperabilità e cooperazione applicativa del sistema delle anagrafi
Si pone in evidenza come il secondo dei punti sia, per l’amministrazione regionale, una attività
strategica in termini di supporto ad una serie di azioni che verranno intraprese
dall’amministrazione regionale al fine di controllare la spesa nel settore sanitario ed innalzare il
livello dei servizi sanitari.
3
SEZIONE I – IL PROGETTO ESECUTIVO
A.
LE RETI CIVICHE
Una rete civica è un ambiente telematico che si propone di promuovere e favorire la
comunicazione, lo scambio e l'erogazione di servizi fra i cittadini e tutti i soggetti pubblici e
privati che costituiscono una comunità locale e, al tempo stesso, di aprire la comunità locale alla
comunicazione via rete con il resto del mondo. In tale ottica una rete civica garantisce quindi un
diritto di cittadinanza telematica e si caratterizza per i seguenti elementi:
− contenuto fornito dagli aderenti. Coloro che si sono ”iscritti“ o che aderiscono
alla rete civica devono avere la possibilità di partecipare attivamente alla
costruzione del contenuto della rete stessa (o partecipando a gruppi di
discussione pubblici o costruendo autonomamente ”pagine“ informative di
interesse generale);
− comunicazione bidirezionale tra gli aderenti e coloro che forniscono
informazioni sulla rete (siano essi amministratori, enti pubblici o privati
cittadini). Non è sufficiente fornire informazioni (sull'esempio di un ``televideo
evoluto") ma occorre agire in conseguenza dello stimolo fornito da tutti gli
aderenti originando uno scambio costruttivo di idee e opinioni a tutto vantaggio
del contenuto qualitativo della rete civica;
− facilità d'uso. È fondamentale fornire ai cittadini uno strumento di utilizzo della
rete il più semplice possibile ed il più possibile integrato;
− economicità d'uso. Considerato che il servizio che si vuole fornire è indirizzato
a tutta la cittadinanza si deve tenere conto dell'economicità di utilizzo del
servizio stesso. Ciò comporta: iscrizione gratuita per l'utilizzo della rete civica,
distribuzione gratuita dell’eventuale software necessario per l’uso dei servizi
fruibili, condizioni agevolate per chi volesse pubblicare informazioni sulla rete;
− condivisione di regole di buon comportamento telematico. Passo fondamentale
delle reti civiche è quello di introdurre nel mondo Internet i propri aderenti,
abituandoli al rispetto degli altri “cittadini virtuali" e al rispetto delle regole
comuni di comportamento atte a salvaguardare i diritti di tutti a “essere in rete".
Dal punto di vista infrastrutturale una rete civica è costituita da un insieme di nodi connessi tra
loro in rete mediante una rete privata o mediante circuiti noleggiati da un operatore di
telecomunicazione, connessi a sua volta ad altre reti (tipicamente Internet). L'accesso
dall'esterno avviene mediante linee telefoniche via modem o, preferibilmente, via rete Internet
per chi già possiede un collegamento. Dal punto di vista software, una rete civica fornisce a un
largo numero di utenti che possono contemporaneamente collegarsi ad essa o da casa o da altri
luoghi (ad esempio, biblioteche, scuole, uffici, etc.) la possibilità di:
− mandare e ricevere e-mail ad altri aderenti alla rete civica e a utenti collegati su
Internet;
− iscriversi a liste di discussione (mailing list);
− accedere ad informazioni testuali, grafiche o sonore contenute negli archivi
della rete civica; inoltre possono essere resi disponibili per lo scaricamento una
serie di programmi di utilità generale liberamente distribuibili;
− accedere a servizi avanzati, quali la consultazione del difensore civico,
l'espletamento di una pratica amministrativa, l'interrogazione di un data-base di
pubblico interesse come ad esempio quello delle delibere comunali;
4
E’ possibile individuare quattro possibili tipologie di reti civiche e comunità on line:
Civic Networks (o reti delle Pubbliche Amministrazioni);
Community Free Nets (o reti dei cittadini);
City Nets (reti in cui la città “si mette in mostra")
Integrated Community on line (o comunità integrata on line)
Le Civic Networks si propongono di migliorare la comunicazione e l’interazione fra
amministrazione pubblica e cittadini rendendo più facile ed efficiente lo svolgimento dei
compiti delle istituzioni.
Le Community Free Nets hanno invece lo scopo dichiarato di facilitare la comunicazione fra le
varie componenti della comunità, permettendo ad ogni suo appartenete di avere lo spazio e
l’opportunità di esprimersi. Vengono realizzate essenzialmente grazie all’apporto degli stessi
cittadini che forniscono i contenuti, decidono gli argomenti, ne delineano la struttura e lo
sviluppo, propongono e realizzano nuovi servizi, partecipano alla loro gestione.
Le City Nets sono reti nelle quali si mettono in mostra informazioni di tipo turistico,
commerciale o relative a servizi di pubblico interesse (spettacoli, orari, prezzi, ecc.). Queste reti
vetrina si differenziano tra loro a seconda che vogliano sviluppare l’immagine turistica della
città, rivolgendosi soprattutto ad utenti esterni alla comunità, o che invece vogliano essere di
supporto alle aziende ed al commercio locale, rivolgendosi quindi ad utenti interni alla
comunità.
Infine le Integrated Community on line i cui elementi caratterizzanti sono:
− coinvolgere comunità di cittadini appartenenti a comuni limitrofi (solitamente
medio piccoli) con le medesime condizioni socio-ecomomiche;
− garantire una integrazione di servizi on line a cittadini ed imprese del territorio
di riferimento, rendendo più efficace ed efficiente l’azione amministrativa;
− l’elevato livello di interazione fra le pubbliche amministrazioni coinvolte, i
cittadini e le imprese;
− una struttura modulare in cui, accanto a spazi web che offrono servizi a cittadini
ed imprese (ad esempio lo sportello unico telematico, sevizi on line per le
famiglie, biblioteche digitali, etc) vi sono spazi autogestiti dagli utenti della
community;
− intranet/extranet per lo scambio di documenti fra le P.A. coinvolte;
− partecipazione on line alla vita democratica (e-democracy).
Mentre i primi tre modelli (di derivazione statunitense) sono più idonei per aree metropolitane e
comuni sopra i 100.000 abitanti, il quarto modello di riferimento è più consono alla realtà
italiana che si caratterizza per una quantità innumerevole di comuni medio-piccoli i cui cittadini
hanno aspettative ed esigenze similari nonostante l’appartenenza ad amministrazioni differenti.
Ciò a maggior ragione nel caso degli specifici progetti a cui si riferiscono queste linee guida,
che vedono coinvolti aggregazioni di Comuni e Province.
Proponiamo di seguito una road map per la nascita e crescita di una Integrated Community on
line.
La prima fase riguarda la nascita della rete civica. I comuni interessati dovranno procedere a
stipulare un protocollo d’intesa (non necessario qualora siano già esistenti fra loro altre forme
amministrative che li legano quali: Unioni di Comuni o Consorzi) in cui si impegnano a
costituire ed alimentare la rete civica stabilendo quali servizi erogare on line ai propri cittadini
con modalità similari. Nel medesimo protocollo dovranno nominare un loro rappresentante che
farà parte del ”Comitato di gestione“: quest'ultimo avrà il compito di decidere le linee guida da
tenere per lo sviluppo della rete civica, redigere i regolamenti d'uso interni, per i cittadini e per i
fornitori di informazioni e far fronte a tutte le istanze di espansione della rete civica (potrà
5
quindi decidere in che modo accogliere le richieste di pubblicazione di informazioni da parte di
chi manifesterà questa intenzione e deciderà anche come allargare la presenza di "nodi“ della
rete civica in città).
Si provvederà quindi alla infrastutturazione hardware e software della rete: verrà costituito uno
Staff centrale che dovrà reperire e organizzare in modo sistematico le informazioni da
pubblicare; gestire i newsgroup, garantire il funzionamento del software e dell’hardware, etc.
Presso ciascuna amministrazione coinvolta saranno costituiti Staff Locali con il compito di
reperire le informazioni locali.
Tutti i funzionari coinvolti saranno dotati di firma digitale per garantire la certezza dei
documenti inviati.
Nell’avvio, di notevole importanza sarà la collaborazione del mondo della scuola; saranno presi
degli accordi con le scuole medie inferiori e superiori per partecipare alla realizzazione della
rete civica. Presso gli istituti scolastici coinvolti saranno istallate postazioni internet per
collegarsi con la rete civica affinché possano:
usufruire dei servizi da essi offerti;
realizzare propri spazi all’interno della rete stessa.
Inoltre per garantire la massima diffusione della rete potranno essere installate postazioni della
rete presso sedi quali le biblioteche comunali.
Sempre nella prima fase verrà predisposto un collegamento tra la rete civica e la rete Internet
che permetterà agli utenti di quest'ultima di vedere il contenuto della rete civica, permetterà ad
alcune postazioni all'interno degli enti di utilizzare in maniera completa Internet (comprese delle
eventuali postazioni di accesso pubbliche) e permetterà lo scambio di e-mail tra utenti Internet e
utenti della rete civica. Il collegamento adottato sarà basato sulla tecnologia xDSL.
Per quanto concerne le soluzioni software per garantire la massima diffusione e l’abbattimento
dei costi verrà effettuata una attenta valutazione di utilizzo di soluzioni software di tipo open
source, sia per gli ambienti operativi che per le applicazioni software.
Nella seconda fase si decideranno le modalità di ingresso di tutte le realtà non contemplate nella
prima fase (privati, aziende ecc.) valutando ulteriori ampliamenti del numero di nodi
(computer/server) della rete civica.
Durante queste due fasi si cercherà di avviare, con le entità coinvolte, dei progetti di
allargamento e potenziamento dei servizi offerti agli utenti al fine di rendere sempre più
``interattivo'' l'uso della rete civica. Si può pensare all'interrogazione di data-base pubblici
all'interno delle amministrazioni (come ad esempio l'archivio delle delibere), al rilascio di
certificati di vario tipo e così via.
6
B.
PROGETTAZIONE DEL SITO INTERNET: ACCESSIBILITA’ ED USABILITA’
“Accessibile” ed “usabile” spesso vengono utilizzati come sinonimi. In realtà, pur
sovrapponendosi parzialmente, i due termini hanno significati differenti. Quando si parla di
“accessibilità” degli strumenti informatici si fa riferimento alle interfacce e ai sistemi di
navigazione resi fruibili da chiunque, indipendentemente dal mezzo utilizzato, sia esso un
browser, uno screen reader con uscita vocale o tattile, un browser testuale.
Quando si parla di “usabilità” di un’interfaccia si fa riferimento alla possibilità, da parte di un
utente generico, di reperire in modo semplice ed immediato le informazioni che sta cercando e
di interagire con un sistema (ad esempio un sito di informazioni o una procedura complessa)
senza ricorrere ad aiuti esterni.
Si tratta di estendere al Web il principio generale di “progettazione universale” che tiene conto
di tutti i possibili utenti, anche di quelli marginali. Seguire questo principio comporta un
miglioramento dell’utilizzo da parte di tutti; si pensi, ad esempio, ai benefici generati
dall’eliminazione delle barriere architettoniche o dalla progettazione dei rubinetti miscelatori
che svolgono tutte le funzioni con una sola leva.
Ogni volta che si progetta qualcosa ci si deve domandare, oltre a cosa si vuole fare, anche chi
fruirà del prodotto finale. Le regole generiche che valgono per qualsiasi disciplina vengono
parimenti adottate per il Web. Tenere conto dell’accessibilità di un servizio significa non
escludere nessuno a priori, ma significa anche porre maggiore attenzione a particolari categorie
di utenti. Di seguito vengono presentate le principali forme di disabilità e le soluzioni previste
per agevolare l’accesso alle informazioni.
Le disabilità fisiche possono essere ricondotte a quattro categorie:
• Disabilità della vista (non vedenti e ipovedenti);
• Disabilità dell’udito;
• Disabilità motorie;
• Disabilità cognitive.
A queste categorie si possono aggiungere le disabilità temporanee (es. rottura di un arto
superiore) e le disabilità professionali (es. sindrome del tunnel carpale).
La disabilità della vista comprende diverse tipologie di utenti: i non vedenti, gli ipovedenti e i
daltonici.
I problemi di accesso alle informazioni in rete e più in generale l’utilizzo del computer,sono
diversi per le differenti tipologie di utenti sopra descritte. Infatti, mentre i non vedenti utilizzano
screen reader per accedere alle informazioni, i daltonici usano invece il computer nel modo
tradizionale e le persone ipovedenti si collocano trasversalmente alle altre due categorie di
utenti. A seconda della gravità dell’ipovisione, infatti, essi possono o navigare in modo
tradizionale, utilizzando un browser, ingrandendo il carattere e magari servendosi delle versioni
ad alto contrasto, oppure affidarsi ad uno screen reader.
L’avvento delle interfacce grafiche ha offerto una modalità di interazione più amichevole: le
operazioni avvengono attraverso la manipolazione di oggetti grafici di significato intuitivo. Ciò
comporta la necessità di una ristrutturazione dell’informazione per consentire l’accesso agli
utenti fruitori di screen reader e di una riorganizzazione della pagina, in modo che ciò che un
utente normale abbraccia con la vista in modo panoramico (il cosiddetto colpo d’occhio), possa
essere linearizzato e letto in modo sequenziale. Il grado di efficienza di uno screen reader
dipende dalla complessità della struttura dell’informazione presentata a video; esso però non
sempre riesce a riprodurre, in modo completo, una modalità di fruizione alternativa alle
interfacce utente. Per non escludere gli utenti affetti da daltonismo è sufficiente non veicolare le
informazioni unicamente attraverso l’uso del colore ed offrire un buon contrasto tra lo sfondo e
il primo piano. Gli utenti ipovedenti sono particolarmente svantaggiati dall’attuale panorama di
siti Internet, costruiti per lo più con criteri per loro assolutamente penalizzanti: combinazioni
7
testo-sfondo poco contrastate, immagini sotto il testo, caratteri troppo piccoli, uso eccessivo di
corsivi e di allineamenti insoliti, e così via. Rendere un sito accessibile ad un ipovedente è
un’attività complessa, a causa della molteplicità delle patologie esistenti. E’ però possibile
seguire alcune semplici regole per agevolare, anche questa categoria di utenti, nell’accesso e
nella fruizione delle informazioni. Pertanto si suggerisce di:
− utilizzare caratteri leggibili preferendo i font senza le c.d. “grazie” (es. “Arial” e
“Verdana”);
− aumentare il contrasto del testo, soprattutto se si inserisce uno sfondo alla
pagina;
− non ridurre eccessivamente gli spazi per il posizionamento dei link e degli
oggetti;
− rendere esplicite immagini e aree attive attraverso l’utilizzo del “tag” “alt”;
− posizionare in modo ravvicinato i “tag” nei “form” di compilazione per
agevolare l’orientamento di chi utilizza software di ingrandimento (es.
magnificatori di pagina).
− permettere la personalizzazione del sito.
Le difficoltà degli utenti con disabilità dell’udito (sordità parziale o completa) sono legate al
sempre maggiore utilizzo di componenti audio all’interno delle pagine Web. I file audio, che
fanno da corredo sonoro alla grafica, oppure le registrazioni – si pensi alla trasmissione delle
sedute del Consiglio comunale - possono diventare una barriera soprattutto se il contenuto audio
diventa una componente essenziale. Inoltre, per i non udenti congeniti, vanno tenute presenti le
difficoltà di apprendimento del linguaggio e la conseguente difficoltà di comprensione di un
testo scritto, soprattutto se è molto elaborato o se tratta di argomenti astratti. Pertanto è
necessario prevedere una serie di accorgimenti:
• sottotitolare i filmati, accompagnarli o sostituirli con segnalazioni visive quando i suoni
veicolano importanti informazioni;
• usare un linguaggio semplice, concreto e chiaro, soprattutto nelle forme di interazione con una
procedura, in modo che le azioni da compiere e i risultati raggiunti siano immediatamente
compresi senza fraintendimenti.
Fino ad ora si è dato per scontato che la versione “solo testo”, preparata per gli utenti non
vedenti, agevolasse anche gli utenti non udenti. In realtà non è così per le ragioni esposte e, in
qualche caso, vale addirittura il contrario: una persona sorda riesce a comprendere meglio
attraverso le immagini che non attraverso la lettura di un testo.
Le disabilità di tipo fisico sono piuttosto numerose: da una modesta paralisi di un arto,
all’incapacità di controllare i propri movimenti a causa di spasmi nervosi, sino ad una mobilità
quasi nulla che consente l’interazione con un sistema solo attraverso un comando d’assenso,
quale, ad esempio, il battito dell’occhio o il soffio in una cannuccia per la selezione dell’azione
proposta. In tutti questi casi la difficoltà di accesso si presenta per ciò che riguarda i dispositivi
di input dei comandi da parte dell’utente (es. compilazione di moduli).
Le persone disabili motorie possono comunque accedere ai siti e ai servizi Web attraverso
particolari supporti tecnologici e soluzioni specifiche. Di seguito vengono riportati alcuni dei
supporti possibili:
− tastiere dalle dimensioni ingrandite e con accorgimenti per evitare la pressione
accidentale di tasti;
− emulatori di mouse che consentono l’azione attraverso micro-movimenti;
− emulazione di tastiera per coloro che possono interagire soltanto attraverso
comandi sì/no;
− algoritmi di previsione che riducono il campo di scelta in funzione dei caratteri
già selezionati. Ad esempio, dopo la stringa “pr” il carattere successivo sarà
sicuramente una vocale e dopo “semplicem”, quasi sicuramente il resto della
parola sarà “ente”;
8
−
linguaggi iconici o ideografici che permettono di selezionare intere parole o
concetti con una singola azione.
L’utente affetto da disabilità cognitiva a comprendere pagine Web con una struttura molto
complessa o in cui siano presenti immagini in movimento troppo veloci. Le sue capacità di
attenzione e concentrazione potrebbero non consentirgli di cogliere a fondo tutti gli aspetti
dell’informazione presente nella pagina. Occorre pertanto evitare di sovraccaricare la pagina di
contenuti e di ricorrere ad elementi in movimento o lampeggianti per attirare l’attenzione.
Per ulteriori approfondimenti si rimanda all’allegato 1 –Legge Stanca
9
C. W3C
Il World Wide Web Consortium (W3C)1 è il consorzio che si occupa di individuare e
promuovere le direttive per lo sviluppo del Web. Sviluppa tecnologie che garantiscono
l’interoperabilità (specifiche, guidelines, software e applicazioni) per guidare il Web ad
esprimere il massimo del suo potenziale agendo come forum di informazioni, comunicazioni e
attività comuni.
Nel 1996 il W3C ha promosso l’iniziativa WAI (Web Accessibility Initiative) che ha come
obiettivi la definizione e la diffusione dei principi dell’accessibilità e la determinazione delle
linee guida da seguire in fase di progettazione e sviluppo di un sito Web. Ogni linea guida si
suddivide in più punti di controllo che fanno riferimento a differenti livelli di priorità e
conseguentemente di conformità.
Attualmente, le direttive relative ai contenuti Web (WCAG) sono in fase di revisione. La
seconda versione della raccomandazione del W3C raggruppa le caratteristiche di un sito Web
accessibile attorno a quattro principi guida (“percepibile”, “operabile”, “comprensibile”,
“resistente”). Osservatori esterni hanno rilevato che le specifiche delle WCAG 2.0 spostano la
descrizione dell’accessibilità ad un grado più astratto e universale. Sarà importante, da parte
della comunità dei progettisti e degli sviluppatori, fornire indicazioni su come passare dai
principi teorici alla pratica quotidiana dello sviluppo Web. Si tratta, infatti, di una traduzione
cruciale per giungere ad una vera e matura applicazione dell’accessibilità dei siti Internet. Si
presentano nel seguito i livelli di priorità individuati nella prima versione delle linee guida ed
una serie di suggerimenti che si dovrebbero sempre tenere presenti quando si affronta un
qualsivoglia progetto Web.
Priorità 1:
Lo sviluppatore di contenuti Web deve conformarsi alle indicazioni relative al presente punto di
controllo. In caso contrario, una o più categorie di utenti viene esclusa dall’accesso alle
informazioni presenti nelle pagine. La conformità a questo punto di controllo costituisce un
requisito base affinché alcune categorie di utenti siano in grado di utilizzare documenti Web.
Priorità 2:
Lo sviluppatore dovrebbe conformarsi a questo punto di controllo. In caso contrario
a una o più categorie di utenti risulterà difficile accedere ai contenuti.
Conformandosi a questo punto di controllo si rimuovono significative barriere per l’accesso
ai documenti.
Priorità 3:
Lo sviluppatore può rispettare anche questo punto di controllo: così facendo viene migliorato
l’accesso ai documenti. Nel caso in cui non dovessero essere rispettate le linee guida relative a
questo punto, qualche categoria di utenti potrebbe essere ostacolata nell’accesso ai contenuti.
Rispettando le priorità indicate si ottengono differenti livelli di conformità:
• A: conforme a tutti i punti di priorità 1;
• AA (doppia A): conforme a tutti i punti di controllo delle priorità 1 e 2;
• AAA (tripla A): conforme a tutti i controlli relativi alle priorità 1, 2 e 3.
Per ulteriori approfondimenti si rimanda a www.w3c.org
10
D. PROTOCOLLO INFORMATICO
La Pubblica Amministrazione è una complessa macchina che consuma e produce un’enorme
quantità di informazioni. Tali informazioni si materializzano sotto forma di documenti che
hanno varia natura sia per ciò che concerne i contenuti (per esempio l’ordine di trasferimento di
un impiegato o la cartella esattoriale inviata ad un contribuente non in regola) che la loro
struttura fisica (per esempio un messaggio di posta elettronica o una classica lettera su carta).
I documenti vengono prodotti, utilizzati, comunicati e mantenuti nell'esercizio delle attività
amministrative che ogni P.A. svolge per il raggiungimento degli obiettivi stabiliti nel proprio
mandato istituzionale. Tali attività sono articolate per processi o, in alcuni casi, per veri e propri
"procedimenti amministrativi", caratterizzati da sequenze di atti governate da regole e procedure
più o meno complesse a seconda dello scopo e contesto del processo considerato. L'attività di
protocollo è quella fase del processo che certifica provenienza e data certa di acquisizione del
documento, mediante la sua identificazione univoca nell'ambito di una sequenza numerica
collegata con l'indicazione temporale. La registrazione di protocollo svolge, quindi, un ruolo
essenziale nella gestione dei procedimenti prevista ai sensi della legge 241/1990 e, più in
generale, in tutti i processi amministrativi che prevedono fasi di attività e termini certi per la
loro conclusione.
Un processo amministrativo può essere supportato da strumenti informatici che siano in grado
di facilitare e, laddove possibile, automatizzare le attività previste. Le tecnologie disponibili per
queste scopo sono molteplici e sono spesso identificate con l’espressione “sistemi di supporto al
lavoro cooperativo” (CSCW, Computer Supported Cooperative Work). Tali sistemi sono poi
spesso raggruppati in due grandi famiglie di prodotti: i “workflow management systems”
(WFMS) e i “sistemi di groupware”.
Sono inoltre disponibili anche per le attività di protocollazione supporti informatici in grado di
creare e gestire il protocollo informatico, cioè l’insieme delle registrazioni che vengono
effettuate ogni qual volta un documento venga ricevuto o prodotto. Tali sistemi possono essere
modularmente integrati in un sistema vero e proprio di supporto al lavoro cooperativo, oppure
includere essi stessi alcune forme di minime supporto ai processi e ai flussi amministrativi.
Il legislatore italiano si è ripetutamente occupato della gestione elettronica dei flussi
documentali e del protocollo informatico. Al riguardo il quadro normativo vigente in materia si
può così sintetizzare:
1. l’articolo 15, comma 2, della legge 15 marzo 1997, n. 59, che prevede che gli atti, dati e
documenti, formati dalla pubblica amministrazione e dai privati con strumenti
informatici e telematici, i contratti stipulati nelle medesime forme nonché la loro
archiviazione e trasmissione con strumenti informatici, sono validi e rilevanti a tutti gli
effetti di legge;
2. il decreto del Presidente della Repubblica 10 novembre 1997, n. 513, “Regolamento
recante criteri e modalità per la formazione, l’archiviazione e la trasmissione di
documenti con strumenti informatici e telematici, a norma dell’articolo 15, comma 2,
della legge 15 marzo 1997, n. 59”;
3. l’art. 4 della legge 16 giugno 1998, n.191, e il relativo regolamento emanato con dPR 8
marzo 1999, n.70, in materia di telelavoro nelle pubbliche amministrazioni;
4. la delibera dell’AIPA del 30 luglio 1998, n.24, che definisce le regole tecniche
sull’archiviazione ottica;
5. il decreto del Presidente della Repubblica 20 ottobre 1998, n. 428, recante
“Regolamento per la tenuta del protocollo amministrativo con procedura informatica”,
che fissa criteri e modalità per la gestione elettronica dei documenti, consente la
11
interoperabilità tra le amministrazioni pubbliche e l’accesso esterno al sistema
documentario, compatibilmente con le norme sulla tutela dei dati personali;
6. il decreto del Presidente del Consiglio dei ministri 8 febbraio 1999, recante le “Regole
tecniche per la formazione, la trasmissione, la conservazione, la duplicazione, la
riproduzione e la validazione, anche temporale, dei documenti informatici ai sensi
dell’articolo 3, comma 1, del decreto del Presidente della Repubblica 10 novembre
1997, n.513”;
7. la circolare dell’Autorità per l’informatica nella pubblica amministrazione (AIPA) 26
luglio 1999, n.22, che detta le modalità per presentare le domande di iscrizione
nell’elenco pubblico dei certificatori;
8. la Direttiva del Presidente del Consiglio dei Ministri 28 ottobre 1999 sulla gestione
informatica dei flussi documentali nelle pubbliche amministrazioni, che fornisce un
fondamentale stimolo alle amministrazioni nella concreta attuazione del quadro
normativo ora esistente, sollecitando un profondo cambiamento di tipo organizzativo e
culturale ancor prima che un aggiornamento di tipo tecnologico.
Il quadro normativo e tecnico viene completato - a norma dell'art. 4, comma 4, del dPR 20
ottobre 1998, n. 428 - con le regole e criteri relativi alle operazioni di registrazione di
protocollo. Tale provvedimento rappresenta l’elemento conclusivo del quadro normativo e
tecnico del nuovo sistema di gestione elettronica delle attività amministrative.
L’Autorità per l’Informatica della Pubblica Amministrazione (AIPA) nel settembre 2000 ha reso
disponibile le “Linee guida alla realizzazione dei sistemi di protocollo informatico e gestione
dei flussi documentali nelle pubbliche amministrazioni”.
Secondo tale documento uno dei primi obiettivi che ciascuna amministrazione si deve dare nel
definire un progetto di informatizzazione dei flussi documentali (rispondente ai principi ed i
requisiti fissati dal DPR 428/98) è quello di individuare il proprio “livello realizzativo”,
corrispondente alle funzionalità che essa stessa vuole realizzare (Figura 1).
1
2
3
Nucleo minimo protocollo
Gestione documentale
Workflow documentali
4
BPR
Figura 1 livelli realizzativi in un progetto di protocollo informatico e gestione dei
flussi documentali
In via indicativa, sono stati individuati quattro livelli di realizzazione del protocollo informatico
- e quindi quattro diverse tipologie di intervento:
1.
Nucleo minimo protocollo
2.
Gestione documentale
12
3.
4.
Workflow documentali
BPR (Business Process Reengineering)
Per nucleo minimo di protocollo si intende la gestione informatica dei documenti in modalità
base. Esso è caratterizzato dalla realizzazione delle seguenti attività:
- registrazione in un archivio informatico delle informazioni riguardanti un documento
(numero, data, mittente/destinatario, oggetto, ecc.);
- segnatura sul documento delle informazioni riguardanti il documento stesso (numero, data,
AOO);
- classificazione d’archivio per una corretta organizzazione dei documenti, corrispondenti
alle funzionalità minime previste dall’art. 7 del DPR 428/98, alle quali può eventualmente
essere aggiunta anche la indicazione dell’assegnatario sul registro di protocollo.
Limitarsi a questo livello di realizzazione significa:
- circoscrivere l’obiettivo dell’intervento alla registrazione dei documenti e alla loro
organizzazione nel sistema documentario;
- prendere in considerazione solamente i documenti protocollati;
- coinvolgere nel processo di informatizzazione esclusivamente l’Ufficio Protocollo;
- consentire l’accesso in via informatica alle informazioni relative ai documenti, ma non ai
documenti stessi.
Per gestione documentale si intende la gestione informatica dei documenti in modalità
avanzata. E’ stata così denominata perché si tratta di una soluzione che privilegia ed esalta
essenzialmente le potenzialità legate alla gestione informatizzata dei documenti e degli archivi.
Essa consiste in realtà in una macro-categoria che ricomprende attività assai eterogenee, che
variano a seconda del grado di funzionalità che si desideri attuare, ma che trovano una logica
ben precisa per il loro accorpamento: ovvero il loro comune presupposto fondamentale, che è
quello della dematerializzazione dei documenti cartacei e quindi della disponibilità degli stessi
a livello informatico.
Essa prevede le seguenti attività:
- registrazione con trattamento delle immagini (scannerizzazione dei documenti cartacei);
- assegnazione per via telematica al destinatario;
- gestione avanzata della classificazione dei documenti (utilizzo di thesauri e vocabolari
controllati, ecc.);
- collegamento dei documenti alla gestione dei procedimenti.
A queste può aggiungersi la:
- realizzazione di un repository documentale per quei documenti di alto contenuto
informativo che meritano uno specifico trattamento (prevedendo ad esempio la creazione
di abstract, l'uso di parole chiave per una indicizzazione più dettagliata, ecc.) che può
assumere la forma di una pubblicazione sul web, che si può considerare la forma
attualmente più evoluta nel processo di creazione di un patrimonio informativo globale.
Procedere a questo livello di realizzazione significa, in linea di massima (considerando il
grande range di alternative attuabili):
- privilegiare l’obiettivo della creazione di patrimonio informativo;
- prendere in considerazione tutti i documenti, non solamente quelli protocollati;
- coinvolgere nel processo di informatizzazione tutti gli uffici, almeno in parte;
- consentire l’accesso in via informatica direttamente ai documenti.
Nella categoria dei Workflow documentali
si ricomprendono quelle attività di
razionalizzazione (e conseguente informatizzazione mediante workflow) esclusivamente dei
processi documentali di una Amministrazione, escludendo quindi quelli primari. Ciò non
significa che non si avranno comunque benefici su tutta l’organizzazione, ma solo in via
indiretta, agendo sui flussi documentali. In altre parole, in tale caso si decide di non entrare nel
merito delle procedure interne. Potrebbe anche essere il caso, ad esempio, di quelle
Amministrazioni che hanno già provveduto ad effettuare razionalizzazioni organizzative.
13
Essa prevede una o più delle seguenti attività:
- informatizzazione dei processi relativi ai flussi documentali in entrata;
- informatizzazione dei processi relativi ai flussi documentali in uscita;
- informatizzazione dei processi relativi ai flussi documentali interni;
- integrazione con gli eventuali workflow relativi ai processi primari.
Procedere a questo livello di realizzazione significa, in linea generale (considerando il range di
alternative attuabili):
- privilegiare l’obiettivo della razionalizzazione ed informatizzazione dei flussi documentali;
- prendere in considerazione tutti i documenti, anche quelli relativi agli iter di processo;
- coinvolgere nel processo di informatizzazione tutti gli uffici;
- consentire l’accesso in via informatica agli iter di processo.
Il BPR (Business Process Reengeneering) è quella categoria che prevede la
reingegnerizzazione dei processi dell’ente al fine di una loro successiva informatizzazione: in
particolare vengono gestiti mediante sistemi integrati di workflow tutti quei processi che
possiedono i requisiti di convenienza, ovvero la complessità, la ripetitività e la stabilità
dell’iter.
Il BPR rappresenta una scelta importante per molti motivi:
- assetto organizzativo e qualità;
- pianificazione strategica;
- controllo di gestione;
- monitoraggio dei costi e tempi.
Il BPR incide profondamente nell’organizzazione della macchina amministrativa e pertanto
necessita di tempi di realizzazione medio-lunghi.
Come si può ben vedere, la scelta del tipo di intervento (nucleo minimo protocollo, gestione
documentale, workflow documentali, BPR ) non solo ha pesanti ricadute in termini di
complessità, di costi, di formazione, di ruoli coinvolti, ecc; ma ancora prima ha una specifica
valenza strategica nel momento in cui definisce e qualifica il progetto stesso:
Questa classificazione, a carattere ovviamente indicativo, deve essere letta con cautela. E’
molto probabile, ad esempio, che nel momento in cui si decida di arrivare alla
informatizzazione dei processi documentali, si sia già provveduto – o si intenda provvedere
contestualmente – all’attivazione della gestione documentale, avviando dapprima l’analisi
organizzativa e in seguito lo studio del sistema informativo a supporto della razionalizzazione
perseguita.
Per quanto concerne l’architettura informatica da adottare c’è innanzitutto da distinguere tra il
caso di realizzazione minima del sistema di protocollo informatico (ossia la esclusiva
realizzazione delle essenziali funzioni di registrazione e classificazione previste dal DPR
428/98) e realizzazione di funzioni più avanzate funzionali alla automazione dei flussi
documentali delle amministrazioni. La realizzazione del solo “nucleo minimo” rappresenta una
posizione nella quale il sistema di protocollo informatico può essere l’unico sistema
automatizzato dell’area organizzativa omogenea che tratti in modo strutturato informazioni su
documenti. In questo scenario è probabile che non esistano altri strumenti automatizzati, al di
fuori del registro di protocollo e del sistema di classificazione (o eventuali strumenti di office
automation), per trattare informazioni correlate alla gestione documentale (come, ad esempio,
procedimenti e loro iter, oppure il funzionario responsabile, l’assegnatario, le scadenze ecc.).
Questo scenario è ipotizzabile nei casi in cui l’amministrazione tratti un volume estremamente
basso di documenti, e quindi non sussistono le condizioni per rendere economicamente
conveniente l’utilizzo di ulteriori strumenti informatici, oppure nel caso in cui ci siano vincoli
sul grado di informatizzazione o il livello culturale informatico del personale.
Mentre l’ultimo caso è auspicabilmente da superare, non è da considerarsi come condizione
negativa la rinuncia all’utilizzo di ulteriori strumenti informatici per la gestione di
informazioni sui documenti nel caso in cui il volume dei documenti trattati sia basso (ad
esempio, non è detto che nel caso di un comune con 500 abitanti debba necessariamente avere
14
un sistema di workflow per tenere traccia dello stato delle poche pratiche che il comune tratta
ogni anno).
Se la scelta dell’amministrazione è di realizzare funzioni e servizi aggiuntivi rispetto al solo
nucleo minimo si presentano diversi scenari e possibilità architetturali:
- soluzione monolitica;
- soluzione modulare;
- soluzione intermedia.
Un tipico scenario di soluzione monolitica è quello in cui il sistema di protocollo venga
realizzato fin dall’inizio come un sistema in grado di gestire, oltre ai dati necessari alla tenuta
del registro di protocollo, anche tipi di informazioni legati al trattamento dei processi svolti
all’amministrazione, come “l’assegnatario della pratica”, “il fascicolo” o “il procedimento
amministrativo”. In molti casi le amministrazioni adottano la soluzione di sviluppare una
applicazione “ad hoc”, monolitica, incentrata sul registro di protocollo, ma in grado di gestire
un po’ di tutto: il tracciamento delle pratiche attraverso forme più o meno sofisticate di
workflow, alcune informazioni relative al controllo di gestione, una base dati documentale
(usualmente limitata ai documenti protocollati con varie possibilità di accesso e ricerca).
Tipicamente all’interno di applicazioni di questo tipo si fa riferimento alle informazioni sulla
struttura organizzativa dell’amministrazione, cioè dipendenti, ruoli, uffici unità organizzative
ecc. Quindi all’interno dell’applicazione di protocollo si viene a creare una base dati (parziale
o totale, bene aggiornata o male aggiornata) della struttura organizzativa. Inoltre nella
applicazione si viene spesso a creare un elenco di corrispondenti, cioè una base dati di soggetti
contenente nomi, indirizzi ed altre informazioni, che interagiscono a vario titolo con
l’amministrazione. Sia nel caso della struttura organizzativa e dei corrispondenti esterni, ma
anche dei documenti, ci si trova di fronte ad una applicazione, cosiddetta di protocollo, ma che
in realtà “invade” altri campi, cioè gestisce informazioni che rappresentano il patrimonio
informativo dell’amministrazione indipendentemente dal fatto che siano collocate in un
contesto di gestione documentale. In alcune realtà tale tipo di soluzione potrebbe ancora
risultare conveniente. Laddove, ad esempio, la amministrazione sia caratterizzata da una forte
staticità (procedimenti ben identificati con iter stabili, carichi di lavoro prevedibili ecc.) allora
potrebbe aver senso costruire una applicazione monolitica perfettamente ritagliata su tali
esigenze che, per definizione, non variano. In generate, tuttavia, una soluzione di tipo
monolitico rappresenta una legacy che impedisce un facile adattamento del sistema di gestione
documentale alla variazione delle esigenze dell’amministrazione ed alla evoluzione delle
tecnologie e dell’offerta del mercato informatico.
Un ulteriore scenario, che rappresenta il modello più evoluto, è quello della soluzione
modulare in cui il nucleo minimo del protocollo sia visto come un modulo applicativo,
esclusivamente dedicato al servizio di certificazione, con tutte le caratteristiche previste dal
DPR 428/98 e dalle successive regole tecniche. Il modulo di protocollo, piuttosto che fornire
direttamente all’utente le funzioni di certificazione previste, sarà accessibile da parte di altre
applicazioni, o componenti, che costituiscono il sistema informatico dell’amministrazione. In
altre parole, il servizio di protocollo è un servizio richiamabile da altre parti (e quindi
integrabile nei più vari contesti applicativi).
Nel contesto architetturale che si viene a delineare, oltre al servizio di certificazione di
protocollo, dovrebbero essere messi a disposizione, centralmente a tutti i potenziali utilizzatori,
altri servizi che costituiscono il patrimonio comune dell’amministrazione, secondo criteri
opportuni di visibilità e sicurezza.
Infine occorre tenere conto di possibili soluzioni intermedie. Ogni forma intermedia di
configurazione tra lo scenario monolitico e quello modulare è ovviamente possibile, anzi è
probabile che la maggioranza delle applicazioni esistenti ricada in questa categoria. A meno di
applicazioni monolitiche basate su tecnologie proprietarie (ad esempio sistemi basati su
mainframe) ogni soluzione che comporti l’uso di tecnologie di supporto aperte di tipo
15
client/server, facenti uso di strumenti ed ambienti di mercato, offre una qualche forma di
modularità e di accessibilità.
La soluzione più ricorrente è quella di incentrare il sistema di gestione del protocollo e delle
pratiche su un database e offrire a vari profili client la possibilità di attivare diverse operazioni
sul sistema. Su questi sistemi è possibile operare degli interventi tesi ad incrementare la
modularità e l’indipendenza tra i vari componenti, fino ad arrivare ad una eventuale
sostituzione di alcune funzioni. Le tecniche di wrapping e l’utilizzo di middleware specifico
possono risultare di ausilio a queste iniziative di riconversione.
Stabilire se è conveniente per una amministrazione avviare un programma di
“modularizzazione” di un sistema di gestione documentale e di protocollo informatico è
comunque una decisione che dovrà scaturire da una attenta valutazione dei costi e dei benefici
dell’operazione.
Per ulteriori approfondimenti si rimanda all’allegato 2–Linee Guida per l’adozione del
Protocollo Informatico
16
E. INDICE DELLA PUBBLICA AMMINISTRAZIONE E POSTA CERTIFICATA
Il D.P.C.M. del 31 ottobre 2000 istituisce l’Indice delle amministrazioni pubbliche e delle Aree
Organizzative Omogenee, accessibile per via telematica, come supporto all’interoperabilità dei
sistemi di protocollo informatico, specificando al contempo le informazioni minime che devono
essere contenute nell’Indice e le modalità d’accesso e di gestione delle stesse, nonché che la
realizzazione e la responsabilità del funzionamento dell’Indice della P.A. (IPA) sono affidate
al CNIPA.
Da un punto di vista informativo, l’IPA può essere considerato composto di due indici logici
distinti:
1. l’indice delle unità organizzative (IUO), contenente le informazioni relative la struttura
organizzativa delle amministrazioni accreditate presso l’indice; tale indice descrive la
struttura organizzativa di ciascuna amministrazione in termini di unità organizzative e
della relativa struttura gerarchica. Esso contiene, per ciascuna unità organizzativa, le
informazioni riguardanti la sede o le sedi e la loro denominazione ed indirizzo postale,
unitamente alle modalità di accesso telematico ad eventuali servizi applicativi on-line
resi disponibili e gli indirizzi delle caselle di posta elettronica, eventualmente afferenti
ad un sistema di Posta Elettronica Certificata.
2. l’indice delle Aree Organizzative Omogenee1 (IAOO), organizzato per amministrazioni
e contenente le informazioni sulla composizione delle relative AOO. L’IAOO contiene
la descrizione dei dati tecnici e di tutte le informazioni rilevanti che caratterizzano
l’accesso telematico ad ogni AOO e, in particolare, per lo scambio di messaggi di posta
elettronica verso le relative caselle di posta istituzionali, afferenti ad un sistema di Posta
Elettronica Certificata. In esso le AOO sono organizzate in base alle amministrazioni di
appartenenza e contengono l’indicazione delle unità organizzative utenti per le quali
sono riferimento, descrivendo, di fatto, una partizione dell’insieme delle UO
dell’amministrazione.
La Posta Elettronica Certificata (PEC) è un servizio di messaggistica che, attraverso l’utilizzo
degli standard riguardanti la posta elettronica, è in grado di fornire attestazioni di recapito con
garanzia di identificazione del mittente e del destinatario. Il servizio comprende ulteriori
funzionalità accessorie per garantire la confidenzialità, l’integrità, il non ripudio, la tracciabilità
e la storicizzazione del flusso dei messaggi.
Le attestazioni o ricevute di recapito sono messaggi di posta elettronica, generati
automaticamente dal servizio di Posta Elettronica Certificata, utilizzati per attestare le fasi della
trasmissione. Tali ricevute, firmate elettronicamente dal sistema emittente, contengono una serie
di informazioni che caratterizzano l’evento cui sono associate, quali data e ora, mittente,
destinatario, oggetto etc.
Il servizio di PEC consentirà alla Pubblica Amministrazione centrale di disporre di
un’infrastruttura di posta elettronica in linea con la normativa vigente in tema di trasmissione
documentale (DPR 445/2000) e di avviare la gestione elettronica dei flussi documentali.
L’utilizzo delle caselle di PEC implica l’abilitazione al transito dei protocolli POP3, IMAP4,
SMTP e HTTPS, necessari per l’accesso alle stesse, da e verso i sistemi che erogano il servizio
di PEC, operanti presso il Centro di Gestione dei servizi di Interoperabilità (CG-I) della RUPA.
Il servizio di PEC è strettamente correlato all’IPA, che ne costituisce un prerequisito funzionale,
poiché in esso sono pubblicati gli indirizzi di Posta Elettronica Certificata associati alle A.O.O.
ed alle funzioni organizzative eventualmente previste dalle amministrazioni.
Per l’avvio dei servizi di IPA e PEC, le amministrazioni interessate devono mettere in atto una
serie d’azioni, sia di carattere organizzativo che tecnologico, al fine di permettere l’utilizzo
degli stessi per la gestione e lo scambio di documenti elettronici, anche attraverso sistemi di
protocollo informatico.
17
Il processo di gestione dei servizi vede coinvolti più attori con ruoli diversi in funzione delle
specifiche attività svolte, quali:
− consultazione delle informazioni contenute nell’IPA;
− accreditamento di una PA presso l’Indice PA e presso il servizio di Posta
Elettronica Certificata;
− aggiornamento dei dati AOO e UO pubblicati nell’IPA;
− accesso ai dati storici relativi all’IPA.
Nell’ambito di tali attività alle amministrazioni spetta l’individuazione delle figure che
ricopriranno i seguenti ruoli e l’attribuzione alle stesse delle relative responsabilità:
− Referente Amministrazione: referente unico per entrambi i servizi,
individuato dall'amministrazione in fase di accreditamento; tale figura è
responsabile della comunicazione al Gestore/Fornitore dell’IPA, nei formati
previsti, di tutte le informazioni relative ad iscrizione e cancellazione delle
AOO ed alle modifiche nella struttura delle UO, comprese tutte le informazioni
relative la Posta Elettronica Certificata.
− Utente: generico utente che accede all’IPA per la consultazione delle
informazioni ivi pubblicate, o un utente di PEC che attraverso account
opportunamente abilitati e secondo le modalità previste accede alla propria
casella di posta.
Completano l’elenco le seguenti figure di coordinamento, esterne alle amministrazioni:
− Responsabile IPA e PEC: supervisiona e coordina lo sviluppo e la gestione dei
servizi di IPA e PEC, garantendo la coerenza del processo d’accreditamento di
una amministrazione presso l’Indice e dei processi di comunicazione fra le PA
ed il Gestore/Fornitore dell’IPA e della PEC. Tale funzione sarà ricoperta dal
CNIPA, anche secondo quanto previsto dal DPCM 31/10/2000;
− Gestore/Fornitore: garantisce la rispondenza dei dati forniti dalle PA con i dati
effettivamente pubblicati nell’IPA; è responsabile di tutte le operazioni di
gestione, manutenzione e pubblicazione dei dati forniti. È responsabile della
creazione e gestione delle caselle di PEC secondo le informazioni fornite dalle
PA. Tale funzione sarà svolta dalla società EDS Pubblica Amministrazione
SpA,. fornitrice dei servizi.
Per ulteriori approfondimenti si rimanda all’allegato 3 –Guida ai servizi di Indice delle
Amministrazioni Pubbliche e delle Aree Organizzative Omogenee e Posta Elettronica
Certificata
18
F. FIRMA ELETTRONICA
La firma digitale è una informazione che viene aggiunta ad un documento informatico al fine di
garantirne integrità e provenienza. Sebbene l’uso per la sottoscrizione dei documenti formati su
supporti informatici sia quello più naturale, essa può essere utilizzata per autenticare una
qualunque sequenza di simboli binari, indipendentemente dal loro significato. Un esempio
sempre più comune di questo uso generalizzato è l’aggiunta di firme digitali ai file contenuti
nella memoria di massa di un sistema di elaborazione onde contrastare gli attacchi dei virus e
degli hacker.
La principale differenza tra firma autografa e firma digitale sta nel fatto che la prima è
direttamente riconducibile all’identità di colui che la appone, poiché la calligrafia è un elemento
identificativo della persona, mentre la seconda non possiede questa proprietà. Per coprire questa
deficienza si ricorre all’autorità di certificazione, il cui compito è quello stabilire, garantire e
pubblicare l’associazione tra firma digitale e soggetto sottoscrittore.
Per contro, mentre l’associazione tra testo di un documento e la firma autografa è ottenuta
esclusivamente attraverso il supporto cartaceo, la firma digitale è intrinsecamente legata ad testo
a cui è apposta, tanto che i due oggetti possono essere fisicamente separati senza che per questo
venga meno il legame esistente tra loro.
Conseguenza di ciò è l’unicità della firma digitale, nel senso che a testi diversi corrispondono
firme diverse e quindi, nonostante la sua perfetta replicabilità, è impossibile trasferirla da un
documento ad un altro.
Per ulteriori approfondimenti si rimanda all’allegato 4 – Firma elettronica: tecnologie e
standard
19
G. INTEROPERABILITÀ E COOPERAIONE APPLICATIVA
Molti servizi pubblici, per poter essere forniti, richiedono l’interazione e la cooperazione di
diverse pubbliche amministrazioni, attuate attraverso la definizione di un procedimento
cooperativo multiente. Il livello di integrazione fra gli attori che partecipano al procedimento
multiente è spesso insufficiente, lasciando al cittadino o all’impresa utente del servizio il
compito di farsi carico della integrazione delle diverse amministrazioni. Quindi, per migliorare
la qualità dei servizi multi-ente, è necessario rendere effettiva la possibilità di integrare i
processi di backoffice delle amministrazioni coinvolte nel servizio.
In tale ottica occorre che il processo di innovazione ed integrazione dei backoffice non risponda
solo agli obiettivi di miglioramento dell’efficienza interna delle Amministrazioni, ma abbia il
compito primario di migliorare l’offerta e la qualità dei servizi offerti ai cittadini, alle imprese o
alle altre Amministrazioni utenti del servizio. E’ necessario che le amministrazioni centrali e
periferiche forniscano agli altri soggetti pubblici, secondo modalità predefinite, l’accesso alle
informazioni di competenza, attraverso servizi con cui operare l’interscambio dei dati per
attuare i processi di cooperazione.
Presso il CNIPA è stato istituito un apposito gruppo di lavoro che si è posto l’obiettivo di
definire il modello, l’architettura e le regole per l’interoperabilità evoluta, la cooperazione e
l’accesso ai servizi applicativi erogati dalle amministrazioni pubbliche nell’ambito del Sistema
Pubblico di Connettività, portanto alla definizione:
• dell’architettura, in termini di servizi infrastrutturali comuni e delle modalità di
interazione fra i componenti
• dell’organizzazione e delle regole di gestione e governo del sistema
• degli standard e tecnologie da adottare
Attualmente il CNIPA è impegnato nella redazione di tali ulteriori documenti e nella
predisposizione di alcune prove - relativamente alla porta di dominio e alla struttura di registri utili per la definizione dei capitolati per la realizzazione dell'infrastruttura generale di
cooperazione applicativa e per la qualificazione dei servizi. Tali attività termineranno, con i
contributi alla revisione dei documenti da parte dei soggetti coinvolti (PAC, PAL, Associazioni
di fornitori), presumibilmente entro marzo 2005.
In linea con le attuali esigenze dell’Amministrazione Regionale, deve essere posta specifica
attenzione alla realizzazione di infrastrutture di base per l’interoperabilità e la cooperazione
applicativa, con specifico ed esclusivo riferimento alla cooperazione tra sistemi di anagrafe,
coerentemente con i principi di cooperazione applicativa espressi a livello nazionale, nell’ottica
di una visione condivisa, e la condivisione del modello di funzionamento definito a livello
nazionale dai gruppi di lavoro del CNIPA, implementando operativamente funzionalità che
consentono ad applicativi di competenza dell’Amministrazione regionale che trattano i dati
anagrafici per le esigenze dell’Assessorato alla Sanità la comunicazione e la cooperazione,
anche se appartengono a domini diversi.
Per ulteriori approfondimenti si rimanda al sito www.cnipa.it, alla voce “Sistema Pubblico
di Connettività e Cooperazione (SPC)”
20
H. LA QUALITÀ DEI BENI E DEI SERVIZI ICT
Un apposito gruppo di lavoro del CNIPA ha realizzato le “Linee guida sulla qualità dei beni e
dei servizi ICT per la definizione ed il governo dei contratti della Pubblica Amministrazione"
Le Linee guida hanno lo scopo di definire:
• un quadro di riferimento complessivo per l’appalto pubblico di servizi ICT da parte
delle amministrazioni;
• metodi quantitativi da applicarsi per definire misure di qualità ed identificare processi di
misura, allo scopo di fornire indicazioni concrete, pragmatiche, immediatamente
applicabili, sia alle amministrazioni appaltanti che ai fornitori offerenti;
• adeguate clausole, da utilizzarsi in fase di negoziazione, per la definizione di capitolati e
contratti pubblici per la fornitura di beni e servizi nel settore ICT, relative alla
descrizione delle attività da prevedersi contrattualmente, ai prodotti che dette attività
realizzano, agli indicatori e misure di qualità da riferirsi sia alle attività che ai prodotti;
• clausole successivamente utili nella fase di attuazione dei contratti ICT, per la
necessaria azione di governo del contratto e lo svolgimento del monitoraggio per la
verifica del rispetto dei requisiti contrattuali in termini di tempi, costi e stato
avanzamento lavori, quantità e qualità attese dei servizi ICT richiesti.
Le Linee guida si rivolgono, simmetricamente, sia alle amministrazioni nel loro ruolo di stazioni
appaltanti di beni e servizi ICT, che ai fornitori che a questi appalti partecipano. La biunivocità
della relazione contrattuale porta inevitabilmente al risultato che una cosa suggerita a chi
appalta si rifletta su chi offre e viceversa. Le più moderne forme di esternalizzazione dei servizi
ICT (outsourcing) trasformano la relazione asimmetrica cliente – fornitore in più paritetiche
relazioni tra partner, enfatizzando ancora maggiormente la dualità della relazione contrattuale.
Dal punto di vista delle amministrazioni l’adozione delle Linee guida offre i seguenti vantaggi:
• accelera la definizione degli atti di gara ICT;
• omogeneizza gli atti di gara;
• integra le diverse culture necessarie alla acquisizione delle forniture ICT;
• permette di evidenziare e valorizzare le best practices.
Dal punto di vista dei fornitori le "Linee guida" descrivono un approccio alla acquisizione di
forniture ICT che:
• aumenta la trasparenza delle gare;
• riduce i possibili contenziosi tra fornitore e stazione appaltante;
• permette di dare il giusto valore alla qualità dei servizi ICT offerti dal fornitore;
• contrasta le logiche del ribasso di costo;
• migliora la descrizione dei servizi ICT richiesti;
• riduce i costi di predisposizione delle offerte.
Per la stesura delle Linee guida si è adottato un approccio caratterizzato da:
• Assunzione di punti di vista complementari per la definizione della qualità, il fruitore
del servizio (utente finale), l’amministrazione appaltante il servizio (stazione
appaltante), la qualità intrinseca del servizio;
• Considerazione dell’intero ciclo di vita inerente l’acquisizione di una fornitura ICT
(elaborazione delle strategie di acquisto, definizione delle modalità di appalto,
definizione del contratto);
• Considerazione di tutte le possibili dimensioni della qualità caratterizzanti prodotti e
servizi ICT nelle diverse fasi del ciclo di vita;
• Enfasi sulla concretezza attuata fornendo in termini pragmatici risposte a domande
operative;
• Eliminazione delle possibili ambiguità nell’adozione a livello contrattuale di livelli di
servizio e indicatori di qualità.
21
Le Linee guida sono strutturate secondo 6 documenti distinti, denominati “Manuali” e 35
"Lemmi" allegati al Manuale operativo "Dizionario delle Forniture ICT elementari".
.Manuale d’uso Presentazione e utilizzo delle Linee Guida
1. Manuale applicativo
Strategie di acquisizione delle forniture ICT
2. Manuale applicativo
Appalto pubblico di forniture ICT
3. Manuale operativo
Dizionario delle forniture ICT elementari
4. Manuale applicativo
Esempi di applicazione
5. Manuale di riferimento
Modelli per la qualità delle forniture ICT
Per ulteriori approfondimenti si rimanda all’allegato 5 – Linee Guida sulla qualità dei
beni e dei servizi ICT per la definizione ed il governo dei contratti della Pubblica
Amministrazione
22
I.
ADOZIONI INTERNAZIONALI
Il 22 settembre 2003 il Ministero della Giustizia e la Regione Siciliana – Assessorato della
Famiglia, delle politiche sociali e delle autonomie locali hanno sottoscritto un protocollo
d’intesa per l’implementazione del processo delle adozioni internazionali promossa dalla
Regione Siciliana, in rispetto al suolo affidato alle regioni dalla legge 476/98 ed in conformità al
Piano Socio-Sanitario regionale ex legge 328/2000.
Finalità ultima del progetto è da ricercarsi nella interconnessione telematica fra i tribunali per i
minorenni siciliani e gli organi degli enti locali che con detti uffici giudiziari interagiscono,
nell’ambito del procedimento di adozione internazionale, per rendere lo stesso più efficace.
L’architettura informatica è basata sulla definizione di uno strato logico ed operativo, chiamato
master data center (MDC) al servizio di tutti i soggetti che operano nel processo delle adozioni
internazionali sul territorio siciliano.
Funzionalmente il MDC può essere assimilato ad un Centro Servizi Territoriale tecnicamente
impostato su un sistema web based che si appoggia su standard XML.
Questo determina la possibilità da parte dei differenti attori coinvolti di condividere un
medesimo sistema informativo, minimizzando gli investimenti infrastrutturali e di manutenzione
evolutiva e aumentando la sicurezza del sistema.
I Comuni e Province non dovranno dotarsi di software alcuno ma soltanto prevedere per codesto
servizio la seguente dotazione:
J. Personal Computer
K. Stampante
L. Lettore di smart card
M. Connessione Internet
N. Smart CARD con firma digitale
O. Posta certificata
23
P. SERVIZI DI ANAGRAFE
Per quanto concerne i servizi di anagrafe, i comuni dovranno fornire il tracciato dei record del
data base dell’anagrafe in un formato che consenta l’interoperabilità dei dati (ad esempio XML).
I dati dovranno essere disponibili su un Server accessibile on line, tramite internet, ovvero in
modalità analoga (ad esempio web services) .
Il Data Base dovrà contenere i seguenti campi:
·
cognome
·
nome
·
sesso
·
data di nascita
·
stato civile
·
comune di nascita
·
codice ISTAT del comune di nascita
·
codice fiscale
·
comune di residenza
·
codice ISTAT del comune di residenza
·
indirizzo di residenza
·
numero civico di residenza
·
CAP di residenza
·
data ultima modifica residenza
·
comune di domicilio
·
codice ISTAT del comune domicilio
·
indirizzo di domicilio
·
numero civico di domicilio
·
CAP di domicilio
24
SEZIONE II - CRITERI DI AMMISSIBILITA’ DEI COSTI
Le presenti disposizioni integrano e non sostituiscono le vigenti norme nazionali e comunitarie
dalle quali discendono le regole cui deve conformarsi l’attuazione delle operazioni di cui trattasi
e per le quali si rimanda alla Sezione I – Normativa di riferimento.
Per quanto non espressamente trattato si fa specifico riferimento al Regolamento (CE) N.
1685/2000 della Commissione, del 28 luglio 2000 recante disposizioni di applicazione del
Regolamento (CE) N. 1260/1999 del Consiglio concernente l’ammissibilità delle spese delle
operazioni cofinanziate dai Fondi strutturali.
In linea generale un costo è ammissibile se:
L’oggetto a cui il costo è riferito non ha già fruito di un contributo pubblico comunitario,
nazionale o regionale;
la spesa è stata effettivamente sostenuta dal soggetto che rendiconta e corrisponde a
pagamenti effettivamente eseguiti ai sensi della norma n. 1 del Reg(CE)1685/2000
la spesa è stata sostenuta entro i termini di eleggibilità.
il costo figura nelle tipologie ammesse nei bandi, avvisi o dispositivi contrattuali che
regolano il rapporto fra il Dipartimento Bilancio e Tesoro ed il soggetto che rendiconta,
quali la presente Guida.
Per la verifica dell’ammissibilità di un costo sono adottati i seguenti criteri:
Criterio della pertinenza
I costi ammissibili devono essere strettamente connessi all’operazione approvata. L’inerenza del
costo al progetto va riscontrata rispetto alla natura, e alla destinazione fisica del bene o servizio.
Le spese effettivamente sostenute devono derivare da impegni giuridicamente vincolanti
(contratti, lettere di incarico, ordinativi, ecc.) da cui risulti chiaramente l’oggetto della
prestazione o fornitura, il suo importo, la sua pertinenza al progetto, i termini di consegna.
Criterio della congruità
Non vengono riconosciuti costi eccessivamente elevati, superflui o imputabili ad inadempimenti
del soggetto che rendiconta (ad esempio penali od ammende). Un costo si considera
eccessivamente elevato quando a insindacabile giudizio del Dipartimento Bilancio e Tesoro si
discosta in maniera sensibile dal costo medio di mercato del bene o servizio acquisito per gli
stessi scopi nello stesso periodo di tempo. Il costo è superfluo quando, ancorché correlabile al
progetto, può essere evitato.
A supporto delle verifiche di congruità il Dipartimento Bilancio e Tesoro fornisce specifiche
indicazioni in merito al costo medio unitario di riferimento o imporre massimali nel rispetto
dell’art.56 della LR 10/99.
Inoltre quale strumento di verifica della congruità del costo del bene o della prestazione
il
Dipartimento Bilancio e Tesoro esamina le procedure utilizzate per la selezione del fornitore
del bene o del prestatore d’opera o di servizio che, devono conformarsi alla vigente normativa
comunitaria o nazionale in termini di Appalti o affidamento di incarichi professionali, nonché
riferirsi a puntuali ricognizioni di mercato, quali l’esame di un numero minimo di cinque
preventivi.
25
Criterio della coerenza
L’ammissibilità dei costi viene valutata anche secondo il criterio di coerenza interna e contabile
relativamente alle attività svolte ed alla rendicontazione di spesa esposta.
Criterio del costo netto
In ogni caso il costo riconoscibile si ottiene sottraendo dalla somma delle spese accertate
eventuali detrazioni di spesa o ricavi.
Criterio di inammissibilità legato alla tipologia del costo
Per loro stessa natura, ed indipendentemente dalla loro legittimità o pertinenza, non sono,
comunque, ammissibili i seguenti costi:
oneri finanziari: gli interessi debitori, gli aggi, le spese e le perdite di cambio ed altri oneri
meramente finanziari (norma 3.1 del Reg. 1685/2000);
ammende, penali e spese per controversie legali (norma 3.5 del Reg.1685/2000);
altre imposte, tasse o oneri: in particolare le imposte dirette e i contributi per la sicurezza
sociale su stipendi e salari non costituiscono spesa ammissibile tranne quando sono
effettivamente e definitivamente sostenuti dal beneficiario finale o dal singolo destinatario
(norma 7.4 del Reg. 1685/2000);
spese di rappresentanza: tese a promuovere l'immagine del contraente, soprattutto presso
fornitori o partner negli affari. Sono considerate spese di rappresentanza anche cessioni a
titolo gratuito di beni o servizi a detti soggetti;
Criterio di ammissibilità dell’IVA
A riguardo dell’ammissibilità dell’IVA si riporta il contenuto della norma n. 7 “IVA e altre
imposte e tasse “ di cui al regolamento 1685/2000 della Commissione Europea:
1. L’IVA può costituire una spesa ammissibile solo se è realmente e definitivamente sostenuta
dal beneficiario finale, oppure dal singolo destinatario nell’ambito dei regimi di aiuto ai
sensi dell’articolo 87 del trattato, e nel caso di aiuti concessi dagli organismi designati dagli
Stati. L’IVA che può essere in qualche modo recuperata, non può essere considerata
ammissibile anche se non è effettivamente recuperata dal beneficiario finale o dal singolo
destinatario
2. Quando il beneficiario finale o il singolo destinatario è soggetto ad un regime forfettario ai
sensi del titolo XIV della sesta direttiva 77/388/CEE sull’IVA, l’IVA pagata è considerata
recuperabile ai fini del punto 1.
Di seguito vengono esposti i criteri specifici di ammissibilità dei costi articolati per macrovoci
di spesa.
26
A) SERVIZI INFORMATICI
In questa voce di costo sono ammissibili le spese sostenute per:
•
Realizzazione ed acquisto di servizi informatici di base e applicativi
Per le tipologie di beni indicate, deve essere disponibile presso il soggetto che rendiconta la
seguente documentazione:
copia degli atti di impegno giuridicamente vincolanti (contratti, buoni d’ordine, etc.) con
identificazione della tipologia del servizio e relativo costo
fattura del fornitore;
documentazione attestante l’avvenuto pagamento, quali, ad esempio, la ricevuta bancaria
del bonifico, con indicazione nella causale del riferimento al progetto, della nota di debito e
del beneficiario; Non sono comunque ammessi pagamenti in contanti.
B) SVILUPPO SOFTWARE E AQUISTO LICENZE
In questa voce di costo sono ammissibili le spese sostenute per:
•
Sviluppo di software
•
Implementazione di software
•
Acquisto di licenze
Per le tipologie di beni indicate, deve essere disponibile presso il soggetto che rendiconta la
seguente documentazione:
copia degli atti di impegno giuridicamente vincolanti (contratti, buoni d’ordine, etc.) con
identificazione della tipologia del bene e relativo costo
documento di trasporto e/o buono di consegna del bene
documento di presa in carico del bene
fattura del fornitore;
documentazione attestante l’avvenuto pagamento, quali, ad esempio, la ricevuta bancaria
del bonifico, con indicazione nella causale del riferimento al progetto, della nota di debito e
del beneficiario; Non sono comunque ammessi pagamenti in contanti.
C) BANCHE DATI
In questa voce di costo sono ammissibili le spese sostenute per:
•
Acquisizione di banche dati
•
Realizzazione di banche dati.
27
Per le tipologie di beni indicate, deve essere disponibile presso il soggetto che rendiconta la
seguente documentazione:
− copia degli atti di impegno giuridicamente vincolanti (contratti, buoni d’ordine,
etc.) con identificazione della tipologia del bene e relativo costo
− documento di trasporto e/o buono di consegna del bene (ove possibile)
− documento di presa in carico del bene (ove possibile)
− fattura del fornitore;
− documentazione attestante l’avvenuto pagamento, quali, ad esempio, la ricevuta
bancaria del bonifico, con indicazione nella causale del riferimento al progetto,
della nota di debito e del beneficiario; Non sono ammessi pagamenti in
contanti.
D) HARDWARE
D.1 - ATTREZZATURE E STRUMENTAZIONI AD AMMORTAMENTO PLURIENNALE
Questa voce comprende i costi relativi ad apparecchiature e strumentazioni ad ammortamento
pluriennale per interventi la cui finalità è la realizzazione o il potenziamento di hardware. In
questo caso i costi sostenuti e ritenuti ammissibili sono riconosciuti nella loro globalità.
Nel caso di progetti inerenti l’acquisto di attrezzature e strumentazioni sono ritenuti ammissibili
i costi sostenuti per:
− Apparati informatici
Vengono riconosciuti sia i costi sostenuti per l’acquisto di beni nuovi di fabbrica direttamente
dal fornitore o da suoi concessionari di zona, sia i costi sostenuti per l’acquisto di materiale
usato. Nel caso di materiale usato, la spesa è ritenuta ammissibile se vengono soddisfatte le
condizioni indicate alla norma n. 4 – Acquisto di materiale usato del Regolamento CE n.
1685/2000 del 28 luglio 2000.
In particolare l’acquisto di materiale usato è consentito se:
− è attestata l’origine esatta del materiale e se il bene non ha beneficiato di alcun
contributo nazionale e/o comunitario negli ultimi sette anni.
− il prezzo non è superiore al prezzo di mercato e risulta inferiore al prezzo del
bene nuovo di fabbrica.
− le caratteristiche tecniche sono rispondenti alle finalità ed esigenze del progetto
cofinanziato
− il bene è conforme alle norme standard pertinenti e vigenti
− il bene è immediatamente disponibile e non necessita di interventi di
manutenzione
Sia nel caso di acquisto di materiale nuovo di fabbrica, che nel caso di acquisto di materiale
usato, non sono ammessi costi inerenti a intermediazioni commerciali (p.e. commissioni
bancarie per pagamenti su estero) Il costo ammissibile è costituito dal costo del bene acquistato
e dai costi relativi ad eventuali dazi doganali, imballo e trasporto.
Non sono ammessi i costi relativi ad eventuali contratti di manutenzione/assistenza tecnica da
effettuarsi
successivamente
all’avvenuta
installazione
e
collaudo
dell’attrezzatura/strumentazione, anche se previsti nel contratto di fornitura. In ogni caso nel
contratto deve essere ben identificato il costo attribuito a questo tipo di prestazioni.
Sono ritenuti ammissibili, nel caso di allestimenti ex novo, i costi sostenuti per la prima
fornitura di materiale di consumo specifico necessario per la fase di avvio delle attività, purché
non prelevato da magazzino (di cui al successivo punto D2), nonché l’acquisto di software
necessario a garantire la funzionalità delle attrezzature/strumentazioni.
28
Per “prima fornitura” si intende la quantità di materiale di consumo strettamente necessaria al
primo funzionamento delle attrezzature e strumentazioni oggetto di cofinanziamento
Nel caso di attrezzature informatiche sono ammessi costi sostenuti per l’aggiornamento
dell’hardware già in possesso del soggetto che rendiconta. In particolare ci si riferisce a singoli
componenti hardware (ad es.: espansioni di memoria; schede grafiche; etc).
Per le tipologie di beni indicate, deve essere disponibile presso il soggetto che rendiconta la
seguente documentazione:
− copia degli atti di impegno giuridicamente vincolanti (contratti, buoni d’ordine,
etc.) con identificazione della tipologia dell’attrezzatura/strumentazione e
relativo costo.
− documento di trasporto e/o buono di consegna del bene
− libro cespiti con la descrizione dei beni.
−
fattura del fornitore;
−
documentazione attestante l’avvenuto pagamento, quali, ad esempio, la ricevuta
bancaria del bonifico, con indicazione nella causale del riferimento al progetto,
della nota di debito e del beneficiario; Non sono comunque ammessi pagamenti
in contanti.
Nel caso di acquisto di materiale usato dovrà essere disponibile anche la seguente
documentazione:
− documentazione idonea ad attestare l’origine esatta del materiale
− attestazione da parte del venditore che il bene non ha beneficiato di alcun
contributo pubblico nazionale, regionale e/o comunitario negli ultimi sette anni.
− documentazione idonea a dimostrare che il costo non è superiore al prezzo di
mercato e risulta inferiore al prezzo del bene nuovo di fabbrica.
− documentazione idonea a dimostrare che le caratteristiche tecniche sono
rispondenti alle finalità ed esigenze del progetto cofinanziato
− documentazione idonea a dimostrare che il bene è conforme alle norme e
standard vigenti e pertinenti al progetto cofinanziato.
Non sono ammissibili i costi esposti nei riepiloghi analitici senza descrizione della spesa o con
una descrizione da cui non sia desumibile la tipologia e la quantità del bene acquistato
D.2 -
MATERIALI DI CONSUMO
Applicabile solo in quanto “prima fornitura”. Il costo del materiale acquistato è determinato in
base al prezzo di fattura più dazi doganali, trasporto e imballo.
Il soggetto che rendiconta deve conservare in originale presso la propria sede, la seguente
documentazione da esibire in sede di verifica amministrativo-contabile:
•
documentazione relativa alla selezione del fornitore del bene;
•
ordine al fornitore contenente l’indicazione dell’esplicito riferimento al progetto;
•
documento di trasporto e buono di consegna (se applicabile);
•
fattura del fornitore contenente il riferimento all’ordine e il costo unitario del bene fornito;
•
documentazione attestante l’avvenuto pagamento, quali, ad esempio, la ricevuta bancaria
del bonifico, con indicazione nella causale del riferimento al progetto, della nota di debito e
del beneficiario; Non sono comunque ammessi pagamenti in contanti.
29
E) RETI
Questa voce comprende i costi relativi ad apparecchiature e strumentazioni ad ammortamento
pluriennale per interventi la cui finalità è la realizzazione o il potenziamento di reti . In questo
caso i costi sostenuti e ritenuti ammissibili sono riconosciuti nella loro globalità.
Nel caso di progetti inerenti l’acquisto di attrezzature e strumentazioni sono ritenuti ammissibili
i costi sostenuti per la realizzazione e/o ammodernamento di:
− Intranet
− Extranet
Vengono riconosciuti sia i costi sostenuti per l’acquisto di beni nuovi di fabbrica direttamente
dal fornitore o da suoi concessionari di zona, sia i costi sostenuti per l’acquisto di materiale
usato.
Nel caso di materiale usato, la spesa è ritenuta ammissibile se vengono soddisfatte le condizioni
indicate alla norma n. 4 – Acquisto di materiale usato del Regolamento CE n. 1685/2000 del 28
luglio 2000.
In particolare l’acquisto di materiale usato è consentito se:
− è attestata l’origine esatta del materiale e se il bene non ha beneficiato di alcun
contributo nazionale e/o comunitario negli ultimi sette anni.
− il prezzo non è superiore al prezzo di mercato e risulta inferiore al prezzo del
bene nuovo di fabbrica.
− le caratteristiche tecniche sono rispondenti alle finalità ed esigenze del progetto
cofinanziato
− il bene è conforme alle norme standard pertinenti e vigenti
− il bene è immediatamente disponibile e non necessita di interventi di
manutenzione
Sia nel caso di acquisto di materiale nuovo di fabbrica, che nel caso di acquisto di materiale
usato non sono ammessi costi inerenti a intermediazioni commerciali (p.e. commissioni bancarie
per pagamenti su estero)
Il costo ammissibile è costituito dal costo del bene acquistato e dai costi relativi ad eventuali
dazi doganali, imballo e trasporto.
Non sono ammessi i costi relativi ad eventuali contratti di manutenzione/assistenza tecnica da
effettuarsi
successivamente
all’avvenuta
installazione
e
collaudo
dell’attrezzatura/strumentazione, anche se previsti nel contratto di fornitura. In ogni caso nel
contratto deve essere ben identificato il costo attribuito a questo tipo di prestazioni.
Sono ritenuti ammissibili, nel caso di allestimenti ex novo, i costi sostenuti per la prima
fornitura di materiale di consumo specifico necessario per la fase di avvio delle attività, purché
non prelevato da magazzino (di cui al precedente punto D2), nonché l’acquisto di software
necessario a garantire la funzionalità delle attrezzature/strumentazioni.
Per “prima fornitura” si intende la quantità di materiale di consumo strettamente necessaria al
primo funzionamento delle attrezzature e strumentazioni oggetto di cofinanziamento
Nel caso di attrezzature di rete sono ammessi costi sostenuti per l’aggiornamento dell’hardware
o del firmware già in possesso del soggetto che rendiconta. In particolare ci si riferisce a singoli
componenti hardware (ad es.: espansioni di memoria; interfacce di rete, matrice di
commutazione; etc) o aggiornamenti della release firmware.
Per le tipologie di beni indicate, deve essere disponibile presso il soggetto che rendiconta la
seguente documentazione:
− copia degli atti di impegno giuridicamente vincolanti (contratti, buoni d’ordine,
etc.) con identificazione della tipologia dell’attrezzatura/strumentazione e
relativo costo.
− documento di trasporto e/o buono di consegna del bene
30
−
libro cespiti con la descrizione dei beni.
−
fattura del fornitore;
−
documentazione attestante l’avvenuto pagamento, quali, ad esempio, la ricevuta
bancaria del bonifico, con indicazione nella causale del riferimento al progetto,
della nota di debito e del beneficiario; Non sono comunque ammessi pagamenti
in contanti.
Nel caso di acquisto di materiale usato dovrà essere disponibile anche la seguente
documentazione:
− documentazione idonea ad attestare l’origine esatta del materiale
− attestazione da parte del venditore che il bene non ha beneficiato di alcun
contributo pubblico nazionale, regionale e/o comunitario negli ultimi sette anni.
− documentazione idonea a dimostrare che il costo non è superiore al prezzo di
mercato e risulta inferiore al prezzo del bene nuovo di fabbrica.
− documentazione idonea a dimostrare che le caratteristiche tecniche sono
rispondenti alle finalità ed esigenze del progetto cofinanziato
− documentazione idonea a dimostrare che il bene è conforme alle norme e
standard vigenti e pertinenti al progetto cofinanziato.
31
F) CONSULENZE SPECIALISTICHE
F.1) PERSONALE DIPENDENTE (NON APPLICABILE)
F.2. PERSONALE ESTERNO CON RAPPORTO ASSIMILABILE A LAVORO DIPENDENTE:
(NON APPLICABILE)
F.3) PRESTAZIONI ESTERNE (PRESTATORI D’OPERA NON SOGGETTI A REGIME IVA)
Si intendono le prestazioni dei soggetti esterni, rispetto al contraente, cui è demandata, sulla
base di uno specifico incarico, la realizzazione di attività strettamente attinenti al progetto
approvato e/o previste nello stesso, quali spese per consulenza scientifica e tecnica. Non sono
rimborsate missioni e/o viaggi.
La collaborazione deve risultare da lettera di incarico o contratto di collaborazione, sottoscritti
dalle parti interessate. Sono ammissibili le seguenti forme contrattuali :
−
Prestazione Occasionale
−
Prestazione Coordinata e Continuativa a Progetto
−
Prestazione Coordinata e Continuativa (dove applicabile)
Il soggetto che rendiconta deve conservare, in originale presso la propria sede, la seguente
documentazione da esibire in sede di verifica amministrativo-contabile:
curriculum vitae da cui risulti la competenza professionale relativa alla prestazione
richiesta;
lettera di incarico o contratto di collaborazione con descrizione dettagliata della prestazione
e relativa accettazione (nel caso di personale della P.A. e di docenti universitari devono
essere rispettate le disposizioni legislative che disciplinano la materia (D.P.R. 11.7.80 n.
382 e art. 58 commi 5, 6 e 7 del D. Lgs. 3.2.93 n. 29, successivamente modificato dall'art.
26 del D. Lgs. 31.3.98 n. 80 e dall'art. 16 del D. Lgs. del 29.10.98 n° 387) recante:
indicazione del riferimento al progetto, oggetto dell’attività, periodo di svolgimento e
output previsto, corrispettivi con indicazione del compenso per ora/giornata di prestazione,
ove applicabile.
documentazione comprovante l’avvenuta esecuzione della prestazione, (rapporti di attività,
relazioni, verbali, ecc.) e/o attestazione di conformità del responsabile di progetto;
nota di debito indicante: data, riferimento al progetto, attività svolta e output prodotto,
corrispettivi e periodo di riferimento ove applicabile;
documentazione attestante l’avvenuto pagamento, quali, ad esempio, la ricevuta bancaria
del bonifico, con indicazione nella causale del riferimento al progetto, della nota di debito e
del beneficiario; assegno bancario o circolare corredati da contabile bancaria di addebito in
conto corrente; mandato di pagamento e relativa liquidazione. Non sono comunque ammessi
pagamenti in contanti;
ricevute di versamento dell’IRPEF relative alle ritenute d’acconto e degli oneri
previdenziali.
F.4 - PROFESSIONISTI SOGGETTI AL REGIME IVA
La prestazione deve risultare da lettera di incarico o contratto di collaborazione professionale
sottoscritti dalle parti interessate.
32
Il soggetto che rendiconta deve conservare, in originale presso la propria sede, la seguente
documentazione da esibire in sede di verifica amministrativo-contabile:
curriculum vitae da cui risulti la competenza professionale relativa alla prestazione
richiesta;
lettera di incarico o contratto di collaborazione con descrizione dettagliata della prestazione
e relativa accettazione - nel caso di personale della P.A. e di docenti universitari devono
essere rispettate le disposizioni legislative che disciplinano la materia (D.P.R. 11.7.80 n.
382 e art. 58 commi 5, 6 e 7 del D. Lgs. 3.2.93 n. 29, successivamente modificato dall'art.
26 del D. Lgs. 31.3.98 n. 80 e dall'art. 16 del D. Lgs. del 29.10.98 n° 387) - recante
indicazione del riferimento al progetto; oggetto dell’attività, periodo di svolgimento, output
previsto e corrispettivi con indicazione del compenso per ora/giornata di prestazione (ove
applicabile);
documentazione comprovante l’avvenuta esecuzione della prestazione, (rapporti di attività,
relazioni, verbali, , ecc.) e/o attestazione di conformità del responsabile di progetto;
fattura indicante: data; riferimento al progetto; attività svolta e output prodotto; corrispettivi
e periodo di riferimento ove applicabile.
documentazione attestante l’avvenuto pagamento, quali, ad esempio, la ricevuta bancaria
del bonifico, con indicazione nella causale del riferimento al progetto, della nota di debito e
del beneficiario; assegno bancario o circolare corredati da contabile bancaria di addebito in
conto corrente; mandato di pagamento e relativa liquidazione. Non sono comunque ammessi
pagamenti in contanti;
ricevute di versamento dell’IRPEF relative alle ritenute d’acconto ed oneri previdenziali.
F.5 - SOCIETÀ
La prestazione deve risultare da lettera di incarico o contratto sottoscritti dalle parti interessate.
Il soggetto che rendiconta deve conservare, in originale presso la propria sede, la seguente
documentazione da esibire in sede di verifica amministrativo-contabile:
documentazione relativa alla selezione del prestatore di servizio o di opera;
lettera di incarico o contratto con descrizione dettagliata della prestazione: indicazione del
riferimento al progetto; oggetto dell’attività, periodo di svolgimento e output previsto;
corrispettivi con indicazione del compenso.
documentazione comprovante l’avvenuta esecuzione della prestazione, (rapporti di attività,
relazioni, verbali, ecc.) e/o attestazione di conformità del responsabile di progetto;
fattura del fornitore indicante: data; riferimento al progetto; attività svolta e output prodotto;
corrispettivi e periodo di riferimento ove applicabile.
documentazione attestante l’avvenuto pagamento, quali, ad esempio, la ricevuta bancaria
del bonifico, con indicazione nella causale del riferimento al progetto, della nota di debito e
del beneficiario; assegno bancario o circolare corredati da contabile bancaria di addebito in
conto corrente; mandato di pagamento e relativa liquidazione. Non sono comunque ammessi
pagamenti in contanti.
33
G – CONNETTIVITÀ INTERNET
In questa voce sono ammissibili i costi per le spese sostenute per:
•
indirizzo IP
•
acquisto domini
•
hosting/housing
Non sono ammissibili costi relativi a canoni o consumi di traffico relativi a circuiti di
telecomunicazione. Sono invece ammissibili i costi di attivazione di circuiti (costi una tantum di
attivazione)
Il soggetto che rendiconta deve conservare, in originale presso la propria sede, la seguente
documentazione da esibire in sede di verifica amministrativo – contabile:
•
documentazione relativa alla selezione del fornitore del bene o prestatore di servizio;
•
Fatture del fornitore erogatore del servizio
•
documentazione attestante l’avvenuto pagamento,. Non sono comunque ammessi pagamenti
in contanti;
H – ADDESTRAMENTO PERSONALE
In questa voce sono ammissibili i costi per le spese sostenute per:
•
addestramento e aggiornamento del personale addetto per le specifiche realizzazione
Il soggetto che rendiconta deve conservare, in originale presso la propria sede, la seguente
documentazione da esibire in sede di verifica amministrativo – contabile:
•
documentazione relativa alla selezione del fornitore del bene o prestatore di servizio;
•
Richiesta che origina il servizio
•
Fatture del fornitore erogatore del servizio
•
documentazione attestante l’avvenuto pagamento, quali, ad esempio, la ricevuta bancaria
del bonifico, con indicazione nella causale del riferimento al progetto, della nota di debito e
del beneficiario; assegno bancario o circolare corredati da contabile bancaria di addebito in
conto corrente; mandato di pagamento e relativa liquidazione. Non sono comunque ammessi
pagamenti in contanti;
I- DIREZIONE LAVORI E PROGETTAZIONE
34
I.1) PERSONALE DIPENDENTE (NON APPLICABILE)
I.2. PERSONALE ESTERNO CON RAPPORTO ASSIMILABILE A LAVORO DIPENDENTE: (NON
APPLICABILE)
I.3) PRESTAZIONI ESTERNE (PRESTATORI D’OPERA NON SOGGETTI A REGIME IVA)
Si intendono le prestazioni dei soggetti esterni, rispetto al contraente, cui è demandata, sulla
base di uno specifico incarico, la realizzazione di attività strettamente attinenti al progetto
approvato e/o previste nello stesso, quali:
−
progettazione esecutiva
−
direzione lavori
−
collaudi
Non sono rimborsate missioni e/o viaggi. La collaborazione deve risultare da lettera di incarico
o contratto di collaborazione, sottoscritti dalle parti interessate. Sono ammissibili le seguenti
forme contrattuali :
−
Prestazione Occasionale
−
Prestazione Coordinata e Continuativa a Progetto
−
Prestazione Coordinata e Continuativa (dove applicabile)
Il soggetto che rendiconta deve conservare, in originale presso la propria sede, la seguente
documentazione da esibire in sede di verifica amministrativo-contabile:
curriculum vitae da cui risulti la competenza professionale relativa alla prestazione
richiesta;
lettera di incarico o contratto di collaborazione con descrizione dettagliata della prestazione
e relativa accettazione (nel caso di personale della P.A. e di docenti universitari devono
essere rispettate le disposizioni legislative che disciplinano la materia (D.P.R. 11.7.80 n.
382 e art. 58 commi 5, 6 e 7 del D. Lgs. 3.2.93 n. 29, successivamente modificato dall'art.
26 del D. Lgs. 31.3.98 n. 80 e dall'art. 16 del D. Lgs. del 29.10.98 n° 387) recante:
indicazione del riferimento al progetto, oggetto dell’attività, periodo di svolgimento e
output previsto, corrispettivi con indicazione del compenso per ora/giornata di prestazione,
ove applicabile.
documentazione comprovante l’avvenuta esecuzione della prestazione, (rapporti di attività,
relazioni, verbali, ecc.) e/o attestazione di conformità del responsabile di progetto;
nota di debito indicante: data, riferimento al progetto, attività svolta e output prodotto,
corrispettivi e periodo di riferimento ove applicabile;
documentazione attestante l’avvenuto pagamento, quali, ad esempio, la ricevuta bancaria
del bonifico, con indicazione nella causale del riferimento al progetto, della nota di debito e
del beneficiario; assegno bancario o circolare corredati da contabile bancaria di addebito in
conto corrente; mandato di pagamento e relativa liquidazione. Non sono comunque ammessi
pagamenti in contanti;
ricevute di versamento dell’IRPEF relative alle ritenute d’acconto e degli oneri
previdenziali.
I.4 - PROFESSIONISTI SOGGETTI AL REGIME IVA
35
La prestazione deve risultare da lettera di incarico o contratto di collaborazione professionale
sottoscritti dalle parti interessate.
Il soggetto che rendiconta deve conservare, in originale presso la propria sede, la seguente
documentazione da esibire in sede di verifica amministrativo-contabile:
curriculum vitae da cui risulti la competenza professionale relativa alla prestazione
richiesta;
lettera di incarico o contratto di collaborazione con descrizione dettagliata della prestazione
e relativa accettazione - nel caso di personale della P.A. e di docenti universitari devono
essere rispettate le disposizioni legislative che disciplinano la materia (D.P.R. 11.7.80 n.
382 e art. 58 commi 5, 6 e 7 del D. Lgs. 3.2.93 n. 29, successivamente modificato dall'art.
26 del D. Lgs. 31.3.98 n. 80 e dall'art. 16 del D. Lgs. del 29.10.98 n° 387) - recante
indicazione del riferimento al progetto; oggetto dell’attività, periodo di svolgimento, output
previsto e corrispettivi con indicazione del compenso per ora/giornata di prestazione (ove
applicabile);
documentazione comprovante l’avvenuta esecuzione della prestazione, (rapporti di attività,
relazioni, verbali, , ecc.) e/o attestazione di conformità del responsabile di progetto;
fattura indicante: data; riferimento al progetto; attività svolta e output prodotto; corrispettivi
e periodo di riferimento ove applicabile.
documentazione attestante l’avvenuto pagamento, quali, ad esempio, la ricevuta bancaria
del bonifico, con indicazione nella causale del riferimento al progetto, della nota di debito e
del beneficiario; assegno bancario o circolare corredati da contabile bancaria di addebito in
conto corrente; mandato di pagamento e relativa liquidazione. Non sono comunque ammessi
pagamenti in contanti;
ricevute di versamento dell’IRPEF relative alle ritenute d’acconto ed oneri previdenziali.
I.5 - SOCIETÀ
La prestazione deve risultare da lettera di incarico o contratto sottoscritti dalle parti interessate.
Il soggetto che rendiconta deve conservare, in originale presso la propria sede, la seguente
documentazione da esibire in sede di verifica amministrativo-contabile:
documentazione relativa alla selezione del prestatore di servizio o di opera;
lettera di incarico o contratto con descrizione dettagliata della prestazione: indicazione del
riferimento al progetto; oggetto dell’attività, periodo di svolgimento e output previsto;
corrispettivi con indicazione del compenso.
documentazione comprovante l’avvenuta esecuzione della prestazione, (rapporti di attività,
relazioni, verbali, ecc.) e/o attestazione di conformità del responsabile di progetto;
fattura del fornitore indicante: data; riferimento al progetto; attività svolta e output prodotto;
corrispettivi e periodo di riferimento ove applicabile.
documentazione attestante l’avvenuto pagamento, quali, ad esempio, la ricevuta bancaria del
bonifico, con indicazione nella causale del riferimento al progetto, della nota di debito e del
beneficiario; assegno bancario o circolare corredati da contabile bancaria di addebito in conto
corrente; mandato di pagamento e relativa liquidazione. Non sono comunque ammessi
pagamenti in contanti.
36
SEZIONE III – LA PROCEDURA DI RENDICONTAZIONE DELLA SPESA
La procedura di rendicontazione della spesa implica adempimenti specifici che non si
esauriscono con la sola esposizione dei costi effettivamente sostenuti, ma si articola nei seguenti
adempimenti:
Esposizione dei costi effettivamente sostenuti di cui al format di rendicontazione;
Dichiarazione di responsabilità e di conformità alla normativa vigente ;
Relazione sullo stato di avanzamento delle attività svolte.
La rendicontazione di spesa va completata dagli adempimenti connessi al monitoraggio
procedurale e fisico.
La rendicontazione è il processo di consuntivazione delle spese effettivamente sostenute dal
soggetto che rendiconta per la realizzazione dell'intervento, finalizzato a:
dimostrare lo stato di avanzamento finanziario del progetto (spesa effettivamente sostenuta);
dimostrare lo stato di avanzamento fisico del progetto;
dimostrare il rispetto dei requisiti e degli adempimenti per ottenere l'erogazione del contributo;
L'attività di rendicontazione, quindi, alimenta un processo trasversale a tutta la gestione, che
interagisce con l'attività di monitoraggio e di controllo.
La rendicontazione di spesa deve riferirsi ad un unico progetto inteso come l’insieme delle
azioni che fanno capo ad un unico atto contrattuale (contratto, convenzione, disciplinare, ecc.)
sottoscritto fra il Dipartimento Bilancio e Tesoro il soggetto che rendiconta (inclusi: varianti,
addendum ed ampliamenti riferiti al medesimo atto contrattuale).
Essa si riferisce al complesso delle spese realizzate per l’esecuzione delle attività previste
indipendentemente dalla fonte di finanziamento (comunitaria, nazionale pubblica, privata) che
contribuisce a sostenere tali spese.
La documentazione deve essere organizzata, conservata, esibita con riferimento al progetto in
base al principio della “contabilità separata per centro di costo”. Qualora all'interno di una
convenzione o disciplinare siano individuabili più iniziative caratterizzate da una propria
autonomia progettuale la contabilità dovrà essere organizzata in modo da far riferimento alle
singole iniziative, salvo presentare quadri di sintesi ben leggibili e interpretabili.
I costi rendicontabili (secondo il criterio della “spesa effettivamente sostenuta” di cui alla norma
n. 1 del Reg. CE 1685/2000) devono essere debitamente rappresentati e giustificati da idonea ed
inequivoca documentazione, pena la non ammissibilità ai contributi.
In linea generale, le spese sostenute devono essere giustificate da quattro tipologie di documenti
che devono essere conservati ed esibiti su richiesta degli organi di controllo:
giustificativi di impegno: sono rappresentati dai provvedimenti che originano la prestazione
o fornitura (ad esempio: lettere di incarico, ordini di servizio, ordini di forniture, ecc.) in cui
sia esplicitamente indicata la connessione e la pertinenza della spesa con l’operazione
cofinanziata. Tali provvedimenti devono essere emessi prima dell’inizio della prestazione o
della fornitura. Qualora applicabile (ad esempio acquisto di forniture, commesse esterne,
ecc.) i giustificativi di impegno includono la verifica delle procedure di selezione del
fornitore o prestatore d'opera secondo le modalità esposte per le singole voci di spesa della
Sezione II della presente Guida;
37
giustificativi della prestazione o fornitura: sono documenti che descrivono la prestazione o
fornitura (come ad esempio: fatture, ricevute esenti IVA, ecc.), fanno riferimento sia al
giustificativo di impegno, che all’operazione cofinanziata e ne esibiscono il relativo costo.
Su tutti gli originali dei titoli di spesa l’importo totale o parziale imputato a titolo di
cofinanziamento deve essere annullato con un timbro ad inchiostro indelebile che riporta, la
denominazione del Programma Operativo, l’indicazione della Misura e del Fondo che
cofinanzia il progetto stesso. Il timbro suddetto deve essere realizzato in modo da prevedere
uno spazio in cui inserire l’importo cofinanziato. Il timbro deve essere apposto sul
documento originale e nella faccia a vista (non sul retro);
giustificativi di pagamento: sono documenti che attestano in maniera inequivoca e correlata
ai giustificativi di cui sopra, l’avvenuta liquidazione della prestazione o fornitura, quali, ad
esempio: la ricevuta bancaria del bonifico, con indicazione nella causale del riferimento al
progetto, della nota di debito e del beneficiario; assegno bancario o circolare corredati da
contabile bancaria di addebito in conto corrente; mandato di pagamento e relativa
liquidazione. Non sono ammessi pagamenti in contanti. In ogni caso i pagamenti sono
ammessi solo se effettuati entro i termini temporali di eleggibilità della spesa previsti per il
progetto;
idonea documentazione probatoria delle attività realizzate (quale, ad esempio, report delle
attività svolte, verbali, prodotti realizzati, ecc.)
Tutta la suddetta documentazione deve essere conservata, in originale, presso il soggetto che
rendiconta conformemente alle leggi nazionali contabili e fiscali e deve avere le seguenti
caratteristiche:
essere riferita a voci di costo ammesse;
essere documentata con giustificativi originali;
essere redatta in modo analitico riportando le voci di formazione del costo finale e
l’indicazione del riferimento al “progetto”;
essere priva di correzioni e leggibile in ogni parte, con particolare attenzione ai caratteri
numerici (importi, date, ecc.);
essere conforme alle norme contabili, fiscali e contributive nazionali;
essere registrata nella contabilità generale del soggetto che rendiconta;
avere data di liquidazione riferita al periodo di eleggibilità.
essere riferite a spese sostenute secondo principi di economia e sana gestione finanziaria;
essere riferite a spese contenute nei limiti dell’importo ammesso a cofinanziamento.
In linea generale i costi sono riconosciuti solo se “effettivamente” e “direttamente” sostenuti
dal soggetto che rendiconta nel periodo di eleggibilità; vale cioè per essi il criterio di
“cassa”.
Non saranno presi in considerazione pagamenti effettuati successivamente al sesto mese dalla
data di conclusione delle attività di progetto e comunque non oltre la data di presentazione
della rendicontazione finale di spesa, detto termine si applica anche in caso di conclusione
del progetto anticipata rispetto alla data stabilita.
In nessun caso sono ammessi a cofinanziamento costi calcolati in misura forfetarie.
Non sono rendicontabili spese accessorie dipendenti da comportamenti anomali del soggetto
realizzatore, quali: infrazioni, spese legali per contenziosi, interessi di mora per ritardato
pagamento e similari.
38
I costi afferenti le diverse tipologie di spesa dovranno considerarsi comprensivi di I.V.A., solo
nel caso in cui tale imposta non sia trasferibile. In questo caso il soggetto beneficiario del
contributo fornirà apposita dichiarazione da cui risultino anche le motivazioni della suddetta
non trasferibilità. In ogni caso il valore dell’I.V.A. dovrà essere identificato separatamente
dall’imponibile.
Nel caso di pagamenti effettuati a favore di fornitori residenti in paesi che non utilizzano l’Euro
ogni singola operazione andrà convertita in Euro utilizzando il tasso di cambio medio del mese
in cui l’operazione è stata liquidata.
39
SEZIONE IV - SCADENZARIO DEGLI ADEMPIMENTI
I Comuni e/o Province Regionali aderenti alla rete dovranno formalizzare la partecipazione al
progetto entro 15 giorni dalla pubblicazione del decreto di finanziamento in GURS, attraverso
la sottoscrizione di un Protocollo d’Intesa di cui è disponibile un facsimile presso il sito della
regione siciliana (www.regione.sicilia.it/bilancio)
In tal caso il progetto è presentato dal Capofila che funge da stazione unica appaltante.
Le coalizioni già costituite (ad esempio Unioni di Comuni, Consorzi etc) non dovranno
sottoscrivere il protocollo d’intesa ma presenteranno direttamente il progetto attraverso
l’Unione, il Consorzio etc. In tal caso stazione unica appaltante è l’Unione, il Consorzio etc.
Tutte le coalizioni dovranno altresì produrre entro il medesimo termine di 15 giorni il
Disciplinare e l’Atto di obbligo e di accettazione, debitamente firmati dal soggetto capofila.
Il progetto esecutivo dovrà essere consegnato improrogabilmente, pena la revoca immediata del
finanziamento, entro e non oltre 45 giorni dalla pubblicazione del decreto di finanziamento in
GURS.
Entro 10 giorni dalla consegna del progetto esecutivo il Dipartimento Bilancio e Finanze della
Regione Siciliana provvederà all’approvazione dello stesso o alla formulazione di eventuali
osservazioni.
Approvato il progetto farà seguito l’erogazione del 100% del Finanziamento a valere sulla
Misura 6.05.
Le gare per la fornitura di beni, servizi, di project financing etc. oltre le consuete modalità di
pubblicazione dovranno essere trasmesse all’Assessorato Bilancio e Finanze all’indirizzo:
[email protected] affinché ne possa essere data diffusione massima.
I progetti saranno oggetto di monitoraggio periodico e dovranno concludersi entro e non oltre
18 mesi dalla data di pubblicazione del decreto di finanziamento in GURS .
40
SEZIONE V - NORMATIVA DI RIFERIMENTO
Nella presente sezione sono individuate le principali norme e documenti di riferimento per la
predisposizione dei progetti esecutivi.
ARGOMENTO
TESTO DI RIFERIMENTO
ALLEGATO
Accessibilità
Legge 4/2004
1
Protocollo Informatico
Linee Guida per l’adozione del
Protocollo Informatico
2
Posta Elettronica Certificata
Guida ai servizi di Indice delle
Amministrazioni Pubbliche e delle
Aree Organizzative Omogenee e
Posta Elettronica Certificata
3
Firma elettronica
Firma elettronica:
standard
4
tecnologie
e
Qualità dei beni e dei servizi Linee Guida sulla qualità dei beni e
5
ICT
dei servizi ICT per la definizione ed
il governo dei contratti della
Pubblica Amministrazione
Certificazione EN ISO 9000
Deliberazione 49/2000, 9 novembre Pubblicata nella G.U.
nell’appalto dei sistemi
2000 - delibera:2000-11-09;49 20 dicembre 2000, n.
informativi automatizzat
Regole tecniche e criteri operativi
296, S.O
per l’utilizzo della certificazione
EN ISO 9000 nell’appalto di
contratti relativi a progettazione,
realizzazione, manutenzione,
gestione e conduzione operativa dei
sistemi informativi automatizzati,
ex art. 7, co. 1, lett. a), del decreto
legislativo 12 febbraio
Riproduzione e conservazione Deliberazione 42/2001, 13
di documenti su supporto ottico dicembre 2001 e Note esplicative delibera:2001-12-13;42) Regole
tecniche per la riproduzione e
conservazione di documenti su
supporto ottico.
Pubblicata nella G.U.
21 dicembre 2001, n.
296
Riproduzione e conservazione Deliberazione 11/2004, 19 febbraio Pubblicata nella G.U. 9
di documenti su supporto ottico 2004 e Note esplicative Regole
marzo 2004, n. 57
tecniche per la riproduzione e
conservazione di documenti su
supporto ottico idoneo a garantire la
conformità dei documenti agli
originali.
41
Comunicazioni elettroniche
G.U. n. 214 del
15.09.200
Appalti pubblici di servizi
Appalti pubblici di servizi
Appalti Pubblici di beni
D.Lgs. recante il Codice delle
Comunicazioni Elettroniche (D.Lgs.
01.08.2003 - 3)
Circolare CNIPA/CR/44, 5 ottobre
2004 - Indicazioni relative agli
appalti pubblici per la fornitura di
personal computer desktop.
Decreto Legislativo 1995/157
Decreto Legislativo 2000/65
Decreto Legislativo 1992 n.358
Appalti Pubblici
Legge Regionale 7/2003
www.regione.sicilia.it
Appalti
Pubblicata nella G.U.
12 ottobre 2004, n.240
www.regione.sicilia.it
GU n.70 del 24/3/2000
www.regione.sicilia.i
t
42
GLOSSARIO
A
ADSL (Asymmetric Digital Subscriber Line): tecnologia che permette la trasmissione di dati
sulla linea telefonica tradizionale (doppino) per brevi distanze e con asimmetria tra la velocità di
scaricamento (download) e di caricamento (upload).
AIPA (vedi CNIPA): Autorità per l’Informatica nella Pubblica Amministrazione costituita ai
sensi dell’art.4 del Decreto Legislativo 12 febbraio 1993, n. 39 (G.U. 20/2/1993, n.42). AIPA è
stata unificata nel 2003 con il Centro Tecnico della Presidenza del Consiglio dei Ministri e
trasformata nel Centro Nazionale per l’Informatica nella Pubblica Amministrazione (CNIPA).
ASP (Active Server Pages): pagine dinamiche con estensione .asp che vengono processate
lato server e che permettono di mostrare sulle pagine si un sito web dei dati contenuti in una
base di dati.
ASP (Application Srvice Provider): società che offre l'utilizzo via Internet di applicazioni
software gestite in remoto da un Data Center. Gli applicativi risiedono e vengono eseguiti sui
server dell'ASP e sono accessibili, con un semplice browser, tramite una rete IP (Internet).
Autenticazione: operazione mediante cui è possibile verificare l’attendibilità di un
identificativo, riferito ad una persona o ad un sistema elaborativo, associato ad una transazione o
ad un messaggio. L’autenticazione è il mezzo attraverso cui il destinatario di una transazione o
di un messaggio può decidere se accettare o meno tale transazione.
B
Banda larga (BL): il termine “banda” indica nelle telecomunicazioni la capacità trasmissiva di
una rete o di un canale, ovvero la massima velocità alla quale è possibile trasferire le
informazioni (misurata in numero di bit per secondo). Il termine “banda larga” (o l’equivalente
inglese broadband) definisce un insieme di tecnologie che consentono di fornire all’utente
collegamenti di velocità molto superiore a quelli della normale rete telefonica (che per
definizione fornisce servizi a banda stretta o narrowband). Sfruttando infrastrutture e tecnologie
innovative rispetto a quelle tradizionali è quindi possibile aumentare la velocità di
comunicazione in generale, e l’accesso a Internet in particolare, permettendo di usufruire di
servizi multimediali e ad alta interattività attraverso una connessione permanente alla rete
(always on). Il legame tra le infrastrutture e i servizi abilitati è talmente forte, che solitamente si
usa il termine “banda larga” in senso ampio ad indicare l’unione di tecnologie, servizi e
contenuti, che possono essere fruiti grazie alle nuove tecnologie.
Benchmarking: processo che consente a un'azienda di migliorare le proprie prestazioni e la
propria posizione all'interno del mercato. Questo si ottiene attraverso un'attenta analisi
comparativa di prestazioni, prassi, prodotti con quelli di aziende ritenute migliori. Il confronto
permette di individuare gli obiettivi da perseguire e le strategie da porre in atto.
BPR (Business Process Reengineering): processo che si propone di modificare un'azienda in
modo radicale attraverso il coinvolgimento delle risorse personali nell'attività di cambiamento,
maggiore flessibilità e diminuzione dei livelli gerarchici. Il fine è raggiungere miglioramenti
significativi nell'organizzazione
43
C
Carta d’identità elettronica / Carta nazionale dei servizi (CIE / CNS): sono carte a
microprocessore, cosiddette “smart card”, che contengono tra le altre cose un “certificato
digitale” che attesta la identità del portatore della carta e che consente in genere anche di
apporre una “firma elettronica o digitale”. Per questo motivo, vengono usate per accertare
l’identità degli utenti che intendono accedere a servizi telematici soggetti a requisiti di sicurezza
e riservatezza o per firmare e trasmettere documenti elettronici con validità legale. La CIE, oltre
all’identificazione elettronica, permette anche l’identificazione visuale (grazie alla fotografia) e
sostituisce a tutti gli effetti l’attuale Carta d’Identità; come quest’ultima, vede quindi coinvolti
nell’emissione il Ministero dell’Interno e i Comuni. La CNS ha invece principalmente una
funzione di accesso e interazione con i servizi on-line e può essere emessa da qualunque
pubblica amministrazione, nel rispetto degli standard e delle regole appositamente definiti.
CNIPA: il Centro Nazionale per l’Informatica nella Pubblica Amministrazione (CNIPA),
istituito dall’ Art. 176 del D. Lgs. del 30 giugno 2003 n. 196 (G.U. n. 174 del 29 luglio 2003)
opera presso la Presidenza del Consiglio per l’attuazione delle politiche del Ministro per
l’Innovazione e le Tecnologie. Unifica in sé due organismi preesistenti: l’Autorità per
l’Informatica nella Pubblica Amministrazione (AIPA) ed il Centro Tecnico per la R.U.P.A. sito
Internet www.cnipa.gov.it
Cooperazione applicativa: erogazione di servizi informatici a valore aggiunto che utilizzano le
funzioni di due o più applicazioni, progettate per erogare servizi singolarmente, appartenenti a
sistemi informatici diversi afferenti allo stesso o a differenti domini.
CRM (Customer Relationship Management): soluzione tecnologica ed organizzativa di
un'azienda per un efficace ed efficiente rapporto con il cliente attraverso strumenti informatici.
Le applicazioni CRM permettono la raccolta, l'analisi e l'utilizzo delle informazioni sul cliente
per rispondere alle sue esigenze ed instaurare un rapporto di fiducia.
Customer satisfaction: la soddisfazione del consumatore, è il nuovo indice per valutare la
salute di un'azienda. Esso rivela a quale livello l'azienda valorizza un patrimonio insostituibile:
la clientela.
D
Data warehouse: letteralmente "magazzino di dati". E' un database di grosse dimensioni in
grado di raccogliere, omogeneizzare, razionalizzare e rendere disponibili tutte le informazioni di
un'azienda. Il data warehouse può essere suddiviso su più computer e può essere costituito da
diversi database. Le informazioni contenute provengono da fonti differenti ed hanno diversi
formati. Questo grande database è utilizzato come supporto alle decisioni aziendali.
Digital divide: divario digitale, fa riferimento alle differenze che si osservano su scala
territoriale (all’interno di una regione o tra più regioni) in relazione alla disponibilità di
tecnologie e servizi digitali, in specifico, di infrastrutture e servizi a banda larga.
Digitale Terrestre - DTT - Digital Terrestrial Television: sistema di diffusione di segnali
televisivi digitali attraverso trasmettitori-ripetitori terrestri, ricevibili con le antenne esistenti. Si
prevede che in breve tempo la DTT sarà in grado di veicolare potenzialmente applicazioni di
carattere innovativo nell’area dei servizi pubblici e dell’interazione tra cittadini e
amministrazioni pubbliche
44
DIT: Dipartimento per l’innovazione e le tecnologie è la struttura della Presidenza del Consiglio
dei Ministri che risponde al Ministro per l’Innovazione delle Tecnologie.
Dominio/Sottodominio: è definito come “l’insieme delle risorse (in particolare le procedure, i
dati e i servizi) e delle politiche di una determinata organizzazione”. Il dominio è anche il
confine di responsabilità di un’organizzazione, in particolare per quanto riguarda le politiche
che definiscono il suo sistema informativo. Il dominio di una Amministrazione può
eventualmente essere scomposto in più “sottodomini”. Detti sottodomini presentano tipicamente
due valenze: una funzionale e una territoriale.
Doppino: Costituisce i normali cavi telefonici ed è composto da due fili di rame intrecciati per
ridurre le interferenze.
DSL (xDSL): l’acronimo indica la famiglia Digital Subscriber Line, ossia l’insieme delle
tecnologie sviluppate a partire dagli anni ‘70 per permettere la trasmissione digitale su uno o più
doppini telefonici in rame sfruttando le caratteristiche trasmissive del mezzo. All’interno della
famiglia, la x viene sostituita da una o più lettere che caratterizzano le singole tecnologie
(ADSL, HDSL, SHDSL, VDSL, ecc.). La tecnologia ADSL è orientata prevalentemente al
cliente residenziale, mentre le altre ai clienti affari. Il vantaggio di tutta la famiglia di tecnologie
xDSL è la possibilità di utilizzare le tratte esistenti di infrastruttura di accesso e quindi di non
richiedere l’esecuzione di lavori su terreno pubblico o all’interno delle abitazioni.
E
e-business: (letteralmente “attività economica elettronica”) termine più ampio di e-commerce
(commercio elettronico), in quanto comprende l’intera gamma delle possibili applicazioni delle
ICT alle attività di impresa interne ed esterne (non solo la gestione dei rapporti con i fornitori e
con il mercato) e indica l’importanza e opportunità di collegare l’innovazione telematica alla
revisione più complessiva della strategia di impresa.
ECDL (European Computer Driving Licence): patente europea del computer.
e-commerce: commercio elettronico, è l’insieme delle attività che avvengono in rete, tramite
computer e collegamenti telematici e attraverso le quali imprese e consumatori realizzano
transazioni commerciali.
e-democracy: un sistema che promuove la partecipazione dei cittadini alle attività delle
pubbliche amministrazioni e
ai loro processi decisionali attraverso l’utilizzo delle Tecnologie dell’Informazione e della
Comunicazione.
e-government: governo o amministrazione elettronica, è la trasformazione delle attività
amministrative e gestionali della pubblica amministrazione, delle modalità di erogazione dei
servizi pubblici, dei processi di partecipazione ai meccanismi democratici, realizzata tramite un
utilizzo intensivo delle nuove ICT.
e-learning: (letteralmente “apprendimento elettronico”) secondo il Piano di azione di e-learning
della Commissione Europea, con questo termine si intende “l’uso delle nuove tecnologie
multimediali e di Internet per migliorare la qualità dell’apprendimento, grazie ad un accesso
facilitato a risorse e servizi utili, nonché la possibilità di gestire scambi e collaborazioni a
distanza”. Le soluzioni di e-learning più attuali riconoscono l’importanza dell’apprendimento
come processo sociale, fornendo quindi opportunità di collaborazione con altri soggetti che
45
apprendono, di interazione con i materiali didattici e di guida da parte degli insegnanti, dei
fornitori e dei tutor. Questi approcci centrati su chi apprende offrono un’ampia gamma di risorse
di studio, personalizzate sulle sue esigenze.
e-procurement: acquisti elettronici. Processo di approvvigionamento di beni sviluppato
elettronicamente, mediante transazioni commerciali computerizzate.
ERP (Enterprise Resource Planning): letteralmente "pianificazione delle risorse aziendali".
L'espressione indica i software applicativi che gestiscono un insieme di attività aziendali.
Queste applicazioni sono in grado di supportare importanti processi di business, quali ad
esempio la pianificazione dei prodotti, la relazione con i fornitori, la gestione degli ordini e il
servizio clienti. "
F
Fibra ottica: filamento in fibra di vetro utilizzato nelle telecomunicazioni, in grado di
trasmettere segnali digitali ad alta velocità attraverso impulsi luminosi (anziché elettrici) e con
una capacità di portata notevolmente superiore a quella dei tradizionali cavi in rame. Ogni fibra
consiste di un'"anima" circondata da un rivestimento con un indice di rifrazione (deviazione dei
raggi luminosi) molto basso.
Firewall: letteralmente “muro tagliafuoco”. Insieme di software/hardware di sicurezza posto a
protezione di una rete o di un computer, che impedisce la comunicazione diretta con la rete e i
calcolatori esterni. Il firewall filtra i dati consentendo il passaggio solamente a determinati tipi
di file provenienti da determinati terminali o da determinati utenti.
Firma Digitale: il risultato della procedura informatica (validazione) basato su un sistema di
chiavi asimmetriche a coppia, una pubblica e una privata, che consente al sottoscrittore tramite
la chiave privata e al destinatario tramite la chiave pubblica, rispettivamente, di rendere
manifesta e di verificare la provenienza e l’integrità di un documento informatico o di un
insieme di documenti informatici.
G
Gateway (GW): Dispositivo che permette la connessione e lo scambio del traffico tra due reti
differenti.
H
HDSL (High bit rate Digital Subscriber Line): (Vedi anche xDSL e ADSL) tecnologia che
permette la trasmissione di dati a velocità elevate su linee telefoniche tradizionali. HDSL è una
tecnologia simmetrica, cioè fornisce la stessa velocità sia in trasmissione che in ricezione
(teoricamente fino a 155 Mbps).
Host: termine generico che identifica un computer connesso ad una rete (p.e. LAN, Internet,
Intranet) e quindi capace di comunicare con altri computer della rete (host).
Hosting: collocazione di un sito Web all'interno di un server Internet che funge da nodo della
rete. L'attività è svolta presso dei Provider che mettono a disposizione dei propri clienti una
parte dell'hard disk e una parte della capacità di elaborazione del proprio server, ospitandone i
siti. In questo modo gli utenti possono avere il loro sito senza necessariamente possedere un
proprio servizio
46
Housing: servizio di mantenimento presso una struttura di un server funzionante come nodo
Internet. Il servizio offerto dai Provider ai propri clienti permette a questi ultimi di risparmiare
sul costo delle reti e delle apparecchiature dedicate, necessarie a mantenere un server
stabilmente collegato alla Rete.
HRM – Human Resources Management HRM: gestione delle risorse umane. Gli strumenti
informatici utilizzati nelle relazioni tra l’azienda e i suoi dipendenti, considerati al tempo stesso
come un capitale e come un "cliente interno".
HTML (Hyper-Text Markup Language): è un linguaggio di programmazione estremamente
diffuso che consente di gestire contemporaneamente file di testo, grafica e suoni per creare
pagine Web.
I
ICT (Information Communication Technology): acronimo che sintetizza l’insieme della
tecnologie informatiche e di quelle delle telecomunicazioni.
Internet: rete internazionale composta da reti governative, accademiche, commerciali, militari e
aziendali di tutto il mondo. Gli utenti che accedono a Internet possono leggere e scaricare dati
pressoché su qualunque argomento da qualsiasi parte del mondo.
Interoperabilità: possibilità da parte dei software applicativi di interagire tra loro attraverso
formati aperti e standard, indipendenti da un singolo fornitore. Quando si parla di
interoperabilità tra applicazioni si intende la capacità di una data applicazione di sfruttare le
funzioni di un’altra applicazione; si dice che A e B interoperano se A è in grado di utilizzare le
funzioni di B e viceversa. L’aspetto cruciale è rappresentato dalla definizione di interfacce
applicative e modelli di interscambio pubblici (e possibilmente standard) che devono essere
definite e validate da parte delle autorità competenti o comunque condivise dal maggior numero
possibile di enti e produttori (standard di fatto).
Intranet: rete ad accesso regolato progettata per la gestione e lo scambio di informazioni
all'interno di un'organizzazione, sviluppata sulla base delle tecnologie Internet. In genere è
posseduta da un'azienda ed è finalizzata a consentire la condivisione delle risorse e delle
informazioni tra tutti i collaboratori interni che dispongono di un accesso. Può essere utilizzata
per svariate funzioni (distribuzione di documenti, condivisione di software, accesso a database,
formazione).
ISDN (Integrated Services Digital Network): tecnologia per la trasmissione digitale integrata di
dati e voce su linee telefoniche tradizionali. L'ISDN mette a disposizione due linee digitali che
permettono la trasmissione di voce e dati a 64 Kbps. Per la connessione ad Internet è possibile
utilizzare contemporaneamente entrambi i canali (arrivando così a 128 Kbps).
ISP (Internet Service Provider): fornitore di servizi quali accesso alla rete Internet e posta
elettronica.
J
Java: linguaggio di programmazione a oggetti per la costruzione di oggetti applicativi da
scaricare a distanza. Consente di realizzare applicazioni di dimensioni sufficientemente piccole
da poter essere scaricate via modem in pochi minuti.
47
L
LAN (Local Area Network): (letteralmente “rete d’area locale”) infrastruttura software e
hardware (schede di rete, cavi, switch) che interconnette un gruppo di computer e periferiche in
un ambiente circoscritto (un ufficio, un edificio o un piano) ed all’interno di un dominio di
amministrazione, in modo che non sia necessario ricorrere a servizi di telecomunicazione
esterni. Consente lo scambio diretto di dati in formato elettronico ad alta velocità fra più di due
computer.
M
MAN (Metropolitan Area Network): rete di trasmissione dati ad alta velocità che collega più
postazioni all’interno di una area metropolitana
MIT (Ministro per l’Innovazione e le Tecnologie): è un Ministro senza portafoglio al quale
sono state delegate, con il DPCM 9 agosto 2001, le funzioni del Presidente del Consiglio dei
Ministri in materia di innovazione e tecnologie.
N
Network: (letteralmente “rete”), sistema per collegare insieme vari computer, in modo che
possano condividere le risorse quali la memoria (disco fisso) e le periferiche (stampanti,
scanner) e comunicare tra loro. I network locali più conosciuti permettono ai computer di usare
e registrare programmi sul disk drive comune, ma non forniscono la comunicazione tra singoli
computer.
Nodo di rete: apparato in cui convergono (di solito per motivi di commutazione) vari flussi di
traffico della rete.
O
Open source: (letteralmente “sorgente aperta”) indica una modalità di rendere accessibile e
fruibile il codice con il quale viene scritto il software. Le licenze d'uso dei programmi
informatici che ricadono sotto questa definizione, che è simile a quella di "software libero",
devono rendere disponibile il codice sorgente del software a tutti coloro che lo usano e devono
rendere possibile la sua redistribuzione, modifica e redistribuzione delle modifiche stesse. La
licenza, inoltre, non deve contenere limitazioni sulle categorie di persone che ne possono trarre
vantaggio, né porre restrizioni sul tipo di software che può essere distribuito insieme a quello in
questione.
Outsourcing: assegnazione di attività a società esterne o consulenti. Permette, ad esempio, di
esternalizzare le operazioni di elaborazione dei dati invece che mantenere direttamente le risorse
umane, l'hardware e il software necessari.
P
POP (Point Of Presence): sito che ospita un insieme di apparati che consentono l’accesso ad
una rete di telecomunicazioni.
Portale: è un punto d'accesso ad Internet che aggrega e mette a disposizione degli utenti un
numero elevato d'informazioni e di servizi su un determinato argomento o settore (portale
verticale) o su più argomenti o settori e consente di accedere ad altre risorse on-line già
selezionate e classificate (es. Kataweb, Virgilio ecc.).
48
Protocollo: insieme di regole standard (sintattiche e semantiche) che permettono il
trasferimento, la ricezione ed il riconoscimento delle informazioni tra computer differenti.
Protocollo informatico: in Italia, il legislatore definisce protocollo informatico come “l'insieme
delle risorse di calcolo, degli apparati, delle reti di comunicazione e delle procedure
informatiche utilizzati dalle amministrazioni per la gestione dei documenti”, ovvero, tutte le
risorse tecnologiche necessarie alla realizzazione di un sistema automatico per la gestione
elettronica dei flussi documentali. Ogni sistema di protocollo informatico, che si intende
adottare o realizzare, deve ottemperare a specifiche indicazioni, riportate nel Testo Unico sulla
documentazione amministrativa (DPR 445/2000).
Provider: fornitore. Società specializzata nel fornire servizi o beni a valore aggiunto.
R
Rete: l'insieme di infrastrutture che consentono di trasportare le informazioni generate da una
sorgente a uno o più destinatari. Ogni utente ha bisogno di collegarsi soltanto con la rete e non
con tutti gli altri utenti.
Rete di accesso: l'insieme dei collegamenti che connettono l'utente con una rete per
l'utilizzazione dei servizi.
Router: nodo di commutazione a pacchetto di reti secondo il protocolli IP. Il dispositivo riceve
pacchetti IP lungo una rete di comunicazione, individua un cammino verso il punto di consegna
e invia il pacchetto al router successivo (o al terminale ricevente se questo è direttamente
raggiungibile).
RUPA / RUPAR: è la Rete Unitaria della Pubblica Amministrazione (e sue diramazioni
Regionali), prevista dalla legge n. 59 del 15 marzo 1997, che ha razionalizzato la situazione preesistente di una molteplicità di reti della PA, prevedendo un’unica rete omogenea per qualità,
sicurezza e costi. Sotto il profilo tecnologico le precedenti reti, realizzate con soluzioni
eterogenee (circuiti dedicati CDN, accessi X.25 e altri), si sono evolute in reti basate sul
protocollo Internet (IP) che hanno favorito l'utilizzo della posta elettronica e del web. (vedi
anche Servizio Pubblico di Connettività).
S
Server: computer su una rete locale dedicato allo svolgimento di un servizio preciso, come la
gestione della rete stessa, la gestione delle periferiche di stampa (print server), lo scambio e
condivisione di dati fra i computer (file server, database server). Un server può inoltre servire a
inviare o ricevere posta elettronica (mail server) o a contenere i file di un sito web (web server).
Server farm: sito dove sono raccolti server di operatori o clienti destinati a fornire servizi sulla
rete.
Service Provider: sono i fornitori di servizi in rete. Essi scelgono direttamente i "pacchetti di
servizi" da offrire agli utenti, e seguono tutte le fasi di commercializzazione del servizio alla
clientela (contratto, fatturazione, assistenza).
Servizi a banda larga: servizi resi disponibili grazie all'utilizzo di tecnologie innovative e che
si concretizzano nella convergenza di servizi di telecomunicazione, di diffusione e d'informatica
49
Sistema Pubblico di Connettività (SPC): è l’evoluzione in atto della RUPA, basata su un
approccio “multi-fornitore” e sulla qualificazione dei diversi attori partecipanti. L’SPC può
essere definito come "l’insieme di strutture organizzative, infrastrutture tecnologiche e regole
tecniche, per lo sviluppo, la condivisione, l’integrazione e la circolarità del patrimonio
informativo della pubblica amministrazione, necessarie per assicurare l’interoperabilità e la
cooperazione applicativa dei sistemi informatici e dei flussi informativi, garantendo la sicurezza
e la riservatezza delle informazioni."
SOAP (Simple Object Access Protocol ): protocollo che nasce come uno standard aziendale
progettato per migliorare l'interoperabilità, frutto del lavoro congiunto di aziende quali
Microsoft, DevelopMentor, IBM, Lotus Development, UserLand e Sun Microsystems. Tale
protocollo permette di costruire interfacce per lo scambio dei dati in formato XML tra
applicazioni diverse.
U
UMTS (Universal Mobile Telecommunications Standard): sistema di comunicazione mobile
di terza generazione, in grado di fornire dati a velocità superiori alle attuali, (capacità di banda
pari a 2 Mbps) nonché di fornire servizi multimediali ad alta risoluzione, quali quelli di banca
virtuale, di pagamento automatico, di commercio elettronico, di videoconferenza, di accesso ad
Internet e di trasmissione di musica ad alta fedeltà. Con l'UMTS il cellulare è diventato un
terminale multimediale in grado di ricevere comunicazioni voce, dati e immagini in movimento.
V
VPN (Virtual Private Network): rete privata virtuale. Una VPN permette di collegare reti
private (LAN) anche se geograficamente distanti, con gli stessi protocolli utilizzati per Internet.
W
WEB: letteralmente "ragnatela". Il termine (per esteso WWW World Wide Web, "ragnatela
mondiale") indica un servizio multimediale offerto su Internet. Da un punto di vista tecnico un
sito WWW è formato da documenti HTML (Hipertext Markup Lancguage) che vengono
distribuiti tramite il protocollo http.
Web Service: applicazione software identificata da un URI (sistema per indicare in modo
univoco una risorsa) la cui specifica può essere definita, descritta e pubblicata mediante
meccanismi basati su XML e che supporta l'interazione diretta con altre applicazioni mediante
messaggistica XML su protocolli Internet-based.
WiFi (Wireless Fidelity): si tratta di uno standard tecnologico di trasferimento dati attraverso
onde radio conosciuto tecnicamente come IEEE 802.11b (evoluto successivamente nella
variante “g”) che permette di implementare reti LAN senza fili (wireless) con velocità dai 5.5 a
oltre 100 Mbit/s
Wireless: (letteralmente, “senza fili”), sistema di trasmissione voce e dati che non fa uso di cavi,
ma che avviene attraverso le frequenze radio o mediante raggi laser.
Workflow: è l'automatizzazione di un processo (parziale o completa) nel corso della quale dei
documenti, delle informazioni o dei compiti passano da un partecipante all'altro, all'interno del
gruppo di lavoro, conformemente ad un insieme di regole predefinite. Un sistema di workflow
definisce, crea e gestisce l'esecuzione di tali processi.
X
50
XML (eXtensible Markup Language): linguaggio markup che struttura le informazioni in
modo che possano essere estratte ed utilizzate da altre applicazioni, come l'HTML, anche l'XML
utilizza dei marcatori che vengono adottati per strutturare e definire le informazioni e non per
visualizzarle. Un documento XML descrive un Web service e comprende informazioni che
specificano esattamente come quel Web service debba operare.
51
ALLEGATO 1
55
Legge n. 4 del 9 gennaio 2004
Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici
(G.U. n. 13 del 17 gennaio 2004)
------------------------------------------------La Camera dei deputati ed il Senato della Repubblica hanno approvato;
IL PRESIDENTE DELLA REPUBBLICA
Promulga
la seguente legge:
Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici
Art. 1
(Obiettivi e finalità)
1. La Repubblica riconosce e tutela il diritto di ogni persona ad accedere a tutte le fonti di
informazione e ai relativi servizi, ivi compresi quelli che si articolano attraverso gli strumenti
informatici e telematici.
2. È tutelato e garantito, in particolare, il diritto di accesso ai servizi informatici e telematici della
pubblica amministrazione e ai servizi di pubblica utilità da parte delle persone disabili, in
ottemperanza al principio di uguaglianza ai sensi dell'articolo 3 della Costituzione.
Art. 2
(Definizioni)
1. Ai fini della presente legge, si intende per:
a) «accessibilità»: la capacità dei sistemi informatici, nelle forme e nei limiti consentiti dalle
conoscenze tecnologiche, di erogare servizi e fornire informazioni fruibili, senza discriminazioni,
anche da parte di coloro che a causa di disabilità necessitano di tecnologie assistive o
configurazioni particolari;
b) «tecnologie assistive»: gli strumenti e le soluzioni tecniche, hardware e software, che
permettono alla persona disabile, superando o riducendo le condizioni di svantaggio, di accedere
alle informazioni e ai servizi erogati dai sistemi informatici.
Art. 3
(Soggetti erogatori)
1. La presente legge si applica alle pubbliche amministrazioni di cui al comma 2 dell'articolo 1 del
decreto legislativo 30 marzo 2001, n. 165, e successive modificazioni, agli enti pubblici economici,
alle aziende private concessionarie di servizi pubblici, alle aziende municipalizzate regionali, agli enti
di assistenza e di riabilitazione pubblici, alle aziende di trasporto e di telecomunicazione a
prevalente partecipazione di capitale pubblico e alle aziende appaltatrici di servizi informatici.
2. Le disposizioni della presente legge in ordine agli obblighi per l'accessibilità non si applicano ai
sistemi informatici destinati ad essere fruiti da gruppi di utenti dei quali, per disposizione di legge,
non possono fare parte persone disabili.
Art. 4
(Obblighi per l'accessibilità)
1. Nelle procedure svolte dai soggetti di cui all'articolo 3, comma 1, per l'acquisto di beni e per la
fornitura di servizi informatici, i requisiti di accessibilità stabiliti con il decreto di cui all'articolo 11
costituiscono motivo di preferenza a parità di ogni altra condizione nella valutazione dell'offerta
tecnica, tenuto conto della destinazione del bene o del servizio. La mancata considerazione dei
requisiti di accessibilità o l'eventuale acquisizione di beni o fornitura di servizi non accessibili è
adeguatamente motivata.
2. I soggetti di cui all'articolo 3, comma 1, non possono stipulare, a pena di nullità, contratti per la
realizzazione e la modifica di siti INTERNET quando non è previsto che essi rispettino i requisiti di
accessibilità stabiliti dal decreto di cui all'articolo 11. I contratti in essere alla data di entrata in
vigore del decreto di cui all'articolo 11, in caso di rinnovo, modifica o novazione, sono adeguati, a
pena di nullità, alle disposizioni della presente legge circa il rispetto dei requisiti di accessibilità, con
l'obiettivo di realizzare tale adeguamento entro dodici mesi dalla data di entrata in vigore del
medesimo decreto.
3. La concessione di contributi pubblici a soggetti privati per l'acquisto di beni e servizi informatici
destinati all'utilizzo da parte di lavoratori disabili o del pubblico, anche per la predisposizione di
postazioni di telelavoro, è subordinata alla rispondenza di tali beni e servizi ai requisiti di
accessibilità stabiliti dal decreto di cui all'articolo 11.
4. I datori di lavoro pubblici e privati pongono a disposizione del dipendente disabile la
strumentazione hardware e software e la tecnologia assistiva adeguata alla specifica disabilità,
anche in caso di telelavoro, in relazione alle mansioni effettivamente svolte. Ai datori di lavoro
privati si applica la disposizione di cui all'articolo 13, comma 1, lettera c), della legge 12 marzo
1999, n. 68.
5. I datori di lavoro pubblici provvedono all'attuazione del comma 4, nell'ambito delle disponibilità di
bilancio.
Art. 5
(Accessibilità degli strumenti didattici e formativi)
1. Le disposizioni della presente legge si applicano, altresì, al materiale formativo e didattico
utilizzato nelle scuole di ogni ordine e grado.
2. Le convenzioni stipulate tra il Ministero dell'istruzione, dell'università e della ricerca e le
associazioni di editori per la fornitura di libri alle biblioteche scolastiche prevedono sempre la
fornitura di copie su supporto digitale degli strumenti didattici fondamentali, accessibili agli alunni
disabili e agli insegnanti di sostegno, nell'ambito delle disponibilità di bilancio.
Art. 6
(Verifica dell'accessibilità su richiesta)
1. La Presidenza del Consiglio dei ministri - Dipartimento per l'innovazione e le tecnologie valuta su
richiesta l'accessibilità dei siti INTERNET o del materiale informatico prodotto da soggetti diversi da
quelli di cui all'articolo 3.
2. Con il regolamento di cui all'articolo 10 sono individuati:
a) le modalità con cui può essere richiesta la valutazione;
b) i criteri per la eventuale partecipazione del richiedente ai costi dell'operazione;
c) il marchio o logo con cui è reso manifesto il possesso del requisito dell'accessibilità;
d) le modalità con cui può essere verificato il permanere del requisito stesso.
Art. 7
(Compiti amministrativi)
1. La Presidenza del Consiglio dei ministri - Dipartimento per l'innovazione e le tecnologie, anche
avvalendosi del Centro nazionale per l'informatica nella pubblica amministrazione di cui all'articolo
4, comma 1, del decreto legislativo 12 febbraio 1993, n. 39, come sostituito dall'articolo 176 del
decreto legislativo 30 giugno 2003, n. 196:
a) effettua il monitoraggio dell'attuazione della presente legge;
b) vigila sul rispetto da parte delle amministrazioni statali delle disposizioni della presente legge;
c) indica i soggetti, pubblici o privati, che, oltre ad avere rispettato i requisiti tecnici indicati dal
decreto di cui all'articolo 11, si sono anche meritoriamente distinti per l'impegno nel perseguire le
finalità indicate dalla presente legge;
d) promuove, di concerto con il Ministero del lavoro e delle politiche sociali, progetti, iniziative e
programmi finalizzati al miglioramento e alla diffusione delle tecnologie assistive e per
l'accessibilità;
e) promuove, con le altre amministrazioni interessate, sentita la Conferenza permanente per i
rapporti tra lo Stato, le regioni e le province autonome di Trento e di Bolzano, l'erogazione di
finanziamenti finalizzati alla diffusione tra i disabili delle tecnologie assistive e degli strumenti
informatici dotati di configurazioni particolari e al sostegno di progetti di ricerca nel campo
dell'innovazione tecnologica per la vita indipendente e le pari opportunità dei disabili;
f) favorisce, di concerto con il Ministero del lavoro e delle politiche sociali e con il Ministro per le
pari opportunità, lo scambio di esperienze e di proposte fra associazioni di disabili, associazioni di
sviluppatori competenti in materia di accessibilità, amministrazioni pubbliche, operatori economici
e fornitori di hardware e software, anche per la proposta di nuove iniziative;
g) promuove, di concerto con i Ministeri dell'istruzione, dell'università e della ricerca e per i beni e
le attività culturali, iniziative per favorire l'accessibilità alle opere multimediali, anche attraverso
specifici progetti di ricerca e sperimentazione con il coinvolgimento delle associazioni delle persone
disabili; sulla base dei risultati delle sperimentazioni sono indicate, con decreto emanato di intesa
dai Ministri interessati, le regole tecniche per l'accessibilità alle opere multimediali;
h) definisce, di concerto con il Dipartimento della funzione pubblica della Presidenza del Consiglio
dei ministri, gli obiettivi di accessibilità delle pubbliche amministrazioni nello sviluppo dei sistemi
informatici, nonchè l'introduzione delle problematiche relative all'accessibilità nei programmi di
formazione del personale.
2. Le regioni, le province autonome e gli enti locali vigilano sull'attuazione da parte dei propri uffici
delle disposizioni della presente legge.
Art. 8
(Formazione)
1. Le amministrazioni di cui all'articolo 3, comma 1, nell'ambito delle attività di cui al comma 4
dell'articolo 7 del decreto legislativo 30 marzo 2001, n. 165, nonché dei corsi di formazione
organizzati dalla Scuola superiore della pubblica amministrazione, e nell'ambito delle attività per
l'alfabetizzazione informatica dei pubblici dipendenti di cui all'articolo 27, comma 8, lettera g), della
legge 16 gennaio 2003, n. 3, inseriscono tra le materie di studio a carattere fondamentale le
problematiche relative all'accessibilità e alle tecnologie assistive.
2. La formazione professionale di cui al comma 1 è effettuata con tecnologie accessibili.
3. Le amministrazioni di cui all'articolo 3, comma 1, nell'ambito delle disponibilità di bilancio,
predispongono corsi di aggiornamento professionale sull'accessibilità.
Art. 9
(Responsabilità)
1. L'inosservanza delle disposizioni della presente legge comporta responsabilità dirigenziale e
responsabilità disciplinare ai sensi degli articoli 21 e 55 del decreto legislativo 30 marzo 2001, n.
165, ferme restando le eventuali responsabilità penali e civili previste dalle norme vigenti.
Art. 10
(Regolamento di attuazione)
1. Entro novanta giorni dalla data di entrata in vigore della presente legge, con regolamento
emanato ai sensi dell'articolo 17, comma 1, della legge 23 agosto 1988, n. 400, sono definiti:
a) i criteri e i princìpi operativi e organizzativi generali per l'accessibilità;
b) i contenuti di cui all'articolo 6, comma 2;
c) i controlli esercitabili sugli operatori privati che hanno reso nota l'accessibilità dei propri siti e
delle proprie applicazioni informatiche;
d) i controlli esercitabili sui soggetti di cui all'articolo 3, comma 1.
2. Il regolamento di cui al comma 1 è adottato previa consultazione con le associazioni delle
persone disabili maggiormente rappresentative, con le associazioni di sviluppatori competenti in
materia di accessibilità e di produttori di hardware e software e previa acquisizione del parere delle
competenti Commissioni parlamentari, che devono pronunciarsi entro quarantacinque giorni dalla
richiesta, e d'intesa con la Conferenza unificata di cui all'articolo 8 del decreto legislativo 28 agosto
1997, n. 281.
Art. 11
(Requisiti tecnici)
1. Entro centoventi giorni dalla data di entrata in vigore della presente legge il Ministro per
l'innovazione e le tecnologie, consultate le associazioni delle persone disabili maggiormente
rappresentative, con proprio decreto stabilisce, nel rispetto dei criteri e dei princìpi indicati dal
regolamento di cui all'articolo 10:
a) le linee guida recanti i requisiti tecnici e i diversi livelli per l'accessibilità;
b) le metodologie tecniche per la verifica dell'accessibilità dei siti INTERNET, nonchè i programmi
di valutazione assistita utilizzabili a tale fine.
Art. 12
(Normative internazionali)
1. Il regolamento di cui all'articolo 10 e il decreto di cui all'articolo 11 sono emanati osservando le
linee guida indicate nelle comunicazioni, nelle raccomandazioni e nelle direttive sull'accessibilità
dell'Unione europea, nonchè nelle normative internazionalmente riconosciute e tenendo conto degli
indirizzi forniti dagli organismi pubblici e privati, anche internazionali, operanti nel settore.
2. Il decreto di cui all'articolo 11 è periodicamente aggiornato, con la medesima procedura, per il
tempestivo recepimento delle modifiche delle normative di cui al comma 1 e delle innovazioni
tecnologiche nel frattempo intervenute.
La presente legge, munita del sigillo dello Stato, sarà inserita nella Raccolta ufficiale degli atti
normativi della Repubblica Italiana. È fatto obbligo a chiunque spetti di osservarla e di farla
osservare come legge dello Stato.
Data a Roma, addì 9 gennaio 2004
CIAMPI
Berlusconi, Presidente del Consiglio dei Ministri
Stanca, Ministro per l'innovazione e le tecnologie
Visto, il Guardasigilli: Castelli
ALLEGATO 2
56
Decreto del 14 ottobre 2003
Approvazione delle linee guida per l'adozione del protocollo informatico
e per il trattamento informatico dei procedimenti amministrativi
(GU n. 249 del 25-10-2003)
--------------------------------------------------IL MINISTRO PER L’INNOVAZIONE E LE TECNOLOGIE
VISTO il decreto del Presidente del Consiglio dei Ministri del 9 agosto 2001, recante
“Delega di funzioni in materia di innovazione e tecnologie al Ministro senza
portafoglio, dott. Lucio Stanca”;
VISTO il decreto del Presidente della Repubblica 28 dicembre 2000, n. 445, recante “Testo
unico delle disposizioni legislative e regolamentari in materia di documentazione
amministrativa”;
VISTA la propria direttiva del 9 dicembre 2002, recante “Trasparenza dell’azione
amministrativa e gestione elettronica dei flussi documentali”;
VISTA la legge 27 dicembre 2002, n. 289, (legge finanziaria 2003) ed in particolare
l’articolo 26;
DECRETA
Articolo 1
1. Sono approvate le allegate linee guida per l’adozione del protocollo informatico e
per il trattamento informatico dei procedimenti amministrativi, che costituiscono parte
integrante del presente decreto.
Il presente decreto sarà pubblicato nella Gazzetta Ufficiale della Repubblica Italiana.
Roma, 14 ottobre 2003
IL MINISTRO
Lucio Stanca
ALLEGATO
L INEE G UIDA
PER L ’ADOZIONE DEL PROTOCOLLO INFORMATICO E PER IL TRATTAMENTO
INFORMATICO DEI PROCEDIMENTI AMMINISTRATIVI
2
INDICE
1
INTRODUZIONE E NORMATIVA DI RIFERIMENTO ............................................................................................4
1.1
1.2
2
SCOPO DELLE LINEE GUIDA E OBIETTIVI STRATEGICI.........................................................................................................5
CENTRO DI COMPETENZA ......................................................................................................................................................6
ADEMPIMENTI DELLE AMMINISTRAZIONI...........................................................................................................6
2.1 A NALISI ED INDIVIDUAZIONE DELLE A REE ORGANIZZATIVE OMOGENEE .....................................................................8
2.2 IL MANUALE DI GESTIONE......................................................................................................................................................9
2.2.1
Adozione di un protocollo unico............................................................................................................................ 10
2.2.2
Piano di sicurezza dei documenti informatici...................................................................................................... 11
2.2.3
Scambio di documenti.............................................................................................................................................. 11
2.2.4
Descrizione del flusso di lavorazione dei documenti.......................................................................................... 11
2.2.5
Regole di smistamento ed assegnazione dei documenti ricevuti...................................................................... 12
2.2.6
Unità organizzative responsabili delle attività di registrazione e della documentazione ......................... 12
2.2.7
Documenti esclusi dalla registrazione di protocollo.......................................................................................... 12
2.2.8
Il sistema di classificazione dei documenti.......................................................................................................... 13
2.2.9
Modalità di produzione e conservazione delle registrazioni............................................................................ 13
2.2.10 Funzionalità del sistema di protocollo informatico............................................................................................ 14
2.2.11 Abilitazioni per l’accesso al sistema documentale............................................................................................. 14
2.2.12 Il registro di emergenza........................................................................................................................................... 14
3
PIANO OPERATIVO ........................................................................................................................................................... 16
3.1
3.2
4
FUNZIONALITÀ MINIME DEL PROTOCOLLO ..................................................................................................... 18
4.1
4.2
4.3
5
REQUISITI DELLA REGISTRAZIONE DI PROTOCOLLO.........................................................................................................19
REQUISITI DELLA SEGNATURA DI PROTOCOLLO ...............................................................................................................19
REQUISITI DI SICUREZZA DEL SISTEMA DOCUMENTALE E DEL SISTEMA DI PROTOCOLLO INFORM ATICO.................20
GESTIONE DOCUMENTALE E GESTIONE DEI FLUSSI DI LAVORO ......................................................... 21
5.1
5.2
5.3
5.4
5.5
5.6
6
ORGANIZZAZIONE DEL PERSONALE E FORMAZIONE ........................................................................................................16
SERVIZI VERSO CITTADINI E IMPRESE .................................................................................................................................16
REQUISITI DEI DOCUMENTI INFORMATICI ..........................................................................................................................22
REQUISITI RELATIVI AI FORMATI DEI DOCUMENTI INFORMATICI ...................................................................................22
SISTEMI DI IDENTIFICAZIONE ED AUTENTICAZIONE .........................................................................................................23
CONSERVAZIONE ED ESIBIZIONE DEI DOCUMENTI INFORMATICI ....................................................................................23
REQUISITI PER LA GEST IONE INFORMATICA DEI DOCUMENTI .........................................................................................23
REQUISITI DEL SISTEMA PER LA GESTIONE DEI FLUSSI DOCUMENTALI..........................................................................24
CONTESTO TECNOLOGICO DI RIFERIMENTO .................................................................................................. 25
6.1
6.2
6.3
6.4
6.5
VERIFICA DI CONFORMITÀ ...................................................................................................................................................25
SERVIZIO DI GESTIONE DEL PROTOCOLLO INFORMATICO E DEI FLUSSI DOCUMENTALI IN MODALITÀ ASP.............25
INTEROPERABILITÀ DEI SISTEMI DI PROTOCOLLO.............................................................................................................26
POSTA CERTIFICATA..............................................................................................................................................................26
COOPERAZIONE APPLICATIVA .............................................................................................................................................27
3
1 INTRODUZIONE E NORMATIVA DI RIFERIMENTO
Con la direttiva del Ministro per l’innovazione e le tecnologie del 9 dicembre 2002 sono stati
definiti gli indirizzi per l’adozione delle norme in materia di protocollo informatico e di trattamento
elettronico dei procedimenti amministrativi.
Il protocollo informatico e, più in generale, la gestione elettronica dei flussi documentali hanno la
finalità di migliorare l’efficienza interna degli uffici attraverso l’eliminazione dei registri cartacei, la
riduzione degli uffici di protocollo e la razionalizzazione dei flussi documentali. L’adozione di tali
sistemi migliorerà inoltre la trasparenza dell'azione amministrativa attraverso strumenti che
facilitano l’accesso allo stato dei procedimenti ed ai relativi documenti da parte di cittadini, imprese
ed altre amministrazioni.
Le Pubbliche Amministrazioni dal 1° gennaio 2004, ai sensi dell’art. 50, comma 3, del decreto del
Presidente della Repubblica 28 dicembre 2000, n. 445, dovranno, quindi, attenersi ai principi e alle
norme di seguito indicati:
a) adozione del protocollo informatico per la registrazione dei dati e documenti delle
Amministrazioni (art. 50 e ss. del D.P.R. 445/2000; decreto del Presidente del Consiglio dei
ministri 31 ottobre 2000, pubblicato sulla Gazzetta Ufficiale del 21 novembre 2000, n. 272);
b) trattamento dei procedimenti amministrativi gestito completamente in modo informatico
(legge 7 agosto 1990, n. 241; D.P.R. 445/2000; decreto legislativo 23 gennaio 2002, n. 10);
c) formazione e conservazione dei documenti informatici (deliberazione Aipa 51/2000,
pubblicata sulla Gazzetta Ufficiale del 14 dicembre 2000, n. 291; deliberazione Aipa
42/2001, pubblicata sulla Gazzetta Ufficiale del 21 dicembre 2001, n. 296);
d) sottoscrizione elettronica dei documenti informatici (d.lgs.10/2002; decreto del Presidente
del Consiglio dei ministri 8 febbraio 1999; decreto del Presidente della Repubblica 7 aprile
2003, n. 137 - “Regolamento di attuazione della direttiva Comunitaria 93/1999” - su firma
elettronica);
e) gestione informatica del sistema documentale e dei flussi documentali (deliberazione Aipa
51/2000; deliberazione Aipa 42/2001; D.P.R. 445/2000);
f) accessi telematici ai dati, ai documenti, ai sistemi, alle banche dati (D.P.R. 445/2000, artt.
58, 59 e 60);
g) sicurezza dei dati, dei documenti, delle tecnologie (decreto legislativo 30 giugno 2003,
n.196; deliberazione Aipa 51/2000, art. 10; D.P.C.M. 31.10.2000, art. 7);
h) direttiva sulla formazione del Ministro per la funzione pubblica del 13 dicembre 2001,
pubblicata su Gazzetta Ufficiale del 31 gennaio 2002, n. 26;
i) disposizioni per la formazione del bilancio annuale e pluriennale dello Stato (Legge 27
dicembre 2002, n. 289, art. 26).
Si tratta di un quadro unitario nell’ambito del quale il protocollo informatico può essere adottato
secondo due tipi di approccio, il primo completo ed il secondo caratterizzato da una gradualità nella
realizzazione:
1) nel primo caso, protocollo, automazione della gestione e dell’ iter delle attività,formazione e
conservazione dei documenti informatici costituiscono un unico sistema di “governo
elettronico”;
2) nel secondo caso, il protocollo informatico si pone come il punto di avvio di un sistema
amministrativo informatico nel quale l’informazione utilizzata è solo di tipo
4
“digitale”,valida in quanto tale, e l’informazione su supporti documentali cartacei viene
“trasformata” in digitale.
Ogni Amministrazione, in base alla propria situazione organizzativa e tecnologica, ferma restando
la scadenza del 1° gennaio 2004, dovrà valutare la possibilità di adottare l’uno o l’altro approccio,
partendo eventualmente da quello minimale per poi evolvere gradualmente verso un sistema
gestionale completamente automatizzato.
In tutti i casi, il livello minimale deve essere finalizzato a creare non solo un sistema di protocollo
in linea con la normativa ma anche un sistema documentale che si caratterizza per essere un sistema
digitale, con la relativa eliminazione dei documenti cartacei una volta trasformati in digitale.
1.1 Scopo delle linee guida e obiettivi strategici
Lo scopo del presente documento è quello di contribuire a creare, fornendo un quadro unitario ed
aggiornato, le condizioni organizzative, funzionali e tecnologiche per la progettazione, la
realizzazione, lo sviluppo e la revisione dei sistemi informativi automatizzati al fine di avviare,
entro l’anno 2003 e quindi dal 1° gennaio 2004, il protocollo informatico e gestire i procedimenti
amministrativi in modo elettronico. Il documento è rivolto a tutte le Amministrazioni pubbliche e si
prefigge di fornire alle stessa un supporto nell’interpretazione e attuazione delle leggi, al fine di
contribuire a promuovere una revisione sostanziale dei procedimenti amministrativi, cogliendo così
lo spirito della norma che ha inteso creare i presupposti di una semplificazione dei procedimenti
amministrativi ed una maggior trasparenza dei processi verso il cittadino e l’impresa.
Nel documento vengono esaminati gli adempimenti delle Amministrazioni, le funzionalità minime,
la gestione documentale e la gestione dei flussi lavorativi, dando risalto alle attività che
l’Amministrazione deve svolgere per ciascuna delle suddette fasi.
Le linee guida in particolare riguardano:
1. gli adempimenti ai quali sono tenute le Amministrazioni:
• assicurare le funzionalità minime di protocollo;
• procedere all’archiviazione della documentazione sulla base del criterio per cui tutta
la documentazione in ingresso diventa “digitale” secondo la normativa tecnica;
• pianificare le attività al fine di realizzare un sistema di base protocollo-archiviazione
che permetta di avviare il sistema documentale informatico sostitutivo di quello
cartaceo;
• accedere al protocollo-archivio informatico “solo” tramite una rete interna
all’amministrazione anche al fine di eliminare la duplicazione di documenti e
fascicoli cartacei, con significative economie gestionali sia interne sia per l’utenza;
• pianificare le attività finalizzate alla gestione informatica dei procedimenti
amministrativi al fine di sostituire, anche in modo graduale, il trattamento manuale
degli stessi procedimenti;
2. la funzionalità minima da assicurare per l’avvio del protocollo informatico;
3. i requisiti dei sistemi documentali e procedimentali che costituiscono un vincolo
progettuale e realizzativo ma anche una opportunità per avviare modalità omogenee di
operatività;
4. aspetti tecnologici.
Le presenti linee guida forniscono un quadro di riferimento generale di carattere normativo e,
unitamente ai precedenti documenti emessi dall’Aipa, “Studio di prefattibilità sul Sistema di
gestione dei flussi di documenti (Sistema GEDOC)”,"Linee guida alla realizzazione dei sistemi di
protocollo informatico e gestione dei flussi documentali nelle pubbliche amministrazioni"
5
(GEDOC2), “Interoperabilità dei sistemi di protocollo informatico in ambiente distribuito”, e a
quelli in via di elaborazione, intende offrire un insieme organico di strumenti di supporto per le
Amministrazioni.
1.2 Centro di Competenza
Con la Direttiva del 9 dicembre 2002 pubblicata sulla Gazzetta Ufficiale del 5 marzo 2003, n. 53, il
Ministro per l’innovazione e le tecnologie, ha creato presso il Centro Tecnico per la R.U.P.A. un
Centro di competenza per il Progetto Protocollo informatico e trasparenza amministrativa quale
unico punto di riferimento, che svolge, in continuità con le attività già svolte dall’Aipa, funzioni di
indirizzo e coordinamento e che promuove iniziative di affiancamento per garantire l'attuazione
della Direttiva, in particolare attraverso:
• le informazioni, le esperienze e i servizi messi a disposizione sul sito web sulla gestione
elettronica dei documenti (http://protocollo.gov.it), le cui finalità sono la condivisione delle
migliori pratiche e la sussidiarietà;
• la collaborazione fornita dal Centro di competenza che può essere contattato al seguente
indirizzo di posta elettronica: [email protected];
• incontri periodici con i referenti delle Amministrazioni allo scopo di verificare lo stato di
avanzamento delle attività.
Tra i suoi compiti in particolare si segnalano:
•
•
•
azioni di sensibilizzazione e comunicazione;
rilevazione periodica dello stato di attuazione dei progetti;
supporto alle amministrazioni, secondo un principio di sussidiarietà, attraverso l’erogazione di
un servizio di gestione del protocollo informatico e dei flussi documentali in modalità ASP.
2 ADEMPIMENTI DELLE AMMINISTRAZIONI
Le Pubbliche Amministrazioni, al fine di adottare entro il 1° gennaio 2004 il protocollo informatico
e gestire i procedimenti amministrativi in modo elettronico, sono tenute ai seguenti interventi:
a) provvedere ad introdurre, nei piani di sviluppo dei sistemi informativi automatizzati,
progetti per la realizzazione di sistemi di protocollo informatico (art. 50, comma 1, del
D.P.R.445/2000).
b) predisporre appositi progetti esecutivi per la sostituzione dei registri di protocollo cartacei
con sistemi informatici (art. 50, comma 2, del D.P.R. 445/2000);
c) realizzare o revisionare i propri sistemi informativi (art. 50, comma 3, del D.P.R. 445/2000);
I progetti dovranno essere pianificati in termini organizzativi, funzionali, tecnologici e finanziari,
nel rispetto della data del 1° gennaio 2004. Il progetto esecutivo ha lo scopo di definire attività,
tempi e costo-benefici per l’operazione di sostituzione anche ai sensi della Deliberazione Aipa
42/2001.
Il sistema informativo viene considerato come un insieme integrato di dati, funzioni e tecnologie
finalizzato non solo alla registrazione di dati e documenti in ingresso ed in uscita, ma anche
6
all’automazione del sistema procedimentale e documentale (protocollo, iter delle attività, atti e
provvedimenti, documenti e modulistica, accessi telematici).
Le Amministrazioni hanno l’obbligo di operare attraverso un piano di automazione adottato o da
adottare, con riferimento al proprio ordinamento, per attuare quanto stabilito dal D.P.R. 445/2000 e
secondo le norme tecniche vigenti (art. 51, comma 1, del D.P.R. 445/2000).
Le stesse devono rivedere i sistemi informativi al fine di realizzare una automazione totale delle fasi
di produzione, gestione, diffusione ed utilizzazione dei propri dati, documenti, procedimenti ed atti
(art. 51, comma 2, del D.P.R. 445/2000).
Gli interventi dovranno quindi comprendere una necessaria e preliminare azione di
razionalizzazione e semplificazione delle attività, dei procedimenti, della documentazione e della
modulistica (art.3, comma 3, della Deliberazione Aipa 51/2000).
Allo scopo di fornire un promemoria e un valido supporto per una corretta scanzione temporale
delle attività sopra riportate, la Direttiva del Ministro per l’innovazione e le tecnologie ha previsto
fasi intermedie fino alla scadenza del 1 gennaio 2004. A questo fine le Amministrazioni che non
abbiano ancora provveduto devono definire, con la massima tempestività, un piano d'azione
dettagliato - il quale preveda lo svolgimento delle attività sotto elencate tenendo conto della citata
scadenza per l'adozione del sistema di protocollo informatico - e comunicare tale piano al Centro
Tecnico per la R.U.P.A., tramite il sito web http://protocollo.gov.it.
Più in dettaglio è necessario:
1. individuare le Aree Organizzative Omogenee (AOO) e i relativi uffici di riferimento ai sensi
dell’articolo 50, comma 4, del D.P.R. n.445/2000;
2. comunicare al Centro Tecnico la casella ufficiale di posta elettronica per l’iscrizione delle
AOO nell'indice delle P.A.;
3. comunicare al Centro Tecnico, per ogni AOO istituita, il nominativo del responsabile del
servizio per la tenuta del protocollo informatico, della gestione dei flussi documentali e degli
archivi, ai sensi dell’articolo 61, comma 2, del DPR n. 445/2000;
4. adottare, per ogni AOO istituita, il manuale di gestione come previsto dalle regole tecniche
di cui all’articolo 5 del D.P.C.M. 31 ottobre 2000;
5. pubblicare e rendere accessibile tramite internet il manuale di gestione che descrive il
sistema di gestione e di conservazione dei documenti e fornisce le istruzioni necessarie per il
corretto funzionamento del servizio per la tenuta del protocollo informatico (cfr. par.2.1.1);
6. predisporre un progetto operativo per la progressiva messa in opera di sistemi di protocollo
informatico integrati con la posta elettronica certificata e la firma elettronica ai sensi
dell'articolo 10, comma 3, del D.P.R. 445/2000 nel rispetto dei principi di interoperabilità di
cui alla circolare Aipa del 7 maggio 2001;
7. predisporre correlate attività di formazione, d’intesa con il Dipartimento della funzione
pubblica ai sensi della Direttiva sulla formazione del Ministro per la funzione pubblica del
13 dicembre 2001;
8. fornire informazioni al Centro Tecnico per la R.U.P.A. sull’avanzamento dei progetti, al fine
di permettere delle rilevazioni periodiche sullo stato di attuazione della normativa.
Inoltre, le Amministrazioni, per l'attuazione della trasparenza dell'attività amministrativa, devono
svolgere, ove non vi abbiano provveduto entro la prevista scadenza, le seguenti azioni:
1. comunicare al Centro Tecnico il nome di un referente, al fine di definire le attività di
interesse comune e concordarne i relativi tempi di realizzazione;
2. individuare i servizi di propria competenza erogati ai cittadini e alle imprese sia con
modalità tradizionali sia in rete;
7
3. pianificare, secondo criteri di priorità, l'attuazione della trasparenza dell'azione
amministrativa come definita in precedenza, tramite la predisposizione di progetti orientati a
fornire ai cittadini e alle imprese servizi informativi con canali telematici diretti o attraverso
intermediazione dell'Ufficio Relazioni con il Pubblico;
4. migliorare la comunicazione tra gli uffici e gli URP al fine di migliorare la comunicazione
esterna e l’esercizio del diritto di accesso;
5. compilare, per ogni progetto una scheda informativa, secondo lo schema riportato in allegato
alla Direttiva, da inviare al Centro tecnico.
Le Amministrazioni, poi, con riferimento al proprio ordinamento, devono:
a) pianificare le attività per la eliminazione dei diversi tipi di protocollo attivati, di cui
all’articolo 3, comma 1,lettera d) del 31 ottobre 2000;
b) accreditare l’Amministrazione presso l’IPA - Indice della Pubblica Amministrazione
(articolo 12 del D.P.C.M. 31 ottobre 2000 recante Regole tecniche per il protocollo
informatico); informazioni in proposito si trovano sul sito http://indicepa.gov.it
La Direttiva è indirizzata a tutte le Amministrazioni centrali dello Stato e agli enti pubblici
sottoposti alla vigilanza ministeriale. Per le regioni e gli enti locali territoriali la stessa costituisce
contributo alle determinazioni in materia, nel rispetto della propria autonomia amministrativa. La
Direttiva può rappresentare uno schema di riferimento anche per le altre Amministrazioni pubbliche
di cui all’articolo 1, comma 2, del decreto legislativo 30 marzo 2001, n. 165.
2.1 Analisi ed individuazione delle Aree Organizzative
Omogenee
Analisi organizzativa
Preliminarmente si dovrebbe procedere all’analisi dei processi per
articolandola per fasi:
la loro semplificazione,
fase 1: definizione del campo di applicazione dell’intervento organizzativo
passo 1 – identificare l’ambito e i livelli di intervento;
passo 2 – delineare il contesto;
passo 3 – fissare gli obiettivi;
fase 2: diagnosi delle criticità e delle priorità;
passo 4 - ricostruire la mappa dei processi reali;
passo 5 – definire le metriche della prestazione complessiva di processo;
passo 6 – misurare la distanza fra obiettivi e situazione attuale;
fase 3: riprogettazione dei processi;
passo 7 – disegnare le alternative di riprogettazione;
passo 8 – progettare il sistema di monitoraggio e controllo;
passo 9 – preparare la gestione del cambiamento organizzativo;
passo 10 – sperimentare e correggere le ipotesi di riprogettazione.
8
Definizione delle Aree Organizzative Omogenee
Attraverso la individuazione e la definizione delle Aree Organizzative Omogenee (AOO) si
rideterminano gli ambiti dei nuovi sistemi di protocollo informatico. Questa individuazione
consente di arrivare ad una diminuzione e semplificazione dell'insieme dei sistemi di protocollo
oggi esistenti. Il fenomeno della frammentazione dei registri di protocollo è una delle maggiori
cause di inefficienze nella gestione dei documenti delle Pubbliche Amministrazioni. Tra le
conseguenze negative derivanti da tale frammentazione va certamente citata la ripetuta
protocollazione del documento (con annesse le operazione di registrazione di dati ridondanti) ad
ogni passaggio anche tra strutture interne alla stessa Amministrazione, oltre alle notevoli difficoltà
di reperimento del documento protocollato tali da rendere, paradossalmente, l'individuazione della
collocazione fisica del documento un problema secondario rispetto all'individuazione del registro di
protocollo in cui esso è stato registrato.
Una AOO può essere definita come un insieme di unità organizzative dell’Amministrazione che
usufruiscono, in modo omogeneo e coordinato, degli stessi servizi per la gestione dei flussi
documentali. Una unità organizzativa associata ad una AOO è un utente dei servizi messi a
disposizione dalla AOO stessa. Una AOO offre, in particolare, il servizio di protocollo dei
documenti in entrata ed in uscita che avviene utilizzando una unica sequenza numerica, rinnovata
ad ogni anno solare, propria all’area stessa (art. 61 D.P.R.445/2000) . Per ulteriori approfondimenti
si può fare riferimento al documento "Linee guida alla realizzazione dei sistemi di protocollo
informatico e gestione dei flussi documentali nelle pubbliche amministrazioni" (GEDOC2).
Le Amministrazioni, al termine di questo processo di analisi, devono comunicare al Centro Tecnico
per la R.U.P.A. la casella ufficiale di posta elettronica per l’iscrizione delle AOO nell'Indice della
Pubblica Amministrazione.
2.2 Il manuale di gestione
Il manuale di gestione, di cui all’articolo 5 del D.P.C.M. 31 ottobre 2000, descrive il sistema di
gestione e di conservazione dei documenti e fornisce le istruzioni per il corretto funzionamento del
servizio per la tenuta del protocollo informatico.
Il responsabile del servizio di cui all’articolo 61 del D.P.R. 445/2000 ha il compito di predisporre
lo schema del manuale di gestione.
L’articolo 5 del predetto decreto è strutturato come un “indice” del manuale e cio’ facilita la
redazione dello stesso; sono citati in particolare i seguenti punti:
a) la pianificazione, le modalità e le misure di cui all’articolo 3, comma 1, lettera d);
b) il piano di sicurezza dei documenti informatici di cui all’articolo 4, comma 4;
c) le modalità di utilizzo di strumenti informatici per lo scambio di documenti all’interno ed
all’esterno dell’area organizzativa omogenea;
d) la descrizione del flusso di lavorazione dei documenti ricevuti, spediti o interni, incluse le regole
di registrazione per i documenti pervenuti secondo particolari modalità di trasmissione, tra i quali,
in particolare, documenti informatici di fatto pervenuti per canali diversi da quelli previsti
dall’articolo 15 del presente decreto, nonché fax, raccomandata, assicurata;
e) l’indicazione delle regole di smistamento ed assegnazione dei documenti ricevuti con la specifica
dei criteri per l’ulteriore eventuale inoltro dei documenti verso aree organizzative omogenee della
stessa amministrazione e/o verso altre amministrazioni;
f) l’indicazione delle unità organizzative responsabili delle attività di registrazione di protocollo, di
organizzazione e tenuta dei documenti all’interno dell’area organizzativa omogenea;
g) l’elenco dei documenti esclusi dalla registrazione di protocollo;
h) l’elenco dei documenti soggetti a registrazione particolare e le relative modalità di trattamento;
9
i) il sistema di classificazione, con l’indicazione delle modalità di aggiornamento, integrato con le
informazioni relative ai tempi, ai criteri e alle regole di selezione e conservazione, anche con
riferimento all’uso di supporti sostitutivi;
l) le modalità di produzione e di conservazione delle registrazioni di protocollo informatico ed in
particolare l’indicazione delle soluzioni tecnologiche ed organizzative adottate per garantire la non
modificabilità della registrazione di protocollo, la contemporaneità della stessa con l’operazione di
segnatura, nonché le modalità di registrazione delle informazioni annullate o modificate nell’ambito
di ogni sessione di attività di registrazione;
m) la descrizione funzionale ed operativa del sistema di protocollo informatico con particolare
riferimento alle modalità di utilizzo;
n) i criteri e le modalità per il rilascio delle abilitazioni di accesso interno ed esterno alle
informazioni documentali;
o) le modalità di utilizzo del registro di emergenza, inclusa la funzione di recupero dei dati
protocollati manualmente.
La corretta ed efficace attuazione delle norme in materia di protocollo e di sistema documentale
informatico è strettamente correlata alla redazione del manuale.
Per sua natura e struttura il manuale comprende analisi, decisioni, piani, iter delle attività,
classificazioni, ecc., definiti in relazione alle specificità organizzative, funzionali, strutturali e di
servizio dell’ Amministrazione di riferimento.
E’ compito dei dirigenti e dei funzionari partecipare alla redazione del manuale per quanto riguarda
le informazioni relative all’unità organizzativa di competenza, anche in relazione alla pubblicità del
manuale stesso.
Il manuale di gestione deve essere reso pubblico ed accessibile sia tramite internet (possibilmente
sul sito del protocollo), sia attraverso supporti informatici o cartacei; deve essere redatto in modo
chiaro, completo, e deve essere periodicamente aggiornato.
Il manuale è quindi l’insieme delle regole certificate dall’Amministrazione per un corretto ed
efficace funzionamento del sistema di protocollo, dei procedimenti amministrativi informatici e del
sistema documentale.
Lo schema del manuale è “comune” (di tipo “standard”) ma la redazione non può che essere
effettuata su “misura” dell’Amministrazione di riferimento, in quanto sono compresi interventi di
tipo organizzativo, procedurale ed informatico specifici dell’ente in questione, non “trasferibili”, in
modo asettico e generalizzato, a tutti gli organismi pubblici.
Una bozza di schema del manuale può essere consultata sul sito http://protocollo.gov.it. Alcune
indicazioni utili per la redazione del manuale sono ricavabili anche da alcuni esempi già realizzati
pubblicati sul sito http://protocollo.gov.it.
Nei paragrafi che seguono sono riportati brevi suggerimenti sulle attività previste nell’ambito della
redazione del manuale.
2.2.1 Adozione di un protocollo unico.
Gli obiettivi da realizzare sono i seguenti:
pianificazione, modalità e misure di cui all’articolo 3, comma 1, lettera d) del D.P.C.M. 31 ottobre
2000: eliminazione dei diversi protocolli di settore, di reparto, multipli per l’adozione di un unico
protocollo (art.5, comma 2,lett. a).
Le attività che discendono dall’applicazione della norma sono le seguenti:
•
censimento dei diversi protocolli;
10
•
•
•
•
analisi dei livelli di automazione;
interventi organizzativi, procedurali e tecnici da effettuare per adottare il protocollo
informatico;
tempi di sostituzione;
costi.
2.2.2 Piano di sicurezza dei documenti informatici
Il responsabile del servizio di cui all’articolo 61 del D.P.R. 445/2000 ha il compito di predisporre
il piano di sicurezza secondo quanto previsto dall’articolo 5, comma 2, lett. b), del D.P.C.M. 31
ottobre 2000.
Le attività che discendono dall’applicazione della norma sono le seguenti:
•
•
•
•
•
analisi dei rischi in relazione alla tipologia dei documenti;
analisi dei rischi in relazione alla tipologia dei dati personali (D.lgs. 196/2003);
misure di sicurezza da adottare di tipo organizzativo, procedurale e tecnico;
formazione dei dipendenti;
monitoraggio periodico del piano di sicurezza.
In particolare, il manuale dovrà fare riferimento ai requisiti di sicurezza di cui al punto 2.2.11.
2.2.3 Scambio di documenti.
Con riferimento alle modalità di utilizzo di strumenti informatici per lo scambio di documenti
all’interno ed all’esterno dell’area organizzativa omogenea, di cui all’articolo 5, comma 2, lett. c),
del D.P.C.M. 31 ottobre 2000, le attività che discendono dall’applicazione della norma sono le
seguenti:
•
•
•
rilevazione dei flussi documentali all’interno dell’ente (o delle AOO) e verso altri enti (o
altre AOO);
mappatura dei flussi;
modalità e tecnologie per lo scambio dei documenti.
La rilevazione dei flussi documentali è facilitata se viene effettuata nell’ambito di un censimento
più ampio che comprenda anche le attività, le procedure, i procedimenti, la modulistica utilizzata (v.
il punto successivo).
2.2.4 Descrizione del flusso di lavorazione dei documenti
La descrizione nel flusso documentale dei documenti ricevuti, spediti o interni di cui all’articolo 5,
comma 2, lett.d), del D.P.C.M. 31 ottobre 2000, costituisce l’aspetto fondamentale di tutto il
processo di automazione del sistema documentale e procedimentale in quanto solo la conoscenza
completa dell’iter delle attività permette di realizzare anche un processo di automazione in linea con
i principi di trasparenza, efficienza, efficacia ed economicità.
Le attività che discendono dall’applicazione della norma sono le seguenti:
11
•
•
•
•
•
censimento di tutte le attività dell’ente (o dell’area organizzativa omogenea) al fine di
descrivere la lavorazione dei documenti; il censimento dovrebbe riguardare i dati di base di
ciascuna attività (denominazione,allocazione, durata,flusso procedurale,modulistica, norme
di riferimento, fasi, risorse umane impegnate,pareri,ecc.);
analisi del risultato del censimento;
interventi di razionalizzazione delle singole attività;
piano di automazione delle attività;
regole di registrazione dei documenti.
2.2.5 Regole di smistamento ed assegnazione dei documenti ricevuti.
Le attività che discendono dall’applicazione della norma di cui all’articolo 5, comma 2, lett. e) del
D.P.C.M. 31 ottobre 2000, concernenti le regole di smistamento ed assegnazione dei documenti
ricevuti, sono le seguenti:
•
•
a seguito della registrazione dei documenti in entrata è necessario stabilire le regole per lo
smistamento, l’assegnazione e la lavorazione degli stessi da parte dei responsabili dei
procedimenti e nell’ambito delle aree organizzative omogenee;
se si considera che i documenti sono per definizione “informatici” (o resi tali, se ricevuti
come cartacei) allora sarà necessario definire con chiarezza e completezza le modalità di
smistamento ed assegnazione di tipo elettronico, anche in considerazione di quanto
stabilisce la legge 241/90 ed il relativo regolamento.
2.2.6 Unità organizzative responsabili delle attività di registrazione e della
documentazione
Le attività che discendono dall’applicazione della norma di cui articolo 5, comma 2, lett. f), del
D.P.C.M. 31 ottobre 2000, concernente le unità organizzative responsabili delle attività di
registrazione e della documentazione sono le seguenti:
•
nell’ambito dell’area organizzativa omogenea, e con riferimento al sistema organizzativo
dell’ente, è necessario indicare le unità organizzative responsabili delle attività di
registrazione e di organizzazione e tenuta della documentazione;
•
nel manuale sarà necessario quindi definire le funzioni specifiche di tali unità organizzative
ed il profilo dei dipendenti che operano in tali unità.
2.2.7 Documenti esclusi dalla registrazione di protocollo
Le attività che discendono dall’applicazione della norma di cui all’articolo 5, comma 2, lett. G e H
del D.P.C.M. 31 ottobre 2000, concernenti i documenti esclusi dalla registrazione di protocollo,
sono le seguenti:
•
riportare nel manuale l’elenco dei documenti esclusi dalla registrazione di protocollo ai sensi
dell’articolo 53, comma 5, del D.P.R. 445/2000.
12
•
riportare l’elenco dei documenti soggetti a registrazione particolare e le relative modalità di
trattamento.
Tali documenti vanno individuati dall’Amministrazione e possono essere registrati attraverso
applicazioni diverse dal sistema di protocollo informatico.
2.2.8 Il sistema di classificazione dei documenti
Il sistema di classificazione è lo strumento che permette di organizzare tutti i documenti secondo un
ordinamento logico, con riferimento alle funzioni e alle attività dell’Amministrazione interessata.
Le attività che discendono dall’applicazione della norma di cui all’articolo 5, comma 2, lett. i), del
D.P.C.M. 31 ottobre 2000, sono le seguenti:
•
il sistema di classificazione dei documenti dovrà essere definito in ragione dell’ordinamento,
dell’organizzazione e dei servizi della stessa Amministrazione.
In particolare, la classificazione dovrà basarsi sui seguenti principi:
•
•
•
omogeneità tematica che caratterizza la stessa AOO (omogeneità funzionale) e che da questa
viene prodotta a sua volta;
autonomia dei documenti rispetto alla struttura organizzativa di riferimento che nel tempo
può’ anche mutare di denominazione, articolazione e funzioni;
reperibilità del documento, in primo luogo, rispetto all’argomento ed ai contenuti e, in
secondo luogo, rispetto alla struttura organizzativa di riferimento.
Il sistema di classificazione può seguire le regole generali definite dalla classificazione decimale.
I sistemi di ricerca elettronica dovranno tenere conto del sistema di classificazione.
Nel manuale dovranno essere indicate inoltre:
• le modalità di aggiornamento del sistema;
• tempi,criteri e regole di selezione e di conservazione;
• l’uso di supporti sostitutivi.
Ulteriori suggerimenti possono essere trovati nel documento "Linee guida alla realizzazione dei
sistemi di protocollo informatico e gestione dei flussi documentali nelle pubbliche amministrazioni
(GEDOC2)", reperibile nel sito web http://protocollo.gov.it.
2.2.9 Modalità di produzione e conservazione delle registrazioni
Le attività che discendono dall’applicazione della norma di cui all’art. 5, comma 2, lett. l), del
D.P.C.M. 31 ottobre 2000, concernenti le modalità di produzione e conservazione delle
registrazioni, consistono nel riportare nel manuale:
•
•
•
le modalità di produzione e di conservazione delle registrazioni di protocollo informatico;
l’indicazione delle soluzioni tecnologiche ed organizzative adottate per garantire la non
modificabilità della registrazione di protocollo;
la contemporaneità della registrazione con l’operazione di segnatura;
13
•
le modalità di registrazione delle informazioni annullate o modificate nell’ambito di ogni
sessione di attività di registrazione.
In particolare, per quanto riguarda le informazioni annullate il manuale dovrà fare riferimento a
quanto stabilito nell’articolo 8 del D.P.C.M. 31 ottobre 2000 (Annullamento delle informazioni
registrate in forma non modificabile).
2.2.10
Funzionalità del sistema di protocollo informatico
Le attività che discendono dall’applicazione della norma di cui all’articolo 5, comma 2, lett. m),
del D.P.C.M. 31 ottobre 2000, concernenti la funzionalità del sistema di protocollo informatico
sono le seguenti:
•
•
2.2.11
Il manuale deve contenere la descrizione funzionale ed operativa del sistema di protocollo
informatico con particolare riferimento alle modalità d’uso;
la descrizione dovrà essere effettuata con lo scopo di indicare con chiarezza e completezza
l’utilizzabilità del sistema da parte di tutti coloro che sono abilitati ad operare nel sistema
documentale e procedimentale dell’amministrazione. Il grado di chiarezza e completezza è
strettamente correlato al grado di chiarezza e completezza di tutte le regole descritte nel
manuale.
Abilitazioni per l’accesso al sistema documentale
Le attività che discendono dall’applicazione della norma di cui all’articolo 5, comma 2, lett. n), del
D.P.C.M. 31 ottobre 2000, consistono nell’individuazione, con riferimento al tipo di accesso, dei
criteri e delle modalità per il rilascio delle abilitazioni all’interno e all’esterno dell’amministrazione.
Il manuale deve pertanto contenere la descrizione delle politiche di accesso ai documenti che
l’Amministrazione intende adottare:
• definendo, relativamente all’accesso ai documenti per gli utenti interni, i criteri di visibilità sulla
base di ruoli e funzioni svolte dai dipendenti.
• classificando, per quanto riguarda l’acceso da parte di utenti esterni (cittadini, imprese, altre
amministrazioni), le modalità relative in due tipologie:
−dirette se l’amministrazione ha previsto una canale di comunicazione con l’esterno in
maniera automatizzata (es. via internet)
−indirette nel caso in cui l’amministrazione permetta l’accesso ai documenti tramite una
struttura di contatto con l’esterno (es. Ufficio Relazioni con il Pubblico, Call center ecc.)
2.2.12
Registro di emergenza
Le attività che discendono dall’applicazione della norma di cui all’articolo 5, comma 2, lett. o), del
D.P.C.M. 31 ottobre 2000, concernente il registro di emergenza, sono le seguenti:
•
riportare sul registro di emergenza la causa, la data e l’ora di inizio dell’interruzione nonché
la data e l’ora del ripristino della funzionalità del sistema (art. 63, comma 1 del D.P.R.
445/2000);
14
•
•
il responsabile del servizio per la tenuta del protocollo informatico, della gestione dei flussi
documentali e degli archivi deve dare l’autorizzazione ad operare in modo manuale (art. 63,
comma 1 del D.P.R. 445/2000);
riportare sul registro di emergenza le autorizzazioni all’uso di procedure manuali per periodi
successivi alle 24 ore ed il numero totale di operazioni registrate manualmente.
15
3 PIANO OPERATIVO
Il piano di attuazione prevede un censimento preliminare dei diversi protocolli esistenti, l’ analisi
dei livelli di automazione, ma soprattutto gli interventi organizzativi, procedurali e tecnici da
effettuare per adottare il protocollo informatico con i tempi di sostituzione e i costi derivanti. Uno
dei primi obiettivi che ciascuna Amministrazione si deve dare nel definire un progetto di
informatizzazione dei flussi documentali, è quello di individuare il proprio “livello realizzativo”,
corrispondente alle funzionalità che essa stessa vuole realizzare.
Le Amministrazioni definiscono quindi un piano d'azione dettagliato che preveda lo svolgimento
delle attività elencate nel paragrafo 2, tenendo conto della citata scadenza del 1 gennaio 2004,
prevista dal DPR 445/2000 per l'adozione del sistema di protocollo informatico. Tale piano d'azione
deve essere inviato al Centro Tecnico per la R.U.P.A. attraverso il sito http://protocollo.gov.it.
3.1 Organizzazione del personale e formazione
Nella fase di analisi organizzativa, gli elementi principali da tenere in considerazione sono:
•
•
•
•
•
•
•
la formazione culturale del personale;
il piano di formazione obbligatorio ai sensi della Direttiva della Funzione Pubblica del 13
dicembre 2001;
il dimensionamento degli organici tenendo presente la diversa organizzazione derivante
dall’introduzione di un protocollo informatico (scadenze e tempi di inserimento dei
documenti da protocollare);
l’organizzazione di un servizio di help desk per gli utilizzatori del protocollo;
la definizione dei profili professionali;
l’assegnazione di incarichi di coordinamento;
l’individuazione di referenti e capi progetto a seconda delle dimensioni
dell’Amministrazione e quindi della tipologia di progetto previsto.
All’analisi organizzativa si deve affiancare un progetto di formazione e comunicazione che deve
essere di esempio e di impulso per l’intera Amministrazione . Deve essere in particolare prevista la
realizzazione di un programma di formazione differenziato a seconda dei destinatari e articolato in
moduli sia teorici che operativi per avviare e monitorare il processo di evoluzione delle competenze
manageriali e professionali al fine di renderle più rispondenti e coerenti con le nuove esigenze. Il
programma di formazione dovrà essere integrato da interventi di comunicazione, opportunamente
pianificati, volti a migliorare il coinvolgimento e la sensibilizzazione del personale, promuovendone
l’adesione agli obiettivi da raggiungere.
3.2 Servizi verso cittadini e imprese
Lo sviluppo della Società dell’Informazione è una delle priorità del Governo: in questo contesto la
prestazione di servizi on- line assume una particolare rilevanza.
La finalità da perseguire è quella di permettere a cittadini e imprese di conoscere in tempi reali le
informazioni relative allo stato delle attività amministrative di proprio interesse, migliorando di
conseguenza l’efficienza, l’efficacia e l’immagine della Pubblica Amministrazione.
16
Il D.P.R. 445/2000, con riferimento ai principi stabiliti dalla legge 241/1990, ha definito tre tipi di
accesso ai dati, documenti ed informazioni del sistema informatico:
a) l’accesso al sistema da parte degli utenti appartenenti all’Amministrazione (art.58 del D.P.R.
445/2000);
b) l’accesso esterno al sistema da parte dei soggetti che esercitano il diritto di accesso ai
documenti amministrativi (art.59 del D.P.R. 445/2000);
c) l’accesso al sistema di una pubblica amministrazione da parte di altre amministrazioni
(art.60 del D.P.R. 445/2000).
Per tutti i tipi di accesso, anche ai sensi della D.lgs 196/2003, le Amministrazioni dovranno definire
le abilitazioni necessarie e le diverse modalità di interrogazione, selezione ed estrazione delle
informazioni, a seconda del grado di riservatezza delle stesse e della tipologia di utenti, utilizzando
firma digitale o certificati di autenticazione.
In seguito, quindi, per l’accesso sicuro ai documenti potranno essere previste diverse modalità di
identificazione e accreditamento degli utenti tramite strumenti quali la carta d’identità elettronica o
la carta nazionale dei servizi.
17
4 FUNZIONALITÀ MINIME DEL PROTOCOLLO
Le Amministrazioni devono garantire almeno la realizzazione del sistema di protocollo secondo i
requisiti di operazioni ed informazioni,definite “funzionalità minime”, di cui agli articoli 53, 55 e
56 del D.P.R. 445/2000. Le operazioni di registrazione e di segnatura di protocollo indicate
rispettivamente all’articolo 53 e all’articolo 55 nonché quelle di classificazione costituiscono
attività necessarie e sufficienti per la tenuta del sistema di gestione informatica dei documenti da
parte delle pubbliche amministrazioni. In particolare si sottolinea che
a) con riferimento ai requisiti della registrazione, la registrazione di protocollo per ogni
documento ricevuto o spedito dalle pubbliche amministrazioni è effettuata mediante la
memorizzazione delle seguenti informazioni:
• numero di protocollo del documento generato automaticamente dal sistema e registrato
in forma non modificabile;
• data di registrazione di protocollo assegnata automaticamente dal sistema e registrata in
forma non modificabile;
• mittente per i documenti ricevuti o, in alternativa, il destinatario o i destinatari per i
documenti spediti, registrati in forma non modificabile;
• oggetto del documento, registrato in forma non modificabile;
• data e protocollo del documento ricevuto, se disponibili;
• l’impronta del documento informatico, se trasmesso per via telematica, costituita dalla
sequenza di simboli binari in grado di identificarne univocamente il contenuto, registrata
in forma non modificabile.
b) con riferimento ai requisiti della segnatura, le informazioni minime previste sono:
• il progressivo di protocollo, secondo il formato disciplinato all’articolo 57;
• la data di protocollo;
• l'identificazione in forma sintetica dell’amministrazione o dell’area organizzativa
individuata ai sensi dell'articolo 50, comma 4.
c) con riferimento alla classificazione dei documenti, vedasi punto precedente 2.2.8.
Il piano di classificazione o titolario di archivio si presenta, generalmente, come uno schema
generale di voci logiche, stabilite in modo uniforme, rispondenti ai bisogni funzionali del soggetto
produttore e articolate tendenzialmente in modo gerarchico al fine di identificare secondo uno
schema logico che va dal generale al particolare l’unità archivistica, cioè l’unità di aggregazione di
base dei documenti all'interno dell’archivio (ad esempio, il fascicolo, il registro, ecc.) entro cui i
documenti sono ordinati secondo le funzioni/attività/affari e/o materie di cui partecipano.
Per garantire le funzionalità minime, sotto il profilo documentale e tecnologico, il sistema di
protocollo sarà costituito da risorse informatiche destinate non solo alla registrazione e alla
segnatura ma anche alla conservazione della documentazione, secondo la deliberazione Aipa n.
42/2001 al fine di rendere concreto l’accesso alla documentazione da parte dei dipendenti abilitati
sia in modalità locale che remota.
Nei paragrafi seguenti vengono presentati i requisiti normativi applicabili per la realizzazione del
nucleo minimo in un sistema di protocollo informatico.
18
4.1 Requisiti della registrazione di protocollo
La registrazione di protocollo per ogni documento ricevuto o spedito dalle pubbliche
amministrazioni secondo l’articolo 53 del D.P.R. 445/2000 è effettuata mediante la memorizzazione
delle seguenti informazioni:
•
•
•
•
•
numero di protocollo del documento generato automaticamente dal sistema e registrato
in forma non modificabile;
data di registrazione di protocollo assegnata automaticamente dal sistema e registrata in
forma non modificabile;
mittente per i documenti ricevuti o, in alternativa, il destinatario o i destinatari per i
documenti spediti, registrati in forma non modificabile;
data e protocollo del documento ricevuto, se disponibili;
l’impronta del documento informatico, se trasmesso per via telematica, costituita dalla
sequenza di simboli binari in grado di identificarne univocamente il contenuto, registrata
in forma non modificabile.
Altri requisiti previsti:
•
Il sistema deve consentire la produzione del registro giornaliero di protocollo (art.53,
comma 2, del D.P.R. 445/2000);
•
L’assegnazione delle informazioni nelle operazioni di registrazione di protocollo è effettuata
dal sistema in unica soluzione, con esclusione di interventi intermedi, anche indiretti, da
parte dell’operatore, garantendo la completezza dell’intera operazione di modifica o
registrazione dei dati;
•
Per quanto riguarda l’impronta del documento si rinvia a quanto definito dall’articolo 17 del
D.P.C.M. 31 ottobre 2000.
Tutti i requisiti sopra riportati permettono di costruire un sistema di protocollo a supporto della
trasparenza e della certezza del sistema amministrativo.
4.2 Requisiti della segnatura di protocollo
Le informazioni minime previste per la segnatura secondo l’articolo 55 del D.P.R.445/2000 sono:
a) il progressivo di protocollo, secondo il formato di cui all’articolo 57;
b) la data di protocollo;
c) l’identificazione in forma sintetica dell’amministrazione o dell’area organizzativa
individuata ai sensi dell’articolo 50, comma 4.
Le informazioni da includere nella segnatura sono definite dall’articolo 19 del D.P.C.M. 31 ottobre
2000.
L’operazione di segnatura di protocollo va effettuata contemporaneamente all’operazione di
registrazione di protocollo.
Per quanto riguarda i requisiti del formato di segnatura si rinvia all’articolo 9 del D.P.C.M. 31
ottobre 2000.
19
Per ciò che concerne la segnatura dei documenti trasmessi si rinvia all’articolo 18 del D.P.C.M. 31
ottobre 2000.
4.3 Requisiti di sicurezza del sistema documentale e del
sistema di protocollo informatico
Il piano di sicurezza dei documenti informatici è previsto dall’articolo 7 del DPCM 31 ottobre 2000
e dall’articolo 10 della deliberazione Aipa n. 51 del 2000, in attuazione dell’articolo 18 del D.P.R.
513/97, come modificato dall’art. 9, comma 4 del D.P.R. 445/2000.
Il piano di sicurezza deve considerare almeno i seguenti aspetti:
• analisi dei rischi;
• politiche di sicurezza;
• interventi operativi;
• misure di sicurezza per la tutela dei dati personali;
• verifica ed aggiornamento del piano.
In particolare, l’articolo 7 del D.P.C.M. 31 ottobre 2000 definisce i requisiti minimi di sicurezza
dei sistemi di protocollo informatico.
20
5 GESTIONE DOCUMENTALE E GESTIONE DEI FLUSSI DI
LAVORO
Per Gestione documentale si intende la gestione informatica dei documenti in modalità avanzata.
Si tratta di una soluzione che privilegia ed esalta essenzialmente le potenzialità legate alla gestione
informatizzata dei documenti e degli archivi. Essa consiste in realtà in attività assai eterogenee, che
variano a seconda del grado di funzionalità da attuare, ma che trovano il loro comune presupposto
fondamentale nella dematerializzazione dei documenti cartacei e quindi della disponibilità degli
stessi a livello informatico.
Essa prevede le seguenti attività:
• registrazione con trattamento delle immagini (acquisizione digitalizzata dei documenti
cartacei);
• assegnazione per via telematica al destinatario;
• gestio ne avanzata della classificazione dei documenti;
• collegamento dei documenti alla gestione dei procedimenti.
A queste può aggiungersi la realizzazione di uno specifico archivio documentale per quei
documenti di alto contenuto informativo che meritano uno specifico trattamento (prevedendo ad
esempio la creazione di compendi, l'uso di parole chiave per una indicizzazione più dettagliata,
ecc.).
La gestione dei flussi di lavoro realizza le seguenti funzionalità (vedasi punto precedente 2.2.4):
• informatizzazione dei processi relativi ai flussi documentali in entrata e in uscita;
• informatizzazione dei processi relativi ai flussi documentali interni;
• integrazione con i flussi di lavoro.
Questa ultima fase è quella che prevede la reingegnerizzazione dei processi dell’Amministrazione al
fine di una loro successiva informatizzazione: in particolare vengono gestiti mediante sistemi
integrati di flussi di lavoro tutti quei processi che possiedono i requisiti di complessità, ripetitività e
stabilità dell’iter.
E’ evidente che se lo scopo da perseguire è la revisione e la razionalizzazione dei processi
amministrativi (Business Process Reengeneering), il raggiungimento di tale obiettivo è
propedeutico per l’attuazione anche del Progetto Protocollo e Gestione documentale.
Per poter affrontare i problemi specifici di una corretta gestione elettronica dei documenti, è
opportuno analizzare, in sintesi, natura e finalità del sistema documentario, nonché le attività
principali che lo caratterizzano, a cominciare dal concetto e dalla funzione del documento, dalla
definizione di sistema documentario e di archivio, dall'analisi delle principali funzioni che
caratterizzano nel modello organizzativo e normativo italiano la formazione dei documenti
(registrazione dei documenti e registrazione di protocollo, classificazione d'archivio), nonché la
tenuta degli archivi e gli aspetti organizzativi (le funzioni del Servizio per la tenuta dei documenti e
degli archivi, il manuale di gestione previsto dalle regole tecniche del D.P.R. 428/98).
Nella più recente attività normativa italiana, a partire dalla legge 241/1990, il documento è definito
in quanto rappresentazione del contenuto di atti. L'elemento qualificante dell'entità documentaria
(cioè la ragione della sua produzione e tenuta) è, infatti, costituito dalla relazione con l'attività
amministrativa e pratica cui partecipa in quanto strumento di memorizzazione stabile nel tempo e
nello spazio.
21
I requisiti per l’adozione del protocollo informatico ed il trattamento elettronico dei procedimenti
amministrativi riguardano il documento informatico, il formato dei documenti informatici, la firma
digitale, l’archiviazione dei documenti, l’accesso telematico, la sicurezza.
I requisiti vincolano le Amministrazioni non solo sul piano organizzativo e tecnologico ma anche
per quanto attiene le acquisizioni dei relativi servizi e tecnologie tramite le procedure di appalto.
I requisiti definiti dal legislatore riguardano:
•
•
•
•
•
i documenti informatici;
i formati relativi ai documenti informatici;
la firma digitale nei documenti informatici;
la gestione informatica dei documenti;
la gestione dei flussi documentali.
5.1 Requisiti dei documenti informatici
La formazione e la conservazione dei documenti informatici delle Pubbliche Amministrazioni (art.3
della deliberazione Aipa 51/2000) devono essere effettuate secondo i seguenti requisiti:
•
•
•
•
•
•
identificabilità del soggetto che ha formato il documento informatico e dell’amministrazione
di riferimento;
sottoscrizione, quando prescritta, dei documenti informatici tramite la firma digitale ai sensi
del D.lgs 10/2002 e delle vigenti norme tecniche;
idoneità dei documenti ad essere gestiti mediante strumenti informatici e ad essere registrati
mediante il protocollo informatico, ai sensi del D.P.R. 445/2000;
accessibilità ai documenti informatici tramite sistemi informativi automatizzati;
leggibilità dei documenti;
interscambiabilità dei documenti.
Il legislatore sottolinea che solo l’esistenza di tutti i requisiti rende validi e rilevanti i documenti a
tutti gli effetti di legge (art.3, comma 2, della Deliberazione Aipa 51/2000).
La formazione e la conservazione non sono considerate dal legislatore solo una operazione
tecnologica ma, prima dell’intervento di automazione, il sistema documentale e procedimentale
devono essere sottoposti a processi di semplificazione e razionalizzazione (legge 241/90; art.3,
comma 3, della Deliberazione Aipa 51/2000).
I contenuti e la struttura dei documenti sono definiti dalla dirigenza e nell’ambito dell’autonomia
delle Amministrazioni, con riferimento all’ordinamento delle stesse(art.3, comma 4, Deliberazione
Aipa 51/2000).
In particolare, per quanto riguarda le modalità di trasmissione e registrazione dei documenti
informatici si rinvia a quanto stabilito dall’art. 15 del D.P.C.M. 31 ottobre 2000.
Per la leggibilità dei documenti nel tempo si rinvia a quanto stabilito dall’articolo 16 del D.P.C.M.
31 ottobre 2000 e alla deliberazione Aipa n. 42/2001 che sostituisce la precedente deliberazione n.
24/1998.
5.2 Requisiti relativi ai formati dei documenti informatici.
I formati adottati devono possedere almeno i seguenti requisiti (art. 4 della Deliberazione Aipa n.
51/2000):
22
•
•
•
•
•
consentire, nei diversi ambiti di applicazione e per le diverse tipologie di trattazione,
l’archiviazione, la facilità di lettura, l’interoperabilità e l’interscambio dei documenti;
la non alterabilità del documento durante le fasi di accesso e di conservazione;
la possibilità di effettuare operazioni di ricerca tramite indici di classificazione e di
archiviazione, nonché sui contenuti dei documenti;
l’immutabilità nel tempo del contenuto e della sua struttura (per cui i documenti informatici
non devono contenere macroistruzioni o codice eseguibile, tali da attivare funzionalità che
possano modificarne la struttura o il contenuto);
la possibilità di integrare il documento informatico con immagini, suoni e video, purché
incorporati in modo irreversibile e nel rispetto dei requisiti di cui alle lettere b) e d) della
citata deliberazione.
5.3 Sistemi di identificazione ed autenticazione
Per la formazione e la gestione di documenti informatici per i quali non è prevista la sottoscrizione,
le Pubbliche Amministrazioni possono utilizzare sistemi elettronici di identificazione ed
autenticazione nell’ambito della propria autonomia organizzativa e dei processi di razionalizzazione
(art. 5, comma 3, della Deliberazione Aipa 51/2000).
5.4 Conservazione ed esibizione dei documenti informatici
Per la conservazione e la esibizione dei documenti informatici (art. 7 della Deliberazione Aipa n.
51/2000) si applicano le norme di cui alla deliberazione Aipa n. 42/2001 e agli articoli 60 e 61 del
DPCM 8 febbraio 1999 e successive modificazioni ed integrazioni.
Attraverso la conservazione elettronica dei documenti si eviteranno duplicazioni e accumuli di
copie cartacee e verrà favorita la trasformazione graduale degli archivi cartacei della P.A. in sistemi
informativi automatizzati ad alto livello di sicurezza ed affidabilità. Inoltre, sarà possibile realizzare
sistemi di ricerca più efficaci e più efficienti. Al riguardo si sta ultimando la stesura di un
documento rivolto alle Amministrazioni, recante linee guida per l’archiviazione e per la
conservazione documentale; tale documento intende ampliare il presente contesto, esaminando
anche alcuni aspetti dell’archiviazione e della conservazione digitale strettamente connessi ai
processi di archiviazione sostitutiva.
5.5 Requisiti per la gestione informatica dei documenti
Il sistema di gestione informatica dei documenti (art. 52 del D.P.R. 445/2000) deve:
•
•
•
•
garantire la sicurezza e l’integrità del sistema;
garantire la corretta e la puntuale registrazione di protocollo dei documenti in entrata ed in
uscita;
fornire informazioni sul collegamento esistente tra ciascun documento ricevuto
dall’Amministrazione e gli atti dalla stessa formati al fine dell’adozione del provvedimento
finale;
consentire il reperimento delle informazioni riguardanti i documenti registrati;
23
•
•
consentire, in condizioni di sicurezza, l’accesso alle informazioni del sistema da parte dei
soggetti interessati, nel rispetto delle disposizioni in materia di “privacy” con particolare
riferimento al trattamento dei dati sensibili;
garantire la corretta organizzazione dei documenti nell’ambito del sistema di classificazione
d’archivio adottato.
Gli interventi sopra indicati esprimono un sistema di gestione documentale di tipo integrato,
definito in tutti i suoi aspetti strutturali, funzionali e relazionali sotto il profilo documentale,
organizzativo ed informatico. La gestione documentale di questo tipo non può essere delegata solo
ai responsabili dei sistemi informatici; soggetti interessati sono anche i dirigenti e/o i responsabili
delle diverse unità organizzative, i quali decidono le regole interne da adottare in materia
documentale.
5.6 Requisiti del sistema per la gestione dei flussi documentali
Il sistema per la gestione dei flussi documentali, oltre a possedere i requisiti di cui all’articolo 52 del
D.P.R. 445/2000, ai sensi dell’articolo 65 del D.P.R. 445/2000, deve anche:
•
•
•
•
fornire informazioni sul legame esistente tra ciascun documento registrato, il fascicolo ed il
singolo procedimento cui esso è associato;
consentire il rapido reperimento delle informazioni riguardanti i fascicoli, il procedimento
ed il relativo responsabile, nonché la gestione delle fasi del procedimento;
fornire informazioni statistiche sull’attività dell’ufficio;
consentire lo scambio di informazioni con sistemi per la gestione dei flussi documentali di
altre amministrazioni al fine di determinare lo stato e l’iter dei procedimenti complessi.
Tale sistema di gestione dei documenti e dei relativi flussi è di tipo “aperto”, totalmente
informatico, e deve quindi essere progettato e realizzato in tutte le sue componenti “prima”
dell’automazione del sistema stesso. Ciò significa che le amministrazioni devono definire tipologia
dei documenti, relazioni tra documenti e procedimenti, struttura dei fascicoli relativi ai
procedimenti, iter dei procedimenti stessi, sistemi di ricerca dei documenti e dei fascicoli. Anche in
questo caso, non si tratta di una operazione informatica ma di un intervento complesso di tipo
documentale, organizzativo, procedurale e tecnico che deve impegnare tutta la dirigenza e/o i
responsabili delle unità organizzative.
24
6 CONTESTO TECNOLOGICO DI RIFERIMENTO
Al fine di adottare un sistema di protocollo informatico a norma del D.P.R. 445/2000, da parte di
ciascuna Amministrazione deve esserne valutato l’impatto sul sistema informativo.
Le indicazioni in merito alla soluzione da adottare dipendono dal contesto specifico. Per le
architetture di riferimento si può consultare il documento ”Linee guida alla realizzazione dei sistemi
di protocollo informatico e gestione dei flussi documentali nelle pubbliche amministrazioni”
(GEDOC 2), pubblicato dall’Autorità per l’informatica nella pubblica amministrazione nel
settembre 2000. Tuttavia, qualunque sia la soluzione tecnologica adottata, si deve tenere presente
che il sistema deve essere dotato di alta affidabilità ed in particolare devono essere previste le
soluzioni di emergenza in caso di caduta del sistema, in quanto l’applicazione ai processi di lavoro
di ciascuna Amministrazione può risultare particolarmente critica (D.P.C.M. 31 ottobre 2000, art.7 Requisiti minimi di sicurezza dei sistemi di protocollo informatico). A tal fine è necessario
approntare un piano e delle procedure di sicurezza (vedasi punto precedente 2.2.2), e le
informazioni trattate devono rispondere ai principi di riservatezza imposti dalla normativa sulla
“privacy”.
6.1 Verifica di conformità
Allo scopo di fornire un ausilio alle Amministrazioni nell’attuazione del progetto di automazione
della tenuta del protocollo e della gestione elettronica dei documenti ed in particolare nella verifica
delle funzionalità dell’applicazione realizzata/acquisita, il Centro di Competenza ha redatto e
pubblicato (cfr. http://protocollo.gov.it) il documento “Supporto alla verifica e alla valutazione dei
Sistemi di protocollo informatico e di gestione dei flussi documentali”, contenente una lista di
controllo per la verifica della conformità di tali sistemi ai requisiti desumibili dal quadro di
riferimento normativo e tecnologico.
Inoltre, tutte le Amministrazioni, indipendentemente dalla scelta effettuata, possono trovare in tale
documento un elenco di requisiti di tipo organizzativo che specifica il contesto organizzativo e di
processo coerente con l’introduzione del sistema di protocollo informatico.
6.2 Servizio di gestione del protocollo informatico e dei flussi
documentali in modalità ASP
Al fine di fornire ulteriori strumenti per l’attuazione della normativa sulla gestione elettronica dei
documenti, il Centro Tecnico per la R.U.P.A. ha promosso la realizzazione di un servizio di
gestione del protocollo informatico e dei flussi documentali in modalità ASP per le pubbliche
amministrazioni. Con questo obiettivo il Centro tecnico, avvalendosi della Consip nella funzione di
stazione appaltante, ha in corso di espletamento la procedura di gara per l’affidamento del servizio
ad operatori di mercato (vedasi bando per la procedura di gara ristretta pubblicato sul sito
http://protocollo.gov.it).
Il servizio offerto alle Amministrazioni si articola in:
- REPRO - Gestione nucleo minimo protocollo
- GEDOC - Gestione documentale
- STORE – Archiviazione ottica dei documenti
- Altri servizi accessori tra cui servizi di supporto, consulenza organizzativa (BPR); formazione.
25
La fornitura sarà regolata da un contratto quadro stipulato tra il fornitore aggiudicatario e il Centro
Tecnico per al R.U.P.A. della durata di 48 mesi prorogabile per ulteriori 24 mesi. Tale servizio è
rivolto a tutte le Pubbliche Amministrazioni previste dal Decreto legislativo 165/2001 che devono
manifestare al Centro Tecnico la loro volontà di aderire attraverso la sottoscrizione di una specifica
convenzione pubblicata sul sito http://protocollo.gov.it. Le Amministrazioni potranno usufruire del
servizio emettendo specifici “Ordinativi di fornitura” nell’ambito del contratto quadro, sottoscritto
dal Centro Tecnico con il fornitore aggiudicatario.
L’Amministrazione aderente potrà usufruire in modo flessibile di qualsiasi servizio tra quelli
previsti dalla fornitura con il solo vincolo di aderire al servizio REPRO per un periodo di almeno 24
mesi. I servizi GEDOC, STORE e gli altri servizi accessori, potranno essere richiesti solo dopo aver
aderito al servizio di base REPRO. Alla scadenza del contratto verrà fornito all’Amministrazione il
software applicativo e la relativa documentazione .
Qualora l’adesione delle Amministrazioni superi i massimali previsti per la fornitura in corso di
aggiudicazione, il Centro Tecnico provvederà a bandire ulteriori gare per l’aggiudicazione di nuove
forniture. In tal caso, in caso si manifesti l’esigenza da parte di gruppi di Amministrazioni locali
aggregate a livello territoriale, il Centro Tecnico potrà verificare la possibilità di specializzare la
fornitura sul territorio, favorendo la gestione locale di analoghe iniziative.
Il servizio proposto è fortemente innovativo in quanto, in attuazione delle norme finalizzate alla
semplificazione dei procedimenti amministrativi, applica il principio del “riuso” del software di
proprietà del Ministero dell'economia e delle finanze e si avvale per la prima volta di un servizio
erogato in modalità ASP. Tali scelte permettono, da un lato, di rendere disponibile il servizio in
tempi rapidi, dall’altro, di limitare i costi a carico delle Amministrazioni a quelli relativi
all’effettivo utilizzo del servizio (costi a consumo).
6.3 Interoperabilità dei sistemi di protocollo
La circolare Aipa del 7 maggio 2001 recepisce le indicazioni presenti nel D.P.R. 445/2000 e
fornisce le regole tecniche per l’interoperabilità dei sistemi di protocollo, ossia per il “trattamento
automatico, da parte di un sistema di protocollo ricevente, delle informazioni trasmesse da un
sistema di protocollo mittente, allo scopo di automatizzare le attività ed i processi amministrativi
conseguenti”.
Il Centro Tecnico rende disponibili alcune caselle di posta elettronica da utilizzate per effettuare i
test di interoperabilità dei sistemi di protocollo informatico.
6.4 Posta certificata
Laddove lo scambio dei flussi comporta uno scambio documentale lo strumento tecnico a supporto
è la posta certificata. Quest’ultima, ai sensi dell’articolo 14 del D.P.R. 445/2000, è un servizio di
messaggistica che, attraverso l’utilizzo dei relativi standard, è in grado di fornire ricevute di
recapito. Le stesse, firmate elettronicamente dal sistema emittente, sono messaggi generati
automaticamente dal servizio di posta certificata, recanti una serie di informazioni che
caratterizzano l’evento cui sono associate. Ulteriori funzionalità accessorie riguardano la garanzia
della confidenzialità, dell’integrità, e della storicizzazione delle ricevute di recapito. Il servizio di
posta certificata è strettamente correlato all’Indice della PA, poiché in esso sono pubblicati gli
indirizzi di posta certificata associati alle AOO e alle funzioni organizzative eventualmente previste
dalle Amministrazioni.
26
6.5 Cooperazione applicativa
Tra gli obiettivi del piano d’azione di e- government, necessari a mettere in atto procedure di
trasparenza degli atti amministrativi, l’erogazione di servizi integrati ai cittadini e alle imprese
implica l’integrazione tra i servizi di diverse Amministrazioni.
Sul piano tecnologico ciò si traduce nell’adozione di uno standard comune per le singole interazioni
tra le Pubbliche Amministrazioni, definito nella busta di e-government allegata al relativo Bando e
nelle successive specifiche indicazioni che verranno fornite da parte del Centro tecnico per la
R.U.P.A..
27
ALLEGATO 3
57
Emesso da:
Titolo documento:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Codice doc.:
Area infrastrutture nazionali condivise
Guida ai servizi di
Indice delle amministrazioni pubbliche e delle
aree organizzative omogenee
e
Posta Elettronica Certificata
Guida_IndicePA_PostaCert.doc
Pagina 1 di 32
Emesso da:
Titolo documento:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Codice doc.:
INDICE
1.
MODIFICHE DOCUMENTO........................................................................................................................ 3
2.
RIFERIMENTI................................................................................................................................................ 3
3.
TERMINI E DEFINIZIONI .......................................................................................................................... 4
4.
OBIETTIVI E CONTENUTI DEL DOCUMENTO..................................................................................... 5
5.
I SERVIZI IN SINTESI................................................................................................................................... 5
5.1.
5.2.
6.
ACCESSO ED UTILIZZO DEI SERVIZI ...................................................................................................... 8
6.1.
6.2.
6.3.
7.
L’INDICE DELLE P.A. E DELLE A.O.O. ................................................................................................................................ 5
LA POSTA ELETTRONICA CERTIFICATA ...............................................................................................................................7
RUOLI E COMPITI ...................................................................................................................................................................... 8
PREDISPOSIZIONE DEI DATI PER L’INSERIMENTO NELL’IPA.........................................................................................10
PROCEDURE DI GESTIONE DEI SERVIZI .............................................................................................................................11
6.3.1. Accreditamento PA..........................................................................................................................................................12
6.3.2. Raccolta ed invio delle informazioni da pubblicare ............................................................................................................13
6.3.3. Rimozione di una PA dall’IPA ......................................................................................................................................13
6.3.4. Iscrizione AOO ...............................................................................................................................................................14
6.3.5. Modifica UO ...................................................................................................................................................................14
6.3.6. Modifica AOO................................................................................................................................................................15
6.3.7. Cancellazione AOO ........................................................................................................................................................15
6.3.8. Conservazione dati storici .................................................................................................................................................16
6.3.9. Accesso ai dati storici .......................................................................................................................................................16
6.3.10.
Consultazione dell’IPA ..............................................................................................................................................16
6.3.11.
Accesso alle caselle di PEC.........................................................................................................................................17
6.3.12.
Riepilogo Ruoli/Fasi..................................................................................................................................................17
MODALITÀ E FORMATI PER L’INVIO DEI DATI...................................................................................18
7.1.
7.2.
7.3.
7.4.
7.5.
DATI RIGUARDANTI L’AMMINISTRAZIONE........................................................................................................................19
7.1.1. Esempio LDIF (amministrazione) ..................................................................................................................................21
7.1.2. Esempio Testo con delimitatore (amministrazione) ...........................................................................................................22
DATI RELATIVI ALL’AREA ORGANIZZATIVA OMOGENEA .............................................................................................22
7.2.1. Esempio LDIF (AOO) ..................................................................................................................................................24
7.2.2. Esempio Testo con delimitatore (AOO) ...........................................................................................................................24
DATI RELATIVI ALLE UNITÀ ORGANIZZATIVE.................................................................................................................24
7.3.1. Esempio LDIF (U.O.) ...................................................................................................................................................26
7.3.2. Esempio testo con delimitatore (U.O.) ..............................................................................................................................28
ULTERIORI ISTRUZIONI SUL FORMATO DEI DATI .............................................................................................................29
7.4.1. Dominio di Posta Elettronica Certificata..........................................................................................................................29
7.4.2. Codici...............................................................................................................................................................................29
7.4.3. Nomenclatura delle AOO................................................................................................................................................30
7.4.4. Sintassi dei campi descrittivi .............................................................................................................................................31
7.4.5. Formato delle date ............................................................................................................................................................31
TRASMISSIONE DEI DATI .......................................................................................................................................................32
Guida_IndicePA_PostaCert.doc
Pagina 2 di 32
Emesso da:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Titolo documento:
Codice doc.:
1. MODIFICHE DOCUMENTO
Descrizione Modifica
Edizione
Data
Prima emissione
1
30/07/2002
Modifica tracciati ed esempi per l’invio dei dati da pubblicare
2
31/10/2002
Aggiornamenti al formato dei dati da inviare per la pubblicazione
3
18/12/2002
Versione ad uso interno non pubblicata
4
n/a
Estensione dati pubblicati nell’IPA, aggiornamento schemi ed esempi
5
16/06/2003
Aggiornamento esempi LDIF e Testo
6
15/12/2003
Modifica formato LDIF per AOO (§ 7.2)
7
19/02/2004
Aggiunta esempi per formati LDIF e Testo
8
4/03/2004
Inserimento paragrafo 7.5 per la trasmissione dei dati
9
10/03/2004
Inseriti riferimenti ad attributo “dominioPEC”
2. RIFERIMENTI
Codice
Titolo
DPCM 31/10/2000
Decreto PCM del 31/12/2000: Regole tecniche per il protocollo informatico
di cui al DPR 20/10/1998 n.428
Circ. 7/5/2001 n.AIPA/CR/28
Circolare AIPA del 7/5/2001 di cui all.art. 18, comma 2, del DPCM
31/10/2000
AttoAggiuntivo2 Interoperabilità
R.U.P.A.
Atto Aggiuntivo n.2 al Contratto Quadro per i Servizi di Interoperabilità
R.U.P.A.
Guida_IndicePA_PostaCert.doc
Pagina 3 di 32
Emesso da:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Codice doc.:
Guida ai servizi di Indice P.A. e Posta Certificata
Titolo documento:
3. TERMINI E DEFINIZIONI
Termine/Acronimo
R.U.P.A.
PA
AOO
Descrizione
Rete Unitaria della Pubblica Amministrazione
Pubblica Amministrazione
Area Organizzativa Omogenea
UO
Unità Organizzativa
IPA
Indice della Pubblica Amministrazione
IAOO
Indice delle Aree Organizzative Omogenee
IUO
Indice delle Unità Organizzative
PEC
Posta Elettronica Certificata
CA
Certification Authority
LDAP
Lightweight Directory Access Protocol
LDIF
LDAP Data Interchange Format
DIT
Directory Information Tree
Guida_IndicePA_PostaCert.doc
Pagina 4 di 32
Emesso da:
Titolo documento:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Codice doc.:
4. OBIETTIVI E CONTENUTI DEL DOCUMENTO
Nel presente documento sono descritti i compiti e le attività a carico delle
amministrazioni pubbliche che devono essere avviate per l’attivazione dell’Indice
della Pubblica Amministrazione (IPA) e per l’accesso al servizio di Posta Elettronica
Certificata (PEC) disponibile nell’ambito della R.U.P.A.. Tali compiti sono descritti
nelle procedure di gestione dei servizi.
Una particolare attenzione è stata posta alle modalità ed ai formati che devono
essere utilizzati da parte delle amministrazioni per la comunicazione delle
informazioni che saranno pubblicate nell’IPA.
5. I SERVIZI IN SINTESI
5.1. L’Indice delle P.A. e delle A.O.O.
Il Decreto del Presidente del Consiglio dei Ministri del 31 ottobre 2000,
recante le regole tecniche per il protocollo informatico nella pubblica
amministrazione, istituisce l’Indice delle amministrazioni pubbliche e delle Aree Organizzative
Omogenee, accessibile per via telematica, come supporto all’interoperabilità dei sistemi
di protocollo informatico.
In tale decreto sono state indicate le informazioni minime che devono essere
contenute nell’Indice e le modalità d’accesso e di gestione delle stesse; la realizzazione
e la responsabilità del funzionamento dell’Indice sono affidate al CNIPA.
Il servizio di Indice delle amministrazioni pubbliche (IPA) realizzato vede
l’estensione delle informazioni gestite e la possibilità d’integrazione con altri indici,
peraltro prevista dal legislatore, al fine di costituire un punto di riferimento per
l’individuazione e l’accesso ai servizi telematici offerti dalla Pubblica
Amministrazione.
Da un punto di vista informativo, l’IPA può essere considerato composto di
due indici logici distinti:
1. l’indice delle unità organizzative (IUO), contenente le informazioni relative la
struttura organizzativa delle amministrazioni accreditate presso l’indice;
Guida_IndicePA_PostaCert.doc
Pagina 5 di 32
Emesso da:
Titolo documento:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Codice doc.:
2. l’indice delle Aree Organizzative Omogenee1 (IAOO), organizzato per
amministrazioni e contenente le informazioni sulla composizione delle
relative AOO.
L’IUO descrive la struttura organizzativa di ciascuna amministrazione in
termini di unità organizzative e della relativa struttura gerarchica. Esso contiene, per
ciascuna unità organizzativa, le informazioni riguardanti la sede o le sedi e la loro
denominazione ed indirizzo postale, unitamente alle modalità di accesso telematico
ad eventuali servizi applicativi on-line resi disponibili e gli indirizzi delle caselle di
posta elettronica, eventualmente afferenti ad un sistema di Posta Elettronica
Certificata.
L’IAOO contiene la descrizione dei dati tecnici e di tutte le informazioni
rilevanti che caratterizzano l’accesso telematico ad ogni AOO e, in particolare, per lo
scambio di messaggi di posta elettronica verso le relative caselle di posta istituzionali,
afferenti ad un sistema di Posta Elettronica Certificata. In esso le AOO sono
organizzate in base alle amministrazioni di appartenenza e contengono l’indicazione
delle unità organizzative utenti per le quali sono riferimento, descrivendo, di fatto,
una partizione dell’insieme delle UO dell’amministrazione.
Lo schema utilizzato, esemplificato nella figura seguente, modella tale struttura
logica creando dei legami tra UO ed AOO attraverso collegamenti bidirezionali, al
fine di soddisfare esigenze di navigabilità e ricerca nell’IPA, a partire da informazioni
sulla struttura organizzativa dell’amministrazione.
Ad una Area Organizzativa Omogenea (AOO) corrisponde un insieme di unità organizzative dell’amministrazione
che usufruiscono, in modo omogeneo e coordinato, dei servizi informatici per la gestione dei flussi documentali, ed
in particolare, del servizio di protocollazione.
1
Guida_IndicePA_PostaCert.doc
Pagina 6 di 32
Emesso da:
Titolo documento:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Codice doc.:
Il corretto e tempestivo aggiornamento delle informazioni pubblicate nell’IPA
sarà responsabilità diretta delle singole amministrazioni, secondo le modalità descritte
in seguito.
5.2. La Posta Elettronica Certificata
La Posta Elettronica Certificata (PEC) è un servizio di messaggistica che,
attraverso l’utilizzo degli standard riguardanti la posta elettronica, è in grado di
fornire attestazioni di recapito con garanzia di identificazione del mittente e del
destinatario. Il servizio comprende ulteriori funzionalità accessorie per garantire la
confidenzialità, l’integrità, il non ripudio, la tracciabilità e la storicizzazione del flusso
dei messaggi.
Le attestazioni o ricevute di recapito sono messaggi di posta elettronica,
generati automaticamente dal servizio di Posta Elettronica Certificata, utilizzati per
attestare le fasi della trasmissione. Tali ricevute, firmate elettronicamente dal sistema
emittente, contengono una serie di informazioni che caratterizzano l’evento cui sono
associate, quali data e ora, mittente, destinatario, oggetto etc.
Il servizio di PEC consentirà alla Pubblica Amministrazione centrale di
disporre di un’infrastruttura di posta elettronica in linea con la normativa vigente in
tema di trasmissione documentale (DPR 445/2000) e di avviare la gestione
elettronica dei flussi documentali.
L’utilizzo delle caselle di PEC implica l’abilitazione al transito dei protocolli
POP3, IMAP4, SMTP e HTTPS, necessari per l’accesso alle stesse, da e verso i
sistemi che erogano il servizio di PEC, operanti presso il Centro di Gestione dei
servizi di Interoperabilità (CG-I) della RUPA.
Il servizio di PEC è strettamente correlato all’IPA, che ne costituisce un
prerequisito funzionale, poiché in esso sono pubblicati gli indirizzi di Posta
Elettronica Certificata associati alle A.O.O. ed alle funzioni organizzative
eventualmente previste dalle amministrazioni.
Guida_IndicePA_PostaCert.doc
Pagina 7 di 32
Emesso da:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Titolo documento:
Codice doc.:
6. ACCESSO ED UTILIZZO DEI SERVIZI
Per l’avvio dei servizi di IPA e PEC, le amministrazioni interessate devono
mettere in atto una serie d’azioni, sia di carattere organizzativo che tecnologico, al
fine di permettere l’utilizzo degli stessi per la gestione e lo scambio di documenti
elettronici, anche attraverso sistemi di protocollo informatico.
A causa dello stretto legame fra i due servizi e del carattere propedeutico
dell’IPA rispetto alla PEC, le attività e le procedure di seguito descritte riguarderanno
prevalentemente il primo, a meno di peculiarità, opportunamente evidenziate, relative
al secondo.
6.1. Ruoli e compiti
Il processo di gestione dei servizi vede coinvolti più attori con ruoli diversi in
funzione delle specifiche attività svolte, quali:
•
•
•
•
consultazione delle informazioni contenute nell’IPA;
accreditamento di una PA presso l’Indice PA e presso il servizio di Posta
Elettronica Certificata;
aggiornamento dei dati AOO e UO pubblicati nell’IPA;
accesso ai dati storici relativi all’IPA.
Nell’ambito di tali attività alle amministrazioni spetta l’individuazione delle
figure che ricopriranno i seguenti ruoli e l’attribuzione alle stesse delle relative
responsabilità:
•
•
Referente Amministrazione: referente unico per entrambi i servizi, individuato
dall'amministrazione in fase di accreditamento; tale figura è responsabile della
comunicazione al Gestore/Fornitore dell’IPA, nei formati previsti, di tutte le
informazioni relative ad iscrizione e cancellazione delle AOO ed alle modifiche
nella struttura delle UO, comprese tutte le informazioni relative la Posta
Elettronica Certificata.
Utente: generico utente che accede all’IPA per la consultazione delle
informazioni ivi pubblicate, o un utente di PEC che attraverso account
opportunamente abilitati e secondo le modalità previste accede alla propria
casella di posta.
Completano l’elenco le seguenti figure di coordinamento, esterne alle
amministrazioni:
•
Responsabile IPA e PEC: supervisiona e coordina lo sviluppo e la gestione dei
servizi di IPA e PEC, garantendo la coerenza del processo d’accreditamento di
una amministrazione presso l’Indice e dei processi di comunicazione fra le PA
Guida_IndicePA_PostaCert.doc
Pagina 8 di 32
Emesso da:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Titolo documento:
•
Codice doc.:
ed il Gestore/Fornitore dell’IPA e della PEC. Tale funzione sarà ricoperta dal
CNIPA, anche secondo quanto previsto dal DPCM 31/10/2000;
Gestore/Fornitore: garantisce la rispondenza dei dati forniti dalle PA con i dati
effettivamente pubblicati nell’IPA; è responsabile di tutte le operazioni di
gestione, manutenzione e pubblicazione dei dati forniti. È responsabile della
creazione e gestione delle caselle di PEC secondo le informazioni fornite dalle
PA. Tale funzione sarà svolta dalla società EDS Pubblica Amministrazione
SpA,. fornitrice dei servizi.
Con la tabella seguente s’intende fornire una descrizione schematica dei ruoli e
delle attività di competenza delle specifiche figure sopra definite.
Funzione
•
Referente
Amministrazione
•
•
Utente
•
•
Responsabile IPA
e PEC
•
•
Guida_IndicePA_PostaCert.doc
Elenco compiti/responsabilità
fornisce, in fase di accreditamento dell’amministrazione
c/o l’IPA, nei formati previsti, i dati relativi la struttura
organizzativa della PA e le sue AOO, comprese tutte le
informazioni relative la PEC, indicandone anche i
rispettivi responsabili;
fornisce al Gestore dell’IPA tutti i dati necessari per
definire variazioni alla struttura organizzativa della PA.
accede alla propria casella di PEC attraverso account
opportunamente abilitati e secondo le modalità previste;
accede alle informazioni dell’IPA attraverso le interfacce
di consultazione rese disponibili dal Gestore/Fornitore.
supervisiona lo sviluppo e la gestione dell’IPA e della
PEC;
coordina il processo di accreditamento di una PA presso
l’IPA;
coordina il processo di rimozione di una PA dall’IPA.
Pagina 9 di 32
Emesso da:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Titolo documento:
Funzione
•
•
•
•
•
•
Gestore/Fornitore
•
•
•
•
Codice doc.:
Elenco compiti/responsabilità
effettua l’accreditamento di una PA presso l’IPA,
creando la radice per la sua struttura organizzativa;
coordina il processo di rimozione di un PA dall’IPA;
esegue il caricamento nell’IPA dei dati sulla struttura
delle UO della PA forniti dal Responsabile
dell’Amministrazione;
esegue modifiche alla struttura delle UO di una PA, su
indicazione del Responsabile dell’Amministrazione;
esegue l’iscrizione/cancellazione delle AOO nell’IPA, su
indicazione del Responsabile dell’Amministrazione;
esegue modifiche dei dati delle AOO di una PA su
indicazione del Responsabile della AOO stessa;
è responsabile dell’integrità fisica e logica dei dati
contenuti nell’IPA e deve provvedere alle operazioni di
salvataggio con cadenza periodica ed a quelle
straordinarie in caso di aggiornamenti;
è responsabile della disponibilità dei servizi di
consultazione ed aggiornamento;
deve fornire, su richiesta del Responsabile
dell’Amministrazione o del Responsabile dell’IPA, i
tracciati delle modifiche effettuate o i file LDIF
costituenti l’archivio storico;
è responsabile della creazione e gestione delle caselle di
PEC, per il servizio disponibile in ambito RUPA,
secondo le informazioni fornite dalle PA aderenti al
servizio.
6.2. Predisposizione dei dati per l’inserimento nell’IPA
Le amministrazioni utente dell’IPA e della PEC devono predisporre i dati e le
informazioni di propria competenza per le quali è prevista la pubblicazione nell’IPA.
Una parte di tali informazioni è richiesta per l’erogazione del servizio di Posta
Elettronica Certificata.
Tali informazioni dovranno essere comunicate al Gestore dell’IPA nei formati
e con le modalità comunicate dallo stesso.
L’insieme minimo di informazioni necessario per il supporto all’interoperabilità
dei sistemi di protocollo informatico, previsto dal DPCM del 31/10/2000, riguarda:
•
•
la denominazione, il codice identificativo e l’indirizzo postale di ciascuna
amministrazione;
l’elenco delle AOO di ciascuna amministrazione;
Guida_IndicePA_PostaCert.doc
Pagina 10 di 32
Emesso da:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Codice doc.:
Guida ai servizi di Indice P.A. e Posta Certificata
Titolo documento:
•
•
•
la denominazione, il codice identificativo, l’indirizzo telematico della casella
istituzionale di posta elettronica di ciascuna AOO;
l’elenco degli uffici o unità organizzative utente di ciascuna AOO.
l’eventuale riferimento al manuale di gestione della AOO reperibile in forma di
documento informatico.
Per consentire la completa gestione delle informazioni relative la struttura delle
amministrazioni e per agevolare l’individuazione e l’accesso ai servizi telematici
offerti, è necessario prevedere la pubblicazione nell’IPA delle seguenti ulteriori
informazioni:
•
•
•
•
•
•
•
•
struttura organizzativa di ciascuna amministrazione accreditata descritta in
termini di relazioni fra le UO;
denominazione, indirizzo di ciascuna UO;
casella ufficiale di struttura (eventualmente di PEC), telefono, fax ed altri
eventuali canali di comunicazione verso ciascuna UO;
collegamento alla AOO di riferimento per ciascuna UO;
elenco di altri servizi telematici eventualmente disponibili presso una AOO e/o
UO, come ad esempio un sito web o un indice particolare che riporta l’elenco
delle persone e dei ruoli, oppure un qualsiasi servizio applicativo accessibile
remotamente via rete;
eventuali dati relativi la sicurezza, come ad esempio il collegamento alla
certification authority emittente i certificati X.509v3 utilizzabili per la
connessione telematica sicura, l’autenticazione dei messaggi e/o degli
interlocutori;
elenco dei servizi telematici offerti da ciascuna UO e relativi collegamenti;
collegamenti ad altri indici specifici gestiti autonomamente da ciascuna
amministrazione o UO.
6.3. Procedure di gestione dei servizi
Le operazioni e le attività di gestione dell’IPA e della PEC che vedono
direttamente coinvolte le singole amministrazioni attraverso i ruoli precedentemente
descritti, sono le seguenti:
•
•
•
•
•
•
accreditamento di una amministrazione, secondo l’art 12 del DPCM
31/12/2000;
raccolta ed invio delle informazioni da pubblicare riguardo alle UO ed alle
AOO;
aggiornamento delle informazioni da pubblicare riguardo alle UO ed alle
AOO;
rimozione di una amministrazione accreditata;
conservazione dei dati storici;
consultazione.
Guida_IndicePA_PostaCert.doc
Pagina 11 di 32
Emesso da:
Titolo documento:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Codice doc.:
La coerenza del processo di accreditamento di una amministrazione presso
l’IPA verrà garantita dal Responsabile dell’IPA (ruolo assegnato al CNIPA), come
successivamente descritto in dettaglio. L’inserimento, la modifica e la cancellazione di
informazioni contenute nell’IPA, dovrà avvenire, di concerto con l’amministrazione,
mediante lo scambio di documenti firmati, anche digitalmente.
L’elenco delle informazioni da pubblicare, dovrà essere trasmesso al Gestore
dell’IPA, nei formati indicati nel capitolo successivo, con una delle seguenti modalità:
• come allegato, firmato digitalmente dal referente dell’amministrazione, ad
un messaggio di posta elettronica2;
• attraverso l’interfaccia web disponibile sul sito http://indicepa.gov.it.
In caso di utilizzo di quest’ultima modalità, il gestore dell’IPA provvederà, una
volta ricevuto l’elenco, a richiedere al referente dell’amministrazione la conferma
formale dei dati forniti.
Di seguito sono dettagliate le fasi di gestione dell’IPA che vedono direttamente
coinvolte le amministrazioni.
6.3.1. Accreditamento PA
1. la PA richiede al Gestore dell’IPA l’accreditamento presso l’Indice, inviando
l’apposito modulo disponibile sul sito web http://indicepa.gov.it;
2. il Gestore dell’IPA, di concerto con l’amministrazione in questione e con il
Responsabile dell’IPA, verifica che la PA possieda i requisiti necessari
all’accreditamento, definisce un codice identificativo per la stessa ed acquisisce
quindi i dati previsti per l’accreditamento, tra i quali il dominio di riferimento per
la PEC;
3. il Gestore dell’IPA provvede a creare nell’IPA la struttura dati necessaria a
contenere i dati della PA (crea il ramo o=AMM,c=it) e nel sistema di PEC il
dominio di riferimento indicato;
4. il Gestore dell’IPA comunica via e-mail al Referente della Amministrazione
l’avvenuto accreditamento fornendo il codice assegnato all’amministrazione da
utilizzare nella segnatura di protocollo, e le credenziali per l’accesso all’area
riservata del sito web IPA.
2
Tale modalità implica che le figure interessate siano preventivamente dotate di opportuna carta di firma digitale.
Guida_IndicePA_PostaCert.doc
Pagina 12 di 32
Emesso da:
Titolo documento:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Codice doc.:
Guida ai servizi di Indice P.A. e Posta Certificata
6.3.2. Raccolta ed invio delle informazioni da
pubblicare
1. il Referente della Amministrazione provvede ad acquisire le informazioni sulle
UO e sulle AOO da pubblicare sull’IPA, le predispone nei formati previsti e le
fornisce al Gestore dell’IPA secondo le modalità indicate nel capitolo
successivo;
2. il Gestore dell’IPA:
• provvede ad eseguire le verifiche di consistenza logica e sintattica dei dati
ricevuti;
• invia al Referente dell’Amministrazione, in formato elettronico o cartaceo a
seconda della modalità di trasmissione utilizzata (e-mail firmata o upload via
web), l’elenco delle modifiche richieste, unitamente ai risultati dei controlli
effettuati;
• in assenza di errori o di incompletezza dei dati, esegue, quindi, un
caricamento preliminare dei dati ricevuti, inviando al Referente
dell’Amministrazione conferma dell’avvenuta pubblicazione;
3. il Referente dell’Amministrazione, sottoscrive (digitalmente nel caso in cui
l’invio sia stato effettuato per via elettronica) e rinvia al Gestore dell’IPA l’elenco
delle modifiche eseguite; qualora fossero necessarie delle revisioni, si ritorna al
passo 1, per tutti i dati coinvolti;
4. il Gestore dell’IPA, ricevuto l’elenco sottoscritto, provvede al consolidamento
della struttura dell’indice ottenuto ed alla sua pubblicazione.
6.3.3. Rimozione di una PA dall’IPA
La rimozione di un’amministrazione dall’IPA può avvenire a seguito di:
•
chiusura dell’amministrazione;
•
fusione o accorpamento di due o più amministrazioni;
In entrambi i casi, la comunicazione dell’evento è a cura del Referente
dell’Amministrazione o, in sua vece, del Responsabile dell’IPA; tale comunicazione
deve pervenire al Gestore dell’IPA mediante documento firmato (digitalmente nel
caso di documento informatico) indicando la data di decorrenza di tale variazione.
Una volta ricevuta la richiesta, il Gestore dell’Indice provvede a chiederne
l’approvazione al Responsabile dell’Indice.
Ricevuta la conferma, il Gestore dell’Indice effettua la cancellazione dei dati di
pertinenza dell’Amministrazione dall’indice, previo salvataggio degli stessi in formato
LDIF ai fini della loro archiviazione.
Guida_IndicePA_PostaCert.doc
Pagina 13 di 32
Emesso da:
Titolo documento:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Codice doc.:
6.3.4. Iscrizione AOO
1. il Referente dell’Amministrazione fornisce al Gestore dell’IPA i dati, nei formati
previsti, relativi alla AOO da iscrivere, indicandone il rispettivo responsabile e
l’indirizzo di PEC della casella istituzionale;
2. il Gestore dell’IPA:
• provvede ad eseguire le verifiche di consistenza logica e sintattica dei dati
ricevuti;
• invia al Referente dell’Amministrazione, in formato elettronico o cartaceo a
seconda della modalità di trasmissione utilizzata al passo 1 (e-mail firmata o
upload via web), l’elenco delle modifiche richieste, unitamente ai risultati dei
controlli effettuati;
• in assenza di errori o di incompletezza dei dati, esegue, quindi, un
caricamento preliminare dei dati ricevuti, inviando al Referente
dell’Amministrazione conferma dell’avvenuta iscrizione;
3. il Referente dell’Amministrazione sottoscrive (digitalmente nel caso in cui l’invio
al punto 2 sia stato effettuato per via elettronica) e rinvia al Gestore dell’IPA
l’elenco delle modifiche eseguite. Qualora fossero necessarie delle revisioni, si
ritorna al passo 2, per tutti i dati coinvolti;
4. il Gestore dell’IPA, ricevuto l’elenco sottoscritto, provvede al consolidamento
della struttura dell’indice ottenuto ed alla sua pubblicazione.
6.3.5. Modifica UO
1. il Referente dell’Amministrazione fornisce al Gestore dell’IPA, nei formati
previsti, l’indicazione delle variazioni da effettuare alle UO pubblicate;
2. il Gestore dell’IPA:
• provvede ad eseguire le verifiche di consistenza logica e sintattica dei dati
ricevuti;
• invia al Referente dell’Amministrazione, in formato elettronico o cartaceo a
seconda della modalità di trasmissione utilizzata al passo 1 (e-mail firmata o
upload via web), l’elenco delle modifiche richieste, unitamente ai risultati dei
controlli effettuati;
• in assenza di errori o di incompletezza dei dati, esegue, quindi, un
caricamento preliminare dei dati ricevuti, inviando al Referente
dell’Amministrazione conferma dell’avvenuta iscrizione;
3. il Referente dell’Amministrazione, sottoscrive (digitalmente nel caso in cui
l’invio al punto 2 sia stato effettuato per via elettronica) e rinvia al Gestore
dell’IPA l’elenco delle modifiche eseguite. Qualora fossero necessarie delle
revisioni, si ritorna al passo 2, per tutti i dati coinvolti;
Guida_IndicePA_PostaCert.doc
Pagina 14 di 32
Emesso da:
Titolo documento:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Codice doc.:
4. il Gestore dell’IPA, ricevuto l’elenco sottoscritto, provvede al consolidamento
della struttura dell’indice ottenuto ed alla sua pubblicazione.
6.3.6. Modifica AOO
1. il Referente dell’Amministrazione fornisce al Gestore dell’IPA, nei formati
previsti, l’indicazione delle variazioni da effettuare alle AOO pubblicate;
2. il Gestore dell’IPA:
• provvede ad eseguire le verifiche di consistenza logica e sintattica dei dati
ricevuti;
• invia al Referente dell’Amministrazione, in formato elettronico o cartaceo a
seconda della modalità di trasmissione utilizzata al passo 1 (e-mail firmata o
upload via web), l’elenco delle modifiche richieste, unitamente ai risultati dei
controlli effettuati;
• in assenza di errori o di incompletezza dei dati, esegue, quindi, un
caricamento preliminare dei dati ricevuti, inviando al Referente
dell’Amministrazione conferma dell’avvenuta iscrizione;
3. il Referente dell’Amministrazione, sottoscrive (digitalmente nel caso in cui
l’invio al punto 2 sia stato effettuato per via elettronica) e rinvia al Gestore
dell’IPA l’elenco delle modifiche eseguite; qualora fossero necessarie delle
revisioni, si ritorna al passo 2, per tutti i dati coinvolti;
4. il Gestore dell’IPA, ricevuto l’elenco sottoscritto, provvede al consolidamento
della struttura dell’indice ottenuto ed alla sua pubblicazione;
6.3.7. Cancellazione AOO
1. il Referente dell’Amministrazione fornisce al Gestore dell’IPA, nei formati
previsti, l’indicazione del codice della AOO da cancellare; nonché le modifiche
da effettuare alle UO conseguenti alla riassegnazione degli uffici utente ad altre
AOO;
2. il Gestore dell’IPA:
• provvede ad eseguire le verifiche di consistenza logica e sintattica dei dati
ricevuti;
• invia al Responsabile della AOO, in formato elettronico o cartaceo a
seconda della modalità di trasmissione utilizzata al passo 1 (e-mail firmata o
upload via web), l’elenco delle modifiche richieste, unitamente ai risultati dei
controlli effettuati;
• in assenza di errori o di incompletezza dei dati, esegue, quindi, un
caricamento preliminare dei dati ricevuti, inviando al Responsabile della
AOO conferma dell’avvenuta iscrizione;
Guida_IndicePA_PostaCert.doc
Pagina 15 di 32
Emesso da:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Titolo documento:
Guida ai servizi di Indice P.A. e Posta Certificata
Codice doc.:
3. il Referente dell’Amministrazione, sottoscrive (digitalmente nel caso in cui
l’invio al punto 2 sia stato effettuato per via elettronica) e rinvia al Gestore
dell’IPA l’elenco delle modifiche eseguite; qualora fossero necessarie delle
revisioni, si ritorna al passo 2, per tutti i dati coinvolti;
4. il Gestore dell’IPA, ricevuto l’elenco sottoscritto, provvede al consolidamento
della struttura dell’indice ottenuto ed alla sua pubblicazione.
6.3.8. Conservazione dati storici
Il Gestore dell’Indice effettua sull’IPA le modifiche richieste, previa
archiviazione della base dati esistente e del file LDIF contenente le modifiche da
apportare.
6.3.9. Accesso ai dati storici
Su richiesta del:
•
Responsabile dell’IPA,
•
Referente dell’Amministrazione,
•
Responsabile dell’AOO,
saranno rese disponibili le informazioni contenute nell’IPA, ad una certa data,
in un formato convenuto (ad esempio LDIF), ovvero i tracciati delle modifiche
effettuate in un intervallo di tempo.
6.3.10.
Consultazione dell’IPA
Sono previste due modalità di accesso/consultazione dei dati contenuti
nell’IPA:
• tramite protocollo LDAP, con opportune query da sistemi ed applicazioni
presenti sulla RUPA e/o da Internet;
• tramite interfaccia WEB per utenti delle PA accreditate e/o presenti sulla
RUPA e per l’utente generico da Internet.
Per la costruzione delle query LDAP sarà resa disponibile la struttura dell’IPA.
Guida_IndicePA_PostaCert.doc
Pagina 16 di 32
Emesso da:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Codice doc.:
Guida ai servizi di Indice P.A. e Posta Certificata
Titolo documento:
6.3.11.
Accesso alle caselle di PEC
L’accesso alle caselle di PEC può avvenire utilizzando:
•
un client di posta elettronica, fra quelli collaudati, utilizzando i protocolli
POP3 o IMAP4 e SMTP;
•
un browser web, utilizzando il protocollo HTTPS.
Il dettaglio della configurazione dei client e le modalità operative di utilizzo del
servizio saranno descritte in un apposito manuale utente.
6.3.12.
Riepilogo Ruoli/Fasi
Nella seguente tabella sono riassunte le attività di competenza dei diversi ruoli
in relazione alle varie fasi previste per la gestione dell’IPA e della PEC
precedentemente descritte. Per le attività va utilizzata la legenda descritta in calce:
Ruoli
Responsabi
le IPA e
PEC
Gestore
Fornitore
Referente
Amministrazione
C
V, M
I, S
C
V, M
I,S
C,I
V, M
I, S
Iscrizione AOO
C
V, M
I, S
Modifica AOO
C
V, M
C, I, S
Cancellazione
AOO
C
V, M
I, S
Modifica UO
C
V, M
I, S
Conservazione
dati storici
C
M
Accesso dati
storici
R, A
I
Fasi
Accreditamento
di una PA
Raccolta ed invio
informazioni da
pubblicare
Rimozione di una
PA
Consultazione
IPA
Guida_IndicePA_PostaCert.doc
Utente
R, A
A
Pagina 17 di 32
Emesso da:
Titolo documento:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Codice doc.:
Accesso alle
caselle di PEC
I
M
V
S
A
C
R
A
= comunicazione informazioni;
= inserimento, modifica e/o cancellazione dati;
= verifica dati;
= sottoscrizione;
= accesso/consultazione dati;
= coordinamento e/o supervisione;
= ricerca/richiesta dati storici
7. MODALITÀ E FORMATI PER L’INVIO DEI DATI
Le amministrazioni che intendono accreditarsi all’IPA ed utilizzare la PEC,
dovranno fornire i dati per la pubblicazione e per le successive modifiche, su file
elettronici di tipo “testo”, in uno dei seguenti formati:
• formato standard LDIF;
• testo con campi separati dal carattere “pound” (“#”).
In entrambi i casi, i file devono essere in formato testo piatto (estensione “.txt”
o “.text”) con righe delimitate dai caratteri di controllo CR/LF (carriage return/line
feed) e senza ulteriori informazioni di formattazione.
Se viene utilizzato il primo formato (LDIF) tutte le informazioni, sia quelle
riguardante l’amministrazione che quelle riguardanti le UO e le AOO, dovranno
essere contenute in unico file.
Se, invece, viene utilizzato il secondo formato (testo delimitato da “#”), le
informazioni dovranno essere inserite suddivise su file distinti, uno per quelle relative
all’amministrazione, uno per le UO ed uno per le AOO. Le UO e le AOO saranno
descritte in tali file una per riga.
Nei paragrafi successivi sono illustrati i campi richiesti per le diverse tipologie
di dati, unitamente a degli esempi pratici. Tali schemi sono applicabili tanto al primo
caricamento dati, quanto ai successivi invii finalizzati alla modifica dei dati stessi già
presenti: ciò vuol dire che ciascuna amministrazione, dovrà comunicare sempre
l’intero corpus dei dati da pubblicare, anche nel caso di modifiche riguardanti uno o
più oggetti; semplicemente, le entry non modificate saranno re-inviate senza
modifiche assieme alle altre.
Le colonne riportate nelle seguenti tabelle indicheranno:
• N: progressivo numerico del campo;
• Dato: descrizione del contenuto del campo;
Guida_IndicePA_PostaCert.doc
Pagina 18 di 32
Emesso da:
Titolo documento:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
•
•
Codice doc.:
Attributo LDIF: nome del campo secondo la sintassi LDIF (N/A=campo
non applicabile per il formato LDIF);
Obbligatorio: indicazione di obbligatorietà per il campo. Nel caso di utilizzo
del formato testo con delimitatore, per i campi non obbligatori non
valorizzati deve essere riportato comunque il delimitatore (##). L’unico
delimitatore che non deve essere inserito è quello che delimita a destra
l’ultimo campo di ciascuna riga.
Negli esempi riportati, si farà riferimento ad una struttura del tipo riportato
nella figura che segue:
Elemento
Descrizione
Radice iPA
Amministrazione
Ufficio/UO
AOO
Relazione
gerarchica
Relazione
biunivoca
7.1. Dati riguardanti l’Amministrazione
L’Amministrazione deve comunicare al Gestore dell’iPA i seguenti dati:
N.
1
2
3
Descrizione dato
nome esteso amministrazione
indirizzo sede legale amministrazione
CAP sede legale amministrazione
Guida_IndicePA_PostaCert.doc
Attributo LDIF
description
street
postalcode
Obbligatorio
Si
No
No
Pagina 19 di 32
Emesso da:
Titolo documento:
N.
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
16+6*(n-1)
17+6*(n-1)
18+6*(n-1)
19+6*(n-1)
20+6*(n-1)
21+6*(n-1)
22+6*(n-1)
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Descrizione dato
città sede legale amministrazione
provincia di appartenenza sede legale3
regione di appartenenza sede legale
Nome responsabile4
Cognome responsabile
Nome referente5
Cognome referente
Indirizzo e-mail referente
Telefono Referente
Dominio di Posta Elettronica Certificata6
URL sito istituzionale7
Numero n dei servizi offerti8
Nome servizio 1
Descrizione servizio 19
Fruibilità da internet del servizio 110
URL servizio 111
E-mail servizio 112
Telefono servizio 1
…
Nome servizio n
Descrizione servizio n
Fruibilità da internet del servizio n
URL servizio n
E-mail servizio n
Telefono servizio n
Titolo del Responsabile
Codice doc.:
Attributo LDIF
l
provincia
regione
nomeResp
cognomeResp
givenName
sn
mail
telephoneNumber
dominioPEC
sitoIstituzionale
N/A
nomes
descrizioneS
fruibs
servizioTelematico
mails
telephoneNumbers
Obbligatorio
No
No
No
No
No
Si
Si
Si
Si
No
No
Si8
No
No
No
No
No
No
nomes
descrizioneS
fruibs
servizioTelematico
mails
telephoneNumbers
titoloResp
No
No
No
No
No
No
No
Sigla targa automobilistica.
Nome e cognome del Ministro, Presidente, Direttore o carica simile dell’amministrazione.
5 Referente unico dell’amministrazione per i servizi di Indice PA e Posta Elettronica Certificata.
6 Nome, scelto dall’amministrazione, del dominio dedicato al servizio di Posta Elettronica Certificata. Per la compilazione di
tale campo, consultare la sezione “Istruzioni per la compilazione”.
7 Indicare, se esiste, l’indirizzo internet da cui si accede alla pagina principale del sito istituzionale dell’amministrazione.
8 N° totale dei servizi erogati trasversalmente all’Amministrazione, le cui responsabilità non sono direttamente riconducibili
ad un’Unità od Ufficio: qualora tale numero sia diverso da 0, saranno da intendersi obbligatori anche i successivi n campi.
9 Descrizione sintetica ma esauriente delle caratteristiche del servizio offerto e delle modalità di accesso.
10 Indicare “SI” se il servizio è fruibile digitalmente (accesso via internet o altra rete), “NO” altrimenti: tale campo è
obbligatorio qualora sia specificato l’attributo “servizioTelematico”.
11 Indirizzo Internet per l’accesso al servizio.
12 Ove non si ritenga possibile indicare recapiti specifici del servizio, indicare i recapiti (e-mail e telefono) dell’U.R.P. a cui sia
possibile chiedere informazioni sul servizio.
3
4
Guida_IndicePA_PostaCert.doc
Pagina 20 di 32
Emesso da:
Titolo documento:
7.1.1.
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Codice doc.:
Guida ai servizi di Indice P.A. e Posta Certificata
Esempio LDIF (amministrazione)
I dati evidenziati in grassetto sono a carico del Gestore dell’IPA:
l’Amministrazione è tenuta ad utilizzare i dati comunicati dal Gestore in sede di
accreditamento.
dn: o=m_ef13, c=it
objectclass: top
objectclass: organization
objectclass: amministrazione
o: m_ef
description: Ministero dell’Economia e delle Finanze
street: Piazza Mastai, 11
postalcode: 00100
l: Roma
provincia: RM
regione: Lazio
sitoIstituzionale: www.finanze.it
logoAmm: Finanze.gif
nomeResp: Sergio
cognomeResp: Bruni
TitoloResp: Direttore
codiceAmm: 111030003201
nomes: 1#servizio dipartimento politiche fiscali
descriziones: 1#Il servizio consente di...
fruibs: 1#si
servizioTelematico: 1#http://www.finanze.it/polfisch
mails: 1#[email protected]
telephonenumbers: 1#02333456
tipoAmm: A
dominioPEC: finanzecert.it
dn: uid=m_ef-mrossi, ou=m_ef, o=referenti
objectclass: top
objectclass: person
objectclass: organizationalperson
objectclass: inetorgperson
objectclass: newPilotPerson
givenname: Mario
sn: Rossi
cn: Mario Rossi
telephonenumber: 06.23456
mail: [email protected]
uid: m_ef-mrossi
Per quanto riguarda il logo dell’Amministrazione, riportato dall’attributo
“logoAmm” ed il cui inserimento è a carico del Gestore dell’iPA, esso dovrà essere
una immagine in formato gif, fornita dall’Amministrazione stessa, di dimensioni non
superiori ad 85x85 pixel.
13
Codice della amministrazione fornito dal Gestore dell’Indice in fase di accreditamento.
Guida_IndicePA_PostaCert.doc
Pagina 21 di 32
Emesso da:
Titolo documento:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Codice doc.:
Tale logo potrà essere inviato al Gestore dell’IPA mediante posta elettronica
all’indirizzo [email protected].
Una volta ricevuta l’immagine, il logo stesso sarà inserito dal Gestore dell’IPA,
nel file LDIF.
7.1.2. Esempio Testo con delimitatore
(amministrazione)
Ministero dell’Economia e delle Finanze#Piazza Mastai, 11#00100#Roma#Lazio
#RM#Sergio#Bruni#Mario#Rossi#[email protected]#06.23456#finanzecert.i
t#www.finanze.it#1#servizio dipartimento politiche fiscali#Il servizio con
sente di...#si#http://www.finanze.it/dippolfisc#[email protected]#02333456#
Direttore
7.2.
Dati relativi all’Area Organizzativa Omogenea
Una AOO è una funzione organizzativa che cura le funzioni di registrazione di
protocollo per tutte le unità organizzative ad essa afferenti.
Ogni AOO è collocata presso una unità organizzativa, pertanto è necessario
descrivere tale unità, analogamente a tutte le altre unità organizzative
dell’amministrazione, secondo il formato descritto nel paragrafo 7.3
Per ciascuna AOO, l’amministrazione dovrà fornire i seguenti dati:
N.
1
2
3
4
5
6
7
8
9
10
Dato
Codice AOO14
Nome AOO14
Indirizzo e-mail istituzionale AOO15
Nome responsabile16
Cognome responsabile16
E-Mail responsabile
Telefono responsabile
Data istituzione
Data soppressione
URL CA emittente certificato17
Attributo LDIF
aoo
description
mail
nomeResp
cognomeResp
mailResp
telephoneNumberResp
dataistituzione
datasoppressione
CAurl
Obbligatorio
Si
Si
Si
Si
Si
No
No
Si
No
No
Vedi le istruzioni per la codifica e nomenclatura delle AOO.
Indirizzo della casella “istituzionale” di posta elettronica certificata associato all’AOO: tale indirizzo dovrà
obbligatoriamente essere di Posta Elettronica Certificata.
16 Nome e Cognome del responsabile dell’AOO e del relativo sistema di protocollo informatico.
14
15
Guida_IndicePA_PostaCert.doc
Pagina 22 di 32
Emesso da:
Titolo documento:
N.
11
12
13
14
15
16
17
18
19
20
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Codice doc.:
Guida ai servizi di Indice P.A. e Posta Certificata
Dato
Telefono
Fax
Città
Indirizzo
CAP
Regione
provincia
Numero “n” uffici afferenti18
Codice ufficio 119
Codice ufficio 2
Attributo LDIF
Obbligatorio
telephonenumber
No
facsimiletelephonenumber
No
l
No
street
No
postalcode
No
regione
No
provincia
No
N/A
Si
codiceuff
No
codiceuff
No
...
18+n
19+n
20+n
21+n
22+n
23+n
24+n
25+n
26+n
27+n
28+n
29+n
30+n
31+n
...
20+n+6*(p-1)
Codice ufficio n
Numero “p” dei servizi Telematici20
Nome Servizio 1
Descrizione Servizio 1
Fruibilità da internet del servizio 1
URL servizio 121
E-mail referente servizio 1
Telefono referente servizio 1
Nome Servizio 2
Descrizione Servizio Telematico 2
Fruibilità da internet del servizio 2
URL servizio 2
E-mail referente servizio 2
Telefono referente servizio 2
codiceuff
N/A
nomes
descriziones
fruibs
servizioTelematico
mailS
telephonenumbers
nomes
descrizioneS
fruibs
servizioTelematico
mails
telephonenumbers
Nome Servizio p
nomes
21+n+6*(p-1)
22+n+6*(p-1)
23+n+6*(p-1)
24+n+6*(p-1)
25+n+6*(p-1)
Descrizione Servizio Telematico p
Fruibilità da internet del servizio p
URL servizio p
E-mail referente servizio p
Telefono referente servizio p
descrizioneS
fruibs
servizioTelematico
mails
telephonenumbers
No
Si
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Collegamento alla Certification Authority per la verifica della validità dei certificati da utilizzare per l’accesso a servizi
protetti.
18 N° degli uffici/unità afferenti all’AOO per il protocollo informatico: tale numero va specificato comunque anche se non
vi sono uffici afferenti (ad es. Per una AOO rimossa).
19 Lista dei codici degli uffici di cui alla nota precedente; tali uffici devono essere già presenti nell’IPA.
20 N° totale dei servizi telematici di competenza dell’AOO: indicare tale numero comunque. Se non vi sono servizi
specificare “0”.
21 Indirizzo internet e descrizione breve del servizio.
17
Guida_IndicePA_PostaCert.doc
Pagina 23 di 32
Emesso da:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Titolo documento:
Guida ai servizi di Indice P.A. e Posta Certificata
Codice doc.:
7.2.1. Esempio LDIF (AOO)
Nell’esempio seguente, per brevità, alcuni campi non sono riportati. I dati
riportati in grassetto sono imposti dal Gestore dell’IPA.
dn: aoo=aoofin02, o=m_ef, c=it
objectclass: top
objectclass: aoo
aoo: aoofin02
description: Dipartimento per le Politiche Fiscali
mail: [email protected]
caurl: http://www.poste.it
dataistituzione: 1997-05-20
codiceuff: ou=uff01, o=m_ef, c=it
codiceuff: ou=uff02, ou=uff01, o=m_ef, c=it
codiceuff: ou=uff03, ou=uff01, o=m_ef, c=it
telephonenumber: 025487911
l: milano
nomeResp: Mario
cognomeResp: Rossi
telephonenumberResp: 06.23456
mailResp: [email protected]
nomes: 1#servizio dipartimento politiche fiscali
descriziones: 1#Il servizio consente di...
fruibs: 1#si
servizioTelematico: 1#http://www.finanze.it/polfisch
mails: 1#[email protected]
telephonenumbers: 1#02333456
7.2.2.
Esempio Testo con delimitatore (AOO)
aoofin02#dipartimento per le politiche fiscali#politichefiscali@finanz
e.it#mario#rossi#[email protected]#02.9951437#19970520##http://ww
w.poste.it#065487911##milano###Lombardia#MI#3#uff01#uff02#uff03#1#serv
izio dipartimento politiche fiscali#Il servizio consente di...#si#http
://www.finanze.it/dippolfisc#[email protected]#02333456
Come si può osservare, laddove un campo non è definito (ad esempio il
numero di telefono) è necessario che compaia un campo vuoto (##).
7.3. Dati relativi alle Unità Organizzative
Guida_IndicePA_PostaCert.doc
Pagina 24 di 32
Emesso da:
Titolo documento:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Codice doc.:
Guida ai servizi di Indice P.A. e Posta Certificata
Le unità organizzative devono essere specificate nel file di definizione di dati,
in un ordine “top-down”: ciò vuol dire che dovranno comparire prima le Unità
Organizzative di livello alto e solo successivamente le Unità Organizzative ad esse
afferenti. Ad esempio se un ufficio “X” appartiene ad una unità organizzativa “U”
gerarchicamente superiore, nel file dovrà essere definita prima “U” e poi “X”.
Per ciascun ufficio/unità, l’amministrazione dovrà fornire i seguenti dati:
N.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Dato
Codice Ufficio22
Nome Ufficio
Codice UO di appartenenza23
Codice AOO di appartenenza24
indirizzo e-mail ufficio25
Casella di Posta Elettronica
Certificata26
URL CA emittente certificato
Telefono
Fax
Città
Indirizzo
CAP
regione
provincia
Nome responsabile
Cognome responsabile
E-Mail responsabile
Telefono responsabile
Numero “p” dei servizi27
Nome servizio 1
Descrizione Servizio 128
Fruibilità da Internet Servizio 129
URL servizio 1
E-Mail referente Servizio 130
Attributo LDIF
ou
description
dn
aooref
mail
st
CAurl
telephonenumber
facsimiletelephonenumber
l
street
postalcode
regione
provincia
nomeResp
cognomeResp
mailResp
telephoneNumberResp
N/A
nomeS
descrizioneS
fruibS
servizioTelematico
mailS
Obbligatorio
Si
Si
Si
Si
No
Si
No
No
No
No
No
No
No
No
Si
Si
No
No
Si
No
No
No
No
No
Codice univoco utilizzato o proposto dall’amministrazione.
Codice dell’unità organizzativa (ufficio, divisione, direzione, dipartimento) gerarchicamente superiore che deve essere già
presente nell’IPA o comparire all’interno del file inviato.
24 Codice dell’AOO a cui l’unità fa riferimento per il protocollo informatico.
25 Tale indirizzo, se di Posta Elettronica Certificata, deve fare riferimento al dominio di Posta Elettronica Certificata
dell’amministrazione.
26 Indicare “SI” se l’indirizzo specificato nel campo 5 fa riferimento ad una casella di Posta Elettronica Certificata, “NO”
altrimenti; è obbligatorio se il campo 5 è valorizzato.
27 N° totale dei servizi, sia telematici che non, di competenza dell’unità: tale valore è obbligatorio. Indicare “0” se non vi
sono servizi di competenza dell’unità.
28 Descrizione sintetica ma esauriente delle caratteristiche del servizio offerto e delle modalità di accesso.
29 Indicare “SI” se il servizio è fruibile digitalmente (accesso via internet o altra rete), “NO” altrimenti.
22
23
Guida_IndicePA_PostaCert.doc
Pagina 25 di 32
Emesso da:
Titolo documento:
N.
25
26
27
28
29
30
31
...
20+6(p-1)
21+6(p-1)
22+6(p-1)
23+6(p-1)
24+6(p-1)
25+6(p-1)
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Codice doc.:
Dato
Telefono referente Servizio 1
Nome servizio 2
Descrizione Servizio 2
Fruibilità da Internet Servizio 2
URL servizio 2
E-Mail referente Servizio 2
Telefono referente Servizio 2
Attributo LDIF
telephonenumberS
nomeS
descrizioneS
fruibS
servizioTelematico
mailS
telephonenumberS
Nome servizio p
Descrizione Servizio p
Fruibilità da Internet Servizio p
URL servizio p
E-Mail referente Servizio p
Telefono referente Servizio p
nomeS
descrizioneS
fruibS
servizioTelematico
mailS
telephonenumberS
Obbligatorio
No
No
No
No
No
No
No
No
No
No
No
No
No
7.3.1. Esempio LDIF (U.O.)
dn: ou=uff01, o=m_ef, c=it
objectclass: top
objectclass: organization
objectclass: organizationalunit
objectclass: ufficio
o: m_ef
ou: uff01
description: Ufficio per il Federalismo Fiscale
street: via scarlatti, 30
mail: [email protected]
st: no
caurl: http://www.sia.it
l: Milano
regione: Lombardia
provincia: MI
postalcode: 00192
nomeResp: Vittorio
cognomeResp: Bianchi
mailResp: [email protected]
telephonenumberResp: 06.23459
aooref: aoo=aoofin02, o=m_ef, c=it
servizioTelematico: 1#http://www.finanze.it/fedfisch.htm
descrizioneS: 1#Web Ufficio per il Federalismo Fiscale
nomeS: 1#Web Ufficio per il Federalismo Fiscale
fruibS: 1#true
telephonenumberS: 1#021412133
mailS: 1#[email protected]
dn: ou=uff02, o=uff01, o=m_ef, c=it
30
Ove non si ritenga possibile indicare un referente specifico, indicare i recapiti (e-mail e telefono) dell’U.R.P. a cui sia
possibile chiedere informazioni sul servizio.
Guida_IndicePA_PostaCert.doc
Pagina 26 di 32
Emesso da:
Titolo documento:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Codice doc.:
objectclass: top
objectclass: organization
objectclass: organizationalunit
objectclass: ufficio
o: m_ef
ou: uff02
description: Ufficio tasse
street: via dei laghi, 40
mail: [email protected]
st: no
caurl: http://www.postecom.it
l: Roma
regione: Lazio
provincia: RM
postalcode: 00155
nomeResp: Giovanni
cognomeResp: Caruso
mailResp: [email protected]
telephonenumberResp: 06.234566777
aooref: aoo=aoofin02, o=m_ef, c=it
dn: ou=uff03, o=uff01, o=m_ef, c=it
objectclass: top
objectclass: organization
objectclass: organizationalunit
objectclass: ufficio
o: m_ef
ou: uff03
description: Ufficio relazioni con il pubblico
street: piazza Nievo, 4
mail: [email protected]
st: si
caurl: http://www.infostrada.it
l: Roma
regione: Lazio
provincia: RM
postalcode: 00155
nomeResp: Antonio
cognomeResp: Cabrini
mailResp: [email protected]
telephonenumberResp: 06.234566768
aooref: aoo=aoofin02, o=m_ef, c=it
servizioTelematico: 1#http://www.finanze.it/urp.htm
descrizioneS: 1#Web Ufficio relazioni con il pubblico
nomeS: 1#Sportello relazioni con il pubblico
fruibS: 1#true
telephonenumberS: 1#021412135
descrizioneS: 2#Il servizio accoglie ricorsi e reclami ed e’ in funzione
dalle 8.00 alle 14.00 dal lunedi al venerdi
nomeS: 2#Sportello ricorsi
fruibS: 2#false
telephonenumberS: 2#06992135
Guida_IndicePA_PostaCert.doc
Pagina 27 di 32
Emesso da:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Titolo documento:
7.3.2.
Guida ai servizi di Indice P.A. e Posta Certificata
Codice doc.:
Esempio testo con delimitatore (U.O.)
uff01#Ufficio per il Federalismo Fiscale##aoofin02#[email protected]#no#http:/
/www.sia.it###milano#via scarlatti, 30#00192#Lombardia#MI#Vittorio#Bianchi#v.
[email protected]#06.23459#1#Web Ufficio Federalismo Fiscale#Web Ufficio Fed
eralismo Fiscale#true#http://www.finanze.it/fedfisch.htm#referente.federalism
[email protected]#021412133
uff02#Ufficio tasse#uff01#aoofin02#[email protected]#no#http://www.
postecom.it###roma#via dei laghi, 40#00155#Lazio#RM#Giovanni#Caruso#g.caruso@
finanze.it#06.234566777#0
uff03#Ufficio relazioni con il pubblico#uff01#aoofin02#[email protected]#si#
http://www.infostrada.it###Roma#piazza Nievo, 4#00155#Lazio#RM#Antonio#Cabrin
i#[email protected]#06.234566768#2#Sportello relazioni con il pubblico#Web
Ufficio relazioni con il pubblico#true#http://www.finanze.it/urp.htm##021412
135#Sportello ricorsi#Il servizio accoglie ricorsi e reclami ed e’ in funzion
e dalle 8.00 alle 14.00 dal lunedi al venerdi#false###06992135
Si osservi che per “uff01” che dipende direttamente dall’amministrazione, il
“codice UO di appartenenza” non è stato specificato, mentre tale informazione è
indispensabile per poter correttamente collocare gli altri due uffici.
Guida_IndicePA_PostaCert.doc
Pagina 28 di 32
Emesso da:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Titolo documento:
7.4.
Codice doc.:
Ulteriori istruzioni sul formato dei dati
7.4.1.Dominio di Posta Elettronica Certificata
Per la corretta compilazione del campo relativo al dominio di Posta Elettronica
Certificata, attenersi alle seguenti linee guida.
1. Il nome dovrà aderire agli standard internet esposti nelle RFC 1035 e 1101. In
sintesi esso potrà contenere solo caratteri alfabetici e numeri; l’unico carattere
speciale ammesso è “-” (il trattino, codice ASCII 45). I caratteri alfabetici
potranno essere maiuscoli o minuscoli, ma ciò sarà ininfluente ai fini
dell’identificazione del dominio stesso, cioè i domini “TestPEC.Rupa.it” e
“testPEC.rupa.it”, sono indistinguibili ai fini dell’identificazione del dominio da
parte del sistema DNS di Internet.
2. Il nome di dominio proposto per le caselle di Posta Elettronica Certificata dovrà
essere distinto da quello utilizzato per le caselle di posta elettronica ordinaria. Ciò
si può effettuare o indicando un sottodominio del dominio già utilizzato (ad es.
postacertificata.cri.it), oppure indicando un nuovo dominio di secondo livello
(ad es. cripost.it). In quest’ultimo caso, sarà necessario seguire le procedure di
registrazione ordinarie, concordate con il proprio Provider/Maintainer.
7.4.2.
Codici
Nella compilazione dei dati, l’Amministrazione è tenuta ad indicare alcuni
codici, da assegnare alle Unità Organizzative ed alle Aree Organizzative Omogenee.
Per quanto riguarda i codici delle AOO, ancorchè a carico
dell’Amministrazione, essi dovranno essere soggetti ad alcune restrizioni, riportate
nella Circolare AIPA 7/5/2001 n.AIPA/CR/28 e successive integrazioni, che
riassumiamo di seguito per brevità.
•
un CodiceAOO è codificato mediante un sottoinsieme dei caratteri previsti dalla
specifica US-ASCII a 8 bit; il codice è composto da una sequenza di lettere
maiuscole ([A-Z]), lettere minuscole ([a-z]), cifre decimali ([0-9]) e dai caratteri “-”
e “_”;
•
un CodiceAOO deve avere una lunghezza non superiore a 16 caratteri.
Guida_IndicePA_PostaCert.doc
Pagina 29 di 32
Emesso da:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Codice doc.:
Guida ai servizi di Indice P.A. e Posta Certificata
Titolo documento:
Per omogeneità, le stesse regole dovranno essere applicate anche ai codici delle
Unità Organizzative.
I codici relativi all’Amministrazione da utilizzare anche nella segnatura di
protocollo sono, invece, assegnati dal Responsabile dell’iPA in sede di
Accreditamento, sulla base delle seguenti regole:
•
per i Ministeri, il codice sarà “m_”, seguito dall’acronimo del ministero stesso, ad
esempio per il Ministero dell’Economia e delle Finanze, il codice sarà “m_ef”;
•
per le Regioni, il codice sarà “r_”, seguito dai primi sei caratteri del nome della
regione (spazi esclusi), ad esempio per la Regione Valle D’Aosta, il codice sarà
“r_valled”;
•
per le Province, il codice sarà “p_”, seguito dalla targa della provincia, ad esempio
per la Provincia di Rieti, il codice sarà “p_ri”;
•
per i Comuni, il codice sarà “c_”, seguito dal codice identificativo del comune
come da Codice Fiscale; ad esempio per il Comune di Gallio, il codice sarà
“c_d882”;
•
per tutti gli altri Enti, il codice sarà un acronimo al massimo di 16 lettere, ad
esempio per l’Ente Nazionale di Previdenza ed Assistenza per i Lavoratori dello
Spettacolo, il codice sarà “enpals”.
L’Amministrazione è tenuta a rispettare il codice assegnato in sede di
accreditamento ogniqualvolta esso dovrà comparire nei dati inviati (ad esempio nel
formato LDIF).
7.4.3.
Nomenclatura delle AOO
Le Aree Organizzative Omogenee individuate dall'Amministrazione
costituiranno, attraverso le rispettive caselle istituzionali di posta elettronica
certificata, i canali privilegiati per lo scambio di documenti elettronici e per l'accesso
al sistema di protocollo informatico.
E’ opportuno, pertanto, che il nome scelto per l'AOO compaia anche
nell'indirizzo di posta elettronica della relativa casella istituzionale e che nella
definizione di tali nomi si prendano in considerazione i seguenti criteri:
•
dal punto di vista semantico, il nome dell'AOO dovrebbe far risaltare la
collocazione della stessa nell'ambito della struttura organizzativa
dell'ammnistrazione, rimandando all'unità o all'insieme di unità organizzative a
Guida_IndicePA_PostaCert.doc
Pagina 30 di 32
Emesso da:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Codice doc.:
Guida ai servizi di Indice P.A. e Posta Certificata
Titolo documento:
cui è associabile (ad es. Direzione, Dipartimento, Ufficio periferico, ecc.), con
una nomenclatura semplice che ne espliciti le attività e/o il ruolo, evitando le
sigle e gli acronimi che potrebbero risultare incomprensibili;
•
7.4.4.
dal punto di vista sintattico, anche in osservanza di quanto previsto nella RFC
2822 riguardo al formato dei messaggi internet, il nome non dovrebbe superare i
30 caratteri (per rimanere nel limite di circa 70 caratteri comprendendo il nome
del dominio di posta) e può essere composto da caratteri alfanumerici (sia
maiuscoli che minuscoli) e dai caratteri speciali di seguito racchiusi fra virgolette:
Carattere
Codice ASCII
“.”
46
“*”
42
“-”
45
“/”
47
“_”
95
“|”
124
Sintassi dei campi descrittivi
Tra i dati forniti dall’amministrazione, alcuni campi quali “description”, “nomeResp”,
“cognomeResp”, “nomeS”, “descrizioneS”, “street”, “l”, devono aderire alla specifica “US7Ascii”.
Ciò vuol dire che tali campi possono contenere solo i caratteri il cui codice ASCII è compreso tra
“32” (spazio) e “126” (tilde “~”).
7.4.5.
Formato delle date
Le date di istituzione e soppressione delle AOO, dovranno essere aderenti allo standard
specificato dalla ISO 8601 e cioè “AAAA-MM-GG”.
Ad esempio se la data è 5 Dicembre 2003, essa dovrà essere resa come “2003-12-05”.
Guida_IndicePA_PostaCert.doc
Pagina 31 di 32
Emesso da:
Titolo documento:
Centro nazionale per l’informatica
nella P.A.
Tipo documento:
Area infrastrutture nazionali condivise
Data emissione:
Guida ai servizi
Guida_IndicePA_PostaCert.doc
15 Marzo 2004
Edizione:
n° allegati:
9
0
Guida ai servizi di Indice P.A. e Posta Certificata
Codice doc.:
7.5. Trasmissione dei dati
Le modalità di trasmissione dei dati sono due:
1. Invio mediante funzionalità “TRASFERISCI” presente nell’area riservata del sito
http://www.indicepa.gov.it.
I files, inviati attraverso la form, subiscono un processo automatico di verifica sintattica e,
se il file non rispetta i formati previsti, verrà visualizzato un report degli errori riscontrati,
in modo da velocizzare le operazioni di correzione da parte di chi invia. Se il file soddisfa
i requisiti, verrà visualizzato un report che include anche la visualizzazione del file giunto
sul sistema a maggior garanzia della corretta ricezione dei dati da parte del sistema
automatico.
La pubblicazione dei dati stessi sarà successivamente comunicata per e-mail al referente
che ha effettuato l’invio, unitamente al dump completo del database riguardante
l’amministrazione (in formato LDIF). Tale file potrà essere utilizzato, ad esempio, per
comunicare future variazioni.
2. Invio mediante messaggio di posta elettronica con allegato firmato digitalmente dal
referente dell’amministrazione.
Per i files inviati in tale modalità, la pubblicazione dei dati è di norma soggetta a tempi
tecnici più lunghi in quanto il Gestore dell’iPA dovrà verificare la firma dell’allegato e
successivamente, in caso di errori, comunicare il report degli stessi al referente ed
attendere un nuovo invio.
Guida_IndicePA_PostaCert.doc
Pagina 32 di 32
ALLEGATO 4
58
Firma elettronica: tecnologie e standard
Sommario
L
a diffusione degli strumenti informatici e la parallela crescita della comunicazione attraverso le reti di
calcolatori hanno posto con pressante urgenza il problema della sostituzione del tradizionale documento
cartaceo con un equivalente strumento informatico. Il meccanismo universalmente adottato per costruire tale
strumento è la firma digitale basata sulla crittografia a chiavi pubbliche. Vengono qui discussi a livello
elementare i concetti fondamentali e le tecnologie su cui la firma digitale si basa.
La firma digitale
La firma digitale è una informazione che viene aggiunta ad un documento informatico al fine di garantirne
integrità e provenienza. Sebbene l’uso per la sottoscrizione dei documenti formati su supporti informatici sia
quello più naturale, essa può essere utilizzata per autenticare una qualunque sequenza di simboli binari,
indipendentemente dal loro significato. Un esempio sempre più comune di questo uso generalizzato è l’aggiunta
di firme digitali ai file contenuti nella memoria di massa di un sistema di elaborazione onde contrastare gli
attacchi dei virus e degli hacker.
La principale differenza tra firma autografa e firma digitale sta nel fatto che la prima è direttamente
riconducibile all’identità di colui che la appone, poiché la calligrafia è un elemento identificativo della persona,
mentre la seconda non possiede questa proprietà. Per coprire questa deficienza si ricorre all’autorità di
certificazione, il cui compito è quello stabilire, garantire e pubblicare l’associazione tra firma digitale e soggetto
sottoscrittore.
Per contro, mentre l’associazione tra testo di un documento e la firma autografa è ottenuta esclusivamente
attraverso il supporto cartaceo, la firma digitale è intrinsecamente legata ad testo a cui è apposta, tanto che i
due oggetti possono essere fisicamente separati senza che per questo venga meno il legame esistente tra loro.
Conseguenza di ciò è l’unicità della firma digitale, nel senso che a testi diversi corrispondono firme diverse e
quindi, non ostante la sua perfetta replicabilità, è impossibile trasferirla da un documento ad un altro.
La base della firma digitale: la crittografia a chiavi pubbliche
I meccanismi di firma digitale poggiano essenzialmente sopra gli algoritmi crittografici a chiavi pubbliche, che
sono detti anche a chiavi asimmetriche poiché utilizzano chiavi diverse per le operazioni di codifica e decodifica.
La chiave di codifica Kc e quella di decodifica Kd vengono utilizzate all’interno delle rispettive funzioni C e D per
trasformare la sequenza binaria che costituisce un messaggio M nel corrispondente messaggio cifrato X,
risultando:
X=C(Kc,M) ; M=D(Kd,X)
La condizione più importante che deve essere soddisfatta affinché il sistema costituito dalla coppia di funzioni C
e D e dalla coppia di chiavi Kc e Kd sia utilizzabile come sistema di cifratura a chiavi pubbliche è che la
conoscenza della chiave pubblica Kp non consenta di determinare la chiave segreta Ks.
Algoritmo di Diffie-Hellman
Nel 1976 Diffie ed Hellman [DIHE76] hanno descritto un protocollo per lo scambio di una chiave segreta sopra
un canale insicuro; tale meccanismo era stato inteso essenzialmente per risolvere il problema dell’avvio di un
normale sistema di cifratura a chiavi simmetriche, quale il DES [FIPS46, FIPS81], ma in realtà ha posto le basi
della crittografia a chiavi pubbliche.
Il protocollo, utilizzato da due interlocutori A e B, può essere descritto come segue:
1.
2.
3.
4.
5.
A e B scelgono pubblicamente un insieme di interi G=[0,N-1] ed un suo elemento s.
A sceglie in modo casuale un elemento a di G, calcola sa mod N e lo invia a B.
B sceglie in modo casuale un elemento b di G, calcola sb mod N e lo invia ad A.
A, ricevuto sb, calcola K= (sb)a mod N.
B, ricevuto sa, calcola K= (sa)b mod N.
In questo modo entrambi gli interlocutori possiedono la chiave K ma sopra il canale insicuro sono stati trasferiti
solo N, s, samod N ed sbmod N che non consentono di ricostruire K. In realtà la determinazione di a noti s ed sa
richiede la soluzione del problema del logaritmo discreto che consiste nella determinazione dell’intero che
corrisponde al logaritmo in una base intera di un intero di cui è noto solo resto della divisione rispetto al modulo
N. Tale problema è computazionalmente difficile.
Lo RSA
Proposto nel 1978 da Rivest, Shamir e Adleman [RSA78], da cui il nome, è il primo sistema di crittografia a
chiavi pubbliche basato sui concetti proposti da Diffie ed Hellman ed è anche quello attualmente più diffuso ed
utilizzato.
Il metodo si basa sulla fattorizzazione di interi di grandi dimensioni e per utilizzarlo ciascun interlocutore deve
compiere le seguenti azioni:
1.
2.
3.
4.
Scegliere due grandi interi p e q che siano primi; il loro prodotto corrisponde al valore di N utilizzato nel
calcolo del modulo nelle operazioni di codifica e decodifica.
Scegliere un intero c, che sia primo rispetto ad T = (p-1)× (q-1), da utilizzare quale chiave pubblica di
codifica Kp.
Calcolare l’intero d per il quale risulta c× d mod T = 1, che verrà usato come chiave segreta di
decodifica Ks.
Rendere pubblici N e la chiave Kp=c.
Il messaggio cifrato X corrispondente ad un messaggio M si ottiene dalla relazione:
X=Mc mod N
mentre la decodifica avviene secondo la relazione:
Xd mod N = (Mc mod N)d mod N = Mcd mod N = M.
La sicurezza dello RSA è affidata alla difficoltà di determinare i fattori primi di un intero quando questo è molto
grande, difficoltà che aumenta in modo esponenziale al crescere del numero di bit usati per la chiave.
Algoritmo di ElGamal
Più vicino dello stesso RSA all’impostazione di Diffie ed Hellman, di cui è di fatto un’estensione, è l’approccio
proposto da ElGamal nel 1985 [ELGA85], nel quale ciascun interlocutore opera nel seguente modo:
1.
2.
3.
Vengono scelti con opportuni criteri gli interi N ed s, con 0 < s < N, che sono resi pubblici.
Viene scelto un intero k < N che verrà utilizzato come chiave privata Ks.
Viene calcolato e reso pubblico il valore di sk mod N che verrà utilizzato come chiave pubblica Kp.
La cifratura di un messaggio è un’operazione un po’ più complessa che nel caso dello RSA. Indicate con α e β le
chiavi segrete scelte da A e B, cosicché Kpa = sα mod N e Kpb = sβ mod N risultano essere le rispettive chiavi
pubbliche, se A vuole inviare un messaggio a B deve effettuare le seguenti operazioni:
1.
2.
3.
4.
Scegliere un intero h < N e calcolare x1 = sh mod N.
Calcolare K = (Kpb)h mod N.
Calcolare x2 = K× M mod N.
Inviare come messaggio cifrato X la coppia (x1, x2).
Il destinatario B, che riceve x1 = sh mod N e possiede β, calcola a sua volta K = (sh)β e recupera M dividendo x2
per il valore di K appena ricavato.
In pratica il sistema di ElGamal può essere riguardato come un cifrario simmetrico nel quale però la chiave di
codifica, da utilizzare anche per la decodifica, viene generata dinamicamente e comunicata, sfruttando il
protocollo di scambio di Diffie-Hellman, insieme con il messaggio.
Il meccanismo di cifrare i messaggi con un sistema simmetrico, generando in modo casuale per ciascuno di essi
una nuova chiave che viene allegata, cifrata mediante un sistema a chiavi pubbliche, al messaggio stesso, viene
largamente utilizzato per sopperire alla intrinseca inefficienza dei cifrari asimmetrici e consentire la cifratura in
linea dei messaggi scambiati in un sistema di comunicazione.
La sicurezza del sistema di ElGamal è ovviamente uguale a quella del protocollo di Diffie-Hellman e si basa sulla
complessità di soluzione del problema del logaritmo discreto.
Le curve ellittiche
Sono stati proposti sistemi crittografici a chiavi asimmetriche che possono essere riguardati come una
generalizzazione di quelli sopra descritti. Infatti, dal punto di vista matematico un tale sistema può essere
considerato come una trasformazione sopra gli elementi di un insieme che possiede la struttura di gruppo
algebrico, è quindi possibile ottenere sistemi diversi e con differenti caratteristiche di sicurezza sostituendo
l’insieme di base.
In particolare è possibile utilizzare come gruppo di base l’insieme dei punti di una curva ellittica definita su di un
campo finito, che costituisce un gruppo abeliano [MENE93]. Il vantaggio principale che si ottiene con tale
approccio è che una scelta opportuna della curva utilizzata dal sistema di cifratura consente di ottenere una
complessità matematica del problema della rottura del codice nettamente superiore a quella dei problemi della
fattorizzazione di un intero di grandi dimensioni o del calcolo del logaritmo discreto.
Uso degli algoritmi crittografici asimmetrici per la firma digitale
I metodi crittografici a chiavi pubbliche possono essere utilizzati per costruire strumenti per la firma digitale, la
differenza principale tra le due applicazioni risiede nel ruolo delle chiavi. Nella crittografia la chiave pubblica
viene utilizzata per la cifratura mentre il destinatario usa quella privata per recuperare il messaggio. Nella firma
il messaggio M non è in genere cifrato ed è direttamente disponibile per il destinatario, viceversa l’autore
utilizza la funzione di cifratura C e la chiave privata Ks per generare il valore di X che, aggiunto ad M, ne
certifica la provenienza grazie alla segretezza della chiave privata. X costituisce la firma digitale di M. Chiunque
può accertare la provenienza del messaggio utilizzando la chiave pubblica Kp per verificare che il valore della
firma corrisponda al messaggio grazie alla relazione:
D(Kp,X) = M
In realtà la verifica della corrispondenza tra firma e messaggio garantisce solo che questa è stata generata
mediante la chiave privata corrispondente a Kp, occorre perciò assicurare per altra via la corrispondenza tra
chiavi e soggetto autore del messaggio. A tale scopo viene utilizzata la "Autorità di Certificazione" (AC), la
quale, dopo aver accertato dell’identità del possessore della chiave privata e della corrispondenza tra questa e
quella pubblica, certifica l’identità del possessore della chiave privata (a meno della rottura della sua
segretezza). L’uso dell’autorità di certificazione consente di raggiungere, oltre la certezza dell’identità
dell’autore di un messaggio, anche l’impossibilità da parte di questi di ripudiare i messaggi da lui generati;
infatti, essendo l’unico detentore della chiave privata è anche l’unico soggetto in grado di generare firme
verificabili con la corrispondente chiave pubblica.
Sebbene qualunque sistema crittografico a chiavi pubbliche possa essere utilizzato per generare firme
elettroniche, un aspetto di grande importanza pratica consiste nella disponibilità di algoritmi di codifica e
decodifica specificamente adatti per la generazione e la verifica della firma. Infatti, dato che di norma il
messaggio M è direttamente disponibile per il destinatario insieme con X, non si ha alcun interesse nella
possibilità di ricostruire M da X. Ciò consente di ridurre molto la lunghezza di X a beneficio dell’efficienza delle
operazioni naturalmente lente di codifica e decodifica.
C’è un altro aspetto di notevole interesse pratico legato alla disponibilità di algoritmi diversi per la cifratura e la
firma. Il governo americano impedisce l’esportazione di software di cifratura che utilizzi chiavi di lunghezza tale
da garantire la resistenza del cifrario per un periodo relativamente lungo. Un’analoga limitazione non si applica
agli algoritmi di generazione e verifica di firme elettroniche a patto che questi non siano modificabili in modo da
renderli utilizzabili per la cifratura.
Lo RSA
L’uso dello RSA per generare firme elettroniche [RSA78] si basa semplicemente sull’inversione del ruolo delle
chiavi rispetto a quello per assicurare la riservatezza, la principale differenza tra le due applicazioni sta nel fatto
che per la firma si evita di applicare l’operazione di codifica all’intero testo. Ciò è particolarmente conveniente
vista la complessità, e quindi la lentezza, delle operazioni coinvolte.
In pratica il testo da firmare viene "compresso" in una sorta di "riassunto", che viene spesso riferito come
"impronta", mediante una opportuna funzione di hash progettata in modo da rendere trascurabile la probabilità
che da testi diversi si possa ottenere il medesimo valore. La dimensione del riassunto è fissa ed è molto più
piccola di quella del messaggio originale; infatti è dell’ordine del centinaio di bit, ciò rende la generazione della
firma, effettuata a partire dall’impronta anziché dal testo, estremamente più rapida. Qualche dettaglio su come
venga realizzata questa operazione verrà fornito nella sezione successiva.
ElGamal
L’algoritmo proposto da ElGamal per la firma digitale [ELGA85] è alquanto diverso da quello già citato destinato
alla cifratura. Per generare la firma di un testo M occorre effettuare le seguenti operazioni:
1.
2.
3.
4.
Generare casualmente un intero h nell’intervallo [0, N-1] che sia primo rispetto N-1.
Calcolare u=sh mod N.
Risolvere rispetto a v la relazione di congruenza M ≡ Ks u + h v mod (N-1).
La firma di M è la coppia (u,v).
La verifica della firma viene effettuata in base alla relazione:
sM = Kpu uv mod N
La sicurezza del sistema è basata sul fatto che la determinazione di una coppia di valori (u,v) che soddisfi la
precedente equazione richiede la soluzione del problema del logaritmo discreto nel caso in cui si fissi u e si
cerchi di determinare v di conseguenza; nel caso opposto, ossia fissando v e cercando di calcolare u, si incappa
in una congruenza esponenziale mista per la quale non sono noti algoritmi efficienti di soluzione.
Schnorr
Il metodo di generazione della firma dovuto a Schnorr [SCHN91] è analogo a quello di ElGamal, dal quale
differisce essenzialmente per l’introduzione di una funzione di hash H che associa a ciascun messaggio ed a
ciascuna chiave un intero in un intervallo di ampiezza predefinita T.
La procedura di generazione della firma è la seguente:
1.
2.
3.
4.
5.
Generare casualmente un intero h nell’intervallo [0,N-1].
Calcolare u=sh mod N.
Calcolare il valore della funzione di hash corrispondente al messaggio ed ad u, ossia e=H(M,u).
Calcolare v=Ks e + h mod N
La firma di M è la coppia (v,e).
La verifica si effettua nel modo seguente:
1.
2.
Calcolare sv.
Calcolare Kp
Anche la sicurezza del sistema di firma di Schnorr, come quello di ElGamal, è legata alla complessità di
soluzione del problema del calcolo del logaritmo discreto. Il vantaggio principale che questo algoritmo presenta
rispetto al precedente è la possibilità di scegliere la dimensione della firma selezionando opportunamente
l’ampiezza T del codominio della funzione di hash.
DSS
Il Digital Signature Standard [FIPS186], proposto dal NIST (National Institute of Standard and Technology) nel
1991, è sostanzialmente una variante del metodo di Schnorr in cui la funzione di hash H ha come unico
argomento il messaggio e quindi il suo valore non dipende dalla chiave di cifratura. L’utilizzazione del sistema
richiede preliminarmente la generazione delle chiavi secondo la seguente procedura:
1.
2.
3.
4.
5.
Scegliere
tra 2511 e
Scegliere
Scegliere
Scegliere
Calcolare
un intero P, da usare nelle operazioni di modulo, che deve essere un numero primo compreso
2512.
un intero Q, divisore primo di P-1 compreso tra 2159 e 2160.
un intero G, nell’intervallo [0,P-1].
di un intero x nell’intervallo (0,Q), che costituisce la chiave privata Ks.
l’intero y = Gx utilizzato come chiave pubblica Kp.
Ottenute le chiavi, la generazione della firma per un messaggio M si ottiene nel modo seguente:
1.
2.
3.
4.
Scegliere casualmente un intero h compreso nell’intervallo (0,Q).
Calcolare l’intero u = (Gh mod P) mod Q.
Determinare il valore di v risolvendo la relazione H(M)= Ks u + h v (mod Q).
La firma di M è la coppia (u,v).
La verifica viene condotta mediante la seguente procedura:
1.
2.
3.
4.
5.
Determinare il valore w tale che w v = 1 mod Q
Calcolare i = H(M) w mod Q.
Calcolare l = u w mod Q.
Calcolare t = ((Gi Kp) mod P) mod Q.
Verificare che t = u.
Il DSS è di fatto una variante dell’algoritmo di Schnorr e quindi deve la sua robustezza alla complessità del
problema del logaritmo discreto, tuttavia la predefinizione dei limiti di variabilità dei parametri di base ha
attirato numerose critiche riguardo l’effettiva sicurezza raggiungibile.
Il processo di firma digitale
Il processo di firma digitale richiede che l’utente effettui una serie di azioni preliminari necessarie alla
predisposizione delle chiavi utilizzate dal sistema di crittografia su cui il meccanismo di firma si basa; in
particolare occorre:
1.
2.
3.
4.
la
la
la
la
registrazione dell’utente presso un’autorità di certificazione,
generazione di una coppia di chiavi Ks e Kp,
certificazione della chiave pubblica Kp,
registrazione della chiave pubblica Kp.
Una volta espletate tali operazioni, per tutta la durata del periodo di validità della certificazione della chiave
pubblica, l’utente è in grado di firmare elettronicamente un numero qualunque di documenti sfruttando la sua
chiave segreta Ks,. Tale periodo può essere interrotto prima del suo termine naturale dalla revoca della
certificazione, che di norma viene effettuata su richiesta del proprietario qualora egli ritenga che la segretezza
della sua chiave privata sia stata compromessa, ma che potrebbe avvenire anche per iniziativa dell’AC, ad
esempio perché l’utente non ha più titolo per l’uso della chiave.
Il processo di sottoscrizione, schematicamente mostrato nella Figura 1, consta di una sequenza di tre
operazioni:
1.
2.
3.
generazione dell’impronta del documento da firmare,
generazione della firma mediante cifratura dell’impronta,
apposizione della firma al documento.
DOCUMENTO
FUNZIONE
DI HASH
IMPRONTA
DOCUMENTO
ALGORITMO DI
DECODIFICA
FIRMA
DIGITALE
CHIAVE
PRIVATA
Figura 1 - Generazione della firma digitale
Le fasi di tale processo e quelle preliminari di registrazione dell’utente e certificazione delle chiavi verranno ora
ordinatamente analizzate con qualche dettaglio.
Registrazione dell’utente
La registrazione dell’utente presso una autorità di certificazione ha il duplice scopo di rendere questa certa della
sua identità ed instaurare con esso un canale di comunicazione sicuro attraverso il quale verranno fatte
viaggiare le chiavi pubbliche di cui viene richiesta la certificazione. All’atto della registrazione l’autorità di
certificazione attribuisce all’utente un identificatore, di cui viene garantita l’univocità, attraverso il quale sarà
possibile a chiunque reperire in modo diretto e sicuro i certificati rilasciati al soggetto all’interno dei cataloghi
pubblici in cui questi sono registrati.
La registrazione avviene attraverso la seguente procedura:
1.
2.
3.
4.
L’utente richiede alla AC la registrazione fornendo la documentazione richiesta da questa per accertare
la sua identità.
Verificata la validità della richiesta, AC attribuisce all’utente un identificatore di cui essa garantisce
l’univocità.
La AC inserisce l’utente con l’identificatore attribuitogli nei cataloghi di utenti registrati che essa
gestisce.
La AC fornisce attraverso un canale sicuro la chiave crittografica che l’utente dovrà utilizzare per le
richieste di certificazione delle chiavi e per accedere ai registri dell’autorità.
La necessità di utilizzare un canale sicuro di comunicazione tra utente ed autorità di certificazione, asserita al
precedente punto 4, non è motivata da esigenze di riservatezza, infatti su tale canale viaggiano essenzialmente
chiavi pubbliche, ma di autenticità. Infatti l’autorità di certificazione, quando riceve una richiesta da un utente,
deve avere la certezza che questa provenga effettivamente da lui e non da qualcuno che lo sta impersonando.
Ciò non può essere sempre ottenuto con la normale firma digitale, basti pensare al caso della richiesta di
certificazione della prima chiave oppure a quella di revoca di una chiave. Analoghi problemi sorgono per l’utente
nei confronti dell’AC quando, ad esempio, questi abbia necessità di verificare la validità della chiave di
certificazione che potrebbe, in un caso estremo, essere stata revocata.
In realtà la possibilità di verificare con certezza la validità della chiave pubblica di certificazione, e quindi la
disponibilità di un canale sicuro attraverso cui effettuare tale operazione, è l’elemento base per garantire
l’affidabilità dell’intero sistema di firma digitale, infatti dalla validità di questa può essere fatta scaturire la
garanzia di validità di tutte le altre.
Generazione della coppia di chiavi
L’utente, mediante un programma adatto al sistema crittografico adottato, genera una coppia di chiavi. Una di
esse, quella da utilizzare per le operazioni di cifratura e quindi per la generazione della firma, sarà mantenuta
segreta ed assumerà il ruolo di Ks. L’altra, destinata alla verifica, verrà resa pubblica attraverso la certificazione
e corrisponderà perciò a Kp.
Certificazione della chiave pubblica
La certificazione della chiave pubblica ha lo scopo di rassicurare chiunque riceva un documento correttamente
firmato, circa l’identità del soggetto che ha apposto la firma. L’operazione avviene attraverso tre passi:
1.
2.
3.
L’utente invia alla AC la richiesta di certificazione per la chiave Kp generata nella fase precedente,
autenticandola mediante la chiave ricevuta dalla AC durante il processo di registrazione.
L’autenticazione può avvenire sia mediante cifratura del messaggio di richiesta, ovvero mediante la sua
sottoscrizione digitale. Poiché lo scambio di messaggi implicato nella certificazione è bilaterale, in
questa fase si possono utilizzare algoritmi di crittografia simmetrici.
La AC genera il certificato e lo sottoscrive per garantirne la provenienza che potrà essere accertata da
chiunque utilizzando la chiave pubblica di AC.
Il certificato viene inviato al richiedente.
Registrazione della chiave pubblica
Una volta emesso, il certificato può essere reso disponibile in uno o più cataloghi ai quali può accedere chiunque
abbia bisogno di accertare la validità di una sottoscrizione digitale. Questa operazione viene di norma
effettuata, almeno per i cataloghi di sua competenza, dalla AC, contestualmente all’emissione.
Generazione dell’impronta
Al testo da firmare viene applicata una funzione di hash appositamente studiata che produce, secondo il
meccanismo sinteticamente mostrato nella Figura 2, una stringa binaria di lunghezza costante e piccola,
normalmente 128 o 160 bit. La funzione di hash assicura l’unicità di tale stringa, nel senso che a due testi
diversi non corrisponde la medesima impronta. Sono disponibili diversi algoritmi di generazione, quali, ad
esempio, MD2 [KALI92], MD4 [RIVE90] e MD5 [RIVE92], originariamente progettati per operare in
combinazione con lo RSA ma utilizzabili con qualsiasi cifrario. Sono disponibili anche algoritmi di hash per i quali
è in corso la standardizzazione ufficiale da parte organismi internazionali, ne sono un esempio il RIPEMD a 128
e 160 bit ed il Secure Hash Algorithm (SHA-1) [JTC196].
Figura 2 - Generazione del'impronta
L’utilità dell’uso dell’impronta è duplice, in primo luogo consente di evitare che per la generazione della firma
sia necessario applicare l’algoritmo di cifratura, che è intrinsecamente inefficiente, all’intero testo che può
essere molto lungo. Inoltre consente l’autenticazione, da parte di una terza parte fidata, della sottoscrizione di
un documento senza che questa venga a conoscenza del suo contenuto. Una tipica situazione in cui si sfruttano
tali caratteristiche dell’impronta è la marcatura temporale che verrà discussa più avanti.
Generazione della firma
La generazione della firma consiste semplicemente nella cifratura, con la chiave segreta Ks, dell’impronta
digitale generata il precedenza. In questo modo la firma risulta legata da un lato, attraverso la chiave segreta
usata per la generazione, al soggetto sottoscrittore, e dall’altro, per il tramite dell’impronta, al testo
sottoscritto.
In realtà l’operazione di cifratura viene effettuata, anziché sulla sola impronta, su una struttura di dati che la
contiene insieme con altre informazioni utili, quali ad esempio l’indicazione della funzione hash usata per la sua
generazione. Sebbene tali informazioni possano essere fornite separatamente rispetto alla firma, la loro
inclusione nell’operazione di codifica ne garantisce l’autenticità.
Apposizione della firma
La firma digitale generata al passo precedente viene aggiunta in una posizione predefinita, normalmente alla
fine, al testo del documento. Normalmente, insieme con la firma vera e propria, viene allegato al documento
anche il valore dell’impronta digitale ed eventualmente il certificato da cui è possibile recuperare il valore della
chiave pubblica.
È evidente che essendo il legame tra firma e documento, stabilito attraverso l’impronta, di natura puramente
logica, la firma stessa e le informazioni aggiuntive eventualmente ad essa associate possono essere registrate e
gestite in modo del tutto separato rispetto al testo sottoscritto; in particolare possono trovarsi su supporti e
sistemi di elaborazione del tutto indipendenti tra loro.
Verifica della firma digitale
L’operazione di verifica della firma digitale, mostrata schematicamente in Figura 3, viene effettuata
ricalcolando, con la medesima funzione di hash usata nella fase di sottoscrizione, il valore dell’impronta e
controllando che il valore così ottenuto coincida con quello generato per decodifica della firma digitale stessa.
DOCUMENTO
FUNZIONE
DI HASH
IMPRONTA
DOCUMENTO
ALGORITMO DI
DECODIFICA
FIRMA
DIGITALE
CHIAVE
PUBBLICA
Figura 3 - Verifica della firma digitale
Per facilitare l’operazione di verifica viene di solito allegato al documento firmato anche il certificato relativo alla
chiave pubblica. Ciò non sarebbe strettamente necessario, dato che questo dovrebbe essere sempre
recuperabile dal registro pubblico del certificatore, tuttavia, specie nel caso in cui la struttura di dati che
costituisce la firma è povera di informazioni, tale ricerca potrebbe essere notevolmente onerosa, soprattutto se
il registro in cui cercare non è univocamente determinato.
Al contrario, la disponibilità del certificato consente di disporre immediatamente delle seguenti informazioni,
difficilmente contenute nella firma:
1.
2.
3.
La chiave pubblica di verifica, mediante cui è possibile effettuare subito un controllo preliminare che
consente, in caso di fallimento, di evitare ogni ulteriore azione.
L’identità dell’autorità di certificazione che ha emesso il certificato. Questa informazione è preziosa per
determinare le modalità di accertamento della validità della firma.
Il codice di identificazione del certificato assegnato dal certificatore. Il suo possesso consente di
accedere ai registri in modo diretto, evitando ricerche basate sull’identità del sottoscrittore, che sono
inefficienti e maggiormente soggette ad errori.
La presenza di un certificato formalmente valido non può però esimere dalla verifica presso il certificatore, è
infatti possibile che sia sopraggiunta una revoca della chiave di sottoscrizione, o, all’estremo, di quella di
certificazione.
Marcatura temporale
Qualora sia necessario attribuire ad un documento certezza circa il momento in cui questo è stato redatto ed è
divenuto valido, si ricorre alla sua marcatura temporale. Questa consiste nella generazione da parte di una
terza parte fidata, normalmente una AC, di una ulteriore firma digitale aggiuntiva rispetto a quella del
sottoscrittore.
CHIAVE
PUBBLICA
IMPRONTA
DOCUMENTO
ALGORITMO DI
DECODIFICA
MARCA
TEMPORALE
CHIAVE
PUBBLICA
Figura 4 - Generazione della marca temporale
L’operazione, rappresentata schematicamente nella Figura 4, avviene secondo la seguente procedura:
1.
2.
3.
4.
L’impronta del documento viene inviata al servizio di marcatura temporale, l’impronta costituisce un
riferimento certo al testo originale ma non ne consente la ricostruzione, pertanto la marcatura può
essere effettuata senza compromettere la confidenzialità del testo.
Il servizio di marcatura aggiunge all’impronta ricevuta la data e l’ora, ottenendo una "impronta
marcata".
L’impronta marcata viene cifrata con la chiave segreta del servizio, ottenendo la marca temporale da
cui è possibile recuperare, mediante la chiave pubblica del servizio, l'impronta del documento e la data
e l'ora della sua generazione.
La marca temporale viene inviata al richiedente il quale la allega al documento.
La marcatura temporale presenta interessanti analogie con l'autenticazione e può essere usata per garantire
che un documento non venga in secondo tempo sostituito con uno diverso da parte dell’autore stesso.
La standardizzazione
Sotto la spinta delle applicazioni commerciali, ed in particolare di quelle bancarie, sono stati sviluppati numerosi
standard, tanto de iure che de facto, relativi all’uso delle tecniche crittografiche, che possono trovare
applicazione per la sottoscrizione digitale.
Nell’ambito della standardizzazione ufficiale, un ruolo determinante é ovviamente giocato dall’International
Standard Organization, che costituisce l’ente normatore primario a livello internazionale. Tale organismo ha
emanato numerose norme in campo crittografico, destinate principalmente al settore bancario ed a quello della
tecnologia dell’informazione, le più significative sono elencate nell’Appendice. Si tenga presente che, per la
normazione in campo informatico, l’ISO opera in congiunzione con l’International Electrical Commission (IEC),
con la quale ha costituito un apposito comitato tecnico congiunto, la Joint Technical Comittee n° 1 (JTC1).
Accanto all’ISO, ed in modo coordinato con esso, opera l’International Telecommunication Union (ITU), che ha
sostituito lo storico CCITT ed emette "raccomandazioni" che hanno valore di norme primarie nei settori delle
telecomunicazioni (ITU-T) e della radiodiffusione (ITU-R). Da esso i provengono le raccomandazioni X.400 ed
X.500 che hanno una importanza fondamentale per i sistemi di messaggistica elettronica. In particolare alla
famiglia X.500 appartiene la raccomandazione X.509 verso cui stanno convergendo tutti i sistemi di
autenticazione e firma digitale quale standard per i certificati. Il coordinamento tra ITU ed ISO è, almeno per le
questioni che hanno riflessi sulla firma digitale, molto stretto. Infatti l’intera famiglia X.500 è emanata in modo
congiunto, ossia a ciascuna "raccomandazione" ITU-T corrisponde uno "standard internazionale" ISO tali che il
testo di entrambi è esattamente lo stesso. Nell’Appendice é riportata la tabella di corrispondenza tra i due tipi di
norme, si noti la diversa tecnica di numerazione usata dai due enti: l’intera famiglia ITU-T è associata ad
un’unica norma ISO/IEC, la 9594, con ciascuna raccomandazione in corrispondenza di una parte di questo
standard.
Accanto agli enti normatori internazionali non può essere ignorato il ruolo delle maggiori organizzazioni di
standardizzazione americane. Il National Institute of Standards and Technology (NIST) è già stato ricordato per
la definizione del Digital Signature Standard (DSS). Ad esso si affianca lo American National Standards Institute
(ANSI), ben noto per i suoi standard largamente diffusi nel mondo dell’informatica, che ha emesso numerose
norme per il settore finanziario tra cui vale la pena ricordare la X9.30.1, che definisce il Digital Signature
Algorithm (DSA), e la X9.30.2, che specifica il Secure Hash Algorithm (SHA-1) recepito anche dall’ISO nella
norma ISO/IEC CD 10118-3 [JTC196].
Deve essere infine menzionato lo Institute of Electrical and Electronics Engineers (IEEE), al quale si deve tra
l’altro la standardizzazione di Ethernet, che sta compiendo un notevole sforzo per sviluppare uno standard unico
ed integrato comprendente tutti gli algoritmi asimmetrici attualmente disponibili, da quelli basati sulla
fattorizzazione degli interi, a quelli che sfruttano il problema del logaritmo discreto, a quelli che usano le
proprietà delle curve ellittiche. Tale progetto di standard viene indicato con la sigla P1363.
Parallelamente agli standard ufficiali, e per alcuni versi in anticipo rispetto a questi, sono stati sviluppati e si
sono affermati alcuni standard di fatto che non possono essere trascurati, soprattutto perché possono vantare
un numero di implementazioni ed una quantità di utenti superiore a quella degli standard de iure. In tale ambito
deve essere ricordato in primo luogo Pretty Good Privacy (PGP), cui deve essere riconosciuto il merito di aver
diffuso la crittografia a chiavi pubbliche, sia pure più con lo scopo di proteggere la riservatezza della
comunicazione che per l’autenticazione dei documenti. Il pacchetto, originariamente sviluppato al
Massachussets Institute of Technology (MIT) e finora di libero utilizzo per scopi non commerciali, è attualmente
lo strumento maggiormente usato in ambito privato ed anche il primo a consentire l’uso, accanto al tradizionale
RSA, del DSS.
Per la diffusione nei prodotti commerciali deve essere infine considerato il Public Key Crypto System (PKCS), un
insieme di specifiche tecniche pubblicate dalla RSA Inc. con lo scopo di fornire uno strumento atto a garantire
l’interoperabilità dei prodotti utilizzanti il cifrario di Rivest Shamir e Adleman.
In definitiva gli standard attinenti la firma digitale maggiormente rilevanti a livello europeo possono essere
inquadrati in quattro filoni principali:
1.
2.
3.
4.
standard bancari;
norme ISO per la tecnologia dell’informazione;
PGP;
PKCS.
Gli standard utilizzati nel settore bancario rivestono particolare importanza poiché sono quelli maggiormente
consolidati e collaudati; d’altra parte essi si presentano in realtà come una molteplicità di norme eterogenee e
sostanzialmente incompatibili tra loro, sviluppate sotto la spinta di specifiche applicazioni, quali il trasferimento
di ordinativi, l’effettuazione di transazioni con carta di credito e così via. L’integrazione dei servizi e dei vari
circuiti bancari ha comunque portato allo sviluppo di strumenti di interoperabilità e alla progressiva convergenza
verso le norme di maggiore generalità.
L’eterogeneità presente nel settore si manifesta in modo eclatante nella sostanziale incompatibilità tra norme
emanate dalla stessa organizzazione, come accade nel caso degli standard internazionali emanati dall’ISO per il
settore bancario da un lato e per quello della tecnologia dell’informazione dall’altro. Questi ultimi, più recenti,
costituiscono la base su cui costruire sistemi interoperabili e durevoli nel tempo. Un fatto che conforta questa
prospettiva é la progressiva convergenza, nel settore più maturo della tecnologia, quello dei certificati, verso lo
X.509 come standard di base unico, eventualmente esteso in modo diverso secondo le particolari necessità, ma
comunque universalmente supportato nelle caratteristiche essenziali.
In effetti fino ad oggi le tecniche crittografiche, anche a chiavi pubbliche, sono state utilizzate essenzialmente
per assicurare la riservatezza della comunicazione e quindi la compatibilità e l’interoperabilità erano considerate
caratteristiche di secondaria importanza, se non addirittura potenzialmente pericolose. Il ribaltamento della
prospettiva introdotto dalla firma digitale, che deve garantire l’autenticità di un documento di fronte a chiunque
e non solo per il diretto destinatario, porterà, come è successo nei protocolli di comunicazione, ad una rapida
convergenza verso gli standard maggiormente efficaci.
Appendice
Principali norme ISO
L’elenco che segue riporta quelli più direttamente correlati con le problematiche connesse alla firma digitale.
ISO/IEC 8372:1987 Modes of operation for a 64-bit block cipher algorithm.
ISO/IEC 8731-1:1988 Banking - Approved Algorithms for Message Authentication - Part 1: DEA
ISO/IEC 8731-2:1992 Banking - Approved Algorithms for Message Authentication - Part 2: Message
Authentication Algorithm
ISO/IEC 8732:1988 Banking - Key management (wholesale)
ISO/IEC 9796:1991 Information technology - Security techniques - Digital signature scheme giving message
recovery.
ISO/IEC 9796-2:1997 Information technology - Security techniques - Digital signature scheme giving message
recovery – Part 2: Mechanisms Using a Hash-Function
ISO/IEC 9797:1994 Information technology - Security techniques - Data integrity mechanism using a
cryptographic check function employing a block cipher algorithm.
ISO/IEC 9798-1:1991 Information technology - Security techniques - Entity authentication mechanism - Part 1:
General model (in revisione come DIS).
ISO/IEC 9798-2:1994 Information technology - Security techniques - Entity authentication mechanism - Part 2:
Mechanisms using symmetric encipherment algorithms.
ISO/IEC 9798-3:1993 Information technology - Security techniques - Entity authentication mechanism - Part 3:
Mechanisms using a public key algorithm.
ISO/IEC 9798-4:1995 Information technology - Security techniques - Entity authentication mechanism - Part 4:
Mechanisms using a cryptographic check function.
ISO/IEC WD 9798-5:1995 Information technology - Security techniques - Entity authentication mechanism Part 5: Mechanisms using zero knowledge techniques.
ISO/IEC 9979:1991 Data cryptografic techniques - Procedures for the registration of cryptographic algorithms.
ISO/IEC 10116:1991 Information technology - Security techniques - Modes of operation for an n-bit block
cipher algorithm (in revisione come DIS).
ISO/IEC 10118-1:1994 Information technology - Security techniques - Hash-functions - Part 1: General.
ISO/IEC 10118-2:1994 Information technology - Security techniques - Hash-functions - Part 2: Hash-functions
using an n-bit block cipher algorithm.
ISO/IEC CD 10118-3 Information technology - Security techniques - Hash-functions - Part 3: Dedicated hashfunctions.
ISO/IEC CD 10118-4 Information technology - Security techniques - Hash-functions - Part 4: Hash-functions
using modular arithmetic.
ISO/IEC 10126-1:1991 Banking - Procedures for message encipherment (wholesale) - Part 1: General
principles.
ISO/IEC 10126-2:1991 Banking - Procedures for message encipherment (wholesale) - Part 2: DEA algorithm.
ISO/IEC 11166-1:1994 Banking - Key management by means of asymmetric algorithms - Part 1: Principles,
procedures and formats.
ISO/IEC 11166-2:1994 Banking - Key management by means of asymmetric algorithms - Part 2: Approved
algorithms using the RSA cryptosystem.
ISO 11568-1:1994 Banking - Key management (retail) - Part 1: Introduction to key management.
ISO 11568-2:1994 Banking - Key management (retail) - Part 2: Key management techniques for symmetric
ciphers.
ISO 11568-3:1994 Banking - Key management (retail) - Part 3: Key life cycle for symmetric ciphers.
ISO DIS 11568-4 Banking - Key management (retail) - Part 4: Key management techniques for public key
cryptosystems.
ISO DIS 11568-5 Banking - Key management (retail) - Part 5: Key life cycle for public key cryptosystems.
ISO DIS 11568-6 Banking - Key management (retail) - Part 6: Key management schemes.
ISO/IEC DIS 11770-1 Information technology - Security techniques - Key management - Part 1: Framework.
ISO/IEC 11770-2:1996 Information technology - Security techniques - Key management - Part 2: Mechanism
using symmetric techniques.
ISO/IEC DIS 11770-3 Information technology - Security techniques - Key management - Part 3: Mechanism
using asymmetric techniques.
Corrispondenza ITU-T X.5xx e ISO/IEC 9594
ITU-T
ISO/IEC
Titolo
X.500
9594-1
X.501
9594-2
Information technology - Open Systems Interconnection - The Directory: Models
X.509
9594-8
Information technology - Open Systems Interconnection - The Directory: Authentication framework
X.511
9594-3
Information technology - Open Systems Interconnection - The Directory: Abstract service definition
X.518
9594-4
X.519
9594-5
Information technology - Open Systems Interconnection - The Directory: Protocol specifications
X.520
9594-6
Information technology - Open Systems Interconnection - The Directory: Selected attribute types
X.521
9594-7
Information technology - Open Systems Interconnection - The Directory: Selected object classes
X.525
9594-9
Information technology - Open Systems Interconnection - The Directory: Replications
X.530
9594-10
Information technology - Open Systems Interconnection - The Directory: Overview of concepts,
models and services
Information technology - Open Systems Interconnection - The Directory: Procedures for distributed
operation
Information technology - Open Systems Interconnection - The Directory: Use of systems
management for administration of the Directory
Riferimenti
[DIHE76] W. Diffie e M. Hellman, "New directions in cryptography", in "IEEE Transactions on Information
Theory", vol. 22 (1976), pp. 644-654.
[ELGA85] T. ElGamal, "A Public-Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms", in
"IEEE Transactions on Information Theory", vol. 31 (1985), n. 4, pp. 469-472.
[FIPS46] National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard,
U.S. Department of Commerce, FIPS PUB 46-2, Washington, DC, 1993.
[FIPS81] National Bureau of Standards, "DES Modes of operation Change Notices 1-2", Federal Information
Processing Standard, U.S. Department of Commerce, FIPS PUB 81, Washington, DC, 1980.
[FIPS186] National Bureau of Standards, "Digital Signature Standard (DSS) Change Notice", Federal
Information Processing Standard, U.S. Department of Commerce, FIPS PUB 186, Washington, DC, 1994.
[JTC196] International Organization for Standardization and International Electrotechnical Commission Joint
Technical Committee 1, "ISO/IEC Draft International Standard 10118-3: Information technology - Security
techniques - Hash functions - Part 3: Dedicated Hash functions", 1996.
[KALI92] B. Kaliski, "RFC 1319: The MD2 Message-Digest Algorithm", Internet Activities Board, Aprile 1992.
[MENE93] A. Menezes, "Elliptic Curve Public Key Cryptosystems", Kluwer Academic Publishers, Norwell,
Massachusetts, 1993.
[RIVE90] R. L. Rivest, "The MD4 Message Digest Algorithm", in "Advances in Cryptology - CRYPTO ‘90", Lecture
Notes in Computer Science, n. 537, Springer-Verlag, Berlino, 1991, pp. 303-311.
[RIVE92] R. L. Rivest, "RFC 1321: The MD5 Message Digest Algorithm", Internet Activities Board, Aprile 1992.
[RSA78] R. L. Rivest, A. Shamir e L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key
Cryptosystems", in "Communications of the ACM", vol. 21 (1978), n. 2, pp. 120-126.
[SCHN91] C. Schnorr, "Efficient signature generation by smart cards", in "Journal of Cryptology", n. 4 (1991),
pp. 161-174.
ALLEGATO 5
59
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Linee guida sulla qualità dei beni e dei
servizi ICT per la definizione ed il governo
dei contratti della Pubblica Amministrazione
Modelli per la Qualità
delle Forniture ICT
Manuale di riferimento
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT
Pagina 1/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
INDICE
1.
GENERALITÀ SUL DOCUMENTO........................................................................................................ 3
2.
GRUPPO DI LAVORO ........................................................................................................................... 3
3.
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT....................................................................... 3
4.
PUNTI DI VISTA PER LA DEFINIZIONE DELLA QUALITÀ ................................................................ 3
4.1.
QUALITÀ INTRINSECA DELLA FORNITURA ..................................................................................... 3
4.2.
PUNTO DI VISTA DEL FRUITORE ....................................................................................................... 3
4.3.
PUNTO DI VISTA DI CHI APPALTA ..................................................................................................... 3
5.
CICLO DI VITA DELLE FORNITURE .................................................................................................... 3
5.1.
PROCESSI PRIMARI ............................................................................................................................. 3
5.1.1.
PROCESSO DI ACQUISIZIONE ........................................................................................................ 3
5.1.2.
PROCESSO DI FORNITURA ............................................................................................................. 3
5.1.3.
PROCESSO DI PROGETTAZIONE ................................................................................................... 3
5.1.4.
PROCESSO DI REALIZZAZIONE E COLLAUDO ............................................................................ 3
5.1.5.
PROCESSO DI GESTIONE OPERATIVA ......................................................................................... 3
5.1.6.
PROCESSO DI MANUTENZIONE ..................................................................................................... 3
5.2.
PROCESSI TRASVERSALI................................................................................................................... 3
5.2.1.
PROCESSO DI GESTIONE................................................................................................................ 3
5.2.2.
PROCESSO DI DOCUMENTAZIONE................................................................................................ 3
5.2.3.
PROCESSO DI GESTIONE DELLA CONFIGURAZIONE ................................................................ 3
5.4.3
PROCESSO DI ASSICURAZIONE QUALITÀ ................................................................................... 3
6.
CATEGORIE ED ATTRIBUTI DI QUALITÀ DELLE FORNITURE ICT................................................. 3
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 2/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
6.1.
CARATTERISTICHE DI QUALITÀ (ISO 9126) ..................................................................................... 3
6.2.
DIMENSIONI DI QUALITÀ (SERVQUAL) ............................................................................................. 3
6.3.
MODELLO DI QUALITÀ ADOTTATO ................................................................................................... 3
6.4.
INDICATORI DI QUALITÀ ..................................................................................................................... 3
7.
GLOSSARIO .......................................................................................................................................... 3
8.
BIBLIOGRAFIA ...................................................................................................................................... 3
8.1.
TESTI...................................................................................................................................................... 3
8.2.
SITI INTERNET ...................................................................................................................................... 3
8.3.
RIVISTE .................................................................................................................................................. 3
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 3/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
1. GENERALITÀ SUL DOCUMENTO
Le Linee guida sulla qualità dei beni e dei servizi ICT per la definizione ed il governo dei
contratti della Pubblica Amministrazione hanno lo scopo di definire:
o
un quadro di riferimento complessivo per l’appalto pubblico di servizi ICT da parte
delle amministrazioni;
o
metodi quantitativi da applicarsi per definire misure di qualità ed identificare processi
di misura, allo scopo di fornire indicazioni concrete, pragmatiche, immediatamente
applicabili, sia alle amministrazioni appaltanti che ai fornitori offerenti;
o
adeguate clausole, da utilizzarsi in fase di negoziazione, per la definizione di capitolati
e contratti pubblici per la fornitura di beni e servizi nel settore ICT, relative alla
descrizione delle attività da prevedersi contrattualmente, ai prodotti che dette attività
realizzano (deliverables contrattuali), agli indicatori e misure di qualità da riferirsi sia
alle attività che ai prodotti;
o
clausole successivamente utili nella fase di attuazione dei contratti ICT, per la
necessaria azione di governo del contratto e lo svolgimento del monitoraggio per la
verifica del rispetto dei requisiti contrattuali in termini di tempi, costi e stato
avanzamento lavori, quantità e qualità attese dei servizi ICT richiesti.
Per la realizzazione di queste Linee guida, il gruppo di lavoro ha dovuto, propedeuticamente
alla scrittura delle diverse tipologie di forniture ICT, definire un modello che costituisse il
riferimento univoco al quale rifarsi. Ciò è stato reso necessario dall’elevato parallelismo con il
quale si è proceduto alla scrittura delle Linee guida ed al grande numero di persone che hanno
direttamente contribuito con propri scritti.
L’approccio alla base del lavoro, più dettagliatamente illustrato nel Manuale d’uso
“Presentazione ed utilizzo delle Linee guida”, si basa:
o
sull’identificazione dei diversi punti di vista per la definizione della qualità concorrenti
in ambito contrattuale;
o
sull’analisi dell’intero ciclo di vita che realizza la fornitura;
o
sull’identificazione di indicatori di qualità da riferirsi alle caratteristiche di qualità
delle attività e prodotti del ciclo di vita.
Questi tre aspetti fondanti del lavoro svolto sono stati esplicitati e dibattuti prima ancora di
iniziare il lavoro di descrizione delle forniture ICT. A queste riflessioni si è scelto di riferirsi
con il termine di “Modelli per la qualità delle forniture ICT”.
Scopo di questo manuale di riferimento è presentare i “Modelli per la qualità delle forniture
ICT” illustrando gli standard e le logiche adottate per la descrizione delle forniture elementari
e la definizione della loro qualità.
Diversamente dalle altre componenti delle Linee guida, Manuali applicativi e Dizionario delle
forniture ICT, questo manuale non esprime “ragionamenti in materia di appalto” o fornisce
“ricette contrattuali” di immediata applicazione in fase di definizione o governo di un contratto
ICT.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 4/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Ciò nonostante si è ritenuto utile completare ed integrare i contenuti affrontati dalle Linee
guida in un ottica operativa e pragmatica con un Manuale di riferimento che fornisse i
riferimenti culturali di base e puntamenti a possibili approfondimenti.
Questo manuale di riferimento presenta:
o
punti di vista per la definizione di qualità
o
processi del ciclo di vita della generica fornitura
o
categorie ed attributi di qualità della generica fornitura
o
glossario (definizioni e acronimi)
o
bibliografia (testi, articoli, siti)
Riferimenti
o
UNI CEI ISO/IEC 12207: 2003 "Tecnologia dell'informazione - Processi del ciclo di vita
del software";
o
Norma ISO/IEC 9126-1:2001 “Software engineering - Product quality - Part 1: Quality
mode”.l
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 5/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
2. GRUPPO DI LAVORO
Le Linee guida di cui il presente manuale fa parte integrante sono state elaborate da un
Gruppo di lavoro, dedicato alla qualità dei beni e dei servizi ICT per la definizione ed il
governo dei contratti ICT della Pubblica Amministrazione. Il Gruppo di lavoro è stato
costituito nel dicembre 2003 dal Centro nazionale per l’informatica nella pubblica
amministrazione (CNIPA), in modo tale da rappresentare al suo interno sia alcune
amministrazioni centrali, che le associazioni di categoria dei fornitori di servizi ICT.
Il Gruppo di Lavoro, di cui è referente l’Ing. Marco Martini, Componente dell’Organo collegiale
del CNIPA, è stato coordinato dal Dott. Marco Gentili, Dirigente del CNIPA. Fanno parte del
Gruppo di lavoro:
Monica Barattieri
Dario Biani
Annarita Bove
Antonello Busetto
Arnaldo Carbone
Caterina Ciarallo
Alfredo D’Amato
Giuseppe Neri
Giorgio Pala
Enrico Pesce
Roberto A. Romano
Giorgio Turconi
in rappresentanza del Ministero di Giustizia;
CNIPA;
in rappresentanza del MIUR
in rappresentanza di FEDERCOMIN;
in rappresentanza di CONSIP;
CNIPA;
in rappresentanza dell'INPS;
in rappresentanza di ASSINFORM;
CNIPA, consulente;
in rappresentanza di SOGEI
in rappresentanza di ANASIN/AITech;
CNIPA, consulente.
Pur non partecipando al Gruppo di lavoro, la Banca d’Italia ha messo a disposizione
l’esperienza codificata nel proprio manuale di qualità del software e fornito utili indirizzi sul
tema dei servizi afferenti allo sviluppo del software, in particolare si ringraziano:
Stefano Fabrizi
Dario Russo
Le Amministrazioni direttamente coinvolte nel Gruppo di lavoro, hanno partecipato ai lavori e
contribuito alla redazione delle Linee anche per il tramite di proprio personale non
direttamente rappresentato nel gruppo, si ringraziano per questo:
Sergio Giacoponi
Gianfranco Pontevolpe
Carla Mastino
Marina Venzo
Aldo Mastroianni
Le imprese associate a Anasin/AITech, Assinform e Federcomin, chiamate a partecipare dalle
proprie associazioni, hanno risposto con entusiasmo e partecipato alla definizione delle Linee
guida mettendo a disposizione le proprie fattive esperienze di erogazione dei servizi ICT e
predisposizione di offerte.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 6/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Hanno contribuito con particolare continuità una ventina di diverse imprese, tra le più
rappresentative del mercato ICT nazionale, che hanno contribuito affiancando il gruppo di
lavoro con circa 80 persone loro dipendenti.
Accenture
Bull
Laser Memory card
ACI Informatica
COMPUWARE
GETRONICS
SAP Italia
Alcatel
CSC Italia
Microsoft
Business Object
EDS Italia
IBM
Sistemi Informativi
Atesia
Elsag
Symantec
C&M Group
FINSIEL
ORACLE Italia
Telecom Italia
Un particolare ringraziamento va pertanto a:
Guido Allegrezza
Brunello Bonanni
Paolo Buttinelli
Marco Casazza
Giuseppe Conforti
Maurizio De Benedetto
Laura Destro
Barbara Donato
Salvatore Ferraro
Giovanni Gadaleta
Ludovico Gullifa
Fabrizio Liberatore
Giacinto Lopiccolo
Loredana Mancini
Giacomo Massi
Francesco Meneghetti
Mario Modesti
Daniele Pagani
Giuliano Perego
Romano Poggi
Domenico Pugliese
Andrea Rigoni
Alessandro Rossi
Giacomo Samuelli Ferretti
Teresa Saragò
Lorenzo Severini
Alfredo Vessicchio
Emanuela Banzo
Piero Bordoni
Roberto Caldarella
Alessandra Chianese
Luigi Costantini
Alfonso De Cristofaro
Giuseppe di Cesare
Carla Fabiano
Assunta Formato
Aurora Girolamo
Vittorio La Commare
Ferdinando Liberti
Francesco Magatti
Andrea Manuti
Ettore Mastrorilli
Luigi Mezzanotte
Franco Moselli
Marco Palermo
Marcella Pignatiello
Andrea Praitano
Annalisa Quagliata
Massimo Rocchi
Maurizio Sacchetti
Vincent N. Santacroce
Emanuela Savelli
Francesco Strata
Stefania Zaccagnini
Danilo Bianco
Giuseppe Borgonovo
Maurizio Caminiti
Fabio Conciatori
Carmine D'arconte
Roberto De Preta
Marco Di Leo
Elena Farina
Alessandro Fossati
Andrea Giuliani
Cristina Leonardi
Stefania Lombardi
Luca Malagodi
Francesco Marconi
Alessandro Mehlem
Giuseppe Militello
Federico Morena
Paola Palleschi
Giovanni Pistarini
Anna Prelati
Antonio Lorenzo Rassu
Paolo Roncella
Bruno Salvadori
Lorella Santucci
Bruno Scialpi
Marco Tampelloni
In varie fasi del lavoro il Gruppo si è avvalso anche dei contributi e dei suggerimenti di altre
persone ed aziende ICT che, pur non essendo coinvolte operativamente nella scrittura delle
Linee guida, hanno seguito con interesse i lavori.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 7/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
3. MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Nell’impostazione della struttura delle Linee guida, si è cercato di identificare il percorso
logico più opportuno per definire dei modelli di qualità delle forniture ICT per la Pubblica
Amministrazione. Non essendo disponibile in letteratura alcun riferimento certo e puntuale, si
è deciso di procedere su due fronti paralleli.
Da un lato si è cominciato a definire il campo di riferimento reale, sviluppando due tipi di
analisi delle forniture ICT:
o
la prima, per identificare il più efficace livello di granularità atto a definire un insieme
il più possibile esaustivo di “forniture elementari”, desunte dall’esperienza e dalla
realtà del mercato attuale; ciò allo scopo di costruire un “dizionario delle forniture ICT”
con valenza operativa e di orientamento per il futuro;
o
la seconda per ottenere, in analogia con quanto sopra, il quadro delle strategie di
acquisizione delle forniture ICT per arrivare alla migliore prospettiva per l’appalto
pubblico delle medesime forniture.
Dall’altro, si è cercato di inquadrare la problematica della qualità senza partire da una pagina
bianca, ma facendo riferimento a capisaldi solidi ed affermati, nel contesto dell’esperienza
legata alle vicende delle Norme ISO e delle decennali attività industriali di sviluppo software.
Si è perciò integrata la moderna visione che privilegia la cultura del servizio nei confronti di
quella del prodotto, con il pur necessario recupero dei valori che al prodotto sono legati. Ciò ha
comportato la necessità di ripartire con la definizione delle caratteristiche di qualità secondo i
diversi punti di vista delle parti in gioco:
o
il fruitore (utente finale, sia che si tratti del cittadino utente dell’Amministrazione, sia
che si tratti dell’operatore, appartenente all’Amministrazione, che opera all’interno del
processo);
o
l’appaltatore ovvero la stazione appaltante;
o
la fornitura come portatrice della sua qualità intrinseca.
A questo proposito, in relazione alle varie proposte della letteratura in materia, il modello
preso a riferimento per descrivere il ciclo di vita di una fornitura ICT è quello indicato dalla
norma UNI CEI ISO/IEC 12207. Infatti, sebbene esso sia concepito per la descrizione di
processi legati allo sviluppo del software, nondimeno risulta facilmente generalizzabile alla
realizzazione di prodotti, servizi e sistemi in senso più ampio.
La norma, infatti, definisce un insieme di processi, attività e compiti progettati per essere
personalizzati rispetto ai diversi progetti software, permettendo l’eliminazione di processi,
attività o compiti non applicabili. La norma, inoltre, non prescrive l’adozione di una
particolare metodologia di sviluppo, né impone uno specifico ciclo di vita (a cascata, a spirale,
incrementale o iterativo), elementi questi che possono variare in funzione dei processi
produttivi e delle metodologie in uso presso ciascun Fornitore. Ciò che prescrive lo standard è
che, qualunque sia il ciclo di vita adottato, debbano essere comunque svolti, in modo
formalizzato e controllato, alcuni processi di base.
Infine si è innestato su quanto previsto dalla norma ISO/IEC 9126-1:2001 sulla qualità del
prodotto software il risultato dell’integrazione dei modelli di qualità sviluppati per i servizi
(Servqual).
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 8/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
4. PUNTI DI VISTA PER LA DEFINIZIONE DELLA QUALITÀ
L’ approccio adottato per la stesura delle Linee guida prevede di considerare diversi punti di
vista al fine di identificare misure di qualità da rappresentare contrattualmente. Detti punti
di vista sono quelli:
o
della qualità intrinseca del servizio, direttamente correlata a caratteristiche di qualità
del servizio e dei prodotti correlati;
o
del fruitore del servizio (utente finale), direttamente interessato alla cosiddetta qualità
attesa e percepita (qualità in uso);
o
della amministrazione appaltante il servizio (stazione appaltante), interessata ai
processi di sviluppo e di erogazione messi in atto dal fornitore.
I paragrafi seguenti esplorano queste diverse dimensioni di qualità che hanno tutte la
necessità di trovare rappresentazione all’interno dei contratti ICT.
4.1. QUALITÀ INTRINSECA DELLA FORNITURA
Per lo sviluppo della Società dell’Informazione si attribuisce grande rilievo alla
“digitalizzazione” delle Amministrazioni pubbliche ed in particolare alla diffusione delle
tecnologie dell’informazione e delle telecomunicazioni (ICT) come strumento per realizzare il
miglioramento della qualità dei servizi resi agli utenti ed accelerare il cambiamento
dell’azione amministrativa verso obiettivi di efficienza ed efficacia.
Lo sviluppo di soluzioni ICT di ausilio per un’Amministrazione, sia per svolgere proprie
funzioni istituzionali sia per erogare servizi on-line ai cittadini e alle imprese, è un’attività
complessa ed in continua evoluzione, che richiede professionalità e strutture specialistiche non
sempre presenti nell’ambito di organizzazioni il cui core business è basato sulla erogazione di
servizi di pubblica utilità; per tali motivi le Amministrazioni tendono sempre più ad acquisirle
rivolgendosi al mercato. L’affidamento avviene attraverso l’esperimento di procedure
concorsuali, svolte nel rispetto delle disposizioni normative nazionali e comunitarie, e la
successiva sottoscrizione di un contratto con il Fornitore selezionato. Il prodotto finale
dell’attività amministrativa, di cui i servizi erogati ai cittadini ed alle imprese costituiscono
parte rilevante, è direttamente influenzato dall’insieme dei processi attuati da tutte le entità
organizzative delle Pubbliche Amministrazioni Centrali (PAC) e Locali (PAL) coinvolte,
incluse le organizzazioni dei loro Fornitori. Ne deriva che l’aspetto del rapporto con i Fornitori
risulta determinante ed è importante stabilire nei contratti regole precise riguardo alle
forniture che si richiedono ed ai relativi requisiti di qualità.
La complessità, in tal senso, sta nel fatto che le forniture informatiche oggetto dei contratti
stipulati dalle Amministrazioni, si configurano in genere come acquisizione di servizi, che
vengono erogati da un Fornitore per un certo periodo di tempo e che non sono necessariamente
correlati alla produzione di beni materiali o immateriali, salvo ci siano beni rinvenienti
contrattualmente determinati.
D’altra parte, anche nel caso della più semplice transazione in cui si realizza la consegna di un
prodotto, esiste un rapporto comunicativo tra il Fornitore e l’Acquirente entro cui la
transazione stessa si sviluppa e si configura come un servizio.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 9/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Sebbene un servizio, a differenza di un prodotto materiale, non si qualifichi per delle proprietà
intrinseche e comporti delle logiche di acquisto diverse dalle logiche di acquisto di un prodotto,
un aspetto che accomuna prodotti e servizi è insito nel concetto stesso di qualità. Secondo le
norme ISO, la qualità può essere definita come … l’insieme delle proprietà e delle
caratteristiche di un prodotto/servizio che gli conferiscono l’attitudine a soddisfare esigenze o
aspettative espresse o usualmente implicite o obbligatorie del cliente e di altre parti
interessate.
Ai fini della definizione, in ambito contrattuale, dei requisiti di qualità di un prodotto/servizio
e delle relative modalità di verifica e controllo, è necessario pertanto identificare i clienti e le
altre parti interessate alla fornitura che, nell’ambito di una Amministrazione che stipuli un
contratto con un Fornitore, possono essere rappresentate dalle seguenti figure:
o
fruitore o utente finale: la persona o l’organizzazione che utilizzerà il prodotto/servizio
oggetto di fornitura contrattuale o beneficerà dei risultati (centro di costo);
o
appaltatore: la persona o l’organizzazione che richiede il prodotto/servizio, ad uso del
fruitore, attraverso la stipula di un contratto con un Fornitore.
Fanno capo alla figura dell’appaltatore, potendo consistere in una stessa entità organizzativa o
in entità distinte, le seguenti:
o
la persona o l’organizzazione che finanzia il progetto per l’acquisizione della fornitura
(centro di spesa);
o
la persona o l’organizzazione che è responsabile, dal lato dell’Amministrazione
acquirente, di realizzare il progetto (centro di responsabilità). E’ il principale
interlocutore del Fornitore, per quanto riguarda le modalità di sviluppo e gestione della
fornitura, secondo i requisiti espressi nel contratto.
Per quanto riguarda poi l’identificazione delle proprietà e delle caratteristiche di qualità,
prendendo spunto dal modello di qualità proposto dalla norma ISO/IEC 9126-1:2001,
presentato di seguito in questo stesso manuale successivo, è possibile caratterizzare un
prodotto/servizio per aspetti legati a:
o
Qualità interna:
prodotto/servizio;
determinata
dall’insieme
delle
caratteristiche
interne
del
o
Qualità esterna: determinata dall’insieme delle caratteristiche che si manifestano
all'esterno, quando il prodotto/servizio è usato come parte di un sistema; dette
caratteristiche sono un risultato delle caratteristiche interne del prodotto/servizio;
o
Qualità in uso: effetto combinato, per l'utente, delle caratteristiche di qualità interna
ed esterna del prodotto/servizio.
Lo schema seguente mostra le relazioni esistenti tra qualità interna, qualità esterna e qualità
in uso: la qualità del processo contribuisce a migliorare la qualità interna ed esterna del
prodotto/servizio e quest’ultima contribuisce a migliorare la qualità in uso; similarmente, la
valutazione della qualità in uso può fornire un feedback per il miglioramento del
prodotto/servizio, e la valutazione del prodotto/servizio può fornire un feedback per il
miglioramento del processo.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 10/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
processo
effetti del
prodotto/servizio
prodotto/servizio
influenza
qualità
del
processo
influenza
attributi
interni di
qualità
dipende da
misure di
processo
influenza
attributi
esterni di
qualità
dipende da
misure
interne
attributi
di qualità
in uso
dipende da
misure
esterne
Contesto d’uso
misure di
qualità in uso
Ai fini della pianificazione e del controllo delle misure di qualità di un prodotto/servizio
oggetto di fornitura contrattuale, le caratteristiche di qualità intrinseche del prodotto/servizio
(qualità interna) o legate all’utilizzo del prodotto/servizio come parte di un sistema (qualità
esterna) o in uno specifico contesto d’uso (qualità in uso), sono da esaminare con riferimento ai
seguenti diversi aspetti, legati allo sviluppo, alla erogazione ed alla valutazione da parte
dell’utente finale del prodotto/servizio:
o
Qualità attesa (o prevista): è determinata dalle esigenze esplicite, implicite,
obbligatorie o latenti, ovvero dalle attese del cliente;
o
Qualità progettata: è il livello di qualità definito nell’ambito del processo di sviluppo
della fornitura, sulla base delle caratteristiche di qualità attesa; regola il sistema
organizzativo, le modalità di realizzazione del prodotto/servizio e le condizioni operative
di funzionamento;
o
Qualità erogata (dimostrata): è il livello di qualità risultante dal processo di gestione
operativa, ovvero relativo al prodotto/servizio realizzato/erogato ed è oggettivamente
dimostrato. E’ l’aspetto di qualità per il quale vanno pianificate ed effettuate le misure
in ambito contrattuale, al fine di applicare penalità in caso di mancato rispetto dei
requisiti di qualità fissati. Le verifiche vanno commisurate alle effettive esigenze di
misura, visto che l’implementazione e la gestione di un sistema di misura è di per sé un
costo per l’Amministrazione e per il Fornitore.
o
Qualità percepita: è il livello di qualità che l’utente valuta, in base all’esperienza d’uso
e tramite il confronto tra le prestazioni erogate e le proprie attese. Essa è influenzata
non soltanto dall’esperienza recente sul prodotto/servizio, ma anche da altri fattori, tra
i quali le precedenti esperienze vissute, il paragone con prodotti/servizi analoghi,
nonché
l’immagine
complessiva
dell’organizzazione
che
realizza/eroga
il
prodotto/servizio. Lo scostamento della qualità percepita dalla qualità attesa,
determina il livello di soddisfazione dell’utente finale.
In particolare, data la complessità tecnica, per la fornitura di un servizio ICT è di norma
necessario che il committente predisponga un documento esterno al contratto, nel quale
definisce in dettaglio l’oggetto della prestazione che richiede. Questo documento, chiamato
“Service Level Agreement (SLA)”, descrive la prestazione richiesta, gli obblighi del Fornitore e
gli obblighi e i diritti del committente e può essere parte del Capitolato Tecnico o un suo
allegato.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 11/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Non esistono SLA standard, ma in sostanza devono essere precisate in dettaglio le condizioni
nelle quali ha validità l’accordo (ambientali, organizzative, tecniche, ecc.) e il livello delle
prestazioni attese (il livello di possesso atteso di determinate caratteristiche).
Comunque, a prescindere dalle metodologie e dai sistemi di misura che si possono adottare, ciò
che conta è che il processo di pianificazione e controllo delle caratteristiche di qualità dei
prodotti/servizi oggetto della esecuzione di un contratto, rilevi e renda coerenti le diverse
concezioni di qualità da parte dei clienti della fornitura, diversità derivanti dalle differenze
che necessariamente contraddistinguono il punto di vista di chi usufruisce del
prodotto/servizio dal punto di vista di chi appalta.
4.2. PUNTO DI VISTA DEL FRUITORE
Il termine fruitore si riferisce al soggetto che è l’utente o il beneficiario dei prodotti/servizi
oggetto di fornitura. In tal senso possono essere fruitori:
o
utenti finali esterni alle Amministrazioni, ovvero i cittadini o le imprese che possono
direttamente usufruire dei prodotti/servizi realizzati in esecuzione del contratto;
o
utenti finali interni ad una stessa Amministrazione o a più Amministrazioni, quali ad
es. dipendenti che utilizzano i prodotti/servizi per svolgere compiti istituzionali
dell’Amministrazione di appartenenza;
o
utenti interni o esterni ad una Amministrazione, appartenenti a Fornitori terzi, che
devono assicurare la gestione operativa e la manutenzione dei prodotti e servizi
realizzati in esecuzione del contratto.
Le diverse tipologie di utenti finali, tra le quali quelle sopra evidenziate, concorrono ad
identificare le caratteristiche di qualità che determinano il profilo di qualità attesa del
prodotto/servizio da parte del fruitore.
Ogni fruitore, infatti, prende in considerazione e valuta prevalentemente quelle caratteristiche
di qualità che risultano direttamente osservabili in relazione alle proprie esigenze. In tal
senso il livello di qualità attesa da parte di un fruitore che utilizzi il prodotto o servizio come
utente finale è necessariamente diverso dal fruitore che dovrà prendere in carico la
manutenzione o la gestione del prodotto. Con riferimento al modello proposto dalla norma
ISO/IEC 9126-1:2001, l’utente finale apprezzerà prevalentemente l’usabilità e la funzionalità
del prodotto; l’utente manutentore o gestore privilegerà anche la manutenibilità.
Tralasciando i casi in cui il fruitore sia l’utente manutentore o gestore, visto che generalmente
una Amministrazione affida al Fornitore tutte le attività relative al ciclo di vita della
fornitura, si può dire che:
o
l’usabilità, intesa come capacità del prodotto di essere capito, utilizzato e gradito;
o
la funzionalità, intesa come capacità del prodotto di soddisfare le esigenze dell’utente;
o
l’affidabilità, intesa sia come disponibilità in termini assoluti del prodotto o servizio, sia
come tolleranza ai guasti atta a garantire la disponibilità del prodotto;
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 12/117
CNIPA
o
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
l’efficienza temporale, come capacità di rispondere tempestivamente alla richieste o
tempo di risposta (a titolo di esempio, la reattività che un prodotto software deve
mostrare ad uno specifico comando impartito dall’utente; la rapidità di intervento di un
servizio di manutenzione attivato mediante call center da un utente);
siano le caratteristiche di qualità comunemente prese a riferimento per determinare il profilo
di qualità attesa di un prodotto da parte del fruitore.
Dal momento che spesso l’utente non è esperto di tecnologie informatiche, un aspetto rilevante
per il fruitore è la gradevolezza e la comprensibilità della interfaccia del prodotto che, proprio
perché spesso è l'unica parte del sistema con cui l'utente entra in contatto, deve essere userfriendly (amichevole per l’utente) e consentire un facile reperimento delle funzioni di interesse.
Nel caso di accesso al sistema da parte di disabili (es. di tipo motorio, visivo, uditivo), una
caratteristica rilevante è l’accessibilità, che prevede il rispetto di specifiche norme.
L'accessibilità è un prerequisito dell’usabilità e non la sostituisce.
Al di là delle caratteristiche di qualità di prodotti/servizi che siano maggiormente significative
dal punto di vista del fruitore e che possono essere rilevate dal modello proposto, è importante
evidenziare che ciò che è più facilmente misurabile e pertanto direttamente percepibile
dall’utenza non è tanto la qualità interna, risultato del processo di sviluppo, quanto la qualità
che attiene all’interazione dell’utente con le risorse e le attività dell’organizzazione preposte
alla erogazione del servizio, elementi che determinano la qualità percepita ed il livello di
soddisfazione dell’utente rispetto al prodotto/servizio realizzato/erogato.
La soddisfazione, misurata attraverso lo scostamento tra qualità percepita e qualità attesa, è
una reazione dell’utente influenzata dall’esperienza diretta sull’utilizzo del servizio (qualità in
uso), in cui le caratteristiche “oggettive” del prodotto/servizio (qualità erogata) sono valutate
alla luce delle aspettative, cioè delle prestazioni attese, ma sono anche influenzate dalla
comunicazione ricevuta, dal contesto esterno e da altri fattori che caratterizzano le modalità di
erogazione del servizio, quali l’accessibilità, gli strumenti utilizzati, le procedure applicate e,
non ultime, la competenza e la cultura “customer-oriented” (orientata al cliente) del personale
che interfaccia direttamente l’utente. Questo ultimo punto dimostra come la soddisfazione
dell’utente sia altresì collegata alla soddisfazione dei dipendenti, sulla quale incidono diversi
elementi, tra i quali il trattamento economico, le responsabilità ed il coinvolgimento
nell’ambito della organizzazione, la crescita professionale, l’ambiente di lavoro. E’ frequente,
infatti, rilevare che un dipendente scontento e demotivato molto difficilmente si dimostra
cortese ed efficiente verso il proprio interlocutore; per contro un dipendente soddisfatto è una
persona motivata, che è solito adottare un approccio proattivo verso l’interlocutore,
contribuendo a migliorarne la percezione sulla qualità del servizio reso.
Si può quindi concludere che ciò che è importante dal punto di vista del fruitore, è che lo
scostamento tra percezioni ed attese risulti minimo; tale risultato non implica peraltro che la
qualità interna e la qualità erogata siano meno importanti: si tratta infatti di dimensioni non
alternative, ma complementari ai fini del buon esito del servizio, al quale contribuisce in modo
determinante l’attenzione posta alle esigenze del fruitore in tulle le attività che caratterizzano
il ciclo di vita della fornitura.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 13/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
4.3. PUNTO DI VISTA DI CHI APPALTA
Il termine appaltatore è utilizzato in questo contesto per riferirsi al soggetto che rappresenta il
cliente diretto del Fornitore nell’ambito di un contratto stipulato da una Amministrazione per
l’acquisizione di un prodotto/servizio ICT e che, oltre a curare le procedure concorsuali per la
selezione del Fornitore, ha la responsabilità di gestire il contratto con il Fornitore
aggiudicatario per tutto il ciclo di vita della fornitura.
Nell’organizzazione di chi appalta sono quindi presenti, oltre a potenziali fruitori e beneficiari
del prodotto servizio oggetto di fornitura, le entità organizzative che hanno in capo la
responsabilità di finanziare e realizzare il progetto e per le quali è necessario perseguire
obiettivi di:
o
efficacia, intesa come grado di rispondenza dell’output agli obiettivi;
o
efficienza, intesa come rapporto input/output, ovvero come relazione tra prestazioni
ottenute e costi sostenuti.
Risulta quindi importante dal punto di vista di chi appalta, da un lato garantire che il
prodotto/servizio oggetto di fornitura risponda alle esigenze dell’Amministrazione, soddisfi le
necessità dei fruitori e sia realizzato/erogato nel rispetto dei requisiti contrattuali, garantendo
appropriate prestazioni rispetto alle risorse utilizzate; dall’altro assicurare che la soluzione
identificata ben si inserisca nel contesto informativo cui è destinata.
In tal senso, nel procedere all’acquisizione del prodotto/servizio, nel definire i
fornitura e nell’effettuare valutazioni in corso d’opera durante l’esecuzione
risultano importanti dal punto di vista dell’appaltatore quegli aspetti
razionalizzazione della modalità di acquisizione della fornitura, tra i quali si
titolo indicativo e non esaustivo:
requisiti della
del contratto,
connessi alla
evidenziano a
o
l’integrazione del prodotto/servizio oggetto di acquisizione nel sistema informatico preesistente e la salvaguardia degli investimenti già effettuati. Da tale punto di vista, con
riferimento alle caratteristiche di qualità indicate nel modello proposto, assumono
importanza caratteristiche quali la interoperabilità, intesa come capacità di interazione
del prodotto/servizio con uno o più sistemi, la conformità alla funzionalità, intesa come
grado di rispondenza a standard, convenzioni e norme di legge in materia e la
coesistenza, intesa come capacità di coesistere con un altro prodotto/servizio in un
ambiente specificato
o
le esigenze di addestramento/formazione del personale, connesse all’acquisizione delle
fornitura. Obiettivo dell’appaltatore è adottare soluzioni che non operino
sconvolgimenti nelle prassi di lavoro in uso presso l’Amministrazione e/o che siano
facilmente utilizzabili da parte degli utenti. Tale obiettivo è più facilmente perseguibile
se il prodotto/servizio presenta caratteristiche di usabilità ed in particolare di
comprensibilità, di apprendibilità e di operatività.
o
la possibilità che il prodotto/servizio sia in grado di operare in ambienti diversi. Detta
funzione è garantita dal livello di portabilità della soluzione, caratteristica che risulta
importante per l’appaltatore sia a fronte della necessità di garantire il costante
adeguamento tecnologico dell’ambiente in cui il prodotto/servizio opera, sia ai fini di
assicurare la possibilità di subentro di un nuovo Fornitore alla scadenza del contratto.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 14/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Gli aspetti sopra evidenziati contribuiscono a determinare il profilo di qualità attesa dal punto
di vista dell’appaltatore e influenzano le misure effettuate nel corso della esecuzione del
contratto.
In particolare dal punto di vista di chi appalta assume importanza prioritaria la valutazione
della qualità delle prestazioni erogate dal Fornitore nel corso della durata del contratto
secondo misure oggettive di caratteristiche di qualità (qualità erogata o dimostrata), che
consentono di evidenziare il grado di conformità delle prestazioni ottenute rispetto ai requisiti
contrattuali.
In tale ottica, oltre alle caratteristiche di qualità già evidenziate, possono essere di interesse
per l’appaltatore:
o
valutazioni relative alla funzionalità, volte in particolare a stabilire se la soluzione
realizzata è in grado di portare effettivamente a termine le operazioni per la cui
esecuzione è stata definita e progettata;
o
valutazioni derivanti da “prove di sforzo'', volte ad individuare i limiti del sistema che
realizza l’ambiente di esercizio del prodotto o di erogazione del servizio rispetto al
dimensionamento adottato ed i margini di ampliamento a fronte del variare dei
parametri di dimensionamento (per esempio numero di utenti serviti, quantità di dati,
tempi di esecuzione);
o
valutazioni relative all’efficienza, aventi l’obiettivo di verificare la capacità di fornire
prestazioni appropriate relativamente alla quantità di risorse utilizzate, in condizioni
stabilite;
o
valutazioni volte a verificare l’affidabilità, con particolare riferimento alla capacità di
ristabilire un livello di prestazioni specificato a fronte di malfunzionamenti;
o
valutazioni di adeguatezza, essenzialmente indirizzate alla verifica dell'appropriatezza
del prodotto/servizio per eseguire un particolare compito e a stabilire se e come esso è
in grado di soddisfare i requisiti per i quali è stato progettato. Includono valutazioni di
tipo riassuntivo, destinate a verificare se un sistema già esistente è conforme e soddisfa
le esigenze degli utenti cui è destinato e valutazioni di tipo formativo effettuate
all’inizio della progettazione di un sistema allo scopo di stabilire le linee guida per il
suo sviluppo futuro.
Risultano inoltre importanti misure atte a rilevare il livello di soddisfazione dei fruitori,
attraverso la valorizzazione dello scostamento tra qualità attesa e qualità percepita; dette
misure consentono all’appaltatore di individuare i driver (linee guida) per migliorare il
servizio erogato, apportando le opportune modifiche in corso d’opera al contratto, ovvero per
meglio dirigere in futuro le scelte relative all’acquisizione di nuovi prodotti e/o servizi.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 15/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
5. CICLO DI VITA DELLE FORNITURE
Sulla base delle definizioni proposte dalla normativa ISO, una fornitura informatica oggetto di
un contratto stipulato tra un’Amministrazione e un Fornitore è il risultato “tangibile”
(materiali; documenti; hardware) o “intangibile” (software; servizi; conoscenze) di un’attività o
di un insieme di attività correlate (processi); dette attività, nell’insieme, costituiscono il ciclo di
vita della fornitura.
Sebbene in un rapporto contrattuale tra Amministrazione e Fornitore, una fornitura abbia
inizio con le attività che seguono la sottoscrizione del contratto e termini alla scadenza del
contratto stesso, il ciclo di vita della fornitura copre l’intervallo temporale che va dalla nascita
dell’esigenza da parte dell’Amministrazione di procedere all’acquisizione di un prodotto o di un
servizio, alla dismissione del prodotto o alla cessazione del servizio oggetto di acquisizione,
attraverso le fasi intermedie di realizzazione, nelle quali si concentrano le attività che hanno
una più alta incidenza sulla qualità finale.
Le modalità di acquisizione e di realizzazione di una fornitura sono diverse a seconda delle
caratteristiche proprie di ogni tipologia e sono significativamente influenzate, tra l’altro, dalle
politiche organizzative e dalle procedure, strategie e metodologie di acquisto in uso presso
ciascuna Amministrazione. Nel presente paragrafo si intende presentare un metodo per
definire e verificare in corso d’opera una fornitura informatica, al fine di consentire alle
Amministrazioni di acquisire prodotti e/o servizi che siano effettivamente rispondenti alle
esigenze espresse ed implicite degli utenti e che ben si integrino nel contesto informativo cui
sono destinati.
Il metodo proposto prende in esame l’intero ciclo di vita di una fornitura; fare riferimento ad
un ciclo di vita, significa prevedere un’organizzazione sistematica delle attività da svolgere
secondo processi opportunamente coordinati tra loro, scanditi dalla emissione di prodotti su
cui si esercitano operazioni di riesame, verifica e validazione in corso d’opera. In tal modo:
o
si definiscono delle regole di comportamento e dei momenti formali di controllo, sia per
il Fornitore sia per l’Amministrazione, che consentono di evitare manifestazioni di
criticità non desiderate di tempi, di costi e di qualità o che comunque ne riducono
significativamente la probabilità di occorrenza;
o
si costruisce una “traccia logica” della storia della realizzazione e del controllo, che dà
evidenza delle operazioni effettuate e delle decisioni prese e che garantisce efficacia
nella copertura rispetto alle criticità non volute e capacità di recupero al loro eventuale
insorgere;
o
si garantisce il raggiungimento degli obiettivi fissati e la coerenza tra gli stessi obiettivi
ed il risultato finale, ovvero si riduce significativamente il rischio che il risultato finale
sia non conforme agli obiettivi iniziali.
In relazione alle varie proposte della letteratura in materia, il modello che si prende a
riferimento per descrivere il ciclo di vita di una fornitura informatica è direttamente derivato
da quello indicato dalla norma UNI CEI ISO/IEC 12207. Modello che, sebbene sia concepito
per la descrizione di processi legati allo sviluppo del software, risulta facilmente
generalizzabile alla realizzazione di prodotti, servizi e sistemi in senso più ampio. La norma,
infatti, definisce un insieme di processi, attività e compiti progettati per essere personalizzati
rispetto ai diversi progetti software, permettendo l’eliminazione di processi, attività o compiti
non applicabili.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 16/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
La norma, inoltre, non prescrive l’adozione di una particolare metodologia di sviluppo, né
impone uno specifico ciclo di vita (a cascata, a spirale, incrementale o iterativo), elementi
questi che possono variare in funzione dei processi produttivi e delle metodologie in uso presso
ciascun Fornitore. Ciò che prescrive lo standard è che, qualunque sia il ciclo di vita adottato,
debbano essere comunque svolti, in modo formalizzato e controllato, alcuni processi di base.
In questo contesto il modello è preso a riferimento in via indicativa, con le opportune
generalizzazioni e/o integrazioni, allo scopo di consentire l’individuazione in modo sistematico
e, per quanto possibile, esaustivo di tutte le caratteristiche di qualità di attività e prodotti,
intermedi e/o finali, che costituiscono il risultato dei processi attuati da un Fornitore in
esecuzione di un contratto stipulato con un’Amministrazione. In particolare, seguendo le
indicazioni della norma, i processi del ciclo di vita di una fornitura sono scomposti in attività e
per ciascuna attività sono identificati i relativi prodotti (documenti, software, soluzioni). La
scomposizione si arresta ad un livello di dettaglio che consenta di individuare attività e
prodotti che possono essere oggetto di verifica, validazione e, nei casi applicabili di
accettazione da parte dell’Amministrazione nel corso della esecuzione di un contratto. Attività
e prodotti sono indicati non con lo scopo di stabilire nome, formato e contenuto espliciti,
quanto con lo scopo di evidenziare i “deliverables tipo” di un contratto sui quali
l’Amministrazione può esercitare gli opportuni controlli per verificare in itinere il rispetto di
tempi, costi e qualità. Una volta individuati attività e prodotti “tipo” di ogni processo del ciclo
di vita, è possibile definire, rispettivamente per le attività e per i prodotti, le caratteristiche di
qualità che si ritengono maggiormente significative in funzione della tipologia di ciascuna
classe di fornitura e degli obiettivi di qualità attesa sul risultato finale.
La norma ISO/IEC 12207 definisce tre tipologie di processi, classificati in:
o
Processi primari. I processi primari sono i processi core business, orientati alla
generazione di prodotti e di servizi verso l’utente finale. Sono sviluppati nell’ambito di
ogni singolo progetto finalizzato alla realizzazione di una fornitura e riguardano sia
l’Amministrazione che il Fornitore.
o
Processi di supporto. I processi di supporto, ad uso interno all’organizzazione che eroga
il servizio, sono utilizzati e svolti come parte integrante di altri processi e
contribuiscono ad assicurare il successo e la qualità del progetto nel suo complesso.
o
Processi organizzativi. I processi organizzativi, di tipo manageriale, sono di solito
sviluppati fuori dell’ambito di specifici progetti. Riguardano la pianificazione e il
controllo del progetto, nonché la gestione delle risorse umane e materiali necessarie per
la conduzione delle attività contrattuali.
I processi primari sono i processi produttivi veri e propri ed includono, oltre ai processi che
regolano l’acquisizione della commessa (Acquisizione) e la gestione dei rapporti con il cliente
(Fornitura), il processo di Sviluppo, articolato nelle fasi di progettazione e realizzazione, il
processo di Gestione operativa, del quale è parte integrante l’assistenza agli utenti ed infine il
processo di Manutenzione, che include le attività relative alla migrazione e alla dismissione
del prodotto o alla cessazione del servizio.
I processi di supporto sono indipendenti dal processo primario cui si riferiscono e sono svolti in
più momenti; includono la Gestione della documentazione, la Gestione della configurazione, il
processo di Assicurazione Qualità, unitamente ai processi di Verifica, Validazione, Riesame
Congiunto con il Committente, Verifiche Ispettive ed infine il processo di Risoluzione dei
problemi (anomalie o non-confomità).
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 17/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
I processi organizzativi sono trasversali ai processi primari e ai processi di supporto ed
includono l’insieme delle attività necessarie per realizzare con successo il progetto e che
riguardano in particolare il processo di Gestione del progetto, di Gestione delle infrastrutture,
di Formazione e di Miglioramento.
I 17 processi sopra indicati, definiti dalla norma, sono composti da “attività” (insieme di azioni
coerenti), a loro volta ulteriormente scomponibili in “compiti” (o azioni di base). Attività e
compiti generano prodotti (documenti, software, servizi, soluzioni). Nella figura che segue si
riporta lo schema dei processi proposti dalla norma.
UNI CEI ISO/IEC 12207
PROCESSI PRIMARI
PROCESSI DI SUPPORTO
Processo di Documentazione
Processo di Acquisizione
Processo di Gestione della
Configurazione
Processo di Fornitura
Processo di Assicurazione Qualità
Processo di Verifica
Processo di
Gestione
operativa
Processo di
Sviluppo
Processo di Validazione
- Progettazione
- Realizzazione
Processo del Riesame Congiunto
Processo di Verifica Ispettiva
Processo di
Manutenzione
Processo di Risoluzione dei problemi
PROCESSI ORGANIZZATIVI
Processo di gestione
Processo di Infrastruttura
Processo di miglioramento
Processo di Formazione
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 18/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Esula dagli scopi del presente lavoro descrivere in dettaglio lo standard proposto dalla norma,
alla quale si rimanda per ogni esigenza di ulteriore approfondimento.
Ai fini delle Linee guida e della descrizione delle forniture ICT si è scelto di semplificare il
ciclo di vita proposto dalla norma UNI/CEI ISO/IEC 12207 riducendo il numero di processi da
17 a 9.
In particolare si sono raggruppati all’interno di un unico processo, denominato processo di
Assicurazione Qualità, molti dei processi di supporto (quelli circondati da un contorno a pallini
nella precedente figura raffigurante il ciclo di vita della ISO/IEC 12207): Assicurazione
Qualità, Verifica, Validazione, Riesame Congiunto con il Committente, Verifiche Ispettive e
Risoluzione dei problemi (anomalie o non-conformità). Analogamente si sono raggruppati
all’interno di un unico processo, denominato processo di Gestione, tutti i processi organizzativi
(circondati da un contorno a pallini nella precedente figura raffigurante il ciclo di vita della
ISO/IEC 12207): Gestione del progetto, Gestione delle infrastrutture, Formazione e di
Miglioramento. In aggiunta si è lasciata cadere la distinzione tra processi di supporto e
processi organizzativi raggruppandoli insieme sotto la dizione di processi trasversali (alle
singole forniture ICT).
Lo schema che ne risulta è rappresentato dalla seguente figura.
Ciclo di vita adottato per le Forniture ICT
PROCESSI PRIMARI
PROCESSI TRASVERSALI
Processo di Acquisizione
Processo di Gestione
Processo di Fornitura
Processo di Documentazione
Processo di
Gestione
operativa
Processo di
Sviluppo
Processo di Gestione della
Configurazione
- Progettazione
- Realizzazione
Processo di
Manutenzione
Processo di Assicurazione Qualità
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 19/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Riassumendo il Ciclo di vota adottato per le forniture ICT nelle presenti Linee guida definisce
due tipologie di processi, classificati in:
o
Processi primari. I processi primari sono i processi core business, orientati alla
generazione di prodotti e di servizi verso l’utente finale. Sono sviluppati nell’ambito di
ogni singolo progetto finalizzato alla realizzazione di una fornitura e riguardano sia
l’Amministrazione che il Fornitore.
o
Processi trasversali. I processi trasversali, ad uso interno all’organizzazione impegnata
nella fornitura, sono utilizzati e svolti come parte integrante di altri processi e
contribuiscono ad assicurare il successo e la qualità del progetto nel suo complesso
riguardando la pianificazione e il controllo del progetto, nonché la gestione delle risorse
umane e materiali necessarie per la conduzione delle attività contrattuali.
Nel prosieguo, i processi individuati nel modello di ciclo di vita adottato sono descritti con le
opportune personalizzazioni e generalizzazioni rispetto alla norma ISO/IEC 12207, con
l’obiettivo di individuare attività e prodotti che possano essere presi a riferimento per
descrivere le classi di forniture ICT e le relative misure di qualità.
Il nome attribuito a ciascuna attività e a ciascun prodotto è puramente indicativo del
contenuto e non esclude la possibilità che l’attività o il prodotto si articolino rispettivamente in
più attività o più prodotti.
La descrizione dei processi e la scomposizione di ciascun processo in attività e prodotti, non
implica che per ciascuna classe di fornitura debbano essere ugualmente considerati, ai fini
delle misure di qualità, tutti i processi, con le attività ed i prodotti indicati.
L’identificazione delle attività e dei prodotti di ciascun processo da prendere in considerazione
nella descrizione di una classe di fornitura e le relative caratteristiche di qualità, sono
funzione della tipologia e della specificità di ciascuna classe, ivi inclusi dimensioni, criticità e
rischi.
5.1. PROCESSI PRIMARI
I processi primari sono i processi produttivi veri e propri ed includono, oltre ai processi che
regolano l’acquisizione della commessa (Acquisizione) e la gestione dei rapporti con il cliente
(Fornitura), il processo di Sviluppo, articolato nelle fasi di progettazione e realizzazione, il
processo di Gestione operativa, del quale è parte integrante l’assistenza agli utenti ed infine il
processo di Manutenzione, che include le attività relative alla migrazione e alla dismissione
del prodotto o alla cessazione del servizio.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 20/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
5.1.1. PROCESSO DI ACQUISIZIONE
Obiettivi
Il processo riguarda le attività che deve svolgere l’Amministrazione per acquisire un prodotto
o un servizio ed ha l’obiettivo di definire le caratteristiche della fornitura richiesta, in termini
di contenuti, tempi e modalità di esecuzione, requisiti di qualità.
Attivazione del processo
Il processo è attivato dall’Amministrazione quando nasce l’esigenza di acquisire un prodotto o
un servizio per conseguire determinati obiettivi. Detti obiettivi possono scaturire, per esempio,
in fase di pianificazione strategica pluriennale e/o di analisi dei processi interni, dalla
necessità di adempiere a disposizioni normative, dall’esigenza di migliorare e/o di offrire
servizi all’utenza, dalla necessità di migliorare la produttività interna o l’interoperabilità e la
cooperazione con altre Amministrazioni.
Attività e prodotti
Nello schema che segue si fornisce una rappresentazione delle attività proprie del processo di
Acquisizione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si
fornisce a seguire una descrizione delle finalità e dei contenuti.
Processo di Acquisizione
Attività
Prodotti
AC-A1
Definizione delle esigenze
AC-A2
Preparazione della richiesta d’offerta
AC-A3
Monitoraggio del Fornitore
ACA1-O1
Studio di fattibilità
ACA2-O1
Documenti di gara (Bando di gara;
Schema di contratto; Capitolato Tecnico;
Schema di offerta tecnico-economica)
ACA3-O1
Registrazioni
Definizione delle esigenze. Include l’insieme delle attività svolte dall’Amministrazione
preliminarmente alla indizione della gara per selezionare un Fornitore al quale affidare la
realizzazione del prodotto. Dette attività riguardano in particolare:
o
la formulazione dei fabbisogni di informatizzazione, sulla base dell’analisi dei processi
interni e degli obiettivi da perseguire;
o
l’identificazione della soluzione e la valutazione della fattibilità, dal punto di vista
tecnico, dei costi connessi alla realizzazione, dei benefici attesi, dei rischi e dei vincoli
tecnologici, temporali e normativi;
o
l’analisi del “make or buy”, intesa come valutazione dell’opportunità di esternalizzare,
in tutto o in parte la realizzazione del progetto e la definizione delle modalità di
selezione del Fornitore.
Il risultato di tale attività è un documento, Studio di fattibilità, che può essere redatto secondo
le “Linee guida per la realizzazione degli studi di fattibilità” emesse dall’AIPA (oggi CNIPA).
Preparazione della richiesta di offerta. A completamento della definizione delle esigenze,
quando l’Amministrazione abbia ritenuto opportuno e conveniente procedere all’acquisizione
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 21/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
della fornitura ed abbia definito sia il contesto della fornitura, sia le modalità di selezione del
Fornitore, l’Amministrazione avvia la redazione dei documenti necessari per espletare la
procedura di gara.
Detti documenti, che descrivono in termini quantitativi e qualitativi l’oggetto della fornitura, i
requisiti e le relative modalità di esecuzione, vanno redatti secondo le disposizioni normative,
nazionali e comunitarie, di riferimento per la tipologia di gara che si deve espletare (pubblico
incanto; licitazione privata; appalto concorso; trattativa privata) e in relazione alle norme che
regolano le procedure di acquisto presso ciascuna Amministrazione. In linea di massima, i
documenti da predisporre sono il Bando di gara, la lettera d’invito a presentare l’offerta, lo
schema di contratto, il capitolato tecnico, lo schema di offerta tecnico-economica che dovrà
essere presentata da ciascun partecipante alla gara, la documentazione per la richiesta del
parere di congruità tecnico-economico di cui all’art. 8 del decreto legislativo 12 febbraio 1993,
n. 39.
Una volta che sia stata espletata la gara, i documenti di gara predisposti
dall’Amministrazione nell’ambito della presente attività e l’offerta tecnico-economica
presentata dal Fornitore aggiudicatario, nell’ambito del processo di Fornitura, debitamente
rivisti per riflettere eventuali modifiche emerse nel corso del procedimento di gara e
sottoscritti dalle parti contraenti, costituiscono la baseline di contratto e regolano l’esecuzione
della fornitura per tutto il ciclo di vita, salvo le modifiche che dovranno essere apportate nel
corso dell’esecuzione degli altri processi.
Monitoraggio del fornitore. A seguito della sottoscrizione del contratto con il Fornitore
aggiudicatario l’Amministrazione, sia in conformità a quanto previsto all’articolo 13, comma 2,
del decreto legislativo 12 febbraio 1993, n. 39, sia al fine di assicurare che la fornitura sia
realizzata nel rispetto dei requisiti di tempi, costi e qualità indicati nei documenti
contrattuali, ha il compito di eseguire il monitoraggio delle prestazioni rese dal Fornitore per
tutta la durata del contratto.
L’attività è effettuata con riferimento alle disposizioni normative vigenti in materia, tra le
quali la Circolare del 28 dicembre 2001, n. AIPA/CR/38, alla quale si può far riferimento per
rilevare le principali attività ed i relativi prodotti.
Accettazione e completamento. L’accettazione della fornitura da parte dell’Amministrazione è
effettuata attraverso il collaudo, attività descritta nell’ambito del processo di Realizzazione.
Successivamente al collaudo con esito positivo della fornitura, l’Amministrazione deve farsi
carico della gestione operativa e della manutenzione, nei casi in cui dette attività non siano
per contratto a carico del Fornitore.
Il completamento può coincidere con la scadenza del contratto, cui può seguire il subentro di
un nuovo Fornitore, ovvero con la dismissione del prodotto o la cessazione del servizio oggetto
di fornitura. Dette attività sono descritte nell’ambito del processo di Manutenzione.
Chiusura del processo
Il processo si conclude con l’accettazione della fornitura e quando risultino completate tutte le
attività a carico del Fornitore in esecuzione del contratto.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 22/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
5.1.2. PROCESSO DI FORNITURA
Obiettivi
Il processo riguarda le attività che deve svolgere il Fornitore, a partire dalla predisposizione
dell’offerta tecnico-economica in risposta ad una richiesta di proposta da parte di
un’Amministrazione, sino alla realizzazione ed alla consegna della fornitura, in caso di
aggiudicazione della commessa.
Attivazione del processo
Il processo è attivato dal Fornitore a fronte della decisione di predisporre un’offerta per
rispondere alla richiesta di presentazione di una proposta da parte di un’Amministrazione. Il
processo prosegue quindi con la sottoscrizione del contratto con l’Amministrazione, in caso di
aggiudicazione della commessa, con la determinazione delle procedure e delle risorse
necessarie a gestire ed assicurare la corretta esecuzione della fornitura e con lo svolgimento di
tutte le attività previste nell’ambito del contratto.
Attività e prodotti
Nello schema che segue si fornisce una rappresentazione delle attività del processo di
Fornitura che riguardano la fase precedente la sottoscrizione del contratto. Le attività che il
Fornitore deve svolgere a valle della sottoscrizione del contratto, ricadono nell’ambito degli
altri processi primari, organizzativi e di supporto del ciclo di vita della fornitura, descritti nei
relativi paragrafi a seguire.
Per le attività ed i prodotti presentati nello schema che segue, si fornisce una descrizione delle
finalità e dei contenuti.
PROCESSO DI FORNITURA
ATTIVITÀ
PRODOTTI
FO-A1
Preparazione della risposta
FOA1-O1
Offerta tecnico-economica
FO-A2
Riesame e sottoscrizione del
contratto
FOA2-O1
Baseline di contratto (Contratto;
Capitolato; Offerta tecnico-economica)
Preparazione della risposta. In risposta alla richiesta di una proposta da parte di
un’Amministrazione (bando di gara, lettera d’invito, ecc.), il Fornitore predispone un’offerta in
cui definisce modalità, tempi e costi per realizzare la fornitura, nel rispetto dei requisiti
specificati dall’Amministrazione nei documenti di gara (capitolato tecnico, schema di
contratto, ecc.).
Il risultato dell’attività è l’offerta tecnico-economica che è vincolante per il Fornitore e, in caso
di aggiudicazione della commessa, diviene parte integrante della baseline di contratto.
Riesame e sottoscrizione del contratto. In caso di aggiudicazione della commessa, il Fornitore
deve negoziare e sottoscrivere il contratto con l’Amministrazione.
E’ parte integrante dell’attività un riesame del contratto da sottoscrivere, al fine di assicurare
che i requisiti siano adeguatamente definiti e documentati, che eventuali scostamenti tra i
requisiti riportati nel contratto e quelli riportati nell’offerta siano risolti e che esistano le
capacità per soddisfare i requisiti indicati.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 23/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Il risultato dell’attività, a valle della sottoscrizione del contratto tra le parti e dell’accettazione
di tutte le clausole contenute nel contratto stesso e nei suoi allegati, è la baseline di contratto,
intesa come insieme dei documenti contrattuali (Contratto, Capitolato Tecnico, Offerta
tecnico-economica) prodotti nell’ambito dei processi di Acquisizione e Fornitura, che regolano
l’esecuzione della fornitura durante il ciclo di vita.
Chiusura del processo
Il processo di Fornitura si conclude con il completamento da parte del Fornitore di tutte le
attività previste in esecuzione del contratto.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 24/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
5.1.3. PROCESSO DI PROGETTAZIONE
Obiettivi
Obiettivo della Progettazione è specificare le caratteristiche della fornitura a partire dai
requisiti indicati negli atti contrattuali, definendo le modalità di realizzazione, di verifica e
collaudo, di gestione operativa e manutenzione della fornitura, anche con riferimento ai mezzi
ed alle risorse umane e materiali necessarie per svolgere tutte le attività proprie dei processi
prima indicati.
Il processo è gestito a livello di progetto secondo il processo di Gestione; le infrastrutture e le
esigenze di formazione del personale preposto alla conduzione delle attività, sono definite e
gestite rispettivamente secondo il processo di Infrastrutture ed il processo di Formazione.
Attivazione del processo
Il processo è svolto dal Fornitore ed è attivato a valle della sottoscrizione del contratto. Sono
dati di input del processo l’insieme dei documenti che costituiscono la Baseline di contratto
prodotti nell’ambito dei processi di Acquisizione e di Fornitura, ovvero il Contratto, il
Capitolato tecnico, l’Offerta tecnico-economica del Fornitore.
Attività e prodotti
Nello schema che segue si fornisce una rappresentazione delle attività proprie del processo di
Progettazione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si
fornisce a seguire una descrizione delle finalità e dei contenuti.
Processo di progettazione
Attività
Prodotti
PR-A1
Analisi dei requisiti
PR-A2
Progettazione tecnica
PR-A3
PR-A4
Progettazione applicativa
Progettazione Test e Collaudi
PRA1-O1
Specifica dei requisiti
PRA2-O1
Architettura tecnica
PRA2-O2
Specifiche dei servizi
PRA3-O1
Specifiche funzionali
PRA3-O2
Disegno della Base Dati
PRA3-O3
Prototipo
PRA4-O2
Specifiche di collaudo
Analisi dei Requisiti. A partire dai requisiti della Fornitura indicati nei documenti
contrattuali, il Fornitore definisce tutti i requisiti, espliciti, impliciti ed obbligatori, che
regoleranno la fornitura nel corso della esecuzione del contratto. In tale attività è necessario
preliminarmente identificare con precisione tutti gli attori interessati alla fornitura, i
destinatari diretti e gli utenti finali e confermare/rivedere le rispettive necessità relative ad
obiettivi e requisiti della fornitura.
Sulla base delle necessità degli utenti, delle relative priorità e delle caratteristiche specifiche
di ogni tipologia di fornitura, devono essere definiti e documentati i requisiti organizzativi e
legati a profili utenti e casi d’uso, i requisiti di sicurezza e di riservatezza, i requisiti di
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 25/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
ingegneria dei fattori umani (ergonomia), i requisiti del sistema, del prodotto software e/o del
servizio, con riferimento al profilo di qualità previsto nel Piano di qualità ed alle
caratteristiche di funzionalità, usabilità, manutenibilità, prestazioni, ..; i requisiti di
progettazione, realizzazione, gestione operativa e di manutenzione, i requisiti di
qualificazione, i vincoli normativi e/o di aderenza a standard, i vincoli tecnologici, i vincoli
ambientali e/o legati al riuso di componenti, le esigenze di addestramento degli utenti.
Nella specificazione dei requisiti, deve essere assicurata la rintracciabilità delle necessità
dell’Amministrazione, la coerenza con le necessità stesse, la fattibilità della progettazione,
della gestione operativa e della manutenzione.
Il risultato dell’attività è costituito dalla Specifica dei requisiti, ovvero da un documento o
insieme di documenti, nei quali sono descritti tutti i requisiti della fornitura, identificati e
classificati, nel senso sopra indicato, secondo criteri documentati.
Progettazione Tecnica. Sulla base dei requisiti indicati nella Specifica dei requisiti, il
Fornitore definisce l’architettura tecnica del sistema. L’architettura tecnica individua le
componenti hardware, software ed infrastrutturali del sistema, le relative configurazioni e le
operazioni manuali. Il Fornitore definisce il servizio da fornire e le relative modalità di
realizzazione, di erogazione e di controllo delle caratteristiche di qualità.
Per la soluzione progettuale devono essere garantite la rintracciabilità dei requisiti, la
coerenza con i requisiti stessi, l’adeguatezza delle norme di progetto e dei metodi utilizzati, la
fattibilità della realizzazione, della gestione operativa e della manutenzione. Il risultato
dell’attività può essere costituito dalle seguenti tipologie di prodotti:
o
Architettura tecnica, documento o insieme di documenti, nei quali è descritta la
soluzione progettuale, ovvero l’architettura hardware e software del sistema che
realizza gli ambienti logici di sviluppo, collaudo ed esercizio, secondo le indicazioni
prima riportate;
o
Specifiche del servizio, documento o insieme di documenti nei quali, con riferimento
alle prescrizioni della norma UNI EN 29004-2:1994 "Elementi di gestione per la qualità
e del sistema qualità. Guida per i servizi", è descritto il servizio con le relative
caratteristiche (Specifiche del servizio), i mezzi e le modalità per realizzare ed erogare
il servizio (Specifiche di realizzazione del servizio) e per controllare i livelli di qualità
(Specifiche di controllo qualità).
Progettazione Applicativa. L’attività è eseguita dal Fornitore nel caso in cui la fornitura
richieda la realizzazione di soluzioni software. Con riferimento ai requisiti del prodotto
software da sviluppare e/o del servizio da erogare, indicati nella Specifica dei requisiti, il
Fornitore definisce l’architettura del prodotto e gli elementi software, dettagliando per ciascun
elemento, le componenti ad alto livello e le relative unità software (moduli applicativi) che
devono essere codificate e sottoposte a prova. Il Fornitore definisce altresì le interfacce (tra
unità software, tra componenti, tra prodotto ed utente), il disegno concettuale, logico e fisico
della Base Dati, la documentazione utente (manuali, help, tutorial, wizard, ..), il diagramma
delle classi e delle interazioni nel caso di soluzioni Object Oriented e quanto specifico in
funzione della tecnologia di sviluppo da adottare.
Nella soluzione progettuale deve essere garantita la rintracciabilità dei requisiti e la coerenza
esterna con i requisiti, la coerenza interna tra i componenti e le unità software, la fattibilità
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 26/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
della realizzazione, della gestione operativa e della manutenzione. Il risultato dell’attività può
essere costituito dalle seguenti tipologie di prodotti:
o
Specifiche funzionali – Documento o insieme di documenti nei quali è indicata
l’architettura e le componenti software, il dettaglio dei moduli applicativi, il disegno
delle interfacce e della documentazione utente. Il documento contiene la
rappresentazione dei processi e del flusso di dati che tali processi utilizzano e
trasformano, le interazioni tra il prodotto da realizzare ed il sistema.
o
Disegno della Base Dati – Documento o insieme dei documenti nei quali è descritto il
modello concettuale e logico dei dati.
o
Prototipo - Modello che contiene tutte le caratteristiche tecniche (funzionali,
prestazionali, di usabilità, ecc.) di un prodotto.
Progettazione Test e Collaudi. E’ parte integrante del processo di progettazione, la definizione
dei test interni (test unitari, test funzionali, test di prodotto, test di integrazione, test di
sistema e test di qualificazione finale) che dovranno essere eseguiti dal Fornitore prima del
rilascio al collaudo, per garantire che quanto realizzato sia conforme ai requisiti indicati nella
Specifica dei Requisiti e agli obiettivi fissati nel Piano di qualità. Tutti i test interni dovranno
essere descritti nel Piano di test, ovvero in un documento o in un insieme di documenti nel
quale, oltre ai casi di test, sono descritti l’ambiente e le risorse necessarie per l’esecuzione dei
casi di test e le modalità di gestione delle anomalie, in coerenza con il processo di Risoluzione
dei problemi. Il documento in genere non è un deliverable contrattuale; tuttavia, in fase di
esecuzione del collaudo della fornitura, la Commissione di collaudo incaricata
dall’Amministrazione può prendere visione del Piano dei test e dei relativi risultati (Test Data
Report).
Nel corso di tale attività il Fornitore deve specificare le operazioni di verifica che potranno
essere effettuate dall’Amministrazione per eseguire il collaudo della fornitura. Nella
descrizione delle prove di collaudo deve essere garantita la rintracciabilità dei requisiti
indicati nei documenti contrattuali e nella Specifica dei Requisiti e la coerenza con i requisiti
stessi. Il risultato dell’attività è costituito dalle Specifiche di collaudo, ovvero da un documento
o insieme di documenti che potranno essere utilizzati a titolo di guida dalla Commissione di
collaudo nominata dall’Amministrazione acquirente per eseguire il collaudo della fornitura. Il
documento definisce le prove di collaudo in coerenza con i requisiti indicati nei documenti
contrattuali e meglio dettagliati nella Specifica dei requisiti; definisce le specifiche
dell’ambiente di collaudo, che dovrà riprodurre fedelmente l’ambiente di esercizio, e le figure
professionali che saranno dal Fornitore per assistere la Commissione nella esecuzione delle
operazioni di collaudo.
Chiusura del processo
La progettazione deve essere sottoposta a Verifica, allo scopo di assicurare la correttezza e la
coerenza rispetto ai requisiti in ingresso.
Il processo si conclude di norma con un riesame della progettazione, ovvero con un’analisi
formale della capacità di quanto progettato di soddisfare i requisiti, espliciti, impliciti ed
obbligatori, indicati nei documenti del contrattuali e/o espressi dall’Amministrazione. La
funzione è a carico del Fornitore ed è svolta in collaborazione formalizzata con il Committente,
nell’ambito del processo di Riesame congiunto.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 27/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Il riesame si completa con la Validazione da parte del Fornitore e l’approvazione formale dei
prodotti del processo da parte dell’Amministrazione, approvazione che definisce la baseline di
progettazione.
Il processo di Progettazione produce alla fine i seguenti risultati:
o
conferma/specifica dei requisiti utente;
o
Baseline di progettazione, intesa come insieme dei documenti che descrivono la
soluzione progettuale e che regolano le modalità di realizzazione, di gestione operativa
e di manutenzione della fornitura;
o
aggiornamento dei prodotti del processo di Gestione, (Piano di progetto, Piano di
qualità, ..).
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 28/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
5.1.4. PROCESSO DI REALIZZAZIONE E COLLAUDO
Obiettivi
Obiettivo della Realizzazione è l’implementazione della soluzione progettuale, in termini di
infrastruttura tecnologica, codice, basi di dati, documentazione utente, servizi; seguono
l’esecuzione dei test ed il collaudo di quanto realizzato, secondo le specifiche prodotte nel
processo di Progettazione. I processi e le attività da svolgere sono regolati dai processi
organizzativi e supportati dai processi di supporto.
Attivazione del processo
Il processo è svolto dal Fornitore ed è attivato a chiusura del processo di Progettazione. Sono
dati di input del processo la Specifica dei requisiti e l’insieme dei documenti che costituiscono
la baseline di progettazione, prodotti nell’ambito del processo di Progettazione.
Attività e prodotti
Nello schema che segue si fornisce una rappresentazione delle attività proprie del processo di
Realizzazione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si
fornisce a seguire una descrizione delle finalità e dei contenuti.
Processo di Realizzazione e collaudo
Attività
Prodotti
RE-A1
Codifica
REA1-O1
Prodotto software
RE-A2
Predisposizione del sistema
REA1-O2
Infrastruttura di collaudo e di esercizio
RE-A3-
Produzione della documentazione
REA1_O3
Documentazione utente
RE-A4
Qualificazione finale
REA4-O1
Certificazione di rilascio al collaudo
RE-A5
Installazione
REA5-O1
Piano di installazione
REA6-O1
Verbale di collaudo
REA6- O2
Fornitura (prodotto software - sistema documentazione utente) in esercizio
nella configurazione di base
RE-A6
Collaudo
Codifica. In accordo con i documenti di output del processo di Progettazione, il Fornitore avvia
la realizzazione di quanto richiesto contrattualmente; in particolare, in caso di fornitura di
servizi che prevedano lo sviluppo di soluzioni applicative, il Fornitore, sulla base delle
Specifiche funzionali, realizza il prodotto, procedendo alla codifica del software, sviluppando e
documentando moduli, componenti e banche dati, ovvero provvedendo alla modifica del
software nel caso in cui non si tratti di un nuovo sviluppo.
A completamento dei test unitari sui singoli moduli il Fornitore, per ciascun elemento
software definito nel processo di Progettazione, procede alla integrazione delle unità software
e dei componenti, eseguendo quindi i test funzionali per verificare che nell’insieme gli
aggregati soddisfino i requisiti dell’elemento software. Segue quindi l’integrazione degli
elementi software e l’esecuzione del test di prodotto, volto a verificare che il software
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 29/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
realizzato, con relativi dati e documentazione, soddisfi i requisiti specificati nel processo di
Progettazione. E’ parte integrante dell’attività la produzione di procedure operative che
regolamentino sia le modalità di gestione operativa che le modalità di manutenzione.
Il risultato dell’attività è il Prodotto software, ovvero l’insieme degli elementi software
integrati, con relativi dati e documentazione nella configurazione finale risultante dal test di
prodotto.
Predisposizione del sistema. In accordo con i documenti che descrivono l’architettura tecnica
e/o le Specifiche di realizzazione del servizio, il Fornitore procede alla predisposizione della
infrastruttura hardware e software necessaria per realizzare il sistema che ospiterà gli
ambienti logici di collaudo e di esercizio, provvedendo ad eseguire l’installazione e
l’integrazione delle componenti hardware e software.
In accordo con il Piano di Test, il Fornitore esegue i test unitari delle specifiche componenti
hardware e software, i test di integrazione, volti soprattutto a verificare gli aspetti di
integrazione inter-intra componenti hardware e software ed i test di sistema, volti a verificare
il corretto funzionamento del sistema rispetto ai requisiti specificati nel processo di
Progettazione.
E’ parte integrante dell’attività la produzione di procedure operative che regolamentino sia le
modalità di gestione operativa che le modalità di manutenzione.
Il risultato dell’attività è l’Infrastruttura hardware e software che ospiterà gli ambienti logici
di collaudo ed esercizio, intesa come insieme di componenti hardware e software integrati, con
relativa documentazione, con le procedure e con quanto propedeutico all’installazione ed
esercizio del prodotto software sviluppato o all’erogazione del servizio, nella configurazione
finale risultante dal test di sistema.
Produzione della documentazione. Parallelamente alla codifica del software e/o alla
predisposizione del sistema il Fornitore procede alla produzione della Documentazione utente
(manuali utente, tutorial, help, wizard, ..). La documentazione utente deve essere predisposta
secondo standard e requisiti fissati nel processo di Progettazione e deve essere oggetto di
verifiche formalizzate per verificarne la corrispondenza ai requisiti. Le verifiche devono inoltre
accertare l’accuratezza, la comprensibilità e più in generale l’usabilità della documentazione.
Qualificazione
finale.
Propedeutica al rilascio della fornitura al collaudo presso
l’Amministrazione, è l’esecuzione di test di validazione o qualificazione finale di quanto
realizzato (prodotto software; infrastruttura di collaudo ed esercizio; documentazione utente),
come ultima valutazione dello stato di consolidamento della fornitura e della sua capacità di
superare il collaudo finale. I risultati di tale test, insieme a quelli di tutti i test, verifiche,
validazioni e riesami effettuati precedentemente, anche relativamente ai prodotti output del
processo di Progettazione, concorrono alla formulazione, da parte del Fornitore, di una
Certificazione di rilascio al collaudo della fornitura.
Installazione. L’attività riguarda l’installazione del prodotto software sviluppato nell’ambiente
di esercizio e/o l’esecuzione di compiti, non svolti nell’ambito dell’attività di Predisposizione del
sistema, volti a rendere operativo il sistema o l’ambiente di erogazione del servizio. Detti
compiti possono riguardare, senza la pretesa di essere esaustivi: l’attivazione di profili utente
per la sicurezza; l’attivazione di postazioni di lavoro; la configurazione di prodotti software; il
caricamento iniziale di dati nelle delle basi dati, a partire da sistemi preesistenti (legacy
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 30/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
systems) per il tramite di attività di migrazione, o direttamente da dati cartacei tramite
attività di acquisizione dati (data entry).
L’attività è svolta secondo un Piano di installazione, correlato al Piano di progetto, nel quale
sono indicati attività, tempi, modi e risorse necessarie.
Il risultato dell’attività è il sistema che ospita l’ambiente di erogazione del servizio, con il
prodotto software sviluppato e le relative basi dati installate e correttamente funzionanti,
secondo i requisiti contrattuali e progettuali, ovvero con tutto quanto necessario a garantire
l’erogabilità dei servizi oggetto di fornitura, nel rispetto dei requisiti contrattuali e di
progettazione.
Collaudo. L’attività è eseguita da una Commissione di collaudo nominata
dall’Amministrazione ed individuata, nella sua composizione, sulla base delle capacità
professionali e di giudizio richieste. La Commissione opera con autonoma responsabilità e
secondo le prescrizioni della normativa di riferimento ed ha il compito di verificare che quanto
realizzato dal Fornitore sia conforme ai requisiti indicati nella baseline di contratto. Possono
essere oggetto di collaudo, secondo quanto richiesto nel contratto, il prodotto software
realizzato, il sistema che ospita l’ambiente di esercizio, il modello di funzionamento del
servizio oggetto di fornitura e tutta la documentazione utente. Le prove di collaudo sono di
regola eseguite nell’ambiente di collaudo predisposto dal Fornitore secondo quanto specificato
nel processo di Progettazione.
Il Fornitore deve supportare la Commissione nella esecuzione delle prove, nel rilevamento dei
risultati, nella stesura del rapporto finale. Per svolgere le prove di collaudo la Commissione
può utilizzare, a titolo di guida, le Specifiche di collaudo predisposte dal Fornitore nell’ambito
del processo di Progettazione, e può prendere visione dei risultati dei test interni eseguiti dal
Fornitore nel corso del processo di Realizzazione e di ogni registrazione concernente le attività
di Riesame, Verifica e Validazione svolta. Il Piano di collaudo, la documentazione di
esecuzione delle prove e delle non-conformità rilevate dovranno essere formalizzati in
documenti.
La verifica con esito positivo della fornitura termina con l’emissione di un Verbale di collaudo
positivo, che sancisce la conformità ai requisiti contrattuali del prodotto software e/o
l’erogabilità del servizio oggetto di fornitura. L’accettazione da parte dell’Amministrazione
dell’esito positivo del collaudo, dà luogo all’accettazione della fornitura. In caso di esito
negativo del collaudo e/o di non-conformità rispetto ai requisiti contrattuali, il Fornitore, in
accordo con il processo di Risoluzione dei problemi, è tenuto a rimuovere i malfunzionamenti e
a presentare nuovamente la fornitura al collaudo, nei tempi e nei modi stabiliti nel contratto.
La conclusione del collaudo con esito positivo e l’accettazione da parte dell’Amministrazione
della fornitura, comportano il congelamento della configurazione di base del prodotto software
e/o del sistema che ospita l’ambiente di erogazione del servizio.
Avviamento alla gestione operativa. Successivamente all’accettazione della fornitura può
essere prevista una attività di avviamento che consiste nell’esercizio del prodotto software
nella configurazione di base presso utenze pilota. Tale attività ha l’obiettivo di verificare
l’affidabilità, le prestazioni, l’usabilità, la sicurezza del prodotto e la sua manutenibilità.
A conclusione del periodo di avviamento viene fornito un “Rapporto su qualità e prestazioni
del prodotto software” in cui sono riportati gli indicatori rilevati ed il relativo andamento
rispetto ai valori di soglia e/o target di riferimento prefissati. Il periodo di garanzia ha di
norma durata di 12 mesi.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 31/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Chiusura del processo
La Realizzazione si conclude con il completamento con esito positivo del collaudo. Il processo
produce, in sintesi, i seguenti risultati:
o
rilascio del prodotto software e/o del sistema che realizza l’ambiente di erogazione del
servizio, corredati della relativa documentazione utente; detti elementi sono individuati
e documentati, nelle loro componenti, nella configurazione risultante dal collaudo, che
rappresenta la configurazione di base per le successive attività previste nell’ambito dei
processi di Gestione operativa e Manutenzione;
o
rilascio della documentazione utente, nella configurazione risultante dal collaudo;
o
aggiornamento della baseline di progettazione e dei prodotti del processo di Gestione.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 32/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
5.1.5. PROCESSO DI GESTIONE OPERATIVA
Obiettivi
Obiettivo del processo è l’erogazione dei servizi, unita alla conduzione funzionale e tecnica del
sistema. Le attività da svolgere sono regolati dai processi organizzativi e supportati dai
processi di supporto.
Attivazione del processo
Il processo è attivato al termine del processo di Realizzazione, con la messa in esercizio del
prodotto software e/o del sistema che ospita l’ambiente di erogazione del servizio, corredati
della documentazione utente e della documentazione necessaria per la gestione. In particolare
sono input del processo, oltre ai prodotti delle attività di Realizzazione, la Specifica dei
requisiti, le Specifiche del servizio, le Specifiche di realizzazione del Servizio e le Specifiche di
controllo qualità del servizio, prodotte nel processo di Progettazione, come eventualmente
modificate dal processo di Realizzazione, nonché le procedure operative prodotte nell’ambito
del processo di Realizzazione.
Attività e prodotti
Nello schema che segue si fornisce una rappresentazione delle attività proprie del processo di
Gestione operativa e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali
si fornisce a seguire una descrizione delle finalità e dei contenuti.
Processo di Gestione operativa
Attività
Prodotti
GO-A1
Prove delle forniture rilasciate in
esercizio
GO-A2
Gestione operativa
GO-A3
Assistenza agli utenti
GOA1-O1
Fornitura (prodotto software – sistema documentazione utente) nella nuova
configurazione
GOA2-O1
Registrazioni relative alla conduzione
tecnico-funzionale del sistema
GOA3-O1
Registrazioni relative all’assistenza
fornita
GOA3-O2
Registrazione dei problemi e delle
richieste di modifica provenienti
dall’utente
Prove delle forniture rilasciate in esercizio. Per ogni nuova versione dei componenti del
prodotto software e/o del sistema rilasciata in esercizio, il Fornitore deve svolgere appropriati
test che verifichino la capacità del componente (nella versione in prova) di soddisfare i
requisiti specificati per la sua gestione operativa. L’esecuzione di tali test deve essere
propedeutica alla accettazione in gestione operativa del componente. In particolare, i test
devono accertare che il componente si attivi, esegua correttamente le sue funzioni, termini le
sue attività così come descritto nei manuali di gestione operativa e nei piani relativi e che non
determini malfunzionamenti nelle altre componenti del sistema (test di non regressione). Il
risultato dell’attività è il prodotto software e/o il sistema nella nuova configurazione
(configurazione corrente).
Gestione Operativa. In accordo con le Specifiche di realizzazione del servizio e le Specifiche di
controllo qualità del servizio, il Fornitore eroga il servizio oggetto di fornitura contrattuale.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 33/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Oltre ai compiti che sono specifici della tipologia di servizio da erogare, indicati nei documenti
sopra citati, il Fornitore nell’ambito di tale attività svolge in via continuativa un insieme di
compiti che sono finalizzati a garantire che il sistema operi in accordo con quanto contenuto
nelle Specifiche del servizio e nella documentazione utente e che rendono possibile la corretta
fruizione del servizio da parte dell’utente finale. Detti compiti possono includere, ad esempio:
o
inizializzazione e disattivazione di componenti del sistema;
o
presidio degli strumenti di controllo e degli ambienti di controllo;
o
gestione delle procedure operative;
o
gestione degli accessi e delle convenzioni;
o
interventi sui malfunzionamenti hardware e software per il ripristino delle
funzionalità;
o
controllo della operatività del sistema e gestione delle procedure di restart e recovery;
o
gestione dei supporti utilizzati nella gestione dei dati e delle stampe;
o
controllo remoto dei sistemi non presidiati, installati presso utenze periferiche;
o
schedulazione ed esecuzione delle attività e produzione rapporti di riepilogo.
L’attività di Gestione operativa deve essere svolta in accordo con il Piano di progetto, il Piano
di qualità ed eventuali documenti correlati ed in accordo con le procedure e la documentazione
predisposta allo scopo nell’ambito del processo di Realizzazione.
Nello svolgimento di questa attività, devono essere identificate, registrate e risolte, le
anomalie riscontrate, in accordo con il processo di Risoluzione dei problemi.
E’ parte integrante dell’attività la predisposizione ed attivazione del sistema per controllare in
via continuativa che le Specifiche del servizio siano soddisfatte e per rilevare e misurare la
qualità del servizio erogato. Le registrazioni delle misure effettuate devono permettere di
valutare l’andamento del servizio e le azioni correttive/preventive da intraprendere per
assicurare il rispetto dei requisiti di qualità contrattuali.
Il risultato dell’insieme dei compiti che il Fornitore svolge nella Gestione operativa è costituito
dalle Registrazioni delle attività svolte per garantire il corretto funzionamento del sistema e
l’erogazione del servizio all’utente finale in accordo con le Specifiche del servizio e la
documentazione utente.
Assistenza agli utenti. Il Fornitore, su richiesta, deve fornire assistenza e consulenza agli
utenti nell’utilizzo del sistema. Le richieste di assistenza, che devono essere registrate e
tracciate fino alla loro conclusione, possono dare luogo a modifiche al sistema. Tali modifiche,
che possono consistere in correzioni permanenti, nuove versioni che includano funzionalità o
funzioni precedentemente omesse o miglioramenti del sistema, devono essere gestite in
accordo con il processo di Manutenzione.
Chiusura del processo
Il processo di Gestione operativa è attuato in via continuativa fino alla conclusione del ciclo di
vita della fornitura, che può coincidere con la dismissione del prodotto software o del sistema
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 34/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
da parte dell’Amministrazione o con la scadenza del contratto, nel caso in cui sia previsto
dall’Amministrazione il subentro di un nuovo Fornitore.
Il processo produce, in sintesi, i seguenti risultati:
o
corretto funzionamento del sistema ed erogazione del servizio agli utenti nel rispetto
delle Specifiche del servizio e della documentazione utente;
o
aggiornamento alla configurazione di base del prodotto software e/o del sistema e
conseguenti modifiche alla documentazione utente
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 35/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
5.1.6. PROCESSO DI MANUTENZIONE
Obiettivi
Obiettivo del processo è sottoporre a modifica il prodotto software e/o il sistema preservandone
l’integrità. Il processo include le attività di migrazione e dismissione.
Le modifiche devono essere attuate e gestite in accordo con il processo di Gestione delle
Configurazione.
Attivazione del processo
Il processo è attivato quando è necessario apportare modifiche al prodotto software, al sistema
ed alla relativa documentazione. L’esigenza di modifica può nascere nell’ambito del processo
di Gestione operativa ed in particolare da segnalazione dell’utente o da parte dello stesso
Fornitore o può derivare da richieste dell’Amministrazione. Sono input del processo i prodotti
del Processo di Progettazione e di Realizzazione. Il processo deve essere attuato secondo piani
e procedure documentate.
Attività e prodotti
Nello schema che segue si fornisce una rappresentazione delle attività proprie del processo di
Manutenzione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si
fornisce a seguire una descrizione delle finalità e dei contenuti.
Processo di Manutenzione
Attività
MA-A1
MA-A2
Prodotti
Analisi dei problemi e delle modifiche
MAA1-O1
Piano delle modifiche
MAA2-O1
Fornitura (prodotto software - sistema documentazione utente) nella nuova
configurazione
MAA2-O2
Registrazioni relative alle modifiche ed
alle prove
MAA3-O1
Fornitura (prodotto software - sistema documentazione utente) in esercizio
nella nuova configurazione
(configurazione corrente)
Esecuzione delle modifiche
MA-A3
Riesame/accettazione delle
modifiche
MA-A4
Migrazione
MAA4-O1
Piano di migrazione
MA-A5
Dismissione
MAA5-O1
Piano di dismissione
Analisi dei problemi e delle modifiche. Il Fornitore deve analizzare le
Registrazione dei
problemi e delle richieste di modifica provenienti dall’utente, nonché ogni altra richiesta o
esigenza di modifica al prodotto software e/o al sistema, in base ai seguenti elementi:
o
Tipologia: correttiva, migliorativa, preventiva, adattativa ad un nuovo ambiente;
o
Campo di applicazione: ampiezza della modifica, elementi del sistema da modificare,
tempi richiesti, costi previsti;
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 36/117
CNIPA
o
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Criticità: impatto sul funzionamento del sistema, sulle prestazioni e sulla sicurezza.
Le modifiche di tipo correttivo sono innescate da impedimenti all’esecuzione di funzioni o da
differenze riscontrate fra l’effettivo funzionamento del prodotto software e quello atteso,
previsto nella relativa documentazione o comunque determinato dalla prassi dell’utente. Tali
modifiche, a differenza delle altre tipologie sopra indicate, seguono una modalità di esecuzione
di tipo continuativo ed, in linea di massima, non sono pianificabili, essendo orientate alla
rimozione dei difetti causati dal prodotto software o dal sistema stesso.
Il risultato dell’attività è il Piano delle modifiche, ovvero un documento o un insieme di
documenti nel quale sono indicati le tipologie di modifiche, i risultati dell’analisi per quanto
riguarda il campo di applicazione e la criticità di ciascuna modifica, nel senso sopra indicato, le
opzioni di soluzione.
Fatta eccezione per le modifiche di tipo correttivo che non sono pianificabili, il Fornitore deve
ottenere dall’Amministrazione l’approvazione del Piano delle modifiche prima di dare luogo
alla esecuzione delle modifiche individuate.
Esecuzione delle modifiche. Sulla base del Piano delle modifiche, il Fornitore realizza le
modifiche seguendo il processo di Progettazione ed il processo di Realizzazione ed in
particolare assicurando che:
o
siano definiti, eseguiti e documentati i test (unitari, funzionali, di prodotto, di sistema,
di non regressione) delle parti modificate e non modificate (unità software, componenti
ed elementi di configurazione) del sistema. L’esecuzione dei test deve essere effettuata
nell’ambiente di collaudo ed i risultati devono essere documentati.
o
sia assicurata la completa e corretta realizzazione dei requisiti nuovi o modificati. Deve
essere inoltre assicurato il corretto funzionamento del sistema rispetto ai requisiti
originali non modificati.
Il risultato delle attività è costituito dal prodotto software e/o dal sistema, con relativa
documentazione, nella nuova configurazione, verificata nell’ambiente di collaudo rispetto ai
requisiti nuovi e ai requisiti non modificati.
Riesame/Accettazione delle modifiche. L’attività è volta a verificare l’integrità del sistema
modificato, attraverso riesami condotti con l’Amministrazione o con l’organizzazione che
autorizza le modifiche sulla base di tutte le registrazioni relative alle modifiche effettuate ed
ai risultati delle prove eseguite (Test Data Report).
L’approvazione delle modifiche da parte dell’Amministrazione, secondo modalità stabilite nel
contratto, comporta l’accettazione da parte dell’Amministrazione del prodotto software e/o del
sistema, con la relativa documentazione, nella nuova configurazione (configurazione corrente),
che diviene operativa nell’ambiente di esercizio e in relazione alla quale vengono svolte le
attività proprie dei processi di Gestione operativa e di Manutenzione.
Migrazione. L’attività è svolta nel caso in cui debba essere effettuata la migrazione del
prodotto software e/o del sistema che realizza l’ambiente di erogazione del servizio in un nuovo
ambiente operativo o nel caso in cui debba subentrare un nuovo soggetto nella erogazione del
servizio oggetto di fornitura contrattuale. In tal caso il Fornitore deve pianificare ed eseguire
tutte le attività necessarie a garantire il corretto funzionamento del prodotto software e/o del
sistema o a garantire la corretta erogazione del servizio in un nuovo ambiente.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 37/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Il Fornitore deve predisporre un Piano di migrazione, che indichi:
o
requisiti della migrazione;
o
attività di migrazione;
o
mezzi, modalità e tempi per eseguire la migrazione;
o
modalità di verifica del prodotto software, del servizio e/o del sistema nel nuovo
ambiente operativo.
Nel caso in cui alla scadenza del contratto sia prevista l’erogazione del servizio da parte di un
nuovo soggetto, il Piano di migrazione deve contenere tutte le informazioni necessarie per
consentire il subentro, con particolare riferimento a:
o
procedure, documentazione e quanto necessario per la gestione operativa e la
manutenzione del sistema;
o
modalità di erogazione della formazione e dell’affiancamento al soggetto subentrante.
Il Fornitore deve svolgere in parallelo le attività del processo di gestione operativa
nell’ambiente di origine, fino al completamento della migrazione ed alla verifica del corretto
funzionamento di quanto realizzato.
Il completamento delle attività di migrazione deve essere notificato a tutti gli interessati.
Tutta la documentazione, il codice e i dati associati al prodotto software, al sistema o al
servizio devono essere archiviati, quando necessario, e accessibili in accordo con i requisiti
contrattuali.
Dismissione. Quando l’Amministrazione abbia deciso di procedere alla dismissione del
prodotto software e/o del sistema o di sospendere l’erogazione del servizio, il Fornitore deve
predisporre ed eseguire un Piano di dismissione delle attività connesse, con particolare
riferimento alle attività di gestione operativa e di manutenzione. Il documento deve contenere
dati di pianificazione con riferimento agli elementi di seguito elencati:
o
cessazione totale o parziale del servizio e dell’assistenza dopo un determinato periodo di
tempo;
o
archiviazione del prodotto software e della relativa documentazione associata;
o
responsabilità per ogni eventuale necessità di assistenza da fornire in futuro;
o
transizione al nuovo prodotto software e/o al nuovo sistema, qualora applicabile;
o
accessibilità alle copie degli archivi dei dati e della documentazione
Il Piano di dismissione, con l’indicazione delle attività previste, deve essere notificato agli
utenti interessati. Le notifiche devono comprendere:
o
descrizione delle attività di sostituzione o di aggiornamento, con relative date di
disponibilità;
o
descrizione delle altre opzioni di assistenza disponibili una volta che il supporto sia
stato rimosso.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 38/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
In caso di avvio di un nuovo prodotto software e/o di un nuovo sistema in sostituzione del
precedente, dovrebbero essere condotte attività di parallelo tra dismissione del vecchio
ambiente ed avvio del nuovo.
Il completamento delle attività di dismissione deve essere notificato a tutti gli interessati.
Tutta la documentazione, il codice e i dati utilizzati dal prodotto software e/o dal sistema o ad
essi associati devono essere archiviati, quando necessario, e accessibili in accordo con i
requisiti contrattuali.
Chiusura del processo
Il processo di Manutenzione è attuato in via continuativa fino alla conclusione del ciclo di vita
della fornitura, che può coincidere con la dismissione del prodotto software o del sistema da
parte dell’Amministrazione o con la migrazione in un nuovo ambiente operativo alla scadenza
del contratto, nel caso in cui sia previsto dall’Amministrazione il subentro di un nuovo
Fornitore. Il processo produce, in sintesi, i seguenti risultati:
o
corretto funzionamento del prodotto software e/o del sistema, attraverso attività che
assicurano in via continuativa la rimozione dei malfunzionamenti, il miglioramento
delle funzionalità e delle prestazioni, l’adeguamento costante all’ambiente tecnologico;
o
definizione delle modalità di migrazione e dismissione del prodotto software e/o del
sistema o di cessazione del servizio.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 39/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
5.2. PROCESSI TRASVERSALI
I processi trasversali, ad uso interno all’organizzazione impegnata nella fornitura, sono
utilizzati e svolti come parte integrante di altri processi e contribuiscono ad assicurare il
successo e la qualità del progetto nel suo complesso, includono la Gestione, la Gestione della
documentazione, la Gestione della configurazione, l’Assicurazione Qualità.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 40/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
5.2.1. PROCESSO DI GESTIONE
Obiettivi
Obiettivo del processo è consentire al Fornitore la conduzione coordinata del progetto che deve
essere sviluppato in esecuzione del contratto, con l’obiettivo ultimo di completare con successo
il progetto, nel rispetto dei requisiti di tempi, costi e qualità indicati nei documenti
contrattuali.
Ricadono nell’ambito di questo processo tutte le attività preliminari all’avvio del processo di
Progettazione, come la pianificazione delle attività, l’acquisizione delle risorse, la definizione
dell’organizzazione del progetto e l’avvio delle attività, nonché tutte le attività di
coordinamento delle risorse assegnate al progetto in corso d’opera; il processo include inoltre le
attività di controllo dell’andamento del progetto, la produzione di stati di avanzamento di tutte
le attività necessarie al conseguimento degli obiettivi contrattuali, inclusa la fornitura alle
parti interessate delle informazioni sulle evoluzioni e sugli avanzamenti del progetto e della
opportuna documentazione e le attività condotte per identificare, valutare e gestire i rischi del
progetto.
Ricadono nell’ambito di questo processo la definizione e manutenzione dell’infrastruttura
necessaria allo svolgimento degli altri processi, questa ultima attuata in via continuativa fino
alla conclusione di tutti i processi del ciclo di vita della fornitura che lo utilizzano.
L’infrastruttura può includere hardware, software, strumenti, tecniche, norme e
apparecchiature per i processi di Progettazione, Realizzazione, Gestione Operativa e
Manutenzione, nonché per i processi di Gestione della Documentazione e Gestione delle
Configurazioni.
Il processo ha anche l’obiettivo di misurare e migliorare i processi attuati dal Fornitore
nell’ambito del ciclo di vita della fornitura fino alla conclusione di tutti i processi svolti dal
Fornitore per eseguire la fornitura oggetto del contratto. Anche rendendo disponibile, in via
continuativa, personale adeguatamente addestrato e formato all’avvio di ciascuna attività
pianificata per l’esecuzione del contratto..
Attivazione del processo
Il processo è svolto dal Fornitore ed è attivato a valle della sottoscrizione del contratto. Sono
dati di input del processo l’insieme dei documenti che costituiscono la baseline di contratto,
prodotti nell’ambito dei processi di Acquisizione e di Fornitura, ovvero il Contratto, il
Capitolato tecnico, l’Offerta tecnico-economica del Fornitore.
A questi si aggiungono l’insieme dei documenti prodotti nel processo di Progettazione per
quanto concerne la definizione dell’infrastruttura e le Registrazioni prodotte nel corso della
esecuzione delle attività, rilevanti ai fini delle misure da effettuare per ciascun processo, per
quanto concerne il miglioramento dei processi produttivi.
Di norma le principali milestones che regolano la pianificazione delle attività ed il rilascio
all’Amministrazione di prodotti intermedi e/o finali sono fissati nel contratto. Ulteriori
momenti e/o elementi di verifica possono essere concordati tra Fornitore ed Amministrazione
nel corso della esecuzione del contratto.
Le attività di “pianificazione” vera e propria di tempi, costi, qualità, gestione rischi e gestione
delle comunicazioni, sono propedeutiche a tutti i processi del ciclo di vita e sono volte a
programmare tutte le attività da svolgere nel corso della esecuzione del contratto, in modo da
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 41/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
rispettare i vincoli ed i requisiti previsti nel contratto stesso. I documenti di pianificazione ed
in particolare la baseline dei tempi e dei costi e della qualità, costruita in questa fase iniziale,
costituisce il programma di riferimento con il quale confrontare i successivi aggiornamenti
nelle fasi realizzative ed esercitare le funzioni di controllo fino alla conclusione del progetto.
Attività e prodotti
Nello schema che segue si fornisce una rappresentazione delle attività proprie del processo di
Gestione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si fornisce
a seguire una descrizione delle finalità e dei contenuti.
Processo di Gestione
Attività
Prodotti
GE-A1
Pianificazione del progetto
GEA1-O1
Piano di progetto
GE-A2
Analisi dei rischi
GEA2-O1
Piano di gestione dei rischi
GE-A3
Pianificazione della comunicazione
GEA3-O1
Piano di gestione delle comunicazioni
GE-A4
Pianificazione della qualità
GEA4-O1
Piano di qualità
GE-A5
Esecuzione del progetto
GEA5-O1
Registrazioni
GEA5-O2
Richieste di cambiamenti
GEA6-O1
Stato Avanzamento Lavori (SAL)
GEA7-O1
Registrazioni
GEA7-O2
Richieste di cambiamenti
Definizione dell’infrastruttura
GEA8-O1
Specifiche dell’infrastruttura
Manutenzione dell’infrastruttura
GEA9-O1
Registrazioni
GE-A10
Definizione dei processi
GEA10-O1
Disegno dei processi
GE-A11
Valutazione dei processi
GEA11-O1
Registrazioni
GE-A12
Miglioramento dei processi
GEA12-O1
Piano di miglioramento dei processi
GE-A13
Definizione delle esigenze
GEA13-O1
Piano di formazione
GE-A14
Sviluppo del materiale di formazione
GEA14-O1
Materiali didattici e strumentazione
GE-A15
Esecuzione della formazione
GEA15-O1
Registrazioni
GE-A16
Conclusione del progetto
GEA16-A1
Archivio del progetto
GE-A6
Controllo del progetto
GE-A7
Revisione, Riesame e valutazione
GE-A8
GE-A9
Pianificazione del progetto. Il punto di partenza per la pianificazione del progetto da realizzare
in esecuzione del contratto, è la definizione degli obiettivi del progetto (ambito del progetto),
ovvero dei criteri qualitativi e quantitativi che devono essere soddisfatti perché il progetto
possa considerarsi completato con successo; segue, quindi, l’individuazione di tutte le entità
organizzative (individui o organizzazioni) che sono attivamente coinvolte nel progetto, o i cui
interessi possono essere influenzati, in modo positivo o negativo, dall’esito del progetto.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 42/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
In genere le entità organizzative interessate alla fornitura oggetto di un contratto includono le
seguenti:
o
Responsabile di contratto – la persona, rispettivamente lato Fornitore e lato
Amministrazione, che è responsabile di tutto quanto attiene alla esecuzione del
contratto;
o
Responsabile di progetto – la persona, rispettivamente lato Fornitore e lato
Amministrazione, che è responsabile di gestire il progetto. Le figure del Responsabile di
contratto e del Responsabile di progetto in molti casi possono coincidere; in altri si
differenziano per i profili professionali richiesti, che nel caso del Responsabile di
contratto risultano più orientati alle competenze giuridico-amministrative.
o
Centro di costo – la persona o l’organizzazione che beneficerà dei risultati del progetto;
o
Centro di responsabilità – la persona o l’organizzazione, rispettivamente lato Fornitore
e lato Amministrazione, che è coinvolta a vario titolo nella realizzazione il progetto;
o
Centro di spesa – l’organizzazione che provvede ad impegnare i fondi per il progetto.
Segue quindi la pianificazione operativa vera e propria che, a partire dai deliverables
contrattuali, ovvero dalle attività e dai prodotti propri dei processi primari, ed attraverso una
scomposizione secondo un livello di dettaglio via via crescente, porta a definire una
disaggregazione gerarchica del lavoro da svolgere ed all’individuazione delle unità elementari
di lavoro, alle quali è possibile assegnare tempi di esecuzione, risorse e costi. Tale attività
consente di definire la baseline di riferimento per misurare le prestazioni di tempi e costi nel
corso della esecuzione del progetto.
Il risultato dei compiti sopra descritti è contenuto nel Piano di progetto, ovvero un documento
(o un insieme di documenti) formale, approvato, utilizzato per gestire e controllare l’esecuzione
del progetto. Il Piano di progetto è un documento dinamico, che può variare man mano che si
consolidano le informazioni sul progetto, a differenza della baseline dei tempi e dei costi che
invece è uno strumento di controllo, che può variare di regola solo a fronte di cambiamenti
approvati degli obiettivi di progetto.
Il Piano di progetto può essere organizzato e presentato in diversi modi; in genere include
almeno, direttamente o attraverso il riferimento ad altri documenti, le seguenti informazioni:
o
informazioni di sintesi sulle caratteristiche del progetto (requisiti e/o obiettivi strategici
che il progetto si prefigge di soddisfare; descrizione del prodotto e/o del servizio che il
progetto dovrà realizzare per soddisfare i requisiti del contratto; durata complessiva
(inizio – fine); eventuali vincoli e supposizioni; eventuali risorse che devono essere rese
disponibili dalle Amministrazioni; Responsabile di progetto assegnato);
o
gli obiettivi del progetto e le entità organizzative coinvolte;
o
l’organizzazione di progetto, le risorse assegnate ed i relativi ruoli e profili
professionali;
o
le interfacce organizzative e tecniche;
o
la Work Breakdown Structure (WBS) riferita alle attività ed ai prodotti propri dei
processi primari, ovvero la scomposizione dei deliverables contrattuali al fine di
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 43/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
definire le unità di lavoro al livello di dettaglio in base al quale sarà necessario
esercitare il controllo in fase di esecuzione del progetto;
o
la stima dei costi, la programmazione temporale delle attività e le assegnazioni di
responsabilità per ciascuna unità di lavoro della WBS;
o
la baseline di riferimento per misurare le prestazioni di tempi e costi;
o
la definizione della periodicità con cui verrà rilevato lo stato di avanzamento lavori
(SAL), le metriche da utilizzare per misurare l’avanzamento, le date programmate di
svolgimento di Riesami e Verifiche;
o
le principali milestones, vale a dire i momenti a cui corrispondono fatti rilevanti dal
punto di vista gestionale e che sostituiscono dei punti di controllo essenziali per la
verifica del corretto avanzamento dei lavori;
o
i problemi aperti e/o le decisioni pendenti;
o
le modalità per la gestione dei cambiamenti.
Analisi dei rischi. Include le attività condotte per identificare, valutare e gestire i rischi del
progetto. Non è un’attività da attuarsi una tantum, ma dovrebbe essere eseguita in modo
sistematico durante tutto il ciclo di vita della fornitura.
L’identificazione dei rischi ha come scopo principale quello di identificare e classificare le
principali sorgenti di rischio del progetto in esame. Le sorgenti di rischio più comuni sono:
o
cambiamenti di requisiti e/o requisiti ambigui;
o
errori, omissioni o incorretta applicazione dei requisiti in fase di progettazione;
o
sottostima di tempi, costi e risorse;
o
non chiara definizione di ruoli e responsabilità;
o
non adeguata competenza del personale;
o
dipendenze esterne.
Una volta individuate e classificate le sorgenti di rischio, si determina:
o
la probabilità (alta; media; bassa) che si verifichino fattori di rischio da ciascuna classe;
o
la frequenza con cui potrebbero verificarsi;
o
la fase del progetto nella quale potrebbero accadere;
o
l’impatto sul progetto (alto; medio; basso), valutato prendendo in esame la perdita
(economica; di immagine o altro) che si avrebbe se l’evento si verificasse;
o
le entità organizzative coinvolte.
Dalla combinazione di uno o più degli elementi precedentemente evidenziati, si determina
l’approccio da seguire per la gestione. In particolare, la valutazione porta il Responsabile di
progetto a decidere quali rischi debbano essere :
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 44/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
o
mitigati (attraverso azioni preventive/correttive volte a limitare la probabilità che si
verifichino e l’impatto sul progetto);
o
accettati (accettare le conseguenze);
o
evitati (attraverso azioni volte ad eliminare le cause).
Il risultato dell’attività è il Piano di gestione dei rischi o un documento equivalente che, oltre a
documentare i risultati delle fasi di identificazione e valutazione, nel senso sopra indicato,
descrive le azioni e le procedure per gestire i rischi e le responsabilità di gestione delle varie
aree di rischio.
Pianificazione delle comunicazioni. E’ l’attività con la quale si determinano le esigenze di
informazione e di comunicazione di tutte le entità organizzative coinvolte nel progetto e/o
destinatarie dei risultati del progetto.
Il prodotto dell’attività è il Piano di gestione delle comunicazioni, o un documento equivalente,
che includa almeno:
o
un metodo di raccolta ed archiviazione delle varie tipologie di informazione;
o
un sistema di distribuzione, che dettagli a chi andranno le informazioni ed in che modo
(rapporti scritti, incontri, ecc.):
o
una descrizione delle informazioni da distribuire (tipologia, formato, contenuto, livello
di dettaglio, convenzioni/definizioni da assumere);
o
una programmazione temporale, che assicuri la tempestività nella generazione e
distribuzione delle informazioni;
o
un metodo per aggiornare e revisionare il Piano di gestione delle comunicazioni in
funzione delle evoluzioni del progetto.
Il livello di dettaglio del documento è dettato dalle esigenze di condivisione di informazioni e
comunicazioni determinate dal progetto.
Pianificazione della qualità. E’ l’attività con la quale, a partire dai requisiti specificati nei
documenti contrattuali, si dettagliano e si documentano tutti i requisiti di qualità espressi,
impliciti ed obbligatori e si definisce come tali requisiti saranno soddisfatti e controllati.
Il prodotto dell’attività è il Piano di qualità, o un documento equivalente, che deve indirizzare
il controllo di qualità, l’assicurazione di qualità ed il miglioramento di qualità per tutte le fasi
del ciclo di vita della fornitura. Descrive almeno gli obiettivi di qualità, i controlli e le
verifiche, i criteri di entrata/uscita delle varie fasi progettuali, i criteri di accettazione dei
prodotti delle fasi.
Esecuzione del progetto. L’attività consiste nella esecuzione di quanto pianificato nel Piano di
progetto, nel Piano di gestione dei rischi, nel Piano di gestione delle comunicazioni e nel Piano
di qualità.
In particolare in tale fase si dà luogo alla esecuzione delle attività proprie dei processi primari,
secondo il programma temporale definito nel Piano di progetto, alla gestione dei rischi,
secondo il Piano di gestione dei rischi, alla distribuzione delle informazioni secondo il Piano di
gestione delle comunicazione.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 45/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Nel corso di tale attività, sulla base dei risultati dell’attività di Controllo del progetto di
seguito descritta, il Fornitore deve rilevare, analizzare e risolvere criticità e problemi emersi.
La risoluzione di tali problemi può comportare modifiche ai piani.
I prodotti dell’attività, oltre ai prodotti propri di ciascuna attività afferente ai processi primari
che vengono svolti in tale ambito, sono:
o
le Registrazioni delle attività svolte;
o
eventuali richieste di cambiamenti (estendere l’ambito del progetto; modificare la stima
dei costi, ecc.), che danno quindi luogo ad una modifica ai piani.
Controllo del progetto Il controllo viene esercitato costantemente durante l’esecuzione del
progetto. L’obiettivo è rilevare e gestire i cambiamenti rispetto ai piani, al fine di assicurare il
completamento del progetto nel rispetto dei tempi, dei costi e della qualità richiesta.
I compiti principali sono costituiti dal controllo complessivo dei cambiamenti e dalle
registrazione delle prestazioni di progetto.
Il controllo complessivo dei cambiamenti consiste essenzialmente nel coordinare e gestire i
cambiamenti attraverso tutto il progetto.
I cambiamenti si rilevano attraverso:
o
il controllo dei tempi: rilevazione dei cambiamenti alla schedulazioni rispetto alla
baseline dei tempi;
o
il controllo dei costi: rilevazione dei cambiamenti al budget del progetto rispetto alla
baseline dei costi;
o
il controllo della qualità: verifica che i risultati delle varie fasi rispettino i requisiti di
qualità;
o
il controllo dei rischi: verifica dell’efficacia delle azioni previste per mitigare/evitare i
rischi e gestione dei cambiamenti nei rischi individuati.
La registrazione delle prestazioni di progetto ha lo scopo di raccogliere in modo sistematico i
risultati sull’andamento del progetto, in modo da fornire alle entità organizzative interessate
le informazioni sull’avanzamento delle attività in termini di quantità messe in opera (attività
completate e/o deliverables prodotti) e risorse spese.
Il risultato finale dell’attività di Controllo del progetto è uno Stato Avanzamento Lavori (SAL),
ovvero un documento, o un insieme di documenti, prodotti periodicamente, secondo la
periodicità e le modalità indicate nel Piano di progetto ed approvate dall’Amministrazione, che
contenga almeno le seguenti informazioni:
o
registrazioni sullo stato delle attività alla data;
o
registrazioni sull’avanzamento alla data;
o
previsioni e stime a finire
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 46/117
CNIPA
o
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
risultati delle attività svolte in esecuzione del Piano di progetto (quali deliverables sono
stati parzialmente o completamente realizzati, in che tempi e con quali costi rispetto
alle previsioni indicate nelle rispettive baseline).
Revisione, riesame e valutazione. Periodicamente, secondo la periodicità e le modalità indicate
nel Piano di progetto e nel Piano di qualità e comunque quando opportuno, vanno effettuate
delle Revisioni a vari livelli (nell’ambito del team di progetto; con le entità organizzative
interessate), aventi ad oggetto elementi quali:
o
esame delle attività correnti e del loro stato;
o
verifica dello stato di avanzamento delle attività e degli eventuali scostamenti dai
piani;
o
esame delle criticità ed identificazione delle relative azioni correttive;
o
analisi dei rischi in essere e delle azioni collegate.
Il Fornitore deve assicurare che i piani e le attività svolte nell’ambito del processo di gestione
siano adeguati rispetto ai requisiti contrattuali.
I prodotti dell’attività, sono:
o
le Registrazioni;
o
eventuali richieste di cambiamenti, che danno quindi luogo ad una modifica ai piani.
Definizione dell’infrastruttura. All’avvio del processo di Progettazione, il Fornitore deve
pianificare e definire l’infrastruttura necessaria per svolgere tutte le attività previste
nell’ambito dei processi del ciclo di vita della fornitura. In particolare, sulla base dei requisiti
contrattuali, della Specifica dei requisiti e considerando le procedure applicabili, le norme, gli
strumenti e le tecniche, il Fornitore deve definite le risorse hardware e software, i mezzi
materiali e quanto altro necessario a soddisfare i requisiti del processo che utilizza il processo
di Infrastruttura e deve pianificare e documentare la relativa configurazione, in accordo con il
processo di Gestione della Configurazione.
Il risultato dell’attività è costituito dalle Specifiche dell’Infrastruttura, ovvero un documento o
un insieme di documenti nel quale, per ciascun processo che utilizza il processo di
Infrastruttura, è definita l’infrastruttura da utilizzare e sono indicate le modalità di
realizzazione con costi e vincoli temporali, le caratteristiche di funzionalità, prestazioni,
sicurezza, riservatezza, disponibilità, requisiti di spazio e attrezzature, la configurazione delle
risorse hardware, software e della documentazione.
L’installazione della infrastruttura è propedeutica alla esecuzione del processo che la richiede.
Manutenzione dell’infrastruttura. Il Fornitore deve assicurare che l’infrastruttura sia gestita,
mantenuta e se necessario modificata, al fine di garantire che continui a soddisfare i requisiti
del processo che la utilizza. Detta attività è svolta nell’ambito dei processi di Gestione
operativa e di Manutenzione e dà luogo ai prodotti ivi evidenziati. Le modifiche alla
infrastruttura vengono realizzate in linea con il processo di Gestione della Configurazione. Il
Fornitore nel corso dell’attività produce le Registrazioni relative alla gestione della
infrastruttura e alle modifiche effettuate
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 47/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Definizione dei processi. Con riferimento ai processi che caratterizzano il ciclo di vita della
fornitura, il Fornitore identifica, organizza e gestisce la propria rete di processi e le relative
interfacce. In particolare devono essere individuati e pianificati tutti i processi che hanno
diretta influenza sulla qualità della fornitura e che possono avere impatto sulla soddisfazione
dell’utente. Detti processi sono descritti in un documento o in un insieme di documenti,
Disegno dei processi, nel quale oltre ad essere indicati attività, input ed output dei processi,
sono indicate le loro applicazioni a specifici casi ed i meccanismi di controllo volti a sviluppare,
monitorare, valutare e migliorare i processi stessi.
Valutazione dei processi. E’ l’attività volta a misurare le prestazioni di ciascun processo, in
termini qualitativi e quantitativi. Le valutazioni sono condotte periodicamente ad intervalli
definiti, secondo piani, sulla base dei dati (dati prestazionali; dati tecnici; dati sui costi della
qualità; ecc.) tratti dalle Registrazioni delle attività svolte in esecuzione dei processi stessi.
I risultati di ciascuna valutazione, documentati nelle relative Registrazioni, costituiscono i
dati di input necessari per il miglioramento dei processi.
Miglioramento dei processi. I risultati dell’attività di valutazione vengono analizzati dal
Fornitore per individuare i punti di forza e di debolezza dei processi impiegati. Queste analisi
rappresentano l’input per la definizione ed attuazione di un Piano di miglioramento dei
processi, che individui le azioni correttive e preventive da adottare al fine di risolvere e
prevenire i problemi e le non-conformità nei prodotti oggetto di fornitura, nonché allo scopo di
raccomandare modifiche nello sviluppo del progetto (o di progetti successivi) e determinare i
necessari avanzamenti tecnologici. Nel corso di tale attività viene aggiornata la
documentazione dei processi, per riflettere le modifiche attuate per migliorare i processi stessi.
Definizione delle esigenze. Sulla base dei requisiti del progetto, il Fornitore definisce le
esigenze di acquisizione di nuove risorse specialistiche e/o di sviluppo delle capacità
professionali esistenti all’interno dell’organizzazione.
In particolare il Fornitore, in relazione alle attività indicate nel Piano di progetto, definisce la
tipologia delle risorse necessarie con il livello di formazione richiesto e predispone un Piano di
formazione, nel quale sono decritti i requisiti delle risorse, le necessità di formazione, i
contenuti degli interventi formativi richiesti, le modalità di erogazione della formazione (corsi
in aula, training on the job, ecc.), i materiali didattici e gli strumenti da utilizzare, i tempi di
esecuzione. Il Piano deve prevedere inoltre specifiche attività di valutazione del grado di
apprendimento degli allievi, ai fini della valutazione dell’efficacia del processo formativo.
Nella pianificazione degli interventi formativi il Fornitore deve assicurare che personale
adeguatamente formato sia disponibile in modo tempestivo per le attività pianificate.
Sviluppo del materiale di formazione. E’ l’attività di predisposizione del materiale didattico e
degli strumenti da utilizzare per eseguire gli interventi formativi, in accordo con quanto
stabilito nel Piano di formazione.
Esecuzione della formazione. E’ l’esecuzione del Piano di formazione, secondo tempi e modi ivi
indicati. L’attività dà luogo alle Registrazioni degli interventi formativi effettuati, che
consentono di valutare l’efficacia del processo formativo e di pianificare ulteriori interventi, in
funzione di nuove esigenze.
Conclusione del progetto. E’ l’attività conclusiva, che comprende l’esecuzione di tutti gli
adempimenti di fine contratto, la verifica del completamento effettivo di tutte le attività e la
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 48/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
verifica finale, avente lo scopo di misurare il successo del progetto rispetto agli obiettivi. E’
parte integrante dell’attività la storicizzazione dei documenti e delle registrazioni prodotte nel
corso della esecuzione del processo, che devono essere archiviati secondo modalità specificate
nel contratto.
Il risultato dell’attività è l’Archivio di progetto, inteso come l’insieme di tutte le informazioni
che lo definiscono e lo caratterizzano, in riferimento all’intero ciclo di vita, raccolte, gestite ed
utilizzate dalla nascita al completamento, ovvero fino alla conclusione del contratto con
l’Amministrazione.
Chiusura del processo
Il processo di Gestione si conclude quando risultino completate tutte le attività e gli
adempimenti previsti dal contratto e siano soddisfatti gli obiettivi del progetto.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 49/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
5.2.2. PROCESSO DI DOCUMENTAZIONE
Obiettivi
Obiettivo del processo è consentire al Fornitore la gestione sistematica dei documenti prodotti
nel ciclo di vita della fornitura. Secondo la norma ISO 9001, i meccanismi di gestione della
documentazione si applicano sia ai documenti che ai dati. I dati possono essere tabelle, grafici,
diagrammi di flusso, banche dati, prospetti, dati informatici e qualunque altra forma di
rappresentazione di informazioni relative al ciclo di vita della fornitura.
Il processo si esplica attraverso un insieme di attività volte a pianificare, progettare, produrre
e distribuire i documenti necessari a tutte le entità organizzative interessate.
Attivazione del processo
Il processo è svolto dal Fornitore in via continuativa, indipendentemente dai processi primari
attivati con la sottoscrizione del contratto. La definizione delle modalità di gestione dei
documenti connessi al ciclo di vita della fornitura segue la sottoscrizione del contratto. Sono
dati di input i requisiti indicati nei documenti che costituiscono la baseline di contratto,
prodotti nell’ambito dei processi di Acquisizione e di Fornitura, nonché i documenti prodotti
nell’ambito del processo di Progettazione, nei quali sono specificati regole, strumenti, standard
e convenzione per la produzione e gestione dei documenti relativi alla fornitura.
Attività e prodotti
Nello schema che segue si fornisce una rappresentazione delle attività proprie del processo di
Documentazione e dei prodotti che costituiscono il risultato di ciascuna attività, per i quali si
fornisce a seguire una descrizione delle finalità e dei contenuti.
Processo di Documentazione
Attività
Prodotti
DO-A1
Pianificazione
DOA1-O1
Piano di gestione della documentazione
DO-A2
Progettazione e sviluppo
DOA2-O1
Documento approvato
DO-A3
Distribuzione e conservazione
DOA3-O1
Registrazioni
DO-A4
Manutenzione
DOA4-O1
Documento approvato (nuova versione)
Pianificazione. Il Fornitore deve definire e documentare le modalità per identificare tutti i
documenti che devono essere prodotti durante il ciclo di vita della fornitura e per
regolamentare le relative modalità di progettazione, sviluppo, distribuzione, conservazione e
manutenzione.
I documenti prodotti nel ciclo di vita della fornitura possono essere in genere di origine interna
e di origine esterna. I documenti di origine interna sono tutti i documenti generati all’interno
della organizzazione del Fornitore, prodotti nel corso della esecuzione del contratto; possono
essere deliverable contrattuali, quali documenti di Specifiche, manuali utente, documenti di
pianificazione, ecc, o possono essere documenti contenenti istruzioni o guide sulle attività da
svolgere e sulle relative modalità di svolgimento. I documenti di origine esterna includono i
documenti prodotti da entità organizzative esterne all’organizzazione del Fornitore e rilevanti
per la fornitura, quali ad esempio le norme, gli standard, i documenti emessi
dall’Amministrazione, i documenti dei sub-fornitori, ecc. Tali documenti devono essere gestiti
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 50/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
esclusivamente in configurazione secondo il loro livello di aggiornamento (revisione, versione,
ecc.) e secondo le modalità previste di distribuzione e di conservazione.
Tutti i documenti, sia di origine interna che di origine esterna, che servono per descrivere la
fornitura in tutto il ciclo di vita, devono essere gestiti in configurazione, in accordo con il
processo di Gestione della Configurazione.
Il risultato dell’attività di Pianificazione è il Piano di gestione della documentazione, ovvero
un documento o un insieme di documenti nel quale sono identificati e classificati per tipologia
e contenuti, secondo criteri ivi indicati, tutti i documenti che devono essere prodotti durante il
ciclo di vita della fornitura e, per ciascun documento identificato, sono indicati un
identificativo (titolo o nome), lo scopo, i destinatari, le procedure e responsabilità per input,
sviluppo, riesami, modifiche, approvazioni, produzione, conservazione, distribuzione,
manutenzione, gestione della configurazione, pianificazione delle versioni intermedie e finali.
Progettazione e sviluppo. Sulla base del Piano di gestione della documentazione, ciascun
documento di origine interna identificato deve essere progettato secondo modelli di
documentazione applicabili per quanto riguarda formati, descrizioni del contenuto, marcature
di sicurezza e di proprietà, imballaggio ed altri eventuali elementi di presentazione, in accordo
con i requisiti e con gli standard eventualmente fissati nei documenti contrattuali e/o
nell’ambito del processo di Progettazione.
Completato il disegno dei documenti, è possibile attivare per ciascun documento il flusso di
sviluppo, utilizzando strumenti automatici per la documentazione e prevedendo le appropriate
forme di controllo (redazione, verifica ed approvazione) da parte di personale autorizzato, che
ne verifica l’adeguatezza rispetto ai requisiti indicati. Il risultato dell’attività è il documento
approvato, che può proseguire nel successivo iter di distribuzione e di conservazione, secondo
le modalità fissate nel Piano di gestione della documentazione.
Distribuzione e conservazione. E’ l’attività relativa alla distribuzione dei documenti e alla loro
conservazione, secondo le modalità indicate nel Piano di gestione della documentazione.
L’attività riguarda sia i documenti di origine interna che i documenti di origine esterna.
La distribuzione è finalizzata ad assicurare che siano disponibili edizioni appropriate dei
documenti a tutte le entità organizzative interessate, siano esse interne o esterne
all’organizzazione del Fornitore. Per la distribuzione possono essere utilizzati diversi supporti,
quali carta, dispositivi elettronici o altre tipologie di supporto. La distribuzione è effettuata di
regola secondo elenchi di distribuzione prestabiliti e può avvenire in forma controllata o non
controllata, a seconda che sia a carico dell’entità emittente distribuire eventuali nuove
versioni del documento o debba essere l’entità ricevente a richiederne eventuali nuovi
aggiornamenti.
Per quanto riguarda la conservazione, di cui è parte integrante l’archiviazione, i materiali
originali devono essere conservati secondo i requisiti di tempi e modi relativi a conservazione
delle registrazioni, riservatezza, sicurezza, manutenzione ed eventuali prescrizioni normative.
La conservazione dei documenti deve prevedere modalità, quali ad esempio la gestione di
elenchi dei documenti, atte ad impedire l’utilizzo di documenti non più validi e superati.
Il risultato dell’attività è rappresentato dalle Registrazioni relative alla distribuzione ed alla
conservazione dei documenti.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 51/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Manutenzione. Nel caso in cui i documenti di origine interna, approvati e distribuiti, debbano
essere modificati, si applica il processo di Manutenzione, con particolare riferimento alle
attività di Analisi dei problemi e delle modifiche, Esecuzione delle modifiche,
Riesame/accettazione delle modifiche.
La progettazione e sviluppo del documento modificato e la relativa distribuzione e
conservazione, avvengono attraverso le attività sopra descritte e secondo il Piano di gestione
della documentazione. Per i documenti da gestire in configurazione, le modifiche devono essere
apportate in accordo con il processo di Gestione della configurazione. Il risultato dell’attività è
costituito dal documento nella nuova versione.
Chiusura del processo
Il processo di Gestione della documentazione si conclude con la conclusione del ciclo di vita
della fornitura, quando risultino completate tutte le attività relative alla distribuzione e
conservazione dei documenti ed in generale tutte le attività previste nel Piano di gestione
della documentazione.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 52/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
5.2.3. PROCESSO DI GESTIONE DELLA CONFIGURAZIONE
Obiettivi
Il processo ha l’obiettivo di garantire l’integrità e la rintracciabilità di tutti gli elementi che
compongono la fornitura nell’intero ciclo di vita, attraverso attività, sia tecniche che gestionali,
d’identificazione e documentazione delle caratteristiche funzionali e fisiche degli elementi, di
controllo dei cambiamenti delle caratteristiche, di registrazione e notifica dello stato di
realizzazione.
La gestione della configurazione identifica la configurazione di un prodotto in alcuni momenti
del ciclo di vita; si basa sulla creazione progressiva di baseline, ognuna delle quali definisce lo
stato del prodotto in un dato momento. Ogni modifica apportata ad un elemento della baseline
deve essere effettuata in modo controllato.
Attivazione del processo
Il processo è svolto dal Fornitore in via continuativa, indipendentemente dai processi primari
attivati con la sottoscrizione del contratto. La definizione delle modalità di gestione della
configurazioni dei prodotti connessi al ciclo di vita della fornitura segue la sottoscrizione del
contratto. Sono dati di input i requisiti indicati nei documenti che costituiscono la baseline di
contratto, prodotti nell’ambito dei processi di Acquisizione e di Fornitura, nonché i documenti
prodotti nell’ambito del processo di Progettazione, nei quali sono specificati regole, strumenti e
modalità per la gestione delle configurazioni dei prodotti oggetto del contratto.
Attività e prodotti
Nello schema che segue si fornisce una rappresentazione delle attività proprie del processo di
Gestione della Configurazione e dei prodotti che costituiscono il risultato di ciascuna attività,
per i quali si fornisce a seguire una descrizione delle finalità e dei contenuti.
Processo di Gestione della Configurazione
Attività
Prodotti
CO-A1
Pianificazione
CO-A2
Identificazione della configurazione
COA1-O1
Piano di gestione della configurazione
COA2-O1
Documenti di configurazione
COA2-O2
Prodotto nella configurazione di base
CO-A3
Controllo della configurazione
COA3-O
Prodotto nella configurazione corrente
CO-A4
Registrazione dello stato di
configurazione
COA4-O1
Registro delle configurazioni
CO-A5
Rilascio e consegna
COA5-O1
Registrazioni
Pianificazione. Il Fornitore deve definire e documentare le modalità di gestione delle
configurazioni dei prodotti durante il ciclo di vita, attraverso la predisposizione di un Piano di
gestione della configurazione, ovvero di un documento o di un insieme di documenti nel quale
sono indicati:
o
le attività di gestione della configurazione, le procedure, il programma temporale di
svolgimento delle attività;
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 53/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
o
le entità organizzative coinvolte nella esecuzione delle attività, le responsabilità
assegnate a ciascuna e la loro interrelazione con altre organizzazioni, tra le quali quelle
preposte alle attività proprie dei processi di Realizzazione e Manutenzione;
o
gli strumenti, le tecniche e le metodologie di gestione della configurazione da utilizzare;
o
lo stadio al quale ciascun elemento dovrebbe essere passato sotto controllo di
configurazione.
Identificazione della configurazione. Il Fornitore, in accordo con il Piano di gestione della
configurazione, deve identificare e documentare gli elementi di configurazione e le loro
versioni. Per ciascuna versione di ciascun elemento devono essere identificati la
documentazione che stabilisce la baseline, le connessioni con la versione, ogni altro dettaglio
che ne permetta l’identificazione, ivi incluse le necessarie caratteristiche funzionali e fisiche di
ciascun elemento, con le interfacce, le modifiche, le deroghe e le concessioni (documenti di
configurazione). Per esempio per i prodotti software, per ciascuna versione di un elemento
devono essere identificati le specifiche tecniche e funzionali, gli strumenti di sviluppo che
abbiano influenza su tali specifiche, le interfacce con altri elementi software o con l’hardware
ed i documenti e gli archivi informatici relativi all’elemento. L’identificazione dell’elemento
software deve essere di regola organizzata in modo che si possa dimostrare la relazione tra
l’elemento ed i requisiti contrattuali.
Il Fornitore deve identificare le versioni degli elementi di configurazione che, integrati tra
loro, costituiscano una specifica versione del prodotto completo. Con accordi formali, in
momenti determinati del ciclo di vita, deve essere stabilita la configurazione di base del
prodotto ed usata come punto di partenza per il controllo formale della configurazione e per lo
sviluppo delle versioni successive (configurazione corrente). Per esempio, in un rapporto
contrattuale tra Fornitore ed Amministrazione la configurazione di base di un prodotto a
completamento del processo di Realizzazione è ratificata dalla conclusione con esito positivo
del collaudo.
L’attività di identificazione della configurazione, produce come risultati i documenti di
configurazione, che descrivono le caratteristiche funzionali e fisiche di ciascun elemento di
configurazione, secondo quanto sopra indicato, e la ratifica della configurazione di base del
prodotto.
Controllo della configurazione. L’attività è svolta secondo il Piano di gestione della
configurazione ed ha lo scopo di assicurare che, dopo il rilascio iniziale dei documenti di
configurazione e la ratifica della configurazione di base, tutte le modifiche siano apportate in
modo controllato. In particolare nel corso di tale attività il Fornitore deve:
o
identificare e registrare le richieste di modifica;
o
analizzare e valutare le modifiche, con riferimento ai requisiti, al campo di applicazione
(ampiezza della modifica; elementi da modificare) ed alla criticità (impatto sul
funzionamento del prodotto, sulle prestazioni e sulla sicurezza).
o
sottoporre i risultati dell’analisi all’iter di approvazione previsto nel Piano di gestione
della configurazione;
o
attuare e verificare le modifiche approvate;
o
rilasciare gli elementi modificati.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 54/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Per proteggere l’integrità della configurazione e fornire la base per il controllo delle modifiche
è necessario che gli elementi di configurazione, le unità che le costituiscono e la
documentazione relativa siano tenuti dal Fornitore in un ambiente che:
o
sia commisurato con le condizioni ambientali richieste (ad esempio software, dati,
documenti, ecc.);
o
li protegga da modifiche non autorizzate o da danneggiamenti;
o
fornisca i mezzi per ricostruirli in caso di danneggiamento;
o
nel caso di software, dati, documenti e disegni, permetta il recupero di una copia
dell’originale sotto controllo;
o
consenta di relazionare la configurazione del prodotto come risultante rispettivamente
dal processo di Progettazione e dal processo di Realizzazione.
Il risultato dell’attività è rappresentato dall’insieme degli elementi modificati che nell’insieme
costituiscono il prodotto nella configurazione corrente.
Registrazione dello stato della configurazione. L’attività consiste nel predisporre registrazioni
sulla gestione della configurazione e rapporti di situazione che mostrino lo stato e la storia
degli elementi controllati, inclusi i documenti relativi alla baseline. La registrazione dello
stato di configurazione inizia dal momento in cui i dati di configurazione sono generati per la
prima volta.
Il Fornitore in particolare deve alimentare e gestire un Registro delle configurazioni, che
consenta di documentare lo stato di costruzione di ciascun prodotto e dei relativi elementi
nelle diverse versioni e nelle diverse fasi del ciclo di vita, con particolare riferimento a:
o
prodotti in corso di realizzazione, di gestione operativa e di manutenzione o in esercizio
presso le Amministrazioni;
o
elenco degli elementi controllati e dei documenti relativi alla baseline;
o
configurazione di base ciascun prodotto, che rappresenta la definizione del prodotto nel
momento specifico;
o
configurazione corrente, costituita dalla configurazione di base e dalle modifiche
approvate, realizzate e collaudate;
o
documentazione riguardante le modifiche e lo stato di attuazione, verifica e collaudo
delle stesse.
Rilascio e consegna. L’attività riguarda il rilascio, la consegna e la conservazione dei prodotti e
della relativa documentazione.
Propedeutica al rilascio è la valutazione della configurazione del prodotto, avente lo scopo di
assicurare la completezza funzionale e fisica degli elementi rispetto ai requisiti.
I materiali originali (codice, documenti, ..) devono essere mantenuti per tutto il ciclo di vita e
devono essere trattati, consegnati e conservati nel rispetto di requisiti relativi a conservazione
delle registrazioni, riservatezza, sicurezza, manutenzione ed eventuali prescrizioni normative.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 55/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Il risultato dell’attività è rappresentato dalle Registrazioni relative al rilascio ed alla consegna
dei prodotti.
Chiusura del processo
Il processo di Gestione della Configurazione si conclude con la conclusione del ciclo di vita
della fornitura, quando risultino completate tutte le attività relative al rilascio ed alla
consegna dei prodotti ed in generale tutte le attività previste nel Piano di gestione della
configurazione.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 56/117
CNIPA
5.4.3
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
PROCESSO DI ASSICURAZIONE QUALITÀ
Obiettivi
Il processo ha l’obiettivo di fornire adeguate assicurazioni che i prodotti ed i processi svolti nel
ciclo di vita della fornitura siano conformi ai requisiti specificati e conformi ai relativi piani.
La norma UNI CEI ISO/IEC 12207 prevede che il processo di Assicurazione Qualità debba
essere svolto in modo coordinato con i processi di Verifica, Validazione, Riesame congiunto,
Verifica Ispettiva e Risoluzione dei problemi. Per tale motivo detti processi, nel seguito, sono
visti come attività proprie del processo di Assicurazione Qualità, essendo ad esso strettamente
collegati.
Attivazione del processo
Il processo è attivato parallelamente al processo di Gestione e svolto dal Fornitore secondo
attività pianificate, in accordo quanto definito nel Piano di qualità.
Attività e prodotti
Nello schema che segue si fornisce una rappresentazione delle attività del processo di
Assicurazione Qualità; sono incluse in tale ambito anche le attività proprie dei processi di
Verifica, Validazione, Riesame congiunto, Verifiche ispettive e Risoluzione dei problemi, in
quanto sono strettamente connesse all’assicurazione qualità.
Per tutte le attività ed i prodotti evidenziati, si fornisce a seguire una descrizione delle finalità
e dei contenuti.
Processo di Assicurazione Qualità
Attività
Prodotti
AQ-A1
Pianificazione
AQA1-O1
Piano di assicurazione qualità
AQ-A2
Assicurazione qualità
AQA2-O1
Registrazioni
AQ-A3
Verifica
AQA3-O1
Registrazioni
AQ-A4
Validazione
AQA4-O
Registrazioni
AQ-A5
Riesame congiunto
AQA5-O1
Registrazioni
AQ-A6
Verifica ispettiva
AQA6-O1
Piano di verifica
AQA6-O2
Rapporto di verifica
AQA7-O1
Piano di gestione dei problemi
AQA7-O2
Registrazioni
AQ-A7
Risoluzione dei problemi
Pianificazione. Sulla base dei requisiti del progetto e in accordo con il Piano di qualità ed il
Piano di progetto, il Fornitore deve sviluppare ed attuare, per tutta la vita del contratto, un
Piano di assicurazione qualità che contenga i seguenti elementi:
o
livelli di qualità, metodologie, procedure e strumenti per svolgere le attività di
assicurazione qualità;
o
procedure relative al riesame del contratto ed alla conseguente coordinazione;
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 57/117
CNIPA
o
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
risorse, programma temporale e responsabilità della conduzione delle attività di
assicurazione qualità, ivi incluse le attività di Verifica, Validazione, Riesame
congiunto, Verifica ispettiva.
Assicurazione qualità. L’attività si specializza nelle seguenti:
o
Assicurazione di prodotto - è volta ad assicurare che tutti i piani predisposti in
esecuzione del contratto soddisfino il contratto stesso, siano tra di loro compatibili e
siano eseguiti secondo le modalità richieste. E’ finalizzata inoltre ad assicurare che i
prodotti siano realizzati in aderenza ai piani e che, al momento della consegna,
soddisfino i requisiti contrattuali e siano accettabili dall’Amministrazione.
o
Assicurazione di processo – è volta ad assicurare che tutti i processi relativi al ciclo di
vita della fornitura (Fornitura, Progettazione, Realizzazione, Gestione operativa,
Manutenzione e processi di supporto) sviluppati in esecuzione del contratto soddisfino
il contratto stesso e siano aderenti ai piani. Ha l’obiettivo inoltre di assicurare che
quanto realizzato da sub-fornitori soddisfi i requisiti del contratto principale stipulato
dal Fornitore con l’Amministrazione.
o
Assicurazione del sistema qualità – include le ulteriori attività di gestione della
qualità, che devono essere assicurate secondo i requisiti della norma ISO 9001 e come
specificato nel contratto.
Il risultato dell’attività è rappresentato dalle Registrazioni relative alle attività svolte e ai
risultati conseguiti.
Verifica. Le verifiche sono eseguite, secondo piani, su attività e prodotti del ciclo di vita che si
ritengono critiche in base alle finalità, all’impatto sul progetto ed alla complessità. L’attività
può essere condotta con vari gradi di indipendenza, nel senso che, a seconda degli obiettivi e
del prodotto da sottoporre a verifica, il grado di indipendenza può spaziare da una stessa
persona o persone differenti nella stessa organizzazione, sino a persone di organizzazioni
differenti.
La verifica può specializzarsi nelle seguenti attività:
o
Verifica del contratto - ha lo scopo di verificare aspetti quali la capacità del Fornitore di
soddisfare i requisiti, la coerenza dei requisiti e l’adeguatezza rispetto alle necessità
dell’utente, l’esistenza di procedure formali per la gestione delle modifiche ai requisiti,
per la risoluzione dei problemi, per l’accettazione della fornitura e per la gestione dei
rapporti tra i contraenti.
o
Verifica del processo – è volta a verificare che ciascun processo sviluppato per
l’esecuzione del progetto sia adeguato ed eseguito secondo i piani ed in accordo con il
contratto e che il personale assegnato sia adeguato alle esigenze ed opportunamente
formato, come richiesto dal contratto.
o
Verifica dei requisiti – è eseguita al fine di assicurare che i requisiti siano coerenti,
fattibili, verificabili e che siano appropriatamente distribuiti sugli elementi hardware,
sugli elementi software e sulle attività manuali, in accordo con i criteri di progettazione
e possano essere sottoposti a prove
o
Verifica della progettazione – ha lo scopo di assicurare la correttezza e la coerenza della
soluzione progettuale rispetto ai requisiti.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 58/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
o
Verifica del prodotto – è volta a determinare che il prodotto software, il sistema o, più
in generale, il risultato di un’attività soddisfi i requisiti o le condizioni imposti loro
dalle attività precedenti, che detti elementi siano tracciabili verso la progettazione e
verso i requisiti, che siano corretti e verificabili.
o
Verifica della integrazione – è volta a verificare che le unità ed i componenti software di
ciascun elemento siano state completamente e correttamente integrati, che gli elementi
hardware, gli elementi software e le attività manuali siano state completamente e
correttamente integrate nel sistema, e che i compiti e le attività di integrazione siano
state svolte secondo i piani.
o
Verifica della documentazione – ha lo scopo di assicurare che la documentazione sia
adeguata, completa e coerente, che sia prodotta tempestivamente e che sia gestita in
configurazione secondo le procedure previste.
Il risultato dell’attività è rappresentato dalle Registrazioni relative alle attività svolte e ai
risultati conseguiti.
Validazione. La validazione ha lo scopo di determinare che il prodotto realizzato soddisfi i
requisiti iniziali, fissati nel contratto e che operi correttamente in relazione alla sua
destinazione d’uso. Analogamente alla Verifica, l’attività può essere condotta con vari gradi di
indipendenza, nel senso che, a seconda degli obiettivi e del prodotto da validare, il grado di
indipendenza può spaziare da una stessa persona o persone differenti nella stessa
organizzazione, sino a persone di organizzazioni differenti.
L’attività è condotta secondo un piano (Piano di test o documento equivalente), nel quale sono
indicati gli elementi da validare, i test da eseguire, le risorse necessarie e le relative
responsabilità, il programma temporale di esecuzione dei casi di test, le modalità di notifica
dei risultati agli interessati.
Il risultato dell’attività è rappresentato dalle Registrazioni relative alle attività svolte, di cui
sono parte integrante i risultati dei test eseguiti (Test Data Report).
Riesame congiunto. E’ eseguito da una qualsiasi delle parti contraenti, l’Amministrazione o il
Fornitore, che possono svolgere rispettivamente il ruolo di parte riesaminante e parte
riesaminata, con lo scopo di valutare lo stato ed i prodotti di un’attività; il riesame congiunto
può essere eseguito periodicamente per tutta la durata del contratto, secondo date identificate
nel Piano di progetto, oppure può essere svolto in modo non pianificato, quando ritenuto
necessario da una delle due parti. In ogni caso è eseguito previa definizione dei prodotti e dei
problemi oggetto di riesame, delle risorse coinvolte, dei mezzi e delle modalità di conduzione.
Il riesame congiunto può specializzarsi nelle seguenti attività:
o
Riesame della gestione del progetto – è volto a valutare lo stato del progetto in
relazione ai piani di progetto, ai documenti di stato avanzamento lavori, alle norme e
linee guida applicabili, allo scopo di verificare che le attività procedano secondo i piani
e di intraprendere le opportune azioni per modificare la direzione del progetto e/o
valutare e gestire i rischi rilevati.
o
Riesame tecnico – è condotto sui prodotti delle attività, con lo scopo di verificare che
essi siano completi, conformi alle norme e alle specifiche, siano realizzati in accordo con
il programma temporale e possano essere dati in input all’attività successiva. L’attività
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 59/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
è anche volta a verificare che la progettazione, la realizzazione, la gestione operativa e
la manutenzione siano condotte secondo i piani.
Il risultato dell’attività è rappresentato dalle Registrazioni relative alle attività svolte e ai
risultati conseguiti. Per quanto riguarda i risultati, in particolare, le parti devono concordare
le reciproche responsabilità di gestione delle azioni conseguenti.
Verifica ispettiva. Le Verifiche Ispettive interne (verifiche ispettive di prima parte), di
responsabilità del Fornitore, sono eseguite allo scopo di determinare se le attività svolte ed i
risultati ottenuti sono in accordo con quanto pianificato e risultano adeguati per il
conseguimento degli obiettivi contrattuali. Sono programmate e condotte periodicamente,
secondo date indicate nei piani di progetto, e sono effettuate da personale con competenze
multidisciplinari, individuato in modo da assicurare la completa indipendenza da chi ha
diretta responsabilità per le attività ed i prodotti sottoposti a verifica.
L’esecuzione di ciascuna verifica ispettiva è preceduta dalla predisposizione ed invio alla/e
organizzazione/i interessata/e di un Piano di verifica, volto a stabilire obiettivi ed estensione
della verifica, attività e prodotti oggetto di verifica, entità organizzative interessate, modalità
di esecuzione, documenti di riferimento e criteri di entrata e di uscita della verifica. La verifica
è di regola condotta attraverso colloqui con il personale, esame delle registrazioni delle attività
interessate e dei relativi prodotti, esame dei documenti di riferimento ed osservazione diretta
del modo di operare rispetto ai documenti di riferimento.
A conclusione della verifica viene redatto un rapporto di verifica, o documento equivalente,
distribuito alla parte verificata ed alle entità organizzative interessate, nel quale sono indicati
i risultati della verifica e la pianificazione delle azioni di soluzione ai problemi o alle non
conformità rilevate.
In relazione a quanto stabilito nel contratto, il Fornitore deve consentire all’Amministrazione
la facoltà di procedere alle Verifiche ispettive di seconda parte, di cui all’art. 8 della
Deliberazione AIPA n. 49/2000, verifiche che dovranno essere condotte secondo le modalità
indicate dalla norma EN ISO 10011. Inoltre il Fornitore, se previsto, deve rendere disponibile
all’Amministrazione la documentazione attestante l’esito delle visite di sorveglianza della
società di certificazione della qualità (Verifiche ispettive di terza parte).
Risoluzione dei problemi. Il processo ha l’obiettivo di analizzare i problemi e le non-conformità,
qualunque sia la loro natura o origine, che vengono individuati durante l’esecuzione dei
processi del ciclo di vita della fornitura. L’obiettivo è fornire un modo tempestivo, responsabile
e documentato per assicurare che tutti i problemi rilevati siano analizzati e risolti e siano
individuate le linee di tendenza, al fine di intraprendere per tempo adeguate azioni
preventive.
I problemi e le non-conformità relative ad attività e prodotti devono essere gestiti dal
Fornitore secondo un ciclo chiuso, in grado di assicurare che per ciascun problema venga
intrapresa una azione, che le parti interessate siano informate dell’esistenza del problema e
della sua evoluzione, che siano identificate, analizzate e rimosse le cause e siano fornite
soluzioni in merito, che sia tracciato e riportato lo stato del problema e siano conservate le
relative registrazioni, in accordo con quanto previsto dal contratto.
Per ciascun problema il Fornitore, in un Piano di gestione dei problemi o in un documento
equivalente, deve definire le modalità di gestione, provvedendo in particolare a classificare
ciascun problema per categoria e priorità, secondo uno schema predefinito, ad eseguire analisi
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 60/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
volte a verificare l’impatto del problema sul progetto, le linee di tendenza, le soluzioni da
implementare, le responsabilità ed i tempi per implementare le soluzioni, le relative modalità
di esecuzione e verifica. Le verifiche devono assicurare che le modifiche siano state apportate
correttamente, che non abbiano introdotto ulteriori problemi e che le linee di tendenza
negative siano state invertite.
L’esecuzione del Piano di gestione dei problemi, documentata dalle Registrazioni relative alle
attività svolte, consente la risoluzione del problema e delle sue cause, che deve essere
verificata secondo quanto previsto nel Piano e notificata tempestivamente alle parti
interessate.
Chiusura del processo
Il processo di Assicurazione Qualità è attuato in via continuativa fino alla conclusione di tutti i
processi svolti dal Fornitore per eseguire la fornitura oggetto del contratto.
Le Registrazioni ed i prodotti delle attività relative al processo di Assicurazione Qualità
devono essere resi disponibili all’Amministrazione, secondo quanto stabilito nel contratto, e
costituiscono dati di input al processo di Miglioramento.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 61/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
6. CATEGORIE ED ATTRIBUTI DI QUALITÀ DELLE FORNITURE ICT
Il concetto di qualità si è significativamente trasformato negli ultimi anni. Questa evoluzione è
conseguenza della crescente attenzione da parte dei fornitori alla soddisfazione del cliente
come fattore critico di successo.
Un presupposto fondamentale per raggiungere questo obiettivo riguarda i processi di
erogazione dei servizi adottati dai fornitori che devono essere definiti, formalizzati, controllati
e, se necessario, modificati in base al monitoraggio dei risultati.
Un altro elemento altrettanto importante riguarda l’individuazione di tutti requisiti di qualità
della fornitura, compito che spetta prevalentemente al cliente sulla base delle proprie esigenze
e che deve chiaramente descrivere negli atti contrattuali.
Per fornire un supporto allo svolgimento di questa attività l’ISO (International Standard
Organization) ha prodotto una serie di norme sia sulla qualità dei processi produttivi sia sulla
qualità dei prodotti/servizi. In particolare per quanto riguarda i prodotti software è stato
definito un modello di riferimento, rappresentato dalla norma ISO/IEC 9126:2001, nel quale
sono definite 6 caratteristiche principali di qualità interna ed esterna (con 27
sottocaratteristiche) e 4 fattori di qualità in uso.
Questa norma è stata emessa in una prima versione nel 1991, e poi revisionata nel 2001 con
l’emissione di una nuova versione dal titolo “Information Technology: Software product
quality” suddivisa in quattro parti. La prima versione definiva nelle linee generali anche un
modello di valutazione della qualità basato sulle sei caratteristiche. Con la successiva versione
questa parte è stata enucleata e inglobata nella norma ISO/IEC 14598 dal titolo “Software
Product Evaluation”.
Riguardo ai servizi, una possibile definizione è la seguente tratta dal glossario dei termini e
delle definizione per la qualità di cui alla norma UNI EN ISO 9000:2000: il servizio è il
risultato di attività svolte all’interfaccia tra fornitore e cliente e di attività proprie del
fornitore per soddisfare le esigenze del cliente.
Le caratteristiche intrinseche di un generico servizio derivanti da questa definizione si
riflettono sul rapporto tra cliente e fornitore che si viene ad instaurare in conseguenza
dell'erogazione di un servizio e, conseguentemente, sul contratto che formalizza tale rapporto.
Relativamente alla definizione data i servizi si caratterizzano, rispetto ad altre tipologie di
forniture, quali l’acquisto o locazione di beni (anche software) o le opere pubbliche, per alcuni
elementi distintivi fondamentali:
o
sono intangibili, qualificandosi in termini delle loro prestazioni piuttosto che
relativamente a qualche attributo fisico posseduto; possono in ogni caso essere connessi
alla realizzazione del servizio la fabbricazione, utilizzazione, acquisto o locazione, di
beni tangibili;
o
sono attività continuative, in altre parole la produzione, o erogazione del servizio, e la
sua fruizione non sono separabili; ovviamente come vedremo meglio di seguito la
continuità di erogazione del servizio può anche attuarsi per il tramite di unità
elementari, discrete, di servizio attivate nel tempo automaticamente o su specifica
richiesta dell’utente;
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 62/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
o
presentano una forte variabilità nel tempo, da attribuirsi a possibili fluttuazioni, delle
componenti organizzative, tecnologiche, umane, e dallo stesso processo del fornitore
fornisce la prestazione, che influenzano le prestazioni raggiunte;
o
sono eterogenei, variando nelle prestazioni, da fornitore a fornitore, al variare del
processo produttivo o ciclo di vita adottato; da utente ad utente, al variare del modus
operandi adottato in funzione delle conoscenze e competenze pregresse.
In funzione delle caratteristiche evidenziate, per i servizi sono proposti in letteratura diversi
modelli di riferimento per la misura della qualità che differiscono in parte dal modello per la
valutazione del prodotto software rappresentato dalla norma ISO/IEC 9126. Questi modelli di
valutazione della qualità dei servizi si basano sulla percezione che ha il cliente del servizio
erogato ed a questo scopo stabiliscono delle caratteristiche di qualità del servizio alle quali
tipicamente un utente si riferisce nella valutazione del servizio (punti di vista di chi appalta e,
soprattutto, del fruitore). Queste caratteristiche sono misurate attraverso un’indagine diretta
sugli utenti del servizio per rilevarne il grado di soddisfazione.
Questo tipo di rilevazione ha però due limiti importanti: il primo riguarda il carattere
soggettivo della valutazione che, in parte, può essere superato selezionando e dimensionando
correttamente il campione d’indagine, il secondo riguarda il fatto che si tratta di una
valutazione di carattere qualitativo e non quantitativo fatta in corso d’opera non utile, quindi,
per stabilire i requisiti di qualità del servizio negli accordi contrattuali con il fornitore. E’
necessario che le caratteristiche di qualità che percepisce il cliente siano espresse in forma
quantitativa per poter essere definite preliminarmente, concordate e misurate durante
l’erogazione in modo oggettivo.
A questo scopo occorre individuare indicatori specifici per tipologie di servizio, che consentano
di tradurre almeno in parte le aspettative di qualità dell’utente, attraverso la definizione di
valori di soglia.
Il tipo di relazione tra grado di soddisfazione dell’utente ed i valori di soglia degli indicatori
adottati può essere individuato basandosi su esperienze pregresse sul medesimo servizio o
servizi simili. Per questo risulta essenziale che nel corso di erogazione di un servizio sia
effettuato un monitoraggio continuo degli indicatori di qualità e rilevazioni periodiche sulla
soddisfazione degli utenti.
I modelli più diffusi per la rilevazione della soddisfazione del cliente sono quelli proposti da
Parasuraman e Kano che definiscono le caratteristiche di qualità che concorrono alla
valutazione della soddisfazione dei clienti.
6.1. CARATTERISTICHE DI QUALITÀ (ISO 9126)
La nuova norma ISO 9126 “Information Technology: Software product quality” definisce una
classificazione gerarchica a due livelli dei requisiti di qualità dei prodotti software. Tale
classificazione può essere, almeno in parte adottata, per classificare anche i requisiti di qualità
dei servizi. La norma individua tre classi di qualità, qualità esterna, qualità interna e qualità
in uso:
o
la qualità esterna si riferisce alle caratteristiche del prodotto rilevabili in fase di
esecuzione nell’ambiente in cui sarà utilizzato, in un certo qual modo corrisponde al
punto di vista di chi appalta;
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 63/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
o
la qualità interna si riferisce alle caratteristiche rilevabili analizzando il codice e la
documentazione di progetto e per l’utente, come punto di vista corrisponde alla qualità
intrinseca della fornitura.;
o
la qualità in uso si riferisce a caratteristiche del prodotto rilevabili in uno specifico
contesto e misura quanto il prodotto supporta l’utente nel raggiungere i suoi obiettivi,
corrisponde pienamente al punto di vista del fruitore.
Se si considera che l’utilizzo di un prodotto non è altro che un servizio che questo eroga ad un
utente, è possibile utilizzare la parte del modello di qualità proposto dalla norma che riguarda
la qualità esterna e la qualità in uso per descrivere la qualità in merito alla modalità di
erogazione di un servizio.
Estendendo questo approccio, si può ritenere che il prodotto sia il risultato dell’attività di
progettazione e realizzazione del servizio stesso (es. Nr. di addetti, curricula professionali,
strumenti di supporto, organizzazione, etc.) e quindi può essere applicato al risultato dei
processi di progettazione e realizzazione del servizio.
Il modello proposto individua per la qualità interna e esterna sei caratteristiche e 27
sottocaratteristiche associate come segue:
Qualità interna ed esterna
Funzionalità
Affidabilità
Usabilità
Efficienza
Mantenibilità
Portabilità
• Adeguatezza
• Maturità
• Comprensibilità
• Prestazioni
• Analizzabilità
• Adattabilità
• Modificabilità
• Installabilità
• Stabilità
• Coesistenza
• Collaudabilità
• Sostituibilità
• Conformità
• Conformità
• Accuratezza
• Tolleranza ai
• Apprendibilità
guasti
• Interoperabilità
• Sicurezza
• Conformità alla
• Operabilità
• Ripristinabilità
• Conformità
funzionalità
alla affidabilità
temporali
• Utilizzo risorse
• Conformità
• Attrattività
alla efficienza
• Conformità alla
usabilità
alla
mantenibilità
alla portabilità
La qualità in uso è descritta attraverso quattro caratteristiche che non sono associate a
sottocaratteristiche:
Qualità in uso
Efficacia
Produttività
Salvaguardia
Soddisfazione
Tra queste caratteristiche quelle che descrivono meglio i requisiti di qualità di erogazione di
un servizio sono le 4 caratteristiche che si riferiscono alla qualità in uso e la funzionalità,
l’affidabilità, l’usabilità, l’efficienza per la qualità interna/esterna.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 64/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Per ogni sottocaratteristica sopra elencata le norma ISO 9126 parte 2, 3, 4 individua una o più
metriche per poter misurare in modo quantitativo il profilo di qualità di un prodotto software.
Sono proposte metriche (o indicatori) diverse per misurare la stessa sottocaratteristica in
quanto riguardano aspetti specifici che insieme concorrono a valutare la medesima. Ogni
fornitura ha esigenze specifiche anche in relazione alla qualità ed è necessario, quindi,
selezionare di volta in volta le metriche opportune. Per esempio se abbiamo l’esigenza di
sviluppare dei programmi batch, che sappiamo saranno utilizzati solo per una volta, non si
dovrà dare enfasi al grado di strutturazione del suo codice che misura la facilità di
comprensione del programma in fase di manutenzione.
Questa metrica diviene al contrario importante in un’applicazione ad alto grado di utilizzo, che
si interfaccia o integra numerose applicazioni e per la quale si prevede un esteso periodo di
esercizio. Tale considerazione può essere estesa anche ai profili di qualità che riguardano le
modalità di erogazione di un servizio.
6.2. DIMENSIONI DI QUALITÀ (SERVQUAL)
Ogni servizio ha lo scopo primario di soddisfare i bisogni di chi lo utilizza e di conseguenza il
grado di soddisfazione del cliente è la misura che permette di stabilire se il servizio è erogato
con il giusto livello di qualità.
Negli ultimi tre decenni un consistente numero di studiosi ha affrontato il tema della qualità e
della sua misura e il concetto che si è andato via via affermando è che la qualità del servizio è
il risultato tra il confronto che fa il cliente tra le sue aspettative riguardo a quanto dovrebbe
offrire il fornitore e le prestazioni effettivamente erogate.
L’indagine svolta tramite interviste a 12 focus group da Parasuram, Zeithalm e Berry ha fatto
emergere che il cliente associa la qualità del servizio alla differenza tra le sue aspettative e la
percezione del servizio riguardo a dieci diversi aspetti di valutazione:
o
Aspetti fisici: aspetto delle strutture fisiche, dell’attrezzatura, del personale e degli
strumenti di comunicazione;
o
Affidabilità: capacità di prestare il servizio promesso in modo affidabile e preciso;
o
Capacità di risposta: volontà di aiutare i clienti e di fornire prontamente il servizio;
o
Competenza: possesso delle abilità e delle conoscenze necessarie a prestare il servizio;
o
Cortesia: gentilezza, rispetto, considerazione e cordialità del personale;
o
Credibilità: attendibilità, credibilità ed onestà;
o
Sicurezza: assenza di pericoli, rischi o dubbi;
o
Accessibilità e facilità di contatto;
o
Comunicazione: informazione ai clienti, mediante linguaggi comprensibili ed attenzione
ad ascoltarne la voce;
o
Comprensione del cliente: impegno preconoscere i clienti e le loro esigenze.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 65/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Nell’ottica di sviluppare un sistema di misura della discrepanza tra percezioni e aspettative
del cliente Parasuram, Zeithaml e Berry hanno sviluppato un sistema per la misura della
qualità (Servqual) basato sulle differenze tra due valutazioni effettuate su una scala a sette
valori da applicare a 97 proposizioni inerenti le 10 dimensioni sopra elencate.
Il sistema Servqual è stato successivamente affinato in quanto, dall’analisi dei risultati
dell’applicazione del metodo, risultarono effettivamente significative 34 proposizioni e sette
dimensioni di qualità. La somministrazione successiva del sistema così modificato a 200 clienti
di cinque diverse categorie di servizi ha permesso di semplificare ulteriormente il modello
eliminando ulteriori proposizioni scarsamente rilevanti in modo da creare un modello a 5
dimensioni di qualità e 22 proposizioni.
Dimensioni di qualità
Aspetti fisici
• aspetto delle
attrezzature
• aspetto delle
strutture fisiche
• aspetto del
personale a contatto
con il cliente
• aspetto dei materiali
associati al servizio
(opuscoli,
presentazioni, ecc)
Capacità di
risposta
Affidabilità
• mantenimento delle
promesse
Capacità di
rassicurazione
• tempestività di
• Il personale deve
erogazione
• interesse a risolvere
i problemi del cliente
• corretta erogazione
del servizio la prima
volta
ispirare fiducia
• disponibilità ad
• I clienti devono
aiutare il cliente
sentirsi sicuri nelle
loro transazioni
• personale
disponibile quando
richiesto
• il personale deve
essere cortese
• Il personale deve
• puntualità
Empatia
• Attenzione
individuale al cliente
• orari di apertura
comodi
• personale che si
occupa
personalmente dei
clienti
avere le competenze • personale che ha a
cuore i principali
per rispondere
interessi del cliente
efficacemente alle
domande dei clienti
• personale che
comprende le
specifiche esigenze
dei clienti
• informare il cliente
su quando sarà
erogata la
prestazione
Il sistema Servqual è stato realizzato per poter essere applicato ad un’ampia gamma di servizi.
La struttura di base messa a punto dagli autori su cinque servizi di riferimento e basata su
queste cinque dimensioni, può essere adattata e personalizzata, se necessario, modificando,
sostituendo o aggiungendo nuove proposizioni che meglio si adattano alle caratteristiche del
servizio ed al contesto di erogazione. Le dimensioni di qualità del sistema Servqual
corrispondono ai punti di vista di chi appalta e del fruitore del servizio.
Il sistema Servqual risulta particolarmente valido quando è impiegato in modo ripetuto
insieme ad altri metodi di misura della qualità in quanto permette di stabilire delle affidabili
correlazioni tra quanto si aspetta il cliente e gli indicatori quantitativi di misura della qualità
del servizi. In questo modo è anche possibile seguire l’evoluzione delle aspettative e delle
percezioni dei clienti rispetto alle diverse dimensioni di qualità del servizio.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 66/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Analizzando le 22 proposizioni del sistema Servqual è possibile in parte associare le 5
dimensioni di qualità alle caratteristiche e sottocaratteristiche definite dalla norma ISO 9126.
La tabella che segue indica dimensioni e caratteristiche di qualità che presentano aspetti
comuni:
Caratteristiche di qualità ISO 9126
Aree di qualità
qualità esterna
Caratteristiche
Dimensioni di qualità (SERVQUAL)
aspetti
affidabilità
fisici
Funzionalità
X
Affidabilità
X
Usabilità
capacità
capacità di
di
empatia
rassicurazione
risposta
X
Efficienza
X
X
X
X
Manutenibilità
Portabilità
qualità in uso
Efficacia
Produttività
Salvaguardia
Soddisfazione
X
X
6.3. MODELLO DI QUALITÀ ADOTTATO
I due modelli di qualità descritti individuano, in parte, elementi diversi da utilizzare nella
descrizione del profilo di qualità di un servizio. E’ opportuno quindi fare riferimento ad un
modello completo che rappresenti tutti gli elementi e che aggreghi insieme quelli comuni.
A tale scopo occorre confrontare le definizioni associate alle caratteristiche/sottocaratteristiche
di qualità nella norma ISO 9126 interpretate nell’ottica più generale di erogazione di un
servizio e le definizioni delle dimensioni/proposizioni del modello Servqual.
Il modello che si propone, riassunto nella tabella della pagina seguente, si compone di 10
caratteristiche di qualità e 32 sottocaratteristiche.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 67/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Caratteristiche
Sottocaratteristiche
Funzionalità
adeguatezza
accuratezza
interoperabilità
sicurezza
conformità alla funzionalità
Affidabilità
maturità
tolleranza
ripristinabilità
conformità
Usabilità
comprensibilità
apprendibilità
operabilità
attrattività
conformità all’usabilità
Efficienza
efficienza temporale
utilizzazione delle risorse
conformità all’efficienza
Manutenibilità
analizzabilità
modificabilità
stabilità
testabilità
conformità alla manutenibilità,
Portabilità
adattabilità
installabilità
coesistenza
sostituibilità
conformità alla portabilità
Efficacia
efficacia
Produttività
produttività
Salvaguardia
salvaguardia
Soddisfazione
empatia
capacità di rassicurazione
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 68/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Le relative definizioni delle caratteristiche e sottocaratteristiche del modello di qualità
adottato, riportate di seguito, possono essere applicate ad ogni specifico processo di cui si
compone un servizio.
Funzionalità. Nel servizio/prodotto sono presenti le funzioni che, con le relative proprietà, gli
conferiscono la capacità di soddisfare le esigenze dell’utente. Sottocaratteristiche associate:
o
o
o
adeguatezza - presenza delle funzioni appropriate per i compiti specificati e gli obiettivi
dell’utente
accuratezza - capacità di fornire i corretti o concordati risultati o effetti con il
necessario grado di precisione;
interoperabilità – capacità del servizio/prodotto di interagire con uno o più sistemi
specificati;
o
sicurezza – capacità di proteggere i dati e l’informazione in modo da evitare che persone
o sistemi non autorizzati possano acquisirla o modificarla e in modo da non rifiutarne
l’accesso alle persone e ai sistemi autorizzati;
o
conformità alla funzionalità – capacità di rispettare standard, convenzioni e norme di
legge e normative similari relativamente alla funzionalità.
Affidabilità. Capacità di mantenere un determinato livello di operatività in determinate
condizioni di utilizzo. Sottocaratteristiche associate:
o
maturità – capacità di erogare correttamente il servizio/prodotto la prima volta senza
o
tolleranza - capacità di mantenere un livello specificato di prestazioni in caso di
la necessità di dover ripetere la prestazione e puntualità nell’erogazione della
prestazione;
malfunzionamenti;
o
ripristinabilità –capacità di ristabilire un livello di prestazioni specificato in caso di
o
conformità - capacità di essere conforme a standard, convenzioni o regole pertinenti
malfunzionamento;
all’affidabilità.
Usabilità. Capacità del servizio/prodotto di essere compreso, imparato, usato ed essere
attraente per l’utilizzatore, quando sia usato in condizioni specificate. Sottocaratteristiche
associate:
o
comprensibilità, capacità di mettere l’utente in grado di capire se il servizio è adeguato,
e come può essere utilizzato per compiti particolari e particolari condizioni d’uso.
o
apprendibilità, capacità di mettere l’utente in grado di imparare ad usare il servizio.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 69/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
o
operabilità, capacità di mettere l’utente in grado di controllare l’avanzamento a seguito
o
attrattività, capacità del servizio/prodotto di essere attraente per l’utilizzatore anche in
o
conformità all’usabilità, capacità di rispettare standard, convenzioni, raccomandazioni
stilistiche o regole riguardanti l’usabilità.
di una richiesta di prestazione.
relazione alla comodità dell’orario di erogazione del servizio, all’aspetto delle
attrezzature, delle personale a contatto con il cliente e del materiale associato al
servizio (opuscoli, presentazioni, ecc).
Efficienza. Capacità del servizio/prodotto di fornire appropriate prestazioni relativamente alla
quantità di risorse usate, in condizioni stabilite. Sottocaratteristiche associate:
o
Efficienza temporale, capacità di rispondere tempestivamente alle richieste e di erogare
o
Utilizzazione delle risorse, capacità di usare quantità e tipi appropriati di risorse
o
tempestivamente la prestazione in condizioni stabilite.
durante lo svolgimento delle sue funzioni in condizioni stabilite.
Conformità all’efficienza, capacità di rispettare standard o convenzioni riguardanti
l’efficienza.
Manutenibilità. Capacità del servizio/prodotto di essere modificato. Le modifiche possono
includere interventi sull’organizzazione, le risorse e gli strumenti a fronte di cambiamenti di
ambiente, e di requisiti e specifiche funzionali. Sottocaratteristiche associate:
o
Analizzabilità, capacità del servizio/prodotto di essere diagnosticato relativamente a
o
Modificabilità, capacità di consentire la realizzazione di una modifica specificata.
o
Stabilità, capacità di evitare effetti inattesi dovuti a modifiche degli elementi di cui si
o
o
deficienze nell’erogazione, o relativamente agli elementi, di cui si avvale, da
identificare per essere modificati.
avvale il servizio.
Testabilità, capacità di consentire la validazione di a seguito di modifiche degli
elementi.
Conformità alla manutenibilità, capacità di rispettare standard o convenzioni
riguardanti la manutenibilità.
Portabilità. Questa caratteristica si adatta in particolare ad un prodotto software e riguarda la
capacità di essere trasferito da un ambiente ad un altro. Sottocaratteristiche associate:
o
Adattabilità, capacità di adattarsi a diversi ambienti specificati senza l’impiego di
azioni o mezzi diversi da quelli forniti espressamente a questo scopo per il software
considerato.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 70/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
o
Installabilità, capacità di essere installato in un ambiente specificato.
o
Coesistenza, capacità di coesistere con altro software indipendente in un ambiente
comune, condividendo risorse comuni.
o
Sostituibilità, capacità di essere utilizzato nello stesso ambiente al posto di un altro
o
Conformità alla portabilità, capacità di rispettare standard o convenzioni riguardanti
prodotto software specificato per lo stesso scopo.
la portabilità.
Efficacia. Capacità di mettere in grado gli utenti di raggiungere obiettivi specificati con
accuratezza e completezza in un contesto d’uso specificato.
Produttività. Capacità di mettere in grado gli utenti di impiegare quantità di risorse
appropriate in relazione all’efficacia ottenuta in un contesto d’uso specificato. (Risorse
rilevanti in relazione alla produttività possono includere il tempo per completare il lavoro,
l’impegno dell’utente, materiali o il costo finanziario dell’utilizzazione).
Salvaguardia. Capacità di ottenere livelli di rischio accettabili per danni alle persone,
all’azienda, al software, alla proprietà o all’ambiente in uno specifico contesto d’uso.
Soddisfazione. Capacità di soddisfare gli utenti in uno specificato contesto d’uso (la
soddisfazione è la risposta dell’utente all’interazione con il servizio). Sottocaratteristiche
associate:
o
Empatia, capacità del personale di porre attenzione individuale al cliente, di
o
Capacità di rassicurazione, capacità del personale di ispirare fiducia, di essere cortese,
comprendere le specifiche esigenze dei clienti, di avere a cuore i principali interessi del
cliente, di dimostrare impegno nel risolvere i problemi, di informare il cliente su
quando sarà erogata la prestazione.
di trasmettere sicurezza nelle sue transazioni.
6.4. INDICATORI DI QUALITÀ
Per la misura delle caratteristiche e sottocaratteristiche del modello sopra descritto, si
propone un insieme di indicatori di qualità per la definizione del profilo di qualità del servizio.
Per ogni singola fornitura occorre preliminarmente selezionare le caratteristiche e
sottocaratteristiche di qualità significative e scegliere successivamente gli indicatori di qualità
associati, che descrivono più efficacemente questi elementi nel contesto di riferimento della
fornitura.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 71/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Ogni indicatore di qualità adottato deve essere quindi associato ad un valore di soglia o valore
obiettivo, che può essere determinato prendendo a riferimento dati di letteratura o, se
disponibili, valori relativi a precedenti forniture equivalenti che dovranno essere
personalizzati in base alle specifiche esigenze.
La tabella che segue, a fronte delle 10 caratteristiche di qualità e delle 32 sottocaratteristiche
definite all’interno del modello di qualità adottato, presenta per ciascuna di queste ultime un
esempio di indicatore di qualità. Ad ogni sottocaratteristica di qualità possono essere associati
più indicatori, quelli di seguito identificati, uno per sottocaratteristica, vogliono solo essere
degli esempi. Per questo motivo la lista degli indicatori di qualità di seguito prodotta non deve
essere intesa in senso esaustivo.
Metriche di misura della qualità – 1/4
caratteristica/
sottocaratt.
funzionalità/
adeguatezza
nome della metrica
descrizione della metrica
misura, formula e dati elementari
adeguatezza funzionale
misura il rapporto tra funzioni
implementate e funzioni
richieste
funzionalità/
accuratezza
accuratezza delle
funzioni implementate
X = 1-A/B
A = numero delle funzioni mancanti.
B = Numero di funzioni previste nei
requisiti
X = A/B
A = numero di funzioni implementate con il
livello di accuratezza richiesto
B = numero di funzioni i cui requisiti
prevedono specifici livelli di accuratezza
funzionalità/
interoperabilità
Difetti nello scambio dei
dati tra applicazioni
funzionalità/
sicurezza
controllo degli accessi
funzionalità/
conformità
conformità funzionale
misura il rapporto tra funzioni
implementate con il livello di
accuratezza richiesto e le
funzioni i cui requisiti
prevedono specifici livelli di
accuratezza
misura il numero di casi in cui X = 1-A/B
la funzione di interfaccia
A = numero di casi in cui è usata la
provoca errori
funzione di interfaccia e sono rilevati errori.
B = numero di casi in cui è usata la
funzione di interfaccia
Conta il numero dei requisiti
X = A/B
di controllo degli accessi
A = numero dei requisiti di controllo degli
implementati rispetto al
accessi implementati
numero dei requisiti di
B = numero dei requisiti di controllo degli
controllo degli accessi
accessi
Conta il numero di item per i X = A/B
quali è assicurata la
A = numero di item per i quali è assicurata
conformità rispetto al numero la conformità
di item per i quali è richiesta
B= numero di item per i quali è richiesta la
la conformità
conformità
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 72/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Metriche di misura della qualità –2/4
caratteristica/
sottocaratt.
affidabilità/
maturità
nome della metrica
descrizione della metrica
Conta il numero di errori che
si presentano durante un
periodo definito e calcola
l’intervallo medio tra due
errori
Malfunzioni che
misura il rapporto tra le
impediscono l’utilizzo del malfunzioni che producono la
sistema
sospensione dell’uso del
sistema ed il totale delle
malfunzioni rilevate
Y=T/A
T = somma degli intervalli di tempo tra due
errori A = numero totale di errori rilevati
affidabilità/
ripristinabilità
disponibilità
misura la disponibilità del
servizio in un determinato
periodo di tempo
X = { To / (To + Tr) }
To = tempo in cui il servizio è operativo
Tr = tempo per le riparazioni
affidabilità/
conformità
conformità per
l’affidabilità
usabilità/
comprensibilità
completezza della
descrizione
X=1- A/B
A = Numero di elementi implementati
conformi riguardo all’affidabilità
B = Numero totale di elementi per cui è
richiesta la conformità
X=A/B
A = Numero di funzioni comprensibili
B = Numero totale di funzioni
usabilità/
apprendibilità
facilità d’uso delle
funzioni
usabilità/
operabilità
comprensibilità dei
messaggi/
comunicazioni
misura la conformità del
prodotto/servizio a
regolamenti, standard e
convenzioni applicabili
riguardo all’affidabilità
Misura la percentuale di
funzioni che risultano
comprensibili dopo la lettura
della descrizione del
prodotto/servizio
Misura il tempo necessario
per apprendere ad usare una
funzione
misura il grado di
comprensione dei
messaggi/comunicazioni
trasmessi in fase di utilizzo
del prodotto/servizio
usabilità
/attrattività
attrattività
dell’interazione con il
prodotto/servizio
conformità all’usabilità
affidabilità/
tolleranza
usabilità/
conformità
all’usabilità
tempo intercorrente tra
due errori (MTBF)
misura, formula e dati elementari
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
misura quanto l’utente valuta
attraente l’interazione con il
prodotto/servizio
misura la conformità del
prodotto/servizio a
regolamenti, standard e
convenzioni applicabili
riguardo all’usabilità
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
X = 1- A/B
A = numero di malfunzioni che producono
la sospensione dell’uso del sistema
B = numero di malfunzioni rilevate
T = tempo medio necessario per imparare
ad utilizzare una funzione correttamente
X = A / UOT
A = numero di volte che l’utente deve
ripetere la stessa operazione in quanto
non è in grado di operare correttamente a
fronte di un messaggio
UOT = periodo di osservazione
Uso di questionari e metodi assegnazione
del punteggio
X=1- A/B
A = Numero di elementi implementati
conformi riguardo all’usabilità
B = Numero totale di elementi per cui è
richiesta la conformità
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 73/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Metriche di misura della qualità – 3/4
caratteristica/
sottocaratt.
efficienza/
efficienza
temporale
efficienza/
utilizzazione
delle risorse
efficienza/
conformità
all’efficienza
nome della metrica
descrizione della metrica
tempo di risposta
misura il tempo medio di
attesa tra la formulazione di
una richiesta e la sua
completa evasione
per i prodotti sw si
misura il numero di errori che
misura il grado di utilizzo si verificano in una unità di
di dispositivi di I/O,
tempo simulando una
memoria, risorse di
condizione di massimo carico
trasmissione.
X = Tmedio / TXmedio
Tmedio = ∑(Ti) / N, (per i=1 a N)
TXmedio = tempo medio di risposta
richiesto
X=A/T
A = numero di messaggi di errore
T = tempo di osservazione
per i servizi si misura il
grado di competenza e
di efficienza del
personale impiegato.
conformità all’efficienza
Uso di questionari e metodi assegnazione
del punteggio per la valutazione della
competenza delle risorse
misura quanto l’utente valuta
competente il personale
preposto all’erogazione del
servizio
misura la conformità del
prodotto/servizio a
regolamenti, standard e
convenzioni applicabili
riguardo all’efficienza
misura il grado di difficoltà nel
diagnosticare
malfunzionamenti
manutenibilità/
analizzabilità
supporto alla diagnosi
manutenibilità/
modificabilità
efficienza del ciclo di
modifica
misura il tempo medio
necessario a rimuovere un
malfunzionamento
manutenibilità/
stabilità
stabilità a seguito di
interventi
misura la percentuale di
interventi di modifica che
producono malfunzioni
manutenibilità/
testabilità
efficienza per i test
misura il tempo necessario
per verificare l’effettiva
rimozione di un
malfunzionamento
manutenibilità/
conformità alla
manutenibilità
conformità alla
manutenibilità
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
misura, formula e dati elementari
misura la conformità del
prodotto/servizio a
regolamenti, standard e
convenzioni applicabili
riguardo alla manutenibilità
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
X=1- A/B
A = Numero di elementi implementati
conformi riguardo all’efficienza
B = Numero totale di elementi per cui è
richiesta la conformità
X=A/B
A = Numero di malfunzionamenti che
possono essere diagnosticate con il
supporto delle funzioni di diagnosi
B = numero totale di malfunzionamenti
rilevati
Tempo medio: Tav = Somma (Tu) / N
Tu = tempo intercorrente tra la richiesta di
intervento ed il suo completamento
N = numero di interventi richiesti
X = Na / Ta
Na = Numero di interventi che hanno
prodotto malfunzioni
Ta = Tempo di erogazione durante il
periodo di osservazione successivo
all’intervento
X = Somma(T) / N
T = Tempo impiegate per assicurarsi
l’effettiva risoluzione di un
malfunzionamento
N = numero di malfunzionamenti risolti
X=1- A/B
A = Numero di elementi implementati
conformi riguardo alla manutenibilità
B = Numero totale di elementi per cui è
richiesta la conformità
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 74/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Metriche di misura della qualità – 4/4
caratteristica/
sottocaratt.
portabilità/
adattabilità
portabilità/
installabilità
nome della metrica
descrizione della metrica
misura, formula e dati elementari
facilità di porting del
software
facilità di installazione
misura la facilità di adattare il
software all’ambiente
misura la facilità di
installazione del software
all’ambiente operativo
portabilità/
coesistenza
Utilizzo concorrente con
altri sistemi
portabilità/
sostituibilità
continuità nell’uso dei
dati
misura il numero di
malfunzioni nell’unità di
tempo dovuti ad utilizzo
concorrente con altri sistemi
misura la quantità di dati che
è possibile usare passando
dal precedente software
senza effettuare interventi
portabilità/
conformità alla
portabilità
conformità alla
portabilità
efficacia
efficacia del task
T = Tempo speso dall’utente per adattare il
software all’ambiente
X=A/B
A = Numero di casi in cui l’utente riesce a
modificare le operazioni di installazione per
esigenze specifiche
B = Numero totale di casi in cui l’utente
tenta di modificare le operazioni di
installazione
X = A/T
A = numero di malfunzioni nel periodo T
T = periodo di utilizzo in concorrenza con
altri sistemi
X=A/B
A = numero di dati usati con il software da
sostituire che possono essere usati senza
interventi
B = numero di dati usati con il software da
sostituire che devono essere usati
X=1- A/B
A = Numero di elementi implementati
conformi riguardo alla portabilità
B = Numero totale di elementi per cui è
richiesta la conformità
M = 100-ΣAi
Ai = percentuale di obiettivo raggiunto
produttività
produttività economica
salvaguardia
salute e sicurezza
dell’utente
soddisfazione/
empatia
empatia
soddisfazione/
capacità di
rassicurazione
capacità di
rassicurazione
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
misura la conformità del
prodotto/servizio a
regolamenti, standard e
convenzioni applicabili
riguardo alla portabilità
misura la percentuale di
obiettivi del servizio/prodotto
raggiunti nel suo utilizzo
misura il rapporto tra costo di
utilizzo e riduzione del costo
per la svolgimento dei compiti
dell’utente
C = Cu/Cr
Cu = costo di utilizzo in un periodo di
tempo
Cr = Risparmio economico nello
svolgimento dei compiti dell’utente in
periodo di tempo
misura l’incidenza di problemi X = 1-A / B
di salute sugli utenti
A = numero di utenti che presentano
ripetuti sintomi di stanchezza, mal di testa,
ecc.
B = numero totale di utenti
misura la percezione
Uso di questionari e metodi assegnazione
dell’utente riguardo alla
del punteggio
disponibilità nel porre
attenzione individuale al alle
sue esigenze, di avere a
cuore i suoi principali
interessi, di dimostrare
impegno nel risolvere i
problemi, di informarlo su
quando sarà erogata la
prestazione
misura la percezione
Uso di questionari e metodi assegnazione
del punteggio
dell’utente capacità del
personale di ispirare fiducia,
di essere cortese, di
trasmettere sicurezza nelle
sue transazioni.
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 75/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
7. GLOSSARIO
Access Provider
Fornitore di accesso; qualsiasi organizzazione che, essendo collegata
direttamente a Internet, vende ad altri la possibilità di accedervi.
Accessibilità
Proprietà dei sistemi informatici di essere fruibili senza
discriminazioni.
ACD
(Automated Call Distributor); dispositivo che permette di smistare le
chiamate in arrivo, gestendone la priorità e monitorando i tempi di
attesa.
Addetti ICT
Addetti inquadrati in un profilo tecnico informatico che, in maniera
prevalente o esclusiva, svolgono attività proprie dell’ICT, nonché
addetti in possesso di qualifica tecnica informatica che esercitano
attività diverse. Comprende anche il numero di addetti non inquadrati
in un profilo tecnico che svolgono, di fatto, attività informatica a livello
professionale, indipendentemente dal possesso di una qualifica tecnica
informatica.
ADSL
(Asymmetric Digital Subscriber Line); protocollo di comunicazione
digitale per la trasmissione di informazioni multimediali ad alta
velocità ottenuta sfruttando per intero il flusso disponibile sul cavo
telefonico, ma privilegiando asimmetricamente la ricezione da parte
dell’utente.
AIPA
(Autorità per l’Informatica nella Pubblica Amministrazione); istituita
ai sensi del decreto legislativo 12 febbraio 1993, n. 39 e nel 2003
trasformata nel Centro Nazionale per l’Informatica nella Pubblica
Amministrazione (CNIPA).
Ambiente
elaborativo
Categoria di risorse informatiche integrate (elaboratori, software di
base, software middleware) utilizzabile con regole e comandi specifici e
noti.
Amministrazione
Generica amministrazione dello stato: Ministeri, Enti pubblici non
economici nazionali, Regioni, Enti locali.
Ampiezza di
banda
Differenza tra la frequenza più alta e quella più bassa utilizzabili nel
canale di trasmissione. Indica la quantità di dati che possono
transitarvi nell'unità di tempo. Usualmente è misurata in bit al
secondo (bps). Per esempio, l'ampiezza di banda di un comune modem è
di circa 15.000 bps, sufficiente per trasferire una intera pagina
dattiloscritta in 1 secondo. Per trasferire un filmato a pieno schermo e
a pieno movimento (full-motion full-screen) necessita invece una
ampiezza di banda di circa 10.000.000 bps.
Analogico
Forma d'onda o segnale continuo (come la voce umana). V. digitale
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 76/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
ANSI
(American National Standards Institute); ente americano, membro
dell’ISO (International Organization for Standardization),
responsabile dell'approvazione di standard in molte aree, compresi
computer e telecomunicazioni.
Antispamming:
Antivirus
API
v. spamming.
v. virus.
(Application Programming Interface): insieme di procedure disponibili
al programmatore per migliorarne la produttività.
Applet
Piccolo programma che può essere prelevato velocemente dalla rete e
usato da qualsiasi computer dotato di un browser capace di eseguire
codice Java.
Applicazione
Complesso di programmi software in grado di realizzare, in un
determinato ambiente elaborativo, funzioni informatiche che
soddisfano un insieme completo e coerente di esigenze di automazione.
Architettura
aperta
Architettura per cui esistono degli standard di pubblico dominio (non
proprietari) e a cui terze parti possono aderire per sviluppare prodotti.
Per esempio, l'architettura del linguaggio Java è aperta, quella di
ActiveX no (proprietà Microsoft).
Architettura
applicativa
Schema che descrive le applicazioni ed i legami tra esse in un
determinato contesto (ad esempio nell'ambito di un sistema
informatico).
Area
organizzativa
omogenea
Insieme di funzioni e di strutture, individuate dall’Amministrazione,
che opera su tematiche omogenee e che presenta esigenze di gestione
della documentazione in modo unitario e coordinato ai sensi
dell’articolo 2, comma 2, del D.P.R. n. 428/98. In particolare, ciascuna
AOO mette a disposizione delle unità organizzative clienti il servizio di
protocollazione dei documenti in entrata ed in uscita, utilizzando una
unica sequenza numerica, rinnovata ad ogni anno solare, propria alla
AOO stessa.
Arrotondamento
Procedimento mediante il quale si determinano le cifre significative di
un numero, o il valore considerato significativo, trasformandolo in un
altro numero, prossimo per eccesso o per difetto.
ASP
(Application Service Provider); qualunque fornitore che cede in uso a
terzi server e software applicativo.
Assicurazione
della qualità
(o garanzia della qualità); insieme di tutte le attività pianificate e
sistematiche, attuate nell'ambito del sistema qualità e di cui, per
quanto occorre, viene data dimostrazione, messe in atto per dare
adeguata confidenza che un'entità (processo, prodotto, organizzazione)
soddisferà i requisiti per la qualità.
ATM
(Asyncronous Transfer Mode); standard per la trasmissione di dati ad
alta velocità.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 77/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Autenticazione
Processo attraverso cui, in una comunicazione tra due parti (uomoelaboratore, elaboratore-elaboratore) una parte verifica la veridicità
dell’identità asserita dall’altra. L’autenticazione si basa in genere sulla
verifica di alcune proprietà che si conoscono essere possedute dalla
controparte. L'autenticazione è il mezzo attraverso cui il destinatario di
una transazione o di un messaggio può decidere se accettare o meno
tale transazione.
Autorizzazione
Operazione con cui un dominio di sicurezza decide se accettare o meno
la richiesta di attivazione di una determinata operazione informatica
proveniente da un messaggio o una transazione.
Bacino di utenza
Insieme degli utenti di un particolare servizio.
Backbone
All'interno di una rete, i tratti di linea con la più alta velocità. Il loro
insieme costituisce una sorta di "spina dorsale" destinata a sorreggere
la maggior parte del traffico, da cui il nome.
Back-up
Copia di riserva (di file, documenti, applicazioni, ecc.) su memorie di
massa quali hard-disk esterni, CD-ROM o CD-RW. Generalmente le
copie di backup vengono effettuate in automatico da specifiche
applicazioni, a scadenze periodiche.
Banda larga
Modalità di trasmissione “veloce” (almeno superiore ai 128 Kbps ) di
contenuti informativi digitalizzati.
Banner
Insegna; piccolo spazio pubblicitario realizzato inserendo su una pagina
web un annuncio concepito proponendo un link per attrarre verso un
sito dell'inserzionista, normalmente a scopo commerciale; è una delle
forme pubblicitarie più diffuse su Internet.
Base dati
Insieme di dati omogenei di interesse rilevante di una o più unità
organizzative, memorizzati in uno o più archivi informatici, organizzati
ed accessibili mediante uno strumento software (ad es. sistemi di
gestione di basi di dati, sistemi di information retrieval), la cui
dimensione è espressa usualmente in Gigabyte.
Baseline
Configurazione (di un documento, di un prodotto, di un contratto, ecc.)
formalmente stabilita ad un momento ben determinato, utilizzata come
riferimento per attività successive.
Baud
Nell'uso comune indica il numero bit che un modem è capace di
trasmettere o ricevere in un secondo (quindi coincide con bps).
Tecnicamente il baud è il numero di segnali discreti in un secondo; se
ogni segnale rappresenta un solo bit, baud e bps coincidono.
BBS
(Bulletin Board System); sistema di bacheca elettronica online. Un BBS
è un computer che utilizza programma server al quale gli utenti
possono collegarsi, usando un software di comunicazione, lasciando
propri messaggi e leggendo quelli di altri utenti.
Comportamento al meglio; Best Common Practice (BCP): documenti che
suggeriscono alcuni modi di comportamento/configurazione che non
rappresentano degli standard obbligatori, ma sono consigliati.
Best practice
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 78/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
BIP
(Base Informativa di Progetto); insieme di tutte le informazioni che
definiscono e caratterizzano un progetto, in riferimento all’intero ciclo
di vita, raccolte, gestite ed utilizzate dalla nascita al completamento..
Blog:
Termine nato dalla contrazione di Web e Log. Il Weblog è una pagina
web strutturata come un diario che raccoglie testi aperti ai commenti
dei lettori. Ogni nuovo intervento aggiunto ai precedenti.
Bookmark
Segnalibro; riferimento ad una pagina Web, di solito memorizzato in un
apposito elenco mantenuto dal browser. Costituisce un modo per
ricollegarsi velocemente ad una determinata pagina.
Bps
(Bits Per Second); unità di misura della velocità di trasferimento (v.
ampiezza di banda) in una trasmissione seriale. Per es., un modem da
28.800 bps è capace di spostare 28.800 bit al secondo.
Bridge
Ponte; dispositivo che inoltra il traffico tra segmenti di reti. V. gateway.
Browser
Programma che permette la visualizzazione delle pagine Web e
l'utilizzo dei servizi offerti dalla navigazione in rete.
Bus
Dispositivo che mette in comunicazione unità diverse, ad esempio la
CPU e la memoria o la memoria e una unità periferica.
Byte
Unità di misura (simbolo B) della quantità di informazione; è formato
da 8 bit e pertanto è in grado di rappresentare 28 = 256 informazioni
diverse.
I multipli sono conteggiati in potenze di due:
1 KiloByte (KB) = 210 Byte = 1024 Byte
1 MegaByte (MB) = 210 KiloByte = 1024*1024 Byte = 1.048.576 Byte
1 GigaByte (GB) = 210 MegaByte = 10243 Byte = 1.073.741.824 Byte
e via di seguito.
Meccanismo di memorizzazione ad alta velocità che può essere
costituito da una sezione riservata della memoria centrale o da un
dispositivo di memorizzazione indipendente. I tipi di caching
comunemente usati sono due: memory caching and disk caching. Nel
primo caso una porzione di memoria a più alta velocità (SRAM Static
RAM) viene utilizzata al posto della più lenta DRAM (Dynamic RAM)
per migliorare l’accesso a dati e istruzioni di più frequente uso. Nel
secondo caso si applica lo stesso principio spostando temporaneamente
il contenuto di porzioni di disco nella RAM.
Caching:
Call Center
Strumento di gestione del contatto con l’utente che utilizza il canale
telefonico. Gestisce nuove modalità di erogazione dei servizi, in
parallelo o in alternativa ai servizi erogati presso lo sportello fisico;
supporta il coordinamento dei processi di servizio tra front office e back
office. V. Help Desk.
Capacity planing
Attività di analisi e previsione sull’uso delle risorse dei sistemi gestiti
per proporre e pianificare le future necessità informatiche.
CBT
(Computer Based Training); termine generico che indica prodotti di
autoistruzione da fruire mediante computer.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 79/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Certificati
elettronici
Attestati elettronici che collegano i dati utilizzati per verificare le firme
elettroniche ai titolari e confermano l’identità dei titolari stessi
(D.Lgs.10/2002).
Certificati
qualificati
Certificati elettronici conformi ai requisiti di cui all’allegato I della
direttiva 1999/93/CE, rilasciati da certificatori che rispondono ai
requisiti fissati dall’allegato IL della medesima direttiva
(D.Lgs.10/2002).
Certificatore
Colui che presta servizi di certificazione delle firme elettroniche o che
fornisce altri servizi connessi alle firme elettroniche (D.Lgs.10/2002). È
certificatore autorizzato il certificatore abilitato inserito nell’elenco
pubblico dei certificatori, previsto dall’articolo 28, comma 6, del DPR 28
dicembre 2000, n. 445 e specificato nel DPCM 8 febbraio 1999,
mantenuto dal CNIPA.
Certificazione
Risultato della procedura informatica, applicata alla chiave pubblica e
rilevabile dai sistemi di validazione, mediante la quale si garantisce la
corrispondenza biunivoca tra chiave pubblica e soggetto titolare cui
essa appartiene, si identifica quest’ultimo e si attesta il periodo di
validità della predetta chiave ed il termine di scadenza del relativo
certificato, in ogni caso non superiore a tre anni (DPR 28/12/2000
n.445).
CGI
Centro di Gestione Interoperabilità della RUPA.
Change
management
Attività riguardante la pianificazione, l’attuazione e la verifica dei
cambiamenti dell’hardware, l’evoluzione dei sistemi operativi e dei
prodotti software di base, dei prodotti applicativi e delle relative
correzioni, necessari a garantire il corretto funzionamento dei sistemi.
Chat
Chiacchiera; forma di comunicazione in rete che consente di
comunicare con uno o più utenti attraverso computer.
Check list
Lista di controllo, usata per verificare le fasi di operazioni complesse.
Chiave
biometrica
Sequenza di codici informatici utilizzati nell’ambito di meccanismi di
sicurezza che impiegano metodi di verifica dell’identità personale
basati su specifiche caratteristiche fisiche dell’utente (DPR 28/12/2000
n.445).
Chiave privata
Elemento della coppia di chiavi asimmetriche, destinato ad essere
conosciuto soltanto dal soggetto titolare, mediante il quale si appone la
firma digitale sul documento informatico o si decifra il documento
informatico in precedenza cifrato mediante la corrispondente chiave
pubblica (DPR 28/12/2000 n.445).
Chiave pubblica
Elemento della coppia di chiavi asimmetriche destinato ad essere reso
pubblico, con il quale si verifica la firma digitale apposta sul documento
informatico dal titolare delle chiavi asimmetriche o si cifrano i
documenti informatici da trasmettere al titolare delle predette chiavi
(DPR 28/12/2000 n.445).
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 80/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Chiavi
asimmetriche
Coppia di chiavi crittografiche, una privata ed una pubblica, correlate
tra loro, da utilizzarsi nell’ambito dei sistemi di validazione o di
cifratura di documenti informatici (DPR 28/12/2000 n.445).
Chioschi
telematici
Elaboratori che forniscono informazioni e servizi al pubblico,
generalmente tramite un video display multimediale, distribuiti sul
territorio, anche presso altre Amministrazioni.
Ciclo di vita del
servizio
Insieme delle fasi che vanno dalla concezione e progettazione del
servizio alla sua realizzazione, messa in opera, manutenzione e
dismissione.
Classe di
fornitura
Categoria di prodotti / servizi che presentano caratteristiche omogenee
per finalità e per modalità di realizzazione e gestione.
Client
Programma usato per ottenere dati da un programma server residente
su un altro computer ovunque situato. Ogni programma client è
progettato per colloquiare solo con uno o più particolari tipi di
programmi server, ed ogni server richiede un determinato tipo di client.
Clustering
Tecnica di analisi dei dati volta alla selezione e raggruppamento di
elementi omogenei in un insieme di dati. Tutte le tecniche di clustering
si basano sul concetto di distanza tra due elementi.
La tecniche di clustering vengono utlizzate generalmente quando si
hanno tanti dati eterogenei e si è alla ricerca di elementi anomali.
CMS
(Content Management System); v.
CNIPA
Centro Nazionale per l’Informatica nella Pubblica Amministrazione;
istituito con le norme contenute nell’art. 176 del D. Lgs n. 196, 30/6/03.
Committente
Soggetto fisico o giuridico le cui esigenze sono oggetto della
realizzazione di un servizio.
Commutazione di
pacchetto
Tecnica di comunicazione in cui i pacchetti di dati sono smistati
attraverso i vari dispositivi della rete, permettendo l'uso della stessa
linea fisica da parte di diversi utilizzatori allo stesso tempo.
Compressione
Processo di ricodificazione dei dati in modo che occupino un numero
inferiore di byte. Vi sono tecniche distinte per la compressione di file, di
immagini, di audio, di filmati, ecc.
Comunicazione
Processo di trasferimento di informazioni (messaggio) da un punto
(emittente) ad un altro (ricevente) mediante l’uso di un codice
(linguaggio) e attraverso un mezzo (canale). Il processo di
comunicazione di dati digitali può essere totalmente o parzialmente
telematico.
Configurazione
Descrizione di un prodotto in termini di aggregato di entità/componenti
(elementi di configurazione).
Configurazione
corrente
Configurazione di base con le relative modifiche approvate.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 81/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Configurazione
di base
Configurazione di un prodotto, formalmente stabilita ad un momento
ben determinato, utilizzata come riferimento per attività successive. La
configurazione di base e le relative modifiche approvate costituiscono la
configurazione corrente.
Conformità
Soddisfacimento di requisiti specificati.
Consistenza del
campione
Percentuale di eventi sui quali vengono rilevate le misure, rispetto al
totale degli eventi su cui potrebbero essere rilevate.
Contact Center
Punto di accesso ad un insieme di funzioni di assistenza attraverso il
telefono e/o e-mail. Call center “evoluto” che integra, oltre a quello
telefonico, anche altri canali di comunicazione ed erogazione del
servizio. Gestisce simultaneamente l’insieme dei canali di contatto: lo
sportello fisico, la posta, il telefono, il fax, l’e- mail, il web, le
messaggerie su telefoni cellulari, etc. v. Call Center e Help Desk.
Contact Router
Sistemi di distribuzione intelligente delle chiamate.
Content filtering
Funzione di controllo sull’accettabilità dei contenuti in transito sulla
rete.
Content
Management
System
Sistema che gestisce lo sviluppo e la strutturazione dei contenuti su un
database su cui sono archiviati testi, audio, immagini, video.
Content security
Funzione che rileva e blocca i contenuti malevoli.
Contratto
Accordo tra due o più parti per costituire, regolare o estinguere un
rapporto giuridico patrimoniale, suscettibile di essere valutato in
termini economici.
Controllo della
qualità
Tecniche e attività a carattere operativo messe in atto per soddisfare i
requisiti della qualità.
Courseware
Termine usato per indicare i contenuti didattici erogati in un corso di
autoistruzione (CBT o WBT).
Criterio di
attivazione di un
servizio
Condizione o evento che stabilisce l’inizio temporale della esecuzione
del servizio.
Criterio di
chiusura di un
servizio
Condizione o evento che stabilisce la conclusione temporale della
esecuzione del servizio.
Criterio di
misura
Regola che si applica nel rilevare le misure.
Crittografia
Tecnica matematica con cui i dati vengono manipolati allo scopo di
impedire a chiunque, tranne al destinatario, di leggerli.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 82/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
CRM
(Customer Relationship Management); approccio per la gestione
complessiva e integrata della relazione con il cliente (utente del
servizio). Insieme di metodologie di gestione dei processi e delle attività
inerenti il governo della relazione con il cliente, dalla fase di
individuazione e segmentazione, all’acquisizione, alla fidelizzazione,
fino allo sviluppo di soluzioni durature di lungo periodo. Nel settore
pubblico si parla di Citizen Relationship Management.
CSS
(Cascading Style Sheets); modelli di stile di documento che permettono
di specificare effetti speciali da applicare al testo, che verrà poi
interpretato dal Browser.
CTI
(Computer Telephony Integration); integrazione tra i sistemi telefonici
e l’hardware e il software dei computer.
Database
Data Warehouse
v. Base Dati
Magazzino di dati; secondo alcuni autori il DW è semplicemente un
sinonimo di database fisico (relazionale o multidimensionale) che
contiene dati; secondo altri il DW può essere definito come una raccolta
di dati integrata.
Dato
Rappresentazione di un fenomeno della realtà di interesse in un
formato codificato, in modo tale da essere memorizzabile ed elaborabile
mediante sistemi informativi.
Dato elementare
Dato che rappresenta un aspetto della realtà di interesse non
ulteriormente scomponibile.
Dato pubblico
Dato detenuto da soggetti pubblici perché raccolto o utilizzato da
soggetti pubblici, nell’ambito dei propri fini istituzionali.
Dato sensibile
Dato personale idoneo a rivelare l’origine razziale ed etnica, le
convinzioni religiose, filosofiche o di altro genere, le opinioni politiche,
l’adesione a partiti, sindacati, associazioni o organizzazioni a carattere
religioso, filosofico, politico o sindacale, nonché a rivelare lo stato di
salute e la vita sessuale.
DB
(Data Base); v. Base Dati.
Decompressione
Processo per riottenere i dati originari a partire da quelli in precedenza
compressi.
Default
Valore predefinito, impostato automaticamente dal sistema, a meno
che non venga specificato esplicitamente un altro valore.
Deliverable
Elemento di fornitura; elemento che può essere oggetto di verifica,
validazione e accettazione da parte della Stazione Appaltante nel corso
dell’esecuzione del contratto di fornitura.
Dial-up
Connessione temporanea tra due macchine, stabilita attraverso una
normale linea telefonica.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 83/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Digitale
Contrapposto ad analogico, indica la rappresentazione di un segnale
utilizzando esclusivamente due simboli (0 e 1). Praticamente tutti i
segnali analogici (continui) possono essere rappresentati in formato
digitale (discreto). V. analogico
Dipartimentali
Elaboratori di fascia media, generalmente utilizzati come nodo
elaborativo autonomo o nell’ambito di un’architettura client/server.
Disaster
recovery
Recupero; procedura di ripristino dell’informazione andata distrutta.
DNS
(Domain Name System); sistema di denominazione del dominio.
Database che contiene una lista di indirizzi IP, strutturato in maniera
gerarchica e consistente in domini, sottodomini, siti e host. I nomi
hanno la forma user @ host.site.subdomain.domain
Docente
o Tutor o Mentor; persona che assicura l’erogazione del servizio
formativo nel rispetto del programma previsto, cura le esercitazioni
pratiche e i casi di studio ed assiste i partecipanti in azioni di recupero
e approfondimento.
Documento
d’identità
elettronico
Documento analogo alla carta d’identità elettronica rilasciato dal
comune fino al compimento del quindicesimo anno di età (DPR
28/12/2000 n.445).
Documento
informatico
Rappresentazione informatica di atti, fatti o dati giuridicamente
rilevanti (DPR 28/12/2000 n.445).
Dominio
Parte di indirizzo Internet che viene dopo il simbolo @ e serve per
l’organizzazione e la rintracciabilità degli indirizzi stessi. V. Nome di
dominio
Dominio di posta
elettronica
certificata
Corrisponde ad un dominio DNS dedicato alle caselle di posta
elettronica degli utenti di posta elettronica certificata.
Dominio e
sottodominio
Si definisce il dominio come "l'insieme delle risorse (in particolare le
procedure, i dati e i servizi) e delle politiche di una determinata
organizzazione". Il dominio è anche il confine di responsabilità di
un'organizzazione, in particolare per quanto riguarda le politiche che
definiscono il suo sistema informativo. Il Dominio di una
Amministrazione può eventualmente essere scomposto in più
"Sottodomini". Detti Sottodomini presentano tipicamente due valenze,
una funzionale e una territoriale.
Download
Scaricare; effettuare il download di un file significa scaricarlo per
esempio da un server al computer dell’utente.
DSN
(Delivery Status Notification); funzionalità di notariato nei sistemi di
posta elettronica.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 84/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
ECTF
(Enterprise Computer Telephony Forum): associazione internazionale
che promuove l’interoperabilità di prodotti e servizi di comunicazione
coordinando lo sviluppo di standard industriali a tale scopo.
EFF
(Electronic Frontier Foundation); organizzazione costituita per studiare
l'impatto sociale del crescente uso di strumenti informatici per
comunicare e trasferire informazioni.
eGif
(eGoverment Interoperability Framework); insieme di politiche e
standard raccomandati per l’interoperabilità dei sistemi IT pubblici.
E-learning
Utilizzo delle nuove tecnologie multimediali e di Internet per
migliorare la qualità dell’apprendimento agevolando l’accesso a risorse
e servizi nonché gli scambi e la collaborazione a distanza (CEC 2001:2).
Metodologia didattica che offre la possibilità di erogare contenuti
formativi elettronicamente attraverso Internet o reti Intranet.
Elemento di
configurazione
Entità all’interno di una configurazione che può essere univocamente
identificata ad un dato punto di riferimento e trattata come una singola
entità nel processo di gestione della configurazione.
E-mail
(Electronic Mail); trasmissione elettronica di messaggi, che possono
includere testo e allegati, da un computer ad un altro collocato
all'esterno o all’interno dell'organizzazione.
Enti locali
Enti la cui sfera di competenza è circoscritta territorialmente e che
perseguono fini delimitati settorialmente. Ne fanno parte, ad esempio,
le Camere di commercio, industria e artigianato, gli Istituti autonomi
per le case popolari, le Aziende di promozione turistica, i Consorzi di
bonifica, gli Enti porto, i Parchi nazionali.
Enti
previdenziali
Enti pubblici che gestiscono forme obbligatorie di previdenza e
assistenza. Rientrano in questa classe, ad esempio, Inps, Inail, Inpdai,
Enpals, ecc.
E-procurement
Servizio attivato dal portale degli Acquisti in rete della Pubblica
amministrazione realizzato dal Ministero dell'economia e delle finanze
(http: //www.acquistinretepa.it); si tratta di acquisti,
approvvigionamenti elettronici effettuati attraverso bandi di gara e
aste on-line; la nuova disciplina introdotta dall’art. 26 della Legge n.
488 del 1999 permette di attivare un’asta telematica permanente ove si
possono incontrare offerta e domanda, in tempo reale, garantendo
sempre all’amministrazione le migliori condizioni di mercato. Anche la
pubblicazione dei bandi di gara può avvenire in via telematica.
ERP
(Enterprise Resource Planning); Pianificazione delle Risorse della
Organizzazione; sistemi costituiti da un insieme di applicazioni
informatiche in grado di gestire i processi aziendali di tipo
amministrativo, produttivo e finanziario, basandosi su una base di dati
unica e sul concetto di integrità del dato.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 85/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
ESMTP/MIME
(Enhanced Simple Mail Transfer Protocol / Multipurpose Internet Mail
Extension); Estensione Multiuso di Posta Internet; protocollo che
permette il trasferimento di file binari (immagini, audio, fax, ecc.)
senza doverli convertire in file di testo come accade per il protocollo
SMTP.
Ethernet
Standard molto diffuso per connettere computer in una LAN. Ethernet
permette una ampiezza di banda di circa 10 Mbps e può essere usata su
molti tipi di computer.
Eudora
Programma client di posta elettronica molto diffuso in ambiente
Macintosh e Windows. Consente a chiunque con un account POP di
ricevere e mandare messaggi elettronici via Internet. Inoltre, consente
di trasferire anche file binari.
Evidenza
oggettiva
Informazione la cui veridicità può essere dimostrata sulla base di fatti
acquisiti a seguito di osservazioni, misurazioni, prove od altri mezzi.
Extranet
Estensione della rete Intranet interna, da una realtà locale ad una
realtà aperta anche alla stessa Internet, pur rimanendo nella stessa
organizzazione (Amministrazioni con più sedi distribuite sul territorio).
FaD
Formazione a Distanza, generalmente suddivisa in tre "generazioni";
prima generazione, costituita dai corsi per corrispondenza; seconda
generazione (sistemi CBT), basata su sussidi multimediali come
videocassette e CD-ROM; terza generazione (e-learning), basata sulla
Rete (sistemi WBT).
FAQ
(Frequently Asked Question); lista di domande (e relative risposte)
fatte di frequente su un determinato argomento, generalmente raccolta
in apposite pagine web.
Fibra ottica
Sottili filamenti di vetro o plastica che trasportano un segnale luminoso
generato da un laser. Generalmente sono più costosi di altri supporti,
ma consentono di raggiungere altissime velocità di trasmissione.
File transfer
Processo di copiatura di un file da un computer ad un altro.
File Transfer
Protocol
V. FTP.
Finestra
temporale di
erogazione
Periodo di tempo sul quale viene calcolato il livello di servizio.
Firewall
Muro di fuoco; combinazione di hardware e software progettata per
impedire accessi non autorizzati a (e da) reti private. Il suo utilizzo
tipico è quello di impedire agli utenti provenienti da Internet l'accesso
non autorizzato ad una Intranet. Un firewall può fornire anche altri
servizi quali autenticazione dell'utente e traduzione di indirizzi.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 86/117
CNIPA
Firma digitale
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Informazione aggiunta a un documento informatico per garantirne
integrità e provenienza. Risultato della procedura informatica
(validazione) basata su un sistema di chiavi asimmetriche a coppia,
una pubblica e una privata, che consente al sottoscrittore tramite la
chiave privata e al destinatario tramite la chiave pubblica,
rispettivamente, di rendere manifesta e di verificare la provenienza e
l’integrità di un documento informatico o di un insieme di documenti
informatici (DPR 28/12/2000 n.445).
Firma elettronica Insieme dei dati in forma elettronica, allegati oppure connessi tramite
associazione logica ad altri dati elettronici, utilizzati come metodo di
autenticazione informatica; (D.Lgs.10/2002).
Firma elettronica Firma elettronica ottenuta attraverso una procedura informatica che
garantisce la connessione univoca al firmatario e la sua univoca
avanzata
identificazione, creata con mezzi sui quali il firmatario può conservare
un controllo esclusivo e collegata ai dati ai quali si riferisce in modo da
consentire di rilevare se i dati stessi siano stati successivamente
modificati (D.Lgs.10/2002).
Fornitura
Istanza della classe di fornitura vista nello specifico contratto (di
fornitura); un contratto può comprendere più classi di fornitura e, per
ognuna, più forniture. Le modalità di acquisizione e di verifica della
qualità possono variare in funzione delle specificità di ogni singola
fornitura e sono significativamente influenzate, tra l’altro, dalla
organizzazione e dalle modalità di acquisizione adottate.
Fornitura
Risultato di un’attività o di un insieme di attività correlate (processi).
Può coincidere con un prodotto software, con un sistema, con un
servizio, con materiali hardware, con un documento.
Forum
Ambienti virtuali all’interno dei quali gli utenti possono discutere di
argomenti di interesse comune. Simili ai blog (v.) ma gli interventi si
suddividono per argomento e generalmente manca il calendario per
rivisitare vecchi interventi. Blog e forum sono particolari Content
Management System (CMS).
Frame Relay
Protocollo di comunicazione per reti geografiche che su suddivide i dati
da inviare in strutture di lunghezza variabile, allocando ampiezza di
banda a richiesta..
Freeware
Modalità di distribuzione del software. L'autore mette a disposizione
gratuitamente il programma non richiedendo alcun compenso per il suo
utilizzo, ma limitandone i diritti di sfruttamento commerciale. V.
Pubblico dominio e Shareware.
FTP
(File Transfer Protocol); protocollo di trasferimento file in Internet.
Full Duplex
Circuito o dispositivo capace di trasmettere in entrambe le direzione
nello stesso tempo (per es. come nelle normali conversazioni
telefoniche). V. Simplex e Half Duplex.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 87/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Gateway
Qualsiasi strumento hardware o software che effettua conversioni tra
protocolli diversi. In senso lato, il termine gateway viene usato per
qualsiasi meccanismo che consente l'accesso ad un altro sistema.
Ultimamente, si preferisce usare il termine router anzichè gateway.
GCA
Gestione controllo accessi.
Gestione dei
documenti
Insieme delle attività finalizzate alla registrazione di protocollo e alla
classificazione, organizzazione, assegnazione e reperimento dei
documenti amministrativi formati o acquisiti dalle Amministrazioni,
nell’ambito del sistema di classificazione d’archivio adottato; essa è
effettuata mediante sistemi informativi automatizzati. (DPR
28/12/2000 n.445).
Gestione per la
qualità
Insieme delle attività di gestione che determinano la politica per la
qualità, gli obiettivi e le responsabilità, e li traducono in pratica,
nell'ambito del sistema qualità, con mezzi quali la pianificazione della
qualità, il controllo della qualità, l'assicurazione della qualità, e il
miglioramento della qualità.
GSF
Gestione della sicurezza fisica.
GSI
Gestione della Sicurezza Infrastrutturale.
GUI
(Graphical User Interface); termine con cui si indicano ambienti grafici
a finestre (quali Windows, OS/2, MacIntosh o XWindows) che
consentono agli utenti di interagire con programmi sofisticati tramite
icone, bottoni, tastiera e mouse.
Half Duplex
Circuito o dispositivo capace di trasmettere in entrambe le direzioni,
ma non allo stesso tempo. V. Full Duplex, Simplex.
HDSL
(High-data-rate DSL); tecnologie trasmissive analoghe ad ADSL ma
con distanza inferiore ai 10 Km.
HDU
(Hard Disk Unit); disco rigido, disco fisso (memoria di massa, memoria
secondaria).
Help desk
Centro assistenza (call center) che fornisce supporto tecnico. L'help
desk (tramite telefono, fax, e-mail) può aiutare l'utente nel corretto
utilizzo di un prodotto, oppure nel consigliare il centro di riparazione
più vicino.
Home page
Pagina base; viene intesa in due significati diversi: 1) la pagina Web
visualizzata come primo documento all'avvio di un browser; 2) la
pagina principale di un sito Web.
Host
Termine generico che identifica un computer connesso ad una rete (p.e.
LAN, Internet, Intranet) e che funge da contenitore di servizi
disponibili per altri computer.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 88/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Hosting
Forma di esternalizzazione in cui il fornitore, utilizzando le proprie
infrastrutture e le proprie piattaforme, eroga servizi personalizzati per
conto del cliente, ma non necessariamente fornisce anche i prodotti per
la fruizione dei servizi.
Housing
Forma di esternalizzazione in cui il fornitore ospita e gestisce presso
proprie infrastrutture gli apparati del cliente necessari all’erogazione
del servizio per conto del cliente. Il fornitore provvede alla connettività,
alla rete e ai servizi a valore aggiunto quali: il monitoraggio 24x7, la
sicurezza (firewall), il backup, la gestione dei malfunzionamenti su
richiesta del cliente, la consulenza. I servizi di consulenza sono
generalmente fatturati ad un canone fisso mensile basato su un
insieme predefinito di ore di supporto.
HTML
(Hyper Text Markup Language); linguaggio di marcatura ipertestuale
per la costruzione di pagine o documenti ipertestuali del World Wide
Web.
HTTP
(Hyper Text Transfer Protocol); protocollo per il trasferimento di pagine
ipertestuali e risorse nel World Wide Web.
HTTPS
(Secure HTTP); estensione del protocollo HTTP per effettuare
transazioni sicure, con dati crittografati e autenticazione del mittente.
Hyperlink
V. Rimando, Hypertext e Ipertesto.
Hz
(Hertz); unità di misura della frequenza (o della ampiezza di banda).
Sinonimo di cicli/secondo.
IAB
(Internet Architecture Board); organizzazione tecnica che supervisiona
l'intera suite di protocolli di Internet. È costituita da due "task force":
IETF e IRTF.
ICT
(Information and Communication Technology); specifica di Information
Technology (IT) che enfatizza l'aspetto delle comunicazioni nell'IT.
IDS
(Intrusion Detection System); funzionalità di monitoraggio delle
attività sospette sulla rete.
IEEE
(Institute of Electrical and Electronic Engineers); organizzazione
internazionale, membro ISO, con il ruolo di definire standard.
IEEE 802
Insieme di standard IEEE dedicato ai protocolli per le LAN.
IETF
(Internet Engineering Task Force); comunità di progettisti di rete,
operatori, produttori e ricercatori il cui fine è quello di coordinare la
gestione e l'evoluzione di Internet. È la maggiore fonte di proposte di
protocolli standard, che sono sottomettessi allo IAB per l'approvazione
finale.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 89/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
IMAP
(Internet Message Access Protocol); standard per la posta elettronica,
permette l'accesso ad un server mail e di manipolare i messaggi come
se si stesse lavorando in locale senza bisogno di scaricare i file. Questo
tipo di accesso offre maggiore elasticità rispetto al POP3 (Post Office
Protocol 3).
IMS
(Instructional Management Systems); progetto per la
standardizzazione della formazione online e offline e in particolare per
la definizione delle specifiche riguardanti l’e-learning.
Indicatore di
qualità
Parametro (numerico) che descrive in termini quantitativi la metrica
(una metrica può essere costituita da più indicatori). Ad un indicatore
sono associati obiettivi / valori soglia che definiscono i livelli di servizio.
Indicatore di qualità e misura sono considerati sinonimi.
Indice delle P.A.
Indice delle Pubbliche Amministrazioni istituito dal DPCM 31/10/2000
presso il Centro Tecnico (ora CNIPA), accessibile per via telematica
(http://indicepa.gov.it). Consente alle singole amministrazioni il
reperimento delle informazioni associate ad un documento informatico
protocollato e trasmesso per via telematica.
Indirizzo
elettronico
Identificatore di una risorsa fisica o logica in grado di ricevere e
registrare documenti informatici (DPR 28/12/2000 n.445).
Indirizzo E-mail
Indirizzo di posta elettronica di un utente; ha la forma nome@dominio
dove nome solitamente coincide con lo userid dell'utente e dominio ha
la forma di un nome di dominio.
Indirizzo IP
Numero di identificazione associato a ogni singolo computer connesso a
Internet.
Internet
Rete globale che consente la connessione di diversi tipi di reti e lo
scambio di informazioni tra gli utenti, indipendentemente dal computer
o dalle reti utilizzate.
Internet
Provider
Fornitore di Internet; azienda o istituzione che fornisce “connettività”
ovvero il collegamento alla rete Internet.
Interoperabilità
Capacità di operare in cooperazione soprattutto per quanto riguarda lo
scambio di dati.
Intranet
Rete privata basata sulle stesse tecnologie di Internet, ma ristretta ad
un determinato gruppo, ad esempio tutti i dipendenti di una
Amministrazione, protetta da firewall (v.) e non accessibile, o solo
parzialmente visibile, all’esterno.
IP
(Internet Protocol); protocollo di comunicazione su Internet.
IP Telephony
Servizi integrati fonia/dati.
Ipertesto
Qualsiasi testo che contiene rimandi ad altri documenti.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 90/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
IPSEC
(IPSecurity); insieme di protocolli per la sicurezza sviluppati dallo
IETF.
IRC
(Internet Relay Chat); sistema di comunicazione che permette agli
utenti di conversare e trasferire programmi in tempo reale attraverso
Internet.
IRTF
(Internet Research Task Force); una delle due task force della IAB che
si occupa della definizione di standard per Internet di lungo periodo e
di altri aspetti teorici.
ISBN
(International Standard Book Numbering); standard internazionale per
la numerazione dei libri.
ISDN
(Integrated Services Digital Network); rete digitale a servizi integrati,
per le comunicazioni di voce e dati in maniera integrata e in formato
digitale attraverso il cavo telefonico, a una velocità di trasmissione
superiore a quella di una linea analogica.
ISO
(International Standards Organization); organizzazione responsabile
della creazione di standard internazionali in varie aree, compresi
computer e telecomunicazioni. I suoi membri sono le organizzazioni che
definiscono gli standard a livello nazionale.
ISOC
(Internet Society); organizzazione non a fini di lucro che facilita ed
assiste l'evoluzione tecnica di Internet, promuovendo lo sviluppo di
nuove applicazioni.
ISP
(Internet Service Provider): fornitore di servizi Internet; qualunque
soggetto che fornisce servizi di connettività a Internet, sia a titolo
gratuito che a pagamento.
ITSEC
(Information Technology Security Evaluation Criteria).
IVR
(Interactive Voice Response); sistemi di risposta automatica.
JAVA
Linguaggio di programmazione sviluppato da Sun Microsystems,
specificatamente progettato per la scrittura di programmi che possono
essere scaricati sul proprio computer dalla rete ed immediatamente
eseguiti. Utilizzando piccoli programmi Java (chiamati Applets), le
pagine Web possono includere animazioni, effettuare calcoli e
quant'altro.
JPEG
(Joint Photographic Expert Group); standard per la compressione di
immagini fotografiche, dal nome del gruppo che lo ha proposto. È
possibile raggiungere rapporti di compressione elevatissimi, al costo
dell'introduzione di leggere distorsioni nell'immagine.
Know-how
Possesso di specifiche cognizioni che consentono di svolgere in modo
ottimale un’attività.
LAN
(Local Area Network); rete che utilizza un protocollo diverso da TCP/IP;
è una rete che connette computer all’interno di uno stesso edificio.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 91/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
LDAP
(Lightweight Directory Access Protocol); protocollo di rete utilizzato dai
server di posta elettronica per gestire le liste degli utenti e gli indirizzi
di posta elettronica dei server per ottenere una "mappa" generale degli
utenti.
Legacy
Eredità; sistemi pre-esistenti ereditati dal passato, ancora utili, che
necessitano in genere di re-ingegnerizzazioni o di interventi
manutentivi per eliminare il degrado.
Leverage
v. Scalabilità.
Link
Collegamento; nei sistemi ipertestuali un link è un segno di
interconnessione tra elementi sorgente ed elementi destinazione. Un
link su un testo, su un'immagine o su qualsiasi oggetto multimediale
richiama un'altro elemento. (v. rimando).
Livello di
servizio
Misura che rappresenta il grado con il quale determinate
caratteristiche di un servizio soddisfano i requisiti del committente.
Load balancing
Bilanciamento del carico; funzionalità per l'ottimizzazione delle risorse
di calcolo che migliora le performance dei servizi forniti.
Termine che identifica un file in cui si tengono registrate le attività
compiute da un computer o da un’applicazione.
Log
Login
Azione di collegarsi ad un sistema informatico. Tipicamente consiste
nell'immettere il proprio userid (non segreto) e la propria password
(segreta).
Look & Feel.
Termine che si riferisce all’aspetto generale e all’operatività di
un’interfaccia utente.
(Media Access Control): indirizzo o identificativo univoco di un
elemento di una rete o di un messaggio.
MAC
Macromedia
Linguaggio di programmazione di Director di Macromedia tramite il
quale è possibile creare applicazioni multimediali molto evolute.
Mailbox
Casella postale di un utente (ospitata generalmente su un server) nella
quale vengono conservati temporaneamente i messaggi prima di essere
scaricati sul computer dell’utente stesso dal programma client di posta
elettronica.
Mailing list
Sistema (solitamente automatizzato) che, ricevuto un messaggio e-mail
da un utente, lo invia a tutti i componenti registrati di una lista.
Mainframe
Elaboratore centrale caratterizzato da molteplicità di utenza, elevata
capacità elaborativa (espressa usualmente in milioni di istruzioni per
secondo -Mips).e possibilità di trattare ingenti quantità di dati.
MAN
(Metropolitan Area Network); rete di calcolatori che serve un'area
estesa approssimativamente quanto una città. Tipicamente, tali reti
sono realizzate tramite fibre ottiche.
Manuale della
qualità
Documento che enuncia la politica per la qualità e descrive il sistema
qualità di una organizzazione.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 92/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Manuale di
gestione
Documento che descrive il sistema di gestione e conservazione di
documenti di una AOO (D.P.C.M. 31 ottobre 2000, articolo 5).
Manutenzione
del software
Insieme degli interventi su applicazioni esistenti, volti a garantire la
piena funzionalità del software applicativo. Si suddivide in:
manutenzione correttiva, volta alla rimozione di errori e
malfunzionamenti; manutenzione adattativa, volta all'impiego di nuove
versioni del software di ambiente (linguaggi DBMS, sistemi
operativi...); manutenzione migliorativa, relativa a modifiche
effettuate, dopo il rilascio in produzione, per migliorare l'applicazione.
MByte
v. Byte
MDN
(Message Delivery Notification); funzionalità di notariato nei sistemi di
posta elettronica.
Memoria di
massa
Dispositivi di memorizzazione collegati a mainframe e computer
dipartimentali in esercizio, costituiti prevalentemente da dischi
magnetici e dotati di capacità dell’ordine dei Gigabyte (GB).
Mentoring
Vedi Tutoraggio.
Metadati
Base informativa addizionale che arricchisce i dati contenuti nel data
warehouse e chiamati in gergo “data about data” coioè dati relativi ai
dati.
Metrica
Termine collettivo usato per indicare (uno o) più indicatori (omogenei)
di qualità. Una metrica può articolarsi su più indicatori (misure). Ad
una metrica non sono direttamente associati obiettivi o valori soglia.
Una metrica fa generalmente riferimento alle caratteristiche e
sottocaratteristiche di qualità definite dalla ISO.
Middleware
Software che si interpone tra due applicazioni e permette il passaggio
dei dati. Un esempio di middleware è il programma che estrae
informazioni da un database e genera pagine web dinamicamente dopo
aver letto la richiesta fatta dall’utente.
MIME
(Multipurpose Internet Mail Extension): standard per allegare file
binari (grafici, audio, ecc.) ai messaggi e-mail.
Mirroring
Mirror, specchio. Effettuare lo specchio di un sito web significa
riprodurne una copia e riproporla su uno o più domini diversi
dall'originale (sito ufficiale), per permettere ai navigatori alternative di
accesso. In questo modo più copie del sito, distribuite in Internet,
riducono i rischi di congestione, alleggeriscono il carico di lavoro dei
server web e di conseguenza permettono accessi più veloci.
Misura
Processo che porta alla determinazione di un valore numerico che
rappresenta il comportamento di una o più componenti di un servizio,
sotto determinate condizioni, rispetto a dei requisiti fissati.
MMS
(Multimedia Message Service): messaggistica per la telefonia cellulare,
predisposta per l'invio di immagini, audio e video.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 93/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Modalità di
accesso al
servizio
Modalità con cui un utente ha la possibilità di fruire del servizio. Ad
esempio, per un servizio di assistenza, una telefonata al servizio di help
desk, o l'invio di una e-mail alla casella di posta appropriata.
Modalità di
raccolta delle
misure
Caratteristiche del processo di misura relative a strumenti, tecniche di
campionamento e criteri di arrotondamento.
Modalità di
rappresentazione
delle misure
Metodo per visualizzare ed interpretare le misure rilevate, ai fini della
rendicontazione.
Modalità di
rendicontazione
Modalità con cui il fornitore del servizio documenta al committente
l’andamento del servizio.
Modem
Dispositivo che modula i segnali digitali uscenti da un computer o da
altro dispositivo digitale in segnali analogici per una linea telefonica
convenzionale e rimodula il segnale analogico ricevuto in risposta e lo
converte in segnale digitale per il dispositivo digitale.
MPEG
(Moving Pictures Experts Group); formato di file per la memorizzazione
di filmati che consente elevati livelli di compressione. Per poter
visualizzare il filmato viene richiesta un’apposita scheda MPEG o un
processore molto potente con un apposito programma (player MPEG).
MPLS
(Multiprotocol Label Switching): iniziativa IETF per integrare a livello
IP varie informazioni tecniche (ampiezza di banda, ecc.) relative e tratti
di rete, per dare agli operatori maggiore flessibilità nella gestione dei
problemi di traffico.
MTA
(Message Tranfer Agent); programma responsabile di ricevere le e-mail
e distribuirle ai destinatari.
MTBF
(Mean Time Between Failure); tempo medio tra due guasti successivi; è
una misura di affidabilità di un prodotto, abitualmente espressa in ore.
Nodo
Ogni singolo calcolatore connesso in una rete.
Nome di dominio
Identificativo univoco di un computer connesso su Internet. I nomi di
dominio hanno sempre 2 o più parti, separate da un punto. La parte
più a sinistra è quella più specifica e quella a destra è quella più
generale e costituisce il dominio vero e proprio.
Non conformità
Non soddisfacimento di requisiti specificati.
Normalizzazione
Procedimento o metodo convenzionale utilizzato per associare ad un
indicatore una grandezza o una quantità di riferimento a prescindere
da quella effettivamente in servizio. Vanno fornite le regole per passare
dal valore non normalizzato a quello normalizzato.
Normativa ISO
Normativa emessa dall’International Organiziation for Standardization
(ISO).
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 94/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
NTP
(Network Time Protocol); servizio automatico di sincronizzazione del
tempo ufficiale di rete da una fonte attendibile.
Obiettivo del
servizio
Fine per il quale il servizio è realizzato ed erogato, sempre legato ad
una specifica esigenza del committente.
On site
Attività svolta presso il Cliente secondo due possibili modalità: 1)
gestita dal Cliente: in questo caso il fornitore provvede esclusivamente
a fornire le apparecchiature richieste; 2) gestita dal Provider: in questo
caso il fornitore assicura al cliente la fornitura della soluzione così
come disegnata da un’apposita progettazione e provvede alla sua
gestione on site e/o in remoto.
Open
architecture
V. Architettura aperta.
Open-source
Categoria di licenze d'uso volte a permettere la diffusione delle
conoscenze, invece di fornire restrizioni per il loro uso
(www.opensource.org). Le licenze che ricadono sotto questa definizione
devono rendere disponibile il codice sorgente del software a tutti coloro
che lo usano, e devono rendere possibile la sua ridistribuzione, la sua
modifica e la ridistribuzione delle modifiche stesse. La licenza, inoltre,
non deve contenere limitazioni sulle categorie di persone che ne
possono trarre vantaggio, né porre restrizioni sul tipo di software che
può essere distribuito insieme a quello in questione.
OSI
(Open Systems Interconnection); modello di riferimento che definisce
gli standard della comunicazione tra computer. È costituito da una
struttura a 7 livelli che descrive le architetture di rete e come i dati
vengono scambiati.
Outsourcing
Affidamento all’esterno di tutto o parte di un’attività di servizio.
PABX
(Private Automatic Branch Exchange): centrale telefonica privata che
adotta una specifica numerazione per i telefoni interni, di solito
raggiungibile anche come derivazione dalla linea telefonica pubblica.
Pacchetto
La più piccola unità di dati inviata attraverso una rete.
Pacchetto
applicativo
Software acquistato in forma standard o personalizzabile, anche a cura
dell’utente, che integra funzioni relative a un’attività specifica o a un
insieme integrato di attività.
Packet Switching
V. Commutazione di pacchetto.
Pagina
Termine generico per indicare una certa quantità di dati visualizzati
sullo schermo. Su Internet, il termine pagina è associato
principalmente al WWWeb e coincide con un documento HTML. Può
contenere testo, immagini e qualsiasi altro oggetto. Il WWW può essere
visto come l'insieme di tutte le pagine di tutto il mondo.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 95/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Password
Parola d’ordine; misura di sicurezza impiegata per limitare l’accesso a
sistemi informatici o a file riservati. Le parole d'ordine sono stringhe di
caratteri alfanumerici che consentono di verificare l’identificazione di
chi è autorizzato ad accedere ad un sistema protetto.
Patrimonio
applicativo
Software applicativo complessivamente sviluppato, espresso in migliaia
di linee di codice (Kloc). Per linea di codice si intende l’istruzione
elementare di un linguaggio di programmazione.
Patrimonio
informatico
Insieme di tecnologie, applicazioni informatiche e basi di dati.
PDF
(Portable Document Format); formato di file della Adobe Systems, per
la visualizzazione e la stampa di documenti contenenti testo e
immagini.
PDL
V. Postazione di Lavoro.
Peer-to-peer
A differenza del modello client-server, nel modello peer-to-peer ogni
nodo della rete può svolgere sia funzioni di client che funzioni di server.
Penale
Sanzione applicabile da un committente di un servizio al fornitore, nel
caso in cui il servizio non venga erogato conformemente ai requisiti.
Porta usualmente ad una riduzione del compenso pattuito con il
fornitore.
Periodicità della
rendicontazione
Intervallo temporale di erogazione del servizio coperto da un rapporto
di consuntivo sull'andamento del servizio predisposto dal fornitore.
Periodo di
osservazione
Periodo temporale contrattuale nel quale il livello di servizio viene
verificato (può corrispondere all'intero periodo nel quale il servizio deve
essere erogato o ad una parte di tale periodo).
Personal
computer
Stazione di lavoro intelligente di utilizzo individuale, operante
autonomamente, o in emulazione di terminale di altri sistemi o
collegata in rete.
Phase Out
Tempo in cui termina la garanzia dell’assistenza, da parte delle case
costruttrici, delle apparecchiature messe fuori produzione.
Piano della
qualità
Documento che precisa le particolari modalità operative, le risorse e le
sequenze delle attività relative alla qualità di un determinato prodotto,
progetto, o contratto.
Piattaforma
tecnologica di
CRM
Applicazioni in grado di realizzare una completa gestione della
relazione con il cliente. Integrano i sistemi di front-office (call/contact
center, ecc.) con i sistemi di back-office (datawarehouse, ecc.).
PM
V. Project Management).
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 96/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
POP
(Post Office Protocol); protocollo progettato per consentire a programmi
di e-mail di leggere la posta da un mail server. Acquistando un accesso
ad Internet da un provider, solitamente si riceve anche un POP account
(cioè una specie di casella postale) grazie al quale è possibile ricevere
posta. Esistono tre versioni di questo protocollo: POP, POP2 e POP3.
L'ultima versione, non compatibile con le precedenti, è la più evoluta e
quella più diffusa attualmente. V. SMTP.
Portabilità
Capacità di un'applicazione di operare in più ambienti elaborativi.
Portale
Sito web che costituisce una porta di ingresso ad un gruppo consistente
di risorse di Internet o di una Intranet e offre una serie di servizi quali:
news, posta elettronica via browser, chat, motori di ricerca, shopping on
line. Per facilitare la ricerca, gli argomenti in un portale sono raccolti
per categorie: viaggi, meteo, politica, cinema, TV, computer,
educazione, musica, cultura, finanza, lavoro, scienze, sport, salute,
divertimenti (giochi on line), attualità, ecc.
Molti portali sono costruiti e manutenuti con componenti software
chiamati portlets.
I portali Web “verticali” o di nicchia (per questi viene proposto il
neologismo “vortali”) sono dedicati ad argomenti specialistici o a fasce
particolare di utenti.
Portlets
Componenti software di un portale, realizzati mediante il linguaggio
Java, per elaborare le richieste e generare contenuti dinamici.
Posta elettronica
V. E-mail.
Postazione di
lavoro
(PdL); stazione di lavoro individuale che consente ad un utente di
svolgere il proprio lavoro utilizzando il sistema informatico; può essere
costituita da una stazione di lavoro intelligente (workstation/personal
computer) o non intelligente (terminale).
Potenza di
calcolo
Capacità eleborativa dei computer, espressa normalmente in Mips
(Milioni di istruzioni per secondo) o in Mflops (Milioni di istruzioni in
virgola mobile per secondo).
PPP
(Point to Point Protocol); protocollo maggiormente utilizzato per
realizzare delle connessioni TCP/IP via telefono e quindi per accedere
ad Internet.
PRISM
(Publishing Requirements for Industry Standard Metadata); standard
per i formati di descrizione dei contenuti web.
Problem
management
Attività finalizzata all’analisi (problem determination), alla gestione e
alla soluzione dei problemi (problem solving) riguardanti l’erogazione
dei servizi.
Project
Management
Attività di conduzione coordinata di un progetto nel rispetto dei
requisiti di tempi, costi e qualità indicati nei documenti contrattuali. .
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 97/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Processo
Insieme di attività tra loro correlate, finalizzate al raggiungimento di
un obiettivo predefinito.
Procurement
Approvvigionamento.
Prodotti o servizi
digitali
Beni o servizi che possono essere ordinati e consegnati direttamente da
un computer attraverso Internet come, ad esempio, file musicali, giochi,
software, giornali on-line, servizi di consulenza, ecc.
Prodotto
software
Insieme di programmi che regolano il funzionamento di un elaboratore
e l'elaborazione dei dati. Può essere di tipo applicativo o di sistema.
Programma
applicativo
Insieme delle funzionalità messe a disposizione dell’utente per
soddisfare le sue esigenze.
Proprietà di una
misura
Attributi che una misura deve possedere per poter essere utilizzabile ai
fine della composizione della valutazione di un servizio.
Protocollo
Descrizione formale del formato dei messaggi e delle regole che devono
seguire due computer affinchè lo scambio possa avvenire. I protocolli
possono essere di basso livello (come spedire i bit e i byte attraverso la
rete) o di alto livello (come scambiarsi documenti, file o altri oggetti).
Per esempio, il TCP/IP è un protocollo di basso livello, l'HTTP è un
protocollo di alto livello.
Provider
V. ISP.
Provisioning
Approvvigionamento.
Proxy
Meccanismo (hardware e/o software) tramite il quale un sistema si
sostituisce ad un altro nel rispondere alle richieste di un computer
remoto.
Pubblico
Dominio
Software o altro materiale liberamente utilizzabile senza alcuna
limitazione. V. Freeware e Shareware.
Punto di accesso
Componente del servizio di posta elettronica certificata che fornisce i
servizi di accesso per l’utente, l’emissione della ricevuta di accettazione
e realizza l’imbustamento del messaggio originale nel messaggio di
trasporto.
Punto di
consegna
Componente del servizio di posta elettronica certificata che effettua la
consegna del messaggio nella casella di posta elettronica dell’utente
destinatario, verifica la provenienza/correttezza del messaggio ed
emette la ricevuta di avvenuta consegna.
Punto di
ricezione
Componente del servizio di posta elettronica certificata che riceve il
messaggio all’interno di un dominio di posta certificata, effettua i
controlli sulla provenienza/correttezza del messaggio, emette la
ricevuta di presa in carico, imbusta i messaggi errati in un messaggio
di anomalia di trasporto.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 98/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Qualità
Insieme delle caratteristiche di un'entità (processo, prodotto,
organizzazione), che ne determinano la capacità di soddisfare esigenze
espresse o implicite.
Qualità di un
dato
Caratteristica del dato desiderata dagli utenti.
RAM
(Random Access Memory); supporto di memoria su cui è possibile
leggere e scrivere informazioni con un accesso "casuale", ovvero senza
dover rispettare un determinato ordine sequenziale, come ad esempio
avviene per un nastro magnetico.
Il termine è correntemente attribuito a supporti di memoria a stato
solido facenti parte dell’hardware di un computer, utilizzati per
formare la memoria principale del calcolatore che ospita il sistema
operativo, i programmi ed i dati.
RDF
(Resource Description Framework); linguaggio simile all'XML.
Dovrebbe costituire il nocciolo duro del cosiddetto "Semantic Web". Con
RDF è possibile fare asserzioni utilizzando delle "triple" composte da
soggetto, predicato e oggetto.
Registrazione
Documento che fornisce evidenza oggettiva di attività eseguite o
risultati ottenuti.
Registro
Pubblico
Registro, archivio, albo formato, utilizzato, conservato da
un’Amministrazione pubblica, previsto da leggi o regolamenti, che
raccoglie dati connessi all’espletamento delle attribuzioni e dei servizi
svolti dall’Amministrazione.
Repository
Deposito di informazioni.
Requisiti per la
qualità
Espressione delle esigenze o loro traduzione in un insieme di requisiti
espressi quantitativamente o qualitativamente, per le caratteristiche di
un'entità (processo, prodotto, organizzazione) al fine di consentirne la
realizzazione e l'esame.
Responsabile
della qualità dei
dati
Soggetto che, all’interno dell’Amministrazione, ha il compito di definire
le regole organizzative e di attuare le iniziative volte al continuo
miglioramento delle diverse qualità dei dati trattati
nell’Amministrazione.
Responsabilità
Comportamento di un soggetto che, se porta alla violazione di un
accordo di servizio, può portare il soggetto a doverne rispondere.
Rete geografica
Insieme di linee di trasmissione, apparecchiature di gestione e
controllo, software operativo e di controllo che realizza la trasmissione
di dati tra diverse localizzazioni di un'Amministrazione o tra
Amministrazioni diverse.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 99/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Rete locale
Insieme di linee di trasmissione, apparecchiature di gestione e
controllo, software operativo e di controllo che realizza la trasmissione
di dati tra diversi elaboratori e posti di lavoro di un’Amministrazione,
in una singola localizzazione fisica. v. LAN
RFC
(Request For Comments); procedura (e il documento da essa prodotto)
per creare nuovi standard su Internet, dopo approvazione da parte
della IETF.
I documenti in procinto di diventare standard evolvono secondo i
seguenti passi:
Proposed Standard: specifica sufficientemente stabile, di un certo
interesse nella comunità Internet, ma non ritenuta sufficientemente
matura;
Draft Standard: richiede almeno due implementazioni che abbiano
dimostrato la loro interoperabilità; con ciò l’IESG ritiene lo standard
sufficientemente maturo;
Standard: richiede un numero di implementazioni significativo e una
notevole esperienza dimostrata dagli utenti; gli viene assegnato un
numero progressivo nella lista degli standard (STD);
I documenti che non sono ritenuti adatti ad essere Internet Standards
vengono etichettati come:
Experimental: relativo a qualcosa ancora in fase di ricerca, pubblicato a
titolo informativo. Può essere l'output di un gruppo di lavoro Internet
(sia IETF che IRTF), oppure un contributo individuale;
Informational: documento di tipo informativo; non rappresenta
raccomandazione di sorta;
Historic: standard ormai completamente rimpiazzati oppure caduti in
disuso;
Best Common Practice (BCP): documenti che suggeriscono alcuni modi
di comportamento / configurazione consigliati. Queste specifiche
diventano spesso standard de facto.
Rimando
Parola, frase, o immagine che collega il documento Web che la contiene
ad un altro. I browser evidenziano il rimando tramite un determinato
colore o tramite una sottolineatura; un clic sul rimando causa il
richiamo del documento collegato.
Router
Instradatore. Dispositivo (hardware o software) che interconnette reti.
RSS
(Really Simple Syndication); formato per la distribuzione e la diffusione
su diversi canali (syndication) di liste di link, titoli e sommari di news.
RUPA
Rete Unitaria delle Pubbliche Amministrazioni.
SAL
Stato Avanzamento Lavori.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 100/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Scalabilità
Possibilità di far crescere ed evolvere un sistema aumentandone o
sostituendone componenti, oppure di estendere le funzioni di un
software applicativo.
Security Host
Hardening
Processo di definizione, mantenimento e controllo delle politiche di
configurazione e di aggiornamento dei sistemi rilevanti per
l’Organizzazione (in termine di sistema operativo e applicazioni di
base).
Server
Computer o programma che fornisce un determinato tipo di servizio ad
un programma client in esecuzione su un computer remoto. Una stessa
macchina può eseguire contemporaneamente più di un programma
fungendo quindi da server per più client sulla rete.
Service Provider
V. ISP.
Servizi ICT
Servizi di Information and Comunication Technology, basati su
tecnologie informatiche, non destinati alla produzione di beni materiali
o immateriali, che vengono forniti per risolvere le esigenze di un
committente relativamente alla progettazione, realizzazione,
manutenzione, gestione e conduzione operativa di sistemi informativi
automatizzati.
Servizi Internet
mobili
Servizi Internet disponibili attraverso un terminale senza fili (telefono
mobile, assistente personale digitale - personal digital assistant,
terminali senza fili o computer palmari) utilizzando il protocollo WAP
(Wireless Application Protocol) o la rete GPRS (General Packet Radio
Service). WAP è un protocollo che rende possibile l'adattamento dei
formati Internet alle caratteristiche di un GSM. GPRS è una tecnologia
che rende possibile inviare/ricevere blocchi di dati da/a un telefono
cellulare.
Servizio
Insieme di processi finalizzati al soddisfacimento di requisiti dati da un
committente, per un determinato periodo di tempo, mediante l'impiego
di risorse umane e/o strumentali, aventi un valore economico non
necessariamente correlato alla produzione di beni materiali.
Servizio ICT
Servizio svolto con l'ausilio determinante delle tecnologie informatiche.
Servizio in
modalità ASP
Il fornitore assicura l’erogazione dei servizi previsti e la fornitura dei
prodotti necessari alla loro fruizione. Si tratta di forniture che fanno
riferimento prevalentemente a servizi standardizzati, erogati con
bassissimi livelli di personalizzazione.
Servizio
informatico
Applicazione rivolta ad una determinata tipologia di utenza (cittadini,
imprese, associazioni di categoria, ecc.) che ha l'obiettivo di soddisfare
specifiche esigenze di carattere conoscitivo o procedurale.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 101/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Servizio on line
Modalità innovativa di erogazione dei servizi da parte della Pubblica
Amministrazione mediante il canale telematico (Internet). Sono stati
introdotti nel documento “E- Europe 2002 Impact and Priorities” –
Commission of the European Communities - Brussel 13.03.2001 (COM
2001) 140 final, e distinti in quattro livelli di offerta, che vanno dalla
semplice offerta di informazioni fino al servizio elettronico completo e
alla compilazione di moduli e formulari, autenticazione compresa.
SGML
(Standard Generalized Markup Language); metalinguaggio utilizzato
per descrivere altri linguaggi, che permette di definire tipi di
documenti strutturati. Da SGML derivano HTML e XML (v.).
Shareware
Modalità di distribuzione del software. L'autore del programma
permette ai potenziali utenti di provarlo per un certo periodo di tempo
senza alcun costo. Trascorso tale periodo, se l'utente vuole continuare
ad usare il programma deve pagare l'importo richiesto. V. Pubblico
dominio.
S-HTTP
(Secure Hyper Text Transfer Protocol); v. HTTPS.
Sicurezza
Insieme delle misure (di carattere organizzativo e tecnologico) tese ad
assicurare a ciascun utente autorizzato (e a nessun altro) i servizi
previsti per l’utente stesso o la categoria di sua appartenenza, nei
tempi e secondo le modalità previste.
Simplex
Trasmissione di dati che avviene solo in una direzione (per es., le
trasmissioni televisive). V. Half Duplex e Full-Duplex.
Sistema
Insieme di elementi integrati composti da uno o più processi, hardware,
software, capacità e risorse che sono in grado di soddisfare requisiti
specificati o obiettivi.
Sistema
elaborativo
Risorsa, basata su elaboratori e software di base, in grado di svolgere
funzioni informatiche predefinite o personalizzate sull'esigenza
dell'utenza.
Sistema
informatico
Insieme dei sistemi elaborativi e delle applicazioni che automatizza un
determinato comparto industriale o della Pubblica Amministrazione.
Sistema
informativo
Insieme di strumenti automatici e manuali, procedure, risorse umane,
flussi informativi, norme organizzative, orientato alla gestione delle
informazioni di interesse di un'azienda o di un Ente per il
perseguimento dei propri fini.
Sistema per la
gestione della
sicurezza delle
informazioni
Sistema che definisce le politiche per la sicurezza del sistema
informativo; individua i confini del sistema informativo in termini di
struttura organizzativa, collocazione fisica, risorse e tecnologie;
analizza adeguatamente i rischi in modo da identificare le minacce alle
risorse, le vulnerabilità e gli impatti sull’impresa e quindi determini il
livello di rischio globale; seleziona i controlli ritenuti appropriati.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 102/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Sistema qualità
Struttura organizzativa, procedure, processi e risorse necessari ad
attuare la gestione per la qualità.
Sito web
Gruppo di documenti, file, immagini, suoni, database associati
nell’ambito del WWW. Gli elementi di un sito web vertono
generalmente su uno o più argomenti omogenei e sono collegati tramite
collegamenti ipertestuali. La maggior parte dei siti web hanno una
Home Page come punto di partenza che spesso costituisce l’indice del
sito.
SLA
(Service Level Agreement); accordo con il quale il fornitore definisce a
priori il livello di prestazioni cui è tenuto nei confronti del committente.
Smartcard
Carta magnetica di riconoscimento.
SMS
(Short Message System); messaggistica per la telefonia cellulare,
predisposta per l’invio di brevi messaggi di testo.
SMTP
(Simple Mail Transfer Protocol); protocollo per il trasporto di posta
elettronica, presente nel modello TCP/IP al Livello Applicazione. È un
protocollo da server a server e quindi, per poter leggere la posta tramite
un client occorre un altro protocollo (v. POP).
SNA
(Systems Network Architecture); architettura di rete usata da
mainframe IBM e compatibili.
Software
Insieme delle diverse tipologie di programmi utilizzate nei sistemi
informatici.
Spamming
Termine tratto da spam, nome di una canzone dei Monty Python; invio
in grande quantità di messaggi elettronici non richiesti (generalmente
commerciali). Può essere fatto attraverso qualunque media, il più
comune è l'e-mail.
SPC
Servizio Pubblico di Connettività; sistema di connettività federato per
la connessione delle Pubbliche Amministrazioni centrali e locali
(evoluzione della RUPA).
Specifica
Documento che stabilisce dei requisiti.
Specifica del
servizio
Insieme delle caratteristiche che descrivono un servizio.
SSL/TLS
(Secure Socket Layer / Transport Layer Security); protocollo progettato
dalla Netscape per realizzare comunicazioni cifrate su Internet. La
versione 3.0, rilasciata nel 1996, è stata utilizzata come base di
sviluppo per il protocollo TLS che è uno standard IETF definito nella
RFC2246.
Standard
Normativa, raccomandazione; si distinguono standard “de iure” o “de
facto”. I primi sono quelli formalizzati da enti autorizzati di
standardizzazione, per es. l’ISO; i secondi sono norme imposte per
diffusione o popolarità da un’industria.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 103/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
STD
Sottoinsieme dei documenti RFC assurti a dignità di standard. La loro
lista ufficiale è mantenuto all'indirizzo http//info. internet.isi.edu80/innotes/std/files/std1.txt . V. FYI.
Storyboard
Sceneggiatura; sequenza di bozzetti o immagini e didascalie che
riassumono la trama di uno spettacolo o di una comunicazione
pubblicitaria o educativa.
Storyboarding
Attività di creazione di uno storyboard.
Streaming
Tecnologia per la riproduzione di file multimediali inviati tipicamente
attraverso Internet.
Tag
Specie di comando, racchiuso tra parentesi angolari, che costituisce
l'elemento caratterizzante l'HTML (per es. <h1>, </H1>, <IMG
SRC="stella.gif">).
Talk
Protocollo che permette a due persone di comunicare in modalità
sincrona (in tempo reale) scambiandosi messaggi immediatamente
visualizzati sullo schermo del computer remoto. Se si desidera
comunicare contemporaneamente con più di una persona, occorre usare
IRC.
TCP/IP
(Transmission Control Protocol / Internet Protocol); protocollo sul quale
è basata la rete Internet.
Template
Modello.
Terminale
Postazione di lavoro non dotata di capacità di elaborazione propria e
perciò collegata a uno o più elaboratori.
TIFF
(Tag Image File Format); formato di file per memorizzare immagini
tipicamente acquisite tramite scanner.
Titolario di
classificazione
Strumento attraverso cui è organizzato il sistema documentale
dell’ente, ed è strutturato su livelli differenti di classificazione. Ai sensi
del DPR 445/2000, art. 26, capo 4, per titolario di classificazione si
intende un quadro alfanumerico di riferimento per l'archiviazione, la
conservazione e la individuazione dei documenti. Il titolario di
classificazione si suddivide in titoli, a loro volta ripartiti in classi.
All'interno di ciascuna classe, ciascun documento deve essere inserito
in un fascicolo. Ogni classe ha un numero variabile di fascicoli,
dipendente dagli affari e dai procedimenti amministrativi istruiti
all'interno della medesima.
TLC
Contrazione del termine Telecomunicazione.
TLS
v. SSL
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 104/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Token ring
Tipologia di LAN, adottata da IBM e canonizzata nello standard IEEE
802.5, in cui tutti i nodi sono collegati con una topologia ad anello. Ogni
nodo passa costantemente un messaggio di controllo (detto token) al
nodo successivo, il nodo che possiede il token può inviare dei dati. È
uno di tipi di LAN più diffuso (insieme a Ethernet); la sua tipica
larghezza di banda è di 16 Mbps.
Transazione
Insieme di messaggi correlati che svolgono un'operazione elementare
unitaria che mantiene la consistenza della base informativa.
Turnover
Sostituzione, avvicendamento del personale.
Tutoraggio
Attività di guida e supervisione di studenti o ricercatori.
Unità di misura
Unità fisica che definisce il riferimento da adottare nella misura di un
fenomeno.
Unità
organizzativa
interna
Per unità organizzativa interna di primo livello s’intende l’articolazione
costituita mediante atto formale della struttura organizzativa
dell’Amministrazione, che costituisce centro di responsabilità
gerarchica e/o funzionale ed il cui responsabile si trova, per incarico
dirigenziale in posizione di dipendenza organizzativa diretta dagli
organi di responsabilità e di decisione politica dell’Amministrazione
stessa. Per unità organizzativa interna di livello intermedio s’intende
la partizione interna dell’Amministrazione costituita mediante atto
formale il cui responsabile, generalmente per incarico dirigenziale,
opera alle dirette dipendenze gerarchiche e o funzionale di unità
organizzative interne di primo livello.
URL
(Uniform Resource Locator); indirizzo di una pagina su Internet. È
costituito di tre parti: il nome del servizio (ad es. http:// che
rappresenta il servizio HTTP (v.), il nome del server o del sito (che
inizia normalmente con “www” e finisce con un suffisso che ne indica il
tipo (“.com” se commerciale, “.it” se italiano, ecc.) e il nome del
documento o del file (che indica dove si trova la pagina all’interno del
server o del sito).
URN
(Uniform Resource Name); per evitare la temporaneità tipica degli
URL, sono stati introdotti gli URN che, per definizione, sono
permanenti ed individuano univocamente una risorsa nel WWW.
USB
(Universal Serial Bus); modalità tecnica per migliorare la connettività
esterna dei
computer.
User-id)
(User Identity): identità dell’utente; identificatore univoco di un utente
in un sistema. Tipicamente, va specificato all'atto del collegamento,
insieme ad una password.
Utente
Addetto di un’unità organizzativa che, nell'ambito del processo di
servizio al quale è assegnato, sistematicamente interagisce (con attività
di elaborazione, acquisizione dati, controllo) con il sistema informatico.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 105/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Utente disabile
Utente di un sistema informatico caratterizzato da limitazioni fisiche o
psichiche che rendono indispensabile l’utilizzo di specifiche tecnologie
di supporto per l’accesso.
Valore di soglia
Valore di riferimento posto ad una misura rilevata durante l'erogazione
del servizio (o ad una elaborazione di misure) nella definizione di un
livello di servizio. La formula con la quale il valore di soglia è correlato
ad una misura è in genere una disequazione.
Valutazione dei
livelli di servizio
Esame sistematico del livello con il quale una determinata componente
di un servizio soddisfa determinati requisiti, in un determinato periodo
di osservazione, in una data finestra temporale di erogazione di un
servizio.
Verifica ispettiva
Esame sistematico ed indipendente mirato a stabilire se le attività
svolte per la qualità ed i risultati ottenuti sono in accordo con quanto
stabilito, e se quanto stabilito viene attuato efficacemente e risulta
idoneo al conseguimento degli obiettivi.
Virus
Programma con la capacità di riprodursi da un computer ad un altro,
all'insaputa del suo utilizzatore. Al verificarsi di determinati eventi,
può rivelare la sua presenza causando inconvenienti più o meno
disastrosi sul computer su cui è in esecuzione.
Voice
compression
Compressione della voce; conversione di un segnale vocale analogico in
un segnale digitale, riducendo al minimo la larghezza di banda
necessaria (teoricamente 16 Mbps).
VoIP
(Voice over Internet Protocol); protocollo che consente di stabilire una
comunicazione vocale attraverso Internet.
VRML
(Virtual Reality Modeling Language); estensione di HTML per la
simulazione di scenari virtuali con cui interagire via WWW.
VRU
(Voice Response Unit); sistemi di risposta vocale automatica.
W3C
(World Wide Web Consortium); organizzazione che rilascia gli standard
ufficiali dei protocolli utilizzati in Internet.
WAN
(Wide Area Network): rete geografica. Rete di computer che ricopre
un'area geografica molto estesa, e che interconnette sia singoli host che
LAN o MAN, dislocati nell’area. Negli uffici pubblici spesso si creano
delle WAN tra host, attraverso la normale linea telefonca, oppure per
mezzo di linee dedicate, o via satellite.
WAP
(Wireless Application Protocol): protocollo di applicazione senza fili;
permette di ricevere e spedire informazioni tramite dispositivi senza
fili, tra i quali il telefono cellulare.
WBT
(Web Based Training); prodotti multimediali per l’apprendimento in
rete.
Web
V. World Wide Web.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 106/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Webmaster
Responsabile tecnico della gestione di un server Web. Lo si può
contattare per malfunzionamenti tecnici riguardanti il sito di cui è
responsabile.
Web server farm
Farm, fattoria. Termine generico per indicare il luogo in cui sono
presenti dei server per il servizio di hosting, homing e lo sviluppo di
applicazioni e servizi per l'IT. Problematiche affrontate nelle web farm
sono quelle inerenti il. load balancing, per una distribuzione ottimale di
servizi offerti in rete e il Fault tolerance, tolleranza ai guasti.
Wireless Lan o
Wlan
(Wireless Local Area Network); sistema di comunicazione flessibile e
accrescibile nella sua estensione, o alternativo ad una rete fissa (wired
Lan). In una Wlan viene utilizzata una tecnologia di radio frequenza
per la ricetrasmissione dei dati, minimizzando la necessità di
connessioni via cavo (wired), favorendo così una discreta mobilità. Una
WLan consente una velocità massima di trasmissione dati (bit rate)
pari a 11Mbps, minore di quella di una rete wired, ma superiore alle
possibilità consentita dai terminali mobili comuni.
Workflow
Flusso di lavoro; il Workflow Management System è un sistema per la
gestione dei processi aziendali mediante documenti elettronici.
World Wide Web
Rete estesa al mondo; conosciuta anche come Web, definisce
un'architettura software per accedere a documenti tra loro collegati e
distribuiti sul mondo intero.
WS
(Web Services); sistema software identificato dalla RFC 2396, le cui
interfacce pubbliche, il protocollo ed il formato dei dati sono definiti e
descritti utilizzando il linguaggio XML.
WWW
V. World Wide Web.
XDSL
(x Digital Subscriber Line); tecnologie progettate per aumentare
l'ampiezza di banda attraverso l'utilizzo di fili telefonici di rame.
Comprende le seguenti tecnologie IDSL, HDSL, SDSL, ADSL, RADSL,
VDSL, DSL-Lite.
XHTML
(eXtended Hypertext Markup Language); v. HTML.
XML
(eXtensible Markup Language); linguaggio derivato dall'SGML (v.) il
metalinguaggio che permette di creare altri linguaggi. Mentre l'HTML
è un'istanza specifica dell'SGML, XML costituisce a sua volta un
metalinguaggio, più semplice dell'SGML, largamente utilizzato per la
descrizione di documenti sul web. L'XML viene utilizzato per definire le
strutture dei dati invece che per descrivere come questi ultimi devono
essere presentati. Tali strutture vengono definite utilizzando dei
marcatori (markup tags). Diversamente dall'HTML, l'XML consente
all'utente di definire marcatori personalizzati, dandogli il controllo
completo sulla struttura di un documento. Si possono definire
liberamente anche gli attributi dei singoli marcatori. La specifica XML,
largamente utilizzata in ambito Internet, è lo standard per la
definizione di documenti.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 107/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
ZIP
Formato di compressione file più diffuso al mondo, originariamente
sviluppato da Phil Katz, i cui programmi PKZip e PKUnZip effettuano,
rispettivamente, il lavoro di compressione e di decompressione.
Zmodem
Protocollo di trasferimento file tra due computer connessi direttamente
via modem. È lo standard attualmente più utilizzato poiché permette
sia il trasferimento di più file sia la ripresa del loro trasferimento in
caso di interruzione.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 108/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
8. BIBLIOGRAFIA
La bibliografia di seguito riportata non deve essere intesa in senso esaustivo.
Immensa è la letteratura disponibile in lingua inglese, peraltro usualmente di più difficile
accesso da parte delle pubbliche amministrazioni. Per questo ci si è maggiormente concentrati
su testi disponibili in lingua italiana limitandosi a indicare alcune prime letture di carattere
generalistico e di orientamento.
I testi referenziati si riferiscono alle edizioni effettivamente consultate, per quelle più lontane
nel tempo potrebbero esistere versioni successive.
I testi sono elencati in ordine decrescente di anno di pubblicazione in riferimento a venti
categorie tematiche:
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
Public Procurement
Outsourcing
Information Technology
Process Engineering
IT Management
Project Management
Monitoring & Control
Benchmarking
Quality Management
Quality Management - CMM
Quality Management - TQM
Quality Management - ISO 9000
Quality Management - Auditing
Qualità dei Dati
Qualità dei Servizi
Customer Satisfaction
Sw Quality
Sw Usability
Sw Engineering
Sw Measurement
Per quanto riguarda i siti Internet sono stati indicati i principali siti italiani ed esteri legati
alle seguenti categorie tematiche:
o
o
o
o
o
o
o
Public Procurement
Outsourcing
Sw Engineering
Certificazione
Normazione
Accreditamento
Altre Istituzioni / Associazioni interessate al tema della qualità
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 109/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
8.1. TESTI
Public Procurement
Argomento / Titolo
Bandi di Gara di Forniture e Servizi
L'ABC degli Appalti di Forniture e Servizi
Appalti Pubblici di Servizi
L'evoluzione della Pubblica Amministrazione italiana
Outsourcing
Argomento / Titolo
L’outsourcing e i nuovi scenari della terziarizzazione
Il Project Finance nelle aziende pubbliche
Sistemi informativi – Volume V – Contratti e qualità
Autore
R. Bonavia, G. Gallo-Orsi
G. Turco Liveri
Del Castillo, C. Galtieri,
U. Realfonzo
A cura di R. Leonardi, F. Boccia
Autore
L. Fumagalli, P. Di Cioccio
F. Amatucci
A cura di C. Batini, B. Pernici, G.
Santucci
Nuove strategie d'acquisto
R. Perrotin, J.M. Loubère
Outsourcing e valorizzazione delle competenze
A. De Paolis
Gestire l’outsourcing
S. Valentini
I Servizi di Outsourcing Informatico
C. Pasini
L’Outsourcing nei Sistemi Informativi Aziendali
R. Virtuani
I Contratti di Impresa
C. Guerrieri
Outsourcing nelle Tecnologie dell’Informazione
R. Glucksmann, M. Ricciardi
Il ricorso alla finanza privata per la realizzazione di opere Unità Tecnica di Finanza di Progetto
pubbliche
ICT
Argomento / Titolo
Autore
Rapporto sull'Informatica e le Telecomunicazioni
Assinform
Information Technology e gestione del cambiamento
R. Ravagnani
organizzativo
Le Soluzioni Informatiche per l’Impresa
C. Guerrieri
Il Sistema Informativo Aziendale
P. F. Camussone
Process Engineering
Argomento / Titolo
Autore
Innovazione dei Processi
T. H. Davenport
La Gestione per Processi
A cura di P. De Risi
Governo e miglioramento dei processi
J. Tsourias
Il Miglioramento dei Processi nel Settore dell’IT
M. Maiocchi
Processi Aziendali e Sistemi Informativi
G. Bracchi, G. Motta
BPR Riprogettazione dei processi aziendali
H. J. Johansson, P. Mc Hugh
A. J. Pendlebury, W. A. Wheeler III
ICT Management
Argomento / Titolo
Autore
La Politica di Mercato nei settori ad alta tecnologia
R. Fiocca
Il Cambiamento Organizzativo nell'Information
V. Merlyn, J. Parkinson
Technology
Informatica e Pubblica Amministrazione: proposta per uno A. Sarti
sviluppo integrato
Information Technology e Management
A. Leggio
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Editore
Il Sole 24 Ore libri
Il Sole 24 Ore libri
Il Sole 24 Ore libri
Anno
1999
1999
1998
Il Sole 24 Ore libri
1997
Editore
Franco Angeli
EGEA
Franco Angeli
Franco Angeli
Franco Angeli
Franco Angeli
Franco Angeli
Franco Angeli
Il Sole 24 Ore libri
ETAS Libri
CIPE
Editore
Assinform
EGEA
Anno
2002
2002
2001
2000
2000
1999
1999
1997
1995
1994
Anno
2004
2000
Il Sole 24 Ore libri
Etas Libri
1999
1998
Editore
Franco Angeli
Nuovo Studio Tecna
Franco Angeli
Franco Angeli
Franco Angeli
Il Sole 24 Ore libri
Anno
2000
1999
1998
1998
1997
1994
Editore
Giuffrè
Franco Angeli
Anno
1998
1995
IDC Italia
1995
Il Sole 24 Ore libri
1993
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 110/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Project management
Argomento / Titolo
Organizzare e Gestire Progetti
Project Management, 7a edizione
Tecniche di Project Management 7a edizione
Gestire i Rischi di Progetto
Lavorare per progetti. Project management e processi
progettuali, 4a edizione
Le sfide di management del XXI secolo
A handbook of walkthroughs, inspections and technical
reviews
Benchmarking
Argomento / Titolo
Benchmarking nella pubblica amministrazione
Il Benchmarking
Benchmarking for competitive advantage
Monitoring & Control
Argomento / Titolo
La pratica della valutazione
Valutare per Governare
Il Check-up dei Sistemi Informativi
Monitoraggio & Valutazione dei Progetti
Contabilità dei Costi. Contabilità per centri di costo e
activity based costing, 2a ed.
Information Technology in action
Monitoraggio dei progetti di investimento
Controlling software projects
Software engineering economics
Quality Management
Argomento / Titolo
Il Quality Manager tra azienda e mercato
Juran's Quality Control Handbook - 5th edition
Applicazioni Informatiche per la Qualità
Progettare in Qualità
La qualità Perché, per chi e come farla
Attractive quality and must be quality
Juran on Planning for Quality
Managing Quality
La qualità non costa
Quality Management - Capability Maturity Model
Argomento / Titolo
CMM for software vers. 1.1
Software Engineering Institute (SEI) Assessment
Methodology
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Autore
E. Baglieri, A. Biffi, E. Coffetti
C. Ondoli, N. Pecchiari, M. Pilati
R.D. Archibald
R. Amato, R. Chiappi
G. Iacono
M. Baldini, A. Miola, P.A. Neri
Franco Angeli
Franco Angeli
Franco Angeli
Franco Angeli
2000
2000
1999
1999
P.F.Drucker
D. Fredman
Franco Angeli
Little Brown
1999
1982
Autore
F. Marchitto
G.H. Watson
Boxwell
Editore
Franco Angeli
Franco Angeli
Mc Graw Hill
Anno
2001
1995
1994
Autore
V. Masoni
A cura di G. Azzone, B. Dente
P. F. Camussone
V. Masoni
L. Brusa
Editore
Franco Angeli
Etas Libri
Etas Libri
Franco Angeli
Giuffrè
Anno
2002
1999
1998
1997
1995
R. Wang
L. Cappugi
T. De Marco
B.W. Boehm
Yourdon Press
Franco Angeli
Yourdon Press
Prentice Hall
1993
1992
1982
1981
Autore
A cura di R. Scaramuzza
J.M. Juran
A cura di V. Scialla
P. De Risi
Giorgio Pala
N. Kano
J.M. Juran
D. Garvin
P. Crosby
Editore
Nuovo Studio Tecna
J.M. Juran editor
Il Sole 24 Ore libri
Il Sole 24 Ore libri
Franco Angeli
Goal/QPC
NY Free Press
NY Free Press
Mc Graw Hill Italia
Anno
1999
1998
1996
1996
1994
1994
1988
1988
1986
Autore
M. Paulk e altri
SEI
Editore
SEI
SEI
Anno
1993
1987
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Editore
Etas Libri
Anno
2000
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 111/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Quality Management - Total Quality Model
Argomento / Titolo
La gestione totale della qualità come strategia per il
successo dell'impresa
La Qualità Totale nella Pubblica Amministrazione
Gemba Kaizen, a commonsense, low cost approach to
management
Sette Strumenti Manageriali della Qualità Totale
Autovalutazione basata sulla gestione della qualità totale.
Modello Europeo
Come costruire la qualità totale
Total Quality Control, 3a ed.
Qualità Totale
Kaizen: The Key to Japan's Competitive Success
Quality Management - ISO 9000
Argomento / Titolo
Guida alla Qualità, 5a edizione
ISO 9000 Handbook - 3rd edition
Qualità, Affidabilità, Certificazione
Guida alla certificazione ISO 9000
Guida all’interpretazione ed all’utilizzo delle norme ISO
9000
La qualità certificata
ISO 9000 Quality Systems Handbook
Quality Management - Auditing
Argomento / Titolo
Le verifiche ispettive interne della qualità nella ISO 9000
Gli Audit sulla Qualità
Qualità dei Dati
Argomento / Titolo
Improving Data Warehouse and Business Information
Quality: Methods for Reducing Costs and Increasing
Profits
Data Quality for the information age
Qualità dei Servizi
Argomento / Titolo
La Carta dei Servizi, Valutazione e miglioramento della
qualità nella P.A
La valutazione dei risultati nelle pubbliche
amministrazioni
Organizzare la Qualità nei Servizi
Migliorare la qualità dei servizi per soddisfare le crescenti
aspettative dei clienti
Utenti e pubblica amministrazione
Misura e valutazione dei servizi pubblici
La qualità nel servizio; Tosalli A.
Customer satisfaction
Argomento / Titolo
Misurare la soddisfazione dei clienti
Customer oriented software quality assurance
Handbook of customer satisfaction measurement
Un metodo per la misurazione della customer satisfaction
Measuring Customer Satisfaction: developement and use
of questionnaires
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Autore
R. Galimberti, M. Maiocchi
Editore
Franco Angeli
G. Negro, B. Susio
M. Imai
Il Sole 24 Ore libri
Mc Graw Hill
1998
1997
A. Galgano
EFQM
Il Sole 24 Ore libri
EFQM
1994
1994
T. Conti
A. Feigenbaum
A. Galgano
M. Imai
Sperling & Kupfer
Mc Graw Hill
Il Sole 24 Ore libri
Mc Graw Hill
1992
1991
1990
1986
Autore
Annuario
A cura di R. Peach
G. Mattana
I. Tsiourias
B. Jensen
Editore
Nuovo Studio Tecna
Mc Graw Hill
Franco Angeli
Franco Angeli
Franco Angeli
G. Iacono
D. Hoyle
A. Tencati
Butterworth
Heinmann
Autore
C. Del Gobbo, C. Reda
D. Aerter
Editore
Franco Angeli
Franco Angeli
Anno
1998
1996
Autore
L. English
Editore
John Wiley & Sons
Anno
1999
T.C. Redman
Artech House
Autore
R. Ruffini
Editore
Guerini e Associati
Anno
1999
G. Rebora
Guerini e Associati
1999
G. Negro
A cura di L. Negri
Il Sole 24 Ore libri
Nuovo Studio Tecna
1999
1998
Editore
Franco Angeli
Prentice Hall
sito internet
UTET
sito internet
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Anno
2000
1999
1999
1996
1995
1995
1994
A cura di G. Barbieri, V. Lo Moro
Il Mulino
A cura di G. A. Certomà, V. Lo Moro,
Il Mulino
R. Malizia
T. Conti, A. Pettigiani, M.G. Pettigiani Bariletti Editori
Autore
B. E. Hayes
F.P. Ginac
N. Hill
GRAMMA
B.E. Hayes
Anno
1998
1996
1996
1995
1990
Anno
2000
1997
1996
1993
1992
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 112/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Sw Quality
Argomento / Titolo
The handbook of software quality assurance
Il Test e la Qualità del Software
Software Quality: Analysis & Guidelines for Success
ISO 9000-3 a tool for software product and process
improvement
ISO 9001 interpreted for software organizations
ISO 9001 & Software Quality Assurance
Software inspection
Il Sistema Qualità del Software
La Qualità nei Progetti Software
Software Quality Engineering: a total technical and
management approach
Sw Usabilità
Argomento / Titolo
Il computer invisibile
Usabilità dei siti web
Software for Use: A Practical Guide to the Models and
Methods of Usage Centered Design
The Usability Engineering Lifecycle: A Practitioner's
Handbook for User Interface Design
Usability Engineering LifeCycle
Il disagio tecnologico
Contextual Design: A Customer-Centered Approach to
Systems Designs
Cost-Justifying Usability
Usability engineering
Usability inspection methods
Sw Engineering
Argomento / Titolo
Software engineering standard – A user’s road map
Autore
A cura di G.G. Schulmeyer
A. Cignoni, P. De Risi
C. Jones
R. Kehoe, A. Jarvis
Editore
Prentice Hall
Il Sole 24 Ore libri
Int. Thomson Pub.
Springer
A. Ronald
D. Ince
T. Gilb, D. Graham
S. Nocentini
A. Banci, G. Iacono
M.S. Deutsch, R.R. Willis
Paradoxicon Pub.
Mc Graw Hill
Addison Wesley
Etas Libri
Franco Angeli
Prentice Hall
Autore
D.A. Norman
M. Visciola
L. Constantine, L. Lockwood
Editore
Apogeo
Apogeo
Addison Wesley
D. Mayhew
Morgan Kaufmanns
1999
D.J. MayHew
A. Cooper
H. Beyer, K. Holtzblatt
Morgan Kaufmanns
Apogeo
Morgan Kaufmann
1999
1999
1997
Bias, D.Mayhew
J. Nielsen
J. Nielsen, R.L. Mack
Academic Press
Morgan Kaufmann
John Wiley & Sons
1994
1994
1994
Autore
J.W. Moore
Editore
IEEE Computer
Society Press
Franco Angeli
John Wiley & Sons
Blackwell Businness
Mc Graw Hill
Oxford University
Press
Mondadori
Informatica
La Manutenzione del Software Applicativo
Encyclopedia of software Engineering
Software process assessment & improvement
Software Engineering Metrics - Vol. I
Japan's Software Factories
M. Sorrentino, G. De Gregori
J. Marciniak
Kuvaja Simila ed altri
M. Shepperd
M.A. Cusumano
Ingegneria del Software
C. Ghezzi, A. Fuggetta, S. Morasca,
A. Morzenti, M. Pezzé
R.S. Pressman
Humphrey Watts
J. Martin
E. Yourdon
Principi di ingegneria del software
Managing the software process
Information Engineering - Book I, II, III
Analisi strutturata dei sistemi
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Mc Graw Hill Italia
Addison Wesley
Prentice Hall
Jackson Libri
Anno
1998
1998
1997
1996
1995
1994
1993
1993
1993
1988
Anno
2000
2000
1999
Anno
1998
1995
1994
1994
1993
1991
1991
1991
1989
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 113/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Sw Measurement
Argomento / Titolo
Misurare il software
Estimating software costs
Software metrics, a rigorous approach 2nd edit.
Function Point
Qualità e Quantità nei Sistemi Software
Metrics and Models in Software Quality Engineering
O-O software metrics
Practical implemetation of software metrics
Software metrics for product assessment
Practical software metrics for project mangement and
process improvement
Applied software measurement
Function point analysis, Difficulties and improvements
Cost estimation for software development
Programming Productivity
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Autore
L. Buglione
C. Jones
N.E. Fenton, S.L. Pfleeger
F. La Noce
D. Natale
S.H. Kan
M. Lorenz, J. Kidd
P. Goodman
R. Bache
G.Bazzana
R.B. Grady
Editore
Franco Angeli
Mc Graw Hill
Thomson Learning
Franco Angeli
Franco Angeli
Addison Wesley
Prentice Hall
Mc Graw Hill
Mc Graw Hill
Prentice Hall
1992
C. Jones
IEEE
Mc Graw Hill
Transaction on Sw
Engineering
Addison Wesley
Mc Graw Hill
1991
1988
B. Londeix
C. Jones
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Anno
1999
1998
1998
1997
1996
1995
1994
1993
1993
1987
1986
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 114/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
8.2. SITI INTERNET
Public Procurement
Argomento / Organizzazione
Autorità per l'Informatica nella Pubblica Amministrazione (AIPA)
Comunità Europea, le pagine della DG XV – “Mercato interno e servizi
finanziari” offrono informazioni relativamente alle direttive comunitarie in
materia di appalti pubblici.
Progetto comunitario SIMAP , presenta informazioni relative alle regole ed
alle procedure per gli appalti pubblici, tra queste la classificazione CEE
"Common Procurement Vocabulary", CPV, anche lingua italiana,
aggiornata all’ultima versione.
Information Services Procurement Library (ISPL), fornisce la versione 1,
del 1996, di Euromethod, metodo di gestione dei contratti successivamente
evolutosi e venduto sotto il nome di ISPL
Outsourcing
Argomento / Organizzazione
Outsourcing Institute ente americano di consulenza
Centro di consulenza americano
Società di management consulting Everest
Sw Measurement
Argomento / Organizzazione
International Function Point User Group (IFPUG)
Associazione Gruppo Utenti Function Point Italia (GUFPI)
Certificazione di qualità
Argomento / Organizzazione
ANGQ Associazione Nazionale Garanzia della Qualità
ASQ American Society for Quality
CISQ Federazione CISQ, Certificazione Italiana Sistemi Qualità Aziendali
Commissione Europea - DG III
EFQM European Foundation For Quality Management
EOQ European Organization For Quality
EOTC European Organisation for Conformity Assessment
European Quality Policy
Globus International Quality Group
IATCA International Auditor and Training Certification Association
IQNet The International Certification Network
ISO 9000 e ISO 14000 - Sito ufficiale ISO
ISO 9000: Year 2000 Revisions - Sito ufficiale ISO
Ministero Industria - sistema italiano della certificazione e della qualità
Q&C Qualità e Competitività
Quality Digest magazine
Quality magazine
Quality Today
SINCERT
The European Information Service on Conformity Assessment Activities
Vision 2000 - Il futuro dei sistemi qualità Gestito da UNI.
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Indirizzo Sito Internet
http://www.aipa.it/
http://europa.eu.int/
http://simap.eu.int/
http://www.fast.de/ISPL/
Indirizzo Sito Internet
http://www.outsourcing.com/
http:// www.outsourcing-expert.com/
http:// www.outsourcing-mgmt.com/
Indirizzo Sito Internet
http://www.ifpug.org/
http://www.gufpi.com/
Indirizzo Sito Internet
http://www.angq.com/
http://www.asq.org
http://www.cisq.com/
http://europa.eu.int/comm/dg03/index_en.htm
http://www.efqm.org/
http://www.eoq.org/start.html
http://www.eotc.be/
http://europa.eu.int/comm/dg03/directs/dg3a/a3/qua
lity/home_en.htm
http://www.globusregistry.com/cgibin/Home/Public/homesummary.cgi
http://www.iatca.com/
http://www.iqnet-certification.com/
http://www.iso.ch/9000e/9k14ke.htm
http://www.iso.ch/9000e/revisionstoc.htm
http://www.minindustria.it/Dgspc/Ispettorato/Patto
_sociale.htm
http://www.qec.it/home.html
http://www.qualitydigest.com/
http://www.qualitymag.com/
http://www.qualitytoday.com/
http://www.sincert.it/
http://www.ticqa.eotc.be/
http://www.unicei.it/vision2000/home.html
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 115/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
Normazione
Argomento / Organizzazione
CEI Comitato Elettrotecnico Italiano
CEN European Committee For Standardization
CENELEC European Committee for Electrotechnical Standardization
Direttive Nuovo Approccio
ECMA Standardizing Information and Communication Systems
ETSI European Telecommunications Standards Institute
IEC International Electrotechnical Commission
IETF Internet Engineering Task Force
ITU International Telecommunication Union
JTC1 - Joint Technical Committee 1
W3C World Wide Web Consortium
EUR-Lex Banca dati della legislazione comunitaria
Guida all'implementazione delle direttive Nuovo Approccio e Approccio
Globale
ISO International Organization for Standardization
Nuovo Approccio e Approccio Globale
Q&C Quando & Come - aggiornamento sulle novità legislative e normative
UNI Ente Nazionale Italiano di Unificazione
UNINFO Ente di normazione per le Tecnologie Informatiche e loro
applicazioni
Accreditamento
Argomento / Organizzazione
EA European co-operation for Accreditation
Membri effettivi e associati dell'EA
IAF International Accreditation Forum
Organismi che hanno firmato l'accordo IAF MLA
Altre Istituzioni / Associazioni interessate al tema dell'IT management
Argomento / Organizzazione
AICQ Associazione Italiana Cultura Qualità
FITA Federazione Italiana Industrie e Servizi Professionali e del Terziario
Avanzato
Forum per la Società dell'Informazione - Presidenza del Consiglio dei
Ministri
SEI/CMM Software Engineering Institute/Capability Maturity Model for
Sw
UNIONCAMERE Unione Italiana delle Camere di Commercio, Industria,
Artigianato e Agricoltura
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Indirizzo Sito Internet
http://www.ceiuni.it/
http://www.cenorm.be/
http://www.cenelec.org/
http://www.newapproach.org/directiveList.as
http://www.ecma.ch
http://www.etsi.org
http://www.iec.ch/
http://www.ietf.cnri.reston.va.us/home.html
http://www.itu.int/
http://www.jtc1.org
http://www.w3.org/
http://europa.eu.int/eur-lex/it/search.html
http://www.eotc.be/news/ec/ec_guide/
http://www.iso.ch/
http://www.newapproach.org/home.asp
http://www.qec.it/quandoecome/home.html
http://www.uni.com/
http://www.uninfo.polito.it/
Indirizzo Sito Internet
http://www.european-accreditation.org/
http://www.europeanaccreditation.org/mla/member.html
http://www.iaf.nu/
http://www.iaf.nu/mlist.asp
Indirizzo Sito Internet
http://www.aicq.it/
http://www.fita.it
http://www2.palazzochigi.it/fsi/
http://www.qpmg.com/sei.htm
http://www.unioncamere.it
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 116/117
CNIPA
MODELLI PER LA QUALITÀ DELLE FORNITURE ICT
8.3. RIVISTE
Denominazione Rivista
Azienda Pubblica
De Qualitate
Economia & Management
Informatica ed Enti Locali
Qualità
Numero d'Oggetto/Part Number
MANUALE 6
 Copyright CNIPA
Descrizione
Rivista bimestrale dedicata alla tematica alla teoria ed alla prassi del management, edita
da Maggioli.
Rivista mensile che tratta il tema della qualità, curandone sia gli aspetti tecnici che
quelli organizzativi e del personale, nei diversi settori tra cui anche quello dei servizi e
dell'information technology, edita da Nuovo Studio Tecna.
Rivista bimestrale della Scuola di Direzione Azienale della Università Bocconi di
Milano, dedicata alle tematica politico-economiche, organizzative, del personale,
gestionali, in cui è sistematicamente trattato anche il settore dell'information
technology, edita da Etas.
Rivista mensile dedicata al tematica del cambiamento organizzativo e tecnologico nel
contesto della pubblica amministrazione locale attuato per il tramite dell'innovazione
tecnologica, edita da Maggioli.
Rivista bimestrale che tratta il tema della qualità, curandone sia gli aspetti tecnici che
quelli organizzativi e del personale, nei diversi settori tra cui anche quello dei servizi e
dell'information technology, edita dall'Associazione Italiana Cultura Qualità (AICQ).
Ed./Issue
Data/Date
Com. Mod./Ch. Notice
1.0
25.01.2005
---
Tutti i diritti riservati - All rights reserved
Manuale di riferimento
MODELLI PER LA QUALITÀ DELLE
FORNITURE ICT Manuale di
riferimento
Pagina 117/117