SISTEMA INFORMATIVO CATALOGO BIBLIOGRAFICO TRENTINO

CAPITOLATO TECNICO Pagina i

SISTEMA INFORMATIVO CATALOGO BIBLIOGRAFICO TRENTINO

CBT CAPITOLATO TECNICO

31/07/2017

CBT-CT

Sistema Informativo CBT

02.1

CAPITOLATO TECNICO Pagina i

INDICE

1 GENERALITÀ 3

1.1 GLOSSARIO 4

2 RUOLI E RESPONSABILITÀ 5

2.1 Responsabile del contratto del contraente 5

2.2 STAKEHOLDER 5

3 DIMENSIONAMENTO DEL SISTEMA 7

4 REQUISITI 10

4.1 Requisiti del sistema 10

4.1.1 gestione delle Acquisizioni 10

4.1.2 GESTIONE DEI PERIODICI A STAMPA 11

4.1.3 GESTIONE DEGLI SCARTI E DELLA RACCOLTA 12

4.1.4 Gestione delle risorse elettroniche 13

4.1.5 Catalogazione 14

4.1.6 CIRCOLAZIONE 16

4.1.7 RICERCA ILS 18

4.1.8 GESTIONE DELLA REPORTISTICA 18

4.1.9 OPAC 20

4.1.10 DISCOVERY 22

4.1.11 Amministrazione e configurazione 22

4.2 REQUISITI DELL’INFRASTRUTTURA 25

4.2.1 ACCESSO AI SERVIZI APPLICATIVI 25

4.2.2 SICUREZZA 26

4.2.2.1 Data Center 26

4.2.2.2 Controllo dei processi e log file 26

4.2.2.3 Tracciabilità 26

4.2.2.4 Policy 27

4.2.3 BUSINESS CONTINUITY E DISASTER RECOVERY 27

4.2.4 NORMATIVA VIGENTE E CERTIFICAZIONI 27

4.2.5 AMBIENTI DI RIFERIMENTO 28

4.2.6 GESTIONE DEI DATI 28

4.2.6.1 Protezione dei dati 28

4.2.6.2 Portabilità dei dati e “uscita contrattuale” 29

4.2.6.3 Dati Aperti e Linked Data 29

5 CONDUZIONE DEL SERVIZIO 31

pag. ii CAPITOLATO TECNICO

5.1 RIUNIONI 31

5.2 Gestione issue 31

6 ATTIVITA’ RICHIESTE 33

6.1 PRESA IN CARICO DEL SERVIZIO 33

6.1.1 POPOLAMENTO DEL SISTEMA CON I DATI ESISTENTI (MIGRAZIONE) 33

6.1.2 FASE PILOTA 33

6.1.3 COLLAUDO E ATTIVAZIONE DEL SERVIZIO 33

6.2 Formazione 34

6.3 MANUTENZIONE DEL SOFTWARE, DELL’INFRASTRUTTURA TECNOLOGICA E ASSISTENZA UTENTE 34

6.3.1 ATTORI DEL PROCESSO DI MANUTENZIONE 36

6.3.2 Difformità nell’erogazione del servizio di manutenzione delsoSoftware. software 36

6.4 RICONSEGNA DEI DATI E CHIUSURA DEL SERVIZIO 37

7 MANUTENZIONE E SVILUPPI SOFTWARE - SERVICE LEVEL AGREEMENT 38

7.1.1 SLA PER MANUTENZIONE CORRETTIVA 40

7.1.2 SLA PER MANUTENZIONE ORDINARIA ED EVOLUTIVA 43

7.1.3 SLA PER IL SERVIZIO DI SUPPORTO SPECIALISTICO 44

7.1.4 SLA per il servizio di assistenza e supporto all’utenza 44

7.1.5 SLA per il servizio di manutenzione dell’infrastruttura tecnologica 46

7.1.6 SLA per la difformità nell’erogazione del servizio di manutenzione del software 47

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 3

1 GENERALITÀ

Il Catalogo Bibliografico Trentino (CBT) costituisce da oltre 30 anni lo strumento principe di cooperazione fra tutte le biblioteche del territorio trentino e il principale supporto ai loro servizi automatizzati.

Le circa 150 biblioteche di varie tipologie (accademiche, di ricerca, di conservazione, specialistiche, di pubblica lettura) collaborano per:

• la creazione del catalogo unico che gestisce ad oggi oltre 1,9 milioni di record (con un incremento annuale di circa 60.000 unità) e circa 5 milioni di esemplari (con aumento annuale di circa 200.000 unità);

• la circolazione delle copie tra le diverse biblioteche, condividendo gli utenti e con oltre

60.000 prestiti interbibliotecari;

• gli scambi di informazione a vari livelli, ad esempio sulle risorse in acquisizione.

Formano oggetto dell’appalto l’acquisizione di un Sistema Informativo per la gestione completa del Catalogo Bibliografico Trentino (CBT), la sua configurazione e avviamento, l’erogazione dei servizi di manutenzione e supporto applicativo e la fornitura e gestione dell’infrastruttura tecnologica a supporto. Il sistema informativo oggetto della fornitura dovrà sostituire l’attuale sistema, viene quindi richiesta anche l’attività di migrazione di tutti i dati esistenti. Il sistema proposto dovrà inoltre comprendere le eventuali licenze d’uso per il funzionamento dello stesso.

Il sistema informativo richiesto dovrà erogare i seguenti servizi applicativi:

• supportare la gestione delle attività di back-office tipiche di un Integrated Library System (ILS), incluse le funzionalità di acquisizione, amministrazione del sistema, gestione dei periodici, gestione delle risorse elettroniche, catalogazione e ricerca, circolazione, comunicazione e collaboration, gestione degli scarti, statistiche e reportistica.

• fornire l’interfaccia web di accesso pubblico al catalogo, On-line Public Access Catalogue (OPAC), e comprendere le funzionalità di ricerca semplice ed avanzata, accesso ai dati personali sui prestiti, prenotazione on-line delle copie, interazione con cataloghi bibliografici esterni, con repository e con servizi di arricchimento delle informazioni.

Nel presente documento con il termine Sistema Informativo CBT si farà riferimento all’insieme di tutti i sottosistemi che lo compongono nonché alle nuove componenti od eventuali nuovi sottosistemi sviluppati nell’ambito del servizio di manutenzione del software.

Informatica Trentina ha adottato, nella definizione delle modalità di erogazione dei servizi di manutenzione del software, le best practices ITIL®, di seguito si farà riferimento pertanto alla terminologia proposta dal glossario ITIL®1.

1xxxxx://xxx.xxxxxx.xxx/xxxxxxxxxx-xx-xxxxx

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 4 CAPITOLATO TECNICO

1.1 GLOSSARIO

API	Application Programming Interface
CBT	Catalogo Bibliografico Trentino
DD	Document Delivery
DR	Disaster Recovery
FEM	Fondazione Xxxxxx Xxxx
ILL	Interlibrary Loan
ILS	Integrated Library System
IT	Informatica Trentina
ITIL	Information Technology Infrastructure Library
LDAP	Lightweight Directory Access Protocol)
OCLC	Online Computer Library Center
OPAC	On-line Public Access Catalogue

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 5

2 RUOLI E RESPONSABILITÀ

2.1 RESPONSABILE DEL CONTRATTO DEL CONTRAENTE

Il Contraente dovrà designare formalmente il Responsabile, appartenente alla propria organizzazione, della gestione e dell’esecuzione di quanto oggetto del contratto e del coordinamento delle risorse impegnate. Tale Responsabile sarà il punto di contatto ufficiale di Informatica Trentina.

2.2 STAKEHOLDER

Di seguito gli stakeholder di Informatica Trentina (attori coinvolti) individuati secondo la vista del Contraente:

Fase	Stakeholder	Ruolo
Contratto	Amministrazione Responsabile del contratto IT	Gestione amministrativa del contratto. Verifica degli stati di avanzamento periodici del servizio. Autorizzazione pagamenti fatture.
Autorizzazione agli accessi e Sicurezza	Responsabile del contratto IT Responsabile Sicurezza	Riferimento per le autorizzazioni agli accessi. Riferimento per le problematiche relative alla sicurezza.
Erogazione del servizio di manutenzione correttiva	Responsabile applicazione	Riferimento per problematiche della soluzione.
Erogazione del servizio di manutenzione ordinaria, evolutiva e supporto specialistico e gestione dell’infrastruttura	Responsabile del contratto IT	Formula la richiesta di valutazione degli interventi. Attiva gli interventi.
Avvio del servizio	Responsabile del contratto IT Responsabile Data center	Valida le condizioni di avvio del servizio. Valida le condizioni di

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 6 CAPITOLATO TECNICO

avvio del servizio dal punto di vista dell’infrastruttura tecnologica.

Per quanto riguarda le comunicazioni il Responsabile del contratto IT rappresenterà il punto di contatto del Responsabile del contratto del Contraente a cui questi si rivolgerà per qualsiasi esigenza dovesse emergere nel corso dell’appalto.

Per qualsiasi problema che non trovasse soluzione attraverso il contatto diretto tra i responsabili del contratto di IT e del Contraente, la modalità di escalation prevista è che la questione venga affrontata dai Responsabili del procedimento di IT e del Contraente (ovvero dalle figure aziendali che sono in grado di vincolare giuridicamente la controparte alle decisioni assunte in sede contrattuale) in una specifica riunione che ha l’obiettivo di individuare le linee di azione per risolvere la controversia ed in ultima analisi, nel caso permanga il disaccordo, intraprendere le azioni ritenute più opportune.

Tutte le comunicazioni scritte e orali inerenti lo svolgimento delle attività richieste dovranno avvenire in lingua italiana.

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 7

3 DIMENSIONAMENTO DEL SISTEMA

Si forniscono di seguito le informazioni (dati aggiornati a fine 2016, giugno 2017) ritenute utili al fine di consentire un idoneo dimensionamento del nuovo sistema in ogni sua singola componente, la corretta pianificazione della fase di migrazione dei dati e l’attività di formazione degli utilizzatori.

CBT - Dimensioni
Numero di biblioteche definite nel sistema	152 di cui 17 con più di un branch
Tipologie di biblioteche che formano il sistema:	• 94 di pubblica lettura • 7 scolastiche • 1 universitaria (Università degli Studi di Trento) • 50 specialistiche/conservazione
Record bibliografici al 01/01/2017	1.975.501
• Record bibliografici creati nel 2016	66.506
Record di copia al 01/01/2017	5.186.715
• Record di copia creati nel 2016	188,489
Authority record al 31/05/2017	• 1572 nomi; • 73 soggetti; • 1 titolo
Prestiti nel 2016	1.427.086
Prestiti ILL interni al CBT nel 2016	61.609
Utenti attivi (almeno un prestito) nel 2016	118.899
Prenotazioni attive il 13 giu 2017	4.733
Fornitori nel modulo Acquisizioni	8.130
Ordini non ricevuti al 13 giu 2017	4.323
Operatori attivi nel sistema al 01/01/2016	520

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 8 CAPITOLATO TECNICO

Utilizzo delle funzionalità ILS da parte delle biblioteche
• Ricerca bibliografica	Tutte le biblioteche
• Catalogazione bibliografica (= creazione di nuovi record bibliografici)	Tutte le biblioteche
• Aggiunta di copia (= esemplare)	Tutte le biblioteche
• Inventariazione	Tutte le biblioteche
• Prestito locale	Tutte le biblioteche
• Prestito interbibliotecario interno al Sistema CBT	Tutte le biblioteche
• Acquisizioni	6 biblioteche, a tendere 10

Utilizzo di funzionalità “speciali” esterne all’attuale ILS da parte delle biblioteche
• Gestione periodici a stampa	5 biblioteche, a tendere 7
• Gestione risorse elettroniche	3 biblioteche, a tendere 5
• Prestito interbibliotecario ILL/DD	5 biblioteche, a tendere 10
• Servizi di Discovery e Indice centrale con sistemi esterni all'attuale ILS	2 biblioteche, a tendere 4
• MedialibraryOnline	56 biblioteche, a tendere 60

Risorse elettroniche (gestite attualmente esternamente all'ILS)
E-journals	• 13. 319 (5.402 abbonamento, 7.917 open) • circa 11.000
• FEM (Fondazione Xxxxxx Xxxx • Università degli Studi di Trento
Ebooks	• 3.620 (500 acquistati, 3.120 open) • 174.965 (EBSCO Academic complete)
• FEM • Università degli Studi di Trento
FTE	• 500 • 11.500
• FEM • Università degli Studi di Trento

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 9

Migrazione dei dati
Dati generali la cui migrazione è obbligatoria:	• record bibliografici • record di inventario • record di copia • heading di nomi, titoli, editori, soggetti, CDD, numeri di controllo, segnature • record di authority • record utenti • record dei fornitori
Dati relativi alle transazioni attive la cui migrazione è obbligatoria:	• prestiti locali, interbranch e ILL • record di inventario • prenotazioni • ordini non ancora ricevuti
Dati la cui migrazione non è obbligatoria:	• ordini con copia ricevuta

Formazione utilizzatori – numero di persone coinvolte
operatori per la catalogazione bibliografica completa e relativa reportistica	100
operatori per l'aggiunta di copia e l'inventariazione e relativa reportistica	200
operatori del prestito locale e relativa reportistica	200
operatori del prestito ILL e relativa reportistica	150
operatori delle acquisizioni e relativa reportistica	20
operatori per la gestione periodici e relativa reportistica	20
operatori per la gestione delle risorse elettroniche e relativa reportistica	10

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 10 CAPITOLATO TECNICO

4 REQUISITI

4.1 REQUISITI DEL SISTEMA

Nel successivi paragrafi vengono introdotte, raggruppate in modo omogeneo, le funzionalità richieste.

==> IMPORTANTE: le caratteristiche obbligatorie, indicate come requisiti minimi nei paragrafi seguenti, devono essere possedute nella loro totalità dalla soluzione proposta. Pertanto, l'insussistenza anche di uno solo degli elementi minimi, qualora venga accertata successivamente all’assegnazione potrà comportare la risoluzione del contratto.

4.1.1 gestione delle Acquisizioni

GESTIONE DELLE ACQUISIZIONI - REQUISITI MINIMI
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
1.1	risorse gestite	Deve essere possibile gestire l'intero processo di acquisizione (pre-ordine, gestione liste di libri in visione, gestione dei fondi e dei venditori, ordine, pagamento, fatturazione, cancellazione, reclami, statistiche e report) per le seguenti risorse bibliografiche: monografie, periodici, dvd, risorse elettroniche. Le tipologie di acquisizione previste devono comprendere l'acquisto, lo scambio e la donazione.
1.2	integrazione	La gestione delle acquisizioni deve essere integrata con tutti i componenti del sistema. in particolare: 1) l'integrazione con la catalogazione deve permettere la condivisione delle informazioni bibliografiche e prevedere una funzione di precatalogazione semplificata; 2) l'integrazione con l'OPAC deve consentire la gestione dei desiderata degli utenti e delle proposte di acquisto e permettere la condivisione delle informazioni sugli stati degli ordini e sulle modalità d'uso delle licenze delle risorse elettroniche.
1.3	history	Tutte le attività di acquisizione devono essere memorizzate e rese disponibili tramite report e funzionalità statistiche. Lo storico delle informazioni correlate (stato dell'ordine, data, biblioteca...) deve essere visualizzabile e filtrabile.
1.4	input di dati	Deve essere consentito acquisire e gestire record provenienti da fonte esterne. Deve inoltre essere permessa la ricerca real time su piattaforme elettroniche di distributori e librerie on line e il caricamento, mediante liste di selezione, delle informazioni bibliografiche trovate.
1.5	record dei fornitori	L’anagrafica dei fornitori deve essere gestita e condivisa a livello di sistema con possibilità di prevedere informazioni riservate a livello di biblioteca. Le informazioni devono poter essere recuperate secondo vari filtri di ricerca e deve essere possibile la creazione di report e statistiche inerenti i fornitori.
1.6	standard di comunicazione con i fornitori	Deve essere supportato l' Electronic Data Interchange (EDI) per le comunicazioni con i fornitori.

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 11

1.7	ordini	Il sistema deve poter gestire ordini d'acquisto aggiungendo note, commenti e l'indicazione del richiedente. Deve inoltre essere possibile sia associare molteplici ordini (ad esempio per molteplici sedi o con molteplici fondi) ad una singola risorsa sia creare ordini duplicati inserendo i dati un'unica volta. Deve essere possibile cancellare ordini dandone comunicazione automatica ai fornitori . Deve essere possibile inoltre generare lettere di reclamo.
1.8	prezzi	Deve essere possibile gestire le imposte previste (es. IVA) e gli sconti.
1.9	operazioni massive	Deve essere possibile effettuare operazioni batch su campi selezionati di specifici ordini d'acquisto.
1.10	gestione budget e fondi	Deve essere permesso il controllo economico articolato in fondi di spesa e la gestione della chiusura dell'anno finanziario. Deve essere possibile la suddivisione delle spese tra più fondi. Devono essere consentiti acquisti in cooperazione tra più enti.
1.11	fatturazione elettronica	Il sistema deve essere in grado di gestire la procedura di fatturazione elettronica prevista per le PA secondo le modalità ed i formati di interscambio definiti dall'Agenzia delle Entrate.
GESTIONE DELLE ACQUISIZIONI - REQUISITI OPZIONALI (qualora offerti)
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
1.12	gestionali	Il sistema deve consentire l'interfacciamento con sistemi gestionali contabili - amministrativi.
1.13	sistemi di pagamento esterni	Il sistema deve consentire l'interfacciamento con sistemi di pagamenti esterni.
1.14	report fornitori	Il sistema deve disporre di strumenti e report per valutare la convenienza e l'affidabilità dei fornitori in funzione ad esempio dei costi e dei tempi di evasione dell'ordine.
1.15	valuta estera	Il sistema deve essere in grado di gestire valute diverse nella procedura degli ordini, anche attraverso un collegamento automatico con il tasso di cambio della valuta prescelta.
1.16	alert	Devono essere previsti alert per specifici motivi, in particolare nel caso di evasioni parziali o in ritardo degli ordini. In tal caso deve essere anche consentito inviare in automatico al fornitore della biblioteca solleciti per le risorse non fornite. Devono poter essere segnalate le spese che eccedono una soglia prefissata o che superano i fondi disponibili.

4.1.2 GESTIONE DEI PERIODICI A STAMPA

GESTIONE PERIODICI a STAMPA - REQUISITI MINIMI
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
2.1	risorse gestite	Deve essere garantita la gestione delle sottoscrizioni, dei rinnovi, degli ordini permanenti e delle informazioni sul posseduto (compresi gli ordini di rilegatura). Devono essere disponibili modelli di previsioni di arrivo generati in modo automatico e condivisi a livello di sistema.

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 12 CAPITOLATO TECNICO

2.2	integrazione	La gestione dei periodici deve integrarsi con la catalogazione e con la circolazione. Inoltre le informazioni relative al posseduto devono essere visualizzate nell'OPAC in formato riassunto e dettagliato.
GESTIONE PERIODICI a STAMPA - REQUISITI OPZIONALI (qualora offerti)
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
2.3	ACNP	Le informazioni bibliografiche e di posseduto dei periodici devono essere rese disponibili al Catalogo Italiano dei Periodici (ACNP).
2.4	notifiche	Devono essere previsti meccanismi ( es. mail e sms) per comunicare a gruppi di interesse (sia bibliotecari che utenti lettori) l'arrivo di fascicoli.

4.1.3 GESTIONE DEGLI SCARTI E DELLA RACCOLTA

GESTIONE DEGLI SCARTI E DELLA RACCOLTA- REQUISITI MINIMI
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
3.1	gestione raccolta in circolazione	Deve essere possibile effettuare modifiche ai dati di copia al momento del prestito o della restituzione.
GESTIONE DEGLI SCARTI E DELLA RACCOLTA - REQUISITI OPZIONALI (qualora offerti)
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
3.2	operazioni massive	Deve essere possibile effettuare modifiche dei dati di copia mediante operazioni massive (ad esempio spostamento da una sezione ad un'altra), effettuabili direttamente dai bibliotecari.
3.3	ragione scarto	E’ necessario che nel record di inventario siano registrate le ragioni dello scarto: deve essere possibile assegnare alla copia da scartare almeno uno dei seguenti valori: - scartato usurato; - scartato vendita; - mancante; - obsoleto (obsoleto tipograficamente, contenuto superato, autori non di moda); - non pertinente alla raccolta; - copia in eccedenza; - smarrito; - da proporre ad altre biblioteche; - revisionato.
3.4	vetrina scarti	Deve essere possibile creare una vetrina interna al sistema ILS, dove i bibliotecari addetti allo scarto possano inserire copie che ritengono di interesse per altre biblioteche.
3.5	gestione scarti	Devono essere previste funzioni, attivabili e gestite direttamente dal bibliotecario, per procedere alla cancellazione massiva e aggiornamento del record di inventario con una nota indicante le ragioni dello scarto.
3.6	mobile	Deve essere possibile effettuare modifiche dei dati delle copie durante la consultazione a scaffale (modifica in mobilità).

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 13

4.1.4 Gestione delle risorse elettroniche

GESTIONE DELLE RISORSE ELETTRONICHE-	REQUISITI MINIMI
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
4.1	ERM	Il sistema deve fornire le funzionalità per gestire il ciclo di vita di una risorsa elettronica: selezione, trial, acquisizione, licenze, attivazione, manutenzione, valutazione, rinnovo, cancellazione.
4.2	record risorse elettroniche	Tutti i record coinvolti nella gestione delle risorse elettroniche (inclusi ordine, collezione/database, licenze, record bibliografico) devono essere collegati e in relazione l'uno l'altro.
4.3	knowledge base (KB)	Il sistema deve fornire una knowledge base, gestita dal Contraente, comprendente tutte le tipologie delle risorse elettroniche e dei relativi metadati e i servizi per il loro utilizzo, all'interno della quale il posseduto delle Biblioteche del CBT interessate possa essere identificato e attivato.
4.4	record locali nella KB	In aggiunta alla knowledge base e a suo complemento, il sistema deve permettere al CBT di creare e aggiornare record locali usando la stessa struttura di dati della knowledge base.
4.5	link resolver	Il sistema deve fornire un OpenURL link resolver. Il link resolver deve usare i dati contenuti nella knowledge base per creare i links appropriati alle risorse richieste dall'utente finale.
4.6	personalizzazione	Ciascuna biblioteca del sistema interessata deve poter personalizzare sia la knowledge base, sulla base del proprio posseduto sia il link resolver (regole di creazione e di visualizzazione dei link e dei menù).
4.7	proxy	Il sistema deve collegarsi via proxy alle risorse elettroniche usando i proxy service in uso presso le biblioteche del CBT interessate.
GESTIONE DELLE RISORSE ELETTRONICHE - REQUISITI OPZIONALI (qualora offerti)
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
4.8	anagrafica fornitori e database licenze	Il sistema deve fornire un database con i dati anagrafici dei fornitori e le licenze standard di risorse elettroniche che possono essere usate dalle biblioteche del CBT interessate come modello as is o come modello per creare i record locali.
4.9	licenze	Deve essere possibile collegare il file che contiene il contratto di licenza al relativo record nel sistema.
4.10	disponibilità licenze	I termini della licenza devono essere disponibili per la visione pubblica.
4.11	pubblicazione	Il sistema deve avere la possibilità di pubblicare, nell'OPAC, liste A-to-Z delle risorse elettroniche (es. e-book, e-journal, ecc.) consultabili e ricercabili.
4.12	Liste A-to-Z	Le liste A-to-Z devono essere create dalle biblioteche del CBT interessate a partire dalla knowledge base ed essere ordinabili almeno per titolo e per collezione/database.

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 14 CAPITOLATO TECNICO

4.13	standard	Il sistema deve supportare standard rilevanti per la gestione delle risorse elettroniche, come DLF ERMI, ONIX-PL, COUNTER, SUSHI.
4.14	gestione record locali nella KB	I record locali creati usando la stessa struttura di dati della knowledge base devono essere trasmessi al Contraente del servizio per l'inclusione a lungo termine nella knowledge base, trasferendo la responsabilità della gestione dalle biblioteche del CBT interessate al Contraente.

Nota: L’accesso alle risorse elettroniche relativamente alle due biblioteche che attualmente ne fanno uso, Università degli studi di Trento e FEM, si basa su tecnologie che garantiscono la fruibilità dei contenuti digitali rispettando i vincoli di licenza d’uso delle singole risorse per le specifiche categorie di utenza. In particolare viene utilizzato un servizio di Reverse Proxy (EZproxy di OCLC) autenticato tramite tecnologia SOAP/2 sviluppata sul prodotto di accesso federato Open Source denominato Shibboleth. Pertanto le risorse elettroniche catalogate in copia come appartenenti all’Università di Trento, modificheranno la URL di accesso inserendo l’indirizzo del proxy server di Ateneo.

4.1.5 CATALOGAZIONE

CATALOGAZIONE - REQUISITI MINIMI
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
5.1	catalogazione partecipata	Deve essere garantita la catalogazione partecipata in unico catalogo centralizzato online.
5.2	copy cataloging	Deve essere possibile l'immissione di dati bibliografici mediante catalogazione derivata in collegamento con cataloghi esterni (ad es. SBN, KVK, Library of Congress). Deve essere possibile selezionare i tag da importare.
5.3	integrazioni	Devono essere rese disponibili in tempo reale le informazioni bibliografiche alle funzionalità di acquisizione, circolazione e all'OPAC.
5.4	template	Deve essere permessa la definizione di modelli specifici per le diverse risorse (monografia, periodico, e-book, audio, video).
5.5	clone	Deve essere possibile duplicare un record bibliografico.
5.6	gestione copie	Deve essere possibile aggiungere ad ogni record bibliografico almeno 550 copie, con almeno i seguenti dati: biblioteca, sede, sezione, segnatura (o collocazione), tipo prestito, disponibilità al prestito ILL, note di copia e note di posseduto.
5.7	inventario	Deve essere possibile creare per ogni copia un record di inventario con almeno i seguenti dati: tipo acquisizione, valuta, prezzo, fornitore, nota.
5.8	authority record	Deve essere possibile creare authority record per Xxxx, Titoli, Xxxxxxxx.
5.9	stampa etichette	Il sistema deve prevedere funzioni di stampa etichette per le copie compatibili con le apparecchiature più diffuse sul mercato.
5.10	standard	E' richiesta la gestione dell’intero set di caratteri UNICODE.

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 15

5.11	standard XXXX	Xxxx essere consentita la registrazione dei dati bibliografici delle varie tipologie di risorse secondo il formato MARC21. Deve essere inoltre consentita la creazione degli authority records in formato MARC 21.
5.12	standard RDA	Deve essere possibile la creazione di metadati secondo lo standard Resource Description Access (RDA).
5.13	modello FRBR	Deve essere possibile organizzare i record bibliografici seguendo il modello Functional Requirements for Bibliographic Records (FRBR).
5.14	modello FRAD	Deve essere possibile organizzare gli authority record seguendo il modello Functional Requirements for Authority Data (FRAD).
5.15	cancellazioni massive	Deve essere possibile effettuare cancellazioni massive di dati mediante operazioni batch.
5.16	export	Deve essere possibile estrarre i dati in formato MARC21 anche mediante filtri e tramite processi asincroni e pianificabili .
5.17	esportazione dati	Deve essere garantita l’esportazione dei dati di catalogo in formato Marc21: - giornaliera verso l’Università di Trento; - settimanale verso Fondazione Xxxxxx Xxxx (FEM); - semestrale verso OCLC (catalogo Worldcat). I processi devono essere configurabili.
5.18	esportazione opendata	Deve essere garantita l’esportazione settimanale dell’anagrafica delle biblioteche e orari verso il portale Opendata; per il tracciato e formati di esportazione si rinvia al link xxxx://xxxx.xxxxxxxx.xx/xxxxxxx/xxxxxxxxxx- biblioteche.
5.19	aggiornamento db	processo di aggiornamento, a richiesta o periodico, della base dati CBT al fine di acquisire l’informazione del codice identificativo della risorsa esterna alimentata (ad esempio il codice identificativo di OCLC). Si deve prevedere la possibilità di aggiornare codici che fanno riferimento a diversi cataloghi esterni;
5.20	servizi Medialibrary	servizi di interrogazione per la ricerca di informazioni bibliografiche in Medialibrary.
5.21	servizi di interrogazione	servizi per l’interrogazione via Web del catalogo bibliografico.
CATALOGAZIONE - REQUISITI OPZIONALI (qualora offerti)
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
5.22	immissione dati	Deve essere possibile sia l'immissione dati guidata e semplificata (cioè con i soli tag necessari per ogni tipologia di record e con etichette comprensibili) per catalogatori occasionali, sia immissione dati rapida per catalogatori esperti.
5.23	immissione metadati	Deve essere possibile aggiungere metadati di catalogazione locali.
5.24	manutenzione dei record	Devono essere disponibili strumenti per la manutenzione dei record (es. per deduplicazioni, controllo sui campi, ecc.).
5.25	controllo URL	Deve essere possibile il controllo periodico della validità degli URL e la produzione dei report relativi.

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 16 CAPITOLATO TECNICO

5.26	immissione di dati - operazioni batch	Deve essere possibile l'immissione di dati bibliografici mediante caricamenti massivi (operazioni batch) .
5.27	input di dati - lettura codici	Deve essere possibile l'immissione di dati bibliografici mediante lettura di codici ISBN, ISSN, EAN e DOI.
5.28	authority control	Deve essere disponibile un collegamento con la base dati del progetto Virtual International Authority File (VIAF).

4.1.6 CIRCOLAZIONE

CIRCOLAZIONE - REQUISITI MINIMI
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
6.1	tipologie di prestito	La circolazione deve garantire: 1) il prestito locale; 2) il prestito interbranch tra sedi diverse della stessa biblioteca; 3) il prestito ILL (Inter Library Loan) interno al sistema con comunicazioni tramite protocollo ISO 10160 e 10161 e trasferimento della gestione della copia 4) il prestito ILL esterno al sistema con interazione con i maggiori gestori di ILL, tra cui Xxxxx, Subito e OCLC. Tutte le tipologie di prestito devono essere tracciate in ogni passaggio.
6.2	policy	Devono essere gestite politiche di prestito in funzione delle diverse tipologie di utenti, politiche delle multe e politiche dei solleciti (tramite sms, e-mail e stampa). Tali policy devono essere personalizzabili per ogni singola biblioteca. Il bibliotecario potrà comunque cambiare tali politiche, anche solo temporaneamente, per le categorie o per il prestito anche in fase di registrazione.
6.3	integrazioni	La circolazione deve interagire con l’OPAC per la conferma dei dati personali modificati dall’utente, l’accettazione e la gestione delle prenotazioni on-line, comprese le richieste ILL (creazione, cancellazione e rinnovi).
6.4	gestione copie con RFID	La gestione delle copie deve poter avvenire con sistemi di lettura ottica (barcode) e tramite tecnologia RFID (tag UHF). I sistemi RFID devono supportare il protocollo SIP2 (ed eventuali evoluzioni future) ed essere integrati con il sistema gestionale.
6.5	integrazione RFID	Le funzioni di circolazione devono essere integrate con i sistemi RFID utilizzati per ragioni di sicurezza (varchi anti taccheggio) e per il selfcheck (autoprestito).
6.6	consultazione	Deve essere possibile gestire risorse in sola consultazione o in solo prestito locale (es. per i materiali di pregio).

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 17

6.7	identificazione utenti	Deve essere prevista, oltre al barcode, la possibilità di identificare gli utenti anche tramite codice fiscale (ad es. per il servizio di prestito, accesso wi-fi, ecc.). Deve essere verificata la struttura del codice fiscale.
6.8	comunicazioni verso gli utenti	Devono essere presenti ed integrati con le funzionalità di circolazione, strumenti di comunicazione elettronica (e-mail e sms) attivabili verso gli utenti. A seconda delle preferenze, l’utente potrà scegliere se ricevere comunicazioni automatiche (ad esempio per solleciti) prioritariamente via e-mail o sms.
6.9	calendario e orari apertura/chiusura	Deve essere consentita la gestione da parte del bibliotecario , per ogni sede di biblioteca, di un calendario delle giornate di apertura e chiusura e degli orari settimanali suddivisi in tre fascie giornaliere. I dati devono essere resi disponibili nell'OPAC.
6.10	dati anagrafici in sede di iscrizione	i dati anagrafici da raccogliere in sede di iscrizione dovranno essere un sottoinsieme di quelli previsti dall'Anagrafe nazionale della popolazione residente (ANPR - D.P.C.M. 10 novembre 2014, n. 194 allegato b) e con essa compatibili al fine di garantire l'omogeneità e l'eventuale interazione tra sistemi. Il set minimo di informazioni richieste deve quindi comprendere: - Codice fiscale; - Cognome; - Nome ; - Luogo Nascita (comune di nascita - stato estero di nascita); - Data Nascita; - Sesso; - Cittadinanza .
6.11	ulteriori dati utente in sede di iscrizione	Devono essere presenti informazioni aggiuntive (es: tipo utente,livello di istruzione, condizione professionale, posizione nella professione) sull'utente utili per l'analisi. Per questo tipo di dati è richiesto prevedere un adeguato numero di campi modificabili nel tempo. Tali campi conterranno un insieme di valori predefiniti selezionabili dall'utente. Le tabelle che ad essi saranno collegate dovranno riferirsi a classificazioni ufficiali o, qualora non definite, andranno concordate con L’Istituto Provinciale di Statistica (ISPAT), competente in materia di classificazione a livello provinciale.
6.12	residenza	Per quanto riguarda la residenza della persona, le informazioni raccolte dovranno seguire le direttive impartite per la costituzione dell'Archivio Nazionale dei Numeri Civici delle Strade Urbane (ANNCSU). Nel decreto in approvazione è previsto che i comuni utilizzino nell'ambito delle attività di competenza esclusivamente i dati presenti nell'ANNCSU. Nello specifico dovranno essere presenti le informazioni relative a - Specie (DUG: via, piazza, lungomare, salita, ecc.) - Denominazione - Civico - Esponente - Comune La frazione non è in questo momento prevista nei tracciati ma ne è richiesta l'integrazione.

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 18 CAPITOLATO TECNICO

6.13	informazioni su prestiti utente	Le informazioni relative alla disponibilità al prestito devono essere immediatamente visibili nell’OPAC da parte dell’utente e utilizzabili inoltre nella circolazione per la ricerca bibliografica interna e per la visione dello stato del prestito.
CIRCOLAZIONE - REQUISITI OPZIONALI (qualora offerti)
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
6.14	prestiti di risorse digitali	Il sistema deve gestire le informazioni di prestiti digitali ("download") di risorse di altre piattaforme (es. MLOL).
6.15	restituzione	Deve essere possibile la restituzione di un prestito in una sede bibliotecaria diversa sia dalla proprietaria che dalla richiedente.
6.16	procedura di prestito off-line	Deve essere presente una modalità di gestione del prestito quando il sistema on-line è temporaneamente bloccato e di procedura di allineamento quando il sistema on-line è di nuovo disponibile.

4.1.7 RICERCA ILS

RICERCA ILS - REQUISITI MINIMI
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
7.1	ricerca semplice	Deve essere possibile una ricerca semplice, google-like, in tutte le risorse disponibili nell'ILS.
7.2	ricerca complessa	Deve essere possibile una ricerca complessa, anche su più campi, tramite operatori booleani e caratteri jolli in tutte le risorse dell'ILS.
7.3	personalizzazioni	Deve essere possibile salvare modelli di query da riutilizzare e avere una dashboard di ricerca personalizzabile a livello di singolo operatore (notifiche, ricerche salvate, etc.)
7.4	risultati della ricerca	Deve essere possibile filtrare i risultati tramite l'utilizzo di faccette personalizzabili.
RICERCA ILS - REQUISITI OPZIONALI (qualora offerti)
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
7.5	dashboard personalizzata	Deve essere possibile avere una dashboard di ricerca personalizzabile a livello di singolo operatore.

4.1.8 GESTIONE DELLA REPORTISTICA

GESTIONE DELLA REPORTISTICA - REQUISITI MINIMI
ID	REQUISITO	DESCRIZIONE DEL REQUISITO

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 19

8.1	usabilità	Il sistema deve prevedere la possibilità di creare e personalizzare, da parte dei singoli bibliotecari e a livello centrale, senza richiedere conoscenze tecniche specifiche, report e statistiche sulla base di tutti i tipi di dati presenti nel sistema.
8.2	export dei dati	Deve essere possibile esportare i report e le statistiche in formati aperti, xls e csv.
8.3	report acquisizione	Deve essere possibile visualizzare e stampare report relativi al processo di Acquisizione. Tra questi sono fondamentali: elenco copie fatturate/ricevute, elenco fatture, elenco ordini, elenco fondi.
8.4	report circolazione	Deve essere possibile visualizzare e stampare report relativi ai prestiti e alle risorse presenti nel catalogo. Tra questi sono fondamentali: - elenco copie in prestito della biblioteca al momento; - elenco copie ILL inviate e ricevute della biblioteca al momento; - storia dei prestiti di una specifica copia; - elenco utenti della biblioteca (con tutti i dati della tessera); - elenco utenti con prestiti scaduti al momento; - elenco copie ammesse al prestito ma non prestate per un determinato periodo; - elenco copie con segnatura e stato del prestito; - registro d'inventario; - cataloghi bibliografici; - elenco biblioteche/sedi/sezioni.
8.5	report catalogazione	Due sono i report imprescindibili per la gestione della biblioteca: i report con un layout definito per le etichette di dorso e barcode dei libri e i report per l’estrazione di dati catalografici finalizzati alla gestione citazionale, ai bollettini bibliografici e ai database locali.
8.6	report mobile	Per l'ambito mobile deve essere garantito l’accesso a livello di report almeno alle seguenti informazioni: - nr. accessi unici in un intervallo di tempo; - nr. accessi totali nell’intervallo di tempo; - nr. utenti registrati; - nr. download dell’app; - nr. app. attive.

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 20 CAPITOLATO TECNICO

8.7	statistiche	Devono essere fornite statistiche inerenti la dotazione della singola biblioteca, il catalogo nel suo complesso e servizi forniti. Le seguenti statistiche sono fondamentali: - prestiti annuali della biblioteca (divisi per sede, tipo utente, etc.); - titoli più letti nella biblioteca in un anno; - prestiti ILL inviati e ricevuti; - patrimonio complessivo nella biblioteca (nr. di copie) diviso per adulti/ragazzi, narrativa/saggistica; - copie e documenti catalogati in un anno in una biblioteca e nel sistema divisi per tipo di materiale, lingua, Classificazione Dewey.
GESTIONE DELLA REPORTISTICA - REQUISITI OPZIONALI (qualora offerti)
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
8.8	strumenti di analisi	Devono essere messi a disposizione strumenti di business analysis dei dati raccolti

4.1.9 OPAC

OPAC - REQUISITI MINIMI
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
9.1	esportazione bibliografie	Deve essere consentito effettuare le seguenti operazioni sui record bibliografici risultanti da una ricerca: -download secondo i formati di citazione biblografica più diffusi (endNote, refWorks , RIS, BibTeX, PDF, EXCEL, HTML, XML,MARC21, MARC XML) -invio tramite e-mail di uno o più record bibliografici.
9.2	piattaforme esterne	Deve essere garantito il collegamento con i cataloghi esterni (es: SBN, MLOL, ebrary, KVK, WorldCat, SBN ) per la ricerca di risorse bibliografiche.
9.3	servizio copertine	Deve essere garantito un servizio che recupera e presenta in OPAC le copertine delle risorse tramite numero di controllo ISBN, ISSN e EAN.
9.4	catalogo ragazzi	Deve poter essere creata una sezione specifica del portale dedicata alla letteratura per ragazzi.
9.5	Internazionalizzazione	Devono essere supportate le lingue italiana, inglese e tedesca.
9.6	RSS	Deve essere supportata la possibilità di esportare contenuti tramite feed RSS.
9.7	arricchimento dell'OPAC	Il sistema deve poter ricevere dinamicamente servizi di arricchimento delle informazioni (es. Syndetic solution).
9.8	design responsive	l'OPAC deve essere fruibile con tablet e smartphone.

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 21

9.9	ricerca semplice - lista	Deve essere possibile effettuare una ricerca google-like all'interno del contenuto informativo del catalogo bibliografico trentino dando la possibilità di effettuare ordinamenti per rilevanza, titolo, autore e anno e un filtro sulle biblioteche. Nel caso di informazione breve è richiesta la possibilità di visualizzare il dettaglio bibliografico dell'opera catalogata inclusa la disponibilità delle copie per ogni sede e la possibilità di raggruppare i risultati restituiti secondo la logica FRBR. Se il termine ricercato non è presente devono essere visualizzati i risultati ottenuti con una ricerca basata su "suggerimenti" o "forse cercavi..." .
9.10	ricerca avanzata	Deve esistere la possibilità di effettuare strategie di ricerca in AND e OR (anche annidate) e la possibilità di decidere di applicare le condizioni logiche a livello di singola copia o di record bibliografico. Deve essere supportato lo standard Common Command Language.
9.11	filtri	In una ricerca deve essere possibile filtrare i libri in base all'albero della collocazione territoriale e in base all'albero delle materie. Deve inoltre essere possibile bloccare un filtro per le ricerche successive alla prima.
9.12	navigazione a faccette	Deve essere possibile tramite faccette filtrare i record selezionati a valle della ricerca. Deve essere possibile (senza assistenza tecnica specialistica) creare faccette da qualsiasi campo.
9.13	ricerca federata	Il sistema deve supportare funzioni di ricerca federata via Z39.50
9.14	servizi di ricerca	Il sistema deve fornire la possibilità di effettuare le ricerche, complete di tutti i filtri, tramite servizi Web o API e restituire il risultato in file strutturato riusabile da altri sistemi. In particolare deve essere garantita la ricerca del materiale "novità".
9.15	ricerca Solr-like	Il sistema deve fornire la possibilità di effettuare ricerche full text, hit highlighting, faceted search, raggruppamento dinamico, integrazione con le basi di dati, gestione di documenti "ricchi" (come documenti word e pdf). Deve inoltre rendere possibili ricerche distribuite e la replicazione dell'indice.
OPAC - REQUISITI OPZIONALI (qualora offerti)
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
9.16	browsing	Deve essere possibile scorrere e visualizzare gli indici per titolo, nomi, soggetti, editore, luogo di pubblicazione con le relative cross-reference.
9.17	mobile app	Il sistema deve fornire una app (scaricabile gratuitamente da Apple Store e Play Store) che permetta l'accesso da mobile al catalogo. L'utente autenticato potrà effettuare via mobile la prenotazione delle copie e il rinnovo dei prestiti in corso.
9.18	OpenURL	L'OPAC deve disporre di servizi per lo scambio di metadati con protocollo OpenURL utilizzando sia il proprio link resolver che eventualmente altri esterni.
9.19	ricerca semplice - mappa	Deve essere possibile effettuare una ricerca google-like all'interno del contenuto informativo del catalogo bibliografico trentino visualizzando i risultati su una mappa in base alla posizione dell'utente e alla collocazione delle biblioteche a cui appartengono le copie trovate dalla ricerca.

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 22 CAPITOLATO TECNICO

9.20
dati di dettaglio Deve essere possibile accedere ai dati di dettaglio relativi a contatti e orari di apertura.

4.1.10 DISCOVERY

DISCOVERY - REQUISITI MINIMI
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
10.1	servizi di discovery	Deve essere garantito un servizio di tipo Discovery che consenta di ricercare sull'indice centrale e accedere in modo unificato a tutte le risorse disponibili nelle biblioteche, sia analogiche sia digitali sia elettroniche anche a livello di singolo articolo per e-journals e a livello di singolo capitolo per gli e-books. la ricerca deve avvenire: -sul catalogo del CBT; - su un indice centrale personalizzabile di risorse selezionate dalle biblioteche e che abbia copertura internazionale e che contenga risorse elettroniche e a stampa anche a livello di singolo articolo o capitolo; - su repository e database locali.
10.2	indice centrale	Il discovery deve essere dotato di un indice centrale integrabile e personalizzabile da parte delle singole biblioteche.
10.3	armonizzazione metadati	Il discovery deve garantire l'armonizzazione dei metadati delle risorse provenienti dalle diverse fonti che alimentano l'indice.
10.4	import standard	Il discovery deve gestire l’importazione, tramite il protocollo OAI/PMH, dei dati provenienti da altri archivi.
10.5	harvesting	Il discovery deve permettere il metadata harvesting dagli archivi compatibili con gli standard OAI/PMH.
10.6	configurazione discovery	Deve essere possibile configurare e profilare il discovery per singola biblioteca (2 biblioteche).
DISCOVERY - REQUISITI OPZIONALI (qualora offerti)
ID	REQUISITO
10.7	import locale	Il discovery deve consentire l’import, anche secondo formati diversi da quelli standard, per acquisizione e integrazione di database gestiti localmente.

Nell’Allegato 1 “Discovery-Risorse elettroniche UNITN e FEM” si fornisce la lista delle collezioni/database di interesse.

4.1.11 Amministrazione e configurazione

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 23

AMMINISTRAZIONE & CONFIGURAZIONE - REQUISITI MINIMI
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
11.1	ruoli utenti "gestionali"	Deve essere consentita la personalizzazione dell'interfaccia in base all'utente o ruolo. (*)
11.2	ruoli utenti "cittadino"	Devono essere previsti sia per la versione OPAC sia per l'eventuale versione "mobile", i seguenti ruoli per l'accesso da parte del cittadino: - Cittadino Non Autenticato. Accede a tutte le funzioni di ricerca all'interno del catalogo - Cittadino Autenticato. Accede a tutte le funzioni di ricerca all'interno del catalogo e alle funzioni di visualizzazione dei propri dati anagrafici, della situazione dei suoi prestiti e alle funzioni di prenotazione della copia on-line.
11.3	permessi	Deve essere possibile assegnare i permessi a vari livelli di granularità (utente, gruppo) per funzione (Catalogazione, Circolazione...) e per tipologia di oggetti (fattura, ordine d'acquisto…).
11.4	comunicazioni verso i bibliotecari	Deve essere presente un mezzo di comunicazione monodirezionale che permetta agli operatori dotati degli opportuni permessi di rendere pubblici messaggi o notizie a tutta la comunità dei bibliotecari tramite l’utilizzo di una semplice "lavagna" delle informazioni.
11.5	macro	Viene richiesta la disponibilità di funzioni build in per automatizzare attività di amministrazione del sistema.
11.6	google analytics	Deve essere possibile l'utilizzo dei servizi di Google Analytics.
11.7	entità organizzative	Devono essere gestiti tutti i livelli organizzativi previsti dal Sistema bibliotecario Trentino: 1) il livello del Sistema Bibliotecario Trentino a) utenti condivisi a livello di sistema per le seguenti informazioni: nome, cognome, sesso, indirizzo di domicilio e indirizzo di residenza, dati di comunicazione (telefono, email), data di nascita; b) dati bibliografici: la catalogazione bibliografica va condivisa a livello di sistema in tempo reale; 2)il livello di aggregazione locale a)dati bibliografici di sistema locale o gestione associata di biblioteche, in particolare a fini di ricerche aggregate in modo efficace; 3) il livello di Biblioteca o istituzione a) gli utenti sono gestiti a livello di biblioteca con un “tipo utente” specifico per biblioteca che permette di applicare politiche di prestito e di gestione specifiche per la biblioteca; b) gli operatori agiscono a livello di biblioteca per le operazioni di Catalogazione bibliografica, aggiunta copia per la sede specifica; Inventariazione e Acquisizione; 4) il livello di Branch o sede, con indirizzo e orario specifico a) il prestito delle copie è gestito a livello di singola sede; il prestito fra le diverse sedi della biblioteca va gestito con tracciatura degli spostamenti fra le diverse sedi (“prestito interbranch”); il prestito fra le diverse biblioteche va gestito con

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 24 CAPITOLATO TECNICO

		procedure di prestito interbibliotecario; 5) il livello di Location o Sezione a) info sulla collocazione delle copie; 6) il livello di Sublocation, ripartizione dello scaffale (attualmente esistente solo per la mappe RFID)
AMMINISTRAZIONE & CONFIGURAZIONE - REQUISITI OPZIONALI (qualora offerti)
ID	REQUISITO	DESCRIZIONE DEL REQUISITO
11.8	anagrafe utenti (lettori)	Deve essere possibile l'interazione con sistemi istituzionali di anagrafe (carta di identità elettronica, codice fiscale, etc.).
11.9	Db utenti	Il Sistema deve garantire un database degli utenti implementabile sia manualmente sia tramite importazione da fonte/file esterno.
11.10	Single sign on	Devono essere implementati servizi di single sign-on con cataloghi o sistemi esterni

(*) A titolo indicativo si evidenziano i ruoli presenti nel sistema attuale:

a. Amministratore del sistema. Ha accesso a tutte le funzioni del gestionale con particolare riguardo alla creazione delle organizzazioni e degli operatori.

b. Gestore. E' il livello di governo centrale della Provincia Autonoma di Trento che ha accesso a tutte le funzioni con esclusione di quelle specifiche dell'Amministratore di Sistema.

c. Catalogatore Bibliografico Avanzato. Accede alla creazione e modifica di dati bibliografici.

d. Catalogatore Bibliografico Base. Accede solo alla creazione dei dati bibliografici.

e. Catalogatore di copia. Accede alle sole funzioni di gestione della copia della propria biblioteca.

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 25

f. Operatore Prestiti. Accede a tutte le funzioni di ricerca e circolazione della copia della propria sede.

g. Operatore Base. Accede alle sole funzioni di ricerca.

h. Amministratore Acquisti. Accede alle funzioni di creazione dei fondi e di gestione dell'ordine.

i. Operatore Acquisti. Accede alle sole funzioni di gestione dell'ordine i fondi ai quale è abilitato.

4.2 REQUISITI DELL’INFRASTRUTTURA

4.2.1 ACCESSO AI SERVIZI APPLICATIVI

1. L’architettura del sistema deve permettere di aggiungere funzionalità nel tempo in accordo con le esigenze reali.

2. L’aggiunta o modifica di funzionalità deve essere effettuata garantendo la continuità dei servizi applicativi (gli interventi sull’hw, sul middleware e sul sw devono avvenire a caldo o al di fuori degli orari di servizio), il mantenimento dei dati pregressi e le prestazioni. In generale la gestione del sistema non deve incidere in modo negativo sulla qualità dei servizi erogati.

3. Deve essere prevista la possibilità da parte del Committente di accedere con i propri strumenti di monitoraggio al sistema oggetto della fornitura per verificare la disponibilità del servizio in erogazione (monitoraggio di I livello).

4. L’url per accedere ai servizi offerti dal sistema deve essere configurabile; viene richiesto, per continuità con la situazione attuale, che l’accesso ai servizi avvenga allo stesso indirizzo dell’attuale.

5. L’accesso ai servizi applicativi deve essere possibile con il solo ausilio di una connessione a internet e di un browser (accesso esclusivamente web-based). L’accesso e l’utilizzo delle funzionalità sia di back-end sia di front-end deve essere garantito con sistemi operativi diversi mediante l’utilizzo dei browser più diffusi (Internet Explorer, Mozilla Firefox, Google Chrome, Safari, etc.).

6. Il sistema deve potersi integrare con sistemi di autenticazione federata basati su protocollo SAML2.0. (in linea con le specifiche tecniche descritte nell’Allegato 2 “AdC-Specifiche tecniche e di interfaccia per l’integrazione dei servizi nella Federazione” e nell’Allegato 3 “AdD-Specifiche tecniche e di interfaccia per l’integrazione dei servizi nella Federazione”) L’autenticazione dovrà essere garantita contemporaneamente sia ad utenti censiti nel sistema di autenticazione federata sia ad utenti censiti localmente al sistema.

7. Le credenziali di accesso, non utilizzate per un periodo superiore a 6 mesi, devono essere disattivate e riattivate solo a seguito di formale richiesta.

8. I meccanismi di autenticazione devono essere basati su password che vengono aggiornate con regolarità e che sono almeno di 8 caratteri.

9. Se offerto: deve essere possibile l’integrazione con LDAP per i profili applicativi (requisito opzionale).

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 26 CAPITOLATO TECNICO

4.2.2 SICUREZZA

4.2.2.1 Data Center

Il Data Center che deve ospitare e gestire l’insieme delle risorse hardware, software e gli archivi dei documenti conservati nell’ambito di erogazione dei servizi applicativi deve essere organizzato e amministrato nel rispetto delle norme italiane ed europee sulle misure di sicurezza e fornito di appositi sistemi di protezione logica e fisica al fine di impedire accessi non autorizzati.

Per la gestione del Data Center si richiede di considerare i parametri chiave della sicurezza, individuati nella check list della guida Procure Secure di ENISA (European Network and Information Security Agency), principalmente in relazione alla risposta ad incidenti di sicurezza, elasticità del servizio, gestione del ciclo di vita delle informazioni e gestione della compliance e delle vulnerabilità.

4.2.2.2 Controllo dei processi e log file

Il servizio proposto deve effettuare un continuativo e metodico processo di auditing al fine di monitorare ogni aspetto della gestione quotidiana del sistema informatico, in termini di accesso, di operazioni effettuate e eventi occorsi.

Il sistema deve consentire la registrazione sequenziale e cronologica delle operazioni effettuate, da un utente, da un amministratore o automatizzate, al fine di permettere l’analisi delle segnalazioni di errore, l’analisi delle operazioni fatte e dei responsabili di tali operazioni e la produzione di statistiche di utilizzo.

E’ richiesto l’invio (via ftp, syslog o altre modalità) dei log, sia di sistema che delle attività effettuate dagli utenti, sulla piattaforma di raccolta messa a disposizione dal Committente.

Relativamente ai log di accesso dei tecnici che amministrano il sistema, sarà cura del Contraente provvedere alle disposizioni di cui al Provvedimento del Garante Privacy “Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema - 27 novembre 2008” con particolare riguardo a quanto disposto nei punti 2.a. “Valutazione delle caratteristiche soggettive”; 2.b. “Designazioni individuali”; 2.c. “Elenco degli amministratori di sistema”; 2.d. “Servizi in outsourcing”; 2.e. “Verifica delle attività” e 2.f. “Registrazione degli accessi”.

4.2.2.3 Tracciabilità

Tutti gli eventi, compresa l’attività di consultazione, dovranno essere registrati dal sistema, garantendo la completa tracciabilità di ogni operazione. Gli utenti abilitati potranno in ogni momento visualizzare da interfaccia le registrazioni di tracciabilità.

Il servizio deve prevedere la tracciatura delle operazioni eseguite, sia da parte dell'utente esterno sia dalle procedure interne. Il Contraente deve inoltrare all’Ufficio Sicurezza del Committente le informazioni relative ad ogni incidente di sicurezza che interessi il sistema. Devono essere monitorati i tentativi di accesso da parte di sistemi che utilizzano credenziali non valide.

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 27

4.2.2.4 Policy

Gli interventi di manutenzione del sistema che verranno richiesti da Informatica Trentina dovranno rispettare, nelle sue varie fasi, le misure di sicurezza previste nei documenti consultabili all’indirizzo: xxxxx://xxx.xxxxxx.xx/Xxx-xxxxx/Xxxxxxxxxxxxxx-Xxxxxxx-x- Sicurezza/Sicurezza-delle-informazioni

4.2.3 BUSINESS CONTINUITY E DISASTER RECOVERY

1. Il Contraente deve fornire servizi di Disaster Recovery (DR) per garantire la continuità operativa in caso di problemi al Data Center Primario. Tali servizi devono soddisfare i seguenti parametri:

o RPO (Recovery Point Objective), ovvero il tempo massimo che intercorre tra la produzione del dato e la sua “messa in sicurezza”: si richiede un valore non superiore a 15 minuti;

o RTO (Recovery Time Objective), ovvero il tempo massimo per ripristino del servizio e il pieno recupero dell’operatività del sistema e dei processi: si richiede un valore non superiore a 8 ore lavorative.

2. Il Contraente dovrà supportare il Committente nel verificare, periodicamente (con periodicità annuale), la soluzione di DR attraverso lo svolgimento di sessioni di test.

3. Il Contraente dovrà mettere a disposizione strumenti per facilitare la gestione e la conduzione del test anche da remoto.

4. Se offerto: Il Data Center primario e i Data Center Secondari devono essere ubicati in aree con differente livello di rischio relativamente ai disastri ambientali. (requisito opzionale)

4.2.4 NORMATIVA VIGENTE E CERTIFICAZIONI

Il sistema deve rispondere ai requisiti definiti nei seguenti atti normativi:

1. D. Lgs. 7 marzo 2005, n. 82 c.d. “Codice dell’Amministrazione Digitale”.

2. Legge 9 gennaio 2004, n. 4, recante “Disposizioni per favorire l’accesso dei soggetti disabili agli strumenti informatici”.

3. X.X.X. 0 xxxxx 0000, x.00, xxxxxxx “Regolamento di attuazione della Legge 9 gennaio 2004,

n. 4, per favorire l’accesso dei soggetti disabili agli strumenti informatici”.

4. Decreto del Ministro per l’Innovazione e le Tecnologie del 8 luglio 2005 recante “Requisiti tecnici e i diversi livelli per l’accessibilità agli strumenti informatici”.

5. Direttiva 27 luglio 2005 della Presidenza del Consiglio dei Ministri – Dipartimento per l’Innovazione e le Tecnologie recante “Qualità dei servizi online e misurazione della soddisfazione degli utenti”.

6. Articolo 23 della L.P. 8/2003 “Disposizioni per l’attuazione delle politiche a favore delle persone in situazione di handicap” che richiede la soddisfazione dello standard W3C e linee guida WCAG per l’accessibilità. Il sistema deve cioè essere in grado di generare pagine in standard W3C, visualizzabili anche da browser meno recenti e compatibili sia con le tecnologie assistive sia con le funzioni di accessibilità dei browser e degli altri programmi utente.

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 28 CAPITOLATO TECNICO

7. Il sistema deve rispettare ogni altro requisito imposto dalla normativa vigente o sopravvenuta.

8. Se offerto: il Data Center deve essere certificato all’ultima versione della norma ISO 27001 (anno 2013) (requisito opzionale).

4.2.5 AMBIENTI DI RIFERIMENTO

Oltre all’ambiente di Esercizio dovrà essere reso disponibile un ambiente di Staging, con caratteristiche analoghe all’ambiente di Esercizio, sul quale dovrà essere possibile effettuare prove e simulazioni (ad esempio di operazioni massive) da parte di utenti autorizzati. L’ambiente di Staging dovrà poter essere a richiesta popolato e successivamente aggiornato con dati dell’ambiente di Esercizio (opportunamente trattati secondo le norme di sicurezza e privacy).

4.2.6 GESTIONE DEI DATI

4.2.6.1 Protezione dei dati

1. Il Contraente deve conservare tutti i dati presso locali tecnici di cui abbia la piena disponibilità, per tutta la durata del contratto.

A norma di quanto previsto dagli articoli 42, 43, 44 e 45 del D.Lgs. 196/03, il Contraente deve garantire che i dati personali trattati durante l’esecuzione dei servizi di cui al presente Capitolato verranno conservati in uno o più stati che assicurano un livello di protezione adeguato ovvero:

• i Paesi dell'Unione europea,

• i Paesi individuati con le decisioni previste dagli articoli 25, paragrafo 6, e 26, paragrafo 4, della direttiva 95/46/CE del Parlamento europeo e del Consiglio, del 24 ottobre 1995, con le quali la Commissione europea constata che un Paese non appartenente all'Unione europea garantisce un livello di protezione adeguato.

In alternativa, il Contraente situato in un paese diverso da quelli indicati nei punti precedenti, secondo quanto disposto dall’Autorità Garante per la Privacy con giusta delibera nr. 35 del 27 maggio 2010 (Gazzetta Ufficiale n. 141 del 19 giugno 2010) deve sottostare alle clausole contrattuali tipo di cui alla decisione della Commissione europea del 5 febbraio 2010, n. 2010/87/UE e sulla base dei presupposti indicati nella medesima decisione (art. 6 della decisione della Commissione europea del 5 febbraio 2010, n. 2010/87/UE).

Tale requisito dovrà essere soddisfatto anche nel caso in cui il Contraente sia legalmente stabilito nell'Unione europea ma affidi il trattamento dei dati personali gestiti nell’ambito del servizio oggetto del presente capitolato ad un soggetto stabilito in un paese terzo che non rientri tra quelli indicati nei punti precedenti.

2. Se il servizio viene fornito in ambiente multi–tenant deve essere garantito l’isolamento dei dati.

3. Devono essere configurate, schedulate e gestite le attività di back-up e restore (quando richiesto) di tutti i dati oggetto del servizio.

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 29

4. Deve essere adottata senza oneri per il Committente e per tutto il periodo di durata del servizio, ogni misura idonea (art. 31 del Codice Privacy) a migliorare la sicurezza delle informazioni e dei dati trattati per l’erogazione del servizio.

5. Il Contraente si obbliga a rendere pubbliche le informazioni relative a chi può accedere ai dati e a quali tipologie di accessi e quali controlli sono in atto sui possibili accessi ai dati del Committente.

4.2.6.2 Portabilità dei dati e “uscita contrattuale”

1. Il Contraente dovrà garantire un servizio avente caratteristiche tecnologiche che diano garanzia di portabilità dei dati nei casi di passaggio ad altro Appaltatore, al termine del contratto, o per altre cause di interruzione del rapporto contrattuale prevedibili e non.

6. Deve essere garantito il trasferimento dei dati presso la Committente (o in ambiente accessibile al Committente) periodico, a richiesta o in caso di termine, per qualsiasi causa, del contratto. Il tal senso dovrà essere previsto:

• l’esportazione dei dati in un formato “piatto” e utilizzabile dal Committente;

• la documentazione descrittiva dei formati di esportazione. Dovrà essere garantito il formato Marc21 per tutte le informazioni che lo prevedono;

• la documentazione con i requisiti, le configurazioni e le modalità per l’accesso alle aree in qui vengono depositati i dati scaricati;

• la procedura automatica che effettua l’esportazione dei dati.

2. Durante la fase di chiusura, l'utenza dovrà poter continuare nello svolgimento delle attività sul sistema e non dovrà subire alcun peggioramento del servizio erogato.

3. Al termine del contratto, il Contraente avrà l'obbligo di mettere a disposizione del Committente tutti i documenti correttamente conservati nonché dovrà, in ogni caso, garantire l’opportuno affiancamento, all’Appaltatore subentrante sia a seguito di nuova aggiudicazione, sia nei casi previsti di risoluzione per inadempimento o recesso anticipato da parte del Committente.

4. Nel momento di avvio della procedura, il Contraente dovrà redigere una valutazione dei rischi conseguenti alla migrazione al fine di pianificare eventuali operazioni di rientro.

5. In caso di richiesta da parte del Committente di definitiva cancellazione fisica di dati al termine del contratto, deve essere garantito che tali dati non possano essere recuperati.

6. Al termine del contratto, deve essere garantita la conservazione e l’accesso ai dati per tutto il tempo necessario a completare l’operazione di migrazione, le cui tempistiche saranno concordate tra le parti.

4.2.6.3 Dati Aperti e Linked Data

Ai sensi dell’articolo 52 del Codice dell’Amministrazione Digitale (CAD), nella fornitura di prodotti e/o servizi che comportino la raccolta e la gestione di dati pubblici, tali dati, i relativi metadati, gli schemi delle strutture di dati e delle relative banche dati, devono poter essere acceduti telematicamente, nel rispetto del principio di neutralità tecnologica, e predisposti per essere riutilizzati da parte di persone fisiche e giuridiche nel rispetto dei principi e delle

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 30 CAPITOLATO TECNICO

raccomandazioni dell’agenda e delle linee guida nazionali per la valorizzazione del patrimonio informativo pubblico rilasciate dall’Agenzia per l’Italia Digitale.

La soluzione in oggetto dovrà quindi essere predisposta e consentire la produzione di dati di tipo aperto in forma disaggregata e, ove possibile, tabellare in modo da consentire all’amministrazione e/o al Committente di avere la piena titolarità dei dati in contenuti nel sistema. Tutte le informazioni devono essere memorizzate nel sistema informativo in modo da potere essere successivamente pubblicate in formato aperto (XML e/o JSON) oltre che MARC21 e con una licenza aperta (CC-BY o CC0), nelle modalità previste dalle Linee Guida Provinciali in tema di Open data (delibera della Giunta della Provincia Autonoma di Trento n° 2858 del 27/12/2012 e successivo aggiornamento delibera n° 2449 del 30/12/2015).

Le funzionalità per la produzione dei dati nel formato aperto non deve avere dei costi aggiuntivi e deve essere possibile senza lo sviluppo di codice (es. mediante configurazioni del sistema da back-office).

In base alle necessità attuali, il sistema deve permettere la pubblicazione in formato aperto dei seguenti insiemi di dati:

• anagrafica delle biblioteche del sistema CBT;

• dati bibliografici del Catalogo Bibliotecario Trentino;

• dati statistici sui prestiti.

Se offerto: si richiede la presenza di uno strumento che permetta l'espansione e la personalizzazione del Catalogo Bibliografico Trentino con tecnologie Linked Data da parte di terzi (requisito opzionale).

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 31

5 CONDUZIONE DEL SERVIZIO

5.1 RIUNIONI

Le riunioni saranno sostenute dietro semplice richiesta (con un almeno 5 giorni di preavviso) di Informatica Trentina o del Contraente. Parimenti, i documenti da discutere nelle riunioni saranno inviati ai partecipanti con almeno 2 giorni di anticipo.

Il Contraente sarà responsabile della preparazione e della distribuzione dei verbali di tutte le riunioni sostenute nel corso dell’attività. I verbali dovranno chiaramente riportare le conclusioni, gli accordi e le azioni concordate (action item) risultanti dalla riunione.

5.2 GESTIONE ISSUE

Il Contraente manterrà aggiornata e renderà disponibile su richiesta una Lista degli issue che riporti tutte le azioni concordate con Informatica Trentina. Tali issue andranno redatti secondo il seguente schema.

ID	Identificativo nel formato T-aammgg- nn: - T = Tipo: A(ction), I(ssue) - aa = anno - mm = mese - gg = giorno - nn = progressivo
Data Apertura	Data di apertura
Origine	Chi ha originato la richiesta
Stakeholders	Chi è coinvolto
Descrizione	Descrizione dettagliata
Soluzione proposta	Descrizione dettagliata della soluzione proposta e delle motivazioni a supporto
Priorità	alta/media/bassa
Stato	Aperta Approvata chiusa
Data pianificata	data di chiusura prevista
Note	Commento
Data chiusura	data chiusura effettiva
Decisioni adottate	Decisioni adottate, a cura del Responsabile del contratto IT

Per la gestione di ciascun issue deve essere seguita la seguente procedura:

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 32 CAPITOLATO TECNICO

1. il Contraente descrive l’issue riscontrato analizzando le possibili soluzioni con l’indicazione della soluzione proposta e le relative motivazioni a supporto;

2. il Contraente invia al Responsabile del contratto IT, secondo lo schema proposto, la documentazione ad esso relativa;

3. il Responsabile del contratto IT approverà o respingerà la proposta di soluzione motivandone le ragioni;

4. il Contraente, a valle dell’approvazione scritta, avvierà le attività concordate per risolvere l’issue.

La lista sarà aggiornata ad ogni riunione.

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 33

6 ATTIVITA’ RICHIESTE

6.1 PRESA IN CARICO DEL SERVIZIO

6.1.1 POPOLAMENTO DEL SISTEMA CON I DATI ESISTENTI (MIGRAZIONE)

La Provincia Autonoma di Trento si è dotata negli anni passati di un applicativo per la gestione del catalogo bibliografico della Provincia Autonoma di Trento, acquistato in licenza d’uso. I dati di tale sistema verranno resi disponibili (secondo tracciati in formato standard Marc 21 per le informazioni che lo prevedono e secondo tracciati definiti in accordo con il Contraente negli altri casi) e dovranno da questi essere utilizzati per la migrazione-popolamento iniziale dell’applicativo oggetto della fornitura.

Il servizio di migrazione-popolamento consiste in tutte quelle attività, strumenti e procedure da mettere in atto per consentire, agli utenti del Committente, di fruire delle nuove funzionalità del Catalogo Bibliografico in continuità con tutti i dati e le informazioni presenti nel sistema preesistente.

Il Contraente dovrà mettere a disposizione tutte le procedure automatizzate necessarie per ridurre al minimo gli eventuali disservizi; l’esecuzione di tutti i processi e delle attività dovrà essere verificata preventivamente nell’ambiente di staging al fine di ridurre al minimo il fattore imprevisti.

Il Contraente dovrà fornire il Piano di progetto riportante le attività di migrazione di dettaglio. Le attività di migrazione devono avere durata massima di 6 mesi.

Nel piano dovrà essere indicato il tempo massimo di fermo del sistema.

Le modalità di svolgimento di dettaglio delle singole attività verranno condotte in accordo la Committente.

6.1.2 FASE PILOTA

Deve essere prevista una fase pilota di utilizzo da parte di un sottoinsieme di utenti, in modo tale da verificare la configurazione e il corretto funzionamento del sistema.

6.1.3 COLLAUDO E ATTIVAZIONE DEL SERVIZIO

Alla conclusione dell’attività di cui al paragrafo precedente verrà effettuato il collaudo, comprendente test di carico, del Sistema Informativo CBT e redatto il verbale di collaudo sottoscritto dalle Parti.

Si richiede al Contraente di progettare, in collaborazione con il Committente, i test di carico coerentemente con gli strumenti utilizzati dal Committente, indicando i parametri principali da valutare/confrontare fra i diversi “run” di test. Inoltre, il Contraente dovrà garantire il necessario supporto per l’esecuzione dei test di carico. Le performance del sistema fanno parte dei parametri qualitativi di valutazione del software in sede di collaudo; pertanto, il Contraente dovrà essere in grado di verificare che le modifiche al software non abbiano impatti degradanti sui tempi di risposta e sulle risorse utilizzate per mantenere in esecuzione l’applicazione.

I servizi oggetto del presente capitolato dovranno essere attivi in esercizio entro un anno dalla firma del contratto.

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 34 CAPITOLATO TECNICO

6.2 FORMAZIONE

Il Contraente dovrà garantire, tramite adeguate sessioni formative, l’addestramento degli utenti al fine di consentire l’utilizzo in autonomia delle funzionalità del nuovo sistema di gestione del Catalogo Bibliografico Trentino.

I corsi di formazione ed addestramento dovranno essere erogati dal Contraente con propri docenti e dovranno tenersi in lingua italiana.

Qualora la formazione sia svolta in aula, le aule e le apparecchiature saranno messe a disposizione dalla Committente. Il Contraente dovrà configurare le apparecchiature presenti nelle aule e fornire idonea documentazione riguardante la definizione di tale configurazione.

L’erogazione dei corsi avverrà secondo un calendario definito e concordato con la Committente.

Il Contraente dovrà predisporre e fornire adeguato materiale didattico e documentazione a supporto di ciascuna tipologia di intervento formativo.

Oltre alla documentazione inerente la fase di addestramento e formazione dovrà essere consegnata, e mantenuta progressivamente aggiornata, tutta la manualistica per l’utilizzo in autonomia delle funzionalità del sistema.

La formazione dovrà essere erogata prima dell’avvio del sistema in produzione e si potrà prevedere, in accordo tra le parti, un eventuale periodo di utilizzo delle funzionalità da parte degli utenti in ambiente di staging.

6.3 MANUTENZIONE DEL SOFTWARE, DELL’INFRASTRUTTURA TECNOLOGICA E ASSISTENZA UTENTE

Il Servizio di manutenzione del software del Sistema Informativo CBT comprende:

⚫ la manutenzione correttiva, per la rimozione di cause ed effetti dei malfunzionamenti delle procedure e dei programmi. Sono ricompresi in tale tipologia sia le cause dei malfunzionamenti che gli effetti degli stessi che sono da ripristinare in quest’ambito.

⚫ la manutenzione ordinaria, che consiste in interventi attuati per adattare i programmi e le procedure alle mutate esigenze dell’utente; a ottimizzare le prestazioni e la qualità delle procedure elaborative anche con riferimento all’ambiente tecnologico; in interventi di realizzazione software “una tantum” per l’estrazione di dati o la produzione di report. Rientrano in tale categoria gli interventi che richiedono un effort di implementazione non superiore ai 6 giorni lavorativi;

⚫ la manutenzione evolutiva, che consiste in interventi attuati per adattare i programmi e le procedure alle mutate esigenze dell’utente. Rientrano in tale categoria gli interventi che richiedono un effort di implementazione superiore ai 6 giorni lavorativi;

⚫ il supporto specialistico, erogato sia presso gli uffici di Informatica Trentina che presso le sedi della Provincia Autonoma di Trento e delle biblioteche del CBT sparse sul territorio provinciale. Nel servizio è compresa l’attività di analisi finalizzata alla

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 35

migliore definizione degli interventi di manutenzione del software. Tali attività richiedono una conoscenza approfondita dell’architettura software e dovranno essere svolte dal progettista del sistema;

⚫ l’assistenza e supporto all’utente, consiste nel recepire la richiesta dell’utente, valutarla, fornire all’utente il supporto richiesto e tutte le indicazioni e informazioni approfondite e dettagliate per un efficace utilizzo del sistema.

Il Servizio di manutenzione del software contempla il servizio di gestione della configurazione che comprende il complesso delle attività finalizzate ad identificare, controllare e tracciare le versioni di ciascun elemento software che compone il sistema e la relativa documentazione.

Tutta la documentazione, tecnica e manualistica utente per l’utilizzo delle funzionalità e dei processi, dovrà essere in lingua italiana e dovrà essere tenuta costantemente aggiornata, a cura del Contraente, in funzione dei cambiamenti apportati al sistema.

L’erogazione dei servizi professionali relativi al servizio di manutenzione dell’infrastruttura tecnologica sono attivati automaticamente all’atto della sottoscrizione del contratto. Il Contraente dovrà fornire, su richiesta della Committente e di prassi nella finestra di servizio standard, il supporto atto a garantire il corretto funzionamento dell’infrastruttura tecnologica, eventualmente operando sui sistemi secondo le modalità ed il rispetto delle norme di sicurezza riportate nel presente capitolato tecnico e concordando preventivamente con la Committente qualsiasi eventuale modifica all’architettura definita.

Le richieste relative alla manutenzione del software, dell’infrastruttura e all’assistenza all’utente ed i relativi tempi di risoluzione verranno tracciati nello strumento BMC Remedy ITM Suite.

Orari e finestre del servizio

• Per i Servizi di manutenzione del sistema relativi a problemi non bloccanti la finestra di erogazione è relativa ai giorni lavorativi dalle 08:00 alle 18:00. Sono lavorativi i giorni da lunedì a venerdì non festivi.

• Per i Servizi di manutenzione del sistema relativi a problemi bloccanti la finestra di erogazione è 14x6 dal lunedì al sabato dalle 08.00 alle 22.00 esclusi i festivi del Comune di Trento.

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 36 CAPITOLATO TECNICO

6.3.1 ATTORI DEL PROCESSO DI MANUTENZIONE

E N

Attori e processi

XX

Xxxxxxx Xxxxxxx Xxxx - XXX Xxxxxxx 0x xxx

(XX)

SS

Service Support 2° liv (fornitore)

TS

Technical Support 3° liv (IT)

AS

Application Support 3° liv (Fornitore)

CG

Change Group (IT )

U T

inserimento

T E

INC User Service Request

richiesta di modifica

inserimento

Manifest

INC User Service Restoration

modifica sw urgente

valutazione/ esecuzione

Inserimento da altri canali

correttiva

CRQsw

Fornitore

TAS

CRQ

CRQ

Deploy(*)

RLM(*)

TAS (*)

INC Access Mangement

Gestisce richiesta

TAS

note:

⚫ TAS(*): il task aperto dal Contraente verso IT è un’eccezione a copertura di eventuale richieste di verifiche/interventi su componenti che afferiscono al DataCenter IT

⚫ RLM(*): il ticket di Release, comprenderà tutte le modifiche avvenute sul servizio ed è di sola utilità/competenza di Informatica Trentina come contenitore di tutte le modifiche occorse

⚫ CRQ Deploy(*): prevede uno step di approvazione del Service Owner IT in quanto deve essere sempre informato sulle modifiche al servizio.

6.3.2 Difformità nell’erogazione del servizio di manutenzione

La chiusura di un ticket o di un task deve avvenire nel rispetto del processo produttivo adottato (effettuazione dei test negli ambienti previsti, adozione delle linee guida di sviluppo del sistema ed aderenza all’architettura software descritta nella documentazione del sistema). L’evidenza di

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 37

chiusura di un ticket o di un task senza il completamento di tutti i passi previsti dal processo produttivo, della modifica di informazioni di categorizzazione, tracciatura o limiti temporali, ovvero la presenza di reclami da parte del cliente di IT che, ad esempio, evidenzia il persistere di un problema nonostante gliene sia stata notificata la risoluzione, comporta la contestazione di una difformità nella gestione dell’intervento relativo, attraverso la richiesta da parte di Informatica Trentina di apertura di uno specifico ISSUE, secondo le modalità descritte nel paragrafo 5.2, ed a cui il Contraente è tenuto comunque a trovare una rapida soluzione. Il Contraente può tempestivamente presentare per iscritto le proprie giustificazioni sulla contestazione mossagli ed in tal caso si seguiranno le modalità previste per l’escalation nel paragrafo 2.1, oppure accettare la contestazione e proporre una soluzione al problema contestato.

Alla gestione delle difformità è applicato lo SLA di cui al paragrafo 7.1.6.

6.4 RICONSEGNA DEI DATI E CHIUSURA DEL SERVIZIO

Alla conclusione del periodo di erogazione del servizio verrà richiesta al Contraente la riconsegna dei dati e della documentazione del Sistema Informativo CBT al Committente.

Per la chiusura del servizio il Contraente si occuperà dell’estrazione dei dati e darà supporto per il necessario (passaggio di consegne) affiancamento da erogarsi in un arco temporale concordato con il Committente secondo un piano di lavoro che tenga conto delle necessità operative. La conclusione positiva del servizio di riconsegna dei dati e chiusura del servizio sarà formalizzato tramite verbale. Durante questa fase andranno soddisfatti i requisiti inerenti

l’ ”uscita contrattuale” di cui al paragrafo 4.2.6.2.

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 38 CAPITOLATO TECNICO

7 MANUTENZIONE E SVILUPPI SOFTWARE - SERVICE LEVEL AGREEMENT

La determinazione del raggiungimento dei livelli di servizio previsti per la fornitura si basa su un modello di riferimento la cui struttura è di seguito illustrata.

Impatto del servizio sui processi di business del Clienti

Nel Service Catalogue di Informatica Trentina è formalizzata l'esistenza di differenti livelli di importanza fra i servizi in erogazione, dipendentemente dall'impatto che ciascun servizio può avere sui processi di business dei Clienti che lo utilizzano.

Il servizio CBT, oggetto della presente capitolato, è classificato nel Service Catalogue come: L3, servizio con impatto moderato/limitato, con un business time (finestra oraria di disponibilità del servizio) pari a 14x6, ovvero dal lunedì al sabato dalle 08.00 alle 22.00 esclusi i festivi del Comune di Trento (l’assistenza all’utente dovrà essere invece garantita 10x5, ovvero su una finestra oraria dal lunedì al venerdì dalle 08.00 alle 18.00 esclusi i festivi del Comune di Trento).

Nei punti seguenti verranno pertanto riportati gli agreement ed i livelli di servizio richiesti per tale livello di criticità.

Agreement

Gli Agreement rappresentano un macroelemento di controllo che consente una verifica rapida e significativa di una situazione complessa. Sono formati da più misuratori, che prendono il nome di Service Target e che concorrono insieme al raggiungimento di un obiettivo di business. Ciascun Agreement è caratterizzato dall’avere una percentuale di compliance da raggiungere, cioè di aderenza dei risultati rispetto al complesso dei Service Target collegati.

Ciascun Agreement è composto da uno o più Service Target, ciascuno dei quali ha un peso specifico nella costituzione dell’Agreement stesso.

Service Target

I Service Target definiscono singoli obiettivi da raggiungere puntualmente e si differenziano per la tipologia della misurazione:

• Tempo di percorrenza di un ticket

• Disponibilità di un sistema

• Compliance rispetto ad un obiettivo.

I Target si applicano puntualmente ad una singola situazione o ad un singolo evento. Ad esempio si applicano ad un singolo ticket, misurandone il tempo di percorrenza rispetto ad un obiettivo prefissato o alla singola indisponibilità di un servizio.

Ciascun Service Target è caratterizzato dall’avere:

• un business time, cioè finestra di servizio entro la quale misurare l'indicatore

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 39

• un obiettivo da raggiungere

• una o più condizioni di innesco

• una o più condizioni di partenza

• una o più condizioni di stop

• una o più condizioni di sospensione.

Modalità di calcolo delle priorità

Ad un ticket di Incident è associata una priorità calcolata in base alla combinazione dei valori di Impatto e Urgenza dichiarati in fase di inserimento.

In generale:

• l’impatto viene inizialmente valorizzato secondo quanto configurato in Service Catalogue:

o con l’impatto associato sul servizio L3;

• l’urgenza viene valorizzata secondo quanto dichiarato dall’utente e comunque con i seguenti vincoli:

o se il malfunzionamento è bloccante l’urgenza assume il livello 1-Critical;

o se il malfunzionamento è parzialmente bloccante l’urgenza assume il livello 2-High;

o se l’utente chiamante è VIP l’urgenza assume il livello 2-High; La priorità viene determinata per i servizi applicativi in base a questo schema:

		Impatto
		1- Extensive	2 - Significant	3 - Moderate	4 - Minor
Urgenza	1-Critical	Critical	Critical	High	High
	2-High	Critical	High	High	Medium
	3-Medium	High	Medium	Medium	Medium
	4-Low	Low	Low	Low	Low

Condizioni di sospensione nei rapporti con l’utenza

Il calcolo dei livelli di servizio può essere sospeso nelle seguenti condizioni:

• attività sospese per l’assenza o la non disponibilità dell’utente, preventivamente informato, che impedisca lo svolgimento dell’intervento;

• attività sospese a fronte della non disponibilità dei beni oggetto dell’intervento, nel caso di forniture di competenza di PAT.

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 40 CAPITOLATO TECNICO

Penali

La valorizzazione degli importi delle penali è attuata su base trimestrale e avviene singolarmente per ciascuno Agreement.

7.1.1 SLA PER MANUTENZIONE CORRETTIVA

In riferimento ai tempi chiusura degli interventi di manutenzione correttiva e di quelli in garanzia vengono applicati i livelli di servizio (SLA) riportati di seguito.

UC21 - Agreement Manutenzione software correttiva

Gli interventi sono registrati attraverso ticket di tipo Change o Task collegati a ticket di tipo Incident

a cui è associata una priorità definita in ragione dell’”Urgenza” dichiarati in fase di inserimento.

L’ Agreement Manutenzione software correttiva misura la capacità di correggere, nei tempi adeguati, il software difettoso.

Periodicità Compliance

Target

trimestre solare 85% per i servizi L3

	Target Interventi di manutenzione correttiva	L3	Peso
	UCst21 Tempo di esecuzione Change sw correttiva	18h	30%
	UCst22 Tempo di esecuzione Change sw correttiva pianificata	entro data pianificata	15%
	Target Interventi di Investigazione e diagnosi	L3	Peso
	UCst23 Tempo di chiusura Task Critical da Incident entro	12h	10%
	UCst24 Tempo di chiusura Task High da Incident entro	16h	20%
	UCst25 Tempo di chiusura Task Medium da Incident entro	24h	15%
	UCst26 Tempo di chiusura Task Low da Incident entro	40h	5%
	UCst37 Tempo di chiusura Task data concordata	Data concordata	5%

Descrizione Service target L’indicatore evidenzia il tempo intercorrente tra la data di ricevimento della richiesta di intervento e la data di chiusura dell’intervento stesso.

I dati rilevati per ciascun intervento attraverso lo strumento BMC Support sono di seguito descritti:

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 41

Condizione di innesco descrive gli attributi che in BMC Support caratterizzano e classificano l’intervento (Change o Task)

Condizione di partenza descrive gli elementi che determinano la rilevazione della data ed il tempo di acquisizione della richiesta di manutenzione

Condizione stop descrive gli elementi che determinano la rilevazione della data di chiusura dell’intervento di manutenzione

Condizione di sospensione descrive gli elementi che eventualmente determinano una sospensione nella misurazione dell’intervallo temporale di esecuzione dell’intervento.

Di seguito gli elementi tecnici di riferimento per la corretta identificazione delle condizioni di controllo dei tempi nell’ambito del sistema BMC Support.

UCst21 Change sw correttiva

Condizione di innesco	Condizione di partenza	Condizione di stop Condizione di sospensione
‘Ticket Type’= “Change” AND ‘Operational’ = “Change/Software/Correttiva” AND 'Priority' = "Critical" AND 'ServiceCI' =/LIKE <Servizio Manutenuto> AND ‘Status’ <> “Cancelled”	Status >= Request for Authorization AND ‘ASGRP’ = <Gruppo del fornitore>	Change Request Status' ‘ASGRP’ != = "Completed" OR <Gruppo del 'Change Request Status' fornitore> = "Closed"

UCst22 Change sw correttiva pianificata

Condizione di innesco	Condizione di partenza	Condizione di stop	Condizione di sospensione
Ticket Type’= “Change” AND ‘Operational’ = “Change/Software/Correttiva” AND 'Priority' != "Critical" AND 'ServiceCI' =/LIKE <Servizio Manutenuto> AND ‘Status’ <> “Cancelled”	Status >= Request for Authorization AND ‘ASGRP’ = <Gruppo del fornitore>	Change Request Status' = "Completed" OR 'Change Request Status' = "Closed"	‘ASGRP’ != <Gruppo del fornitore>

UCst23 - UCst24 – UCst25 - UCst26 – Ucst37 Interventi di Investigazione e diagnosi

Condizione di innesco Condizione di partenza Condizione di stop Condizione di sospensione

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 42 CAPITOLATO TECNICO

UCst23 - UCst24 – UCst25 - UCst26 ‘Ticket Type’= “Task” AND ‘Request Ticket Type’ = “Incident” AND 'Product Name' /LIKE <Product Manutenuto> AND 'Priority' = (“Critical” OR “High” OR “Medium” OR “Low”) AND 'StatusReasonSelection <> “Cancelled” AND ‘Scheduled End Date’ = NULL	Status >= Assigned AND ‘Assignee Group’ = <Gruppo del fornitore>	Status >= Closed	‘Assignee Group’ != <Gruppo del fornitore>
Ucst37 Ticket Type’= “Task” AND 'Product Name' /LIKE <Product Manutenuto> AND ‘Scheduled End Date’ <> NULL AND 'StatusReasonSelection <> “Cancelled” AND	Status >= Assigned AND ‘Assignee Group’ = <Gruppo del fornitore>	Status >= Closed	‘Assignee Group’ != <Gruppo del fornitore>

* Condizioni di sospensione

▪ interruzioni del servizio schedulate per il rilascio programmato di modifiche o aggiornamenti e comunicate al Cliente con un preavviso di almeno 1 giorno solare o attraverso un calendario dei rilasci condiviso;

▪ interruzioni di servizio richieste dal Cliente;

▪ esecuzione tempestiva di modifiche o aggiornamenti richiesti e/o necessari al corretto funzionamento dei sistemi eseguite di norma dopo le ore 17.00 o nei fine settimana. In caso di fermo la Società dovrà preavvisare con il massimo anticipo possibile il Cliente e sarà autorizzata a procedere alla sospensione anche in caso di silenzio di quest’ultimo;

▪ interruzioni di servizio dovute a causa di forza maggiore quali, a titolo indicativo e non esaustivo:

- fermi, degradi o malfunzionamenti causati da software di base e/o di ambiente non più supportati dal fornitore e non sostituiti dalla Società per esplicita decisione del Cliente;

- fermi, degradi o malfunzionamenti causati da software applicativo non prodotto dalla Società o da servizi non progettati dalla Società, non supportati dai relativi fornitori;

- disservizi indotti da terze Parti contraenti con il Cliente;

- volumi di servizio eccedenti la tolleranza prevista;

- ritardi indotti da operazioni dell’utente o da richiesta del Cliente di prolungamento del servizio, qualora non a titolo oneroso;

- indisponibilità dell’Utente finale o indisponibilità dell’hardware o del software messo a disposizione a cura del Cliente;

- disastro;

- sciopero.

ad interruzioni di erogazione dell’energia elettrica o ad altri fatti non imputabili alla Società, sempre che, una volta rimossi tali impedimenti, la Società non abbia indotto, per fatto o colpa ad essa addebitabile, ulteriori ritardi nel ripristino del servizio.

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 43

7.1.2 SLA PER MANUTENZIONE ORDINARIA ED EVOLUTIVA

Vengono applicati livelli di servizio (SLA), come riportati di seguito, in riferimento ai tempi di esecuzione delle attività di manutenzione evolutiva richieste.

UC22 - Agreement Manutenzione e sviluppi software

L’ Agreement Manutenzione e sviluppi software misura la capacità di valutare e realizzare la manutenzione, l’evoluzione e lo sviluppo di un software.

Periodicità trimestre solare Compliance 95%

Target

	Target	Peso
	UCst27 Tempo di valutazione Change software entro 5gg	25%
	UCst28 Tempo di implementazione Change software (entro la data concordata)	75%

Di seguito gli elementi tecnici di riferimento per la corretta identificazione delle condizioni di controllo dei tempi nell’ambito del sistema BMC Support.

UCst27 Valutazione Change software

Condizione di innesco	Condizione di partenza	Condizione di stop	Condizione di sospensione
‘Ticket Type’= “Task” AND ‘Request Ticket Tytpe’ = “Change” AND 'Product Name' /LIKE <Product Manutenuto> AND ‘Operational’ = “Task/Change/Valutazione intervento” AND ‘Status Reason’ <> “Cancelled”	Status >= Assigned AND ‘Assignee Group’ = <Gruppo del fornitore>	Status >= Closed	‘Assignee Group’ != <Gruppo del fornitore>

UCst28 Implementazione Change software

Condizione di innesco	Condizione di partenza	Condizione di stop	Condizione di sospensione
‘Ticket Type’= “Task” AND ‘Request Ticket Tytpe’ = “Change” AND 'Product Name' /LIKE <Product Manutenuto> AND ‘Operational’ = “Task/Change/Esecuzione intervento” AND ‘Status Reason’ <> “Cancelled”	Status >= Assigned AND ‘Assignee Group’ = <Gruppo del fornitore>	Status >= Closed	‘Assignee Group’ != <Gruppo del fornitore>

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 44 CAPITOLATO TECNICO

7.1.3 SLA PER IL SERVIZIO DI SUPPORTO SPECIALISTICO

In riferimento alla qualità del servizio di supporto specialistico vengono applicati i livelli di servizio (SLA) riportati di seguito.

UCSS - Agreement Servizio di supporto specialistico

L’ agreement Servizio di supporto specialistico misura la tempestività della risposta ad una richiesta di supporto specialistico.

Periodicità trimestre solare

Compliance 95%

Service Target supporto specialistico

ID	Target	Tempo massimo previsto	Peso
UCss01	Tempo di attivazione degli interventi di supporto specialistico	5 gg	25%
UCss02	Tempo di conclusione attività di analisi	Data concordata	75%

Di seguito gli elementi tecnici di riferimento per la corretta identificazione delle condizioni di controllo dei tempi.

UCss01 Attivazione degli interventi di supporto specialistico

Condizione di innesco	Condizione di partenza	Condizione di stop	Condizione di sospensione
Trasmissione da parte di Informatica Trentina della e- mail di richiesta.	La data di ricezione da parte del Contraente della e-mail di richiesta di Informatica Trentina	La data di erogazione del supporto specialistico richiesto attestata dalla e-mail di risposta del Contraente.	La data indicata nella mail di sospensione trasmessa da Informatica Trentina

UCss02 Implementazione attività di analisi

Condizione di innesco	Condizione di partenza	Condizione di stop	Condizione di sospensione
Trasmissione da parte di Informatica Trentina della e- mail di richiesta.	La data di avvio concordata rilevata dalla comunicazione di attivazione	La data di conclusione concordata rilevata dalla comunicazione di conclusione attività del Contraente	La data indicata nella mail di sospensione trasmessa da Informatica Trentina

7.1.4 SLA per il servizio di assistenza e supporto all’utenza

In riferimento alla qualità del servizio di assistenza e supporto all’utenza vengono applicati i livelli di servizio (SLA) riportati di seguito.

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 45

UC1 - Agreement Incident e Request Fulfilment

Misura la capacità di fornire supporto all’utenza e di risolvere i malfunzionamenti in autonomia o ingaggiati da altri gruppi di supporto.

Periodicità trimestre solare Compliance 85% per i servizi L3

Target

	Target	L3	Peso
	UCst01 Tempo di presa in carico Incident	5h	35%
	UCst02 Tempo di esecuzione attività di Access Management: Gestione password	3h	15%
	UCst03 Tempo di esecuzione attività di Access Management: Gestione utenze	6h	10%
	UCst04 Tempo di soluzione Incident Critical entro	20h	20%
	UCst05 Tempo di soluzione Incident High entro	30h	15%
	UCst06 Tempo di soluzione Incident Medium/Low entro	45h	5%

Condizione di innesco	Condizione partenza	Condizione stop	Condizione di sospensione	Note
UCst01	presa in carico supporto all'utenza
‘Ticket Type’= “Incident” AND 'Service Type' = “User Service Restoration” 'ServiceCI' =/LIKE <Servizio Manutenuto> AND Status <> “Cancelled” AND “Service” = <XXX>	Status >= Assigned AND “Assigned Group” = <Gruppo del fornitore>	Status >= In Progress	Status = “Pending” AND ( Status Reason = “Client Hold” OR Status Reason = “Client Action Required” )
UCst02	esecuzione attività di Access Management: Gestione password
‘Ticket Type’= “Incident” AND 'Service Type' = "User Service Request" AND 'ServiceCI' =/LIKE <Servizio Manutenuto> AND 'Operational' = “Access Management/Gestione Password” AND Status <> “Cancelled” AND “Service” = <XXX>	Status >= Assigned AND “Assigned Group” =	Status >=	Status = “Pending” AND ( Status Reason = “Client Hold” OR Status Reason = “Client	Le attività previste sono: - reset password - ripristrino
	<Gruppo del fornitore>		Action Required” )	password
UCst03	esecuzione attività di Access Management: Gestione utenze

CATALOGO BIBLIOGRAFICO TRENTINO

CBT

pag. 46 CAPITOLATO TECNICO

Condizione di innesco	Condizione partenza	Condizione stop	Condizione di sospensione	Note
‘Ticket Type’= “Incident” AND 'Service Type' = "User Service Request" AND	Status >= Assigned	Status >=	Status = “Pending” AND (	Le attività previste sono:
'ServiceCI' =/LIKE <Servizio Manutenuto> AND	AND		Status Reason = “Client	- creazione
'Operational' = “Access Management/Gestione Utenze”	“Assigned		Hold” OR	utenza
AND	Group” =		Status Reason = “Client	- modifica
Status <> “Cancelled” AND	<Gruppo del		Action Required” )	utenza
“Service” = <XXX>	fornitore>			-
				disabilitazione
				utenza
				- cancellazione
				utenza
UCst04	soluzione Incident Critical
‘Ticket Type’= “Incident” AND 'Service Type' = “User	Status >=	Status >=	Status = “Pending”
	Service Restoration” AND 'ServiceCI' =/LIKE <Servizio	Assigned	Resolved	AND (
Manutenuto> AND 'Priority' = “Critical”	AND		Status Reason = “Client
AND Status <> “Cancelled” AND “Service” = <XXX>	“Assigned		Hold” OR
	Group” =		Status Reason = “Client
	<Gruppo del		Action Required” )
	fornitore>
UCst05	soluzione Incident High
‘Ticket Type’= “Incident” AND 'Service Type' = “User	Status >=	Status >=	Status = “Pending”
Service Restoration” AND 'ServiceCI' =/LIKE <Servizio	Assigned	Resolved	AND (
Manutenuto> AND 'Priority' = “High”	AND		Status Reason = “Client
AND Status <> “Cancelled” AND “Service” = <XXX>	“Assigned		Hold” OR
	Group” =		Status Reason = “Client
	<Gruppo del		Action Required” )
	fornitore>
UCst06	soluzione Incident Medium/Low entro
‘Ticket Type’= “Incident” AND	Status >=	Status >=	Status = “Pending”
'Service Type' = “User Service Restoration” AND	Assigned	Resolved	AND (
'ServiceCI' =/LIKE <Servizio Manutenuto> AND	AND		Status Reason = “Client
‘Product Categorization Tier 3 <> “Tecnologico” AND	“Assigned		Hold” OR
('Priority' = “Medium” OR 'Priority' = “Low”)	Group” =		Status Reason = “Client
AND Status <> “Cancelled” AND	<Gruppo del		Action Required” )
“Service” = <XXX>	fornitore>

7.1.5 SLA per il servizio di manutenzione dell’infrastruttura tecnologica

In riferimento alla qualità del servizio di assistenza e supporto all’utenza vengono applicati i livelli di servizio (SLA) riportati di seguito.

CATALOGO BIBLIOGRAFICO TRENTINO CBT

CAPITOLATO TECNICO Pagina 47

UC31 - Agreement Availability

Misura la disponibilità del servizio lato utente (misurata ai confini della connettività internet della rete provinciale).

Target	Peso
UCst31 - Disponibilità del servizio	100%

Periodicità trimestre solare Compliance 93% per i servizi L3 Target

7.1.6 SLA per la difformità nell’erogazione del servizio di manutenzione del software

In riferimento alla qualità del servizio di manutenzione del software vengono applicati i livelli di servizio (SLA) riportati di seguito.

Presenza di Richieste contestate

Servizio	KPI - Descrizion e	I dati rilevati	La metrica	SLA	Periodo di riferime nto
Servizio di manuten zione del software	L’indicatore evidenzia la presenza di ISSUE di contestazion e di un Ticket o di un Task.	Vengono rilevati puntualmente nel periodo di riferimento: • la presenza di ISSUE relativi sia a richieste formulate attraverso Ticket che quelle formulate attraverso Task, contestati da Informatica Trentina.	C è il numero degli interventi di manutenzione contestati nel periodo di riferimento a cui non viene data una giustificazione ritenuta valida da Informatica Trentina.	C = 0	Mese solare