Ministero dello Sviluppo Economico

Transcript

1 Ministero dello Sviluppo Economico DIREZIONE GENERALE PER LA VIGILANZA SUGLI ENTI, IL SISTEMA COOPERATIVO E LE GESTIONI COMMISSARIALI Progetto sistema informatico di gestione accertamenti contributi Capitolato tecnico

2 Sommario 1 Premessa Descrizione della fornitura Oggetto della fornitura Beni Servizi Piano di Progetto Pianificazione delle attività Tempistica del progetto Prodotti da rilasciare Approvazione Accettazione Base Informativa di Progetto Qualità della fornitura Garanzia Penali Penali per ritardata consegna Penali di mancato Collaudo Penali per mancato rispetto Livelli di Servizio Conduzione ed Assistenza sistemistica Penali per mancato rispetto Livelli di Servizio Manutenzione Correttiva Penali per mancato rispetto Livelli di Servizio Addestramento e Formazione Penali per mancato aggiornamento della Base Informativa di Progetto Figure professionali previste Dettaglio delle figure professionali Analisi dei requisiti utente Principali funzionalità Struttura dei dati Profilazione degli utenti Dati di ambiente Funzionalità del Nuovo Sistema Architettura SOA Architettura applicativa: componenti principali Capitolato tecnico 21 luglio 2015 Pag. 2

3 1 Premessa Nell ambito della Direzione generale per la vigilanza sugli enti, il sistema cooperativo e le gestioni commissariali, la Divisione IV Albi - Contributi enti cooperativi si occupa di: Gestione dell'albo delle società cooperative a mutualità prevalente e delle cooperative diverse da quelle a mutualità prevalente Gestione dell'albo Nazionale delle società cooperative edilizie di abitazione e dei loro consorzi Amministrazione del Comitato per l'albo nazionale delle società cooperative edilizie di abitazione e dei loro consorzi ai sensi dell'articolo 13 della legge n. 59 del 1992 Riconoscimento dei consorzi di produzione e lavoro ammissibili ai pubblici appalti ai sensi della legge n. 422 del 1909 ed approvazione delle relative modifiche statutarie Istruttoria delle istanze di riesame in materia di contributi dovuti dagli enti cooperativi Adempimenti connessi alla determinazione del contributo biennale di revisione Accertamento e Riscossione dei contributi di revisione dovuti dagli enti cooperativi e delle somme relative all'articolo 11 della legge 31 gennaio 1992, n. 59, e relativa attività esecutiva Elaborazione dati, indagini ed analisi sul sistema cooperativo Approntamento di prodotti e servizi di informazione connessi all'attività dell'ufficio Relazione triennale al Parlamento ai sensi dell'articolo 16 della legge n. 59 del 1992 La Divisione IV nello svolgimento delle proprie attività interagisce in particolare con la Divisione VI - Scioglimenti, gestioni commissariali, liquidazione coatta amministrativa degli enti cooperativi, e con la Divisione V - Vigilanza sui sistema cooperativo. Attività ispettiva e di revisione. 2 Descrizione della fornitura Al fine di razionalizzare il sistema informativo di gestione della Divisione IV, L Amministrazione intende rivedere i processi ed il relativo Sistema Informatico anche al fine di consentire un maggior livello di automazione nella gestione delle pratiche, migliorare l interscambio di informazioni fra la varie Divisioni ed introdurre una soluzione completa ed integrata per il gestire il processo dall inserimento dell istanza da parte della cooperativa, attraverso il Portale Cooperative, sino al sistema di reporting Direzionale. La realizzazione di un nuovo sistema informatico per la gestione di accertamenti e contributi (nel seguito Nuovo Sistema) dovrà permettere all Amministrazione di perseguire gli obiettivi di accrescere l efficienza nella gestione delle pratiche relative alla riscossione dei contributi previsti dalla normativa vigente nonché di dematerializzazione e di cooperazione applicativa fra i vari moduli del sistema informatico direzionale. Capitolato tecnico 21 luglio 2015 Pag. 3

4 La fornitura in oggetto consentirà all Amministrazione la revisione dei processi di analisi della situazione debitoria delle cooperative, l invio degli accertamenti, la gestione delle istanze presentate dalla cooperative medesime, la chiusura degli accertamenti ed, eventualmente, l iscrizione a ruolo per i soggetti inadempienti. Il Nuovo Sistema utilizzerà una base dati esistente (Oracle), che dovrà essere integrata con le informazioni strettamente connesse agli accertamenti inviati dall Amministrazione ed alle comunicazioni da parte delle cooperative relative a detti accertamenti, registrati nel data base FoliumCS - Sicoop. Tali informazioni potranno essere ulteriormente integrate dalle informazioni che il fornitore riterrà di inserire per migliorare l efficienza e la funzionalità della soluzione proposta. L obiettivo principale della presente fornitura è quello di migliorare l efficienza delle procedure interne riducendone i relativi costi di gestione attraverso una maggiore fruibilità delle applicazioni informatiche di back office ed una maggiore integrazione fra i vari moduli del sistema informativo Direzionale. L oggetto della fornitura consentirà a tutti gli utenti autorizzati di accedere al Nuovo Sistema, interrogare, modificare ed inserire i dati relativi alle pratiche di propria competenza, garantendo l integrazione con le altre componenti del sistema stesso 1. Le attività dei Funzionari, quali, ad esempio, la correzione dati, la protocollazione dei documenti, l invio di PEC) e del Dirigente (ad. es. firma digitale) verranno eseguite in un unico ambiente e con un elevato livello di automazione. La fornitura consentirà la gestione dei vari steps autorizzativi del processo di lavorazione delle varie tipologie di pratiche; in particolare, i profili degli utenti verranno parametrizzati in base al ruolo nell organizzazione e potranno essere definiti controlli specifici per ciascun profilo; verrà garantita la tracciabilità delle operazione effettuate. Inoltre, il Nuovo Sistema oggetto della fornitura interagirà con il sistema di reporting Direzionale, consentendo ai Responsabili di avere dati ed indicatori aggregati secondo le necessità utili a migliorare il controllo sulle attività. 3 Oggetto della fornitura Si richiede la realizzazione del Nuovo Sistema mediante sviluppo software ad hoc. Per l esecuzione di tale attività si stima una durata massima di 8 mesi dalla data di stipula del contratto. Si richiede inoltre la fornitura di beni e servizi per una durata non inferiore a 16 mesi successivi alla data di rilascio in produzione del Nuovo Sistema che comprenda le aree di intervento sottoelencate e garantisca i corrispondenti Livelli di Servizio (SLA Service Level Agreement) concordati e riscontrati nel Piano di Qualità per i servizi, di cui al successivo paragrafo ad es.: Portale coop, sistemi informatici di altre Divisioni, base dati Parix-COSE Capitolato tecnico 21 luglio 2015 Pag. 4

5 La data di rilascio in produzione del Nuovo Sistema sarà indicata in apposito verbale sottoscritto dall Amministrazione e dal Fornitore. Realizzazione del Nuovo Sistema (sviluppo software ad hoc); Migrazione dei dati dall attuale piattaforma (FoliumCS-Sicoop) ; Supporto per la predisposizione e la gestione degli ambienti operativi (ambiente di produzione, collaudo e sviluppo); Documentazione tecnica del Nuovo Sistema (Analisi dati, Analisi funzioni); Documentazione Utente; Consolidamento e conduzione operativa dell intero ambiente (ambienti di produzione, collaudo e sviluppo); Supporto all avviamento in esercizio; Manutenzione correttiva; Manutenzione evolutiva ed adeguativa; Supporto sistemistico, consistente nella risoluzione di problematiche relative al software di base (compreso DBMS) - installato sulla componente server - indipendenti dal software applicativo e riconducibili a bug di sistema operativo e/o blocco (a livello software) del sistema; Mantenimento e misurazione dei Livelli di Servizio attraverso dispositivi HW e/o SW che consentano la programmazione di allarmi e l avvio di procedure di segnalazione e risoluzione dell anomalia riscontrata, oltre alla possibilità di effettuare statistiche sui predetti livelli di servizio in un qualunque arco temporale ; Reportistica periodica su tutte le aree soggette a misurazione e controllo. Ai fini dell erogazione dei servizi, si intendono giorni lavorativi i giorni feriali (dal lunedì al venerdì non festivi) con orario dalle ore 9:00 alle ore 18:00. Il Fornitore dovrà porre in essere ogni attività necessaria ed opportuna per rendere pienamente operativa l erogazione dei predetti servizi e per mantenerla in perfetto stato di efficienza per tutta la durata del progetto, impegnandosi a predisporre ed adottare tutti gli strumenti, le metodologie e le misure necessarie per garantire il rispetto dei requisiti di sicurezza e qualità, nonchè i Livelli di Servizio indicati nell Offerta (comunque relativi ad una disponibilità del sistema non inferiore al 98,6%), pena l applicazione delle relative penali. Tutto ciò premesso, l Amministrazione richiede la fornitura dei beni e servizi paragrafi. descritti nei successivi 3.1 Beni Licenze software: Capitolato tecnico 21 luglio 2015 Pag. 5

6 Diritto di proprietà per l Amministrazione del software sviluppato ad hoc relativo al Nuovo Sistema e delle relative interfacce con gli altri moduli del sistema informatico in essere presso l Amministrazione ; Dispositivo di monitoraggio (HW e/o SW), opportunamente predisposto e configurato, che consenta all Amministrazione di acquisire in modalità autonoma ed indipendente la reale disponibilità dei servizi di elaborazione. Tale dispositivo, comprensivo di eventuali canoni di manutenzione, dovrà essere disponibile all Amministrazione per un minimo di 16 mesi successivi alla data di rilascio in produzione. La fornitura non deve prevedere costi aggiuntivi per Licenze d uso di prodotti software di proprietà di terzi e relativi canoni di manutenzione. Nel caso in cui il Fornitore decida di utilizzare nell ambito della realizzazione del Nuovo Sistema componenti software il cui utilizzo è a titolo oneroso, la fornitura dovrà comprendere licenze d uso illimitate per almeno 200 utenti per ognuno di tali componenti, comprensive dei canoni di manutenzione ed assistenza per un minimo di 16 mesi successivi dalla data di rilascio in produzione del Nuovo Sistema. 3.2 Servizi System integration: realizzazione ed integrazione della soluzione applicativa in accordo ai requisiti funzionali espressi di seguito al capitolo 6 Analisi dei requisiti utente ; supporto all avviamento, collaudo, rilascio in esercizio; formazione e supporto post-avvio; Attività di migrazione dati ; Manutenzione correttiva della piattaforma software: manutenzione correttiva della piattaforma per un minimo di 16 mesi successivi alla data di rilascio in produzione ; Manutenzione evolutiva ed adeguativa della piattaforma software: manutenzione evolutiva ed adeguativa della piattaforma per un minimo di 16 mesi successivi alla data di rilascio in produzione; Conduzione di progetto Assistenza sistemistica/data Base Administration per un minimo di 16 mesi successivi alla data di rilascio in produzione Descrizione dei servizi System Integration Fase di Progettazione Sulla base dei requisiti indicati nella Specifica dei requisiti, il Fornitore definisce: Capitolato tecnico 21 luglio 2015 Pag. 6

7 Architettura tecnica: Il risultato dell attività è costituito dall Architettura tecnica, documento nel quale è descritta la soluzione progettuale, ovvero l architettura hardware e software del sistema che realizza gli ambienti logici di sviluppo, collaudo ed esercizio (componenti HW, SW ed infrastrutturali del sistema, relative configurazioni ed operazioni manuali) Architettura applicativa: Il risultato dell attività è costituito almeno dalle seguenti tipologie di prodotti: analisi funzionale Documento nel quale è indicata l architettura e le componenti software, il dettaglio dei moduli applicativi ed il disegno delle interfacce. Il documento contiene la rappresentazione dei processi e del flusso di dati che tali processi utilizzano e trasformano, le interazioni tra il prodotto da realizzare ed il sistema. analisi dati Documento nel quale è descritto il modello concettuale e logico dei dati. documentazione utente - Documento che descrive come sarà composta la documentazione utente (manuali utente, tutorial, help contestuali etc.; in particoleare, il manuale utente, ovvero documento che descrive il funzionamento del sistema dal punto di vista dell utente finale, dovrà essere suddiviso in sezioni corrispondenti ai vari profili di utenza individuati in sede di analisi (compreso il profilo amministratore di sistema). Progetto Test e Collaudo: in questa fase il Fornitore definisce i test interni (test unitari, test funzionali, test di prodotto, test di integrazione, test di sistema e test di qualificazione finale) che dovranno essere eseguiti prima del rilascio al collaudo, per garantire che quanto realizzato sia conforme ai requisiti indicati nell Analisi dei Requisiti e agli obiettivi fissati nel Piano di qualità. Il risultato dell attività è costituito dal Piano di collaudo, documento che potrà essere utilizzato dalla Commissione di collaudo nominata dall Amministrazione per eseguire il collaudo della fornitura. Il documento definisce le prove di collaudo in coerenza con i requisiti indicati nei documenti contrattuali e meglio dettagliati nella Specifica dei requisiti; definisce le specifiche dell ambiente di collaudo, che dovrà riprodurre fedelmente l ambiente di esercizio, e le figure professionali che saranno dal Fornitore per assistere la Commissione nella esecuzione delle operazioni di collaudo. La fase di progettazione si completa con l approvazione da parte dell amministrazione. Tutta la documentazione fornita in fase di Progettazione dovrà essere opportunamente aggiornata durante le varie fasi di sviluppo del progetto ed, in particolare, alla data di rilascio in produzione del Nuovo Sistema Fase di Realizzazione e Collaudo In tale fase si procede alla implementazione della soluzione progettuale, in termini di infrastruttura tecnologica, codice, basi di dati, documentazione utente, servizi; seguono l esecuzione dei test ed il collaudo di quanto realizzato, secondo le specifiche prodotte nel processo di Progettazione. Codifica: il Fornitore, sulla base delle Specifiche funzionali, realizza il prodotto, procedendo alla codifica del software, sviluppando e documentando moduli, componenti e banche dati. Capitolato tecnico 21 luglio 2015 Pag. 7

8 A completamento dei test unitari sui singoli moduli il Fornitore, per ciascun elemento software definito nel processo di Progettazione, procede alla integrazione delle unità software e dei componenti, eseguendo quindi i test funzionali per verificare che nell insieme gli aggregati soddisfino i requisiti dell elemento software. Parte integrante dell attività è la produzione di procedure operative che regolamentino sia le modalità di gestione operativa che le modalità di manutenzione. Il risultato dell attività è il Prodotto software, ovvero l insieme degli elementi software integrati, con relativi dati e documentazione nella configurazione finale risultante dal test. Predisposizione del sistema: In accordo con i documenti che descrivono l architettura tecnica e/o le Specifiche di realizzazione del servizio, il Fornitore procede alla predisposizione della infrastruttura hardware e software necessaria per realizzare il sistema che ospiterà gli ambienti logici di sviluppo, collaudo e di esercizio, provvedendo ad eseguire l installazione e l integrazione delle componenti hardware e software. È parte integrante dell attività la produzione di procedure operative che regolamentino sia le modalità di gestione operativa che le modalità di manutenzione. Il risultato dell attività è l Infrastruttura HW e SW che ospiterà gli ambienti logici di sviluppo, collaudo ed esercizio, intesa come insieme di componenti hardware e software integrati, con relativa documentazione, con le procedure e con quanto propedeutico all installazione ed esercizio del prodotto software sviluppato o all erogazione del servizio, nella configurazione finale risultante dal test di sistema. Documentazione: Parallelamente alla codifica del software e/o alla predisposizione del Nuovo Sistema il Fornitore procederà alla produzione della Documentazione utente (manuali utente, tutorial, help contestuali etc.). La documentazione utente sarà predisposta secondo standard e requisiti fissati nel processo di Progettazione e sarà oggetto di verifiche formalizzate per verificarne la corrispondenza ai requisiti, l accuratezza, la comprensibilità e più in generale l usabilità. Installazione: L attività riguarda l installazione del prodotto software sviluppato nell ambiente di esercizio e/o l esecuzione di compiti, non svolti nell ambito dell attività di Predisposizione del sistema, volti a rendere operativo il sistema o l ambiente di erogazione del servizio. Detti compiti riguardano, fra l altro: a) l attivazione di profili utente per la sicurezza; b) l attivazione di postazioni di lavoro; c) la configurazione di prodotti SW; d) il caricamento iniziale di dati nelle delle basi dati, a partire dal sistema esistente (v. par Attività di migrazione dati). L attività è svolta secondo un Piano di installazione, correlato al Piano di progetto, nel quale sono indicati attività, tempi, modi e risorse necessarie. Il risultato dell attività è il sistema che ospita l ambiente di erogazione del servizio, con il prodotto software sviluppato e le relative basi dati installate e correttamente funzionanti, secondo i requisiti contrattuali e progettuali. Capitolato tecnico 21 luglio 2015 Pag. 8

9 Collaudo: L attività è eseguita da una Commissione di collaudo nominata dall Amministrazione. Saranno oggetto del collaudo, tra l altro, il prodotto software realizzato, il sistema che ospita l ambiente di esercizio, la documentazione aggiornata relativa alla fase di progettazione, la documentazione utente. Le prove di collaudo saranno eseguite nell ambiente di collaudo predisposto dal Fornitore, che supporterà la Commissione nella esecuzione delle prove, nel rilevamento dei risultati e nella stesura del rapporto finale. La verifica con esito positivo della fornitura termina con l emissione di un verbale di collaudo positivo, che sancisce la conformità ai requisiti contrattuali del prodotto software e/o l erogabilità del servizio oggetto di fornitura, dando luogo all accettazione della fornitura. In caso di esito negativo del collaudo e/o di non-conformità rispetto ai requisiti contrattuali, il Fornitore è tenuto a rimuovere i malfunzionamenti e a presentare nuovamente la fornitura al collaudo, nei tempi e nei modi stabiliti nel contratto. Avviamento in esercizio: Successivamente all accettazione della fornitura è prevista l attività di avviamento che consiste nell esercizio del prodotto software Attività di migrazione dati Come indicato precedentemente, il Nuovo Sistema utilizzerà una base dati già esistente, a meno delle informazioni strettamente connesse agli accertamenti inviati dall Amministrazione ed alle comunicazioni da parte delle cooperative relative a detti accertamenti. 3.3 L attività di migrazione dei dati consisterà pertanto nel trasferimento dei dati accertamenti/comunicazioni attualmente gestiti dal sistema FoliumCS e (v. par. 6.6 Architettura SOA Tutte le applicazioni del MiSE offrono, accanto alle tradizionali interfacce end-user, anche interfacce di collegamento per l integrazione con tutti gli altri sistemi del ministero attraverso una piattaforma di Enterprise Service Bus (ESB). L ESB o middleware è una piattaforma tecnologica che rimuove qualsiasi collegamento diretto punto-punto tra il provider di un servizio ed il suo consumer. Pertanto qualunque applicativo che intende usufruire di un servizio esposto da un altro sistema, si collega direttamente al bus e non al provider che effettivamente implementa il servizio. Il bus ha il compito di ricevere la richiesta dall'applicazione consumer, e indirizzarla correttamente al sistema fornitore interfacciandosi con esso utilizzando protocolli standard di settore (xml, wsdl, soap, rest, publish and subscribe ecc.). In questo modo da un lato si disaccoppia in modo forte il consumer dal fornitore per il servizio specificatamente richiesto, e dall altro si concentra sul bus l implementazione dei servizi di log, audit, orchestrazione(routing), sicurezza, garanzia di consegna, trasformazione del formato del messaggio xml, e d integrazione che diversamente bisognerebbe implementare ogni volta alla coppia consumer/provider. L obiettivo è mantenere all interno del MiSE un architettura distribuita di tipo SOA (Service Oriented Architecture) in grado di aumentare e garantire sicurezza, flessibilità e gestibilità del flusso di informazioni che viaggiano tra i vari applicativi, ognuno della quale può essere sia consumer sia provider di servizi. Capitolato tecnico 21 luglio 2015 Pag. 9

10 Obiettivo Tutti i processi d integrazione sia in essere sia in divenire interni al MiSE devono essere gestiti dalla piattaforma SOA. La piattaforma utilizzata dal MiSE per l integrazione dei sistemi fra loro comunicanti è la piattaforma Oracle BPM nella versione 11g. Il sistema BPM detto BPM COOP è stato realizzato al fine di soddisfare l esigenza della Direzione Generale per le Piccole e Medie Imprese e gli Enti Cooperativi (DG-PMI-EC) del Dipartimento per l impresa e l internazionalizzazione del Ministero dello Sviluppo Economico, di ottimizzare i propri processi interni attraverso l automazione degli stessi secondo una logica di Business Process Management; Il prodotto commerciale su cui si basa l architettura SOA, è Oracle Unified Business Process Management, che a sua volta è basato su un altra serie di prodotti Oracle che forniscono le funzionalità primarie per il disegno e l esecuzione dei Business Process. L Oracle Business Process Management Suite 11g è una soluzione BPM completa che si basa sullo standard BPMN 2.0 sia per la modellazione sia per l esecuzione dei processi di business. Inoltre tale suite è stata costruita e si basa su una sottostante architettura denominata Oracle SOA Suite (11g), che mette a disposizione una svariata gamma di adapter per l integrazione con sistemi esterni. Architettura L infrastruttura di esecuzione dei processi si basa sullo standard SCA (Service Component Architecture) e offre in maniera nativamente integrata tutti i componenti necessari all esecuzione ed al monitoraggio dei processi di business (motore di esecuzione di processi di business BPMN e BPEL, Human Workflow, ecc.), nonché all integrazione di sistemi ed applicazioni esterne (JMS Adapter, Database Adapter, File Adapter, ecc.). L application server utilizzato dalla suite è Oracle WebLogic Server 10.3 e il DBMS è Oracle Enterprise 10g. Capitolato tecnico 21 luglio 2015 Pag. 10

11 3.3.1 Personalizzazioni dell Ambiente Ministero dello Sviluppo Economico L architettura sopra descritta è interamente rilasciata nell ambiente informatico del Ministero su un sistema centralizzato ed ingegnerizzato (Oracle ODA). Su tale struttura a breve verrà rilasciato con funzioni di collaborazione applicativa anche il nuovo sistema di Protocollo Informatico del Ministero che basa il suo documentale sul prodotto Oracle Web Center Content che diverrà l unico documentale per tutte le applicazioni core. Inoltre l infrastruttura ospita il prodotto Oracle Portal che è il sistema attraverso cui vengono pubblicati su internet i nuovi servizi a terzi e le interfacce dalle applicazioni basate su SOA. Capitolato tecnico 21 luglio 2015 Pag. 11

12 3.3.2 Architettura di dettaglio Scheda Prodotto Prodotto Versione Oracle BPM Suite Oracle SOA Suite Oracle Enterprise Manager Oracle Service Bus Oracle WMS policy Manager Oracle JRF WebService Asyncronous services Web Logic Server Web Center Content Oracle Portal Capitolato tecnico 21 luglio 2015 Pag. 12

13 Architettura applicativa: componenti principali). Tali dati comprendono sia dati strutturati, sia puntatori a documenti gestiti nel sistema di gestione documentale (v. par Sistema documentale ADAM). I suddetti dati dovranno essere trasferiti nell ambito della base dati del Nuovo Sistema, senza alcuna eccezione a meno di preventivo assenso scritto da parte dell Amministrazione Manutenzione Correttiva La manutenzione correttiva è volta a rimuovere le cause e gli effetti dei malfunzionamenti delle procedure e dei programmi, ed è innescata da impedimenti nell esecuzione dell applicazione o di differenze riscontrate fra l effettivo funzionamento del software applicativo e quello atteso, previsto dalla relativa documentazione. Ai fini dell erogazione del servizio di manutenzione correttiva vanno considerati i seguenti parametri: segnalazione anomalia: data e ora in cui il Fornitore riceve la comunicazione dell anomalia sull apposito sistema di segnalazione ; comunicazione di avvenuto intervento: data e ora in cui il Fornitore avrà attuato l intervento correttivo e comunicato sul sistema di segnalazione la risoluzione dell anomalia stessa; valore di soglia dell intervento: massimo intervallo di tempo intercorrente tra la segnalazione di anomalia e la comunicazione di avvenuto intervento; Fix Response Time (FRT): differenza temporale tra la comunicazione di avvenuto intervento e la segnalazione anomalia; ad ogni anomalia viene assegnato un livello di gravità in relazione al danno prodotto sul sistema. Il Fornitore renderà disponibile un sistema di gestione delle segnalazioni/risoluzioni di anomalie, in modo da consentire la rilevazione oggettiva dei Livelli di Servizio dichiarati in fase di offerta e riscontrabili nel Piano di Qualità nonché l emissione di adeguati reports con periodicità trimestrale. In relazione al FRT, alla classe di gravità ed al tempo impiegato per comunicare la risoluzione dell anomalia, vengono definiti i valori di soglia che identificano i Livelli di Servizio (SLA Service Level Agreement), riportati nella seguente tabella : Classe di gravità Descrizione Valori di Soglia 1. Altissima L intera applicazione è indisponibile agli utenti 2. Alta Funzionalità critiche dell applicazione sono indisponibili agli utenti 6 ore nel 98% dei casi; 8 ore nel restante 2% 6 ore nel 98% dei casi; 12 ore nel restante 2% Capitolato tecnico 21 luglio 2015 Pag. 13

14 Classe di gravità Descrizione Valori di Soglia 3. Media Funzionalità non critiche dell applicazione sono indisponibili agli utenti 12 ore nel 98% dei casi; 32 ore nel restante 2% 4. Bassa Funzionalità non critiche dell applicazione sono indisponibili agli utenti, ma non c è impatto sull immediata operatività 24 ore nel 98% dei casi; 72 ore nel restante 2% Inoltre, allo scopo di rendere misurabile la qualità del servizio di Manutenzione correttiva, l Amministrazione si riserva di utilizzare tutti o parte degli indicatori riportati nel successivo paragrafo 3.11 Qualità della fornitura 2, compresi i relativi livelli di servizio e penali che si intendono aggiuntivi rispetto a quelli riportati nel seguito del Capitolato. Nel caso in cui per parte di tali indicatori o livelli di servizio o penali aggiuntive si rilevino aspetti di sovrapposizione, divergenza o conflitto nell ambito di altre sezioni del Capitolato, si intendono sempre validi i criteri più favorevoli per l Amministrazione Manutenzione Evolutiva ed Adeguativa La manutenzione evolutiva (MEV) è una componente essenziale del progetto in quanto volta ad assicurare la futura rispondenza del software realizzato alle esigenze dell utente. Comprende tutti quegli interventi di evoluzione del sistema che si potranno rendere necessari per far fronte a nuove esigenze, quali, a titolo di esempio: adeguamento della soluzione tecnica a fronte di innovazioni normative e/o organizzative ; adeguamento della soluzione tecnica alle modifiche introdotte dagli Enti esterni sulla struttura dei dati dei flussi informativi scambiati ; adeguamento della soluzione tecnica in relazione a mutate esigenze degli utenti in un quadro di invarianza delle caratteristiche tecniche e funzionali di base degli obiettivi primari delle applicazioni. La MEV sarà erogata concordando con l Amministrazione le opportune variazioni al Piano di progetto, ogni qualvolta nuove esigenze comportino variazioni alla soluzione tecnica già realizzata. La manutenzione adeguativa (MAD) è volta ad assicurare la costante aderenza delle procedure e dei programmi alla evoluzione dell'ambiente tecnologico ed organizzativo del sistema informativo, come ad esempio l innalzamento dei livelli di software di base o l introduzione di nuove apparecchiature, in un contesto generale di compatibilità con l esistente. 2 estratti dalle Linee guida CNIPA sulla qualità dei prodotti e servizi ICT per la definizione e il governo dei contratti della Pubblica Amministrazione Capitolato tecnico 21 luglio 2015 Pag. 14

15 Allo scopo di rendere misurabile la qualità totale dei servizi offerti di MEV e MAD, l Amministrazione si riserva di utilizzare tutti o parte degli indicatori riportati nel successivo paragrafo 3.11 Qualità della fornitura, compresi i relativi livelli di servizio e penali che si intendono aggiuntivi rispetto a quelli riportati nel seguito del Capitolato. Nel caso in cui per parte di tali indicatori o livelli di servizio o penali aggiuntive si rilevino aspetti di sovrapposizione, divergenza o conflitto nell ambito di altre sezioni del Capitolato, si intendono sempre validi i criteri più favorevoli per l Amministrazione Conduzione di progetto Le caratteristiche del progetto richiedono di impostare e di avviare modalità di Project Management che permettano un pieno controllo del progetto stesso. La funzione di Project Management (i.e. Direzione Lavori) dovrà identificare attività da svolgere, priorità, tempi, risorse, verificare il completamento delle attività nonché garantire l integrazione tra tutte le componenti del progetto, la gestione del rischio e le eventuali ripianificazioni. L Amministrazione si riserva di individuare una figura preposta allo svolgimento di funzioni di auditing (da affiancare alla Direzione Lavori) al fine di assicurare il corretto feedback utente rispetto alle specifiche funzionali riportate nel seguito. Dovrà essere prevista dal Fornitore una figura di Project Manager (Capo Progetto) a coordinamento di tutte le attività, il quale avrà la piena responsabilità dei rapporti con l Amministrazione, assumendo quindi il ruolo di Direttore Lavori per il Fornitore. Entro il termine di 10 (dieci) giorni solari a decorrere dalla data di efficacia del contratto, il Fornitore comunicherà all Amministrazione il nominativo del Project Manager responsabile delle attività contrattuali a cui l Amministrazione stessa, per il tramite del proprio Direttore dell esecuzione del contratto, farà riferimento per ogni aspetto riguardante l esecuzione delle attività contrattuali. La nomina del Project Manager sarà sottoposta all approvazione dell Amministrazione che potrà richiedere di effettuare un incontro conoscitivo e che avrà facoltà, a suo insindacabile giudizio, di rifiutare la nomina richiedendo al Fornitore la proposta di un nuovo candidato. Si precisa altresì che la tipologia delle attività da svolgere e la complessità della materia trattata richiedono che tutte le attività siano improntate ad una assoluta attenzione alla riservatezza Assistenza sistemistica/data base administration Il servizio di assistenza sistemistica serve a supportare l Amministrazione nelle fasi di ottimizzazione, gestione e tuning delle risorse hardware e software di base. Fornisce inoltre il necessario supporto all interno del progetto di sviluppo, collaborando al disegno dell'architettura del sistema per ciò che concerne il sistema operativo, le interazioni fra software e hardware sia a livello centrale che periferico nonché la definizione delle interfacce tra sottosistemi diversi. Il servizio di Data Base Administration serve a supportare l Amministrazione nella gestione del DBMS, curandone l ottimizzazione, il dimensionamento, il tuning e gli aspetti di sicurezza e di recovery. Fornisce Capitolato tecnico 21 luglio 2015 Pag. 15

16 inoltre il necessario supporto all interno del progetto di sviluppo, collaborando alla progettazione logica e fisica delle basi di dati. I servizi potranno essere forniti anche da remoto, concordando con l Amministrazione le procedure di accesso al fine di garantire comunque l integrità, la riservatezza e la sicurezza delle informazioni contenute nei sistemi. 3.4 Piano di Progetto Si richiede di fornire un Piano di Progetto secondo i termini stabiliti dal contratto, che comprenda almeno le seguenti componenti: GANTT di Progetto, nel quale siano rappresentate le attività di progetto organizzate per Fasi ed Obiettivi, con esplicitazione dei tempi e delle milestones; Piano di Base del Progetto che, per ogni attività, ne evidenzi le milestones principali, le metodologie e gli strumenti di monitoraggio utili a verificarne l andamento; Piano di Dettaglio delle Attività che contenga per ogni attività/obiettivo, i tempi, i prodotti previsti, le risorse coinvolte, eventuali criticità e potenziali azioni da intraprendere; Piano dei rilasci che contenga il dettaglio relativo ai rilasci, le relative modalità operative ed i servizi a supporto. All interno del suddetto Piano dei Rilasci saranno individuati anche : Analisi funzionale del Nuovo Sistema; Analisi Dati del Nuovo Sistema; Documentazione utente; Piano di comunicazione e formazione Stato avanzamento lavori Rendicontazione risorse Esercizio garanzia: le modalità con le quali il Fornitore assicurerà all Amministrazione la prevista garanzia Il Fornitore, entro e non oltre il termine di 5 (cinque) giorni lavorativi dalla data di inizio delle attività, dovrà consegnare all Amministrazione il Piano di Progetto ed il Piano di Qualità. L Amministrazione, entro 10 (dieci) giorni lavorativi dalla consegna del Piano di Progetto e del Piano di Qualità, procederà all approvazione, per il tramite del Direttore dell esecuzione del contratto, e comunicherà al Fornitore la propria approvazione in merito ai suddetti documenti. Il Piano di Progetto sarà oggetto di consolidamento, revisione ed approvazione da parte dell Amministrazione in fase di esecuzione del progetto con cadenza trimestrale. Capitolato tecnico 21 luglio 2015 Pag. 16

17 Entro 5 (cinque) giorni lavorativi dalla scadenza di ogni trimestre, il Fornitore si impegna a sottoporre all approvazione dell Amministrazione l aggiornamento del Piano di Progetto, ivi compreso lo stato di avanzamento lavori, eventuali ripianificazioni e la rendicontazione delle risorse impiegate per le relative attività svolte nell arco del trimestre. Entro 5 (cinque) giorni lavorativi dalla scadenza di ogni trimestre verrà sottoposto all approvazione dell Amministrazione anche il Piano di Qualità, qualora quest ultimo sia oggetto di modifica. Entro i 10 (dieci) giorni lavorativi successivi alla consegna, l Amministrazione procederà all approvazione, per il tramite del Direttore dell esecuzione del contratto, del documento aggiornato e ne darà comunicazione al Fornitore. In caso di richieste da parte dell Amministrazione di modifiche/integrazioni, il Fornitore dovrà aggiornare il relativo documento nel termine di 5 (cinque) giorni lavorativi dalla comunicazione, pena l applicazione delle penali indicate nel seguito. 3.5 Pianificazione delle attività La data di inizio delle attività sarà comunicata dall Amministrazione al Fornitore ed il Fornitore è obbligato ad iniziare la prestazione dei previsti servizi entro tale data. Entro la data di inizio delle attività, l Amministrazione comunicherà al Fornitore il nominativo del proprio Direttore dell esecuzione del contratto. Il Piano di Progetto dovrà recepire e, possibilmente, migliorare le tempistiche riportate nel successivo paragrafo. 3.6 Tempistica del progetto Il Progetto dovrà essere articolato su 3 Fasi principali (tra loro parallelizzabili), i cui completamenti identificano le milestones sulle quali dovrà basarsi la tempistica del Piano di Progetto, includendo le opportune fasi intermedie ed i rilasci volti a garantire la funzionalità ed il controllo del progetto stesso durante l esecuzione. Il dettaglio relativo al contenuto dei rilasci, le relative modalità operative ed i servizi a supporto devono essere descritti nel Piano dei Rilasci. I termini sono indicati rispetto alla data di inizio lavori e sono da intendersi espressi in gg solari. FASE 1 (entro il termine di 60 gg dalla data di inizio lavori) Progettazione architettura tecnica Progettazione Architettura Applicativa (Analisi funzionale, Analisi dati, documentazione utente); Progettazione del Piano di Comunicazione e Formazione; Piano dei Test e del Collaudo Capitolato tecnico 21 luglio 2015 Pag. 17

18 Successivamente all approvazione di quanto sopra, si darà luogo alla successiva fase 2. FASE 2 (da concludere entro il termine di 210 gg dalla data di inizio lavori) Predisposizione del sistema (consolidamento delle piattaforme di produzione, sviluppo e collaudo per l intero ambiente operativo); Codifica (Sviluppo, parametrizzazione, test del software e della documentazione tecnica/utente); Migrazione dei dati dal sistema attuale al Nuovo Sistema (utilizzando sistemi alimentanti automatici e/o attraverso apposite procedure all uopo sviluppate e/o manualmente con attività di data - entry); Collaudo; Avvio in esercizio del Nuovo Sistema; Erogazione della formazione e relativo supporto. FASE 3 (fino alla conclusione del contratto) Erogazione dei servizi contrattualmente previsti tramite interventi di Conduzione ed assistenza sistemistica, Manutenzione Correttiva, Adeguativa ed Evolutiva. I servizi saranno oggetto di validazione trimestrale tramite reporting sul mantenimento degli SLA. 3.7 Prodotti da rilasciare I prodotti da rilasciare, previsti dal progetto, saranno sottoposti a consegna e/o approvazione e/o accettazione formale da parte dell Amministrazione, per il tramite del Direttore dell esecuzione del contratto secondo quanto contrattualmente previsto. 3.8 Approvazione Per attività di approvazione si intende il processo formale di verifica e validazione dei prodotti realizzati, ivi compresi i previsti rilasci documentali, da parte dell Amministrazione sulla base delle verifiche effettuate dal Direttore dell esecuzione del contratto e/o della Commissione di Collaudo. I prodotti previsti per approvazione nel Capitolato Tecnico dovranno essere consegnati secondo le modalità ed i termini previsti dal Piano di Progetto approvato e dovranno risultare conformi alle prescrizioni del Piano di Qualità. Entro 15 (quindici) giorni lavorativi dalla data di consegna l Amministrazione, sentito il Direttore dell esecuzione del contratto, comunicherà al Fornitore le proprie determinazioni in ordine all approvazione. Il termine per la comunicazione delle determinazioni s interromperà nel caso in cui l Amministrazione contesti per iscritto al Fornitore la sussistenza di anomalie che non consentano lo svolgimento dell attività Capitolato tecnico 21 luglio 2015 Pag. 18

19 di verifica. Il termine decorrerà ex - novo dall eliminazione delle anomalie, a totale carico del Fornitore, comunque non oltre 5 (cinque) giorni lavorativi dalla contestazione. Nell ipotesi di perdurante sussistenza delle anomalie, l Amministrazione avrà facoltà di dichiarare risolto il contratto senza che il Fornitore possa accampare alcun diritto. 3.9 Accettazione Par accettazione si intende la formalizzazione dell esito positivo delle attività di collaudo. Il Nuovo Sistema oggetto della fornitura verrà sottoposto a collaudo di accettazione da parte dell Amministrazione, in contradditorio con il Fornitore, secondo quanto indicato nei rispettivi Piani di Test. Il Collaudo verrà eseguito dalla Commissione di Collaudo che produrrà un verbale riportante le operazioni effettuate e l esito del Collaudo stesso; le operazioni di collaudo dovranno iniziare e concludersi entro i termini indicati nel Piano di Progetto approvato. Il Collaudo si intenderà positivamente superato solo se la soluzione informatica realizzata risulterà correttamente funzionante secondo i requisiti riportati nel Capitolato Tecnico e l analisi funzionale/dati definite nel Piano dei Rilasci approvato dall Amministrazione. In caso di esito negativo del Collaudo, il Fornitore avrà a disposizione, a decorrere dalla data di consegna del verbale, i successivi 15 (quindici) giorni per rimuovere, senza alcun onere aggiuntivo per l Amministrazione, i vizi e le difformità riscontrati dalla Commissione e riportati nel verbale. In tale ipotesi l Amministrazione procederà nuovamente al Collaudo non prima che siano trascorsi i predetti 15 (quindici) giorni e non oltre i successivi 10 (dieci) giorni. Nell ipotesi in cui anche il secondo Collaudo dia esito negativo, l Amministrazione, ferma restando la facoltà di applicare le penali e sempre che il Fornitore non si trovi in situazione di forza maggiore, dovrà assegnare al Fornitore un nuovo termine, non inferiore a 15 (quindici) giorni, per l eliminazione delle anomalie. Successivamente alla scadenza di tale termine l Amministrazione, nei 15 (quindici) giorni successivi, dovrà effettuare un nuovo Collaudo e, qualora dalle operazioni dello stesso risulti la perdurante sussistenza delle anomalie, avrà facoltà di dichiarare risolto il contratto senza che il Fornitore possa accampare alcun diritto. I prodotti oggetto di formale approvazione da parte del Direttore dell esecuzione del contratto sono : piano di progetto; piano di qualità; analisi funzionale/analisi dati; documentazione utente; piano di comunicazione e formazione; piano di assistenza ed affiancamento; piano di collaudo Capitolato tecnico 21 luglio 2015 Pag. 19

20 Il prodotto oggetto di formale accettazione da parte della Commissione di Collaudo sarà il Nuovo Sistema informatico per la gestione di accertamenti contributi. Non saranno soggetti ad accettazione o approvazione formale ma solo al processo di consegna: documenti che misurano l efficacia ed efficienza delle attività; altri prodotti connessi al ciclo di vita del software; disegno di dettaglio; specifiche di test; codice sorgente; codice di test e collaudo. Tutta la documentazione sarà redatta utilizzando prodotti della suite Microsoft Office (compreso Microsoft Project) e consegnata esclusivamente su supporto digitale, anche nel formato sorgente di ogni singolo tool utilizzato Base Informativa di Progetto Allo scopo di garantire all Amministrazione la sincronia dei documenti di progetto e la contestuale verifica delle attività contrattualmente previste, il Fornitore si obbliga a rendere disponibile su apposito server la Base Informativa documentale di Progetto, utilizzando un apposito gestore documentale, anche open source. Il Fornitore si obbliga, altresì, ad acquisire digitalmente tutti gli atti cartacei comunque prodotti e rilevanti ai fini del contratto stesso. L aggiornamento della Base Informativa documentale di Progetto dovrà avvenire entro il termine di 5 gg lavorativi dall approvazione di ogni singolo documento Qualità della fornitura La qualità della fornitura dovrà essere assicurata tramite l applicazione del Piano di Qualità per il progetto. Si richiede in fase di offerta, una proposta di Piano di Qualità soggetto a valutazione da parte dell Amministrazione. Il Piano di Qualità costituirà il riferimento per le attività di verifica e validazione svolte dal Fornitore all interno dei propri gruppi di lavoro, e dal gruppo di lavoro dell Amministrazione incaricato degli adempimenti contrattuali di consegna, approvazione e accettazione. Inoltre, allo scopo di rendere misurabile la qualità totale dei servizi previsti, l Amministrazione si riserva di utilizzare tutti o parte degli indicatori riportati nel seguito, estratti dalle Linee guida CNIPA sulla qualità dei prodotti e servizi ICT per la definizione e il governo dei contratti della Pubblica Amministrazione alla voce Capitolato tecnico 21 luglio 2015 Pag. 20

21 Classi di fornitura per: Sviluppo e MEV di software ad hoc (SSW), compresi i relativi livelli di servizio e penali che si intendono aggiuntivi rispetto a quelli riportati nel Capitolato. Nel caso in cui per parte di tali indicatori o livelli di servizio o penali aggiuntive si rilevino aspetti di sovrapposizione, divergenza o conflitto nell ambito di altre sezioni del Capitolato, si intendono sempre validi i criteri più favorevoli per l Amministrazione. Capitolato tecnico 21 luglio 2015 Pag. 21

22 Indicatore 1: Densità dei test rispetto alla dimensione del sw (analisi) TSTD Classe di fornitura Caratteristica /Sottocaratteristica Indicatore/Misura Sistema di gestione delle misure Unità di misura Dati elementari da rilevare Periodo di riferimento Frequenza esecuzione misure Regole di campionamento Formula di calcolo Regole di arrotondamento Obiettivi (valori soglia) SVILUPPO E MEV DI SOFTWARE AD HOC Funzionalità / Accuratezza Densità dei test rispetto alla dimensione del sw (analisi) TSTD L obiettivo è quello di verificare che la progettazione dei test funzionali e di integrazione, per i test che devono essere documentati e consegnati (specifiche di test), preveda una copertura minima delle condizioni di test (esempio condizione positive, condizione non valida, condizioni negative) e di utilizzo che ogni singola funzione può possedere, misurando il numero complessivo dei test progettati rispetto al numero di function point del software (opzione 1), o in loro assenza, al numero di funzionalità elementari (opzione 2). Questo indicatore è da utilizzare in fase di approvazione del piano e delle specifiche di test, al termine della fase di progettazione. Ha lo scopo primario di validare l attività di progettazione del test sotto l aspetto della copertura e dei volumi richiesti, mentre la valutazione del livelli minimi di copertura dei test rispetto ai requisiti si considera esaurita in fase di approvazione delle specifiche. E limitato ai soli test funzionali e di integrazione. La rilevazione può essere fatta durante l analisi delle specifiche di test, in validazione al termine della fase di analisi, o con gli appositi tool di test management utilizzati. TSTD = percentuale. - Dimensioni in function point (FP) delle applicazioni a inizio del periodo di osservazione (Ntotale_FP), metodo di conteggio: IFPUG ultima versione. La rilevazione è manuale. Il conteggio deve essere fatto da una risorsa che sia CFPS (Certified Function Point Specialist) del metodo di conteggio IFPUG. - Numero totale di funzionalità elementari definite nelle Specifiche o in altra documentazione (piano di test) (Nfunz) - Numero totale dei test funzionali e di integrazione sviluppati sulle funzionalità elementari (Ntest_funz). La durata della fase di analisi Una volta, al termine del periodo di riferimento NA TSTD = (Ntest_funz / (Ntotale_FP ^ 1.2)) x 100 esempio: sono stati sviluppati e documentati 350 casi di test per 500 FP previsti. Ntotale_FP ^ 1.2 = 500 ^1.2 = (arrotondato all intero) TSTD = (350 / 1733) x 100 = 20% Il risultato della misura va arrotondato al punto % intero: - per difetto se la parte decimale è <= 0,5 - per eccesso se la parte decimale è > 0,5 Un indice di riferimento è il rapporto numero di casi di test = function point ^1,2 (fonte Caper Jones), che prevede una crescita sempre maggiore del numero di test rispetto all aumentare del numero di function point, per rispondere adeguatamente alla maggior complessità che deriva dall aumento delle dimensioni del software. Il rapporto casi di test = function point ^1,2 può essere usato per riferirsi ad un modello di crescita esponenziale del numero dei test, bisogna ad esempio considerare le specifiche Capitolato tecnico 21 luglio 2015 Pag. 22

23 Classe di fornitura Caratteristica /Sottocaratteristica Indicatore/Misura Azioni contrattuali Eccezioni SVILUPPO E MEV DI SOFTWARE AD HOC Funzionalità / Accuratezza Densità dei test rispetto alla dimensione del sw (analisi) TSTD categorie di sviluppo software, come ad esempio le applicazioni web o di data warehouse, dove il numero di test potrebbe non essere direttamente collegabile ai function point. Nell ambito della metrica si considerano solo i test funzionali e di integrazione oggetto di pianificazione e la parte rappresentativa degli stessi che deve essere documentata e consegnata all Amministrazione, in modo da garantirne il futuro riutilizzo. Si considera accettabile una soglia del 10-20% sul rapporto numero di test = function point ^1,2, da variare a seconda della criticità dell applicazione, con un valore minimo di 1 test per function point. N.totale Function N. test totali (FP 10% Test Documentati 20% Test Documentati Point ^1.2) 10% Valore di 20% Valore di Test soglia Test soglia E importante che la definizione del test, dei suoi confini e dimensioni, sia univoca e condivisa all interno del progetto, affinchè sia possibile utilizzare l indicatore correttamente. Il raggiungimento del valore soglia conferma l accettazione del prodotto; in mancanza si attiva la richiesta di revisione e riedizione del piano e delle specifiche di test entro un termine da stabilire. Se il numero di test definiti risulta inferiore alla soglia impostata, significa che la copertura del test è inadeguata; la copertura del test è un indicatore diretto del potenziale numero di difetti rilevabili durante il test e successivamente al collaudo, quindi del potenziale aumento dei costi della non qualità (manutenzione correttiva, perdita di produttività, danno all immagine, ecc.). Le eccezioni riguardano quelle tipologie di forniture di sviluppo software dove non sia possibile o coerente l utilizzo della metrica dei FP o della scomposizione funzionale. In questi casi la metrica potrà essere rivista sulla base delle diverse tecniche utilizzate per il dimensionamento del software o della fornitura. Capitolato tecnico 21 luglio 2015 Pag. 23

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

25 Classe di fornitura Caratteristica /Sottocaratteristica Indicatore/Misura SVILUPPO E MEV DI SOFTWARE AD HOC Affidabilità / maturità Difettosità NDIF stesso presenti inconvenienti in esercizio; si può ad es. fare riferimento alla seguente classificazione Classe di criticità Descrizione Sanzioni civili e penali, consistenti perdite economiche, gravi ripercussioni sull immagine Interruzione del servizio con conseguenti danni economici e di immagine Perdite moderate, facilmente recuperabili Perdite scarse, facilmente recuperabili Inconvenienti lievi Valore soglia errori bloccanti (es.) Valore soglia errori non bloccanti (es.) 0,01% 0,5% 0,1% 1% 0,2% 2% 0,5% 5% 1% 5% Azioni contrattuali Eccezioni Il superamento dei valori di soglia comporta l applicazione di una penale da determinare come % del corrispettivo, in funzione della classe di criticità e della tipologia di errore. L applicazione delle regole contrattuali può iniziare dopo un periodo di osservazione dall inizio dell avviamento/diffusione (esempio, della durata di 1-2 mesi). Indicatore 3: Complessità ciclomatica COC Classe di fornitura Caratteristica /Sottocaratteristica Indicatore/Misura Sistema di gestione delle misure Unità di misura Dati elementari da rilevare Periodo di riferimento Frequenza esecuzione misure Regole di SVILUPPO E MEV DI SOFTWARE AD HOC Manutenibilità / modificabilità Complessità ciclomatica COC Tale indicatore misura la complessità della struttura di controllo di un modulo software. La rilevazione è fatta tramite tool automatici di misura specifici per il linguaggio di programmazione utilizzato. Numero. - Numero di archi del grafo. - Numero di nodi del grafo. - Numero di componenti software connesse. NA NA NA Capitolato tecnico 21 luglio 2015 Pag. 25

26 Classe di fornitura Caratteristica /Sottocaratteristica Indicatore/Misura campionamento Formula di calcolo Regole di arrotondamento Obiettivi (valori soglia) Azioni contrattuali Eccezioni SVILUPPO E MEV DI SOFTWARE AD HOC Manutenibilità / modificabilità Complessità ciclomatica COC L algoritmo di calcolo è il seguente: COC = E N + p dove E = numero di archi del grafo del modulo; N = numero di nodi del grafo del modulo; p = numero di componenti software connesse. Intero più prossimo. COC < 21 Il superamento dei valori di soglia comporta l applicazione di una penale compresa tra lo 0,05 % e lo 0,5 % del corrispettivo del software per ogni unità in aumento rispetto al valore di soglia. NA Indicatore 4: Livello di documentazione LDO Classe di fornitura Caratteristica /Sottocaratteristica Indicatore/Misura Sistema di gestione delle misure Unità di misura Dati elementari da rilevare Periodo di riferimento Frequenza esecuzione misure Regole di campionamento Formula di calcolo Regole di SVILUPPO E MEV DI SOFTWARE AD HOC Manutenibilità / modificabilità Livello di documentazione LDO Tale indicatore misura la quantità dei commenti presenti in un modulo software. La rilevazione è fatta tramite tool automatici di misura specifici per il linguaggio di programmazione utilizzato. Percentuale. Numero di Line Of Code (LOC). Numero di linee di commento. NA NA NA L algoritmo di calcolo è il seguente: LDO = LC/LOC dove LC = numero delle linee di commento; LOC = numero delle linee di codice; Il valore di LDO va espresso in percentuale. Intero più prossimo. Capitolato tecnico 21 luglio 2015 Pag. 26

27 Classe di fornitura Caratteristica /Sottocaratteristica Indicatore/Misura arrotondamento Obiettivi (valori soglia) Azioni contrattuali Eccezioni SVILUPPO E MEV DI SOFTWARE AD HOC Manutenibilità / modificabilità Livello di documentazione LDO 25% < LDO Il superamento dei valori di soglia comporta l applicazione di una penale compresa tra lo 0,1 e lo 0,5 % del corrispettivo del software per ogni unità in diminuzione rispetto al valore di soglia. NA Capitolato tecnico 21 luglio 2015 Pag. 27

28 Indicatore 5: Facilità d uso FUSO Classe di fornitura Caratteristica /Sottocaratteristica Indicatore/Misura Sistema di gestione delle misure Unità di misura Dati elementari da rilevare Periodo di riferimento Frequenza esecuzione misure Regole di campionamento Formula di calcolo Regole di arrotondamento Obiettivi (valori soglia) Azioni contrattuali Eccezioni SVILUPPO E MEV DI SOFTWARE AD HOC Usabilità / Operabilità Facilità d uso FUSO L indicatore misura la capacità di supportare l utente nella sua operatività. Le informazioni necessarie vengono rilevate da un campione selezionato di utenti finali. La raccolta delle informazioni avviene tramite analisi delle risposte inseriti in opportuni questionari distribuiti al campione prescelto. Percentuale Voto (in una scala predefinita) attribuito a ciascuna risposta del questionario Durante la fase di analisi, se applicato al prototipo, durante la fase di consegna e collaudo se applicato alla documentazione utente. La misura viene effettuata ad ogni riedizione del prodotto. Per ogni applicazione e per ogni profilo utente deve essere inserito nel campione almeno un utente per ogni livello professionale. Se possibile utilizzare criteri di stratificazione degli utenti. Dati necessari: numero utenti soddisfatti (USOD), per ogni applicazione numero utenti selezionati (USEL), per ogni applicazione FUSO USOD 100 USEL Un utente viene considerato soddisfatto se la percentuale pesata di risposte positive al questionario è superiore alla soglia stabilita. Il peso attribuito ad ogni risposta tiene conto della importanza attribuita alla domanda. Il valore percentuale va arrotondato alla cifra intera. FUSO 70 nella fase di analisi FUSO 90 nella fase di consegna e collaudo Il raggiungimento del valore soglia conferma l accettazione del prodotto; in mancanza si attiva la richiesta di revisione. NA Indicatore 6: Efficienza di rimozione errori RERR Classe di fornitura Caratteristica /Sottocaratteristica Indicatore/Misura SVILUPPO E MEV DI SOFTWARE AD HOC Affidabilità / ripristinabilità Efficienza di rimozione errori RERR Capitolato tecnico 21 luglio 2015 Pag. 28

29 Classe di fornitura Caratteristica /Sottocaratteristica Indicatore/Misura Sistema di gestione delle misure Unità di misura Dati elementari da rilevare Periodo di riferimento Frequenza esecuzione misure Regole di campionamento SVILUPPO E MEV DI SOFTWARE AD HOC Affidabilità / ripristinabilità Efficienza di rimozione errori RERR Verrà utilizzato lo stesso sistema di gestione della rilevazione dei difetti con la componente aggiuntiva di registrazione degli interventi di rimozione, dei tempi impegnati e relativo esito. Il sistema si applica sia alle attività di nuovo sviluppo sia agli interventi di MEV. Il sistema dovrà essere in grado di raccogliere ed elaborare i dati elementari in particolare nell arco temporale relativo all avviamento / diffusione / garanzia. La rilevazione può essere fatta in modalità mista con appositi tool di defects tracking e trouble ticketing 3. RERRBL, RERRNBL = percentuale. T = ora Nr malfunzioni rilevate per Tipo; Nr interventi di rimozione effettuati con esito positivo; Tempo di rimozione e ripristino. Nel corso dell avviamento / diffusione. In base alle caratteristiche dell applicazione può essere stabilita la frequenza di misura nell arco temporale dell avviamento / diffusione. NA Malfunzioni rimosse nel tempo limite (valori espressi come percentuale): RERRBL= MBL rimossi / MBL rilevati Formula di calcolo Regole di arrotondamento Obiettivi RERRNBL= MNBL rimossi /MNBL rilevati dove: MBL rimossi/rilevati = numero totale delle Malfunzioni Bloccanti rimosse nel tempo limite / rilevate nel periodo di osservazione; MNBL rimossi/rilevati = numero totale delle Malfunzioni Non Bloccanti rimosse nel tempo limite / rilevate nel periodo di osservazione; Tempo di rimozione e ripristino T = D-fi - D-in D-in= data/ora inizio intervento eseguito nel tempo limite D-fi= data/ora fine intervento eseguito nel tempo limite Gli indicatori esposti possono essere misurati distintamente per ciascuna Classe di criticità, come individuata ai fini dell indicatore DIFETTOSITA NDIF. La percentuale va arrotondata al primo decimale. L obiettivo è quello di tenere sotto controllo l efficienza e l efficacia del periodo di 3 Nel caso di MEV, anche se contrattualmente il Fornitore non è considerato responsabile e non deve rispondere delle anomalie presenti nel prodotto realizzato da altri, la rilevazione deve essere effettuata e resa disponibile prontamente all interfaccia indicata dalla Stazione appaltante, per consentire a questa ogni possibile intervento utile a valutare prontamente e eventualmente a ripristinare il livello atteso della qualità del servizio. È presupposto a ciò la corretta individuazione delle responsabilità associate al funzionamento delle singole componenti, che deve essere naturalmente gestito nell ambito del sistema di Configuration Management (vedasi Manuale di riferimento - modelli per la qualità delle forniture ICT 5.4. Processi di supporto). Capitolato tecnico 21 luglio 2015 Pag. 29

30 Classe di fornitura Caratteristica /Sottocaratteristica Indicatore/Misura (valori soglia) SVILUPPO E MEV DI SOFTWARE AD HOC Affidabilità / ripristinabilità Efficienza di rimozione errori RERR avviamento / diffusione monitorando la tempestività di intervento a fronte di malfunzionamenti. Valori soglia: RERRBL 98% con tempo limite = 3-4 ore. Il restante 2% dei casi deve essere risolto nel tempo limite = 6 12 ore. RERRNBL 95% con tempo limite = 4 12 ore; il restante 5% dei casi deve essere risolto nel tempo limite = ore. Azioni contrattuali Eccezioni I valori soglia comunque dipendono dalla criticità delle applicazioni; inoltre il valore della % di rimozione fa riferimento alla misura a fine avviamento / diffusione riferita all intero arco temporale. I malfunzionamenti bloccanti riscontrati nel periodo coperto da garanzia devono comunque essere tutti rimossi. Valori misurati della % di rimozione al di sotto dei valori di soglia comportano l applicazione di una penale da determinare come % del corrispettivo, orientativamente compresa tra lo 0,1% e l 1% per ogni punto percentuale, in funzione della classe di criticità, della tipologia di errore e dell entità dello scostamento. L applicazione delle regole contrattuali può iniziare dopo un periodo di osservazione dall inizio dell avviamento / diffusione (esempio, della durata di 1-2 mesi) Garanzia Il Fornitore, senza oneri aggiuntivi per l Amministrazione, dovrà fornire la garanzia sul Nuovo Sistema per la durata di 24 (ventiquattro) mesi, a decorrere dalla data di accettazione del Nuovo Sistema, con modalità tali da evitare all Amministrazione interruzioni del servizio, da prevedere esplicitamente nel Piano dei Rilasci. 4 Penali La somma delle penali applicabili non potrà eccedere, per tutta la Durata del Contratto, il 10% del valore del corrispettivo complessivo. Nel caso in cui la somma delle penali applicabili ecceda detto limite, l Amministrazione avrà facoltà di dichiarare la risoluzione in danno del Contratto. Inoltre, allo scopo di rendere misurabile la qualità totale dei servizi previsti, l Amministrazione si riserva di utilizzare tutti o parte degli indicatori riportati nel par Qualità della fornitura, compresi i relativi livelli di servizio e penali che si intendono aggiuntive rispetto a quelle riportate nel seguito. Capitolato tecnico 21 luglio 2015 Pag. 30

31 Nel caso in cui per parte di tali indicatori o livelli di servizio o penali aggiuntive si rilevino aspetti di sovrapposizione, divergenza o conflitto nell ambito di altre sezioni del Capitolato, si intendono sempre validi i criteri più favorevoli per l Amministrazione. Per l applicazione delle penali, si rimanda all apposita sezione del dettato contrattuale. 4.1 Penali per ritardata consegna Per ogni giorno lavorativo di ritardo nella comunicazione del nominativo del Project Manager del Fornitore potrà essere applicata una penale pari a 250,00. Per ogni giorno lavorativo di ritardo nell inizio delle attività rispetto alla data stabilita, nonché per ogni giorno lavorativo di ritardo nella consegna del Piano di Progetto e del Piano di Qualità, potrà essere applicata una penale pari a 500,00. Per ogni giorno lavorativo di ritardo nell aggiornamento del Piano di Progetto e/o del Piano di Qualità nell ipotesi in cui l Amministrazione, valutate le deduzioni del Fornitore, ne comunichi la mancata approvazione, potrà essere applicata una penale pari a 250,00. Per ogni giorno lavorativo di ritardo nel completamento previsto dal Piano di Progetto per le Fasi dalla 1 alla 3, potrà essere applicata una penale pari allo 0,2% del corrispettivo previsto per la Fase stessa. 4.2 Penali di mancato Collaudo Nell ipotesi in cui il Collaudo del Nuovo Sistema abbia dato esito negativo, l Amministrazione potrà applicare al Fornitore una penale di importo pari allo 0,5% del Corrispettivo complessivo per il Nuovo Sistema, per ogni giorno intercorrente fra la data del verbale di collaudo negativo e la data di accettazione del Nuovo Sistema. 4.3 Penali per mancato rispetto Livelli di Servizio Conduzione ed Assistenza sistemistica In relazione al livello di servizio richiesto, per ogni ora di indisponibilità della piattaforma oltre quelle previste (max 120 h/anno max 10 h/mese), verrà applicata una penale di 250, Penali per mancato rispetto Livelli di Servizio Manutenzione Correttiva In relazione al FRT rispetto a definiti valori di soglia, verranno applicate le penali secondo l algoritmo della seguente tabella, considerando un periodo di osservazione mensile a partire dal rilascio in esercizio del Nuovo Sistema fino al termine del Progetto: Capitolato tecnico 21 luglio 2015 Pag. 31

32 Classe Valori di Soglia 3 ore nel 98% dei casi; 6 ore nel restante 2% 4 ore nel 98% dei casi; 12 ore nel restante 2% 12 ore nel 98% dei casi; 32 ore nel restante 2% 24 ore nel 98% dei casi; 72 ore nel restante 2% Importo Penale Per ogni punto percentuale in diminuzione rispetto ai valori di soglia, nel periodo di osservazione 1% del valore contrattuale del servizio nel periodo di osservazione 0,5% del valore contrattuale del servizio nel periodo di osservazione 0,3% del valore contrattuale del servizio nel periodo di osservazione 0,2% del valore contrattuale del servizio nel periodo di osservazione 4.5 Penali per mancato rispetto Livelli di Servizio Addestramento e Formazione Per le attività di formazione saranno valutati i livelli di servizio relativi all efficacia delle tecnologie e delle metodologie didattiche : tramite questionario di verifica dell apprendimento a fine corso; misurando la percentuale di risposta positiva ai questionari compilati dai partecipanti, il cui risultato complessivo deve essere > 80% La penale applicata sarà pari all 1% del valore contrattuale del servizio nel periodo di osservazione, per ogni punto percentuale di scostamento in diminuzione rispetto ai valori di soglia. 4.6 Penali per mancato aggiornamento della Base Informativa di Progetto La penale applicata sarà pari allo 0,1% del valore contrattuale del servizio nel periodo di osservazione, per ogni giorno di ritardo rispetto al valore di soglia (5 gg) rappresentativo del livello di servizio. 5 Figure professionali previste Nell offerta dovranno essere indicati il numero delle figure professionali che verranno impiegate nel progetto e la quantificazione delle giornate uomo relative all impegno richiesto, valutate in funzione delle attività da svolgere. L Amministrazione si riserva la facoltà di verificare, in ogni momento dell esecuzione del progetto, la corrispondenza del mix di figure professionali effettivamente impiegate rispetto a quanto dichiarato dal Fornitore. Di seguito si riporta uno schema indicativo di caratteristiche minime richieste dall Amministrazione per le figure professionali e la stima del loro impiego per linea di attività. Capitolato tecnico 21 luglio 2015 Pag. 32

33 Oggetto di fornitura giorni uomo system integration e migrazione/porting 170 test e supporto al collaudo 50 assistenza avviamento e formazione 15 manutenzione correttiva/adeguativa/evolutiva per minimo 16 mesi 120 assistenza sistemistica/db per minimo 16 mesi 30 Totale Dettaglio delle figure professionali Figura professionale per i servizi di system integration e migrazione/porting % di impiego Capo progetto 10% Analista senior 30% Analista Programmatore 60% Figura professionale per i servizi di manutenzione adeguative/evolutiva % di impiego Capo progetto 5% Analista senior 30% Analista Programmatore 65% Figura professionale per i servizi di assistenza sistemistica/data Base Administration % di impiego Sistemista 70% Data Base Administrator 30% Capitolato tecnico 21 luglio 2015 Pag. 33

34 Figura professionale per i servizi di assistenza all avviamento e formazione % di impiego Capo progetto 10% Docente 90% Figura professionale per i servizi di test e supporto al collaudo % di impiego Capo Progetto 20% Analista senior 40% Analista Programmatore 40% Capo Progetto Titolo di studio Esperienze lavorative Ruolo Laurea in discipline economiche o tecniche Anzianità lavorativa di almeno 10 anni, con almeno 4 di provata esperienza lavorativa nella specifica funzione su progetti complessi. E particolarmente apprezzata, se abbinata ad esperienze anche in altri settori, la conoscenza del settore pubblico, preferibilmente nella Pubblica Amministrazione italiana. Coordina lo sviluppo dei progetti e ne dispone la realizzazione, eventualmente suddividendoli in moduli da assegnare agli analisti. E responsabile degli aspetti tecnici ed economici. Pianifica e organizza in generale l'attività delle risorse, verificando che vengano rispettate le specifiche relative a piano di lavoro, previsione dei costi e dei tempi. Mantiene i rapporti con l'utente onde prevedere anche possibili interventi atti a soddisfare esigenze potenziali nonché l'approvazione finale del progetto, assicurandosi che tutta la documentazione del prodotto sia completa ed esauriente. Riferisce periodicamente al committente sullo stato di avanzamento dei progetti evidenziando gli scostamenti dal piano e proponendo eventuali revisioni. Si fa portatore delle problematiche rilevate nel corso del progetto, propone opportune soluzioni e intraprende, d accordo con l Amministrazione, le necessarie azioni correttive anche per quanto riguarda gli aspetti connessi al sistema informatico. Analista senior Titolo di studio Laurea in discipline economiche o tecniche Capitolato tecnico 21 luglio 2015 Pag. 34

35 Esperienze lavorative Anzianità lavorativa di almeno 8 anni, con almeno 4 di provata esperienza lavorativa nella specifica funzione su progetti complessi. Sono particolarmente apprezzate: - l esperienza nel settore pubblico, preferibilmente nella Pubblica Amministrazione italiana, se abbinata ad esperienze anche in altri settori; - la conoscenza dei processi istruttori di provvedimenti amministrativi, dei principi, delle tecniche di controllo nonché di aspetti amministrativocontabili (contabilità finanziaria, economico-patrimoniale, processi di formazione dei bilanci pubblici); - la conoscenza, comprovata dalle esperienze pregresse, delle tecnologie di analisi strutturata e di tracciabilità dei requisiti proposte nell offerta tecnica Ruolo Disegna il modello dei dati e delle funzioni del sistema interfacciandosi costantemente con il Capo Progetto; verifica la coerenza tra i requisiti utente e le indicazioni dello sviluppo tecnico. Risolve in autonomia le problematiche relative a modelli dati e funzioni, nonché organizzative e tecnologiche allineandosi costantemente con il capo progetto e con il responsabile lato Amministrazione. Collabora attivamente con i programmatori ed il Capo progetto nella definizione delle soluzioni. Partecipa alla definizione del piano di attuazione dei moduli che gli verranno affidati fornendo una stima dei tempi e delle risorse necessari. Definisce e segue la realizzazione della documentazione operativa per l'utente e fornisce l'istruzione necessaria per l'utilizzo della procedura sviluppata; Analista Programmatore Titolo di studio Esperienze lavorative Diploma/Laurea in discipline tecniche Anzianità lavorativa di almeno 5 anni, almeno 2 anni di provata esperienza su progetti correlati all implementazione di soluzioni informatiche similari a quelle richieste dal progetto, anche basate su architetture web. E particolarmente apprezzata la conoscenza delle principali tecnologie di supporto in uso alla Pubblica Amministrazione descritte nel Capitolato Tecnico (PEC, protocollo, firma digitale, etc.). Ruolo Partecipa alla definizione delle specifiche di programmazione del progetto sulla base dell analisi. Provvede all'organizzazione e alla strutturazione delle basi di dati, dell'interfaccia utente e alla gestione degli archivi in accordo con le specifiche di progetto. Produce flow-chart. Può svolgere attività di documentazione e aggiornamento di procedure esistenti. Effettua la stesura di programmi originali e la revisione di quelli esistenti, conduce le prove pratiche di funzionamento dei programmi per la loro messa a punto finale. Capitolato tecnico 21 luglio 2015 Pag. 35

36 Sistemista Titolo di studio Esperienze lavorative Ruolo Diploma/Laurea in discipline tecniche Anzianità lavorativa di almeno 5 anni, almeno 2 anni di provata esperienza su progetti correlati all implementazione di soluzioni informatiche similari a quelle richieste dal progetto, anche basate su architetture web. Si occupa dell'ottimizzazione, gestione e tuning delle risorse hardware e software di base. Fornisce supporto all interno del progetto di sviluppo, collaborando al disegno dell'architettura del sistema per ciò che concerne il sistema operativo, le interazioni fra software e hardware sia a livello centrale che periferico, la definizione delle interfacce tra sottosistemi diversi. Installa, manutiene e gestisce il software di base e di sistema e tutte le interazioni con l'ambiente applicativo. Verrà valutato, inoltre, il possesso di certificazioni di integrazioni con la suite Oracle SOA 11G. Capitolato tecnico 21 luglio 2015 Pag. 36

37 Data Base Administrator Titolo di studio Esperienze lavorative Ruolo Diploma/Laurea in discipline tecniche Anzianità lavorativa di almeno 5 anni, almeno 2 anni di provata esperienza su progetti correlati all implementazione di soluzioni informatiche similari a quelle richieste dal progetto, anche basate su architetture web. Amministra il DBMS, curandone l ottimizzazione, il dimensionamento, il tuning e gli aspetti di sicurezza e di recovery. Può essere coinvolto anche nel progetto di sviluppo, fornendo supporto tecnico per la progettazione logica e fisica delle basi di dati. Verrà valutato, inoltre, il possesso di certificazioni di integrazioni con la suite Oracle SOA 11G. Docente Titolo di studio Esperienze lavorative Ruolo Diploma/Laurea in discipline tecniche Attività di docenza di almeno 5 anni su progetti correlati all implementazione di soluzioni informatiche similari a quelle richieste dal progetto, preferibilmente in ambito Pubblica Amministrazione. Eroga corsi di formazione al personale operativo del cliente sui prodotti/servizi oggetto delle forniture, assicurando il supporto necessario al fine di garantire la completa autonomia nell'utilizzo dei prodotti/servizi acquisiti. Capitolato tecnico 21 luglio 2015 Pag. 37

38 6 Analisi dei requisiti utente 6.1 Principali funzionalità Il Nuovo Sistema informatico per la gestione di Accertamenti e Contributi è lo strumento attraverso il quale la Divisione 4 della Direzione Generale per la Vigilanza sugli Enti, il sistema cooperativo e le gestioni commissariali (nel seguito DG) potrà esaminare la situazione contributiva delle cooperative, inviare comunicazioni in caso di cooperative inadempienti, gestire la fase interlocutoria relativa alle istanze presentate dalle cooperative ed, eventualmente, procedere alla fase di escussione del credito per il tramite di Agenzia delle Entrate/Equitalia. Il Nuovo Sistema consentirà altresì la gestione di eventuali ricorsi presentati dalle cooperative. Per lo svolgimento delle attività i funzionari ed il dirigente saranno supportati dalla possibilità di interrogare la base dati per estrarre tutte le informazioni necessarie al corretto svolgimento della propria attività. Le pratiche potranno essere assegnate ai vari funzionari secondo criteri parametrici; il Nuovo Sistema consentirà in maniera automatica la protocollazione dei documenti, l archiviazione nel sistema di gestione documentale, la firma digitale e l invio delle PEC. Il Nuovo Sistema interagirà con il portale cooperative attualmente in esercizio nonché con il sistema Parix- COSE e con il sistema di gestione della Divisione V Vigilanza FoliumCS - Sicoop Tutti i dati gestiti nell ambito del Nuovo Sistema saranno consultabili attraverso il sistema di reportistica della DG basato sul sistema SAS-VA, un ambiente dinamico, aggiornato quotidianamente, attraverso il quale sarà possibile consultare tutti i dati in uso alla DG ed, attraverso analisi e comparazioni, individuare criticità nell ambito dei vari processi. Le principali funzionalità supportate dal Nuovo Sistema sono: assegnazione pratiche sospensione pratiche invio/gestione accertamenti invio/gestione note di cortesia gestione Istanze tipizzazione delle istanze ed interazione con il portale cooperative tipizzazione delle comunicazioni pregresse importo non dovuto in quanto società non cooperativa importo non dovuto in quanto sede cooperativa in Regione a statuto speciale importo non dovuto in quanto aderente ad associazione Capitolato tecnico 21 luglio 2015 Pag. 38

39 pagamento effettuato e non registrato pagamento effettuato con anomalie compensabili istanza generica Modifiche moduli B/C17 d ufficio 4 Gestione ruoli iscrizioni a ruolo gestione ricorsi insinuazione passivo Tale elenco è da intendersi come insieme minimale di funzionalità che il Nuovo Sistema dovrà prevedere. Nei successivi paragrafi, ai fini di una maggiore chiarezza espositiva, sono riportate delle immagini rappresentanti ipotesi di videate del Nuovo Sistema. Tali immagini sono da considerarsi puramente indicative e non devono essere considerate né vincoli alla realizzazione del Nuovo Sistema né esaustive dei dati e delle funzionalità in esse riportate. 6.2 Struttura dei dati I dati nell ambito del Nuovo Sistema hanno una struttura composta da tre livelli (Entità), organizzati gerarchicamente: ad una Entità di livello superiore corrispondono una o più Entità di livello inferiore (rapporto 1 a N). 4 sulle modalità di ricezione, visualizzazione e gestione dei modelli contenenti i dati di bilancio delle società cooperative rilevanti per la determinazione dei contributi (ex mod. C17, attuale Mod. B) è in corso un attività di approfondimento da parte dell Amministrazione i cui risultati, qualora rilevanti per la realizzazione del Nuovo Sistema, saranno resi noti al Fornitore per il conseguente aggiornamento dei requisiti Capitolato tecnico 21 luglio 2015 Pag. 39

40 Entità Cooperativa Descrizione Al primo livello troviamo le cooperative, identificate univocamente dal proprio codice fiscale, ad ognuna delle quali corrisponde un fascicolo, da intendersi quale livello aggregativo superiore di tutte le pratiche ad essa relative. Comunicazioni Amministrazione Accertamento Al secondo livello abbiamo le comunicazioni dell amministrazione (ad es.: le note di cortesia, gli accertamenti). Un tipo particolare di comunicazione è costituito dagli accertamenti, ovvero dai provvedimenti attivati dall Amministrazione tesi al recupero di eventuali contributi non pagati. Istanza Le istanze collegate ad un accertamento corrispondono alle richieste presentate dalla cooperativa a fronte di tale comunicazione (generalmente tramite il portale Cooperative). Per ogni istanza presentata il funzionario responsabile attiva un processo istruttorio che può concludersi o con l accettazione dell istanza stessa o con il suo respingimento. Durante il processo istruttorio vi è una fase interlocutoria in cui l Amministrazione può richiedere ulteriori chiarimenti. Al termine dell istruttoria l istanza viene chiusa. Un accertamento si considera chiuso quando tutte le sue istanze sono chiuse Possono essere presentate dalle cooperative istanze spontanee, ovvero non corrispondenti ad alcuna comunicazione, oppure istanze in risposta ad altre comunicazioni da parte dell Amministrazione (ad es.: note di cortesia) Gli accertamenti vengono in generale attivati mediante una procedura periodica che verifica la situazione debitoria di ogni cooperativa e, in caso di differenza fra importo dovuto ed importo versato, provvede all invio dell accertamento. L accertamento non viene inviato automaticamente nel caso in cui, per la medesima cooperativa, esista già un accertamento aperto (i.e. la cooperativa non ha ottemperato al pagamento e/o sussistono istanze ancora in fase istruttoria) per lo stesso periodo contributivo. Capitolato tecnico 21 luglio 2015 Pag. 40

41 Esempio ABC Sociale Cooperativa n periodo n periodo Accertamento n. 872 Istanza di tipo A n. 913 Istanza Istanza di tipo B Le istanze presentate dalle cooperative saranno distinte per tipologia: ogni tipologia di istanza darà luogo ad attività diverse di aggiornamento della base dati. 6.3 Profilazione degli utenti Sicurezza Il Nuovo Sistema consentirà la gestione della sicurezza su 3 livelli: - Livello 1: accesso al sistema - Livello 2: accesso alle funzioni del sistema - Livello 3: accesso ai dati del sistema Capitolato tecnico 21 luglio 2015 Pag. 41

42 Livello 1: accesso al sistema Il Nuovo Sistema consentirà l accesso esclusivamente agli utenti autorizzati, che verranno dotati di proprie credenziali di accesso (utente e password). Livello 2: accesso alle funzioni del sistema Sulla base del profilo assegnato (funzionario/dirigente/direttore/amministratore di sistema) l utente sarà abilitato ad eseguire specifiche funzioni del Nuovo Sistema con specifiche modalità (sola visualizzazione/modifica/esecuzione). Livello 3: accesso ai dati del sistema Sulla base del profilo assegnato (funzionario/dirigente/direttore/amministratore di sistema) l utente sarà abilitato alla gestione di determinati dati presente sul Nuovo Sistema (ad es.: le cooperative di una determinata Regione) con specifiche modalità (sola visualizzazione/modifica/esecuzione). La gestione delle utenze e l assegnazione dei profili utenti sarà effettuabile dall amministratore di sistema. Tutte gli accessi alla base dati, effettuati sia in visualizzazione/stampa che in aggiornamento, nonchè le funzioni utilizzate e gli eventi significativi, verranno tracciati; mediante apposita reportistica fornita dal Nuovo Sistema, aggiuntiva rispetto al log applicativo, sarà possibile risalire agevolmente all utente che ha effettuato le suddette operazioni, con indicazione di data ed ora della relativa esecuzione Assegnazione pratiche Le pratiche verranno assegnate ai funzionari con criteri parametrizzabili (ad. es: round robin); il Nuovo Sistema metterà a disposizione apposite funzioni per la gestione e la parametrizzazione di dette assegnazioni. dovrà essere prevista una modalità di assegnazione manuale in deroga al criterio generale, ad uso esclusivo dell utente con profilo Dirigente. Nel caso di istanze che fanno riferimento alla stessa comunicazione da parte della cooperativa e/o allo stesso accertamento inviato dall amministrazione, l algoritmo di assegnazione le attribuirà preferibilmente allo stesso funzionario. Per ogni istanza aperta collegata ad un accertamento il Nuovo Sistema prevederà un avviso per il funzionario competente all approssimarsi della data di scadenza per il pagamento del contributo prevista sull accertamento medesimo Sospensione pratica L Amministratore del sistema, in casi eccezionali e previa autorizzazione del Dirigente, potrà sospendere una pratica (es. una istanza) per un numero di giorni variabile. Sarà possibile escludere dalla visualizzazione le pratiche sospese sino alla data prevista di fine sospensione. Una pratica sospesa è a tutti gli effetti una pratica ancora aperta. Per essere trattata dal funzionario, una pratica non deve essere sospesa. Capitolato tecnico 21 luglio 2015 Pag. 42

43 Per ogni istanza sospesa collegata ad un accertamento il Nuovo Sistema prevederà un avviso per il funzionario competente all approssimarsi della data di scadenza per il pagamento del contributo prevista sull accertamento medesimo. 6.4 Dati di ambiente Per la gestione autonoma da parte degli utenti (amministratore di sistema) dei dati di ambiente (i.e. tabelle di decodifica, tipicamente codice e descrizione) il Nuovo Sistema metterà a disposizione apposite funzioni che ne consentiranno la gestione. 6.5 Funzionalità del Nuovo Sistema Accertamenti note di cortesia Invio accertamenti Le cooperative sono in generale tenute a pagare una serie di contributi, individuati da un codice tributo. I pagamenti devono essere effettuati, salvo i casi di esenzione, ad intervalli regolari (annuali o biennali, in funzione del codice tributo) ed entro date di scadenza determinate. In caso di pagamento irregolare l Amministrazione provvede all invio tramite PEC di un accertamento alla cooperativa inadempiente. Il programma per l invio degli accertamenti (di tipo batch) viene schedulato periodicamente ed ha come parametro il periodo (uno o più anni). Per ogni cooperativa iscritta all albo 5 e per ogni scadenza, differenziata in base allo specifico codice tributo il programma verifica se: la cooperativa è tenuta a pagare o rientra in uno dei casi di esenzione previsti dalle norme; la cooperativa è già oggetto di un precedente accertamento ancora non chiuso; In questo caso verifica se la situazione debitoria attuale è coerente con quella relativa all accertamento già inviato e solo in caso contrario procede all invio di una nuova lettera di accertamento che illustra la nuova situazione. Allo scopo di poter effettuare analoghe verifiche anche successivamente la data dell invio dell accertamento, il Nuovo Sistema memorizza la situazione al momento dell invio, ed, in particolare: canale utilizzato per la trasmissione dell accertamento (PEC, raccomandata AR nei casi in cui la PEC del destinatario non fosse disponibile) indirizzo destinatario situazione debitoria 5 Per le cooperative presenti sul Registro Imprese ma non iscritte all albo dovrà essere definito in sede di analisi del Nuovo Sistema uno specifico trattamento Capitolato tecnico 21 luglio 2015 Pag. 43

44 6.5.2 Invio note di cortesia In prossimità della scadenza di un contributo il Nuovo Sistema consente l invio tramite PEC a tutte le cooperative tenute al pagamento di un promemoria che specifica somma dovuta e scadenza. Il programma per l invio delle note di cortesia (di tipo batch) viene schedulato periodicamente ed ha come parametri il numero di giorni antecedenti la scadenza - utili alla schedulazione del programma medesimo - ed il contributo in scadenza; il programma calcola il dovuto 6, tenendo conto di eventuali esenzioni. Allo scopo di poter effettuare riscontri successivamente la data dell invio della nota di cortesia, il Nuovo Sistema memorizza la situazione al momento dell invio, ed, in particolare: canale utilizzato per la trasmissione della nota di cortesia (PEC, raccomandata AR) indirizzo destinatario situazione debitoria Le cooperative che ritengono non corretta la situazione debitoria presentata nella nota di cortesia potranno presentare opportuna istanza spontanea tramite il portale facendo riferimento alla nota ricevuta nel testo della comunicazione Visualizzazione degli accertamenti L utente potrà visualizzare l elenco degli accertamenti inviati dall Amministrazione. Oltre alla visualizzazione del relativo documento sarà possibile visualizzare l elenco delle istanze ad esso riferite, con indicazione se trattasi di istanza chiusa o ancora aperta. Potranno essere visualizzate anche istanze gestite da altri funzionari. Selezionando la singola istanza potranno essere visualizzati i dati dell istanza stessa. In caso di istanza assegnata al funzionario corrente verrà attivato il relativo processo di gestione, specifico del tipo di istanza. 6 Per il calcolo del dovuto, se la cooperativa non ha ancora presentato il bilancio per il periodo in oggetto, si applicherà quanto previsto dall art. 5 del DM 2006, pertanto l Amministrazione accerta le somme da pagare sulla base dei parametri risultanti dall ultimo documento agli atti. Capitolato tecnico 21 luglio 2015 Pag. 44

45 Visualizzazione delle note di cortesia L utente potrà visualizzare l elenco delle note di cortesia inviate dall amministrazione. Capitolato tecnico 21 luglio 2015 Pag. 45

46 6.5.3 Gestione delle istanze Tipizzazione istanze ed interazione con portale cooperative Presupposti generali per il funzionamento del Nuovo Sistema sono i seguenti: ogni istanza presentata dalla cooperativa appartiene ad una delle seguenti tipologie importo non dovuto: no coop importo non dovuto: aderente associazione importo non dovuto: B/C17 errato pagamento effettuato ma non registrato pagamento effettuato con anomalie compensabili istanza generica ogni istanza presentata dalla cooperativa può essere: associata ad un accertamento spontanea Le istanze possono essere presentate dalle cooperative esclusivamente attraverso il portale, che presuppone, tra l altro, la presenza dell indirizzo PEC. La cooperativa nel presentare un istanza dovrà necessariamente indicare la tipologia (fra quelle presenti) e, nel caso di istanza associata ad un accertamento, indicare l accertamento medesimo. Per la gestione delle istanze non tipizzate presenti attualmente (in quanto inviate all Amministrazione precedentemente allo sviluppo sul portale della funzione di tipizzazione) dovrà essere prevista una funzione di tipizzazione che consentirà al funzionario competente di assegnare ad ogni istanza un tipo ed un accertamento di riferimento. E possibile che a fronte di una comunicazione da parte della cooperativa vengano assegnate più tipi; in questo caso il Nuovo Sistema genererà automaticamente una istanza per ogni tipo assegnato, collegandole alla medesima comunicazione della cooperativa ed, in caso di istanza collegata ad un accertamento, al medesimo accertamento. In sede di assegnazione delle pratiche ai funzionari l algoritmo di assegnazione dovrà tenere conto che istanze relative alla medesima comunicazione vanno assegnate allo stesso funzionario. Le istanze non collegate ad alcun accertamento verranno considerate istanze spontanee. Capitolato tecnico 21 luglio 2015 Pag. 46

47 Capitolato tecnico 21 luglio 2015 Pag. 47

48 Caratteristiche generali gestione istanze La gestione delle istanze inviate dalle cooperative a seguito di un accertamento è caratterizzata da alcuni elementi comuni alle varie tipologie di istanza e da elementi specifici per ogni tipo di istanza, riconducibili alla fase di accettazione dell istanza stessa da parte dell Amministrazione. Di seguito si dettagliano gli elementi comuni alle varie tipologie, gli elementi specifici verranno dettagliati nell ambito dei relativi paragrafi Visualizzazione elenco istanze Nella sezione superiore dell interfaccia verrà visualizzato l elenco delle istanze nello stato aperte attribuite al funzionario. Selezionando l istanza sarà possibile accedere ai dati di dettaglio della medesima Capitolato tecnico 21 luglio 2015 Pag. 48

49 Il ciclo di gestione dell istanza Con riferimento all istanza presentata, ed a prescindere dalla tipologia, il funzionario ha a disposizione tre scelte: accettazione, rifiuto, interlocuzione. Rifiuto istanza Nel caso di rifiuto dell istanza verrà predisposto dal sistema un documento con layout pre-definito al quale il funzionario potrà aggiungere delle note esplicative per la cooperativa. Tale documento verrà posto fra gli atti da firmare per il dirigente, accompagnato da una nota del funzionario al dirigente. In caso di firma da parte del dirigente, l istanza verrà chiusa, la risposta automaticamente protocollata, archiviata sul sistema documentale ed inviata tramite PEC all indirizzo della cooperativa. In caso di rifiuto della firma da parte del dirigente l istanza tornerà in lavorazione al funzionario, con eventuale indicazione da parte del dirigente delle motivazione. Interlocutoria Nel caso il funzionario ritenga che per il trattamento dell istanza siano necessarie integrazioni da parte della cooperativa oppure che vi sia stata una errata tipizzazione della medesima, verrà predisposto un Capitolato tecnico 21 luglio 2015 Pag. 49

50 documento con layout pre-definito al quale il funzionario potrà aggiungere delle note esplicative per la cooperativa. Tale documento verrà automaticamente protocollato, archiviato sul sistema documentale ed inviato tramite PEC all indirizzo della cooperativa. Accettazione istanza Nel caso di accettazione dell istanza il Nuovo Sistema consentirà all utente di apportare alla base dati le necessarie modifiche al fine di rendere coerenti le informazioni archiviate con le richieste della cooperativa. I dati da inserire saranno pertanto differenti a seconda del tipo di istanza presentata e verranno dettagliati nei successivi paragrafi. Al termine dell inserimento delle necessarie modifiche, il Nuovo Sistema predisporrà un documento con layout pre-definito al quale il funzionario potrà aggiungere delle note esplicative per la cooperativa. Tale documento verrà posto fra gli atti da firmare per il dirigente, accompagnato da una nota del funzionario al dirigente. In caso di firma da parte del dirigente, l istanza verrà chiusa, le modifiche alla base di dati predisposte dal funzionario rese effettive tramite l utilizzo di specifici Web Server, la risposta verrà automaticamente protocollata, archiviata sul sistema documentale ed inviata tramite PEC all indirizzo della cooperativa. In caso di rifiuto da parte del dirigente l istanza tornerà in lavorazione al funzionario, con indicazione da parte del dirigente delle motivazione. In tal caso le modifiche al data base non avranno luogo Dettaglio istanza pulsanti comuni per la visualizzazione dei dati Nell ambito del dettaglio di ciascuna istanza, oltre ai dati identificativi dell istanza medesima ( ad es.: nome della cooperativa, data e n. di protocollo della comunicazione, eventuali note) sarà possibile visualizzare: i seguenti dati: Comunicazioni Accertamenti Iscrizione ad associazioni Ispezioni Amministratori Situazione Contributiva Visure Procedure concorsuali/provvedimenti amministrativi Per ogni tipo di dato nei successivi paragrafi verranno descritte le informazioni trattate Comunicazione Capitolato tecnico 21 luglio 2015 Pag. 50

51 L utente potrà visualizzare sia i dati relativi all istanza selezionata sia i dati relativi ad eventuali altre istanze riferibili alla stessa comunicazione da parte della cooperativa. In quest ultimo caso il Nuovo Sistema segnalerà se trattasi di istanze già aperte oppure chiuse. Il Nuovo Sistema consentirà la visualizzazione della comunicazione relativa all istanza selezionata Capitolato tecnico 21 luglio 2015 Pag. 51

52 Il Nuovo Sistema consentirà la visualizzazione degli allegati alla comunicazione relativa all istanza selezionata Capitolato tecnico 21 luglio 2015 Pag. 52

53 Accertamenti (relativi alla cooperativa) L utente potrà visualizzare tutti gli accertamenti riferiti alla cooperativa collegata all istanza selezionata, anche se attribuiti ad altri funzionari. Per ogni accertamento il Nuovo Sistema segnalerà se lo stato è chiuso o aperto (si ricorda che un accertamento è chiuso se tutte le istanze ad esso collegate sono chiuse e se la cooperativa ha sanato il relativo debito) Iscrizione ad associazioni L utente potrà visualizzare i periodi di iscrizione della cooperativa alle varie associazioni. Inoltre sarà possibile visualizzare tutte le eventuali istanze precedentemente presentate dalla cooperativa di modifica della situazione associativa con l indicazione se l istanza sia stata o meno accettata dall Amministrazione (verranno visualizzate anche le istanze assegnate ad altri funzionari). Capitolato tecnico 21 luglio 2015 Pag. 53

54 Ispezioni/revisioni L utente potrà visualizzare le revisioni/ispezioni straordinarie effettuate dall Amministrazione sulla cooperativa. I relativi dati strutturati sono memorizzati sul data base Sicoop (i documenti, come in tutti gli altri casi, sul sistema di gestione documentale Adam) Per ogni ispezione sarà possibile visualizzare i dati relativi ai verbali Capitolato tecnico 21 luglio 2015 Pag. 54

55 Per ogni ispezione sarà possibile visualizzare i dati relativi ad eventuali altri documenti collegati Per ogni ispezione sarà possibile visualizzare i dati relativi ad eventuali provvedimenti sanzionatori attivati dalla Divisione 6 Capitolato tecnico 21 luglio 2015 Pag. 55

56 Anche i dettagli dei vari provvedimenti sanzionatori saranno visualizzabili; tali dettagli dipendono dallo specifico provvedimento, di seguito si descrive il caso più significativo, ovvero le Liquidazioni Coatte Amministrative, per il quale saranno visualizzabili: numero e data del decreto di LCA, decreto in formato.pdf dal sistema documentale nome, cognome e codice fiscale del Commissario liquidatore, CV in formato.pdf dal sistema documentale, lista eventuali altri incarichi attributii al medesimo soggetto nome, cognome e codice fiscale dei membri del comitato di sorveglianza, CV in formato.pdf dal sistema documentale, lista eventuali altri incarichi attributii al medesimo soggetto Capitolato tecnico 21 luglio 2015 Pag. 56

57 Nel caso della LCA sarà visualizzabile l estratto dei dati di visura relativi al provvedimento sanzionatorio Saranno inoltre visualizzabili tutti i documenti relativi alla procedura in oggetto: allegati vari, eventuali controdeduzioni, etc Amministratori L utente potrà visualizzare l elenco degli amministrazioni con indicazione di: Nome e cognome CF Carica Periodo della carica (da/a) Capitolato tecnico 21 luglio 2015 Pag. 57

58 Se legale rappresentante (si/no) Inoltre, saranno visualizzabili per ogni soggetto gli eventuali altri incarichi ricoperti nell ambito di altre imprese, anche non cooperative (si dovrà fare riferimento al Registro Imprese e non esclusivamente all albo delle cooperative) Situazione contributiva L utente potrà visualizzare la situazione contributiva della cooperativa relativamente a: Contributi versati Movimenti F24 relativi ai contributi versati Dati di bilancio Modelli B/C17 presentati Capitolato tecnico 21 luglio 2015 Pag. 58

59 Capitolato tecnico 21 luglio 2015 Pag. 59

60 Visure camerali L utente potrà visualizzare l estratto dei dati della cooperativa presenti sulla visura camerale desumibili dal database Parix-Cose; previa approvazione del dirigente, sarà disponibile la funzionalità per la visura effettiva sul sistema Telemaco (Camere di commercio, servizio generalmente a pagamento) Procedure concorsuali/provvedimenti amministrativi L utente potrà visualizzare: - l estratto dei dati della cooperativa relativi ad eventuali procedure concorsuali desumibili dal database Parix-Cose; previa approvazione del dirigente, sarà disponibile la funzionalità per la visura effettiva sul sistema Telemaco (Camere di commercio) - I dati sui provvedimenti amministrativo in carico alla cooperativa, con evidenza dei dati dei relativi documento a supporto, specifici del tipo di provvedimento amministrativo in essere Capitolato tecnico 21 luglio 2015 Pag. 60

61 Capitolato tecnico 21 luglio 2015 Pag. 61

62 La gestione delle specifiche tipologie di istanza Di seguito, per ogni tipo di istanza, si descrive il comportamento del Nuovo Sistema nella fase di accettazione dell istanza, che come descritto in precedenza, è specifica della tipologia. Le modifiche alla base di dati predisposte dal funzionario verranno rese effettive esclusivamente in seguito alla firma da parte del Dirigente. Nel caso di mancata firma l istanza tornerà in lavorazione al funzionario e le modifiche proposte dal funzionario non verranno rese effettive importo non dovuto: la società non è una cooperativa In caso di accettazione dell istanza di importo non dovuto in quanto la società alla data di scadenza del contributo contestato non era una cooperativa, verrà presentata all utente la attuale situazione anagrafica registrata sul sistema Parix - Cose. Sulla base dei dati forniti dalla cooperativa nell ambito dell istanza il funzionario predisporrà le modifiche anagrafiche inserendo i corretti periodi in cui la società è stata una cooperativa e quelli in cui non lo è stata. Al termine dell inserimento delle modifiche, il Nuovo Sistema predisporrà un documento con layout predefinito al quale il funzionario può aggiungere delle note esplicative per la cooperativa. Tale documento verrà posto fra gli atti da firmare per il dirigente, accompagnato da una nota del funzionario al dirigente. Le modifiche dovranno successivamente essere apportate anche sul Registro Imprese, cui il sistema non avrà accesso diretto. Le modalità per la comunicazione alla Camera di Commercio dell avvenuta modifica al fine di adeguare anche il Registro Imprese con le nuove informazioni verranno specificate in fase di analisi funzionale 7. 7 Ad esempio, si potrebbe ipotizzare che il Nuovo Sistema inoltri una comunicazione via PEC alla cooperativa, che dovrà provvedere quanto prima alla comunicazione dei dati variati; il Nuovo Sistema potrebbe anche inviare analoga comunicazione alla Camera di Commercio competente Capitolato tecnico 21 luglio 2015 Pag. 62

63 Al termine, mediante l apposito pulsante, potrà sottoporre alla firma del dirigente l accettazione dell istanza importo non dovuto: la società ha sede in una Regione a Statuto Speciale In caso di accettazione dell istanza di importo non dovuto in quanto la società alla data di scadenza del contributo contestato aveva sede in una Regione a Statuto Speciale e pertanto non doveva pagare il contributo, verrà presentata all utente la attuale situazione anagrafica registrata sul sistema Parix - Cose. Sulla base dei dati forniti dalla cooperativa nell ambito dell istanza il funzionario predisporrà le modifiche anagrafiche inserendo i corretti periodi in cui la società ha avuto sede nella Regione a Statuto Speciale. Al termine dell inserimento delle modifiche, il Nuovo Sistema predisporrà un documento con layout predefinito al quale il funzionario potrà aggiungere delle note esplicative per la cooperativa. Tale documento verrà posto fra gli atti da firmare per il dirigente, accompagnato da una nota del funzionario al dirigente. Capitolato tecnico 21 luglio 2015 Pag. 63

64 Le modifiche dovranno successivamente essere apportate anche sul Registro Imprese, cui il sistema non avrà accesso diretto. A tal fine il Nuovo Sistema inoltrerà una comunicazione via PEC alla cooperativa, che dovrà provvedere quanto prima alla comunicazione dei dati variati; eventualmente il Nuovo Sistema provvederà anche ad inviare analoga comunicazione alla Camera di Commercio competente. Camera di Commercio Camera di Commercio Camera di Commercio CCIAA Camera CCIAA di Commercio Al termine, mediante l apposito pulsante, potrà sottoporre alla firma del dirigente l accettazione dell istanza importo non dovuto: la cooperativa è aderente ad una associazione In caso di accettazione dell istanza di importo non dovuto in quanto la società alla data di scadenza del contributo contestato aderiva ad una associazione riconosciuta, verrà presentata all utente la attuale situazione anagrafica registrata sul sistema Parix- COSE. Capitolato tecnico 21 luglio 2015 Pag. 64

65 Sulla base dei dati forniti dalla cooperativa nell ambito dell istanza il funzionario predisporrà le modifiche anagrafiche inserendo i corretti periodi in cui la società è stata associata ed a quale associazione. Il Nuovo Sistema visualizzerà un indicatore di revisione ordinaria espletata dall Amministrazione. In tal caso infatti, anche se aderente ad una associazione, la cooperativa è tenuta al pagamento del contributo all Amministrazione in quanto quest ultima ha sostenuto gli oneri relativi alla revisione effettuata. Nel caso in cui, in presenza di tale indicatore, il funzionario decida comunque di accettare l istanza della cooperativa ed invii il documento alla firma del dirigente, a quest ultimo verrà visualizzato un warning che gli evidenzi la particolare situazione. Al termine dell inserimento delle modifiche, il Nuovo Sistema predisporrà un documento con layout predefinito al quale il funzionario potrà aggiungere delle note esplicative per la cooperativa. Tale documento verrà posto fra gli atti da firmare per il dirigente, accompagnato da una nota del funzionario al dirigente. Capitolato tecnico 21 luglio 2015 Pag. 65

66 Al termine, mediante l apposito pulsante, potrà sottoporre alla firma del dirigente l accettazione dell istanza pagamento effettuato ma non registrato In caso di accettazione dell istanza di pagamento non registrato la cooperativa avrà trasmesso tramite il portale le attestazioni di avvenuto pagamento. Nel caso in cui non lo avesse fatto verrà richiesto di procedere in tal senso mediante la fase interlocutoria. Al fine di valutare la coerenza di quanto dichiarato dalla cooperativa al funzionario saranno disponibili funzionalità per la visualizzazione della situazione debitoria/contributiva della cooperativa quali: contributi versati modelli F24 relativi ai contributi versati modelli B/C17 bilanci Capitolato tecnico 21 luglio 2015 Pag. 66

67 il funzionario competente potrà registrare tramite apposita funzione: l anno di riferimento del versamento il codice tributo l importo versato la data del versamento Inoltre il funzionario potrà compilare un apposito campo note ove trasmettere al dirigente, per la firma, osservazioni in merito alla particolare situazione. Capitolato tecnico 21 luglio 2015 Pag. 67

68 Al termine, mediante l apposito pulsante, potrà sottoporre alla firma del dirigente l accettazione dell istanza pagamento effettuato con anomalie compensabili Nel caso in cui una cooperativa abbia effettuato il pagamento dovuto ma per un periodo e/o per un codice tributo errati, tale pagamento potrà essere utilizzato in compensazione per il periodo e/o il codice tributo effettivamente dovuto Al fine di valutare la coerenza di quanto dichiarato dalla cooperativa al funzionario saranno disponibili funzionalità per la visualizzazione della situazione debitoria/contributiva attuale della cooperativa quali (v. paragrafo (pagamento effettuato ma non registrato) per le figure: contributi versati modelli F24 relativi ai contributi versati modelli B/C17 bilanci In caso di accettazione dell istanza di pagamento effettuato con anomalie compensabili il funzionario avrà preventivamente verificato la trasmissione da parte della cooperativa della documentazione di supporto necessaria alla valutazione dell istanza medesima. Nel caso in cui la documentazione risultasse insufficiente verrà richiesto di procedere in tal senso mediante una la fase interlocutoria. Capitolato tecnico 21 luglio 2015 Pag. 68

69 Al termine, mediante l apposito pulsante, potrà sottoporre alla firma del dirigente l accettazione dell istanza. Il Nuovo Sistema renderà disponibile una funzione di simulazione della situazione debitoria che verrebbe a crearsi nell ipotesi in cui si procedesse con la compensazione così come impostata. Tale funzione sarà fruibile dal funzionario prima della firma del Dirigente, per visualizzare gli effetti potenziali della modifica, che, come già detto, diverrà effettiva solo dopo la firma da parte del Dirigente. Nell ipotesi di presenza di un residuo il Nuovo Sistema provvederà ad includere automaticamente nella risposta alla cooperativa l autorizzazione a compensare alla prossima scadenza anche detto residuo. Anche la nota di risposta sarà inviata solo in caso di firma da parte del Dirigente. Capitolato tecnico 21 luglio 2015 Pag. 69

70 istanza generica Nel caso in cui una cooperativa abbia inoltrato una istanza che non fa parte di alcuna fra le tipologie classificate, verrà trattata come istanza generica. In caso di accettazione dell istanza le azioni effettuate (extra sistema) dal funzionario saranno descritte nel campo note per il dirigente, ed il Nuovo Sistema, in caso di firma del dirigente, effettuerà esclusivamente la protocollazione della risposta, l invio della PEC e la chiusura dell istanza. Capitolato tecnico 21 luglio 2015 Pag. 70

71 6.5.4 Gestioni ruoli Iscrizioni a ruolo L iscrizione a ruolo è prevista per le cooperative che, pur avendo ricevuto un accertamento, non hanno provveduto entro i termini previsti a saldare il proprio debito con l Amministrazione. Il programma (di tipo batch) verrà schedulato periodicamente, ed accetterà come parametro il numero di giorni successivi alla data di invio dell accertamento che danno luogo all iscrizione a ruolo. In casi eccezionali, e solo da parte dell Amministratore del Sistema, potrà esserne richiesta la schedulazione immediata, anche soltanto su una parte degli accertamenti in essere. Per ogni cooperativa cui sia stato inviato un accertamento da almeno x gg, (x = parametro), verranno automaticamente iscritte a ruolo tutte le cooperative 8 : a cui è stato inviato un accertamento la cui situazione debitoria contestata non sia stata interamente sanata; in caso di debito parziale la cooperativa verrà iscritta a ruolo per la parte di debito residuo per cui non risultino istanze aperte (comprese eventuali istanze relative ad accertamenti diversi da quello in sede di trattamento oppure istanze spontanee) L iscrizione a ruolo avverrà tramite comunicazione ad Agenzia delle entrate/equitalia. Il tracciato record di tale comunicazione e le modalità di trasmissione sono in corso di definizione, e saranno oggetto di specifica in sede di Analisi Funzionale del Nuovo Sistema Gestione ricorsi Le modalità di gestione dei ricorsi saranno oggetto di specifica in sede di Analisi Funzionale del Nuovo Sistema Insinuazione passivo Nel caso di una cooperativa per la quale sia stata avviata la procedura di Liquidazione Coatta Amministrativa (LCA) oppure di Scioglimento forzato con liquidatore e che si trovi in una situazione debitoria nei confronti dell Amministrazione, il Nuovo Sistema consentirà l iscrizione dell Amministrazione tra i creditori. Il programma (di tipo batch) verrà schedulato quotidianamente e/o a cadenza regolare ed identificherà le cooperative nella suddetta situazione comunicandolo alla Divisione VI (Provvedimenti sanzionatori) mediante aggiornamento della base dati Sicoop nonché via al commissario liquidatore 9. 8 attive sul Registro Imprese 9 Il testo della comunicazione sarà specifico in base al provvedimento sanzionatorio/procedura concorsuale in essere Capitolato tecnico 21 luglio 2015 Pag. 71

72 6.5.6 Modifiche Modelli B/C17 d ufficio Sulle modalità di ricezione, visualizzazione e gestione dei modelli contenenti i dati di bilancio delle società cooperative rilevanti per la determinazione dei contributi (ex mod. C17, attuale Mod. B) è in corso un attività di approfondimento da parte dell Amministrazione i cui risultati, qualora rilevanti per la realizzazione del Nuovo Sistema, saranno resi noti al Fornitore per il conseguente aggiornamento dei requisiti. A seguito di una verifica spontanea il funzionario può rilevare che il modello B/C17 presentato dalla cooperativa è errato e procedere pertanto alla sua correzione. Il Nuovo Sistema metterà a disposizione una specifica funzione per effettuare tale operazione, consentendo la visualizzazione dei dati attualmente registrati sul data base. Il sistema prevede la firma da parte del dirigente, solo a seguito della quale le modiche diverranno effettive. Capitolato tecnico 21 luglio 2015 Pag. 72

73 Le modalità per la comunicazione di avvenuta modifica alla cooperativa e/o alla Camera di Commercio fine di adeguare anche il Registro Imprese con le nuove informazioni verranno specificate in fase di analisi funzionale Il desk top del dirigente (atti da firmare) L utente con profilo dirigente avrà accesso alla funzione atti da firmare, che consentirà di visualizzare l elenco degli atti predisposti dai funzionari per la firma. Selezionando uno degli atti il Nuovo Sistema consentirà la firma dell atto o il re-invio al funzionario. Al dirigente saranno rese disponibili tutte le funzioni di visualizzazione della situazione della cooperativa comuni ai vari tipi di istanze e descritti nel precedente paragrafo (Dettaglio istanza pulsanti comuni per la visualizzazione dei dati) 10 Ad esempio, si potrebbe ipotizzare che il Nuovo Sistema inoltri una comunicazione via PEC di avvenuta modifica alla cooperativa, con eventuale richiesta di aggiornamento dei dati da parte delle medesima al Registro Imprese; il Nuovo Sistema potrebbe anche inviare analoga comunicazione alla Camera di Commercio competente Capitolato tecnico 21 luglio 2015 Pag. 73

74 Firma Nel caso di firma da parte del dirigente il Nuovo Sistema richiederà l inserimento del PIN, ed, a seguito di tale inserimento, l istanza viene chiusa, le modifiche alla base di dati predisposte dal funzionario verranno rese effettive tramite l utilizzo di specifici web server, la risposta verrà automaticamente protocollata, archiviata sul sistema documentale ed inviata tramite PEC all indirizzo della cooperativa. Nel caso di indirizzo PEC errato verrà gestito opportunamente il flusso di ritorno. Sarà disponibile anche la funzione di firma massiva, ovvero la possibilità di firmare più documenti inserendo il PIN una sola volta. Capitolato tecnico 21 luglio 2015 Pag. 74

75 Restituzione al funzionario Nel caso di mancata firma da parte del dirigente l istanza tornerà in lavorazione al funzionario, con indicazione da parte del dirigente delle motivazioni del rifiuto. Le modifiche proposte dal funzionario non verranno rese effettive. 6.6 Architettura SOA Tutte le applicazioni del MiSE offrono, accanto alle tradizionali interfacce end-user, anche interfacce di collegamento per l integrazione con tutti gli altri sistemi del ministero attraverso una piattaforma di Enterprise Service Bus (ESB). L ESB o middleware è una piattaforma tecnologica che rimuove qualsiasi collegamento diretto punto-punto tra il provider di un servizio ed il suo consumer. Pertanto qualunque applicativo che intende usufruire di un servizio esposto da un altro sistema, si collega direttamente al bus e non al provider che effettivamente implementa il servizio. Il bus ha il compito di ricevere la richiesta dall'applicazione consumer, e indirizzarla correttamente al sistema fornitore interfacciandosi con esso utilizzando protocolli standard di settore (xml, wsdl, soap, rest, publish and subscribe ecc.). In questo modo da un lato si disaccoppia in modo forte il consumer dal fornitore per il servizio specificatamente richiesto, e dall altro si concentra sul bus l implementazione dei servizi di log, audit, orchestrazione(routing), sicurezza, garanzia di consegna, trasformazione del formato del messaggio xml, e d integrazione che diversamente bisognerebbe implementare ogni volta alla coppia consumer/provider. L obiettivo è mantenere all interno del MiSE un architettura distribuita di tipo SOA (Service Oriented Architecture) in grado di aumentare e garantire sicurezza, flessibilità e gestibilità del flusso di informazioni che viaggiano tra i vari applicativi, ognuno della quale può essere sia consumer sia provider di servizi. Obiettivo Capitolato tecnico 21 luglio 2015 Pag. 75

76 Tutti i processi d integrazione sia in essere sia in divenire interni al MiSE devono essere gestiti dalla piattaforma SOA. La piattaforma utilizzata dal MiSE per l integrazione dei sistemi fra loro comunicanti è la piattaforma Oracle BPM nella versione 11g. Il sistema BPM detto BPM COOP è stato realizzato al fine di soddisfare l esigenza della Direzione Generale per le Piccole e Medie Imprese e gli Enti Cooperativi (DG-PMI-EC) del Dipartimento per l impresa e l internazionalizzazione del Ministero dello Sviluppo Economico, di ottimizzare i propri processi interni attraverso l automazione degli stessi secondo una logica di Business Process Management; Il prodotto commerciale su cui si basa l architettura SOA, è Oracle Unified Business Process Management, che a sua volta è basato su un altra serie di prodotti Oracle che forniscono le funzionalità primarie per il disegno e l esecuzione dei Business Process. L Oracle Business Process Management Suite 11g è una soluzione BPM completa che si basa sullo standard BPMN 2.0 sia per la modellazione sia per l esecuzione dei processi di business. Inoltre tale suite è stata costruita e si basa su una sottostante architettura denominata Oracle SOA Suite (11g), che mette a disposizione una svariata gamma di adapter per l integrazione con sistemi esterni. Architettura L infrastruttura di esecuzione dei processi si basa sullo standard SCA (Service Component Architecture) e offre in maniera nativamente integrata tutti i componenti necessari all esecuzione ed al monitoraggio dei processi di business (motore di esecuzione di processi di business BPMN e BPEL, Human Workflow, ecc.), nonché all integrazione di sistemi ed applicazioni esterne (JMS Adapter, Database Adapter, File Adapter, ecc.). L application server utilizzato dalla suite è Oracle WebLogic Server 10.3 e il DBMS è Oracle Enterprise 10g. Capitolato tecnico 21 luglio 2015 Pag. 76

77 6.6.1 Personalizzazioni dell Ambiente Ministero dello Sviluppo Economico L architettura sopra descritta è interamente rilasciata nell ambiente informatico del Ministero su un sistema centralizzato ed ingegnerizzato (Oracle ODA). Su tale struttura a breve verrà rilasciato con funzioni di collaborazione applicativa anche il nuovo sistema di Protocollo Informatico del Ministero che basa il suo documentale sul prodotto Oracle Web Center Content che diverrà l unico documentale per tutte le applicazioni core. Inoltre l infrastruttura ospita il prodotto Oracle Portal che è il sistema attraverso cui vengono pubblicati su internet i nuovi servizi a terzi e le interfacce dalle applicazioni basate su SOA. Capitolato tecnico 21 luglio 2015 Pag. 77

78 6.6.2 Architettura di dettaglio Scheda Prodotto Prodotto Versione Oracle BPM Suite Oracle SOA Suite Oracle Enterprise Manager Oracle Service Bus Oracle WMS policy Manager Oracle JRF WebService Asyncronous services Web Logic Server Web Center Content Oracle Portal Capitolato tecnico 21 luglio 2015 Pag. 78

79 6.7 Architettura applicativa: componenti principali Il sistema informativo della Direzione Generale si articola in tre Web Application: 1. Parix. Interroga ed aggiorna la base dati Cose (Oracle), quotidianamente popolata (via batch) con le informazioni relative alle società cooperative provenienti dalle Camere di Commercio. Comprende sia dati provenienti dalle Camere di Commercio, sia dati originati direttamente nell ambito della Direzione. La maggior parte dei dati relativi alle cooperative risiede sul database Cose. I dati sono accessibili in lettura direttamente sul data base e modificabili tramite Web Services esposti dal sistema Parix. FoliumCS. Consente la gestione delle attività della Divisione V (Vigilanza) e parte delle attività della Divisione VI (Procedure concorsuali). Fa riferimento alla base dati Sicoop, (Oracle) ed interagisce, in sola lettura, con la base dati Cose. Utilizza il sistema di gestione documentale open-source Adam.. I dati sono accessibili in lettura direttamente sul data base e modificabili tramite Web Services esposti dal sistema FoliumCS. 2. Portale Coop. Portale utilizzato dalle cooperative per comunicare con l Amministrazione (ad es.: invio istanze). Interagisce con l applicazione FoliumCS aggiornando la base dati Sicoop ed il sistema documentale Adam. La figura seguente illustra schematicamente le interazioni fra applicazioni: Internet Parix WS FoliumCS (Div V e VI) WS Portale Coop JDBC JDBC API WS WS Sicoop Cose DB Oracle Adam Protocollo Capitolato tecnico 21 luglio 2015 Pag. 79

80 6.7.1 Portale cooperative Descrizione E il sistema con cui le cooperative comunicano con l Amministrazione. Le informazioni trasmesse dalle cooperative vengono registrate sulla base dati Sicoop e sul sistema Adam di gestione documentale. Tramite il portale, le cooperative forniscono le seguenti informazioni: I dati relativi ai modelli B/C17, ovvero informazioni di natura economica, generalmente estratti dal bilancio e dalla nota integrativa ad esso associata, che servono da base per il calcolo dei contributi dovuti dalla cooperativa. Tali informazioni vengono attualmente acquisite dalle cooperative e validate da funzionari dell amministrazione; dopo la validazione vanno a sostituire o integrare i dati precedentemente presentati dalla cooperativa 11 Le istanze, classificate per tipologia ed eventualmente collegate ad un accertamento (oppure, istanze spontanee) L insieme di tali richieste costituisce le comunicazioni della cooperativa. Le istanze sono contenute in documenti a testo libero da cui non è possibile estrarre informazioni strutturate. Sono classificate con un tipo ed, eventualmente, associate ad un accertamento. Dal punto di vista della documentazione, sono disponibili: modello dei dati (tracciati, descrizione campi, chiavi ed indici) librerie utili alla gestione dei documenti sul sistema Adam, opportunamente documentate Interazioni con il Nuovo Sistema Il Nuovo Sistema interagisce con il Portale cooperative sia acquisendo le comunicazioni delle cooperative inviate tramite portale, sia condividendo con il portale (e dunque con le cooperative) le decisioni assunte dall Amministrazione e la relativa documentazione. Il Nuovo Sistema dovrà fornire i Web Services necessari al portale per consultare/aggiornare le tabelle condivise (es. istanze, lettere interlocutorie, etc.); per la implementazione di tali Web Services, che dovranno sostituire quelli attualmente in uso per l interazione fra il portale ed il sistema attualmente in uso, verranno fornite le specifiche tecniche Sistema gestionale Parix-COSE 11 è in corso uno studio da parte dell Amministrazione volto a conferire valore di autocertificazione a tali dichiarazioni, eliminando la successiva fase di validazione Capitolato tecnico 21 luglio 2015 Pag. 80

81 Descrizione Parix è una web application che consente la gestione delle informazioni relative alle cooperative provenienti dalle Camere di Commercio. Tali informazioni sono conservate sulla base dati Cose (Oracle). Oltre alle informazioni costitutive, (i.e. quelle presenti in una visura camerale), il sistema Parix-Cose consente la gestione di altre informazioni rilevanti per il Nuovo Sistema, fra cui: I contributi dovuti dalle cooperative, calcolati a partire dalle dichiarazioni delle cooperative (modelli B/C17 i pagamenti effettuati dalle cooperative e le informazioni relative alle scadenze ed agli interessi di mora applicabili l appartenenza alle associazioni di cooperative legalmente riconosciute Interazioni con il Nuovo Sistema La maggior parte dei dati relativi alle cooperative risiede sul data base Cose, pertanto il Nuovo Sistema interagirà con esso per l acquisizione in lettura di tali informazioni. Per quanto riguarda gli accessi in modifica, l accoglimento di una istanza proveniente dalla cooperativa comporterà in generale un aggiornamento del data base Cose; Il Nuovo Sistema procederà agli aggiornamenti del data base Cose generalmente attraverso Web Services esposti dall applicazione Parix di cui verranno fornite specifiche e documentazione Sistema gestionale Divisione V - Vigilanza Descrizione La Divisione V si occupa della vigilanza sulle cooperative tramite ispettori che, ad intervalli regolati da norme specifiche, verificano la rispondenza ai requisiti previsti; le cooperative riconoscono all Amministrazione, per lo svolgimento dell attività di revisione, dei contributi. La Divisione V utilizza per la gestione delle attività di ispezione/revisione delle cooperative la web application FoliumCS. I relativi dati strutturati sono conservati sulla base dati Sicoop; le informazioni di natura documentale sono registrate nel sistema documentale Adam. Il Nuovo Sistema consentirà la consultazione di tali informazioni al funzionario incaricato di valutare l istanza. Le informazioni strutturate verranno prelevate tramite accesso diretto alla base dati. Verranno forniti i tracciati record di tutte le tabelle rilevanti, opportunamente documentati. Le medesime tabelle contengono anche le informazioni necessarie per estrarre i documenti dal sistema Adam tramite API di cui verranno fornite librerie e documentazione. Capitolato tecnico 21 luglio 2015 Pag. 81

82 Interazioni con il Nuovo Sistema Tra il Nuovo Sistema e il sistema gestionale della Divisione V sono previste le seguenti interazioni: Il Nuovo Sistema acquisisce la documentazione relativa alle eventuali ispezioni effettuate sulle cooperative prelevandole dalla base dati Sicoop e dal sistema documentale Adam Sistema gestionale Divisione VI provvedimenti sanzionatori Descrizione L informatizzazione di questa divisione è ancora in uno stato preliminare. Le funzionalità presenti sono coperte da un estensione di FoliumCS. I dati relativi ai provvedimenti sanzionatori risiedono sul database Sicoop Verranno forniti i tracciati record delle tabelle interessate alle funzionalità offerte dal Nuovo Sistema Interazioni con il Nuovo Sistema Tra il Nuovo Sistema ed il sistema gestionale della Divisione VI sono previste le seguenti interazioni: Il Nuovo Sistema avrà accesso ai dati ed ai documenti relativi ad eventuali provvedimenti sanzionatori emessi dalla Divisione VI a carico della cooperativa in esame. Tali dati sono presenti nella base dati Sicoop e nel sistema documentale Adam Nello scenario indicato nel paragrafo (Insinuazione passivo) il Nuovo Sistema notificherà la decisione di insinuazione nel passivo della società cooperativa al commissario liquidatore della Divisione VI competente (es. tramite , oppure aggiornamento base dati Sicoop) Sistema documentale ADAM Adam è un sistema documentale open-source, client-server corredato di librerie API e di un interfaccia Web Services (assai limitata nella versione in uso). Il Nuovo Sistema da sviluppare utilizzerà l interfaccia API. Le informazioni di natura documentale previste nel Nuovo Sistema verranno gestiti su Adam. Verranno fornite le suddette librerie corredate di documentazione ed i file di configurazione necessari Sistema protocollo Speed Si tratta del sistema di protocollo in uso presso il Ministero dello Sviluppo Economico. E dotato di un interfaccia a Web Services di cui verrà fornita documentazione. Verranno forniti i dati di configurazione necessari ad utilizzare tali Web Services (memorizzati anche sulla base dati Sicoop) Capitolato tecnico 21 luglio 2015 Pag. 82

83 6.7.7 Sistema di PEC Non è disponibile un PEC Manager, pertanto il nuovo sistema dovrà utilizzare le librerie standard di Java. Verranno forniti i dati di configurazione necessari (memorizzati anche sulla base dati Sicoop) Sistema per la firma digitale CoSign CoSign è un sistema di firma digitale remota che si integra con i sistemi di Active Directory (LDAP) e con i vari sistemi di Content Management (tra cui SharePoint). Supporta la firma multipla. E accessibile sia tramite librerie API che tramite Web Services. Verranno fornite le librerie e la necessaria documentazione Sistema SAS per il query-reporting dinamico Il sistema consente agli utenti di navigare in maniera autonoma sulle varie basi di dati e rappresentare in maniera dinamica ed integrata le informazioni estratte (ad es.: Saldi e contributi versati, Situazione debitoria, Dati di statuto e bilancio, dati albo, natura giuridica, sedi locali, variazione natura giuridica, variazione Sedi, periodi in cui la cooperativa è stata iscritta ad una associazione ed i periodi in cui non lo è stata. Il sistema è utilizza un database proprio, aggiornato quotidianamente acquisendo i dati dai vari data base mediante programmi batch. Il Nuovo Sistema dovrà consentire tale acquisizione di dati Schema di sintesi interazioni applicative del Nuovo Sistema Capitolato tecnico 21 luglio 2015 Pag. 83

84 L immagine riassume le interazioni descritte nei paragrafi precedenti. Capitolato tecnico 21 luglio 2015 Pag. 84