CAPITOLATO TECNICO

La Polizia di Stato e precisamente la Direzione Centrale per i Servizi Tecnico Logistici e per la Gestione Patrimoniale (D.C.S.T.L.G.P.) intende provvedere alla razionalizzazione dei sistemi informatici in uso presso la Direzione stessa.

I sistemi informatici interessati, più innanzi descritti in dettaglio, sono:

• il Sistema Informatico Accasermamento,

• il Sistema Informatico Auditing Web.

Obiettivo dell’Amministrazione è pervenire ad una sostanziale integrazione tra i due sistemi che preveda la migrazione del Sistema Informatico Accasermamento su un’architettura di tipo web- based in sostituzione dell’attuale architettura client-server.

Dovrà inoltre essere prevista l’integrazione informatica tra il sistema informatico risultante ed il Sistema Informatico SICOGE. La descrizione completa della fornitura richiesta è riportata nel seguito del presente documento.

2 IL CONTESTO ORGANIZZATIVO

Ai fini del presente documento lo schema organizzativo di riferimento è il seguente:

Direzione Centrale dei Servizi Tecnico Logistici e della Gestione Patrimoniale

Altre Aree

Area 2^ Accasermamento Carabinieri

Area 1^ Accasermamento Polizia di Stato

Nell’ambito della Direzione Centrale per i Servizi Tecnico –Logistici e della Gestione Patrimoniale del Dipartimento della Pubblica Sicurezza del Ministero dell’Interno (in seguito detta D.C.S.T.L.G.P.), le Aree 1^ e 2^ svolgono tutte le attività correlate alla gestione dell’accasermamento delle Forze dell’Ordine: in particolare l’Area 1^° si occupa dell’accasermamento della Polizia di Stato mentre l’Area 2^° svolge gli analoghi compiti per l’Arma dei Carabinieri.

In estrema sintesi, con il termine “accasermamento” si intende l’insieme delle attività amministrative e contabili necessarie ad assicurare la manutenzione degli immobili adoperati dalle Forze dell’Ordine per i compiti d’istituto (Commissariati, Questure, Stazioni dei Carabinieri, etc.)

nei casi in cui gli immobili siano di proprietà pubblica e la gestione completa dei contratti di affitto (valutazione iniziale, stipula, rinnovi, pagamenti, dismissioni) nei casi in cui gli immobili siano di proprietà privata1. Il numero delle unità immobiliari gestite dai due Uffici è pari circa 10.000 mentre circa 5.000 sono i contratti di affitto in essere. Dal punto di vista contabile, i circa 10 capitoli di spesa gestiti in modo esclusivo dai due Uffici hanno avuto per l’anno 2010 uno stanziamento iniziale complessivo pari a circa 450 milioni di Euro.

I processi lavorativi eseguiti possono, in generale, essere distinti in due fasi:

• fase istruttoria ed amministrativa,

• fase contabile.

Dal punto di vista dell’oggetto del processo è possibile invece identificare tre principali raggruppamenti:

• pratiche di lavori di manutenzione su un immobile,

• pratiche di stipula o di rinnovo di un contratto di affitto di un immobile,

• pratiche di accreditamento di fondi, ai funzionari delegati, per le esigenze di cui sopra. L’ordine di grandezza delle pratiche aperte annualmente è di circa 3.500. Ogni pratica prende generalmente l’avvio da una richiesta ed è accompagnata, in tutto il suo iter, da una corrispondenza

in ingresso ed in uscita: in ciascuno dei due uffici esiste una sezione che provvede alla

protocollazione della corrispondenza. Annualmente vengono protocollati circa 15.000 documenti in ingresso e 3.000 in uscita.

Le successive fasi amministrative sono tipiche della singola tipologia di processo (nel S.I. Accasermamento sono censiti circa 100 tipi di processo) e, dopo l’esecuzione di un certo numero di passi logici, si concludono di norma con l’emissione di un provvedimento amministrativo di autorizzazione alla spesa (decreto o autorizzazione).

La successiva fase contabile prende l’avvio dalla ricezione del decreto amministrativo e si sviluppa in una serie di controlli, calcoli e produzione di atti formali, dipendenti dal tipo di pratica, fino alla produzione di un documento contabile di spesa: impegno, mandato di pagamento o ruolo.

Accanto a questo iter che prevede l’erogazione di un importo come corrispettivo di un lavoro o di un fitto ben determinato e fissato nell’oggetto della pratica esiste la gestione degli accreditamenti periodici o suppletivi che gli uffici dispongono a favore dei funzionari delegati, a valere sui capitoli

1 A seguito delle variazioni normative introdotte dall’art. 2 comma 222 della Legge 191 del 23/12/2009 , la gestione degli affitti è in via di definizione con Agenzia del Demanio presso il Ministero dell’Economia.

di spesa gestiti, in base alle richieste ed alle disponibilità e che vengono impiegati per scopi che sono resi noti agli uffici a consuntivo, tramite i rendiconti che gli stessi funzionari delegati inviano. Questo tipo di processo innesca ovviamente una problematica di controllo dei rendiconti, controllo del “saldo” di ogni funzionario delegato e di ridistribuzione, ogni anno, dei fondi eventualmente eccedenti (girofondi).

Una parte rilevante delle attività degli uffici è inoltre rivolta al controllo complessivo della spesa ed alla elaborazione di previsioni di spesa per gli anni futuri. In questo ambito il S.I. fornisce numerosi strumenti di verifica ed è in grado di elaborare, a partire dai dati correnti, previsioni di spesa per gli anni futuri.

3 I SISTEMI INFORMATIVI ATTUALMENTE IN USO

3.1 Il Sistema Accasermamento Forze di Polizia

Il S.I. Accasermamento, attualmente in uso presso le Aree 1^ e 2^ della D.C.S.T.L.G.P. fornisce uno strumento per l'elaborazione automatica delle informazioni in grado di alimentare una banca dati in cui confluiscano tutte le informazioni significative riguardanti:

• le comunicazioni protocollate entranti ed uscenti;

• le pratiche trattate (in termini generali);

• le unità logistiche trattate;

• le pratiche riguardanti i lavori;

• le pratiche riguardanti i contratti di manutenzione;

• le pratiche riguardanti i fitti passivi;

• le pratiche riguardanti gli alloggiamenti;

• i capitoli di spesa adoperati;

• gli accreditamenti alle prefetture,

• gli impegni di spesa;

• i mandati di pagamento;

• i ruoli di pagamento.

Pur presentandosi, da un punto di vista tecnico, come un sistema unico, il S.I. Accasermamento può essere logicamente suddiviso sia in base alle forze dell’ordine trattate sia in base al tipo di attività che viene svolta.

Sussistono difatti significative differenze tra l’area CC e quella PS dovute sia alla diversa preponderanza che hanno nelle due aree i diversi tipi di pratica (per la PS prevalgono i lavori, per i CC prevalgono i fitti) sia al fatto che per motivi organizzativi non sempre le modalità di lavoro nelle due Aree coincidono.

Va poi considerato che, nell’attuale organizzazione per Aree è confluita la ex divisione di Ragioneria del servizio Accasermamento e quindi vi è un’ulteriore divisione tra attività “amministrative” ed attività di “ragioneria”. Ad oggi il S.I. è utilizzato continuativamente dalla quasi totalità dei 90 impiegati degli Uffici e supporta tutte le normali attività d’ufficio.

A fianco del S.I. Accasermamento è stato inoltre sviluppato negli ultimi anni ed è operativo un sottosistema dedicato alla gestione del personale in forza presso l’Area Accasermamento P.S., per quanto riguarda:

• Gestione degli orari di lavoro,

• Gestione delle assenze,

• Gestione dei ritardi e dei recuperi,

• Gestione delle ferie e dei permessi,

• Gestione delle ore di lavoro straordinario,

• Gestione dei buoni pasto,

• Gestione delle premiazioni (“fondino”, “fondone”, etc.),

• Statistiche sulle assenze.

Nel suo complesso il Sistema Accasermamento conta, ad oggi, circa 480 funzioni2 on-line, 260 funzioni di stampa da sistema, oltre 100 stampe di documenti in formato Word ed Excel ed utilizza un data base relazionale strutturato in circa 250 tabelle e circa 90 viste per un totale di circa 200.000 Mbytes di dati archiviati.

3.1.1 L’architettura e l’infrastruttura tecnologica attuale del sistema Accasermamento

Dal punto di vista tecnico il S.I. Accasermamento si basa su un modello client-server di tipo Remote Database Model (RDM). Esso prevede la presenza di una unica banca dati - attualmente su Oracle 8 - residente su un unico sito elaborativo (Server Dati) mentre l'intera logica applicativa e

2 Si intende per funzione ogni singola scelta terminale di un menù disponibile all’utente, in grado di eseguire tutte le normali operazioni logiche di ricerca/lettura/scrittura/modifica/cancellazione su un insieme di dati, utilizzando una o più finestre di dialogo

l'interfaccia utente (Sql*Form 6.0 e Sql*Report 6.0) è interamente residente sulle macchine client ed è riprodotta su ognuna di esse.

Su ogni postazione di lavoro sono quindi presenti:

• i moduli software per l’esecuzione delle funzioni online, in formato *.FMX,

• i moduli software per l’esecuzione delle funzioni di stampa, in formato *.RPT,

• le librerie generali del sistema *.PLL

• il software “client” di Oracle per l’esecuzione delle funzioni,

• i prodotti MS Word ed Excel, utilizzati per la produzione dei documenti, direttamente dalle funzioni del S.I.

L’aggiornamento del software su ciascun client avviene automaticamente ogni mattina all’accensione delle postazioni di lavoro, tramite un processo che preleva automaticamente dal server gli eventuali moduli nuovi o modificati rilasciati in produzione.

Le caratteristiche dell’applicazione e dell’ambiente software sopra descritto sono tali da non porre nessun problema di compatibilità e requisiti hardware: il sistema è utilizzabile su qualsiasi P.C. dotato di S.O. Windows ’95 o successivo e di MS Office ’95 o successivo, i requisiti hardware richiesti, in termini di spazio su disco, memoria RAM e scheda grafica sono ampiamente soddisfatti da un qualsiasi P.C. attualmente in commercio.

Client Oracle run form Oracle run report Files *.fmx, *.rpt

Server Dati

RDBMS Oracle

Le stazioni di lavoro Client dispongono tutte del S.O. Microsoft Windows Xp. Il server dati è una macchina Fujitsu-Siemens biprocessore Xeon a 2,8 Ghz con 2 Gbyte di RAM e S.O. Windows Server 2003. La memoria su disco è attualmente divisa in tre dischi logici con capacità rispettivamente di 136, 107 e 29,2 GByte. Una analoga macchina è utilizzata come server documentale per l’archiviazione centralizzata dei documenti (Word) prodotti dagli utenti.

3.1.2 Le funzionalità attuali del sistema Accasermamento

La descrizione funzionale del sistema informatico dell’Accasermamento è presente nell’Allegato 4 in cui sono riportati gli schemi generali dei menù funzionali, l’elenco delle funzioni e, per ciascuna di essa, una breve descrizione dei compiti assolti. Nella tabella seguente sono riassunte le diverse aree funzionali come presentate dal menù principale del sistema.

1 Gestione Protocollo

2 Gestione Spedizione

3 Gestione Pratiche

4 Gestione Lavori

5 Gestione Fitti

6 Gestione Alloggiamenti

7 Gestione Unità Logistiche

8 Gestione Capitoli

9 Gestione Accreditamenti

10 Gestione Ragioneria

11 Gestione Capitolo Riservato

12 Gestione Affari Generali

13 Gestione Tabelle di Servizio

14 Gestione Fascicoli di Carattere Generale

La dimensione complessiva del S.I. misurata secondo la metodologia dei Function Point è pari a

7.381 FP.

3.1.3 I volumi dei dati del sistema Accasermamento

All’interno del presente paragrafo sono riportate le informazioni sui volumi delle principali entità trattate dalle banche dati del sistema. La seguente tabella illustra il dettaglio di tali valori

Banca dati	Occorrenze
Pratiche	73.000 circa
Protocolli in entrata	350.000 circa
Protocolli in uscita	65.000 circa
Unità Logistiche	11.000 circa
Decreti Lavori	13.000 circa
Decreti Fitti	31.000 circa
Accreditamenti	22.000 circa
Ruoli	11.000 circa
Impegni Lavori	1.700 circa
Mandati Lavori	2.400 circa
Mandati Fitti	1.250 circa
Storico Monitoraggio	46.000 circa

3.2 Il sistema Auditing Web

Il sistema “AuditingWeb” è, come dice il nome, un applicativo gestionale sviluppato per rispondere alle esigenze di pianificazione e controllo dei flussi di spesa relativamente ai capitoli di spesa gestititi dalla DCSTLGP ed è utilizzato, in via quasi esclusiva, dagli uffici centrali della DCSTLGP stessa.

Il flusso logico dell’applicativo si basa sull’immissione, effettuata dagli utenti delle diverse Aree, tramite apposite interfacce video, delle informazioni sulle “spese” previste ed eseguite, sui vari capitoli di spesa. Tali informazioni, opportunamente classificate e sintetizzate, vengono successivamente processate per ottenere tutta una serie di report cartacei ed elettronici sull’andamento della spesa complessiva consuntiva e preventiva.

Il sistema “Auditing” è assolutamente scollegato dal “core business” delle diverse Aree, non entrando assolutamente nella gestione della fase istruttoria delle varie pratiche amministrative che danno luogo ai provvedimenti di spesa.

In altri termini, mentre il S.I. Accasermamento nasce come un sistema gestionale per il supporto operativo alla fase istruttoria delle pratiche e si è “allargato” nel corso degli anni fino a comprendere esigenze più specificatamente contabili e di reporting direzionale, il S.I. Auditing Web è nato e si è specializzato esclusivamente come strumento per il controllo e la previsione dei flussi di spesa. In estrema sintesi si può dire che mentre per il S.I. Accasermamento le colonne portanti sono le pratiche, le unità logistiche ed i capitoli di spesa, per il S.I. AuditingWeb la colonna portante è soprattutto il capitolo di spesa.

Una certa sovrapposizione funzionale tra i due sistemi quindi esiste, ma non è completa: la figura seguente fornisce un quadro di massima della situazione.

Accasermamento

Auditing Web

Livello di sovrapposizione tra il S.I. Accasermamento e il sistema Auditing WEB

3.2.1 Le funzionalità attuali del sistema Auditing Web

L’applicativo WEB AUDITING Gestionale 3.0 della Direzione Centrale dei Servizi Tecnico- Logistici e della Gestione Patrimoniale è un sistema che fornisce supporto all’intero iter amministrativo. Ha come scopo principale di monitorare l’andamento delle procedure contrattuali efficacia, gestione e ottimizzazione dei tempi procedurali in relazione agli obiettivi assegnati.

Esso scambia i dati con il sistema di Accasermamento mediante database Microsoft SqlServer 2005.

La descrizione funzionale del sistema informatico dell’Auditing è presente nell’Allegato 5 in cui sono riportati gli schemi generali dei menù funzionali, l’elenco delle funzioni e, per ciascuna di essa, una breve descrizione dei compiti assolti. Nella tabella seguente sono riassunte le diverse aree funzionali come presentate dal menù principale del sistema.

1	Evidenza Direttore
2	Gestione Pratiche
3	Gestione Capitoli
4	Gestione Finanziaria Capitoli
5	Associazione Risorse Capitoli Speciali
6	Export Storico
7	Divisione per programmi
8	Gestione Richieste
9	Programmazione- Ricerca Generale
10	Programmazione – Gestione Modifiche
11	Modifiche alla Programmazione
12	Riepiloghi
13	Anagrafiche
14	Tabelle
15	Reportistica
16	Gestione Menù

17	Comunicazioni
18	Cambio Password
19	Guida utente

3.2.2 L’infrastruttura tecnologica e la banca dati del sistema Auditing Web

Il S.I. Web Auditing si basa su un applicativo sviluppato in tecnologia .NET versione 2.0. I linguaggi utilizzati sono:

1. XX.XXX per lo strato di presentation

2. C# per le parti core dell’applicativo

Il web server usato è IIS di Microsoft nella versione 6.0.

Il database server utilizzato è Microsoft SQL-Server versione 2005.

Il S.I. risiede su nr. 5 apparati server della Soc. OLIDATA con nr. 2 processori Dual Core AMD Opteron(tm) Processor 265 da 1794 MHz, 4 Gb di RAM e storage da 200 Gb. Il S.O. impiegato è Windows Server 2003 Standard Edition.

Dei nr. 5 apparati nr. 2 hanno funzione di Domain Controller del Dominio AUDIT e DNS SERVER, e nr. 3 di Web Server del Dominio AUDIT con SQL Server 2005.

3.3 I sistemi esterni coinvolti

Il SICOGE, acronimo di Sistema di Contabilità Gestionale Finanziaria, è il sistema informatico realizzato dalla Ragioneria Generale dello Stato per la gestione dei flussi informativi relativi al bilancio, agli impegni e ai titoli di spesa generati dalle attività delle diverse amministrazioni statali.

L’utilizzo di SICOGE ha eliminato, di fatto, i flussi cartacei tra le Amministrazioni e le Ragionerie conseguendo:

• una riduzione del margine di errore (legato alle ripetute trascrizioni dei titoli) e dei tempi di inoltro e di lavorazione;

• una conoscenza tempestiva per le Amministrazioni della situazione contabile dei propri capitoli di spesa;

• un miglioramento dei servizi al cittadino/creditore.

Ulteriori informazioni sul sistema SICOGE sono reperibili in rete all’indirizzo:

xxxx://xxx.xxx.xxx.xxx.xx/XXXXXXXX-X/x-XXXXXXXX0/XXXXXX/xxxx-x-xx-xxxxxx/xxxxx.xxxx.

4 DEFINIZIONE DELLA FORNITURA

L’oggetto della fornitura interessa la realizzazione del nuovo sistema LOCO, che sarà il sistema di riferimento Logistico-Contabile degli uffici interessati dai processi dell’Accasermamento delle Forze di Polizia e dei Carabinieri.

La realizzazione del sistema LOCO dovrà anzitutto prevedere la migrazione su piattaforma web del sistema Accasermamento, per utilizzare tutte le potenzialità del nuovo modello architetturale. La migrazione applicativa del sistema Accasermamento dovrà minimizzare il più possibile gli impatti sulle interfacce e sui flussi operativi note agli utenti.

I sistemi informatici attualmente utilizzati - il sistema Accasermamento, il sistema Auditing Web, il sistema esterno SICOGE - operano in maniera assolutamente indipendente l’uno dall’altro costringendo gli operatori ad una ripetizione di operazioni manuali che risultano non solo inutilmente costose ma potenziali fonti di errori. Il sistema Accasermamento si configura infatti come un Fornitore di informazioni di input sia verso il sistema Auditing Web che verso il sistema SICOGE ed in entrambi i casi il flusso viene implementato, attualmente, in maniera manuale attraverso la sostanziale ri-digitazione nei sistemi Auditing Web e SICOGE di dati già contenuti e gestiti dal sistema Accasermamento. Oltre all’adozione dell’architettura web per il sistema Accasermamento, la fornitura persegue anche l’obiettivo di eliminare le suddette operazioni

manuali per sostituirle con flussi informatici equivalenti. La realizzazione del sistema LOCO dovrà pertanto prevedere:

• l’integrazione del sistema Accasermamento con il sistema di Auditing;

• l’integrazione con il sistema del MEF SICOGE;

• l’erogazione di servizi a corredo.

4.1 Oggetto della fornitura

La fornitura richiesta è articolata nelle seguenti classi di beni e servizi:

1. Servizi di migrazione e sviluppo SW ad hoc per la realizzazione del nuovo sistema LOCO:

a. Servizi di porting applicativo, a corpo, per la migrazione dell’attuale sistema informatico Accasermamento in architettura web (S.I. Accasermamento Web);

b. Servizi, che saranno verificati a consuntivo, per l’integrazione tra il S.I. AccasermamentoWeb e il sistema AuditingWeb,

c. Servizi, che saranno verificati a consuntivo, per l’integrazione tra il S.I. AccasermamentoWeb e il sistema SICOGE,

2. Servizi di Assistenza sistemistica per la configurazione del sistema LOCO;

3. Servizio di MAC in garanzia;

4. Servizio di Formazione e addestramento d’aula degli utenti del sistema LOCO;

5. Servizi di Conduzione funzionale, Supporto agli utenti e MEV degli attuali sistemi;

6. Servizio di Project management per la Direzione dei lavori.

4.2 Durata della fornitura

Il contratto avrà la durata massima di 24 mesi decorrenti dalla data di inizio fornitura. Si precisa che negli ultimi 12 mesi di efficacia del contratto sarà erogata esclusivamente l’attività di manutenzione in garanzia sul software sviluppato e rilasciato nel corso dei precedenti 12 mesi, secondo quanto descritto al capitolo 7.

4.3 Componenti della fornitura a carico dell’Amministrazione

L’Amministrazione renderà disponibile quanto segue:

• le infrastrutture tecnologiche HW e SW di base presso la sede della DCSTLGP indicata dall’Amministrazione in Roma;

• le postazioni di lavoro necessarie all’esecuzione delle attività di Sviluppo, MEV, MAC e Supporto da parte del Fornitore, con le caratteristiche, la quantità e per i periodi indicati dal Fornitore stesso;

• l’operatività dei sistemi di elaborazione ed in genere degli apparati annessi, comprensivi del servizio di connettività, backup e restore;

• le strutture delle banche dati ed i relativi dati dei sistemi interni interessati dalla proposta progettuale oggetto di fornitura;

• le aule attrezzate per l’erogazione dei corsi;

• un gruppo di governo con competenze amministrative e tecniche afferenti la materia oggetto di fornitura e che fornirà tutte le indicazioni, i requisiti, le specifiche e verificherà lo stato avanzamento dei lavori;

• un responsabile tecnico di progetto con il compito di condurre, con il Fornitore la realizzazione della fornitura e di sottoscrivere ed accettare tutti i deliverable di fornitura finali ed intermedi per conto dell’Amministrazione.

4.4 Componenti della fornitura a carico del fornitore

Il fornitore dovrà renderà disponibile quanto segue:

• le licenze software ,compresi gli ambienti ed i tools di sviluppo previsti dal Fornitore, relative agli applicativi forniti (DB ed ogni altra licenza software necessaria all’utilizzo del sistema).

• Installazione e configurazione, sugli ambienti hardware messi a disposizione dall’Amministrazione, di tutti i software necessari all’utilizzo del sistema informatico.

• Ambiente di test in cui rilasciare i prototipi del sistema informatico in argomento ;

• Connessione internet protetta all’ambiente di test ;

5 LA SOLUZIONE PROGETTUALE

Nell’offerta tecnica il Fornitore deve descrivere l’architettura tecnica e funzionale del nuovo sistema LOCO della Polizia di Stato, coerente con le soluzioni applicative già disponibili all’interno dell’Amministrazione, indicare i benefici della nuova soluzione web-based e presentare il piano dei tempi di implementazione che consideri i principali rischi del progetto e le contromisure adottate.

6 SERVIZI DI MIGRAZIONE APPLICATIVA E DI SVILUPPO SW AD HOC

6.1 Descrizione

L’oggetto di questo servizio della fornitura consiste nella realizzazione del nuovo sistema LOCO della Polizia di Stato, mediante migrazione del sistema “Accasermamento” dall’attuale architettura client-server a una piattaforma web. Sono oggetto di questa parte della fornitura anche lo sviluppo del software di integrazione tra il sistema dell’Accasermamento ed il sistema di auditing web oltre al software di dialogo con il sistema SICOGE del MEF.

In particolare il nuovo sistema potrà essere realizzato secondo una delle seguenti modalità:

• Riuso e personalizzazione di sistemi già esistenti;

• Realizzazione ad hoc.

6.2 Dimensionamento

Gli elementi di stima della migrazione applicativa degli interventi devono essere derivati dai valori già espressi nei capitoli precedenti che illustrano l’entità dei sistemi informatici attualmente in uso.

Questa stima è indicativa e non esaustiva, e non dovrà essere vincolante per il Fornitore per l’effettuazione dell’offerta tecnica-economica che dovrà assicurare la copertura funzionale richiesta pena esclusione.

Sarà cura del Fornitore effettuare il conteggio dei Function Point (FP) per le nuove componenti di integrazione alla fine della redazione dei requisiti utente e delle specifiche funzionali. Il conteggio delle dimensioni in Punti Funzione dovrà essere effettuato secondo le modalità di conteggio definite dal IFPUG secondo lo standard in uso alla data.

6.3 Modalità di erogazione

Il servizio dovrà essere erogato in modo coerente alle indicazioni contenute nei “lemmi” del CNIPA, oggi DigitPA, nel “Dizionario delle forniture ICT” per la classe di fornitura “1.2.3 MSW Migrazione e conversione applicazioni” e “1.1.1 SSW Sviluppo e MEV di Sw ad hoc”. In particolare, i processi di erogazione dovranno attraversare le fasi indicate nella seguente tabella e produrre, per ognuna, i prodotti elencati.

Fasi	Prodotti
Analisi dei requisiti	Specifiche dei requisiti Piano di Progetto
Progettazione tecnica conversione	Progetto tecnico Prototipo tecnico (se necessario)
Progettazione applicativa	Specifica funzionale

Fasi	Prodotti
conversione
Progettazione Test e Collaudo	Specifiche di test Specifiche di collaudo
Realizzazione conversione	Codice software
Predisposizione del sistema	Infrastruttura hardware e software di collaudo ed esercizio Rapporto di esecuzione dei test
Produzione della documentazione di conversione	Documentazione utente
Qualificazione finale	Comunicazione pronti al collaudo Rapporto di esecuzione di test
Collaudo	Codice software, dati migrati in versione definitiva
Avviamento conversione	Rapporto su qualità e prestazioni del Prodotto

La conclusione di una fase e l’inizio della successiva dovranno necessariamente avvenire previa approvazione formale dei documenti di output ed input di ciascuna fase da parte dell’Amministrazione.

Al termine di ogni intervento il Fornitore dovrà fornire tutta la documentazione tecnica del S.I. aggiornata, per le attività di collaudo funzionale e di conteggio dei Function Point.

6.4 Collaudo

L’attività di collaudo per le applicazioni software migrate e per i nuovi moduli software di integrazione tra i sistemi, sarà eseguita da una Commissione di collaudo nominata dall’Amministrazione. La Commissione opererà con autonoma responsabilità e secondo le prescrizioni della normativa di riferimento con il compito di verificare che quanto realizzato dal Fornitore sia conforme ai requisiti indicati nella baseline contrattuale. Sarà oggetto di collaudo il prodotto migrato ed il nuovo software di integrazione realizzato. Le prove di collaudo saranno eseguite nell’ambiente di collaudo dell’Amministrazione, configurato dal Fornitore secondo quanto specificato nel processo di Progettazione e nelle specifiche di collaudo.

7 SERVIZIO DI SPERIMENTAZIONE E AFFIANCAMENTO ALL’AVVIAMENTO

Successivamente all’accettazione della Fornitura dovrà essere erogato dal fornitore un periodo di

sperimentazione della durata di 2 mesi che consiste nell’esercizio del prodotto software.

Tale fase ha l’obiettivo di verificare l’affidabilità, le prestazioni, l’usabilità, la sicurezza del prodotto e la sua manutenibilità. Si dovrà fornire un piano dettagliato della fase di sperimentazione.

Dopo la fase di sperimentazione, che non potrà durare più di 2 mesi, l’Amministrazione procederà con la messa in esercizio della fornitura. Tale fase prevede:

• la definizione a sistema di tutte le chiavi di accesso in base ai ruoli e ai profili degli utenti di tutte le sedi periferiche

• la definizione di tutti i Servizi centrali coinvolti nel processo e agli amministratori di sistema dell’Amministrazione.

Durante l’avviamento del sistema in esercizio il forniture dovrà assicurare un servizio di affiancamento per almeno 1 mese. Durante tale fase il fornitore dovrà garantire tutti gli interventi volti ad assicurare il corretto funzionamento e l’operatività del sistema, nel rispetto delle caratteristiche di qualità e dei livelli di servizio offerti.

8 SERVIZIO DI ASSISTENZA SISTEMISTICA

8.1 Descrizione

Il servizio di assistenza sistemistica ha lo scopo di attuare tutte le attività necessarie alla configurazione degli apparati hardware del software di base e dei prodotti middleware degli ambienti target, resi disponibili dall’Amministrazione, oggetto del servizio di sviluppo e MEV del software applicativo

Tale assistenza da erogare a cura del fornitore per tutta la durata della fornitura è propedeutica anche alla creazione e alla gestione degli ambienti di sviluppo, test/collaudo ed esercizio oltre alla fase di installazione del sw applicativo.

8.2 Modalità di erogazione e dimensionamento

Il servizio sarà erogato a consumo per gli ambienti target, per un impegno minimo di almeno 15 giorni erogati da un mix di figure professionali senior certificati per gli ambienti target resi disponibili dall’Amministrazione ed oggetto dello sviluppo e MEV del software applicativo:

• Amministratori di sistema e di DB;

• Analisti programmatori;

• Sistemisti junior, senior e consulente;

9 SERVIZIO DI MAC IN GARANZIA

9.1 Descrizione

Il servizio ha lo scopo di rimuovere le cause e gli effetti, sia sulle interfacce utente sia sulle basi dati, dei malfunzionamenti delle procedure e dei programmi in esercizio del nuovo sistema LOCO.

La manutenzione correttiva è normalmente innescata da una segnalazione di impedimento all’esecuzione dell’applicazione/funzione o dal riscontro di differenze fra l’effettivo funzionamento del software applicativo e quello atteso, come previsto dalla relativa documentazione o comunque determinato dai controlli che vengono svolti durante l’attività dell’utente.

I malfunzionamenti imputabili a difetti presenti nel codice sorgente, o nelle specifiche di formato o di base dati, non rilevati a suo tempo durante il ciclo di sviluppo o in collaudo, sono risolti dal servizio di manutenzione correttiva con la riparazione del codice sorgente.

9.2 Modalità di erogazione

Il servizio dovrà essere erogato “in garanzia” per i 12 mesi solari successivi all’esito positivo del collaudo effettuato dall’Amministrazione conseguente alla migrazione del sistema sulla nuova piattaforma Web e alla realizzazione degli oggetti software di integrazione. Le fasi previste si caratterizzeranno per i contenuti descritti nei “lemmi” del CNIPA, oggi DigitPA, nel “Dizionario delle forniture ICT” per la classe di fornitura “1.2.2 MAC Manutenzione correttiva ed adeguativa”, cui si rimanda. Le fasi previste, al minimo, saranno le seguenti:

Attività	Output
Analisi del problema	Specifica della modifica Piano di test
Realizzazione della modifica	Patch del sistema. Casi di test
Xxxxxxxx	Xxxxxxx di collaudo
Attuazione delle modifiche	Prodotto software modificato
Rendicontazione	Rapporto di manutenzione

A tal fine Il fornitore dovrà fornire un servizio di call center,con copertura dal lunedì al venerdì in orario 9/18, per dare un supporto immediato al primo contatto sui problemi segnalati.

Il servizio dovrà perseguire i seguenti obiettivi:

• assicurare la comunicazione tempestiva ed efficace tra l’utenza e le strutture di supporto e viceversa;

• smistare alle strutture di assistenza specifiche la risoluzione dei problemi non risolvibili nell’ambito di questo servizio;

Dovranno essere garantiti i seguenti livelli minimi di servizio:

1) Risposta entro 20”, per l’80% delle chiamate ricevute.

2) Percentuale di chiamate perdute non superiore al 4%.

Le Richieste potranno essere inoltrate con le seguenti modalità:

• Numeri Telefonico, E-Mail,Fax

10 SERVIZIO DI FORMAZIONE E ADDESTRAMENTO D’AULA

I servizi di formazione saranno erogati al fine di :

• istruire l’utenza finale al corretto uso delle postazioni secondo le procedure i metodi e le funzioni erogate dal sistema;

• illustrare all'utenza centrale i servizi erogati dalla fornitura.

L’erogazione della formazione, aula, avverrà frontalmente. Il contenuto formativo fornito dovrà necessariamente essere coerentemente integrato, manutenuto ed erogato con la documentazione utente del sistema nonché aggiornato a seguito delle attività contrattuali di manutenzione, evoluzione e gestione.

10.1 Obiettivi formativi

La formazione erogata avrà l’obiettivo di:

❑ formare l’utenza all’utilizzo delle postazioni fornite;

❑ illustrare le architetture, il trattamento, i livelli qualitativi e le implementazioni realizzate;

❑ illustrare i contenuti dei servizi oggetto delle classi di forniture del presente capitolato, i termini del servizio ed i suoi livelli.

10.2 Utenza

I destinatari dei servizi di formazione saranno dipendenti degli uffici centrali e periferici interessati.

10.3 Soddisfazione dei Requisiti

La formazione dovrà essere erogata presso le strutture messe a disposizione dall’Amministrazione, allestite per l’erogazione della formazione. Tale allestimento comprenderà:

• infrastrutture didattiche e informatiche adeguate allo svolgimento dei corsi;

• postazioni di lavoro, in numero adeguato ai discenti previsti per ciascuna edizione del corso. Il possesso di una certificazione UNI EN ISO 9001:2000, valida al momento di presentazione dell’offerta da parte del Fornitore (oppure da parte di uno dei soggetti costituenti il raggruppamento

o l’associazione temporanea d’impresa) nel settore merceologico dell’istruzione, costituirà titolo

preferenziale in sede di valutazione.

Ulteriore titolo preferenziale sarà costituito dall’erogazione della formazione secondo le linee guida UNI ISO 10015:2001.

Le fasi previste si caratterizzeranno al minimo per i contenuti descritti nei “lemmi” del CNIPA, oggi DigitPA, nel “Dizionario delle forniture ICT” per la classe di fornitura “1.3.2 FOR – Formazione e addestramento”.

Le fasi per il servizio di formazione saranno le seguenti:

Attività	Prodotti
Analisi dei requisiti	Specifica dei requisiti
Progettazione e sviluppo contenuti	Piano di progetto
Gestione operativa	Erogazione corsi Rapporto attività di formazione

10.4 Dimensionamento

L’erogazione dei corsi sarà effettuata per un totale di 5 giornate d’aula. A corredo del materiale didattico dei corsi dovrà essere fornito un CBT/WBT con l’obiettivo di illustrare tutte le funzionalità del nuovo sistema, lato utenti, con la durata minima di 10 minuti.

11 SERVIZI DI CONDUZIONE FUNZIONALE, SUPPORTO AGLI UTENTI E MEV DEGLI ATTUALI SISTEMI INFORMATICI

11.1 Descrizione

Obiettivo del servizio, in accordo con l’oggetto della fornitura è quello di continuare a fornire i servizi di conduzione funzionale, di supporto agli utenti e di MEV sui sistemi attualmente in uso durante le attività di implementazione del nuovo sistema.

11.2 Modalità di erogazione e dimensionamento

I servizi dovranno essere erogati on-site presso le sedi dell’Amministrazione. I servizi di conduzione funzionale e supporto agli utenti saranno erogati “a corpo”, fino al rilascio in esercizio del nuovo sistema LOCO. Il servizio di MEV dovrà essere erogato “ a consumo”, attraverso singoli interventi richiesti dall’Amministrazione. Per ogni intervento si applicano le fasi progettuali descritte nel capitolo che illustra lo “sviluppo SW ad hoc”.

11.3 Dimensionamento

L’impegno per i servizi di conduzione funzionale e assistenza è attualmente pari a 1 FTE annuo.

La dimensione di tutti gli interventi di MEV sarà al massimo di 500 FP. Il conteggio delle dimensioni in Punti Funzione dei singoli interventi dovrà essere effettuato secondo le modalità di conteggio definite dal IFPUG secondo lo standard in uso alla data.

12 SERVIZIO DI PROJECT MANAGEMENT PER LA DIREZIONE DEI LAVORI.

12.1 Descrizione

Il controllo e la gestione di tutte le attività connesse con l’erogazione dei servizi / prodotti costituisce uno strumento operativo di buona amministrazione per il governo dei contratti ICT che consente di perseguire gli obiettivi che sono stati preposti nell’ottica di un miglioramento continuo dei servizi e delle infrastrutture esistenti.

A tal proposito si osserva che per i contratti di rilievo a valenza pluriennale, non è possibile trascurare l’effetto della continua evoluzione dei sistemi informativi che, nel tempo, porta a scelte operative di riprogettazione delle infrastrutture già realizzate, con lo scopo di migliorare l’efficacia e l’efficienza dei servizi congiuntamente ad un abbattimento dei costi sostenuti.

L’esperienza acquisita tramite le risultanze delle attività di Direzione Lavori può altresì contribuire all’evoluzione delle forme contrattuali, sia per quanto concerne la definizione delle diverse tipologie di servizio richieste, che per la definizione dei livelli di servizio, delle misure e degli indicatori, dei modelli di tariffazione e delle modalità di applicazione delle penali.

Le fasi previste si caratterizzeranno al minimo per i contenuti descritti nei “lemmi” del CNIPA, oggi DigitPA, nel “Dizionario delle forniture ICT” per la classe di fornitura “4.1.2 DLA Direzione Lavori”.

Le fasi per il servizio di project management per la direzione dei lavori saranno le seguenti:

Attività	Prodotto
Realizzazione del servizio	Servizio predisposto
Gestione operativa	Erogazione del servizio

12.2 Dimensionamento

Per tutta la durata del servizio la conduzione ed il controllo dovrà essere affidata dal Fornitore ad un Direttore tecnico dei lavori. L’impegno previsto per la figura professionale del Direttore Lavori che

dovrà garantire il regolare funzionamento del servizio e coordinare tutte le attività di fornitura dovrà essere stimato dal Fornitore.

13 DESCRIZIONE DEI PRODOTTI

Di seguito si fornisce una descrizione dei contenuti dei prodotti delle attività di realizzazione del nuovo sistema informativo LOCO, che diventeranno proprietà dell’Amministrazione a seguito del collaudo di accettazione del nuovo sistema.

13.1 Specifica dei requisiti

Il documento di Specifica dei requisiti rappresenta il documento principale di descrizione dei requisiti. Descrive il "perché” e il “che cosa" del progetto ed è un punto fermo su cui convalidare tutte le decisioni future. L’input al documento è costituito da una descrizione di carattere generale delle esigenze espresse dall’utente-committente.

Il documento di Specifica dei requisiti dovrà contenere l'elencazione formale e relativa descrizione di tutti i requisiti della fornitura, siano essi funzionali e non funzionali, emersi nella fase di definizione delle esigenze utente. I requisiti devono essere univocamente identificabili, classificati e relazionati tra loro in scala gerarchica e tramite riferimenti incrociati.

La prima classificazione necessaria è tra requisiti funzionali e non funzionali, alla quale seguirà una analisi di dettaglio con ulteriore scomposizione e classificazione:

• I requisiti funzionali descrivono le funzionalità dei servizi del sistema. Il contenuto rappresenta quello che il sistema deve e non deve fare. Il loro sviluppo può prevedere la realizzazione dei casi d’uso e degli altri documenti previsti contrattualmente.

• I requisiti non funzionali definiscono vincoli e proprietà del sistema, rispetto a standard specifici (ad esempio di accessibilità), caratteristiche qualitative o ad indicazioni specifiche (come tempi di risposta, realizzabilità, portabilità, ecc)..

Il livello di completezza del documento deve consentire una chiara visibilità dei requisiti, impliciti ed espliciti, e dei cambiamenti e/o dei servizi aggiuntivi che si propone di realizzare e dei benefici attesi, facendo riferimento alla realtà con cui l’utente ha familiarità: lo scopo è di poter condividere tali intenti con l’utente, in modo da garantire la totale adeguatezza delle finalità dell’intervento alle aspettative.

Il livello di dettaglio deve consentire di raggiungere un’adeguata base per la successiva fase di progettazione tecnica / applicativa e di progettazione dei test, per la verifica e validazione dei requisiti.

In linea generale il documento di Specifica dei requisiti deve contenere:

• la definizione del progetto, glossario delle definizioni e acronimi utilizzati (o riferimento al glossario del progetto);

• il contesto di riferimento (attuale e previsto) e l’ipotesi di soluzione; deve essere fornita una descrizione, quanto più dettagliata in base agli elementi disponibili, della soluzione, in termini sia funzionali che architetturali, che si offre all’utente rispetto alle esigenze. Questa parte include la descrizione delle esigenze, dei vincoli, del processo di business e dei processi operativi di cui è composto;

• gli attori coinvolti, numero e tipologia degli utenti coinvolti;

• i requisiti funzionali e non funzionali, descritti, classificati e codificati (attributi) come previsto dal piano di gestione dei requisiti. E’ necessaria una descrizione testuale dei requisiti individuati finalizzata a consentire una completa comprensione e condivisione con l’utente di quanto definito;

• nei casi previsti, vanno inseriti i riferimenti ai documenti di specifiche dei casi d’uso;

• la descrizione degli eventi coinvolti nel requisito;

• la descrizione, o riferimento a documento esterno, dell’architettura complessiva del sistema che si intende realizzare. Si richiede di individuare e rappresentare, con il formalismo che si ritiene più opportuno, le diverse componenti hardware e software e, se necessario, indicando i benefici derivanti dalla soluzione architetturale proposta, o determinate sue componenti;

• l’analisi dei dati, la descrizione dei dati trattati, in forma di schema concettuale iniziale, nonché stima iniziale dei volumi;

• le indicazioni, nel caso di sviluppo di prototipo, delle caratteristiche realizzative e dei suoi obiettivi;

• evidenza e descrizione delle modifiche in corso d’opera, intervenute successivamente alla prima consegna del documento e gestite secondo le modalità definite nel piano di gestione dei requisiti. È fondamentale, in qualunque momento, garantire la tracciabilità delle modifiche: tutti i documenti esplicativi dei contatti con l’utente (verbali di riunione, lettere, mail, fax, ecc..) devono quindi essere inseriti tra gli allegati e costituire parte integrante del documento;

• i riferimenti a ulteriore documentazione di interesse prodotta o preesistente, utile per la comprensione dei requisiti e del contenuto del documento (esempio: definizione dei requisiti

nella documentazione contrattuale, studi di fattibilità, documentazione a corredo del software originale da assoggettare a MEV, resoconti riunione, ecc.).

La specifica dei requisiti potrà contenere, direttamente o come allegato, il disegno logico dell’architettura del servizio, ossia il disegno di massima dell’architettura del servizio, costituito dalla visione logica e non tecnologica delle componenti e servizi interni ed esterni alla specifica fornitura, determinante per identificare, nei tempi opportuni, la corretta integrazione a livello di business con il sistema esistente ed ogni eventuale opportunità di riuso degli elementi presenti all’interno della stessa, o di altre linee di business.

Gli altri documenti di specifica dei requisiti (specifica dei casi d’uso, glossario e piano di gestione dei requisiti) sono di seguito descritti per le loro caratteristiche principali.

13.2 Specifica dei Casi D’uso

Il caso d’uso descrive i requisiti funzionali del sistema da sviluppare secondo lo standard di modellazione UML. Il caso d’uso non descrive la struttura interna al sistema né come lavora, ma solo l’interazione fra un Attore ed il sistema da sviluppare, specificando cosa il sistema fa per ottenere il risultato atteso.

Il caso d’uso è quindi estremamente semplice nella sua articolazione, in quanto deve permettere di individuare l’attore, l’attività che svolge, le condizioni e i vincoli per effettuare questa attività. Su questa base è necessario definire uno standard di specifica dei casi d’uso, in cui sono state immesse le regole sintattiche per la loro stesura. Il documento di specifica dei caso d’uso contiene, per ogni caso d’uso definito, le seguenti sezioni:

• Breve descrizione del Caso d’uso.

• Elenco degli attori con indicazione dell’attore principale.

• Precondizioni.

• Flusso Base degli Eventi.

• Eccezioni.

• Postcondizioni.

• Flussi alternativi.

• Sottoflussi.

• Informazioni aggiuntive.

• Scenari.

13.3 Piano di gestione dei requisiti

Il documento dettaglia come sono organizzati, gestiti e documentati i requisiti all’interno del progetto, come i requisiti sono tracciati e le loro eventuali relazioni, descrivendo i tipi di documenti previsti, le categorie e tipologie di requisiti ed i loro attributi (codice identificativo, priorità, stato, indice di stabilità, ecc.), specificando altresì le informazioni da raccogliere ed i meccanismi di controllo da usare per la misurazione, la validazione, la reportistica e il controllo dei cambiamenti dei requisiti.

Il piano di gestione dei requisiti fornisce anche le linee guida su come verrà gestita la tracciabilità e la modifica dei requisiti nell’intero svolgimento della fornitura.

Il documento si può configurare come una sezione integrata in preesistenti documenti di pianificazione del progetto / fornitura o attraverso un documento specifico (piano di gestione dei requisiti).

13.4 Specifiche funzionali

Il documento definisce totalmente l'applicazione in modo da ottenere una descrizione funzionale completa, non ambigua ed indipendente dalle scelte tecnologiche di realizzazione.

Contiene in modo completo ed esaustivo l’analisi dell’applicazione interessata sia relativamente ai processi ed alle modalità con cui tali processi risulteranno visibili agli utenti finali, sia al disegno logico dei dati secondo il modello relazionale, sia per quanto riguarda gli aspetti non funzionali (architettura, sicurezza, vincoli, prestazioni, ecc.), sia alla documentazione delle interfacce.

Il livello di completezza deve essere tale da:

• consentire l’approvazione delle funzionalità da parte dell’Amministrazione e dell’utente;

• consentire la produzione delle Specifiche di test e collaudo;

• consentire lo svolgimento delle successive fasi di sviluppo;

• garantire la tracciabilità con quanto descritto nel documento di requisiti.

Il disegno della base dati fa parte della specifica funzionale; deve contenere la descrizione della struttura dati, in termini di:

• schema concettuale;

• volumi trattati;

• schema logico;

• dati per il caricamento iniziale;

• aspetti di sicurezza;

• eventuali collegamenti con base dati esterne;

• mapping concettuale-logico;

• schema fisico;

• glossario;

• dizionario dati.

13.5 Prototipo

Per una più agevole verifica del prodotto dovrà essere inoltre realizzato un prototipo web navigabile dell’applicazione. In tale caso il prototipo è un elemento delle Specifiche funzionali, rivolto alla esplicitazione dell’interfaccia utente, in termini di layout e di modalità di utilizzo dell’applicazione.

13.6 Piano di test

Il piano di test è il documento principale delle specifiche di test, ha lo scopo di guida allo svolgimento dei test e delle valutazioni connesse ai test. Oltre ad individuare le prove da effettuare, definisce quali tipologie di test, quale strategia e quali tecniche utilizzare, come va condotto il test, chi lo eseguirà, cosa va testato, quanto durerà, il livello di copertura assicurato, l’ambiente e le risorse necessarie per la progettazione, la preparazione e l’esecuzione, le modalità di gestione delle anomalie, in coerenza con il processo di Risoluzione dei problemi.

In particolare, il piano di test deve contenere:

• la definizione del progetto, glossario delle definizioni e acronimi utilizzati (o riferimento al glossario del progetto), gli assunti, i vincoli e rischi;

• le indicazioni sulla strategia, la metodologia, il livelli e le tipologie di test e le tecniche utilizzate per la progettazione ed esecuzione dei test;

• i ruoli e responsabilità del gruppo di test predisposto dal Fornitore;

• il legame con gli altri processi presenti nella fornitura;

• i criteri di ingresso ed uscita delle vari livelli o cicli di test previsti;

• gli strumenti eventualmente utilizzati e le conseguenti strategie per l’automazione e gestione del test;

• la pianificazione temporale delle attività (in alternativa come rimando al piano di progetto);

• la pianificazione delle risorse necessarie all'esecuzione dei test (prodotti, ambienti operativi, risorse umane, ecc;), la descrizione dell’ambiente necessario per l’esecuzione dei test, comprendente le modalità di predisposizione delle basi dati di test;

• la lista degli oggetti sottoposti a test (codice, documentazione, eventuali prodotti intermedi);

• la lista dei test funzionali e non funzionali pianificati con il loro legame (mappatura) ai requisiti (funzionali e non) e gli attributi definiti, come ad esempio tipologia del test e il livello di rischio rappresentato;

• il livello di copertura atteso;

• la specifica dei test pianificati, o il rimando all’allegato specifica di test;

• la descrizione dell’ambiente di test e delle modalità di generazione ed eventuale mascheramento delle basi dati di test;

• la descrizione delle modalità di esecuzione e di rendicontazione dei test, compresi i rapporti di esecuzione dei test;

• la descrizione delle modalità di gestione delle anomalie, in coerenza con il processo di Risoluzione dei problemi;

• i riferimenti a ulteriore documentazione di interesse prodotta o preesistente utile per la comprensione dei test e del contenuto del documento (esempio: definizione dei requisiti nella documentazione contrattuale, studi di fattibilità, documentazione a corredo del software originale da assoggettare a MEV, resoconti riunione, ecc.).

13.7 Specifica di test

La specifica di test è il risultato della progettazione di dettaglio dei test, precedentemente pianificati, e contiene, per ogni test, i dettagli necessari per la loro esecuzione ed utilizzo, da parte sia del Fornitore che dell’Amministrazione.

Il documento deve integrare il Piano di Test e deve, per assicurare le appropriate caratteristiche qualitative della progettazione, utilizzare uno standard ed una opportuna codifica delle informazioni e livello dei contenuti.

Per i test funzionali lo standard di documentazione deve garantire la ripetibilità e riusabilità del test, l’ indipendenza da altri test e un livello di dettaglio delle informazioni sufficiente a garantire la riesecuzione e riscontro oggettivo dell’esito degli stessi da parte di personale diverso da chi ha progettato il test iniziale o sviluppato il software.

In particolare, ogni test, funzionale e non funzionale, deve contenere:

• una codifica univoca e il legame con il test definito in pianificazione (piano di test) e i relativi requisiti o aspetti della progettazione funzionale/tecnica oggetto del test;

• la descrizione di ogni condizione di test prevista;

• la descrizione delle precondizioni, ossia i requisiti per avviare il test (operazioni manuali ed automatiche, ad esempio il caricamento di dati sul database), necessarie per rendere autoconsistente e rieseguibile (condizioni di ripetibilità) il test o per segnalare la sua relazione con altri test o funzionalità (regole di propedeuticità). Condizioni particolari da aggiungere alle basi dati di test;

• la descrizione della sequenza di azioni da svolgere, i dati da utilizzare e i risultati attesi da verificare durante le attività svolte;

• l’eventuale descrizione di ulteriori combinazioni di dati da utilizzare, sulla medesima sequenza di azioni descritta, per verificare la stessa o altre condizioni di test;

• la descrizione della verifica del test, per indicare quali azioni specifiche sono previste per accertare l’esito del test oltre a quelle svolte direttamente durante le azioni svolte; a titolo di esempio si possono citare le verifiche di congruità sul database di dati inseriti o modificati.

13.8 Specifiche di collaudo

Le specifiche di collaudo definiscono l’ambiente di collaudo, che dovrà riprodurre fedelmente l’ambiente di esercizio; esse sono composte dal Piano di Collaudo, che costituisce la guida per lo svolgimento delle attività di collaudo di qualsiasi software realizzato, e la Specifica di collaudo, che descrive il dettaglio dei test.

Il contenuto del piano di collaudo e della specifica di collaudo è analogo al Piano di test e Specifica di test precedentemente descritta, con particolare attenzione alle seguenti informazioni:

• strategia, metodologia e obiettivi del collaudo;

• pianificazione temporale del collaudo;

• specificazione dei requisiti e dei vincoli dell’ambiente di collaudo;

• caratteristiche dell’hardware e del software di base previste per il collaudo;

• oggetti sottoposti a collaudo;

• elenco dei test con evidenza della copertura rispetto ai requisiti e al rischio;

• descrizione dei test formali, funzionali, non funzionali da eseguire, con particolare attenzione ai test specifici per la validazione dei requisiti;

• descrizione dei test automatici eventualmente realizzati e delle modalità di impiego;

• le metriche ed indicatori di qualità e relative soglie;

• i criteri di accettazione da parte dell’Amministrazione;

• i contenuti previsti nei verbali di collaudo;

13.9 Rapporto di esecuzione dei test

La reportistica di test è un aspetto base per il controllo del progetto di test e lo stato di avanzamento dello stesso. Il rapporto di esecuzione dei test deve essere disponibile per una consultazione diretta dal personale dell’Amministrazione, e consentire di controllare e monitorare il risultato del test da un livello alto di visione (aree funzionali e requisiti) fino al dettaglio dei singoli test.

Al fine di fornire un riferimento concreto alla documentazione necessaria per il controllo e consuntivo delle attività di test, si elencano alcuni rapporti normalmente più utilizzati e richiesti:

• Sommario e dettaglio dei risultati di esecuzione delle sessioni di test.

• Risultati dei test (passati, falliti, non eseguibili, non eseguiti) per grado di rischio.

• Risultati dei test (passati, falliti, non eseguibili, non eseguiti) per requisito.

• Elenco dei test senza specifica di test (progettazione non completata).

• Elenco dei test mai eseguiti, senza risultati di esecuzione.

• Contenuto di ogni singolo test (specifica di test).

• Statistiche risultati test (passati, falliti, non eseguibili, non eseguiti), percentuali sul totale, per funzione / requisito.

• Test e risultati dei test associati con difetti.

• Grafico e lista dei difetti per loro priorità e stato.

• Grafico di andamento nel tempo dei difetti aperti, suddivisi per priorità.

13.10 Prodotto software

Per prodotto software si intende genericamente l’insieme degli oggetti software, che sono eseguibili sul sistema direttamente o tramite mediazione da parte di un compilatore o di un interprete, a titolo esemplificativo e non esaustivo quindi:

• programmi;

• tracciati e definizioni dati;

• schermi di input/output;

• procedure;

• query.

Fanno parte del prodotto, inoltre, l’help on-line e l’eventuale manualistica on-line, nonché l’eventuale codice di test e collaudo con i relativi dati di supporto.

Ove applicabile, il codice sorgente dovrà comprendere anche il codice per la distribuzione automatizzata. In tal caso, esso dovrà comprendere:

• procedura di installazione ripetibile;

• procedura di disinstallazione ripetibile;

• parametri di configurazione dell’ambiente su cui l’applicazione si deve installare.

13.11 Documentazione utente

La documentazione utente, rivolta all’utente finale delle applicazioni, è composta dal Manuale utente e dal Manuale di gestione dell'applicazione, rivolta a utenti tecnici.

Manuale utente : il manuale utente deve fornire una descrizione generale dell’applicazione e una guida operativa all’utilizzo delle singole funzionalità utilizzabili.

Manuale di gestione : il manuale di gestione è lo strumento necessario alle strutture preposte all’installazione ed esercizio dell’applicazione. È un manuale rivolto a personale tecnico.

14 FIGURE PROFESSIONALI

Le figure professionali che compongono il gruppo di lavoro devono avere le seguenti competenze e e titoli di massima, con almeno una certificazione tra quelle indicate:

CAPO PROGETTO
Titolo di Studio	Laurea in discipline tecniche o cultura equivalente
Certificazioni/Xxxxxx/ Abilitazioni	• PMI; • ITIL v3 Intermediate: Service Design;
Anzianità lavorativa	• Minimo 10 anni, di cui almeno 5 anni di provata esperienza nella gestione di progetti di grandi dimensioni con più team cross-functional richiedenti definizione e applicazione di processi organizzativi complessi
Conoscenze	• Metodologie di misura progetti • Metodologie di sviluppo • Redazione di specifiche di progetto • Analisi di processi • Conoscenze di tecniche e prodotti SW per project management e risk management • Ottime capacità relazionali

ANALISTA PROGRAMMATORE
Titolo di Studio	Diploma di perito informatico o equivalente
Certificazioni/Xxxxxx/ Abilitazioni	• Da dichiarare a cura dell’impresa
Anzianità lavorativa	Minimo 5 anni, di cui almeno 2 nella funzione
Esperienze Lavorative	• Verifica della corretta applicazione di metodi e standard • Sviluppo di analisi tecnica di media complessità • Documentazione procedure • Programmazione e test (preparazione di casi di test ed esecuzione di test) • Partecipazione a gruppi di progetto di medie/grandi dimensioni • Installazione e personalizzazione di sistemi anche complessi • Progettazione ed integrazione di sistemi
Conoscenze	• Tecnologie emergenti • Metodologie di analisi e disegno di prodotti SW • sistema di virtualizzazione VmWare • Tecniche di programmazione Object oriented • Ottima conoscenza dei linguaggi di programmazione: ASP, HTML/XTML/XML/javascript • Tecniche di programmazione in ambiente Java • DBMS Relazionali e in particolare del DBMS offerto, DBA

	• Strumenti di modellazione dati • Strumenti per il cleaning e la qualità dei dati
PROGRAMMATORE
Titolo di Studio	Diploma di perito informatico o equivalente
Anzianità lavorativa	Minimo 3 nella funzione
Esperienze Lavorative	• Preparazione ed esecuzione di casi di test • Preparazione di documentazione di programmi • Partecipazione alla stesura di specifiche tecniche • Partecipazione a gruppi di progetto di medie dimensioni • Installazione e personalizzazione di sistemi anche complessi • Progettazione ed integrazione di sistemi
Conoscenze	• Metodologie di analisi, disegno di prodotti SW • linguaggi di programmazione • Strumenti per la codifica dei programmi • Tecniche di programmazione strutturata e in ambiente java • Ottima conoscenza dei linguaggi di programmazione: ASP, HTML/XTML/XML/javascript
PROGETTISTA DI SISTEMI INFORMATICI
Titolo di Studio	Laurea in discipline tecniche o cultura equivalente
Certificazioni/Xxxxxx/ Abilitazioni	ITIL v3 Foundation;
Anzianità lavorativa	Minimo 10 anni, di cui almeno 4 nella funzione
Esperienze Lavorative	• Redazione di specifiche di progetto • Valutazione costi e soluzioni tecniche • Stima di risorse per la realizzazione di progetto • Definizione di scopi, obiettivi, approcci e strategie per la realizzazione del progetto • Analisi e progettazione di sistemi informativi, package e procedure complesse • Definizione delle componenti della soluzione • Stima di tempi • Controllo prestazioni • Responsabilità su gruppi di progetto • sistema di virtualizzazione VmWare
Conoscenze	• Tecniche e prodotti SW per Project Management e Risk Management • Architetture di sistemi complessi e tecnologie • Problematiche architetturali • Integrità, riservatezza ed affidabilità dei sistemi informativi • Impatti organizzativi e system reingeneering • Tecniche di assessment di processi • Assicurazione qualità, benchmarking e capacity planning •
SISTEMISTA
Titolo di Studio	Laurea in discipline tecniche o cultura equivalente

Certificazioni/Xxxxxx/ Abilitazioni	Da dichiarare a cura dell’impresa
Anzianità lavorativa	Minimo 8 anni, di cui 4 nel ruolo
Esperienze Lavorative	• Installazione, personalizzazione, tuning e troubleshooting di server e client in ambienti Microsoft e Linux • Esperienza specialistica su tecnologie e prodotti di SAN e back-up • Attività di installazione, configurazione ed update del software, sia di S.O. che di altri prodotti presenti in fornitura • Tuning ed ottimizzazione della configurazione del sistema per garantirne la massima efficienza (utilizzo della cpu, memoria,I/O dischi e spazio) • Configurazione/ gestione di sottosistema dischi ed integrazione in ambiente SAN • Stesura di documenti tecnici ed operativi • Progettazione test integrati •
Conoscenze	• Specifiche competenze: o configurazioni cluster Windows e Linux o configurazioni dei DBMS Relazionali, DBA o Configurazione di infrastruttura di Storage e sistemi di back-up • Conoscenza Sistemi Operativi Linux e Windows, • Linguaggi : C - C++ - • sistema di virtualizzazione VmWare • Conoscenze specialistiche delle applicazioni enterprise conformi agli standard Java • Conoscenza della piattaforma HP Open View • Conoscenza del sw di Backup Symantec • Skill specifico nella gestione, configurazione e tuning di Application Server

RESPONSABILE BASE DATI (DBA)
Titolo di Studio	Diploma di perito informatico o diploma analogo
Certificazioni/Xxxxxx/ Abilitazioni	Da dichiarare a cura dell’impresa
Anzianità lavorativa	Minimo 8 anni, di cui almeno 3 nella funzione.
Esperienze Lavorative	• Partecipazione nella funzione a progetti analoghi in ambito economico, finanziario, Pubblica Amministrazione
Conoscenze	• Gestione, ottimizzazione e progettazione di RDBMS; • data modeling; • tecniche di disegno di DB applicativi • tecniche di gestione di dizionari dati aziendali e, più in generale, delle informazioni aziendali; • tecniche di Integrazione di dati provenienti da sistemi diversi • Data quality measurement and assessment; • tecniche di data cleaning; • sistemi operativi (Windows/Unix/Linux).

15 PIANO DI PROGETTO

A partire dalla data di inizio attività, il Fornitore deve svolgere tutte le attività che consentono la conduzione coordinata della fornitura ed il governo della stessa da parte dell’Amministrazione, nel rispetto dei requisiti di tempi, costi e qualità di cui al presente documento, al contratto ed ai relativi allegati.

Il Fornitore dovrà predisporre e mantenere aggiornato un Piano di Progetto relativo a tutte le attività previste dal rapporto di fornitura, indicando per ciascuna attività i tempi, le risorse necessarie ed il relativo impegno. In particolare il piano di progetto dovrà prevedere i seguenti contenuti minimi:

• una sintesi delle caratteristiche della fornitura (requisiti e/o obiettivi che il progetto si prefigge di soddisfare);

• una descrizione del prodotto ed i servizi che il progetto dovrà realizzare per soddisfare i requisiti del contratto;

• la calendarizzazione delle attività;

• eventuali vincoli;

• le risorse che devono essere rese disponibili dall’Amministrazione per la riuscita del progetto e le attività proprie e specifiche dell’Amministrazione;

• le risorse assegnate ed i relativi ruoli e profili professionali e CV in formato europeo;

• la scomposizione dei deliverables contrattuali al fine di definire unità di lavoro al livello di dettaglio idoneo ad esercitare un efficace controllo in fase di esecuzione;

• la definizione della periodicità con cui verrà rilevato lo stato di avanzamento lavori (SAL), gli indicatori da utilizzare per misurare l’avanzamento, le date programmate di svolgimento di Riesami e Verifiche;

• le principali milestone, vale a dire i momenti a cui corrispondono fatti rilevanti dal punto di vista gestionale e che costituiscono dei punti di controllo essenziali per la verifica del corretto avanzamento dei lavori;

• i problemi aperti e/o le decisioni pendenti;

• le richieste di cambiamenti.

Il Fornitore in particolare dovrà produrre:

• un primo Piano di Progetto in sede di presentazione dell’Offerta Tecnica, che dia evidenza di come intenda organizzare le proprie strutture per eseguire la fornitura richiesta, di quali risorse saranno assegnate, con indicazione dei relativi profili professionali e dei relativi

ruoli/responsabilità, di quali strumenti e metodologie saranno utilizzati in caso di aggiudicazione della commessa, delle tempistiche programmate;

• una versione aggiornata del Piano di Progetto, da consegnare all’Amministrazione entro dieci giorni dalla sottoscrizione del contratto e, successivamente, entro il termine di dieci giorni solari dalla scadenza di ciascun trimestre e/o su richiesta dell’Amministrazione.

Dovranno essere altresì indicate, attraverso una tabella riepilogativa, le risorse professionali (in numero e qualifica) che si intendono allocare per la realizzazione della fornitura. Le risorse professionali allocate per il progetto dovranno essere anche riportate in un allegato a parte, illustrate con il proprio curriculum vitae (CV) anonimo e codificato secondo il modello europeo. In caso di aggiudicazione dell’appalto il Fornitore indicherà nel piano definitivo i nominativi delle risorse professionali assegnate al progetto indicando per ognuna il CV di riferimento esibito in fase di offerta.

Le variazioni della composizione delle risorse professionali nel corso del progetto dovranno avere il benestare dell’Amministrazione ed in ogni caso non potranno essere di spessore inferiore a quanto offerto in sede di gara.

16 PIANO DI QUALITÀ

Il Fornitore dovrà presentare in sede di presentazione dell'Offerta Tecnica, il Piano di qualità che intende applicare nel corso della fornitura. Il Piano di qualità deve essere prodotto in rispetto alle norme ISO/IEC 9126 e deve contenere, al minimo, i seguenti contenuti:

• gestione: devono essere fornita la descrizione dell'organizzazione del gruppo di lavoro impegnato sul contratto indicando il responsabile di commessa;

• documentazione: deve essere definito l'insieme della documentazione da produrre nel corso dell'attuazione del contratto, che assume il ruolo di evidenza oggettiva dell'esecuzione delle attività da cui è generata;

• obiettivi di qualità: devono essere identificati in modo chiaro ed inequivocabile gli obiettivi di qualità della fornitura; per questo è necessario definire per ogni prodotto da realizzare o servizio da erogare gli attributi di qualità, le metriche con cui misurare gli attributi identificati, i valori limite ritenuti accettabili con cui confrontare le misure degli attributi di qualità effettuate sulla base delle metriche definite;

• procedura per la valutazione della qualità di un prodotto/servizio: deve essere definita una procedura per la valutazione della qualità dei prodotti e/o servizi che espliciti: modalità di

misura, modalità di calcolo ed aggregazione di misure per il computo di indicatori derivati, frequenza delle misure, periodi temporali di riferimento;

• gestione delle anomalie o sofferenze: devono essere riportate o referenziate le specifiche procedure previste per la gestione di problemi quali non conformità, slittamenti, richieste di cambiamenti. La descrizione deve comprendere la casistica, la modulistica di supporto prevista, i ruoli e le responsabilità delle risorse coinvolte;

• controllo del codice software: devono essere definiti e descritti i criteri, le procedure e gli strumenti adottati per il controllo (immissione, salvaguardia e catalogazione) delle versioni degli elementi software del progetto in sviluppo.

Le metriche proposte dovranno coprire tutte le classi della fornitura prevedendo per ognuna almeno una metrica dedicata alla documentazione.

17 REQUISITI DI QUALITÀ E LIVELLI DI SERVIZIO

I capitolo riporta gli indicatori di qualità e i livelli di servizio che caratterizzano al minimo, il profilo della qualità della fornitura che il Fornitore dovrà proporre e riportare nel Piano della Qualità proposto in fase di offerta.

Classe di fornitura	SVILUPPO E MEV DI SOFTWARE AD HOC
Caratteristica /Sottocaratteristica	Manutenibilità / modificabilità
Indicatore/Misura	Complessità ciclomatica – COC
Sistema di gestione delle misure	Tale indicatore misura la complessità della struttura di controllo di un modulo software. La rilevazione è fatta tramite tool automatici di misura specifici per il linguaggio di programmazione utilizzato.
Unità di misura	Numero.
Dati elementari da rilevare	Numero di archi del grafo. Numero di nodi del grafo. Numero di componenti software connesse.
Periodo di riferimento	NA
Frequenza esecuzione misure	NA
Regole di campionamento	NA

Formula di calcolo	L’algoritmo di calcolo è il seguente: COC = E – N + p dove E = numero di archi del grafo del modulo; N = numero di nodi del grafo del modulo; p = numero di componenti software connesse.
Regole di arrotondamento	Intero più prossimo.
Obiettivi (valori soglia)	COC < 21
Azioni contrattuali	Il superamento dei valori di soglia comporta l’applicazione di una penale dello 0,05 % del corrispettivo del software per ogni unità in aumento rispetto al valore di soglia.
Eccezioni	NA

Classe di fornitura	SVILUPPO E MEV DI SOFTWARE AD HOC
Caratteristica /Sottocaratteristica	Manutenibilità / modificabilità
Indicatore/Misura	Livello di documentazione – LDO
Sistema di gestione delle misure	Tale indicatore misura la quantità dei commenti presenti in un modulo software. La rilevazione è fatta tramite tool automatici di misura specifici per il linguaggio di programmazione utilizzato.
Unità di misura	Percentuale.
Dati elementari da rilevare	Numero di Line Of Code (LOC). Numero di linee di commento.
Periodo di riferimento	NA
Frequenza esecuzione misure	NA
Regole di campionamento	NA
Formula di calcolo	L’algoritmo di calcolo è il seguente: LDO = LC/LOC dove LC = numero delle linee di commento; LOC = numero delle linee di codice; Il valore di LDO va espresso in percentuale.
Regole di arrotondamento	Intero più prossimo.
Obiettivi (valori soglia)	25% < LDO
Azioni contrattuali	Il superamento dei valori di soglia comporta l’applicazione di una penale dello 0,5 % del corrispettivo del software per ogni unità in diminuzione rispetto al valore di soglia.
Eccezioni	NA

Classe di fornitura	SVILUPPO E MEV DI SOFTWARE AD HOC
Caratteristica /Sottocaratteristica	Affidabilità / maturità
Indicatore/Misura	Difettosità – NDIF
Sistema di gestione delle misure	L’obiettivo è quello di tenere sotto controllo l’affidabilità dell’applicazione, monitorando il tasso degli errori applicativi che provocano il fermo dell’applicazione. Verrà utilizzato lo stesso sistema di gestione sia per le attività di nuovo sviluppo sia per gli interventi di manutenzione evolutiva. Il sistema dovrà essere in grado di raccogliere ed elaborare i dati elementari in particolare nelle fasi di test, collaudo e nell’arco temporale relativo all’ avviamento/diffusione. Il sistema di rilevazione deve prevedere una classificazione delle malfunzioni ad esempio in base alle seguenti tipologie: non bloccante: malfunzione che, pur impedendo l’uso delle funzioni software, non inibisce l’operatività da parte dell’utente; l’utente può cioè ugualmente pervenire ai risultati attesi mediante l’utilizzo di altre funzionalità comunque offerte dal sistema; bloccante: malfunzione che rende totalmente o parzialmente non utilizzabili le funzionalità disponibili all’utente. I fermi dell’applicazione sono provocati da errori bloccanti. Ogni malfunzione rilevata deve essere analizzata e classificata per rilevarne la causa. Malfunzioni derivanti dalla medesima causa devono essere conteggiate una sola volta.
Unità di misura	Percentuale
Dati elementari da rilevare	Dimensioni in FP delle applicazioni a inizio del periodo di osservazione. Nr malfunzioni per tipo. Fase di rilevazione (test, collaudo, avviamento / diffusione).
Periodo di riferimento	Primi sei mesi di esercizio (dopo l’eventuale avviamento).
Frequenza esecuzione misure	NA
Regole di campionamento	NA
Formula di calcolo	Dati necessari: NDIFB = MBTOT / FP NDIFNB = MNBTOT / FP MBTOT = numero totale di Malfunzioni Bloccanti rilevate nel periodo di riferimento; MNBTOT = numero totale di Malfunzioni Non Bloccanti rilevate nel periodo di riferimento; Il valore va espresso come percentuale.
Regole di arrotondamento	La percentuale va arrotondata al decimale successivo dell’ultimo decimale significativo del valore di soglia. (es. per valore di soglia = 0,01 l’arrotondamento è al terzo decimale).

Classe di fornitura	SVILUPPO E MEV DI SOFTWARE AD HOC
Obiettivi (valori soglia)	NDIF= 0,2%
Azioni contrattuali	Il superamento dei valori di soglia comporta l’applicazione di una penale da determinare come 0,1 % del corrispettivo.
Eccezioni	L’applicazione delle regole contrattuali inizia dopo un periodo di osservazione dall’inizio dell’avviamento

Classe di fornitura	FORMAZIONE E ADDESTRAMENTO
Caratteristica / Sottocaratteristica	Soddisfazione
Indicatore/Misura	Accettazione corso / modulo didattico tradizionale – ACT
Metodi e strumenti di misura	Elaborazione indicatori relativi all’erogazione della singola edizione del corso/modulo (EDD, AAD)
Unità di misura	Numero
Dati elementari da rilevare	Livello di soddisfazione del partecipante
Periodo di riferimento	Fase di erogazione del servizio
Frequenza esecuzione misure	Ogni singolo corso didattico
Regole di campionamento	N.A.
Formula di calcolo	ACT = 0,6EDD+0,4AAD Media pesata degli indicatori relativi a: EDD: Efficacia didattica del docente AAD: Adeguatezza attrezzature didattiche
Regole di arrotondamento	Arrotondamento alla seconda cifra decimale
Obiettivi, valori soglia	ACT > 6
Azioni contrattuali	Per ACT =< 6 l’Amministrazione può richiedere la riproposizione totale o parziale dell’edizione del corso (a totale carico del Fornitore) e richiedere la predisposizione e l’attuazione di specifiche azioni correttive
Eccezioni	Nessuna

Classe di fornitura	MANUTENZIONE CORRETTIVA
Caratteristica /Sottocaratteristica	Efficienza/Efficienza temporale
Indicatore/Misura	Rispetto dei tempi di risoluzione del problema – RTRP
Sistema di gestione delle misure	L’indicatore misura la differenza tra il tempo previsto per la risoluzione del problema ed il tempo effettivamente impiegato per la risoluzione del problema. Le durate sono classificate per tipo sulla base dei livelli di gravità definiti dall’Amministrazione a livello contrattuale. Per esempio: Sistema bloccato o gravi problemi nel sistema produttivo Problemi nella gestione del sistema produttivo Una funzione non opera correttamente Gap/errori nella documentazione: richieste di sviluppo Si fa riferimento alle analisi di rendicontazione delle attività di manutenzione
Unità di misura	Percentuale
Dati elementari da rilevare	durata prevista di risoluzione problema durata effettiva di risoluzione problema
Periodo di riferimento	Non inferiore a 6 mesi solari consecutivi
Frequenza esecuzione misure	Nei momenti stabiliti per verificare il livello di qualità del servizio di manutenzione
Regole di campionamento	Vanno considerate tutte le richieste pervenute
Formula di calcolo	Dati necessari: durata prevista di risoluzione problema (Tp) durata effettiva di risoluzione problema (Te) RTRP = Tp − Te Si calcola quindi la frequenza delle durate inferiori al valore normale FN i = N (durata ≤ valore normale) ×100 RTRP Neventi e la frequenza delle durate superiori al valore limite FL i = N (durata ≤ valore limite) ×100 RTRP Neventi i = 1,...,4 (le durate sono classificate in funzione della gravità)
Regole di arrotondamento	Le durate vanno arrotondate al giorno La frequenza va arrotondata al punto percentuale sulla base del primo decimale al punto % per difetto se la parte decimale è ≤ 0,5 al punto % per eccesso se la parte decimale è > 0,5

Classe di fornitura

MANUTENZIONE CORRETTIVA

Obiettivi (valori soglia)

Obiettivi:

RTRP ≤ valore normale con FNRTRP ≥ frequenza normale RTRP ≤ valore limite con FLRTRP ≥ frequenza limite Valori soglia:

I valori massimi per la soluzione del problema sono definiti contrattualmente in funzione della gravità, tali valori per manutenzione correttiva sono:

Gravità 1 : 8 ore,

Gravità 2 : 16 ore,

Gravità 3 : 24 ore,

Gravità 4 : 84 ore.

frequenza normale = 95% frequenza limite = 100%

Azioni contrattuali

Per ogni 1% di FNRSP inferiore alla frequenza normale si applica una penale in termini di percentuale del corrispettivo nel periodo di riferimento, come dalla seguente tabella:

Gravità 1 = 0,5% del corrispettivo nel periodo di riferimento Gravità 2 = 0,4 % del corrispettivo nel periodo di riferimento Gravità 3 = 0,3 % del corrispettivo nel periodo di riferimento Gravità 4 = 0,2 % del corrispettivo nel periodo di riferimento

Per ogni 1% di FLRTPC inferiore alla frequenza limite normale si applica una penale in termini di percentuale del corrispettivo nel periodo di riferimento, come dalla seguente tabella:

Gravità 1 = 1% del corrispettivo nel periodo di riferimento Gravità 2 = 0,8 % del corrispettivo nel periodo di riferimento Gravità 3 = 0,6 % del corrispettivo nel periodo di riferimento Gravità 4 = 0,4 % del corrispettivo nel periodo di riferimento

Eccezioni

L’applicazione delle regole contrattuali inizia dopo un periodo di osservazione dall’avvio del servizio della durata di 3 mesi.

Le conseguenze del mancato rispetto delle richieste nei tempi previsti non viene applicato se le cause non sono imputabili al Fornitore di servizi.

18 LUOGO DI SVOLGIMENTO DELLE ATTIVITÀ LAVORATIVE

Le attività saranno eseguite presso gli uffici di Roma dell’Amministrazione.

19 MODALITÀ DI COMPILAZIONE DELLE OFFERTE

19.1 Offerta Economica

Nell’offerta oltre al costo globale della fornitura, dovranno essere forniti i costi distinti per le singole attività e dovrà essere presentata secondo quanto riportato nell’Allegato 1

19.2 Offerta Tecnica

La offerta tecnica dovrà contenere un indice completo del proprio contenuto, nonché, a pena di esclusione dalla gara una Relazione tecnica, sulla base delle linee guida indicate nell’Allegato 2, in lingua italiana priva di qualsiasi indicazione diretta o indiretta di carattere economico, dalla quale si evincono in maniera diretta e dettagliata le caratteristiche del sistema offerto, mettendo a confronto le caratteristiche tecniche minime richieste e quelle offerte, le modalità di fornitura e di presentazione dei servizi oggetto di fornitura, con riferimento dei requisiti indicati nel Capitolato tecnico.

Il numero massimo di pagine del documento comprensivo di allegati dovrà essere pari a 100 e dovrà essere redatto su fogli formato A4 con carattere Arial corpo 13. I curricula delle figure professionali proposte e il Piano di Qualità potranno costituire un allegato a parte.

In particolare, l’offerta dovrà esplicitamente attestare la rispondenza della fornitura a tutti i requisiti e vincoli espressi dal capitolato, pena l’esclusione dalla gara.

Lo schema di offerta tecnica dovrà essere conforme, al minimo, al seguente schema:

• Premessa

• Soluzione progettuale

• Modalità di erogazione del servizi

o Servizi di migrazione e di sviluppo SW ad hoc

o Servizio di assistenza sistemistica

o Servizio di MAC in garanzia

o Servizio di formazione e addestramento in aula degli utenti

o Servizi di conduzione funzionale, supporto agli utenti e di MEV

o Servizio di project management per la direzione lavori

• Organizzazione e Qualità

o Organizzazione della fornitura

o Curricula delle risorse professionali offerte

o Piano di qualità generale

Si richiede che nella offerta tecnica siano identificati i processi previsti e le metriche che saranno applicate durante lo svolgimento del progetto, e che siano specificati gli impegni presi nei riguardi di quanto richiesto, insieme ad ogni informazione opportuna per chiarire al Ministero le modalità con le quali questi impegni saranno soddisfatti.

20 CRITERI DI VALUTAZIONE DELL’OFFERTA

La fornitura sarà aggiudicata, a favore del concorrente che avrà presentato l’offerta più vantaggiosa sotto il profilo tecnico economico, da individuare sulla base dei parametri e con i pesi di seguito elencati:

a) Prezzo 30%

b) Caratteristiche tecniche 70%

Il punteggio sarà determinato dalla somma algebrica del punteggio tecnico e del punteggio dell’offerta economica calcolato applicando la seguente formula:

Y = PT + PE

I punti relativi all’offerta tecnica (PT) saranno attribuiti secondo il criterio di seguito specificato:

PARAMETRI DI VALUTAZIONE		PESI
P – Progetto
P1	Architettura del nuovo sistema	10
P2	Piano di progetto	5
P3	Tempi di realizzazione	5
TOTALE		20
S – Servizi

S1	Servizi di migrazione applicativa e di sviluppo SW ad hoc	10
S2	Servizio di Assistenza sistemistica	2
S3	Servizi di MAC in garanzia	3
S4	Servizi di Conduzione funzionale, Supporto agli utenti e di MEV	5
S5	Servizio di Formazione e Addestramento d’aula	5
S6	Servizio di Project management per la direzione lavori	5
TOTALE		30
O –Organizzazione e Qualità
O1	Organizzazione della fornitura	5
O2	Quantità e qualità dei risorse professionali offerte	10
O3	Piano di qualità generale	5
TOTALE		20
TOTALE PUNTI TECNICI		70

Per ciascuno dei pesi indicati, la commissione assegnerà ad ogni offerta tecnica un punteggio utilizzando i criteri di cui all’Allegato 3.

I punti relativi all’offerta economica (PE) saranno attribuiti secondo il criterio di seguito specificato:

Legenda:

Y = punteggio totale ottenuto; PE = Punteggio economico Pbase = è il prezzo a base d’asta;

Pofferto = è il prezzo dell’offerta in esame;

I punteggi ottenuti dall’esame tecnico ed economico saranno quindi sommati al fine di ottenere la graduatoria finale, aggiudicando la gara alla Società che ha ottenuto il punteggio maggiore.

La gara sarà aggiudicata all’offerta che avrà conseguito la massima valutazione totale. Tutti i calcoli saranno arrotondati alla seconda cifra decimale. A parità di punteggio complessivo si proporrà l’aggiudicazione a favore dell’offerente che avrà ottenuto il maggiore punteggio tecnico.

Document Metadata

Table of Contents

CAPITOLATO TECNICO

Document Metadata