SERVIZI PROFESSIONALI PER LE ATTIVITÀ DI MANUTENZIONE DI SOFTWARE APPLICATIVO GIS

Formano oggetto delle prestazioni richiedibili i servizi professionali per le attività di sviluppo e manutenzione di software applicativo GIS. Nel par. “1.1 SERVIZI RICHIESTI”del Capitolato Tecnico di Sviluppo vengono elencati i servizi richiesti per l’intera durata dell’Accordo Quadro ed i profili professionali richiesti.

In questo documento vengono descritte le attività di manutenzione e definite le modalità di attivazione ed erogazione dei servizi per le attività di manutenzione di software applicativo GIS per ciascuna specifica applicazione di cui si richieda la manutenzione.

Per la definizione delle modalità di attivazione ed erogazione dei servizi per le attività di sviluppo di software applicativo GIS si rimanda al Capitolato Tecnico di Sviluppo.

Il presente documento contiene inoltre la definizione degli impegni contrattuali da rispettare, gli obblighi da onorare ossia i vincoli posti dal contesto di collaborazione nonché le regole da seguire nel corso dell’interazione tra le parti coinvolte nel progetto.

I servizi professionali per le attività di manutenzione di software applicativo GIS previsti nel contratto prevedono:

o la presa in carico del sistema,

o la manutenzione correttiva,

o la gestione del servizio (quali attività di supporto tecnico e di dominio),

o il supporto all’utenza (opzionale),

o la manutenzione evolutiva e il supporto specialistico (opzionale),

o la riconsegna del sistema e chiusura del servizio (opzionale).

Informatica Trentina ha adottato, nella definizione delle modalità di erogazione dei servizi di manutenzione del software, le best practices ITIL® così come descritte nei documenti di cui al capitolo 4; di seguito si farà riferimento pertanto alla terminologia proposta dal glossario ITIL®1.

1.1 MODALITA’ DI ATTIVAZIONE DEL SERVIZIO PER ATTIVITÀ DI MANUTENZIONE DI UNA APPLICAZIONE GIS

L’attivazione dei servizi professionali per attività di manutenzione avverrà nell’ambito di un processo basato sulla definizione congiunta tra Committente e Contraente dell’intervento.

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

I servizi professionali che potranno essere richiesti sono i seguenti:

a) Servizi professionali per le attività di presa in carico del sistema, manutenzione

correttiva, gestione del servizio, e opzionalmente il supporto all’utenza (che rientrano nel canone)

b) Servizi professionali per le attività di manutenzione evolutiva, per il supporto specialistico e per la riconsegna del sistema e chiusura del servizio (che rientrano nel Tempo e Spesa)

L’attivazione delle suddette due tipologie di servizi professionali, per le attività di manutenzione di un sistema Gis, avverrà con la seguente modalità:

- “Interventi misti “a canone” e a “tempo e spesa”

come meglio descritto nel successivo paragrafo.

Le modalità di erogazione delle specifiche attività sono descritte nel cap. “5 ” del presente documento.

1.1.1 PUNTO 1 - INTERVENTI A CANONE E A TEMPO E SPESA

Per gli interventi Misti “a canone e a tempo e spesa” al fine della manutenzione di un’applicazione Gis, la modalità di attivazione può essere suddivisa nei seguenti distinti momenti:

 L’inoltro da parte della Committente di una Richiesta di intervento al Contraente che contenga tutti gli elementi necessari ad una valutazione accurata del servizio richiesto. In particolare verranno fornite le seguenti informazioni:

o la descrizione dell’applicazione GIS da gestire e la relativa documentazione tecnica,

o per la parte a canone (presa in carico del sistema, manutenzione correttiva, gestione del servizio, e opzionalmente il supporto all’utenza):

 i possibili ruoli e figure professionali necessari,

 la stima dei costi in termini di “giornate lavorative mensili medie per ciascuna figura professionale“ necessarie all’erogazione del servizio (canone mensile),

o per la parte a tempo e spesa (manutenzione evolutiva, supporto specialistico e riconsegna del sistema e chiusura del servizio):

 i possibili ruoli e figure professionali necessari,

 impegno (effort) massimo richiesto per ciascuna figura professionale in termini di giornate lavorative per l’intera durata del servizio di manutenzione della specifica applicazione Gis. Si tratta di un massimale non garantito di giorni persona disponibili per il tipo di attività richiesto per l’intera durata del servizio di manutenzione della specifica applicazione Gis,

o i livelli di servizio (SLA) richiesti,

o le caratteristiche HW e SW del sistema da gestire,

o gli skill richiesti,

o i template da utilizzare per la documentazione da produrre,

o gli ambienti per gli sviluppi software,

o gli ambienti HW e SW richiesti al Contraente,

o gli strumenti messi a disposizione dalla Committente,

o la durata del servizio;

o i termini entro i quali dovrà essere formulata la Risposta dal Contraente

(comunque non inferiori a 3 giorni lavorativi).

Invece per le informazioni di seguito elencate, la Richiesta di intervento potrà fare riferimento al Capitolato Tecnico di gestione, salvo diverse necessità che dovranno essere esplicitate nella Richiesta stessa:

o ruoli e responsabilità,

o la Pianificazione e Conduzione del servizio,

o descrizione delle attività da svolgere per la parte a canone: Presa in carico del sistema, Erogazione del servizio di manutenzione correttiva, Erogazione del servizio di gestione del servizio, Erogazione del servizio di supporto all’utenza (opzionale), Difformità nell’ erogazione del servizio di manutenzione del software,

o descrizione delle attività da svolgere per la parte a tempo e spesa: Erogazione del servizio di manutenzione evolutiva, Erogazione del servizio di supporto specialistico, Riconsegna del sistema e chiusura del servizio, Difformità nell’ erogazione del servizio di manutenzione del software,

o i documenti che descrivono le linee guida e la gestione dei processi relativi al servizio di Manutenzione del software negli ambienti della Committente,

o le modalità di verifica / validazione delle attività svolte,

o la lista dei documenti che il Contraente deve gestire

o i contenuti del piano di progetto che dovrà essere proposto dal Contraente e sulla base del quale il Contraente si impegna ad eseguire il servizio.

Tutte le sopra elencate informazioni potranno anche essere condivise successivamente in appositi incontri;

 la presa in carico da parte del Contraente della Richiesta di intervento inoltrata dal Committente. A seguito della valutazione della Richiesta, il Contraente invia la sua Risposta costituita da una accettazione della Richiesta di intervento, integrata con eventuali osservazioni, e da un piano di progetto contenente quanto richiesto nella Richiesta di intervento (sulla base di quanto descritto nel cap. “3.1.1 Piano di Progetto” del presente Capitolato Tecnico di Gestione, con le eventuali integrazioni esplicitate nella Richiesta di intervento stessa).

Tale Risposta dovrà essere formulata entro i termini indicati nella Richiesta stessa (comunque non inferiori a 3 giorni lavorativi).

 in caso di accettazione da parte del Committente della suddetta Risposta del Contraente, comprese le eventuali osservazioni e la proposta contenuta nel piano di progetto sulla base del quale il Contraente si impegna ad eseguire il servizio di manutenzione richiesto, verrà conseguentemente aggiornata la Richiesta di intervento, che diventa quindi la Richiesta di intervento definitiva e accettata dalle parti e vincolante per l’esecuzione dell’attività. Il Committente emetterà quindi l’Ordine che disciplinerà le attività sulla base di quanto definito nella Richiesta di intervento stessa (integrata con i contenuti del suddetto piano di progetto per l’erogazione del servizio di manutenzione) definendo la data di avvio delle attività, oltre alle modalità di fatturazione sulla base di quanto indicato nel Contratto;

 in caso di non accettazione da parte del Committente della suddetta Risposta del Contraente, comprese le eventuali osservazioni e la proposta contenuta nel piano di progetto per l’erogazione del servizio, il Committente potrà eventualmente definire una nuova Richiesta di intervento rispondente ai requisiti richiesti, i cui contenuti potranno anche essere condivisi in appositi incontri da fissare secondo le modalità previste al capitolo “3.2.3 ”;

 in caso di accettazione da parte del Contraente della Nuova Richiesta di intervento e da parte del Committente del Nuovo piano di progetto per l’erogazione del servizio, il Committente emetterà l’Ordine che disciplinerà l’erogazione del servizio sulla base di quanto definito nella nuova Richiesta di intervento definitiva (integrata con la Nuovo piano di progetto per l’erogazione del servizio di manutenzione) e accettata dalle parti;

 l’esecuzione delle attività di manutenzione dell’applicazione oggetto dell’intervento.

Le richieste ed i relativi tempi di presa in carico ed evasione verranno tracciate via posta elettronica tra il Responsabile del contratto del Committente ed il Responsabile del contratto del Contraente.

2 RUOLI E RESPONSABILITÀ

Il Contraente dovrà designare formalmente il Responsabile, appartenente alla propria organizzazione, della gestione e dell’esecuzione di quanto oggetto del contratto, la persona così identificata sarà anche Responsabile del coordinamento delle risorse impegnate.

Il Responsabile del Contraente sarà il punto di contatto ufficiale di Informatica Trentina.

2.1 COMUNICAZIONE

Di seguito gli stakeholder (attori coinvolti) individuati secondo la Vista del Contraente:

Fase	Stakeholder	Ruolo
Contratto	Direzione 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; riceve l’elenco dei soggetti individuati quali "Amministratori di Sistema" ed esegue verifiche sul rispetto delle misure di sicurezza previste contrattualmente.
Erogazione del servizio di manutenzione correttiva, gestione servizio presa in carico	Responsabile del Contratto IT Responsabile servizi di data center	Riferimento per problematiche applicative Riferimento per problematiche relative al funzionamento dell’infrastruttura

		tecnologica
Erogazione del servizio manutenzione evolutiva, supporto specialistico, riconsegna sistema	Responsabile del Contratto IT Responsabile servizi di data center	Formula la richiesta di valutazione degli interventi di manutenzione evolutiva o supporto specialistico Attiva gli interventi di manutenzione evolutiva o supporto specialistico o riconsegna sistema.
		Riferimento per problematiche relative al funzionamento dell’infrastruttura tecnologica
Avvio del servizio	Responsabile del Contratto IT	Valida le condizioni di avvio del servizio.
	Responsabile servizi di data center	Valida le condizioni di 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.

3 PIANIFICAZIONE E CONDUZIONE DEL SERVIZIO

3.1 PIANIFICAZIONE DEL SERVIZIO ‌

3.1.1 PIANO DI PROGETTO

Il Contraente si impegna ad eseguire il servizio sulla base del Piano di Progetto presentato in risposta alla Richiesta di Intervento e alle attività richieste (sia per la parte a canone che per la parte a tempo e spesa).

Il Contraente dovrà predisporre il piano di progetto nel rispetto della seguente articolazione:

1) Presa in carico dell’applicazione oggetto del servizio di manutenzione:

il Contraente dovrà definire l’organizzazione ed il piano di attività previste per la presa in carico dell’applicazione oggetto del servizio di manutenzione (vedi sezione 5.1 “Presa in carico del sistema” nel Capitolato Tecnico);

2) Pianificazione e conduzione del servizio: il Contraente dovrà:

 definire una WBS (Work Breakdown Structure), con indicazione di task e milestone, relativa alla gestione delle attività sui sistemi oggetto del servizio ed una pianificazione temporale prevedibile per le attività e definire processi e modalità per attuare l’erogazione del servizio in tutte le attività previste dallo stesso, descrivendo il ciclo di vita del software che intende adottare per gli interventi di manutenzione evolutiva;

 descrivere le metodologie e gli strumenti impiegati per le attività implementative previste e le tecniche di modellazione impiegate nelle varie fasi del ciclo di vita del software;

 descrivere la procedura di gestione della documentazione di progetto (vedi le sezioni del Capitolato Tecnico 5.2: Servizio di manutenzione del software, 5.3 Riconsegna del sistema e chiusura del servizio, 3.1.7 Piano di gestione della documentazione, 3.2.6 Gestione della documentazione, 6.1 Lista documenti da gestire)

 descrivere modalità e tempi delle attività di Riconsegna del sistema e chiusura del Servizio (vedi sezione 5.3 “Riconsegna del sistema e chiusura del servizio” nel Capitolato Tecnico);

3) Gestione dei rischi:

il Contraente dovrà definire, sulla base dell’analisi dei rischi, le azioni previste per il controllo, monitoraggio, mitigazione e presidio/soluzione dei rischi individuati relativi all’erogazione del Servizio (vedi sezione 3.1.4 “Gestione dei Rischi” nel Capitolato Tecnico);

4) Stime

il Contraente dovrà definire la metodologia adottata per la stima delle risorse da utilizzare per l’erogazione del servizio per le attività previste e le relative risultanze (vedi sezione 3.1.5 “Stime” nel Capitolato Tecnico);

5) Composizione ed organizzazione del gruppo di lavoro:

il Contraente dovrà definire la composizione del gruppo di lavoro che il Contraente intende utilizzare per l’erogazione dei servizi previsti, l’organizzazione adottata per attuare l’erogazione dei servizi previsti (processi, modalità e strumenti tecnologici), nonché le interfacce del gruppo di lavoro proposto, fornendo evidenza dei ruoli (in base ai profili professionali indicati nelle schede di descrizione delle risorse professionali) assunti dai suoi componenti, anche attraverso l’utilizzo di una matrice RACI.

Il Piano di Progetto presentato dal Contraente in risposta alla Richiesta di Intervento diventa, se accettato dal Committente, parte integrante della Richiesta di Intervento stessa. Il Committente emetterà quindi l’Ordine che disciplinerà le attività sulla base di quanto definito nella Richiesta di intervento stessa (integrata con il suddetto Piano di Progetto).

Il Contraente dovrà fornire eventuali aggiornamenti del Piano di Progetto entro 5 giorni lavorativi dall’evento che ha causato la necessità dell’aggiornamento ed in ogni caso dopo ogni Stato Avanzamento Lavori.

Variazioni alla pianificazione saranno valide ed impegnative per Informatica Trentina solo se approvate e sottoscritte dai suoi Rappresentanti in apposite riunioni (si veda par. 3.2.3). In caso di non accettazione verrà redatta una nota con le indicazioni correttive.

3.1.2 WORK BREAKDOWN STRUCTURE (WBS)

Il Contraente dovrà inserire nel Piano di Progetto la WBS secondo cui saranno gestite le attività. Nella WBS dovranno essere definiti i task e le milestones.

Come sistema standard di tracciamento delle attività verrà usato Microsoft Project.

3.1.3 CICLO DI VITA

Il Contraente dovrà identificare il ciclo di vita da utilizzarsi, per gli interventi di manutenzione ordinaria, che verrà riportato nel piano di progetto del Contraente dove dovranno essere identificate tutte le attività richieste dal presente Capitolato Tecnico.

3.1.4 GESTIONE DEI RISCHI

Il Contraente dovrà analizzare nel Piano di Progetto le criticità e descrivere le azioni di presidio.

Occorre pertanto:

 identificare il rischio;

 analizzarlo in base a quanto nel par. 3.1.5;

 in caso di magnitudo (criticità) superiore a 0,25, definire piano di mitigazione;

 implementare tale piano;

 eseguire controllo e monitoring.

3.1.5 ANALISI E VALUTAZIONE DEL RISCHIO

Per ogni criticità deve esserne evidenziata la Probabilità di accadimento con la seguente scala di rilevanza:

 0,1 = probabilità molto bassa;

 0,3 = probabilità bassa;

 0,5 = probabilità media;

 0,7 = probabilità alta;

 0,9 = probabilità molto alta.

Deve essere evidenziato altresì l’Impatto, ossia le conseguenze dell'eventuale verificarsi della situazione critica, con la seguente scala di rilevanza:

 0,1 = impatto molto basso;

 0,3 = impatto basso;

 0,5 = impatto medio;

 0,7 = impatto alto, aspetto importante;

 0,9 = impatto molto alto, aspetto fondamentale.

Per le criticità, per le quali il valore risultante dal prodotto della probabilità con l’impatto è superiore o uguale a 0,25, è obbligatorio individuare le azioni di presidio necessarie per garantire il successo dell'intervento ed il relativo responsabile.

Il Contraente dovrà informare in forma scritta entro 5 giorni il Responsabile di progetto di Informatica Trentina di ogni evento che possa generare ritardi sulle attività del progetto.

Tabella A: Sintesi delle criticità e delle relative azioni di presidio

3.1.6 STIME

Il Contraente dovrà usare metodi per fornire evidenza delle stime delle risorse da utilizzare per l’erogazione del servizio. Dovranno essere prodotte le stime che giustifichino il dimensionamento del team di risorse proposto in particolare per il servizio di Manutenzione correttiva.

Il Contraente sarà responsabile dell’aggiornamento delle stime.

Le stime iniziali andranno inserite nel Piano di Progetto. Durante lo svolgimento delle attività tali dati andranno aggiornati e consegnati ad Informatica Trentina negli aggiornamenti del Piano di Progetto.

3.1.7 PIANO DI GESTIONE DELLA DOCUMENTAZIONE

Il Contraente dovrà dettagliare nel Piano di Progetto la propria procedura di gestione della documentazione di progetto.

Per la versione elettronica dei documenti dovranno essere usati i formati previsti dal Codice dell’Amministrazione Digitale (CAD), quindi, a titolo esemplificativo, in formato pdf e/o aperto (OpenOffice / LibreOffice).

L’utilizzo di software differenti dovrà essere ridotto al minimo ed il loro eventuale uso dovrà essere sottoposto all’approvazione di Informatica Trentina.

3.2 CONDUZIONE DEL SERVIZIO

3.2.1 CONTROLLO E MONITORAGGIO

Il Contraente dovrà fornire periodicamente evidenza formale circa il raggiungimento dei

Service Level Agreements definiti per ciascuna attività di cui al capitolo 5

Tali evidenze andranno registrate in formato elettronico e consegnate ad Informatica Trentina nel Rapporto di Avanzamento (si veda par. 3.2.3) .

3.2.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
Data chiusura	data chiusura effettiva
Note	Commento

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

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 e presentata ad ogni riunione periodica di avanzamento.

3.2.3 REVISIONI E REPORTING

Sono previste riunioni periodiche per le attività oggetto della fornitura.

Durante queste riunioni verranno svolte revisioni tecniche formali dei prodotti eventualmente realizzati e dei servizi erogati.

Per tutte le riunioni il Contraente assicurerà che opportuna convocazione venga fornita con 5 giorni di anticipo. Parimenti i documenti da discutere nelle riunioni saranno inviati ad Informatica Trentina con 2 giorni di anticipo.

Altre riunioni potranno essere sostenute dietro semplice richiesta (con un massimo di 5 giorni di preavviso) di Informatica Trentina o del Contraente.

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

Il Contraente dovrà produrre e trasmettere con cadenza mensile il “Rapporto di Avanzamento” contenente le seguenti informazioni:

 stato corrente dell’attività;

 ragioni di eventuali ritardi, problemi, azioni correttive pianificate o prese (Gestione degli ISSUE);

 stato avanzamento dei rischi

 eventi principali previsti nel periodo successivo;

 azioni chiuse nel periodo ( si veda par. 3.2.2).

3.2.4 GESTIONE DELLA CONFIGURAZIONE

Per la Configurazione, il Contraente dovrà utilizzare il repository SVN messo a disposizione da Informatica Trentina S.p.A. ed accedibile via ssh all’indirizzo xxx.xxxxxx.xx.

Durante tutte le attività di modifiche al software, relative al servizio in oggetto, il Contraente dovrà eseguire frequenti (possibilmente giornalieri):

 rilasci (commit) di software “compilabile”.

 aggiornamenti (update) dei sorgenti locali.

Tali rilasci sono necessari per mitigare problematiche di integrazione dei singoli componenti e per gestire in modo efficace i backup del codice sorgente del progetto.

Il Contraente svolgerà il ruolo di Responsabile della configurazione del software.

Informatica Trentina si riserva il diritto di verificare tramite audit le attività di gestione della configurazione del Contraente ed, in caso di difformità, lo stesso sarà tenuto a sanarle entro 24 ore dalla notifica che avverrà via e-mail.

3.2.5 NOMENCLATURA PER LE VERSIONI SOFTWARE

Lo standard per l’etichettatura del software prevede la seguente sintassi:

Ver-X_Y_Z[_W-TN] indica un nuovo tag del software dove X, Y, Z sono numeri naturali e

 X è un numero che indica la versione dell'applicazione (e che viene incrementato a fronte di cambiamenti significativi del software; tale incremento è a discrezione del responsabile della configurazione in accordo col responsabile del progetto);

 Y è un numero che rappresenta il progredire del software sulla HEAD del repository: viene incrementato ad ogni versionamento del software solo se si è sulla HEAD del repository;

 Z è un numero che rappresenta il progredire del software su di un Branch. Per questo motivo vale 0 se si è sulla HEAD. Un numero maggiore di zero sui branch.

 W è opzionale; è un numero che rappresenta il progredire del software sul Branch di un Branch (vedi nota seguente: Branch di branch).

 TN è opzionale; N è il numero di ticket a cui il tag è associato

Esempio: Ver-2_9_0, Ver-2_10_0, Ver-2_11_0, ... sono tag presenti sulla HEAD del repository

Ver-2_12_0-T546754277 è il tag facente riferimento al ticket 546754277

Branch-NN indica un nuovo branch; NN è il numero che identifica il tag da cui viene fatto partire il branch (ovvero X_Y_Z nella definizione precedente del tag).

Esempio: devo fare un branch a partire dal tag Ver-2_10_0; il branch si chiamerà: Branch- 2_10_0.

I tag su questo branch saranno Ver-2_10_1, Ver-2_10_2, Ver-2_10_3 e così via.

Patch-NN indica un branch per una o più correttive e segue la nomenclatura del branch per NN.

Branch di branch

Questo standard prevede un unico livello di brach con la lettera Z. Nei rarissimi casi in cui si è costretti a fare un branch di un branch, il nome del branch sarà sempre Patch-NN con NN corrispondente al valore del tag da cui si parte ed i tag sul branch saranno Ver- NN_W con W numero naturale maggiore di 0.

Esempio: devo fare un branch a partire dal tag Ver-2_10_2 presente sul branch Patch- 2_10_0. Chiamerò questo nuovo branch Patch-2_10_2. I tag su quel branch saranno Ver- 2_10_2_1, Ver-2_10_2_2, ...

3.2.6 GESTIONE DELLA DOCUMENTAZIONE

Il Contraente dovrà creare, mantenere e rendere disponibile su richiesta il documento “Lista Documenti Prodotti”, che riporti tutti i documenti prodotti, inclusi i rapporti, i piani ed i verbali.

La lista dovrà indicare il riferimento del documento, il tipo, la data di emissione, gli autori, lo stato (bozza o approvato), il formato elettronico ed il nome del file.

3.2.7 MIGLIORAMENTI E CORREZIONI

Il Contraente dovrà analizzare e pianificare gli eventuali miglioramenti e correzioni all’attività svolta ed alla documentazione prodotta.

Dovranno essere implementati solo quei cambiamenti/miglioramenti approvati da Informatica Trentina in apposite riunioni (si veda par. 3.2.3)

Il Contraente traccerà le proposte di modifica secondo le modalità previste per la gestione degli ISSUE (si veda par. 3.2.2).

4 STRUMENTI ED AMBIENTI

4.1 AMBIENTI DI RIFERIMENTO ED ALTRI AMBIENTI

Per la descrizione dettagliata degli ambienti di riferimento necessari per le attività di sviluppo software e manutenzione nell’ambito dei servizi professionali per le attività di sviluppo e manutenzione di software applicativo GIS si rimanda al paragrafo 4.1 AMBIENTI OPERATIVI, LINGUAGGI, STANDARD, PRODOTTI DI

RIFERIMENTO del Capitolato Tecnico di Sviluppo.

Per la descrizione dettagliata di altri ambienti che potrebbero essere richiesti per le attività di sviluppo software e manutenzione nell’ambito dei servizi professionali per le attività di sviluppo e manutenzione di software applicativo GIS si rimanda al paragrafo 4.2 ALTRI AMBIENTI OPERATIVI, LINGUAGGI, STANDARD, PRODOTTI.

4.2 STRUMENTI UTILIZZATI DAL CONTRAENTE NELLA GESTIONE DEL SISTEMA

Sono di seguito elencati i documenti che Informatica Trentina mette a disposizione del Contraente per la gestione dei processi relativi al servizio di Manutenzione del software:

 SGQ-PR-50.1 Incident management;

 SGQ-PR-50.3 Access management;

 SGQ-PR-70.1 Change management;

 SGQ-PR-80.1 Release and Deployment management;

 SIC-LG-06 “Sviluppo sicuro principali minacce e relative contromisure”;

 SIC-LG-07 “Sicurezza nella progettazione e sviluppo di soluzioni informatiche”, limitatamente al par. 2.2.2 come di seguito specificato;

 SIC-POL-08 “Sicurezza nella progettazione e sviluppo di soluzioni informatiche”, limitatamente al par. 2.2 come di seguito specificato;

 SIC-POL-10 Sicurezza nell’esercizio e gestione di soluzioni informatiche – policy aziendale;

La documentazione tecnica, di proprietà dell’Amministrazione, relativa alla specifica applicazione oggetto del servizio di manutenzione sarà fornita insieme alla Richiesta di Intervento inviata al Contraente.

Tale documentazione tecnica è redatta da parte dell’impresa che ha realizzato la specifica applicazione oggetto del servizio di manutenzione, la quale rimane titolare del connesso diritto d’autore. Detta documentazione non può essere utilizzata se non ai fini della

Risposta del Contraente alla Richiesta di Intervento, comprensiva del Piano di Progetto, e della prestazione del servizio di cui alla suddetta Richiesta di Intervento.

All’avvio delle attività, Informatica Trentina metterà a disposizione del Contraente i seguenti strumenti:

 i Sistemi di Gestione della configurazione con autorizzazione all’accesso al personale del Contraente;

 il Sistema BMC Remedy ITsm Suite per il governo dei processi e la gestione del ticketing;

Riguardo l’infrastruttura tecnologica e gli ambienti di Test / Quality / Produzione nella sede del Committente, le attività richieste al Contraente, le modalità di lavoro e le autorizzazioni all’accesso al personale del Contraente saranno definiti nella Richiesta di Intervento.

Anche l’infrastruttura tecnologica che dovrà essere collocato presso il Contraente sarà definita nella Richiesta di Intervento

Gli ambienti messi a disposizione del Contraente sono condivisi con altri sistemi pertanto sarà cura del Contraente prestare la massima attenzione per evitare di interferire con essi.

Il Contraente dovrà provvedere al collegamento telematico ridondato con Informatica Trentina.

Inoltre, in ottemperanza a quanto previsto dal Provvedimento del Garante per la Privacy del 27/11/2008 "Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema" e successive modificazioni, il Contraente dovrà provvedere all'individuazione e formale nomina dei soggetti individuati quali "Amministratori di Sistema", così come disposto nei punti 2.a. e 2.b. del succitato provvedimento. Copia di tale elenco dovrà essere trasmesso ad Informatica Trentina, ovvero dovrà essere aggiornato in caso di variazioni, così come previsto nei punti 2.c. e 2.d. del provvedimento di cui sopra.

Informatica Trentina provvederà alla registrazione di tutti gli accessi logici effettuati sui propri sistemi, così come disposto dal punto 2.f., e si riserva la facoltà di effettuare le attività di verifica previste dal punto 2.e..

Gli accessi al data center di Informatica Trentina avverranno via VPN; in seguito sono elencate le piattaforme software con la lista dei browser e degli ambienti Java collaudati per la versione attualmente in uso. La compatibilità di client diversi andrà opportunamente valutata di volta in volta e, anche in caso positivo, non verrà fornito alcun supporto da Informatica Trentina.

Piattaforme collaudate

Piattaforma

Sistemi Operativi : lista dei browser e dei Java Environment

Windows

 XP Professional SP3 32 bit: Internet Explorer 7.0, Internet Explorer 8.0 and Firefox 3.0.Sun JRE 6

 Vista Enterprise SP1 32 bit and 64 bit: Internet Explorer 7.0, Internet Explorer 8.0 and Firefox 3.0.Sun JRE 6

 Windows 7 Enterprise 32 bit and 64 bit: Internet Explorer

8.0 and Firefox 3.5 Sun JRE 6 (6.5R2 and above)

Di seguito si riporta la lista dei client compatibili (ma non verificati con la versione di VPN attualmente in uso) comprendenti la lista dei browser e degli ambienti Java:

Piattaforme compatibili

Piattaforma

Sistemi Operativi

Browser e Java Environment

Windows

 Vista Enterprise/Ultimate/Business/Home Basic/Home Premium with Service Pack 1 or 2 on 32 bit or 64 bit platforms

 Windows 7 Enterprise/Ultimate/Professional/H ome Basic/Home Premium on 32bit or 64 bit platforms (6.5R2 and above)

 XP Professional with SP2 or SP3 on 32 bit or 64 bit

 2000 Professional XX0

x XP Home Edition XX0

x XP Media Center 2005

 Windows 2003 server SP2, 32bit and 64 bit 1

 Internet Explorer 8.0

 Internet Explorer 7.0

 Internet Explorer 6.0

 Firefox 3.5

 Firefox 3.0

 Firefox 2.0

 Sun JRE 5/1.5.07 and above

 Microsoft JVM – for Windows 2000

( * Wherever- applicable)

5 ATTIVITÀ DA SVOLGERE

L’attività richiesta riguarda la manutenzione del Sistema Informativo oggetto della specifica Richiesta di Intervento, sia sui componenti software costituenti il Sistema all’avvio delle attività, sia sulle nuove componenti od eventuali nuovi sottosistemi, sviluppati nell’ambito dell’erogazione del servizio di manutenzione del software stesso, sulla base delle indicazioni contenute nel presente capitolato tecnico.

La manutenzione del sistema dovrà rispettare, nelle sue varie fasi, le misure di sicurezza previste così come di seguito indicato:

 durante la fase di analisi occorre individuare e definire i requisiti posti dal cliente

(interno o esterno), quelli non precisati ma necessari, quelli derivanti da norme cogenti e/o stabilite dall’azienda (vedi par. 2.1 del documento SIC-LG-07 “Sicurezza nella progettazione e sviluppo di soluzioni informatiche – Linee guida”): la proposta di soluzione deve soddisfare tutti i requisiti individuati;

 durante la fase di progettazione occorre individuare le potenziali minacce e

vulnerabilità che possono mettere in pericolo la sicurezza dell’applicazione, tramite un’analisi degli scenari chiave di utilizzo e l’identificazione delle risorse critiche per le quali è necessario garantire particolare protezione, definendo successivamente le metodologie ed i meccanismi di sicurezza da utilizzare sulla base delle vulnerabilità rilevate (per i dettagli in merito alle principali minacce e relative contromisure fare riferimento al documento SIC-LG-06 “Sviluppo sicuro: principali minacce e relative contromisure - Linee guida”) ;

 durante la fase di realizzazione occorre attenersi a quanto previsto nel par. 2.2.2 del

documento SIC-POL-08 “Sicurezza nella progettazione e sviluppo di soluzioni informatiche

– Policy aziendale” e nel par. 2.2.2 del documento SIC-LG-07 “Sicurezza nella progettazione e sviluppo di soluzioni informatiche – Linee guida”;

 i test dovranno riguardare anche le caratteristiche di sicurezza e la verifica di

eventuali vulnerabilità applicative secondo le modalità e le indicazioni presenti nel par. 2.2.4 del documento SIC-POL-08 “Sicurezza nella progettazione e sviluppo di soluzioni informatiche – Policy aziendale”;

 relativamente all’avviamento del servizio devono essere rispettati i criteri di

sicurezza descritti nel par. 2.2.5 del documento SIC-POL-08 “Sicurezza nella progettazione e sviluppo di soluzioni informatiche – Policy aziendale”.

La documentazione sopra indicata è reperibile al link (xxxxx://xxx.xxxxxx.xx/Xxx- siamo/Certificazioni-Qualita-e-Sicurezza/Sicurezza-delle-informazioni).

Informatica Trentina si riserva il diritto di sottoporre a riesame in apposite riunioni (si veda par. 3.2.3) e di approvare/non approvare i prodotti risultanti dalle attività sotto indicate secondo quanto previsto nel capitolo 6 Verifica e Validazioni.

In caso di non accettazione verrà redatta una nota con le non conformità/difetti rilevati.

Quanto riportato nei successivi paragrafi potrà essere modificato sulla base di quanto riportato nella specifica Richiesta di Intervento.

5.1 PRESA IN CARICO DEL SISTEMA

L’attività di presa in carico dell’applicazione oggetto del servizio di manutenzione consiste nell’acquisire tutte le informazioni che sono necessarie all’erogazione del servizio di manutenzione del software della suddetta applicazione.

Informatica Trentina fornirà a questo scopo tutta la documentazione e gli strumenti referenziati al capitolo 4.

Informatica Trentina procederà a verificare che le risorse del Contraente coinvolte nel progetto siano coerenti con quanto proposto nell’offerta tecnica presentata dal Contraente in sede di gara e nel Piano di Progetto relativo alla specifica Richiesta di Intervento. Qualora nel corso del progetto una delle risorse venisse sostituita, Informatica Trentina procederà ad analoga verifica.

L’attività verrà condotta dal Contraente, con il supporto del personale indicato da Informatica Trentina, per un intervallo di tempo definito nella Richiesta di intervento secondo un piano e le modalità di svolgimento concordate con Informatica Trentina. Alla conclusione dell’attività verrà redatto un verbale, sottoscritto dalle parti, secondo i criteri di verifica di cui al capitolo 6.

Verrà inoltre erogata, se necessario, dal personale di Informatica Trentina una sessione di formazione sull’utilizzo del BMC Tool al fine della corretta implementazione dei processi di Incident, Change e Deploy Management richiesta per l’espletamento dei servizi descritti nei successivi paragrafi.

Durante questo periodo il Contraente dovrà inoltre predisporre presso il proprio data center l’ambiente di sviluppo / test del sistema necessario alla gestione ed evoluzione del servizio secondo le caratteristiche precedentemente indicate.

5.2 SERVIZIO DI MANUTENZIONE DEL SOFTWARE

Il Servizio di manutenzione del software dell’applicazione oggetto della specifica Richiesta di Intervento 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. Per tale attività viene monitorato il livello di servizio o SLA (Service Level Agreement) definito nella specifica Richiesta di Intervento;

 la gestione del servizio (quali attività di supporto tecnico e di dominio) limitatamente a ciò di cui il Contraente assume la responsabilità secondo quanto descritto in 5.2.1.4 A tale attività viene applicato lo SLA definito nella specifica Richiesta di Intervento;

 opzionalmente il supporto all’utenza;

 la manutenzione evolutiva, che consiste in interventi attuati per adattare i programmi e le procedure alle mutate esigenze dell’utente e per ottimizzare le prestazioni e la qualità delle procedure elaborative anche con riferimento all’ambiente tecnologico, nonché in interventi di realizzazione software “una tantum” per l’estrazione di dati o la produzione di report. A tale attività viene applicato lo SLA definito nella specifica Richiesta di Intervento;

 il supporto specialistico descritto al par. 5.2.1.3 Erogazione dei servizi di Supporto Specialistico.

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 consegnata dovrà quindi essere tenuta costantemente aggiornata, a cura del Contraente, in funzione dei cambiamenti apportati al sistema.

Le procedure per il passaggio in esercizio del software modificato nonché le modifiche alle strutture dei dati derivanti sia da interventi di manutenzione correttiva che di manutenzione ordinaria, dovranno essere automatiche e replicabili nei diversi ambienti (Test, Quality e Produzione). Al Contraente verrà dato accesso agli ambienti di Test, Quality e Produzione del sistema, per poter:

- effettuare le verifiche di funzionamento del sistema (ambienti di Test e Quality)

- eseguire le attività per il passaggio in produzione dello stesso a seguito di manutenzione del software server (ambiente di Produzione).

Nel caso in cui l’attività di manutenzione implichi modifiche al database o al componente client, il Contraente, in qualità di DBA applicativo, fornirà il relativo apporto.

Per quanto riguarda il supporto specialistico, si precisa quanto segue:

1. l’erogazione del supporto specialistico viene erogato a favore del responsabile del progetto di IT sia presso gli uffici di Informatica Trentina che presso le sedi dei Clienti di Informatica Trentina. Tali attività richiedono una conoscenza approfondita dell’architettura software e dovranno essere svolte dal progettista del sistema. A tale attività viene applicato lo SLA definito nella specifica Richiesta di Intervento.

2. l’erogazione del supporto specialistico viene anche erogato a favore dei servizi tecnici di IT sia presso gli uffici di Informatica Trentina che presso le sedi dei Clienti di Informatica Trentina. Tali attività richiedono una conoscenza approfondita dell’architettura tecnica del sistema e dovranno essere svolte da personale con

approfondite conoscenze del sistema di tipo “sistemistico”. Anche a tale attività viene applicato lo SLA definito nella specifica Richiesta di Intervento.

L’interlocuzione tra il Committente ed il Contraente per tutte le esigenze operative non risolvibili nell’ambito dei processi ITIL adottati, nonché l’esercizio, da parte del Contraente, del ruolo di DBA Applicativo, avverranno attraverso l’attivazione sul sistema BMC Remedy ITsm Suite di una Service Request tra quelle proposte nel Catalogo dei servizi interni e l’assegnazione al gruppo di Technical Support adeguato, selezionato fra quelli disponibili.

Orari e finestre del servizio

Per la definizione di orari e finestre dei Servizi di manutenzione del software si rimanda al business time del servizio definito nella Richiesta di Intervento inviata al Contraente e relativa all’applicazione GIS oggetto di questo servizio.

5.2.1 MODALITÀ DI EROGAZIONE DEL SERVIZIO DI MANUTENZIONE DEL SOFTWARE

Le richieste ed i relativi tempi di risoluzione verranno tracciati nello strumento BMC Remedy ITM Suite di volta in volta attraverso la gestione di un Ticket di tipo Change oppure di un Task.

Il Contraente sulla base della notifica ricevuta, prenderà in carico la richiesta e provvederà, nel più breve tempo possibile, per avere a disposizione un lasso di tempo adeguato al mantenimento degli SLA, ad effettuare la diagnosi della richiesta per verificarne la corretta classificazione.

Durante tale fase il Contraente avrà cura, eventualmente, di richiedere al Responsabile del Contratto IT tutte le informazioni di approfondimento che fossero necessarie per il completamento della stessa, oppure a contattare direttamente i PM di riferimento dell’utente finale che ha richiesto l’intervento.

Nel caso in cui il Contraente verifichi un’errata assegnazione o classificazione della richiesta, dovrà provvedere, nel più breve tempo possibile, a chiudere la richiesta motivando nel campo WORK INFO NOTES la decisione e, in particolare, il motivo dell’errata classificazione o assegnazione e indicando anche tutte le eventuali informazioni in suo possesso che potrebbero essere utili per la corretta gestione della richiesta.

In caso di incarico tramite ticket di Change il Contraente dovrà impostare il campo STATUS a “Cancelled”.

In caso di incarico tramite Task il Contraente dovrà impostare il campo STATUS a “Closed” e la STATUS REASON a “Cancelled” riportando le motivazioni nel campo WORK INFO NOTES.

Se il Contraente accetta la classificazione della richiesta, a seconda della classificazione stessa, verranno seguite le indicazioni di seguito riportate.

5.2.1.1 Erogazione del servizio di Manutenzione Correttiva.

Si descrive di seguito il processo per l’erogazione del servizio di manutenzione correttiva.

Il Ticket di Change è stato classificato con TEMPLATE “Software Change: correttiva”. Il Contraente sulla base di tali classificazioni provvederà entro i limiti temporali previsti dagli specifici SLA, a rimuovere la causa del malfunzionamento, rendere disponibile il risultato di tali attività all’utente e a chiudere il ticket, descrivendo dettagliatamente le operazioni effettuate nel Tab Work Detail nei campi NOTES dei Work Info relativi ai “Work Info Type” del gruppo “Supporto Applicativo”.

Nel caso in cui l’attività richieda il rilascio in produzione di componenti software, vanno seguite le indicazioni operative di seguito riportate.

 Alla conclusione dell'intervento di manutenzione, il Contraente effettua le attività necessarie per il rilascio del sistema in esercizio, predisponendo se necessario le procedure automatiche per il deploy, crea un task utilizzando il task template “Change SW: Deployment SW correttiva” e:

o indica nel campo “Summary*” l’applicazione e una breve descrizione dell’oggetto del deployment;

o espone nel campo “Notes” le istruzioni di deployment;

o se necessario, modifica il gruppo e la persona cui assegnare il Task;

o se necessario, valorizza i campi “Scheduled Start Date+” e “Scheduled Stop Date+” con l’intervallo di tempo nel quale si desidera venga effettuato il passaggio in esercizio

L’assegnazione del Task deve pervenire alla struttura di Informatica Trentina al massimo entro le ore 15:00 per poter effettuare il passaggio in esercizio nell'intervallo tra le ore 17:00 e le ore 18:00 dello stesso giorno (finestra ordinaria). In casi eccezionali le azioni da intraprendere saranno concordate tra il Responsabile del Contratto IT ed il Responsabile del Contratto del Contraente.

 A fronte dell'evidenza dell'esito positivo del passaggio in esercizio, verificato dalla chiusura del Task e dal passaggio della Change nello stato di “Completed”, il Contraente avverte il richiedente (determinando così il tempo totale dell'intervento considerato nel calcolo degli SLA). Alla chiusura dell’intervento, il Contraente compilerà tutte le informazioni supplementari nel campo Work Detail della Change.

Il servizio di manutenzione correttiva contempla anche le attività di “Investigazione e Diagnosi” ossia l’insieme delle attività finalizzate alla verifica e all’individuazione delle cause che hanno determinato un malfunzionamento od un problema nell’utilizzo del sistema, nonché di eventuali workaround che permettano di aggirare seppur temporaneamente la disfunzione.

La richiesta viene inoltrata tramite un Task collegato ad un ticket di tipo Incident. Il Contraente provvederà entro i limiti temporali previsti dallo specifico SLA di cui al paragrafo 5.4.2, ad eseguire la richiesta ed a chiudere il task, descrivendo dettagliatamente le operazioni effettuate nel Tab Work Info nei campi SUMMARY e WORK INFO NOTES.

5.2.1.2 Erogazione del servizio di Manutenzione Evolutiva

Si descrive di seguito il processo per l’erogazione del servizio di manutenzione evolutiva.

L’erogazione del servizio di manutenzione evolutiva avviene nell’ambito di un processo basato sulla definizione congiunta tra IT e Contraente dell’intervento. L’attività è suddiviso in quattro distinti momenti:

1. la presa in carico da parte del Contraente della richiesta di valutazione di un intervento, inoltrata dal Responsabile del Contratto IT e contenente gli elementi necessari a definire e stimare l’intervento, il cui prodotto finale è costituito da una proposta di intervento del Contraente che contiene una descrizione sintetica delle attività, della documentazione da produrre/aggiornare, dei costi in termini di giornate lavorative necessarie e dei tempi di rilascio previsti;

2. l’esame da parte del Responsabile del Contratto IT e dei PM della proposta di intervento con eventuale approvazione finale e conseguente attivazione dei lavori;

3. la realizzazione da parte del Contraente delle modifiche al software, la produzione e/o l’aggiornamento della documentazione tecnica di progetto ed il rilascio (o il supporto al rilascio) nell’ambiente di Test e di Quality ovvero la messa a disposizione dei prodotti delle elaborazioni una tantum. In particolare, precondizione per il rilascio nell’ambiente di Test di Informatica Trentina è che siano stati eseguiti i test di integrazione e forniti tutti i relativi documenti di test; potranno essere previsti anche rilasci intermedi (sia della documentazione aggiornata che del SW) soggetti a validazione da parte di Informatica Trentina;

4. al termine delle attività previste si procederà alla validazione conclusiva eventualmente anche attraverso un collaudo formale effettuato in contraddittorio tra le parti. Il Responsabile del Contraente, il Responsabile del Contratto IT ed i PM provvederanno congiuntamente ad effettuare le verifiche necessarie e riporteranno sul verbale di collaudo, redatto dal Responsabile del Contratto IT, il dettaglio delle attività svolte e l’esito del collaudo che riguarderà i seguenti punti:

o verifica dei rapporti di test;

o corretta operatività dei Sistemi;

o verifica della documentazione prodotta/aggiornata.

Al superamento positivo del collaudo il Contraente provvederà ad effettuare il passaggio in produzione nei tempi concordati con i PM ed il Responsabile del Contratto IT ed a chiudere l’intervento.

Le richieste ed i relativi tempi di presa in carico verranno tracciati nello strumento BMC Remedy ITsm Suite attraverso la gestione di:

 un Task di Valutazione e stima (OPERATIONAL: TIER1: “Task” – TIER2: “Change” – TIER3: “Valutazione intervento”). Tale richiesta conterrà gli elementi per la definizione e la stima degli impegni necessari a realizzare la modifica richiesta al software. Il Contraente sulla base della notifica e-mail, prenderà in carico il task (portandolo in stato in lavorazione, STATUS “Work in progress”) e provvederà, entro un tempo massimo di 5 giorni, a formulare una proposta di soluzione, allegando i relativi documenti al Task e indicando nel campo SUMMARY del paragrafo WORK INFO: la stima dei giorni richiesti per l’effettuazione dell’intervento, i tempi di rilascio praticabili ed il periodo di validità della stima. Con tali informazioni il Contraente chiude il Task. Sarà cura del Contraente eventualmente richiedere al Responsabile del Contratto IT e/o ai PM tutte le informazioni di approfondimento che fossero necessarie per la definizione della proposta di intervento.

 Il Responsabile del Contratto IT valuterà in accordo con i PM la proposta di

intervento, raccogliendo tutti gli elementi decisionali in merito e, nel caso di approvazione dell’intervento inserirà un Task di Esecuzione Intervento (OPERATIONAL: TIER1: “Task” – TIER2: “Change” – TIER3: “Manutenzione Evolutiva”). Tale Task conterrà la richiesta di attuazione della proposta di soluzione precedentemente formulata dal Contraente e l’indicazione della tempistica concordata sulla base della stima effettuata dal Contraente stesso, (nel campo SCHEDULED END DATE del TAB “DATES”), che diventerà l’elemento di valutazione del raggiungimento dello SLA previsto per il servizio. Il Contraente prenderà in carico il Task (portandolo in stato in lavorazione, STATUS “Work in progress”) e provvederà ad effettuare l’attività richiesta nei tempi concordati; il Task verrà quindi riassegnato (STATUS: Assigned) al Change Group di riferimento per il Sistema per l’effettuazione dell’eventuale collaudo. In caso di collaudo negativo, il Task verrà quindi riassegnato, con l’evidenza delle anomalie riscontrate, al Contraente che dovrà provvedere alla risoluzione e, al termine delle attività, riassegnerà il Task al Change Group di riferimento per il Sistema. Questa iterazione continuerà fino al collaudo positivo, momento nel quale il Responsabile del Contratto IT chiuderà il Task (determinando così il tempo totale dell'intervento considerato nel calcolo degli SLA).

 Per il passaggio in produzione dell’intervento realizzato, il Responsabile del

Contratto IT assegnerà un Ticket di tipo Release con OPERATIONAL (TIER1: “Release” – TIER2: “Completa” – TIER3: “Nessuno”) con, nel campo

SUMMARY, la descrizione della richiesta, nel campo BUSINESS JUSTIFICATION il valore “Maintenance” oppure “Enhancement”, nel campo TARGET DATE la data di richiesta del passaggio in esercizio. Il Contraente effettuerà le attività preparatorie necessarie per il rilascio del sistema (predisponendo se necessario le procedure automatiche per il deploy) e porterà il ticket di Release in stato di approvazione della pianificazione impostando il campo STATUS a “Planning Approval” (verrà impostato automaticamente l’approvatore della pianificazione). Tale passaggio di stato costituisce la notifica di Preavviso passaggio in esercizio.

 All’approvazione della pianificazione di rilascio il Contraente porta il ticket di Release alla MILESTONE “Deployment” e STATUS “In Progress” e lo assegna

al Coordinator Group “AS – sigla applicazione - EXT”. Tale assegnazione costituisce la notifica di Richiesta esecuzione passaggio in esercizio. Il Contraente assicurerà la necessaria collaborazione ad effettuare tutte le attività previste per completare il Rilascio in produzione, secondo le istruzioni da lui precedentemente formulate. In casi eccezionali le azioni da intraprendere saranno coordinate tra il Responsabile del Contratto IT ed il Responsabile del Contratto del Contraente.

Alcuni interventi di manutenzione evolutiva, all’atto dell’apertura del ticket di Change, potranno essere classificati con una priorità elevata (campo PRIORITY valorizzato con “High” o “Critical”). In tal caso il Contraente dovrà, nell’esecuzione dei Task collegati alla Change, individuare ed attuare la soluzione meglio rispondente al problema nel minor tempo possibile e, quando necessario od opportuno, concordare con il Responsabile del Contratto IT le modalità operative tese a minimizzare i tempi di messa a disposizione della soluzione per l’utente finale.

Tutte le attività vanno condotte nel rispetto dei requisiti di sicurezza per la progettazione e realizzazione di soluzioni informatiche così come descritti in SIC-LG-06, SIC-LG-07, SIC-POL-08.

Tutte le risorse impiegate nelle attività dovranno saper operare sulla base del processo e degli output previsti per l’esecuzione delle attività di sviluppo descritti nel cap. “5.1 SVILUPPO DEL SOFTWARE” del Capitolato Tecnico di Sviluppo.

5.2.1.3 Erogazione dei servizi di Supporto Specialistico

Si descrive di seguito il processo per l’erogazione del servizio di supporto specialistico.

L’erogazione del servizio di supporto specialistico avviene nell’ambito di un processo basato sulla definizione congiunta tra IT e Contraente dell’intervento.

L’attività è suddivisa nei seguenti distinti momenti:

a) la presa in carico da parte del Contraente della richiesta di valutazione di un intervento, inoltrata dal Responsabile del Contratto di IT, il cui prodotto finale è

costituito da una proposta di intervento del Contraente che contiene una descrizione sintetica dell’intervento, della documentazione da produrre/aggiornare, dei costi in termini di giornate lavorative necessarie e dei tempi di rilascio previsti;

b) l’esame da parte di IT della proposta di intervento con eventuale approvazione finale e conseguente attivazione dei lavori;

c) la realizzazione da parte del Contraente dell’intervento richiesto, la produzione e/o l’aggiornamento della documentazione tecnica concordata.

Le richieste ed i relativi tempi di presa in carico verranno tracciati nello strumento BMC Remedy ITsm Suite attraverso la gestione di:

 Il Responsabile del Contratto IT valuterà in accordo con i PM la proposta di

5.2.1.4 Erogazione della Gestione del Servizio

Per quanto concerne le attività di gestione del servizio rientrano in queste categorie:

1. tutte le attività di supporto tecnico e di dominio legate alla quotidiana gestione del servizio;

2. opzionalmente, se indicato nella Richiesta di Intervento, anche le attività relative alla gestione e al ripristino dell’infrastruttura tecnologica.

Categoria 1)

Per la categoria 1), e cioè per le attività di supporto tecnico e di dominio legate alla quotidiana gestione del servizio, il committente aprirà un ticket di Incident all’interno del quale sarà aperto un Task che avrà la seguente classificazione Tier 1: “Request Fulfillment”, Tier 2: “Richiesta di Informazioni” Tier 3: variabile.

Il Contraente sulla base di tali classificazioni provvederà, entro i limiti temporali previsti dagli specifici SLA, a chiudere il task portandolo nello stato “Closed”, status reason “Success”, e rendere disponibile il risultato di tali attività al richiedente, descrivendo dettagliatamente le operazioni effettuate nel Tab Work Info del task.

Per quanto riguarda l’infrastruttura tecnologica e gli ambienti di Test / Quality / Produzione nella sede del Committente, le attività richieste al Contraente, le modalità di lavoro e le autorizzazioni all’accesso al personale del Contraente saranno definiti nella Richiesta di Intervento.

Anche l’infrastruttura tecnologica che dovrà essere collocata presso il Contraente sarà definita nella Richiesta di Intervento.

Categoria 2)

Per la categoria 2), e cioè per le attività relative alla gestione e al ripristino dell’infrastruttura tecnologica, il Contraente dovrà operare sui sistemi secondo i privilegi e le responsabilità riportate nella Richiesta di Intervento distinguendo i seguenti ambienti:

 ambiente di sviluppo e test:

 ambienti di quality e produzione:

e i seguenti componenti:

 middleware

 sistema operativo

Per la gestione delle componenti middleware verranno definiti specifici tipi di profilo, come ad esempio:

 LogViewer: utente in grado solo di visualizzare i log applicativi in modalità “readonly”

 Deployer/Data Manager: utente che gestisce i “deploy” applicativi e/o i dati applicativi all’interno del database e/o su file system

 DBManager: utente con i massimi privilegi di amministrazione sul database dell’applicazione.

 MiddlewareAdmin: utente abilitato all’amministrazione completa dello strato di “middlware”.

Il Contraente avrà i privilegi di accesso e dovrà possedere le competenze necessarie a garantire il corretto funzionamento dell’infrastruttura tecnologica dell’applicazione oggetto del servizio di manutenzione e il suo aggiornamento/evoluzione. In particolare verranno forniti gli accessi per la gestione dei middleware che compongono l’infrastruttura tecnologica dell’applicazione oggetto del servizio di manutenzione.

Per la gestione del sistema operativo, il Contraente avrà i privilegi di accesso e dovrà possedere le competenze necessarie per utilizzare i sistemi operativi previsti nell’infrastruttura tecnologica dell’applicazione oggetto del servizio di manutenzione.

Le responsabilità sistemistiche che rimarranno in carico a Informatica Trentina verranno precisamente indicate e distinte dalle responsabilità in carico al Contraente.

Nel caso in cui il committente (tramite sistema di monitoraggio o altro) rilevi un problema o un blocco nel servizio verrà aperto un ticket di Incident all’interno del quale sarà aperto un Task che verrà assegnato al gruppo “TS-- sigla applicazione - EXT” e avrà la seguente classificazione Tier 1: “Task”, Tier 2: “Incident” Tier 3: variabile. Se la segnalazione deriva da un allarme presente nel tool di monitoraggio quest’ultima verrà anche notificata ad una casella di posta di gruppo che il Contraente dovrà espressamente indicare nel corso delle attività di presa in carico del sistema.

Si ritiene opportuno evidenziare che in caso di task riferito ad una indisponibilità del servizio il ripristino

dell’Infrastruttura Tecnologica è comunque misurato sulla effettiva fruibilità del servizio per il cliente

finale.

Nel caso in cui l’incarico assegnato con il Task al Contraente non risultasse di pertinenza di quest’ultimo il Contraente provvederà a documentarne le ragioni insieme a suggerimenti sulle attività da svolgere nella tab Work Info del Task e chiudere lo stesso portandolo nello stato “Closed” , status reason “Success”.

Si precisa che l’attività sistemistica di aggiornamento del middleware ricade nelle ordinarie attività di gestione dell’infrastruttura tecnologica e verrà gestita tramite un Ticket di Change classificato con TEMPLATE “Infrastructure Change” e con i relativi Task associati, assegnati al gruppo “TS- sigla applicazione - EXT”.

In ogni caso, per tutte le attività vale quanto segue:

1. Il Contraente nell'implementazione e gestione degli ambienti è tenuto al rispetto dei controlli inerenti previsti nell'Annex A dello standard CEI ISO/IEC 27001:2005 “Tecnologia per l’Informazione – Tecniche per la Sicurezza – SGSI - Requisiti” secondo le politiche/procedure proprie interne nel caso in cui sia certificata rispetto al predetto standard o in alternativa secondo quanto previsto dalla SIC-POL-10 “Sicurezza nell'esercizio e gestione di soluzioni informatiche”.

2. Tutte le attività vanno condotte nel rispetto dei requisiti di sicurezza nell’esercizio e gestione di soluzioni informatiche così come descritti in SIC-POL-10.

5.2.1.5 Servizio di Supporto all’Utenza

Nell’ambito di questo servizio le principali (non esaustive) attività previste sono:

 assistenza telefonica di “secondo livello” (il primo livello è assicurato dal Customer Service Desk della Committente), che consente di garantire all’utenza dei sistemi assistenza informatica e supporto tecnico finalizzati al corretto utilizzo delle funzioni/applicazioni in esercizio, con risoluzione delle problematiche - anche con strumenti di remotizzazione dell’assistenza - tramite verifica delle esigenze del Cliente e dei vincoli, limiti e potenzialità delle applicazioni;

 diagnostica e risoluzione di problemi relativi all’utilizzo delle applicazioni;

 predisposizione di documentazione operativa e note operative di soluzione su richieste ripetitive;

 redazione di manualistica utente;

 attività di quality, volte a verificare la correttezza funzionale di componenti applicative nelle fasi che precedono la loro messa in esercizio; le attività saranno svolte sulla base di documentazione (casi di test) e manualistica/documenti resi disponibili dalla Committente;

 attività di coordinamento alla formazione del’utente in caso di messa in produzione di nuove componenti.

Si precisa che il servizio ricomprende:

 la valutazione della tipologia della richiesta e la sua eventuale riassegnazione alla struttura della Committente idonea a risolvere il problema, secondo le modalità di seguito descritte;

 il contatto telefonico diretto con l’utente che ha attivato la richiesta di assistenza (la sede dell’utente è di regola sul territorio provinciale), tramite mezzi telefonici del Contraente.

5.2.1.6 Modalità di erogazione del Servizio di Supporto all’Utenza

Le richieste ed i relativi tempi di risoluzione verranno tracciati nello strumento BMC Remedy ITsm Suite attraverso la gestione di un Ticket di tipo Incident. Il Contraente sulla base della notifica ricevuta, prenderà in carico il ticket e provvederà, nel più breve tempo possibile ad effettuare la diagnosi della richiesta per verificarne la corretta classificazione. Durante tale fase il Contraente avrà cura eventualmente di richiedere al Responsabile del contratto IT, tutte le informazioni di approfondimento che fossero necessarie per il completamento della stessa oppure a contattare direttamente l’utente finale che ha richiesto il supporto.

Nel caso in cui il Contraente verifichi un’errata assegnazione o classificazione del ticket, dovrà provvedere, nel più breve tempo possibile, a riassegnare il ticket al Serve Desk inserendo nel Work Detail (Add Work Info, campo Notes) il motivo dell’errata classificazione o assegnazione e indicando anche tutte le eventuali informazioni in suo possesso che potrebbero essere utili per la relativa correzione.

5.2.2 DIFFORMITÀ NELL’EROGAZIONE DEL SERVIZIO DI MANUTENZIONE DEL

SOFTWARE.

La chiusura di un ticket 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 chiusura di un ticket senza il completamento di tutti i passi previsti dal processo produttivo, 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 del ticket relativo attraverso la richiesta da parte di Informatica Trentina di apertura di uno specifico ISSUE, secondo le modalità descritte nel paragrafo 3.2.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.

5.3 RICONSEGNA DEL SISTEMA E CHIUSURA DEL SERVIZIO

Si descrive di seguito il processo per riconsegna del sistema e chiusura del servizio.

Alla conclusione del periodo di erogazione del servizio di manutenzione del software verrà effettuata, presso la sede del Committente, la riconsegna del sistema al personale indicato da Informatica Trentina di tutti gli elementi della configurazione corrente del sistema (software, documentazione aggiornata circa le variazioni intervenute nel corso del contratto e circa le informazioni rilevanti per l’erogazione dei servizi di manutenzione del software, etc.). Il Contraente dovrà fornire a questo scopo tutta la documentazione e gli strumenti referenziati al capitolo 4 debitamente aggiornati.

Per la ripresa in carico del sistema da parte del personale indicato da Informatica Trentina il Contraente darà supporto per il necessario affiancamento per un impegno non superiore al numero di giorni-persona definito nella Richiesta di Intervento e da erogarsi in un arco temporale concordato con Informatica Trentina secondo un piano di lavoro che tenga conto delle necessità operative legate alla fase di presa in carico del sistema da parte del nuovo team individuato. Alla conclusione dell’attività verrà redatto un verbale, sottoscritto dalle parti, secondo i criteri di verifica di cui al capitolo 6.

5.4 LIVELLI DEL SERVIZIO

5.4.1 PREMESSE

Vengono di seguito descritti i livelli di servizio che possono essere adottati per i servizi erogati dal Committente.

Per ogni applicazione oggetto del servizio di manutenzione, nella relativa Richiesta di Intervento inviata al Contraente saranno descritti:

 Il livello di servizio (sulla base della criticità del servizio stesso)

 Il business time del servizio (cioè degli orari di erogazione previsti)

a partire dagli esempi di SERVICE LEVEL AGREEMENT e SERVICE TARGETS di seguito indicati.

5.4.1.1 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, dipendente dall'impatto che ciascun servizio può avere sui processi di business dei Clienti che lo utilizzano.

Ad ogni servizio presente in Service Catalogue è stato assegnato uno dei seguenti livelli di criticità:

 L1: servizi con impatto esteso.

Sono i servizi più critici che necessitano di un intervento e di un ripristino immediato in caso di malfunzionamento.

 L2: servizi con impatto significativo o ampio.

 L3: servizi con impatto moderato/limitato.

 L4: servizi con impatto minore/localizzato.

Sono i servizi meno critici che necessitano di un intervento e di un ripristino non immediato in caso di malfunzionamento.

I livelli di servizio garantiti sono differenti per ciascuna fascia: più stringenti per L1; via via meno vincolanti passando da L2 a L4.

5.4.1.2 Struttura degli indicatori

Il modello di riferimento per la misurazione dell’erogazione dei servizi si basa sulla struttura di seguito illustrata.

Business Time

I business time, cioè degli orari di erogazione previsti, sono così specificati:

 24x7

Tutti i giorni dalle 00.00 alle 23.59.

 14x6

Dal lunedì al sabato dalle 08.00 alle 22.00 esclusi i festivi del Comune di Trento.

 10x5

Dal lunedì al venerdì dalle 08.00 alle 18.00 esclusi i festivi del Comune di Trento.

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:

1. Tempo di percorrenza di un ticket

2. Disponibilità di un sistema

3. 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

 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.

Calcolo del Livello di servizio

Ciascun target specifico è determinato dal rapporto tra numero di interventi completati nei tempi previsti ed il numero totale degli interventi registrati nella periodicità prevista. Nel caso in cui, nella periodicità prevista, non fossero registrati interventi allora lo specifico target verrà considerato completamente raggiunto ed il rapporto suddetto verrà considerato pari ad 1.

A ciascun target così calcolato viene poi attribuito un peso, indicato in tabella, che viene utilizzato per il calcolo della compliance complessiva dell’agreement. La sommatoria dei valori così ottenuti, in termini percentuali, determinerà il livello di servizio raggiunto nel periodo. Tale livello dovrà risultare essere maggiore o tutt’al più uguale al livello di compliance previsto.

Ecco di seguito la Modalità di calcolo della compliance

∑(NUCst_i-OK · PesoUCst_i)

su ogni STuc_i (service target dello SLA)

∑ (NUCst_i· PesoUCst_i)

su ogni STuc_i (service target dello SLA)

Il calcolo della percentuale di compliance per ciascun agreement avviene secondo la formula seguente:

Percentuale di compliance =

dove:

NUCst_i-OK è il numero di eventi hanno soddisfatto il service target UCst_i

PesoUCst_i è il peso del service target UCst_i (vedi tabella dello SLA relativo)

∑NUCst_i è il numero di eventi complessivi relativi al service target UCst_i

che

UC sta per “Underpinning Contract” e cioè un contratto legalmente vincolante tra le parti con uno o più fornitori esterni che supportano l’organizzazione IT nella fornitura dei servizi.

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 (L1/L2/L3/L4);

 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;

o se il malfunzionamento è tale da consentire all’utente di lavorare seppur con qualche difficoltà, l’urgenza assume il livello 3-Medium;

o se il malfunzionamento è tale che l’utente conferma che è sufficiente risolverlo senza carattere di urgenza, l’urgenza assume il livello 4-Low.

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;

 l’utente finale non accetta la sessione di collegamento remoto ovvero decide di sospendere o interrompere la sessione per cause strettamente non legate al servizio di assistenza;

 l’agente per l’accesso da remoto è stato immotivatamente disattivato da parte dell’utente finale.

 Attività non effettuabili a fronte di problematiche legate all’obsolescenza di prodotti hardware e software, per il mancato supporto di assistenza da parte del Contraente.

5.4.2 SERVICE LEVEL AGREEMENT MANUTENZIONE CORRETTIVA –L3

In riferimento ai tempi chiusura degli interventi di manutenzione correttiva 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à trimestre solare

Compliance 85%

Service Target Manutenzione correttiva (L3)

ID	Target Interventi di manutenzione correttiva	Tempo massimo previsto	Peso
UCst21	Tempo di esecuzione Change sw correttiva	18h	30%
UCst22	Tempo di esecuzione Change sw correttiva pianificata	entro data pianificata	15%
ID	Target Interventi di Investigazione e diagnosi	Tempo massimo previsto	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:

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’ =

Change Request Status'

"Completed" OR 'Change Request Status'

= "Closed"

‘ASGRP’ !=

UCst22 Change sw correttiva pianificata

Condizione di innesco Condizione di Condizione Condizione

Ticket Type’= “Change” AND ‘Operational’ = “Change/Software/Correttiva” AND

'Priority' != "Critical" AND 'ServiceCI' =/LIKE <Servizio Manutenuto> AND

‘Status’ <> “Cancelled”

partenza

di stop

di sospensione

Status >=

Request for Authorization AND ‘ASGRP’ =

Change

Request Status'

"Completed" OR 'Change Request Status'

= "Closed"

‘ASGRP’ !=

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

Condizione di innesco

Condizione di partenza

Condizione di stop

Condizione di sospensione

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’ =

Status >= Closed

‘Assignee Group’ !=

UCst37

Ticket Type’= “Task” AND 'Product Name' /LIKE <Product Manutenuto> AND

‘Scheduled End Date’ <> NULL AND

'StatusReasonSelection <> “Cancelled” AND

Status >= Assigned AND

‘Assignee Group’ =

Status >= Closed

‘Assignee Group’ !=

5.4.3 SERVICE LEVEL AGREEMENT MANUTENZIONE EVOLUTIVA – L3

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%

Service Target

Target

Tempo

Peso

massimo

previsto

UCst27

Tempo di valutazione Task Change software entro

5gg

25%

UCst28

Tempo di implementazione Task Change software

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’ =

Status >= Closed

‘Assignee Group’ !=

UCst28 Implementazione Change software

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

5.4.4 SERVICE LEVEL AGREEMENT SUPPORTO SPECIALISTICO – L3

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

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

5.4.5 SERVICE LEVEL AGREEMENT GESTIONE DEL SERVIZIO – L3

Categoria 1), e cioè per le attività di supporto tecnico e di dominio legate alla quotidiana gestione del servizio

Misura la capacità di chiudere gli interventi di supporto tecnico e di dominio (Task collegati ad Incident) nei tempi previsti.

Periodicità annuale Compliance 85%

Target

Target	L3	Peso
UCst23 Tempo di chiusura Task Critical da Incident entro	12h	20%
UCst24 Tempo di chiusura Task High da Incident entro	16h	40%
UCst25 Tempo di chiusura Task Medium da Incident entro	24h	30%
UCst26 Tempo di chiusura Task Low da Incident entro	40h	10%

Categoria 2), e cioè per le attività relative alla gestione e al ripristino dell’infrastruttura tecnologica

Misura la capacità di ripristinare l’infrastruttura tecnologica (Task collegati ad Incident) nei tempi previsti.

Periodicità annuale Compliance 85%

Target

Target	L3	Peso
UCst23 Tempo di chiusura Task Critical da Incident entro	12h	30%
UCst24 Tempo di chiusura Task High da Incident entro	16h	40%
UCst25 Tempo di chiusura Task Medium da Incident entro	24h	25%
UCst26 Tempo di chiusura Task Low da Incident entro	40h	5%

5.4.6 TABELLE PER GLI SLA CORRISPONDENTI AI SERVIZI DI LIVELLO L1, L2, L3 ED L4

Le tabelle inserite nei precedenti paragrafi si riferiscono ad un servizio di livello L3 per il quale quindi non è richiesta alcuna modifica. Nel caso in cui il servizio richiesto fosse di livelli differenti da L3 allora le tabelle relative ai Target Service (manutenzione correttiva)

vanno aggiornate con quelle di seguito riportate. E’ sufficiente copiare la tabella contenente il Service Target di interesse nel testo al posto di quella già definita (livello L3) e modificare conseguentemente la Compliance.

UC21 - Agreement Manutenzione software correttiva

Compliance 95% per i servizi L1

90% per i servizi L2 85% per i servizi L3 80% per i servizi L4

Service Target per servizi di livello L1

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

Service Target per servizi di livello L2

UC		Tempo massimo previsto
	Target Interventi di manutenzione correttiva	Tempo massimo previsto	Peso
UCst21	Tempo di esecuzione Change sw correttiva	13h	30%
UCst22	Tempo di esecuzione Change sw correttiva pianificata	entro data pianificata	15%
UC		Tempo massimo previsto
	Target Interventi di Investigazione e diagnosi	Tempo massimo previsto	Peso
UCst23	Tempo di chiusura Task Critical da Incident entro	8h	10%
UCst24	Tempo di chiusura Task High da Incident entro	12h	20%
UCst25	Tempo di chiusura Task Medium da Incident entro	20h	15%

UCst26 Tempo di chiusura Task Low da Incident entro

UCst37 Tempo di chiusura Task data concordata

40h

Data concordata

Service Target per servizi di livello L3

UC		Tempo massimo previsto
	Target Interventi di manutenzione correttiva	Tempo massimo previsto	Peso
UCst21	Tempo di esecuzione Change sw correttiva	18h	30%
UCst22	Tempo di esecuzione Change sw correttiva pianificata	entro data pianificata	15%
UC		Tempo massimo previsto
	Target Interventi di Investigazione e diagnosi	Tempo massimo previsto	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%

Service Target per servizi di livello L4

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

5.4.7 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 Ticket contestati

Servizio

KPI -

Descrizione

I dati rilevati

La metrica

SLA

Periodo di riferimento

Servizio di manutenzione del software

L’indicatore evidenzia la presenza di ISSUE di

contestazione 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

6 VERIFICA E VALIDAZIONI

Attività	Criterio di verifica
Attività di presa in carico del sistema	Strumenti ed ambienti di cui al paragrafo 4 attivi, operativi ed accessibili, nonché il rispetto, per le risorse del Contraente coinvolte nel progetto, dei requisiti minimi dichiarati in fase di offerta.
Erogazione servizio manutenzione del software	Rispetto degli SLA descritti al capitolo 5.4
Riconsegna del sistema e chiusura del servizio	Consistenza della baseline rilasciata in configurazione. Strumenti ed ambienti di cui al capitolo 4 attivi, operativi ed accessibili. Verbale di presa in carico.

A conclusione delle attività verrà redatto in contraddittorio tra le parti un verbale di validazione del servizio che attesterà la corretta riconsegna del sistema.

6.1 LISTA DOCUMENTI DA GESTIRE

Di seguito sono riepilogati i documenti di cui è richiesta la realizzazione in questo Capitolato Tecnico. I documenti sono indicati con il nome ed il paragrafo di riferimento all’interno del presente documento.

Identificativo	Documento	Paragrafo
E-AAA-MAN-PIA-01 (*)	Piano di Progetto	3.1 3.1.2 3.1.4
E-AAA- MAN-SAL-01 (*)	Rapporto di Avanzamento	3.1.6 3.2.1
E-AAA-MAN-LDP-01 (*)	Lista Documenti Prodotti	3.2.6
E-AAA-MAN-RIU-01 (*)	Verbale di Riunione	3.2.3
E-AAA-MAN-LAC-01 (*)	Lista Azioni Concordate	3.2.3
E-AAA-DIM -01 (*)	Documento di architettura e dimensionamento del sistema	< per le manutenzioni evolutive con impatto su architettura >

Identificativo	Documento	Paragrafo
E-AAA-PFZ -01 (*)	Progettazione funzionale	< per le manutenzioni ordinarie ed evolutive >
E-AAA-CTS -01 (*)	Progettazione del test	< per le manutenzioni ordinarie ed evolutive >
E-AAA-RTS -01 (*)	Rapporto di esecuzione del test	< per le manutenzioni ordinarie ed evolutive >
Vari	Tutta la documentazione tecnica di progetto	4

(*) Dove AAA è il codice dell’applicazione interessata.

Document Metadata

Table of Contents

SERVIZI PROFESSIONALI PER LE ATTIVITÀ DI MANUTENZIONE DI SOFTWARE APPLICATIVO GIS

Document Metadata