Contract

La documentazione del presente Appalto Specifico, che dettaglia e contestualizza l’oggetto della for- nitura, e la documentazione dell’Accordo Quadro a cui si fa riferimento per quanto non esplicitamente indicato nel presente AS, regolamenteranno in maniera congiunta gli obblighi scaturenti dall’aggiu- dicazione della presente procedura nonché l’erogazione dei servizi oggetto della stessa.

Come previsto dall’Accordo Quadro, in caso di difformità tra quanto indicato nella documentazione dell’Accordo Quadro e dell’Appalto Specifico prevale la disciplina particolare introdotta dall’Ap- palto Specifico.

1.1. RIFERIMENTI E ALLEGATI

Il presente Appalto Specifico fa pieno riferimento alla documentazione dell’Accordo Quadro “Servizi Applicativi”. Le relative appendici sono allegate al presente capitolato comprensive delle specializ- zazioni che si rendono necessarie per adeguarle alle specificità del contesto organizzativo del Co- mune:

• Appendice 1 - Profili professionali

• Appendice 2 - Indicatori di Qualità

• Appendice 3 – Cicli e Prodotti

1.2. GLOSSARIO

Nel corpo del presente capitolato tecnico, si intende con il termine:

• “AQ”: l’Accordo Quadro;

• “AS”: l’Appalto Specifico basato sull’AQ;

• “CAD”: Codice dell’Amministrazione Digitale;

• “Fornitore AS”: l’Impresa aggiudicataria dell’AS;

• “Fornitura”: il complesso delle attività e dei servizi richiesti in AS;

• “Ente”: Messina Social City;

• “Comune”: il Comune di Messina;

• “Servizi base”: l’insieme dei servizi, analiticamente descritti al paragrafo 4.11 del presente Capitolato Tecnico, che il Comune, in tutto o in parte, obbligatoriamente richiede in Appalto specifico, per usufruire dell’AQ;

• “Servizi complementari”: l’insieme dei servizi, analiticamente descritti al paragrafo 4.12 del presente Capitolato Tecnico, che il Comune può, in tutto o in parte, richiede in Appalto spe- cifico, in aggiunta ai servizi base;

• “Servizi accessori”: l’insieme dei servizi, analiticamente descritti al paragrafo 4.13 del pre- sente Capitolato Tecnico;

• “Servizi realizzativi”: si intendono tutti i servizi che producono o modificano software anche attraverso parametrizzazioni e personalizzazioni;

• “Obiettivo”: unità organica di lavoro, affidabile al fornitore, in cui si scompongono i servizi erogati in modalità progettuale. Dal punto di vista del Fornitore l’obiettivo è assimilabile ad un “progetto”, la cui esecuzione è suddivisa nelle fasi, indicate dal ciclo di vita applicato, che richiedono la realizzazione di specifici prodotti.

• “Baseline del sistema”: versione formalmente approvata degli elementi della configurazione del sistema, indipendentemente dal supporto di registrazione, formalmente descritta e fissata in un momento specifico del ciclo di vita del sistema.

• “Richiesta di offerta”: la documentazione predisposta dal Comune che verrà inviata ai forni- tori nella fase di rilancio del confronto competitivo per l’aggiudicazione di un Appalto Spe- cifico.

• “Riuso di un software”: il complesso di attività svolte per poterlo utilizzare in un contesto diverso da quello per il quale è stato originariamente realizzato, al fine di soddisfare esigenze similari a quelle che portarono al suo primo sviluppo.

• “MAC”: Manutenzione correttiva;

• “MAD”: Manutenzione adeguativa;

• “MEV”: Manutenzione evolutiva;

2. CONTESTO

AMAM S.p.A., in ottemperanza a quanto previsto dall’art. 68 del Decreto Legislativo 7 marzo 2005,

n. 82 e nel rispetto dei principi di economicità e di efficienza, tutela degli investimenti, riuso e neu- tralità tecnologica, ha deliberato di prendere a riuso dal Comune di Salerno, il software denominato SIMEL2.

Grazie all’adozione della piattaforma applicativa SIMEL2, la società intende dotarsi di applicativi verticali per i procedimenti amministrativi di tutti gli uffici in modo da permetterne la completa inte- grazione.

L’obiettivo della fornitura è quindi la personalizzazione, parametrizzazione ed evoluzione, in fun- zione dei prodotti software inclusi nella piattaforma SIMEL2 e di interesse per la Società, aggiun- gendo nuovi moduli funzionali ed integrati con quelli già esistenti nonché l’implementazione di nuovi.

3. DEFINIZIONE DELLA FORNITURA

Per quanto sopra, oggetto della prestazione è l’erogazione di servizi professionali di supporto specia- listico applicati per la personalizzazione e parametrizzazione, l'evoluzione, il mantenimento e la ge- stione della piattaforma applicativa SIMEL2, nonché l’integrazione e verticalizzazione nell’ambito delle soluzioni applicative in uso presso l’azienda. La fornitura è strutturata in servizi base, comple- mentari e servizi accessori.

La seguente tabella riassume per le tipologie di Servizi richiesti la composizione dei servizi in AS:

Servizi	Valore stimato	Sottoservizio	Richiesto
Base	Indicativamente 60%	Sviluppo e Manutenzione Evolutiva	SI

	del valore dell’AS	Manutenzione adeguativa	SI
	del valore dell’AS	Parametrizzazione e personalizzazione	SI
Complementari	Indicativamente 37% del valore dell’AS	Gestione applicativa	SI
		Manutenzione correttiva	SI
		Contenuti di siti web	NO
		Servizio di supporto specialistico	SI
Accessori	Indicativamente 3% del valore dell’AS	Formazione	SI

Per ciascun servizio applicativo sono indicate nel capitolo 4.24 Metriche e dimensionamento i volumi stimati.

3.1. DURATA

Il contratto derivante dalla procedura in oggetto avrà decorrenza dalla stipula del contratto, o dall’eventuale esecuzione anticipata dello stesso, e avrà durata di 36 mesi decorrenti dalla conclu- sione della fase di attivazione dei servizi oggetto dell’appalto specifico.

4. DESCRIZIONE DEI SERVIZI

Il presente Appalto Specifico è teso ad indirizzare le esigenze progettuali di manutenzione ed evolu- zione di tutti i prodotti e sistemi informativi facenti parte o afferenti all’ambito del presente Capito- lato.

L’ambito delle attività richieste all’Appaltatore, in ottemperanza a quanto descritto dall’AQ, è ulte- riormente dettagliato nelle schede tecniche allegate di cui ne è riportato elenco al paragrafo 1.1.

Per la definizione delle attività e della responsabilità prevista per le fasi progettuali previste nei cicli di vita del software, si farà riferimento all’Appendice 3 – Cicli e Prodotti.

L’azienda si riserva, per ciascuno degli interventi affidati in appalto, di governare con proprie risorse la conduzione delle attività progettuali e tecnico-architetturali, quali la definizione dell’architettura applicativa, l’analisi dei requisiti e l’analisi funzionale, mentre darà in affidamento di volta in volta al fornitore un tipo di ciclo di vita del software adeguato all’obiettivo ed al contesto di riferimento in cui andrà attuato (Ciclo Completo, Ciclo Realizzativo, ecc.).

In linea con quanto sancito dall’Accordo Quadro, durante l’arco temporale di validità dell’Appalto Specifico, ogni intervento progettuale sul singolo applicativo sarà ulteriormente scomposto in Obiet- tivi la cui esecuzione verrà suddivisa in fasi proposte dall’Appaltatore in accordo con il fornitore aggiudicatario.

Sarà quindi l’azienda che all’avvio di ciascuna specifica fase di sviluppo, si incaricherà di fissare gli Obiettivi attribuendo le attività al Fornitore.

In generale tutti gli Obiettivi affidati al Fornitore, siano essi sviluppi nuovi, manutenzioni evolutive, adeguativa, migliorative, dovranno seguire gli standard di sviluppo, organizzativi e documentali pre- visti dall’azienda e dettagliati all’avvio dell’obiettivo.

4.1. REQUISITI GENERALI

L’erogazione dei servizi base richiede la conoscenza delle principali piattaforme tecnologiche e lin- guaggi di programmazione, nonché competenze di gestione, controllo e misurazione dei progetti in- formatici e la conoscenza della normativa di riferimento.

Il Fornitore dovrà tener conto dei seguenti principali requisiti di base, che saranno ulteriormente spe- cificati nel kick off di avvio del servizio:

• paradigma SOA come paradigma architetturale preferenziale: le applicazioni dovranno essere progettate tenendo debitamente conto delle necessità di integrazione all'interno dei sistemi informativi dell’azienda. Per tale motivo, allorquando intervengano necessità di interagire con altri sistemi, od opportunità proattiva di esposizione del sistema in oggetto verso altri sistemi, dovrà essere utilizzato un approccio orientato ai servizi (SOA);

• aderenza ad altre linee guida architetturali: al di là delle linee guida architetturali di massima può essere necessario definire ulteriori indicazioni su come dispiegare le varie componenti (es. dislocazione delle risorse grafiche di applicazioni web, ...);

• utilizzo di tecnologie, linguaggi e design object Oriented: dovranno essere utilizzati linguaggi, tecnologie e strumenti ispirati al paradigma object-Oriented;

• utilizzo di database relazionale come strumento di persistenza dei dati: il sistema, allorquando necessiti di persistere dati applicativi, dovrà farlo su database di tipo relazionale, da scegliersi nell'insieme di DBMS previsti dagli standard dell’Amministrazione;

• utilizzo di piattaforma J2EE come piattaforma di realizzazione: la piattaforma tecnologica di implementazione è rappresentata dalla piattaforma enterprise basata sul linguaggio java;

• utilizzo di stack di librerie/framework applicativi predefiniti: al di sopra della piattaforma JEE sarà possibile utilizzare un set di framework applicativi/librerie selezionate dall’Amministra- zione. L'eventuale utilizzo di librerie aggiuntive dovrà: (a) essere limitato alle finalità non coperte dallo stack applicativo standard, (b) concordato con l’Amministrazione;

• evidenza della meta-progettazione: dovranno essere utilizzate linea guida di meta-design che indichino quali pattern utilizzare per passare dall'astratto del problema al concreto dell'imple- mentazione in una determinata e specifica piattaforma target. Nel caso in cui l’Amministra- zione fornisca una sua linea guida di meta-design per lo stack applicativo prescelto per la realizzazione del progetto, il fornitore potrà decidere di adottarlo per lo sviluppo, così come potrà decidere di adottare strumenti che implementino automaticamente tale meta-design (es. strumenti di generazione del codice).

• conoscenza della piattaforma SIMEL2

L’erogazione dei servizi realizzativi dovrà essere realizzata utilizzando un set di linguaggi e fra- mework applicativi ben definiti, selezionati dall’azienda, con l'obiettivo di garantire da un lato la più ampia compatibilità possibile con gli ambienti di esercizio previsti e dall'altro lato di permettere al fornitore la realizzazione delle casistiche/funzioni tipicamente previste dalla tipologia dei sistemi og- getto di realizzazione.

Gli standard di sviluppo e/o processo ed ulteriori requisiti e vincoli di dettaglio, saranno resi disponi- bili in fase di kick off di avvio del servizio.

Nei paragrafi successivi si riporta un elenco non esaustivo delle principali competenze tecniche e le principali competenze trasversali e normative richieste. Tale elenco ha carattere meramente generale di trasversale applicabilità nell’Appalto Specifico, tuttavia non costituisce un vincolo o limitazione per eventuali ulteriori prodotti necessari al soddisfacimento delle esigenze per l’evoluzione tecnolo- gica dell’Amministrazione. Eventuali prodotti, piattaforme, tecnologie e sistemi non citati possono

essere richiesti in ogni caso in tempi successivi previo congruo preavviso.

4.1.1. PRINCIPALI COMPETENZE

4.1.1.1. METODOLOGIA E TECNICHE

Analisi, Disegno e Programmazione ad Oggetti (OOA); Analisi, Disegno e Programmazione per Ser- vizi (SOA); Testing del SW prodotto (Test Unitari, Test di Integrazione e Test di Sistema) per garan- tire gli aspetti funzionali, qualitativi del codice, di efficienza (prestazione e carico), di accessibilità, di usabilità e di sicurezza;

4.1.1.2. TECNICO

Piattaforme e strumenti di testing del SW; DBMS relazionali (Oracle, Microsoft SQL, PostgreSQL, MySQL, etc.); Piattaforme Linux (Redhat, CentOS, Ubuntu, etc.); Piattaforme Microsoft (Windows NT, Windows 2000 Pro / Server / Advanced Server, Windows 2003/2005/2008/2010/2012 Server Standard / Enterprise, Windows XP/Vista/Seven/8, 10, etc.); Piattaforme Apple MacOSX; Sistemi di Identity and access management system (LDAP/SSO, CAS, Shibboleth, etc.); Protocolli di Comuni- cazione (HTTP, HTTPS, STP, SSTP); Navigatori Web (Internet Explorer, Mozilla Firefox, Google Crome, Opera, Edge, Safari, etc.); Sistemi di CMS e ECM (Alfresco, OpenCMS, Liferay, SharePoint, etc.); Sistemi Documentali (Alfresco, SharePoint, etc.); Motori di ricerca standard e semantici (Goo- gle search, Solr, Lucene, etc.); Prodotti per analisi e statistiche (Google analitycs, etc.); Prodotti di Office Automation (Microsoft Office: Word, Excel, PowerPoint, Visio, Project; Open/Libre Office, etc.); Suite Adobe Enterprise System (Adobe Acrobat, Adobe Lifecycle Designer, Adobe Lifecycle ES, Adobe Experience Manager); Tecnologie di virtualizzazione (VMware, virtual PC, Citrix, etc.); Tecnologie Mobile (smartphone, tablet, phablet) e relativi S.O. (Android, iOS, Windows Phone); Sistemi di Cloud Computing; Web Server (Apache, Microsoft Internet Information Server); Applica- tion Server (Jboss, WebLogic, Tomcat); Sistemi di configuration e versioning di programmazione (CVS, Subversion, etc.); Strumenti di modellazione dati (Xxxxx, Enterprise Architect, StarUML, etc.); Architetture applicative complesse; Soluzioni di Business Process Management (Bonita BPM, etc.); Paradigmi di Application Integration ed Enterprise Service Bus (WSO2, etc.); Soluzioni di alta affi- dabilità e business continuity (clustering, Disaster recovery);

4.1.1.3. LINGUAGGI ED AMBIENTI DI PROGRAMMAZIONE

Html, CSS: XML/WSDL/WSS/XSLT; XHtml; XForms/XFA/XDP; Ajax; Javascript; Java (Mvc, JSP, Servlets e EJB, J2EE); C#, C++; PHP, Python; Access, SQL, CGI, PERL, PLSQL; Visual Basic, VbScript, XX.Xxx, Xxx.XXX,.NET; PL/SQL; Microsoft Visual Studio; RichFaces, Prime Faces, An- gularJS, XXxxxx, Xxxxxx, Xxxxxx0, ecc.

4.1.1.4. COMPETENZE TRASVERSALI

Conoscenza della metrica dei Function Point IFPUG 4.3 o successivi. È indispensabile la presenza di almeno una risorsa certificata per le attività connesse ai servizi realizzativi; Tecniche e metodi di gestione e controllo dei progetti informatici. In caso di progetti rilevanti o critici o integrati, è indi- spensabile la presenza di almeno una risorsa di project management con Certificazioni Prince 2 e PMI, per le attività connesse ai servizi realizzativi; Conoscenza della disciplina IT Service Manage- ment in generale e dei framework ITIL o equivalenti.

4.1.1.5. CONOSCENZE NORMATIVE

Codice degli appalti D. Lgs. 50/2016 e s.m.i.; Accessibilità da parte dei soggetti disabili: la legge n. 4 del 9 gennaio 2004 “Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informa- tici”, prevede che le Pubbliche Amministrazioni non possono stipulare, a pena di nullità, contratti per la realizzazione e la modifica di siti Internet quando non è previsto che essi siano conformi ai requisiti di accessibilità stabiliti dal decreto del Ministro per l’Innovazione e le Tecnologie dell’8 luglio 2005,

recentemente aggiornati attraverso il nuovo decreto del 20 marzo 2013 firmato dal ministro per l’istruzione, l’università e la ricerca Xxxxxxxxx Xxxxxxx. Incentivi all'innovazione della PA: il Decreto legislativo n. 235/2010 introduce il nuovo Codice dell’Amministrazione Digitale (CAD) che avvia un processo di modernizzazione, digitalizzazione e sburocratizzazione delle PA. Difatti, attraverso la razionalizzazione della propria organizzazione e l'informatizzazione dei procedimenti, le PA ricave- ranno dei risparmi che potranno utilizzare per il finanziamento di progetti di innovazione e per l'in- centivazione del personale in essi coinvolto.

4.2. COMPATIBILITÀ

Il software realizzato dovrà essere compatibile con il release/livello effettivo degli ambienti di col- laudo/esercizio attivi al momento in cui il software sarà utilizzato. È pertanto obbligo del Fornitore predisporre e mantenere costantemente adeguati i propri ambienti di sviluppo e testing alle configu- razioni degli ambienti dell’azeinda, per minimizzare eventuali criticità derivanti da disallineamenti tra gli ambienti del Fornitore e quelli target.

Ciò comporta la verifica da parte del Fornitore, in fase di Definizione dell’Obiettivo, degli effettivi release e dell’eventuale piano di evoluzione degli ambienti.

4.3. PREDISPOSIZIONE AMBIENTE DI COLLAUDO

Al termine delle attività di realizzazione, e comunque ricomprese nelle attività dell’obiettivo realiz- zativo, il Fornitore dovrà supportare le strutture tecniche dell’azienda nella predisposizione dell’am- biente di collaudo (definizione e caricamento della base dati, installazione del software applicativo, personalizzazione del software di base, ecc.) e alla predisposizione degli script per il testing proce- duralizzato o automatico secondo quanto richiesto in Appalto Specifico. Tale attività dovrà essere espressamente prevista nel Piano di Lavoro dell’obiettivo.

La fase di realizzazione (od equivalente) si intende chiusa solo quando le attività di verifica hanno dato esito positivo dei suddetti test.

4.4. SUPPORTO AL COLLAUDO

L’obiettivo realizzativo comprende il supporto alle attività di collaudo. In particolare, il fornitore dovrà garantire la presenza on site nei tempi che saranno indicati in AS (in genere entro 1 giorno lavorativo) per garantire il passaggio di conoscenza sulle funzionalità rilasciate, il supporto all’ese- cuzione dei test proceduralizzati od automatici ed altre attività in funzione della specificità dell’obiet- tivo e richieste dall’azienda per ottimizzare il collaudo ed il successivo rilascio in esercizio.

4.5. SUPPORTO ALLA CONSEGNA IN GESTIONE

L’obiettivo realizzativo comprende il supporto alla consegna in gestione del software realizzato al fine di assicurare un appropriato passaggio di consegne ai Servizi di Gestione.

4.6. SUPPORTO PASSAGGIO IN ESERCIZIO

L’obiettivo realizzativo comprende il supporto ai gruppi di gestione dell’azienda finalizzato alla pre- disposizione dell’ambiente di esercizio ed avvio in produzione del software rilasciato. Si precisa che la messa in esercizio potrà avvenire anche in un momento differito rispetto all’avvenuto collaudo.

4.7. SUPPORTO SISTEMISTICO

L’obiettivo realizzativo comprende il supporto sistemistico al fine di assicurare, in particolare:

• l’assistenza ad analisti e programmatori per lo sviluppo e la manutenzione;

• l’ottimizzazione delle prestazioni dei programmi;

• il tuning degli accessi alle basi dati, application server ed infrastrutture interessate;

• la predisposizione degli ambienti di test, delle banche dati di prova, del mascheramento dei dati, ecc..

4.8. TEST FACTORY

Al Fornitore viene richiesto di progettare i test, monitorare il grado di copertura degli stessi, verificare la completezza e la rispondenza dei test ai requisiti, controllare l’esecuzione e memorizzare i risultati, fornire tutti i report per le necessarie verifiche e consentire il riutilizzo dei test in successivi contesti.

A tal fine il Fornitore dovrà disporre di una propria test factory e, nell’ambito di essa, di un prodotto di test management con cui gestire la fase di test relativa ai servizi oggetto della presente fornitura (test proceduralizzato). Il prodotto dovrà garantire la possibilità di integrarsi completamente con il prodotto di test management eventualmente adottato dall’azienda e convenuto in sede di attivazione dell’obiettivo.

Qualora in sede di attivazione di ciascun obiettivo si rilevi che ai fini dell’attendibilità ed efficacia del testing software siano rilevati/necessarie integrazioni applicative significative e/o particolari con- dizioni operative di verosimiglianza con gli ambienti e condizioni di esercizio, il Fornitore dovrà provvedere altresì predisporre i propri ambienti affinché riproducano fedelmente tutto quanto neces- sario per assicurare la completezza, rispondenza e correttezza della fornitura. Qualora si rendano ne- cessari misure straordinarie a prova del risultato atteso, l’azienda si riserva la facoltà di mettere a disposizione l’accesso da remoto ai propri ambienti di sviluppo / test ad ulteriore verifica dell’unifor- mità e fedeltà dei test condotti per le integrazioni di maggior rilievo.

4.9. TEST FUNZIONALI E NON FUNZIONALI

All’interno di ogni fase del ciclo di vita del sw, ed in particolare nell’ambito della fase di “Realizza- zione” (o fase che include la realizzazione), devono essere svolte dal Fornitore, preferibilmente tra- mite strumenti automatici, tutte le attività di verifica e validazione delle componenti realizzate (test di modulo, di funzione, di integrazione (o di sistema), di prestazione, di sicurezza, di compatibilità, di usabilità, di accessibilità, di stress o di carico del sistema, ecc.). Per ogni Obiettivo realizzativo la predisposizione e l’esecuzione di un piano di test esaustivo sotto tutti gli aspetti funzionali e non funzionali sarà richiesta come d’obbligo in funzione ragione dell’importanza dell’obiettivo e dei ri- schi intriseci da minimizzare.

4.10. GARANZIA

Ogni prodotto software realizzato/modificato deve essere pienamente rispondente ai requisiti funzio- nali espressi, alle normative vigenti, ai requisiti non funzionali (sicurezza, usabilità, prestazionalità, manutenibilità, ecc.) nonché agli standard, linee guida e miglior prassi disponibile per lo sviluppo software ed eventualmente specificati dall’azienda in fase di avvio di ciascun servizio e in fase di attivazione degli Obiettivi.

Ne discende che eventuali anomalie, difettosità residua non intercettata durante le fasi di test del fornitore e di collaudo dell’ente, riscontrabili sulle funzionalità realizzate e/o modificate durante l’in- tera fornitura devono essere rimosse, come parte integrante dei servizi che li hanno realizzati, a totale carico del Fornitore.

Pertanto, l’impresa dovrà garantire la tempestiva rimozione dei difetti del software nuovo e/o modi- ficato nonché la correzione e/o il ripristino delle basi dati deteriorate come ripercussione dei difetti nei tempi indicati in Appalto Specifico, vedasi Appendice 2 - Indicatori di Qualità.

Si precisa che gli interventi correttivi dovranno riguardare anche la documentazione a corredo.

Per tutto il software rilasciato il Fornitore deve produrre/aggiornare la relativa documentazione. La documentazione deve rispondere a requisiti di accuratezza, comprensibilità e più in generale usabilità.

Pertanto, deve essere garantita, come parte integrante dei servizi realizzativi, la correzione gratuita dei difetti riguardanti:

• gli oggetti software nuovi e/o modificati;

• le basi dati deteriorate come ripercussione dei difetti;

• la documentazione a corredo al software.

La garanzia opera per tutto il periodo di erogazione relativamente a tutto il software collaudato (o forma equivalente) e per i 12 mesi successivi per tutti i prodotti collaudati (o forma equivalente) nel corso dei dodici mesi precedenti.

4.11. SERVIZI BASE

4.11.1. PERSONALIZZAZIONE E PARAMETRIZZAZIONE

Il servizio consiste principalmente nella personalizzazione e parametrizzazione di software commer- ciale ed in attività volte al riuso, adeguamento, customizzazione ed integrazione di software già di- sponibile in base agli obiettivi, funzionali o meno, richiesti dall’Amministrazione.

Per "riuso di programmi informatici o parti di essi" si intende la possibilità per una Pubblica Ammi- nistrazione di riutilizzare gratuitamente programmi informatici o parti di essi quando:

• il software è di proprietà di una Pubblica Amministrazione ovvero sviluppato per conto e a spese di un’altra Amministrazione;

• appartengono alla categoria del software libero o a Codice sorgente aperto. Nel dettaglio, per il servizio in oggetto:

• per parametrizzazione si intende l’utilizzo di funzionalità native, accessibili tramite menù de- codificati, in cui è possibile impostare determinati parametri o configurare il funzionamento del programma senza necessità di sviluppo e conoscenza di codice o linguaggi informatici. In questo caso, diventano rilevanti le competenze relative allo specifico pacchetto software pre- sente presso l’Amministrazione e che sarà indicato all’interno del singolo AS;

• la personalizzazione è finalizzata a coprire ulteriori esigenze funzionali non originariamente offerte dalla soluzione con una limitata attività di sviluppo software, come per esempio la predisposizione di interfacce con altri sistemi, la realizzazione di funzionalità non presenti nel pacchetto/sw esistente, nuovi rapporti di stampa, o altro. Per personalizzazione si intende quindi attività di sviluppo, tramite l’utilizzo di linguaggi di III e IV generazione, metodi Ob- ject Oriented, sviluppi WEB Based, ecc. In questo caso valgono, dunque, i requisiti generali espressi per il servizio realizzativo di sw ad hoc e laddove necessario integrati dalla cono- scenza del pacchetto/sw open source od in riuso al cui contorno devono essere sviluppate le personalizzazioni.

In genere le parametrizzazioni non modificano la baseline del sistema diversamente dalle personaliz- zazioni che creano software stabile, che deve essere misurato e gestito. Pertanto, salvo diversa indi- cazione in AS, il fornitore dovrà fornire tutti gli elementi per la misurazione dell’effort e della base- line secondo la metrica dei Punti Funzione (PF).

In questo servizio verranno dunque comprese le attività sui software commerciali quali ad esempio ERP, CRM, SRM, PLM, SCM, e-procurement, Knowledge and Content Management, Business In- telligence, sistemi di gestione documentale (Filenet, Documentum, SharePoint, ecc.) e package

specifici dei vari comparti (sanità, ecc..), nonché sui sistemi open source quali Open CMS, Moodle, documentale Alfresco, ecc..

4.11.2. MANUTENZIONE ADEGUATIVA

Manutenzione Adeguativa: comprende l’attività volta ad assicurare la costante aderenza delle pro- cedure e dei programmi all’evoluzione dell’ambiente tecnologico del sistema informativoed al cam- biamento dei requisiti organizzativi, normativi, di legge e d’ambiente. La Manutenzione Adeguativa normalmente viene innescata dall’esigenza di:

• adeguamenti richiesti dal cambio di Xxxxx e/o normative che regolamentano la fruizione e il funzionamento dei sistemi informativi;

• adeguamenti dovuti a cambiamenti di condizioni di utilizzo (ad esempio per variazioni del numero utenti, per migliorie di performance, per aumento delle dimensioni delle basi dati, ecc.);

• adeguamenti necessari a seguito di innalzamento di versioni del software di base/middleware;

• migrazioni di piattaforme/middleware di base verso altri prodotti.

4.11.3. SVILUPPO E MEV

Sviluppi di interi nuovi sistemi informativi o applicazioni; in cui si ritengono inclusi:

• gli sviluppi di interi nuovi sistemi applicativi, o parti autonome degli stessi (nel caso si pre- veda la realizzazione a lotti o a obiettivi), che risolvono esigenze specifiche a fronte di fun- zionalità ancora non assolte informaticamente;

• rifacimento di sistemi applicativi, le cui funzionalità non sono soddisfatte con le modalità o le caratteristiche richieste, previa valutazione che non sia conveniente attuare una Manuten- zione Evolutiva al software esistente (vedasi punto immediatamente successivo);

Manutenzione evolutiva di software, che include gli interventi volti ad arricchire le applicazioni esistenti di nuove funzionalità, o comunque a modificare le funzionalità già esistenti. Comprende gli interventi volti ad arricchire il prodotto di nuove funzionalità o di altre caratteristiche non funzionali, quali l’usabilità, le prestazioni, ecc. o comunque a modificare o integrare le funzionalità del prodotto. Tale manutenzione implica la scrittura di funzioni aggiuntive d’integrazione a sistemi applicativi esi- stenti o parti di funzioni (anche in sostituzione di altre già esistenti) di dimensione significativa e di cui è possibile preventivamente definire i requisiti o quantomeno identificare le esigenze. In pratica si tratta di implementazioni di uno specifico sistema informatico, sovente aggregabili fra loro, che comunque danno luogo a una nuova release / baseline del prodotto iniziale.

Manutenzione perfettiva: comprende le attività volte ad assicurare interventi per migliorare la qua- lità del servizio, che non incrementano il valore patrimoniale del bene. Rientrano:

• interventi per migliorare le performance dell’applicativo attraverso il tuning, la revisione dello storage space, la facilitazione dell’interazione uomo-macchina, la revisione/ottimizzazione degli schemi delle basi dati, l’ottimizzazione del codice;

• interventi sul software assimilabili a piccole migliorie. Tali interventi devono corrispondere a modifiche di lieve entità che non trasformano le specifiche funzionali e la struttura logica dell’applicativo o del data base e quindi non variano il valore economico dell’applicativo. Gli interventi devono perciò avere un impatto limitato in termini di tempo e risorse ed in partico- lare non devono comportare oneri per rilasci dedicati;

• modifiche generali di impostazione dell’interfaccia utente che non implicano la modifica di

funzionalità, come ad esempio modifica dei titoli delle maschere o delle label dei campi o della loro allocazione nella videata;

• interventi volti a securizzare l'applicativo.

4.12. SERVIZICOMPLEMENTARI

I Servizi Complementari rappresentano i servizi che generalmente si associano ai Servizi Realizzativi e di Mantenimento in operatività del software.

Ai fini del presente Appalto Specifico in questo gruppo sono inclusi i seguenti servizi:

• Gestione applicativi

• Manutenzione Correttiva

• Supporto Specialistico (specialisti di prodotto / tecnologia / piattaforma, analisti Business Process Reengineering, analisti di tematica, Sicurezza Informatica).

4.12.1. GESTIONE APPLICATIVA

Il servizio di Gestione applicativi per il presente Appalto Specifico comprende l’insieme di attività, risorse e strumenti di supporto per la gestione in operatività delle applicazioni e delle loro relative basi dati.

Si includono in questo gruppo le seguenti attività: Gestione delle funzionalità in esercizio; Acco- glienza e tracciatura delle richieste di intervento; Gestione operativa applicazioni; Presa in carico di nuove funzionalità in esercizio; Supporto agli utenti, per l’uso appropriato delle funzioni secondo le modalità previste nei manuali d’uso / Customer service Desk; Pianificazione funzionale del servizio; Prodotti/servizio ad hoc per esigenze estemporanee di servizio; Affiancamento per il trasferimento di know-how.

A seconda dei sotto ambiti il servizio può includere il contatto diretto con gli utenti delle applicazioni che potranno rivolgersi direttamente al servizio via telefono e/o via e-mail o applicazione web pre- posta oppure indirettamente tramite un Help Desk di I livello ove previsto.

Laddove previsto il colloquio con l’utenza, oltre alla tempestività ed efficacia dell’assistenza fornita, acquista particolare rilevanza la professionalità nella gestione della relazione con l’utenza.

Le risorse del Fornitore preposte al servizio dovranno acquisire e mantenere un’ottima preparazione sia funzionale sia tecnica sui sistemi, sulle applicazioni ed in genere sul patrimonio applicativo dell’azienda. Tali risorse dovranno lavorare in sinergia con il gruppo dei servizi realizzativi e con i restanti gruppi sugli altri servizi al fine di rispondere prontamente ed efficacemente alle diverse atti- vità contenute nel servizio stesso.

I livelli di servizio minimi sono presenti nell’Appendice 2 - Indicatori di qualità.

I principali gruppi di attività su cui il Fornitore è chiamato a adempiere nel presente AS sono:

• Gestione delle funzionalità in esercizio:

o servizio di help desk (ove non attivato separatamente) su postazioni attrezzate dall’azienda;

o risoluzione delle richieste di intervento effettuate dall’utente tramite accoglienza e tracciatura delle richieste di intervento tramite un prodotto di trouble ticket manage- ment, le richieste di intervento di tutti i servizi erogati. Il ticket permette al Cliente di verificare e monitorare lo stato di avanzamento della propria richiesta fino alla sua chiusura, e all’azeinda di gestire e monitorare ogni singola richiesta per tutto il suo

ciclo di vita. Le prerogative del servizio di accoglienza, sono dunque: fornire un unico punto di contatto agli utenti per la segnalazione di problematiche e/o di richieste di informazioni relative all’ambiente ICT oggetto del servizio (solo per l’area applica- tiva), fornire uno strumento che garantisca la tracciabilità e la misurabilità del servizio (quello utilizzato anche dall’azienda), assegnare la risoluzione delle problematiche emerse alle strutture competenti dell’azienda per la gestione dell'intervento, gestire il controllo e la chiusura dei ticket per le attività svolte, con relativa notifica all’utente che ha effettuato la segnalazione;

o intercettazione e registrazione dei problemi alla fonte, classificazione, eventuale ripro- duzione dell’errore e, se necessario, conseguente attivazione del servizio di garanzia software e/o di Manutenzione Correttiva, laddove previsto, e verifica dell’esito dell’intervento effettuato. A tale proposito il Fornitore registrerà le informazioni utili alla verifica degli indicatori di qualità del servizio e alla produzione di opportuna re- portistica;

o validazione tecnica e controllo dei risultati delle elaborazioni, al fine di assicurare l’in- tegrità e la correttezza dei dati presenti sulla base informativa, del contenuto dei flussi informativi provenienti o destinati ad organismi esterni e dei dati esposti negli elabo- rati del sistema;

o ripristino base dati;

o modifiche di parametri di esecuzione o di tabelle di riferimento o decodifica;

o verifica ed aggiornamento di eventuale documentazione specifica della gestione ap- plicativa contenente FAQ, modi d’uso, modalità di esecuzione di particolari attività del servizio di gestione (ad esempio manutenzione preventiva, ecc.) in collaborazione con i gruppi di sviluppo che sono responsabili della manualistica utente e di gestione;

o gestione della configurazione.

• Gestione operativa applicazioni

o Assistenza applicativa di secondo livello: attività di gestione delle richieste e delle segnalazioni di malfunzionamento pervenute dagli utenti e non risolte dall’assistenza di primo livello.

o Gestione malfunzionamenti (incident): adozione di soluzioni di by pass applicativi, con eventuale intervento per la correzione e messa a punto dei dati, su segnalazione dell’utente. Include le attività di supporto tecnico-sistemistico al processo di trouble- shooting applicativo connesso ad incidenti o problemi rilevati nella conduzione dei servizi applicativi.

o Backoffice applicativo: gestione delle attività funzionali all’esercizio delle applica- zioni (monitoraggio dell’accessibilità e della fruibilità del prodotto software e dell’in- frastruttura, monitoraggio e verifica delle procedure batch, schedulazione di job di integrazione e relativo controllo dell’andamento, controllo log dei servizi di integra- zione); attività proattive di prevenzione di eventuali malfunzionamenti, anche attra- verso verifica delle prestazioni e tuning applicativo; prevenzione e correzione delle incongruenze sui dati dovute al sistema, sia a livello di singolo dato sia per bonifiche estese.

o Correzione dati (request): individuazione e correzione delle incongruenze sui dati do- vute all’operatività dell’utente finale e non recuperabili dallo stesso, sia a livello di singolo dato sia di bonifiche estese.

o Manutenzione basi dati e gestione metadati: alimentazione, aggiornamenti ed allinea- menti ricorrenti delle basi dati (alfanumerica, geografica, decisionale); include attività quali ad esempio: la verifica preventiva degli impatti a seguito di modifica / cancella- zione dati; la verifica degli accessi agli archivi; le modifiche ai parametri di configu- razione; la storicizzazione dei dati; la creazione di nuovi indici; l’aumento dello spazio disco.

o Collaudo e messa in esercizio: gestione dei rilasci verso gli ambienti di collaudo ed esercizio (produzione della baseline di rilascio corredata dalla documentazione di in- stallazione, deployment e gestione nell’ambiente specifico) e aggiornamento del re- pository delle anagrafiche aziendali per i prodotti gestiti.

o Gestione della configurazione: individuazione e predisposizione di tutti gli item di configurazione (identificazione), creazione e modifica delle baseline di configura- zione (controllo), verifica ed aggiornamento dello stato delle baseline(audit).

• Presa in carico di nuove funzionalità in esercizio:

o schedulazione e pianificazione della presa in carico di nuove funzionalità attraverso apposite sessioni di formazione erogate dal gruppo che ha sviluppato il software;

o schedulazione e pianificazione del rilascio in esercizio di nuove funzionalità;

o verifiche tecniche specifiche su procedure, parametri e tabelle, manuale utente, ma- nuale di gestione, definizioni relative ai dati, ecc..;

o supporto alla predisposizione dell’ambiente di esercizio, e quanto necessario a con- sentire l’inizio delle attività da parte degli utenti;

o gestione della nuova configurazione.

• Assistenza tecnico/funzionale agli utenti:

o affiancamento all’utente finale volto ad istruirlo all’uso delle funzionalità sia nuove che già presenti in esercizio;

o Customer service desk / Assistenza utilizzo applicativi. Fornisce supporto all’utente nell’utilizzo operativo e funzionale degli applicativi, risposte a quesiti legati alla na- vigazione nell'applicativo, all'attivazione delle funzionalità, all'indicazione di percorsi e di modalità di utilizzo. Rientrano in questo servizio anche i semplici consigli o le verifiche normalmente contemplate nel manuale utente dell'applicativo, (es. riavviare il pc, scollegare e ricollegare la stampante, provare a stampare un documento al di fuori della procedura) e che risolvono un eventuale malfunzionamento, ecc. (cd. how to use).

o Assistenza sulla logica applicativa. Fornisce all’utente tutte le informazioni di logica applicativa legate all’uso delle procedure e l’assistenza finalizzata a spiegare all’utente la logica e gli algoritmi utilizzati nelle varie funzionalità (cd. logica applicativa). Sod- disfa le richieste finalizzate a verificare le credenziali e le profilazioni utente per l’ac- cesso ai sistemi informatici.

• Supporto agli utenti, per l’uso appropriato delle funzioni secondo le modalità previste nei manuali d’uso:

o preparazione di documentazione aggiuntiva rispetto a quella a corredo dei sistemi in esercizio, (es. documenti di sintesi, demo, presentazioni, ecc.);

o verifica della configurazione. Il servizio ha l'obiettivo di supportare operativamente

l’utente per tutte le attività di verifica effettuate per risolvere un malfunzionamento apparente che ne limita l’operatività , supportare l’utente per gli aspetti legati alla ve- rifica della configurazione della postazione di lavoro finalizzata al corretto utilizzo dell’applicativo, come ad esempio: gestione permessi di scrittura alle cartelle locali, aggiornamenti versioni del software di base e Runtime a supporto, installazione di plugin, viewer necessari all’applicativo, lettori smart card e software di firma digitale, corretta configurazione di parametri della pdl, installazione di un applicativo, verifiche finalizzate a riprodurre segnalazioni di anomalia che possono anche non ripresentarsi;

o supportare l’utente nella procedura di installazione/importazione e rimozione del cer- tificato digitale dal browser.

o predisposizione dell’ambiente dimostrativo (es. base dati, utenze specifiche, ecc);

• Pianificazione funzionale del servizio:

o movimentazione giornaliera dei batch, ove richiesto / applicabile;

o disponibilità del servizio on line (funzionalità TP);

o controllo e fasatura dell’introduzione di nuove versioni di software di base (anche in via estemporanea e/o transitoria) nell’ambiente gestionale;

o pianificazione ed esecuzione di elaborazioni di prova, con relativa ripresa di dati reali, a scopo di manutenzione preventiva, per anticipare l’esito dell’elaborazione di proce- dure critiche per l’azienda.

• Prodotti/servizio:

o realizzazione di prodotti informatici o erogazione di servizi “ad hoc”, per soddisfare particolari e puntuali esigenze dell’utente, non risolvibili con le funzionalità disponi- bili nel sistema informativo e che di norma non entrano a far parte stabile del parco applicativo.

• Affiancamento per il trasferimento di know how necessario al corretto svolgimento del servi- zio:

o l’attività consiste in una fase di “training on the job” a terzi individuati dall’azienda, finalizzata a trasmettere il know-how funzionale applicativo e tecnico-sistemistico ne- cessario alla gestione del software in esercizio. All’attivazione verranno concordate le risorse professionali impegnate nell’attività che potranno appartenere anche a diversi servizi, ecc. In corso d’opera potranno essere attivati anche più obiettivi per trasferi- menti parziali relativamente a specifiche attività/applicazioni, ecc.

4.12.2. MANUTENZIONE CORRETTIVA

Per manutenzione correttiva si intende la diagnosi e la rimozione delle cause e degli effetti, sia sulle interfacce utente che sulle basi dati, dei malfunzionamenti delle procedure e dei programmi in eser- cizio ed in genere di tutti i componenti del sistema non in garanzia.

A discrezione dell’azienda, in corso d’opera verrà affidata in Appalto Specifico l’erogazione del ser- vizio di Manutenzione Correttiva di applicazioni/sistemi propri collegati a prodotti software svilup- pati attraverso i servizi realizzativi di base nonché dei prodotti software facente capo all’asset dell’ambito dei servizi del presente capitolato.

Il servizio di manutenzione correttiva viene innescato da una segnalazione di impedimento all’uso dell’applicazione di una o più delle sue funzioni. Per impedimento si intende una malfunzione vera e propria dell’applicazione o gli effetti che tale malfunzione ha causato alla base dati (es. anomalie in

un programma batch che corrompono la base dati).

I malfunzionamenti, le cui cause non sono imputabili a difetti presenti nel software applicativo, ma ad errori tecnici, operativi o d’integrazione con altri sistemi (ad esempio interruzione del collega- mento di rete, uso improprio delle funzioni, ecc.), oppure relativi a software in garanzia (del fornitore uscente), comportano, da parte del servizio di manutenzione correttiva, il solo supporto all’attività diagnostica sulla causa del malfunzionamento, a fronte della segnalazione pervenuta, ma sono poi risolti da altre strutture di competenza.

Analogamente, per il software realizzato/modificato nel corso del medesimo Appalto Specifico, i malfunzionamenti dovranno essere risolti nell’ambito dei servizi realizzativi in quanto coperto dalla garanzia.

Sono parte integrante del servizio di Manutenzione Correttiva le seguenti attività non vincolanti:

• contributi di competenza sistemistica e specialistica di prodotto necessari alla corretta solu- zione del malfunzionamento;

• attivazione del gruppo di sviluppo per adeguare l’eventuale software in corso di sviluppo/mo- difica/collaudo;

• test in ambiente assimilabile all’ambiente di esercizio della soluzione realizzata;

• gestione della configurazione;

• in caso di malfunzioni su programmi di interfaccia verso l’esterno, validazione tecnica e con- trollo dei risultati del contenuto dei flussi informativi destinati a strutture esterne o dei dati esposti negli elaborati del sistema;

• allineamento della documentazione.

Nel caso in cui i sistemi dell’azienda comprendano pacchetti e/o sw personalizzato o integrato, il servizio di manutenzione correttiva in caso di malfunzionamenti sulla componente di pacchetto di mercato è finalizzato a diagnosticare la natura del malfunzionamento distinguendo se questo è all’interno del codice sorgente del pacchetto di mercato o all’interno del software parametrizzato/per- sonalizzato il servizio è tenuto alla tempestiva apertura della segnalazione sul contratto di manuten- zione dello specifico pacchetto ed alla successiva verifica dell’esito dell’intervento effettuato; le ri- sorse deputate al servizio dovranno dimostrare un’approfondita conoscenza del pacchetto utilizzato dall’azienda, tale da azzerare i rischi di apertura di segnalazioni di malfunzionamento errate ovvero segnalazioni che si risolvono con parametrizzazione del pacchetto.

Laddove applicabile, il servizio include la validazione tecnica ed il controllo dei risultati del conte- nuto dei flussi informativi da/per il pacchetto.

Le attività sopra descritte rientrano nel concetto di Mantenimento Applicativo ed hanno lo scopo di assicurare il corretto funzionamento e le migliori prestazioni degli applicativi in esercizio.

Il Mantenimento Applicativo è una categoria più ampia che comprende la Manutenzione Correttiva vera e propria (ovvero gli interventi sul software per eliminare eventuali difettosità residue) ma in- clude anche attività umane volte al presidio, al controllo e alla verifica proattiva del buon funziona- mento di un sistema.

Si definiscono Applicativi in esercizio gli applicativi rilasciati in ambiente di produzione di cui gli utenti fanno un uso produttivo. Le attività in capo al mantenimento applicativo sono dono dunque la gestione dei malfunzionamenti e possono essere svolte in seguito a segnalazione utente oppure in modo proattivo per evitare disservizi o impedimenti nella regolare attività dell’utente fruitore del servizio applicativo.

4.12.3. SUPPORTO SPECIALISTICO

Il Servizio di Supporto Specialistico comprende un insieme integrato di attività propedeutiche ovvero integrative ovvero di ausilio ai servizi sia realizzativi sia complementari al fine di rendere sinergici ed esaustivi tutti i componenti della fornitura.

In corso d’opera l’azienda potrà individuare attività puntuali collegate al servizio base oppure racco- gliere le esigenze di supporto sull’arco temporale della fornitura dell’Appalto Specifico e pertanto le attività di Supporto Specialistico saranno attivate di volta in volta attraverso singoli obiettivi.

Il servizio di Supporto Specialistico comprende risorse specialistiche finalizzate principalmente alle seguenti attività:

• Know How specialistico e sistemistico:

o problem solving di alto livello su tematiche funzionali/amministrative;

o consulenza specialistica di tematica finalizzata al rispetto degli iter amministrativi;

o consulenza specialistica sul sulla normativa applicabile nel contesto dei servizi;

o assistenza operativa diretta presso l’utente per la soluzione di problematiche di alto livello;

o supporto al servizio di Gestione Applicativi per le problematiche di alto livello;

o supporto sistemistico e supporto specialistico per l’utilizzo di prodotti software;

o supporto di alto livello per attività di change management;

o supporto specialistico per la predisposizione di relazioni tecniche per studi di fattibi- lità, redazione di documenti di architettura, individuazione dei requisiti di sistema, valutazioni, ecc..

• Attività di analisi:

o supporto tematico per la redazione di studi, analisi di fattibilità, stima dei tempi e costi, stima dei benefici, comparazione tra diverse possibili soluzioni, valutazione di solu- zioni che prevedano l’utilizzo e l’eventuale personalizzazione di prodotti software pre- senti sul mercato;

o analisi dei processi;

o analisi della sicurezza informatica;

o esecuzione di sperimentazioni ed analisi casi di studio;

o sviluppo di prototipi, di tipo “usa e getta”, per esigenze non direttamente collegabili ai servizi realizzativi.

• Redazione documentazione

o creazione o aggiornamento di documentazione non collegata a specifici interventi di sviluppo od in generale ai servizi realizzativi;

o redazione di presentazioni;

o divulgazione delle informazioni, attraverso la predisposizione di pubblicazioni, bro- xxxxx, bozzetti grafici, template;

o consulenza specialistica di tematica su materie amministrativo-contabili;

o supporto per le fasi di produzione dei report, di interpretazione e analisi dei risultati,

di presentazione e discussione degli stessi;

o predisposizione e distribuzione del materiale (anche di tipo multimediale) che si ren- derà necessario per la formazione e/o la diffusione dei sistemi e delle metodologie sottese.

o Attività di data entry: finalizzata all’alimentazione iniziale o al recupero di dati/docu- menti o attività di supporto alle migrazioni;

o Attività di presidio: supporto sistemistico alla gestione delle applicazioni realiz- zate/modificate dai servizi base.

L’elenco non si può considerare esaustivo/vincolante ed immutabile, pertanto in corso d’opera nel periodo di competenza dell’Appalto Specifico verranno identificare al meglio le necessità in ogni caso comunque orientate a supportare lo sviluppo, la manutenzione e la gestione dei prodotti, solu- zioni e piattaforme propri dei sistemi informativi dell’ambito Flussi Documentali.

4.13. SERVIZI ACCESSORI

4.13.1. FORMAZIONE

L’introduzione di nuove applicazioni e nuove modalità di interazione con la PA richiede l’attivazione di progetti di istruzione, formazione ed addestramento sia per gli amministrativi sia per gli utenti. Tale attività, in funzione della distribuzione territoriale o dell’organizzazione del lavoro, può avvenire in diverse forme: da sessioni di formazione in aula od a distanza, all’erogazione di corsi Web attra- verso la predisposizione di WBT, ecc..

4.14. ATTIVITÀ PROPEDEUTICHE ALL’EROGAZIONE DEI SERVIZI

Ai fini del presente Appalto Specifico si rendono necessarie le attività preparatorie alla presa in carico dei servizi quali: formazione del personale, acquisizione know how sul contesto tecnologico ed ap- plicativo, predisposizione ambienti tecnologici e/o strumenti operativi e di supporto.

Tutte le spese e gli oneri dell’Appaltatore relativi alle attività propedeutiche alla erogazione del ser- vizio oggetto di Appalto Specifico sono da intendersi ricomprese e compensate nel corrispettivo del servizio del relativo Contratto d'appalto.

4.15. ACQUISIZIONE KNOW HOW

Il Fornitore aggiudicatario dovrà garantire l’esecuzione della fornitura a regola d’arte attraverso il pieno rispetto dei requisiti minimi e dei livelli di servizio a partire dalla data di inizio attività. Per garantire l’efficacia dei servizi fin dall’avvio della fornitura, il Fornitore deve impiegare personale pienamente formato sulle tematiche funzionali e tecniche oggetto della fornitura nonché dei metodi, degli strumenti e degli standard che nel corso della fornitura saranno utilizzati. A tal fine si rende necessario un periodo di presa in carico.

Per i prodotti, piattaforma e servizi che per natura o rilevanza sono “critici” si richiede un periodo di addestramento stimabile in due mesi.

Tale addestramento consisterà in riunioni di lavoro, esame della documentazione esistente con assi- stenza di personale esperto, affiancamento nell’operatività quotidiana condotta dal fornitore uscente e/o dall’azienda.

Durante le attività di training on the job la responsabilità delle operazioni continuerà ad essere in capo al Fornitore uscente e/o dall’azienda.

4.16. PIANIFICAZIONE INIZIALE

In avvio dell’Appalto Specifico, ed entro le tempistiche indicate al successivo paragrafo 9.6.1, ver- ranno richiesti:

• “il Piano di lavoro iniziale”;

• “il Piano di Subentro”;

• “il Piano della Qualità”

4.17. PRESENTAZIONE CV

Per i servizi erogati a giorni persona, alla stipula del contratto il Fornitore dovrà consegnare i CV delle risorse che intende utilizzare per la fornitura dei servizi stessi.

A propria discrezione, l’azienda si riserva di valutare che i CV consegnati siano congrui rispetto alle attività ed obiettivi affidati per l’intera durata dell’Appalto Specifico. Qualora si dovessero indivi- duare situazioni eccepibili, il Fornitore dovrà proporre le opportune sostituzioni al fine di assicurare l’erogazione dei servizi a regola d’arte.

4.18. CONTEGGIO BASELINE INIZIALE

Ai fini della presa in carico di applicazioni stimate in Punti Funzione (sia servizi realizzativi sia Ma- nutenzione Correttiva) ad inizio della fornitura il Fornitore potrà effettuare il conteggio della baseline iniziale in Punti Funzione. Considerato il volume dell’asset applicativo affidato, il conteggio potrà essere effettuato a campione limitatamente su di un significativo sottoinsieme di prodotti.

Eventuali difformità rispetto al conteggio effettuato dall’Ente in Appalto Specifico, dovranno essere approvati dall’Ente medesimo all’attivazione del servizio.

4.19. REQUISITI ORGANIZZATIVI

Il Fornitore dovrà designare il Responsabile Unico delle attività contrattuali.

Il Responsabile unico delle attività contrattuali, senza oneri aggiuntivi per l’azienda, dovrà:

• farsi carico della gestione del personale componente i vari gruppi di lavoro (pianificare le ferie, le sostituzioni per malattia, indisponibilità in genere) al fine di garantire la regolare disponibilità delle risorse nell’orario di servizio. L’organizzazione del Fornitore dovrà essere tale da garantire l’autonomia delle proprie risorse pur nel rispetto delle esigenze dell’azienda e pertanto, in caso di attivazione di servizi continuativi o che richiedano un presidio, sarà responsabilità del Fornitore proporre ed aggiornare i piani di presenza e di eventuale turna- zione in funzione dello specifico piano di lavoro (copertura in caso di picchi di lavoro, ferie, reperibilità, extraorario, ecc..);

• riferire all’azienda, mediante SAL periodici svolti presso la sede del Committente, su tutte le attività legate alla corretta esecuzione dei servizi quali, ad esempio, la stima, la pianificazione e la consuntivazione degli Obiettivi, gli adempimenti legati alla qualità, il controllo dell’avan- zamento lavori, la verbalizzazione degli incontri con l’utenza, le attività di valutazione e con- tenimento dei rischi, l’efficacia e l’efficienza dell’attività di test, ecc.;

• assicurare un alto grado di sinergia tra le risorse impiegate nello sviluppo e quelle impiegate negli altri servizi quali la gestione per la fase di avviamento in esercizio delle applica- zioni/obiettivi, al fine di garantire un costante e adeguato grado di conoscenza e di attenzione evitando discontinuità.

In sede di avvio ma anche successivamente a mano a mano in ragione dell’attivazione di ulteriori obiettivi, l’ambito dei servizi appaltati sarà scomposto in raggruppamenti/sotto ambiti ove per cia- scuno di essi l’azienda individuerà un proprio referente tecnico delle attività e servizi con cui il

Referente Unico ed eventuali preposti dell’Appaltatore dovranno riferirsi come punto di riferimento per lo svolgimento delle attività e servizi.

4.20. REQUISITI DI QUALITÀ DELLA FORNITURA

Nell’esecuzione delle attività contrattualmente previste il Fornitore dovrà:

• rispettare i principi di assicurazione e di gestione della qualità della norma EN ISO 9001 rispetto alla quale gli è stata richiesta la certificazione;

• attenersi ed essere conforme a quanto previsto dal proprio Sistema di Gestione della Qualità e dal Piano della Qualità del presente Appalto Specifico;

• implementare e perseguire le soluzioni migliorative proposte dal Fornitore in sede di offerta;

• rispettare i livelli di servizio e gli indicatori di qualità riportati nell’Appendice 2 - Indicatori di qualità, così come integrata ed aggiornata nello specifico documento di Appalto Specifico;

• attenersi scrupolosamente alle indicazioni tecniche ed operative convenute in sede di attiva- zione degli obiettivi/servizi.

La qualità attesa è riportata nell’Appendice 2 - Indicatori di qualità.

4.21. PIANO DI QUALITA’

Il Fornitore dovrà produrre, tra i documenti di stipula dell’Appalto Specifico ed entro le tempi- stiche indicate al successivo paragrafo 9.6.1, il Piano di Qualità proposto e funzionale all’eroga- zione dei servizi della fornitura.

Il Piano di Qualità è il documento di riscontro per la valutazione della qualità del servizio erogato, rispetto al quale si valuta il livello qualitativo dei servizi erogati per l’intera durata contrattuale, anche in riferimento alle effettive esigenze dell’utenza.

Il Piano di Qualità generale dovrà essere predisposto dal Fornitore e dovrà:

• fornire lo strumento per collegare i requisiti specifici dei servizi contrattualmente richiesti con le procedure generali del sistema qualità del Fornitore già esistenti;

• esplicitare le disposizioni organizzative e metodologiche adottate dal fornitore, allo scopo di raggiungere gli obiettivi tecnici e di qualità contrattualmente definiti;

• dettagliare i metodi di lavoro messi in atto dal fornitore, facendo riferimento o a procedure relative al proprio sistema, e per ciò descritte nel manuale qualità, o a procedure sviluppate per lo specifico contrattuale, a supporto delle attività in esso descritte (in questo caso da alle- gare al piano): in particolare, per i servizi realizzativi, dovranno essere esplicitati, con riferi- mento al contesto della fornitura, le modalità di formazione del gruppo di lavoro, i cicli di vita adottabili, gli effort per fase media stimata, le modalità di avanzamento e di controllo e di rendicontazione interna ed esterna, le modalità e gli strumenti per il test funzionale e non, ecc.; garantire il corretto e razionale evolversi delle attività contrattualmente previste, nonché la trasparenza e la tracciabilità di tutte le azioni messe in atto dalle parti in causa, il Fornitore e Azienda;

• rispettare quanto previsto dalla norma EN ISO 10005;

Il piano di qualità dell’Appalto Specifico dovrà essere approvato prima dell’avvio delle attività con- trattuali in sede di presa in carico di cui all’art. 4.4 e ne potrà essere richiesti aggiornamento periodico dall’azienda.

4.22. ORARIO DI EROGAZIONE DEI SERVIZI

In termini di orario le esigenze di servizio sono di massima indirizzabili da una copertura estesa, erogabile attraverso una turnazione delle risorse, senza soluzione di continuità dall’apertura del ser- vizio al termine.

La tabella seguente riporta in forma schematica le caratteristiche del livello di presidio in continuità secondo quanto storicamente osservato finora.

APPLICA- TIVO

TIPOLOGIA SERVIZIO

ORARIO

PE- RIODO

ESTEN- SIONE

REPERIBI- LITA’

Tutti gli applica- tivi

• Servizi Com- plementari

• Gestione Ap- plicativi

8:30-18:00

lun-ven

su richiesta a fronte di esi- genze speci- fiche

• Servizi Base - Sviluppo

8:30-18:00

lun-ven

su richiesta a fronte di esi- genze speci- fiche

Non prevista

In corso d’opera è tuttavia possibile che per particolari obiettivi di natura critica o esigenze estempo- ranee di servizio sia necessario fare ricorso ad un profilo orario particolare, nel caso ciò si verificasse si riporta a titolo indicativo come di seguito in tabella l’orario presunto:

APPLICA- TIVO

TIPOLOGIA SERVIZIO

ORA- RIO

PE- RIODO

ESTEN- SIONE

REPERIBI- LITA’

Applicativi di natura “critica”

• Servizi Comple- mentari

• Gestione Applica- tiva

8:00-

18:00

lun-ven sabato

su richiesta a fronte di esi- genze specifi- che

Per festività devono intendersi solamente le festività a carattere nazionale. Si precisa che:

• in caso sia presente un gruppo di lavoro l’orario sarà garantito secondo una distribuzione delle presenze da concordare con l’azienda nel piano di lavoro, all’interno dell’orario di servizio. Non sono previste maggiorazioni;

• relativamente all’extraorario pianificato (oltre le ore 20,00 – dal lunedì al venerdì e oltre le 14.00 del sabato) nonché domenica e festivi, gli interventi in reperibilità (on-site o da re- moto) verranno retribuiti alla tariffa oraria base maggiorata del 20%.

4.23. LUOGO DI EROGAZIONE DEI SERVIZI

Il luogo di lavoro prevalente per il personale impiegato dal Fornitore sia sui Servizi Base, nonché Complementari per la sola Manutenzione Correttiva, è la sede stessa del Fornitore salvo eccezioni puntuali da definire a richiesta.

Per i Servizi Complementari la sede di lavoro sarà puntualmente definita in sede di avvio dell’appalto

/ servizio e potrà essere la sede stessa del Fornitore oppure una delle sedi di lavoro dell’azienda non- ché eventuali presidi distaccati.

Sono fatte salve alcune eccezioni nelle quali il Fornitore dovrà garantire comunque la presenza del proprio personale presso l’azienda:

• formazione di nuove risorse, passaggi consegne in affiancamento a colleghi esperti

• formazione in aula per aggiornamenti su nuove funzionalità di applicativi in gestione

• riunioni di lavoro, stati avanzamento lavori

• kick off di fasi di sviluppo (avvio Obiettivi)

• collaudo a fronte di una consegna di software sviluppato (fine Obiettivo, consegna del soft- ware)

• temporanea impossibilità da parte del Fornitore di erogare il servizio dalla propria sede

Si segnala, comunque, che potrebbe esserci la necessità di interventi in sedi diverse da quelle inizial- mente indicate, che saranno tempestivamente comunicate dall’azienda.

L’azienda si impegna a comunicare al Fornitore con sufficiente preavviso (15 giorni solari) le date per gli incontri di lavoro presso la sede dell’azienda stessa o altre sedi preposte.

Non sono previsti rimborsi per trasferte.

Sia che il luogo di lavoro si trovi presso la sede del Fornitore, che presso la sede dell’azienda (o suo Ente consorziato), è responsabilità del Fornitore dotare i propri dipendenti di stazioni di lavoro (pc) tecnologicamente adeguate al tipo di lavoro svolto, dotate del software di base, di programmi antivi- rus e degli strumenti software necessari all’esecuzione dei servizi contrattuali, come ad esempio pro- dotti per lo sviluppo di software applicativo, nel pieno rispetto delle indicazioni sulla sicurezza e delle policy interne che l’azienda comunicherà al Fornitore.

Ove necessario e non diversamente indirizzabile, l’azienda metterà a disposizione del Fornitore am- bienti operativi, server di test e di preproduzione sui quali il Fornitore avrà accesso da remoto tramite una VPN strettamente personale, concessa e configurata dall’azienda con la supervisione di tecnici in sede e designate per le sole finalità strettamente correlate ai servizi svolti.

In tal caso al Fornitore viene fatto obbligo di utilizzare detti server di sviluppo/test, al fine di garantire il rispetto degli standard e delle versioni dello stack applicativo, in coerenza con gli ambienti di eser- cizio dell’azienda.

4.24. METRICHE E DIMENSIONAMENTO DELLA FORNITURA

In considerazione della diversità delle esigenze dell’azienda, non è possibile prevedere a priori una suddivisione per servizi, dimensioni, piattaforme tecnologiche ed applicative.

A livello di Appalto Specifico vengono, pertanto, identificate le metriche generalmente applicabili, i fattori che ne determinano la misura facendo riferimento al livello di servizio più alto. In tal modo, al declinarsi delle condizioni in AS sarà possibile richiedere l’adeguamento del livello di servizio entro il perimetro economico stabilito in aggiudicazione.

L’azienda si riserva la facoltà di attualizzare in corso d’opera le quantità stimate e non vincolanti, e relative alla suddivisione in classi di servizi, nel caso di esigenze ad oggi non prevedibili, e comunque entro il limite del corrispettivo contrattuale - rispetto al quale non sussiste garanzia alcuna di completa fruizione.

5. GRUPPI DI LAVORO

Le risorse professionali da impiegarsi nella fornitura di AS dovranno fare riferimento ai profili pro- fessionali indicati nell’Appendice 1 - Profili professionali.

Rispetto a questi profili professionali, l’Impresa offrirà le rispettive tariffe unitarie per singolo giorno persona (da intendersi comprensive di eventuali trasferte, della prestazione del servizio in orario esteso e della reperibilità). Queste tariffe unitarie per giorno persona si riferiscono ad 8 ore lavorative; pertanto, laddove la prestazione sia inferiore a 8 (otto) ore, la prestazione stessa sarà retribuita in modo proporzionale.

Inoltre, la tariffa si riferisce all’esecuzione dei servizi a perfetta regola d’arte e nel pieno rispetto delle modalità e delle prescrizioni contrattuali.

5.1. SERVIZIO BASE

Classe di Progetto Gestionale: CICLO COMPLETO	Ciclo Completo
	Range utilizzabile		Mix di riferimento (non vincolante)
	Da	A	Mix di riferimento (non vincolante)
Capo Progetto	2%	5%	5%
Analista Funzionale	15%	45%	35%
Analista Programmatore	20%	50%	28%
Specialista di Tecnologia/Prodotto	0%	10%	5%
Specialista di Tematica	0%	10%	2%
Programmatore	10%	40%	25%

Classe di Progetto Gestionale: CICLO REALIZZATIVO	Ciclo Realizzativo
	Range utilizzabile in AS		Mix di riferimento (non vincolante)
	Da	A	Mix di riferimento (non vincolante)
Capo Progetto	0%	5%	1%
Analista Funzionale	15%	15%	5%
Analista Programmatore	20%	50%	25%
Specialista di Tecnologia/Prodotto	0%	10%	9%
Specialista di Tematica	0%	5%	0%
Programmatore	20%	80%	60%

5.1.1. SERVIZI REALLIZZATIVI A GIORNI PERSONA

Comprendono i servizi realizzativi di Servizio di Sviluppo e Mev di software ad hoc per i quali la metrica dei Punti Funzione non si applica o fornisce un risultato non rispondente all’effort richiesto ed erogato nonché i servizi di Manutenzione Adeguativa.

Per la costruzione della base d’asta in AS si è stimato il mix di figure sotto riportato.

Tale mix non è da considerarsi vincolante per l’azienda in quanto rappresentando un impiego stimato

idoneo a caratterizzare il presente Appalto Specifico, ma non necessariamente corrispondente in modo omogeneo per ciascun sotto ambito di attività del AS.

Per il servizio di Manutenzione Adeguativa si stima il seguente impegno:

Servizio di Manutenzione Adeguativa	Mix di riferimento (non vincolante)
Capo Progetto	12,00%
Analista Funzionale	18,00%
Analista Programmatore	22,00%
Specialista di Prodotto/Tecnologia	15,00%
Programmatore	33,00%

5.2. SERVIZI COMPLEMENTARI

5.2.1. SERVIZI COMPLEMENTARI MISURATI IN GIORNI PERSONA

Per ciascun servizio complementare sono stati previsti i profili professionali che normalmente ricor- rono in questo tipo di forniture per permettere all’azienda di individuare in AS il gruppo meglio ri- spondente alle proprie esigenze ed alla propria organizzazione.

Pertanto, i mix utilizzati per la costruzione dell’offerta economica rappresentano un insieme piuttosto ampio per poter ricomprendere in una visione globale le diverse e puntuali necessità che verranno espresse in AS.

5.2.2. SERVIZIO DI GESTIONE APPLICATIVI STIMATO IN GIORNI PERSONA

Servizio di Gestione Applicativi	Mix di riferimento (non vincolante)
Capo progetto	1,00%
Specialista di prodotto/tecnologia	20,00%
Analista Funzionale	10,00%
Analista Programmatore	40,00%
Programmatore	20,00%
Sistemista Junior	5,00%
Data Base Administrator	4,00%

Normalmente i servizi di gestione sono misurati e remunerati a giorni persona a consumo in quanto spesso prestano la loro opera in gruppi misti con l’azienda ed in attività per definizione poco pianifi- cabili a priori.

5.2.3. SERVIZIO DI MANUTENZIONE CORRETTIVA AD INTERVENTO STIMATO IN

GIORNI PERSONA A CORPO

Di seguito si riportano i profili professionali ed il relativo mix sulle previsioni globali dell’intero lotto per l’erogazione del servizio di manutenzione correttiva misurato e remunerato a giorni persona a corpo.

Servizio di manutenzione correttiva	Mix di riferimento in Appalto Specifico (non vincolante)
Analista Funzionale	5,00%
Analista Programmatore	40,00%
Programmatore	50,00%
Specialista di prodotto/tecnologia	5,00%

5.2.4. SERVIZIO DI SUPPORTO SPECIALISTICO

Normalmente il servizio di supporto specialistico è attivato, misurato e remunerato a giorni persona a corpo in quanto spesso prestano in modalità progettuale e comporta di regola l’impiego di una o più figure di professionalità specifica da impiegarsi per la realizzazione di prodotti puntuali (studi di fattibilità, prototipi, gap analisi, ecc..). Attività dunque che vengono pianificate a priori, la cui com- pleta responsabilità sul raggiungimento degli obiettivi è dell’Impresa.

Servizio di Supporto Specialistico	Mix di riferimento in Appalto Specifico (non vincolante)
Capo progetto	5,00%
Specialista di tematica	20,00%
Specialista di prodotto/tecnologia Senior	10,00%
Specialista di prodotto/tecnologia	19,00%
Analista Funzionale	10,00%
Analista Programmatore	10,00%
Specialista di pacchetto	20,00%
Data Base Administrator	6,00%

6. 7. DIMENSIONAMENTO STIMATO

Nel seguito è riportato un quadro di stima relativo ai volumi previsti per ciascuna tipologia di inter- vento quale sommatoria delle esigenze da indirizzare per il fabbisogno stimato dall’azienda.

Servizi base	Valore stimato GG/PP (non vincolante)
Sviluppo/Manutenzione evolutiva	850
Manutenzione adeguativa	71
Personalizzazione e Parametrizzazione	496

Servizi complementari	Valore stimato GG/PP (non vincolante)
Manutenzione correttiva	77
Gestione Applicativi	154
Supporto Specialistico	538

Servizi accessori

Valore stimato GG/PP (non vincolante)

Formazione

7.1. FIGURE PROFESSIONALI E COMPETENZE TECNICHE

Per le competenze tecniche delle figure professionali si rimanda a quanto descritto in Appendice 1 - Profili Professionali.

8. STRUMENTI A SUPPORTO DELL’OPERATIVITÀ DELLA FORNITURA

I processi interni all’azienda quali ad esempio la verifica della qualità del software, la gestione della configurazione, la gestione della dimensione degli asset informativi in gestione, sono automatici ed effettuati ad ogni variazione avvenuta in ambiente di collaudo ed esercizio.

Tali processi avvengono applicando le principali Metriche del Software conosciute.

Il Fornitore dovrà prevedere processi operativi, modalità per la verifica, risorse, strumenti/prodotti quali:

• strumenti per la verifica della qualità del software;

• strumenti per la gestione della configurazione del sw;

• strumenti per gestire l’inventario Funzionale applicativo che gestisce il censimento dimensio- nale in Punti Funzione delle applicazioni dell’Amministrazione.

Tali strumenti dovranno essere atti allo scopo, coerenti ed applicabili ai processi interni all’azienda, e dovranno rendere disponibili output informatici definiti per consentire le verifiche previste negli indicatori specifici, che verranno effettuate in contraddittorio con il Fornitore.

I dettagli dei processi, degli strumenti e le note operative saranno messe a disposizione del Fornitore alla presa in carico del servizio.

A completamento di ciascun rilascio software e superamento delle verifiche di qualità e collaudo, il Fornitore dovrà provvedere alla messa in configurazione all’Amministrazione della release secondo le indicazioni convenute nel kick off di avvio dei servizi dell’AS ed eventualmente specializzate per il singolo obiettivo.

9. MODALITÀ DI EROGAZIONE

I servizi previsti nel presente AS, siano essi base, complementari o accessori, possono essere erogati in modalità progettuale o continuativa.

A prescindere dalla modalità con cui si erogheranno i servizi, le imprese aggiudicatarie devono:

• provvedere in piena autonomia al coordinamento e all’organizzazione dei servizi oggetto della fornitura;

• garantire il rispetto dei processi, degli standard e di eventuali linee guida adottate dall’azienda e descritte più dettagliatamente in sede di avvio dell’AS;

• assicurare la creazione, in lingua italiana, di tutta la documentazione prodotta a seguito delle attività oggetto dei servizi.

Nei paragrafi successivi si riporta una descrizione delle differenti modalità di erogazione dei servizi.

9.1. MODALITÀ PROGETTUALE

I servizi oggetto della fornitura da erogare in modalità progettuale che possono essere scomposti in Obiettivi e/o Interventi sono principalmente i servizi realizzativi nonché le attività del servizio di supporto specialistico.

Per ciascun obiettivo occorre indicare il ciclo di vita con cui effettuare le attività. I cicli di vita di un obiettivo sono caratterizzati da una o più fasi, a seconda delle dimensioni, delle caratteristiche, della criticità e della tipologia di progetto/obiettivo.

Ai fini del presente Appalto Specifico sono principalmente applicabili i Cicli Completo e Realizza- tivo, riportati in Appendice 2 - Indicatori di Qualità.

Tuttavia, in funzione di specifiche esigenze organizzative o specificità di particolari obiettivi, in corso d’opera potranno essere definiti altri cicli prodotti.

In ogni caso, dovrà essere redatto un piano di lavoro e previsti da alcuni eventi o milestone impre- scindibili, quali:

• Richiesta stima: richiesta effettuata dall’azienda al Fornitore, di procedere ad una valutazione dei tempi e dei costi dell’obiettivo e/o intervento all’interno dei vincoli indicati dall’azienda stessa;

• Comunicazione della Stima: dei tempi e dei costi dell’obiettivo e/o intervento, effettuata dal

Fornitore;

• Autorizzazione: tramite una comunicazione formale o una riunione di start-up, con cui l’azienda autorizza l’avvio delle attività relative all’obiettivo e/o intervento stimato.

• Consegna: è la milestone con cui il Fornitore rilascia i prodotti realizzati e, contestualmente, l’azienda ne verifica la quantità e la tipologia senza alcuna valutazione di contenuto;

• Collaudo e Verifica di conformità: realizzata dall’azienda, corrisponde alla valutazione con verifica di merito dei prodotti consegnati. Realizzata con esito positivo determina, per prodotti intermedi, l’Approvazione, per prodotti finali l’Accettazione dell’obiettivo e/o output dell’in- tervento. In caso di sviluppo software tale verifica corrisponde al collaudo del software prima del suo rilascio in esercizio.

9.2. GESTIONE DEGLI OBIETTIVI

Nei seguenti paragrafo è riportata per sommi capi l’operatività prevista a priori per la gestione degli obiettivi che in funzione di eventuali esigenze particolari o variazioni organizzative potrà essere ul- teriormente specializzata in corso d’opera in accordo con il Fornitore.

9.2.1. STIMA E ATTIVAZIONE OBIETTIVI

L’azienda richiede la stima di un Obiettivo e/o Intervento, comunicando al Fornitore le informazioni necessarie e disponibili di volta in volta per ciascun obiettivo, quali e non limitatamente:

• data prevista di inizio attività;

• data prevista di fine attività;

• eventuali date/scadenze critiche e/o vincolanti per il Fornitore;

• eventuale tetto/massimale di spesa;

• riferimenti a documentazione esistente (studi di fattibilità, requisiti utente già espressi, ecc);

• ove applicabili eventuali riferimenti a best practice ed esperienze progettuali pregresse su esi- genze analoghe;

• ove applicabili eventuali limiti di applicabilità e/o vincoli tecnologici e/o di esercibilità;

• ove applicabili eventuali indicazioni specifiche architetturali e progettuali.

9.2.2. VALUTAZIONE DELLE DIMENSIONI DEGLI OBIETTIVI

Il dimensionamento degli Obiettivi in termini di impegno progettuale dovrà essere effettuato, ove previsto e possibile, utilizzando la metrica dei Punti Funzione; a richiesta dall’azienda, il dimensio- namento degli Obiettivi e/o Interventi sarà effettuato in Giorni Persona.

Per gli obiettivi misurati in Punti Funzione ci sono momenti specifici del ciclo di vita in cui effettuare la misura, stimata o effettiva, precisamente:

• definizione dei requisiti: stima iniziale;

• analisi o fase equivalente: possibile revisione della stima in funzione di scostamenti nei re- quisiti utente iniziali. L’azienda può fissare uno scostamento massimo accettabile e deve, in ogni caso, approvare la nuova stima;

• fine realizzazione: consuntivo dell’obiettivo.

Resta inteso che nel caso in cui i conteggi successivi alla stima iniziale risultino inferiori alla stima/misurazione precedente, tale dimensione aggiornata sostituisce ai fini della fatturazione la stima

iniziale.

Dunque, in nessun caso, potranno essere addebitati all’azienda oneri per Punti Funzione non realizzati anche se le stime precedenti erano state accettate dall’azienda stessa.

Si precisa inoltre che l’azienda si riserva la possibilità di richiedere una stima aggiornata dei Punti Funzione in ogni momento durante tutto il ciclo di vita dell’obiettivo ed un nuovo conteggio del consuntivo anche durante il collaudo.

Il dimensionamento in Punti Funzione degli Obiettivi dovrà essere effettuato secondo le modalità di conteggio IFPUG 4.3. o successive.

A partire dalla baseline, per la definizione dell’effort realizzativo di massima saranno applicabili le indicazioni dell’azienda sulla metodologia e procedura standard applicabile indicata nella documen- tazione allegato AS e che potrà essere soggetta ad ulteriori aggiornamenti ed integrazioni sia in fase di avvio dell’AS, sia successivamente per fare fronte ad eventuali specificità degli obiettivi.

Salvo ove diversamente indicato, ai fini del presente AS, verranno applicate le seguenti modalità in linea come già disciplinato nello Schema di AQ:

• i PF di ADD verranno riconosciuti alla tariffa unitaria del PF offerta dall’Impresa per la classe di progetto gestionale;

• i PF di CHG verranno riconosciuti al 50% della tariffa unitaria del PF offerta dall’Impresa per la classe di progetto gestionale;

• i PF di DEL verranno riconosciuti al 10% della tariffa unitaria del PF offerta dall’Impresa per la classe di progetto gestionale.

In tutti i casi in cui gli obiettivi rilascino prodotti che modificano la consistenza del parco applicativo misurata in Punti Funzione (PF) chiamata anche baseline del sistema, il Fornitore è tenuto a fornire tutti gli elementi di misurazione necessari a mantenere aggiornata la baseline.

Il Fornitore dovrà garantire la costante alimentazione del sistema di tracciatura dell’asset applicativo dell’Amministrazione.

Nella seguente tabella si riportano i momenti in cui deve essere effettuata una misura, stimata o ef- fettiva, dell’effort realizzativo degli obiettivi e gli scostamenti massimi in eccesso consentiti tra le diverse fasi. Per ogni misurazione viene indicata la fase del ciclo completo in cui essa deve avvenire, precisando che laddove venga utilizzato un ciclo di vita diverso dovrà essere utilizzata la fase equi- valente.

Misura	Fase	Scostamento massimo
Stima Iniziale	Definizione (o equivalente)	N/A
Conteggio di Revisione	Analisi (o equivalente)	15%
Conteggio Consuntivo	Realizzazione (o equivalente)	0%

Si precisa che per i cicli di vita per cui non è previsto il Conteggio di Revisione, lo scostamento massimo del Conteggio Consuntivo potrà essere del 15% rispetto alla stima iniziale.

Il dimensionamento dell’obiettivo, a requisiti invariati, può subire delle variazioni al termine della fase di analisi (o equivalente). Tali variazioni, opportunamente giustificate dal Fornitore e approvate dall’azienda, ai fini della fatturazione, devono essere contenute nello scostamento massimo

consentito di cui alla tabella precedente.

In ogni caso, lo scostamento del conteggio rispetto alla stima iniziale deve essere tenuto sotto con- trollo dal Fornitore e comunicato all’azienda con la massima tempestività e comunque in tempo utile per intervenire sugli scostamenti.

Si precisa che al termine della fase di Realizzazione o equivalente, dovrà essere effettuata la consun- tivazione dell’obiettivo, contestualmente al conteggio dei Punti Funzione di baseline.

Resta inteso che nel caso in cui i conteggi successivi risultino inferiori alla misurazione precedente, tale dimensione aggiornata sostituisce ai fini della fatturazione la misurazione precedente.

Dunque, in nessun caso potranno essere addebitati all’Amministrazione oneri per Punti Funzione non realizzati anche se le stime precedenti erano state accettate dall’Amministrazione.

Il dimensionamento in Punti Funzione degli Obiettivi dovrà essere effettuato secondo le modalità di conteggio IFPUG, 4.3 e successive versioni.

9.2.3. OBIETTIVI MISURATI IN GIORNI PERSONA

Il dimensionamento degli Obiettivi e/o Interventi misurati in Giorni Persona dovrà avvenire ove pos- sibile nella fase iniziale di Definizione, o fase equivalente o comunque prima di avviare le attività.

Il dimensionamento viene realizzato previo calcolo a priori del corrispettivo sulla base della stima delle figure professionali da impiegare, e affidando le attività in modalità “a corpo” oppure conside- rando la stima come un massimale di giorni uomo.

In entrambi i casi il valore della stima costituisce un riferimento fisso ai fini della fatturazione, indi- pendentemente dall’effettivo consumo di risorse a cui il Fornitore potrà andare incontro in corso d’opera. Solo in casi eccezionali, a fronte di eventi imprevisti di forza maggiore, tale valore potrà essere riconsiderato, previa approvazione da parte dell’azienda.

9.3. CANCELLAZIONE OBIETTIVI

Nel caso di abbandono dell’obiettivo per cause imputabili al Fornitore, al Fornitore non verranno riconosciuti i corrispettivi per le attività eventualmente già svolta ed è inoltro tenuto a restituire gli eventuali acconti corrisposti prima della verifica di conformità.

Nel caso di cancellazione degli Obiettivi in corso di esecuzione, per cause non imputabili al Fornitore: non dovranno essere restituiti eventuali giorni persona già erogati a fronte di attività completate ed accettate dall’azienda (verifica di conformità positiva);

per obiettivi in Punti Funzione, sarà riconosciuto lo stato di avanzamento raggiunto all’ultima fase positivamente conclusa, secondo la formula sotto riportata. La percentuale di avanzamento ciclo di vita adottato ed a consuntivo sia per singola fase sia cumulativo. Pertanto, la formula sarà: PF rico- nosciuti = PF dell’obiettivo cancellato x % avanzamento cumulativo all’ultima fase del ciclo di svi- luppo completata dall’Impresa ed accettata dal’azienda.

In caso di ciclo completo gestionale, può essere usato come riferimento la seguente tabella:

Fase	Impegno	Avanzamento Cumulativo
Analisi	30%	30%
Disegno	15%	45%
Realizzazione e Test	40%	85%
Supporto al Collaudo	5%	90%
Documentazione finale	5%	95%
Avvio in esercizio	5%	100%

In caso di ciclo realizzativo gestionale, può essere usato come riferimento la seguente tabella:

Fase	Impegno	Avanzamento cumulativo
Analisi	5%	5%
Disegno	5%	10%
Realizzazione e Test	75	85%
Supporto al Collaudo	5%	90%
Documentazione finale	5%	95%
Avvio in esercizio	5%	100%

9.4. MODIFICA DEI REQUISITI FUNZIONALI IN CORSO D’OPERA

Nell’eventualità di un cambiamento dei requisiti funzionali in corso d’opera, si opererà come segue:

• nel caso di nuovi requisiti che richiedano lo sviluppo di nuove funzionalità saranno contate in FP le funzionalità aggiunte;

• nel caso di modifica dei requisiti, il Fornitore procederà ad una quantificazione dell’effort necessario per la realizzazione delle modifiche richieste. Nel caso in cui tale effort sia appro- vato dal Comune, ai fini della fatturazione il corrispettivo per il progetto sarà ricalcolato con- siderando anche il dimensionamento delle variazioni richieste;

• nel caso di cancellazione di requisiti, è necessario correggere il valore dei Punti funzione ri- conosciuti considerando i FP relativi ai requisiti cancellati.

9.5. MODALITÀ CONTINUATIVA

I servizi da erogare in modalità continuativa non sono scomponibili in fasi e richiedono attività con- tinuative come, ad esempio: la gestione applicativi e la manutenzione correttiva.

L’azienda si riserva la possibilità di attivare per uno o più dei sotto ambiti applicativi afferenti all’am- bito del presente capitolato, la manutenzione correttiva con singoli interventi ad hoc. Si tratta comun- que di interventi/eventi non pianificabili e per questo la modalità di erogazione deve essere

continuativa, cioè garantita ogni volta che se ne ha necessità.

L’attivazione dei servizi in modalità continuativa, generalmente, è prevista a partire dalla data di inizio attività contrattuali e l’erogazione, senza soluzione di continuità, termina alla scadenza stabilita dall’azienda od al massimo alla data di fine attività. In ogni momento il Comune può sospendere e/o interrompere il servizio ed analogamente in funzione dello stato di obsolescenza ed eventuali dismis- sioni riferibili all’asset applicativo di riferimento, piuttosto che a seguito di nuove acquisizioni che vadano ad arricchire per altra via l’asset applicativo dell’ambito, il Comune si riserva la possibilità di rivedere in corso d’opera ed attualizzare l’asset applicativo attivato in manutenzione correttiva.

La regolamentazione contrattuale dei servizi, la pianificazione ed il riepilogo delle risorse impegnate, è in giorni/persona, con modalità a tempo e spesa.

Anche in caso di regolamentazione contrattuale a tempo e spesa, le attività pianificabili dovranno essere stimate a preventivo sia in termini di impegno che di date di completamento e le eventuali variazioni dovranno essere comunicate e concordate con l’azienda.

I servizi continuativi comprendono attività come la presa in carico del sistema a inizio fornitura e di nuove funzionalità sviluppate in corso di esecuzione, attività che si realizzano con una certa periodi- cità: ad esempio la presa in carico e la risoluzione di richieste utenti, l’avviamento in esercizio di nuove applicazioni, i piccoli interventi estemporanei o prodotti servizio (report urgenti).

Il servizio di manutenzione correttiva è tipicamente ad evento in quanto innescato da una segnala- zione di impedimento all’esecuzione dell’applicazione/funzione, o dal riscontro di differenze fra l’ef- fettivo funzionamento del software applicativo e quello atteso, come previsto dalla relativa documen- tazione o comunque determinato dai controlli che vengono svolti durante l’attività dell’utente. Esso viene assimilato alla modalità continuativa in quanto la segnalazione di malfunzione non sono pre- vedibili a priori.

9.6. PIANIFICAZIONE E CONSUNTIVAZIONE

Le modalità di pianificazione e di consuntivazione riportate nei paragrafi seguenti sono riferite a tutte le attività previste nella Fornitura. I principali documenti sono il piano di lavoro, il rendiconto risorse e lo stato di avanzamento lavori.

9.6.1. PIANIFICAZIONE

In fase di esecuzione delle attività sarà necessario predisporre e mantenere aggiornato un Piano di Lavoro Generale in cui descrivere interventi/obiettivi, tempi e impegno per ciascun servizio, consi- derando soprattutto:

• un piano di subentro (a inizio fornitura) da prevedere quando il Comune lo ritenga opportuno;

• un piano di trasferimento del know how (quando richiesto); un piano di lavoro per tutti i ser- vizi a carattere continuativo; un piano riepilogativo (per i servizi a carattere progettuale).

Il Fornitore è tenuto a comunicare proattivamente e con la massima tempestività qualsiasi criticità, ritardo o impedimento che modifichi il piano concordato e ad inviare tempestivamente la ripianifica- zione delle attività.

A fronte di tali ripianificazione autorizzate dall’azienda, dovrà essere predisposta una nuova versione del Piano di lavoro generale.

In nessun caso potrà essere rivisto il Piano di Lavoro generale per inadempimenti da parte del forni- tore.

In qualunque momento l’azienda può richiedere la consegna del Piano di Lavoro generale che dovrà contenere tutti gli aggiornamenti concordati.

Per ciascun Intervento e/o Obiettivo di carattere progettuale il Fornitore è tenuto a presentare e tenere aggiornato un Piano di Lavoro Obiettivo.

9.6.2. STATO AVANZAMENTO LAVORO

Il Fornitore dovrà mantenere aggiornato la sezione di stato di avanzamento prevista nei singoli Piani approvati, fornendo tempestivamente indicazioni sulle attività concluse ed in corso, esplicitandone la percentuale di avanzamento, descrivendo eventuali criticità/ritardi e le relative azioni di recupero.

La periodicità dello Stato Avanzamento Lavori sarà di massima definita su base mensile, tuttavia per esigenze particolari e/o obiettivi particolarmente delicati la periodicità potrà essere richiesta con ca- denza settimanale o quindicinale.

9.6.3. CONSUTIVAZIONE

La consuntivazione delle attività dovrà essere predisposta periodicamente, indicativamente su base mensile, per tutti i servizi a carattere continuativo oppure ad evento e su richiesta del Comune per le attività a carattere progettuale. In questo ultimo caso andranno aggiornati i relativi piani di lavoro con le date e gli impegni effettivi (giorni persona, punti funzione, o altra metrica dimensionale, ecc.).

Il rendiconto risorse deve essere presentato sempre per i servizi a carattere continuativo e ove xxxxxx- sto per i servizi progettuale.

9.7. MODALITÀ DI CONSEGNA

In sede di avvio dell’AS, il Comune definirà le modalità specifiche da utilizzare per la fornitura, quali modalità di comunicazioni cartacee, smaterializzate, miste ed indicando eventuali strumenti a sup- porto della fornitura.

9.7.1. OGGETTI SOFTWARE

Il Fornitore ha l’obbligo di utilizzare e mantenere un proprio strumento di configuration e versioning del software, in modo da garantire la gestione della configurazione in tutte le attività che prevedono oggetti software. Il Comune indicherà, in sede di avvio dell’Appalto Specifico o eventualmente in corso d’opera, il proprio strumento di Configuration Management Applicativo a cui il Fornitore dovrà obbligatoriamente fare riferimento per portare a termine compiutamente la consegna.

Il dettaglio delle modalità con cui procedere alla consegna degli oggetti software sarà fornito in sede di AS. In ogni caso il Fornitore dovrà accompagnare sempre la consegna di oggetti software con un documento in cui viene descritta la lista di oggetti software (LOS).

Più compiutamente le operazioni di consegna e messa in configurazione del software rilasciate sa- ranno descritte nelle linee guida per fornite durante il kick-off.

9.7.2. DOCUMENTAZIONE

Il Fornitore deve consegnare al Comune tutti i prodotti della fornitura di natura documentale.

L’azienda dispone di un proprio strumento di gestione della configurazione e della documentazione di prodotto, che saranno descritte nelle linee guida fornite durante il kick off.

In generale il Fornitore deve essere in grado di inviare documenti e comunicazione formali anche via PEC al fine di poter dare tempestiva comunicazione formali riguardanti l’Appalto Specifico.

La documentazione ufficiale dovrà essere in formato nativo PDF (Portable Document Format) fir- mata digitalmente ed eventualmente corredata da allegati tecnici eventualmente in altri formati tecnici e di office automation (.pdf, .doc, .xls, .ppt, .mpp, ecc…) e deve essere accompagnata dalla lettera di consegna comprensiva dell’indice della documentazione consegnata e relativa versione/data.

Ove praticabile è sempre previsto il ricorso a consegna in formato elettronico, tuttavia in caso di impedimenti tecnici o imprevisti organizzativi sarà ammessa la consegna su un supporto digitale non modificabile (cd, dvd, ecc.) contenente la documentazione in formato nativo originale elettronico, firmata digitalmente ed accompagnata dalla lettera di consegna in formato cartaceo, nel caso di tem- poranea indisponibilità degli strumenti descritti.

9.7.3. ASSENZA DI VIRUS

Tutti i prodotti consegnati su supporti ottici o in via telematica dovranno essere esenti da virus infor- matici o altri artefatti classificabili come malware. Comune si riserva di verificare l’assenza di virus e vulnerabilità secondo le modalità e gli strumenti che riterrà più opportuni.

9.8. VINCOLI TEMPORALI

La consegna dei prodotti previsti dal contratto deve avvenire entro i termini stabiliti nella tabella nel seguito riportata, oppure definiti nel momento in cui si attivano determinati obiettivi e/o interventi.

Comune potrà definire tempi e modi per la consegna dei prodotti di specifiche forniture

Tuttavia, salvo diversa indicazione, si riportano nella tabella seguente i vincoli applicabili di massima per alcuni dei prodotti/output più diffusi nonché l’evento a partire dal quale si calcolano i termini per la consegna:

Prodotto	Evento	Giorni	NOTE
Piano della qualità ge- nerale	Stipula contratto o even- tuale esecuzione antici- pata	30 GG	Il piano di qualità deve contem- plare le soluzioni/sistemi/miglio- rie offerte.
Piano di lavoro gene- rale (prima consegna)	Stipula contratto o even- tuale esecuzione antici- pata	30 GG	Il piano dovrà essere approvabile entro e non oltre la data di inizio delle attività. Deve essere com- prensivo del piano di subentro.
Piano di subentro	Stipula contratto o even- tuale esecuzione antici- pata	30 GG
Piano di lavoro gene- rale	Fine mese di riferimento	15 GG
Piano di lavoro dell’obiettivo	Su richiesta	15 GG
Rapporto Indicatori di qualità della fornitura	Fine del periodo di riferi- mento	15 GG

In caso di mancata approvazione o rilievi di qualunque deliverable/documento della fornitura il For- nitore è tenuto a riconsegnarlo entro il termine definito dal Comune.

Nel caso la mancata approvazione dovesse reiterarsi più di 3 volte consecutivamente, il Fornitore ne sarà ritenuto responsabile per colpa grave e l’avvio dell’AS verrà considerato sospeso sino alla sua risoluzione o rientro delle criticità ostative.

L’obiettivo è la conclusione della fase di attivazione dell’AS in tempi certi e possibilmente entro 30

giorni a far data dalla sottoscrizione del contratto o dall’eventuale esecuzione anticipata dello stesso.

10. GOVERNO DELLE FORNITURE

Non oltre 5 giorni lavorativi a decorrere dalla stipula del contratto o all’eventuale esecuzione antici- pata dello stesso, sarà pianificato un incontro di Kick-Off che si terrà entro i successivi 5 giorni lavo- rativi presso le sedi del Comune tra il responsabile del Centro di Competenza del Comune ed even- tuali suoi delegati ed il Referente dell’Appaltatore ed eventuali suoi delegati, al fine di organizzare l’avvio delle attività, secondo quanto già specificato nei documenti dell’Accordo Quadro.

Il Servizio dovrà essere avviato con tutte le accortezze necessarie al fine di non introdurre disconti- nuità nei progetti in corso.

L’obiettivo è la conclusione della fase di attivazione in 4 settimane a far data dalla sottoscrizione del contratto o dall’eventuale esecuzione anticipata dello stesso.

L’attivazione sarà ritenuta conclusa quando l’intero gruppo sarà composto e non ci saranno più pas- saggi di consegne in corso. Gli incontri di affiancamento saranno svolti presso le sedi del Comune.

Gli incontri di Kick-Off e gli incontri di affiancamento saranno a carico dell’Appaltatore senza alcun onere per il Comune.

Durante la fase di attivazione, quale documentazione dell’attività di passaggio di consegne, l’Appal- tatore si impegna a revisionare la documentazione di servizio al momento disponibile e che sarà con- divisa dal Comune, integrandola e arricchendola con tutte le parti ritenute utili per la corretta com- prensione del processo e per l’esecuzione operativa delle attività relative.

La data di conclusione effettiva della fase di attivazione sarà concordata tra il responsabile incaricato del Comune o un suo delegato ed il Referente dell’Appaltatore o un suo delegato. Dal giorno seguente il servizio sarà considerato avviato e si applicheranno le modalità di monitoraggio e controllo espli- citate in Appendice 2 – Indicatori di Qualità.

Per tutti i prodotti/tools che verranno forniti dal Comune viene fatto integrale richiamo alle condizioni ed ai limiti all'uso ed all'accesso di cui all’art. 10 dello Schema di Contratto.

10.1. ACCETTAZIONE/APPROVAZIONE PRODOTTI DELLA FORNI- TURA

Come indicato nei capitoli precedenti, il Comune sottopone a processo di Accettazione / Approva- zione tutti i prodotti previsti per i servizi attivati nei relativi AS al fine di verificare la rispondenza dei prodotti stessi ai requisiti stabiliti (funzionali e non funzionali).

Le anomalie / malfunzionamenti / disallineamenti dovranno essere tempestivamente risolte dal For- nitore per permettere la prosecuzione delle attività, comunque entro i tempi definiti dai livelli di ser- vizio (Appendice 2 - Indicatori di Qualità). Eventuali ritardi nella risoluzione delle anomalie ri- scontrate comporteranno l’applicazione delle sanzioni contrattualmente previste.

Nel caso si verifichino situazioni “anomale” che, a giudizio del Comune, sia per numerosità sia per gravità, sia per non rispetto dei tempi massimi indicati per la risoluzione delle anomalie, non consen- tano lo svolgimento o la prosecuzione delle attività il Comune procederà alla sospensione della fase e lo slittamento del termine della fase sarà a totale carico del Fornitore comportando le azioni con- trattuali previste.

I nuovi termini di consegna dei prodotti verranno indicati dal Comune ed entro tali termini il Fornitore dovrà procedere alla consegna della versione corretta dei prodotti stessi. In caso di 2 sospensioni sul medesimo obiettivo il Comune si riserva la facoltà di dichiarare non approvabile il prodotto oggetto di verifica per inadempimento del Fornitore e gli acconti eventualmente versati al Fornitore dovranno

essere da lui restituiti.

All’atto dell’accettazione dei prodotti dell’obiettivo, in caso in cui sia possibile procedere all’accet- tazione/approvazione dei prodotti, verrà redatto e sottoscritto dal Comune il verbale di accettazione. Tale documento sarà utilizzato in fase di Verifica di Conformità.

Per i servizi realizzativi, assume particolare rilevanza l’accettazione del prodotto software realizzato.

Le attività di accettazione vengono pianificate nella fase di Collaudo. Tale fase è di responsabilità del Comune: l’esecuzione dei test di collaudo avverrà in contraddittorio con il Fornitore che è tenuto a dare supporto, senza alcun onere aggiuntivo.

Al termine del collaudo, verrà redatto il verbale di collaudo con allegati i casi di test eseguiti ed il relativo esito. Tali dati determineranno il valore dell’indicatore di qualità TNCO - “Tasso di Casi di test eseguiti in collaudo con esito negativo”.

Si precisa che qualora il valore rilevato dell’indicatore sia inferiore al 10%, il Comune darà un termine molto limitato (indicativamente un termine di 3 giorni lavorativi) per riconsegnare il software cor- retto e verranno riprese le attività di collaudo senza alcuna ripianificazione; non si ha una formale sospensione del collaudo.

Diversamente, qualora il valore rilevato dell’indicatore sia superiore al 10%, verrà sospeso il col- laudo.

Il Comune ed il fornitore concorderanno il tempo di sospensione ed a tale periodo sarà applicato l’apposito indicatore di qualità.

Come indicato nella trattazione generale, nel caso di 2 sospensioni sulla medesima attività / fase / prodotto, il Comune si riserva di risolvere il contratto per inadempimento del fornitore.

In caso di obiettivi realizzativi molto piccoli in termini di punti funzione/funzionalità realizzate, per i quali non si addice la misurazione in termini percentuali della difettosità (casi di test indicativamente inferiori a 50), sarà il Comune a stabilire le soglie di difettosità fisiologica e le modalità di sospensione del collaudo.

10.2. VERIFICHE DI CONFORMITÀ

Il soggetto deputato all’esecuzione delle attività di verifica di conformità, dopo aver acquisito la do- cumentazione tecnico-funzionale dei servizi (sia a carattere continuativo che progettuale), procederà a certificare la corretta esecuzione degli stessi. Della verifica di conformità si darà apposita comuni- cazione al fornitore che potrà parteciparvi. Al termine della suddetta verifica verrà data comunica- zione formale al fornitore.

10.3. RILEVAZIONE SODDISFAZIONE DEGLI UTENTI

Il Comune si riserva di effettuare una rilevazione sulla Soddisfazione degli utenti su tutti o parte dei servizi presenti in AS. In tal caso il Fornitore è tenuto a predisporre i questionari ed elaborare i dati raccolti, fornendo tutti gli elementi per verifica e condivisione. Si precisa che il campione e le moda- lità di rilevazione verranno sempre definite dal Comune.

10.4. MONITORAGGIO

Il Fornitore si impegna a fornire al Comune tutti i documenti necessari all’attività di monitoraggio nei formati standard richiesti e, se offerta, mediante la messa a disposizione della soluzione tecnolo- gica per il monitoraggio, il controllo e la verifica della fornitura, salvo evoluzioni derivanti dall’in- troduzione, da parte del Comune, di strumenti automatici a ciò deputati (es. portale della fornitura, ecc.). Il Fornitore si impegna a inviare alla Consip e al Comune la documentazione comprovante

l’esito delle visite di sorveglianza della società di certificazione della qualità e/o il rinnovo della cer- tificazione entro un mese dalla data della verifica. Inoltre, il Fornitore e/o i subfornitori potranno essere fatti oggetto di verifiche anche ispettive effettuate dal Comune tramite personale proprio o da terzi da essa incaricati, svolte nel rispetto di quanto prescritto dalla serie di norme EN ISO 19011:2003. In caso di mancato invio della documentazione nei termini e modi richiesti od in pre- senza di irregolarità, comporterà le sanzioni previste contrattualmente.

Il Comune si riserva di effettuare controlli sulla qualità del software prodotto con appositi strumenti; si riserva inoltre di verificare lo stato di avanzamento delle attività anche presso la sede del Fornitore. In tal caso il Fornitore deve essere disponibile ad incontri/visite del Comune o personale delegato, finalizzate alla verifica del reale stato di avanzamento della produzione del software, del test, dell’ef- fettivo utilizzo del mix di figure professionali offerte rispetto a quelle previste contrattualmente, dello stato di implementazione ed utilizzo delle soluzioni, metodologie.

10.5. FLUSSI INFORMATIVI DI MONITORAGGIOFORNITURE

L’aggiudicatario dell’Appalto Specifico è tenuto all’invio a Consip S.p.A. dei flussi informativi di Monitoraggio Forniture secondo le specifiche presenti nell’apposito allegato al Capitolato d’Oneri dell’Accordo Quadro.

10.6. AZIONI CONTRATTUALI

Ogni inadempimento contrattuale darà origine ad un’azione commisurata alla criticità della viola- zione.

I principali aspetti delle prestazioni contrattuali vengono presidiati da appositi indicatori di qualità, specialmente laddove vengono definite specifiche misure. Altri aspetti non sono oggetto di misura- zioni strutturate di cui all’Appendice 2 - Indicatori di Qualità.

Il mancato rispetto dei requisiti minimi richiesti e/o come migliorati dal fornitore in Offerta tecnica determina azioni contrattuali conseguenti che possono consistere in una o più delle seguenti azioni:

• coinvolgimento di un livello più elevato di interlocutori, sia del fornitore, che della stazione appaltante, allo scopo di prendere le decisioni necessarie al ripristino delle situazioni fuori soglia o fuori controllo (attivazione di una procedura di escalation);

• ripetizione da parte del fornitore dell’erogazione della prestazione, rifacimento di un’attività, riconsegna di un prodotto (chiusura di una non conformità);

• azione di intervento sui processi produttivi del fornitore per evitare il ripetersi di sistematiche non conformità (esecuzione di una azione correttiva);

• applicazione di rilievi;

• perdita della quota variabile del corrispettivo legato al raggiungimento di un livello di qualità minimo;

• applicazione di penali;

• azioni aggiuntive (richiesta danni, risoluzione anticipata del contratto, ecc.).

Segue un approfondimento degli istituti a tutela della qualità dell’erogazione della fornitura.

10.6.1. RILIEVI

I rilievi sono le azioni di avvertimento da parte del Comune conseguenti il non rispetto degli adem- pimenti contenuti nella documentazione contrattuale. Pertanto, oltre a quanto esplicitamente previsto potrà essere emesso un rilievo su qualunque inadempimento se non diversamente sanzionato. Sono

notificati al Fornitore tramite comunicazione formale, ognuna delle quali potrà contenere uno o più rilievi.

I rilievi non prevedono di per sé l’applicazione di penali e, se reiterati e accumulati, danno luogo a penali e/o altre azioni contrattuali.

In Appendice 2 - Indicatori di Qualità è riportato il livello di servizio che determina il numero massimo di rilievi tollerati al cui superamento di un’azione di livello superiore, perdita quota sospesa o penale. Qualora il Fornitore ritenga di procedere alla richiesta di annullamento del rilievo dovrà sottoporre al Comune un documento con elementi oggettivi ed opportune argomentazioni entro il termine definito (in genere 3 giorni lavorativi dall’emissione della nota di rilievo).

10.6.2. PENALI

Lo scopo delle penali è quello di riequilibrare il servizio effettivamente ricevuto (di minore qualità, e/o generando disservizi e/o ritardi e/o inducendo un danno all’utilizzatore) dal Comune al corrispet- tivo da erogarsi che è stabilito per prestazioni effettuate a regola d’arte.

Le penali da adottare sono individuate all’interno Appendice 2 - Indicatori di Qualità.

10.6.3. CHIUSURA DEL SERVIZIO

La chiusura del servizio è pianificata entro il termine del periodo contrattuale previsto per il presente appalto.

La chiusura del servizio deve permettere di gestire un’eventuale transizione con un altro aggiudica- tario subentrante. Segue esattamente la stessa logica e gli stessi tempi dell’attivazione del servizio in quanto deve essere graduale e verificabile.

Le suddette attività saranno poste a carico del fornitore aggiudicatario entrante a seguito di una nuova procedura, senza alcun onere per il Comune.

Document Metadata

Table of Contents

Contract

Document Metadata