Ministero dello Sviluppo Economico · Architettura tecnica: Il risultato dell’attiità è...

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

Progetto sistema di gestione accertamenti – contributi

Capitolato tecnico – 21 luglio 2015

Pag. 2

Sommario

1 Premessa .................................................................................................................................................. 3

2 Descrizione della fornitura ...................................................................................................................... 3

3 Oggetto della fornitura ............................................................................................................................ 4

3.1 Beni ........................................................................................................................................................ 5

3.2 Servizi ..................................................................................................................................................... 6

3.3 Piano di Progetto ................................................................................................................................. 12

3.4 Pianificazione delle attività .................................................................................................................. 13

3.5 Tempistica del progetto....................................................................................................................... 14

3.6 Prodotti da rilasciare ........................................................................................................................... 15

3.7 Approvazione ....................................................................................................................................... 15

3.8 Accettazione ........................................................................................................................................ 15

3.9 Base Informativa di Progetto ............................................................................................................... 17

3.10 Qualità della fornitura ......................................................................................................................... 17

3.11 Garanzia ............................................................................................................................................... 26

4 Penali ...................................................................................................................................................... 26

4.1 Penali per ritardata consegna.............................................................................................................. 27

4.2 Penali di mancato Collaudo ................................................................................................................. 27

4.3 Penali per mancato rispetto Livelli di Servizio Conduzione ed Assistenza sistemistica ...................... 27

4.4 Penali per mancato rispetto Livelli di Servizio Manutenzione Correttiva ........................................... 27

4.5 Penali per mancato rispetto Livelli di Servizio Addestramento e Formazione .................................... 28

4.6 Penali per mancato aggiornamento della Base Informativa di Progetto ............................................ 28

5 Figure professionali previste................................................................................................................ 28

5.1 Dettaglio delle figure professionali ..................................................................................................... 29

6 Analisi dei requisiti utente .................................................................................................................... 34

6.1 Principali funzionalità .......................................................................................................................... 34

6.2 Struttura dei dati ................................................................................................................................. 35

6.3 Profilazione degli utenti....................................................................................................................... 37

6.4 Dati di ambiente .................................................................................................................................. 39

6.5 Funzionalità del Nuovo Sistema .......................................................................................................... 39

6.6 Architettura SOA .................................................................................................................................. 71

6.7 Architettura applicativa: componenti principali.................................................................................. 75



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



Pag. 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 stesso1.

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

1 ad es.: Portale coop, sistemi informatici di altre Divisioni, base dati Parix-COSE



Pag. 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 descritti nei successivi

paragrafi.

3.1 Beni

Licenze software:



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

3.2.1 Descrizione dei servizi

3.2.1.1 System Integration

3.2.1.1.1 Fase di Progettazione

Sulla base dei requisiti indicati nella Specifica dei requisiti, il Fornitore definisce:



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

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



Pag. 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. 3.2.1.2

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.



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

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



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



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



Pag. 12

3.3.2 Architettura di dettaglio

Scheda Prodotto

Prodotto Versione

Oracle BPM Suite 11.1.1.0

Oracle SOA Suite 11.1.1.0

Oracle Enterprise Manager 11.1.1.0

Oracle Service Bus 11.1.1.6

Oracle WMS policy Manager 11.1.1.0

Oracle JRF WebService Asyncronous services 11.1.1.0

Web Logic Server 10.3.6.0

Web Center Content 11.1.1.0

Oracle Portal 11.1.1.0



Pag. 13

Architettura applicativa: componenti principali).

Tali dati comprendono sia dati strutturati, sia puntatori a documenti gestiti nel sistema di gestione

documentale (v. par. 6.7.5 - 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.

3.3.2.1 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

6 ore nel 98% dei casi;

8 ore nel restante 2%

2. Alta Funzionalità critiche dell’applicazione

sono indisponibili agli utenti





Pag. 14

Classe di gravità Descrizione Valori di Soglia

3. Media Funzionalità non critiche

dell’applicazione sono indisponibili

agli utenti



4. Bassa Funzionalità non critiche

dell’applicazione sono indisponibili

agli utenti, ma non c’è impatto

sull’immediata operatività



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 fornitura2, 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.

3.3.2.2 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”



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

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

3.3.2.4 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



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



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



Pag. 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à



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



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

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

3.11 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



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



Pag. 22

Indicatore 1: Densità dei test rispetto alla dimensione del sw (analisi) – TSTD

Classe di fornitura SVILUPPO E MEV DI SOFTWARE AD HOC

Caratteristica /Sottocaratteristica

Funzionalità / Accuratezza

Indicatore/Misura Densità dei test rispetto alla dimensione del sw (analisi) – TSTD

Sistema di gestione delle misure

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.

Unità di misura TSTD = percentuale.

Dati elementari da rilevare

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

Periodo di riferimento La durata della fase di analisi

Frequenza esecuzione misure

Una volta, al termine del periodo di riferimento

Regole di campionamento

NA

Formula di calcolo

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 = 1.733 (arrotondato all’intero) TSTD = (350 / 1733) x 100 = 20%

Regole di arrotondamento

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

Obiettivi (valori soglia)

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



Pag. 23



Funzionalità / Accuratezza

Indicatore/Misura 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 Point

N. test totali (FP ^1.2)

10% Test Documentati 20% Test Documentati

10% Test

Valore di soglia

20% Test

Valore di soglia

100 251 25 100 50 100

1.000 3891 389 1000 778 1.000

10.000 63.096 6.310 10.000 12.620 12.620

20.000 144.956 14.495 20.000 28.991 28.991

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.

Azioni contrattuali

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

Eccezioni

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.



Pag. 24

Indicatore 2: Difettosità – NDIF



Affidabilità / maturità

Indicatore/Misura 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.

Unità di misura percentuale


Dimensioni in FP delle applicazioni a inizio del periodo di osservazione. Nr malfunzioni per tipo. Fase di rilevazione (test, collaudo, avviamento / diffusione).

Periodo di riferimento

Primi sei mesi di esercizio (dopo l’eventuale avviamento).


NA


NA

Formula di calcolo

Dati necessari NDIFB = MBTOT / FP NDIFNB = MNBTOT / FP MBTOT = numero totale di anomalie bloccanti rilevate nel periodo di riferimento; MNBTOT = 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



Pag. 25



Affidabilità / maturità

Indicatore/Misura Difettosità – NDIF

stesso presenti inconvenienti in esercizio; si può ad es. fare riferimento alla seguente classificazione

Classe di criticità

Descrizione Valore soglia

errori bloccanti (es.)

Valore soglia errori non bloccanti

(es.)

1 Sanzioni civili e penali, consistenti perdite economiche, gravi ripercussioni sull’immagine

0,01% 0,5%

2 Interruzione del servizio con conseguenti danni economici e di immagine

0,1% 1%

3 Perdite moderate, facilmente recuperabili

0,2% 2%

4 Perdite scarse, facilmente recuperabili

0,5% 5%

5 Inconvenienti lievi

1% 5%

Azioni contrattuali 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.

Eccezioni 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



Manutenibilità / modificabilità

Indicatore/Misura 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.

Unità di misura Numero.


- Numero di archi del grafo. - Numero di nodi del grafo. - Numero di componenti software connesse.

Periodo di riferimento NA


NA

Regole di NA



Pag. 26




Indicatore/Misura Complessità ciclomatica – COC

campionamento

Formula di calcolo

L’algoritmo di calcolo è il seguente: COC = E – N + p dove E = numero di archi del grafo del modulo; N = numero di nodi del grafo del modulo; p = numero di componenti software connesse.


Intero più prossimo.


COC < 21

Azioni contrattuali 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.

Eccezioni NA

Indicatore 4: Livello di documentazione – LDO




Indicatore/Misura 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.

Unità di misura Percentuale.


Numero di Line Of Code (LOC). Numero di linee di commento.

Periodo di riferimento NA


NA


NA

Formula di calcolo

L’algoritmo di calcolo è il seguente: LDO = LC/LOC dove LC = numero delle linee di commento; LOC = numero delle linee di codice; Il valore di LDO va espresso in percentuale.

Regole di Intero più prossimo.



Pag. 27




Indicatore/Misura Livello di documentazione – LDO

arrotondamento


25% < LDO

Azioni contrattuali 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.

Eccezioni NA



Pag. 28

Indicatore 5: Facilità d’uso – FUSO



Usabilità / Operabilità

Indicatore/Misura 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.

Unità di misura Percentuale


Voto (in una scala predefinita) attribuito a ciascuna risposta del questionario

Periodo di riferimento 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.

Formula di calcolo

Dati necessari: numero utenti soddisfatti (USOD), per ogni applicazione numero utenti selezionati (USEL), per ogni applicazione

100USEL

USODFUSO

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.

Obiettivi (valori soglia) FUSO ≥ 70 nella fase di analisi FUSO ≥ 90 nella fase di consegna e collaudo

Azioni contrattuali Il raggiungimento del valore soglia conferma l’accettazione del prodotto; in mancanza si attiva la richiesta di revisione.

Eccezioni NA

Indicatore 6: Efficienza di rimozione errori – RERR



Affidabilità / ripristinabilità

Indicatore/Misura Efficienza di rimozione errori – RERR



Pag. 29






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

Unità di misura RERRBL, RERRNBL = percentuale. T = ora


Nr malfunzioni rilevate per Tipo; Nr interventi di rimozione effettuati con esito positivo; Tempo di rimozione e ripristino.

Periodo di riferimento Nel corso dell’avviamento / diffusione.


In base alle caratteristiche dell’applicazione può essere stabilita la frequenza di misura nell’arco temporale dell’avviamento / diffusione.

Regole di

campionamento NA

Formula di calcolo

Malfunzioni rimosse nel tempo limite (valori espressi come percentuale):

RERRBL= MBLrimossi/ MBLrilevati

RERRNBL= MNBLrimossi/MNBLrilevati

dove:

MBLrimossi/rilevati = numero totale delle Malfunzioni Bloccanti rimosse nel tempo limite /

rilevate nel periodo di osservazione;

MNBLrimossi/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.

Obiettivi 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).



Pag. 30





(valori soglia) 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 = 16 – 24 ore. 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.

Azioni contrattuali

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.

Eccezioni L’applicazione delle regole contrattuali può iniziare dopo un periodo di osservazione dall’inizio dell’avviamento / diffusione (esempio, della durata di 1-2 mesi).

3.12 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. 3.11 Qualità della fornitura, compresi i relativi livelli

di servizio e penali che si intendono aggiuntive rispetto a quelle riportate nel seguito .



Pag. 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,00 .

4.4 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:



Pag. 32

Classe Valori di Soglia

Importo Penale

Per ogni punto percentuale in diminuzione rispetto ai valori di soglia, nel periodo di osservazione

1 3 ore nel 98% dei casi; 6 ore nel restante 2%

1% del valore contrattuale del servizio nel periodo di osservazione


0,5% 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à.



Pag. 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 385

5.1 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%


Figura professionale per i servizi di assistenza

sistemistica/Data Base Administration % di impiego

Sistemista 70%

Data Base Administrator 30%



Pag. 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%


Capo Progetto

Titolo di studio Laurea in discipline economiche o tecniche

Esperienze lavorative 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.

Ruolo 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



Pag. 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 amministrativo-

contabili (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 Diploma/Laurea in discipline tecniche

Esperienze lavorative 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.



Pag. 36

Sistemista





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



Pag. 37

Data Base Administrator





Ruolo 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


Esperienze lavorative 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.

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



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



Pag. 39

pagamento effettuato e non registrato

pagamento effettuato con anomalie compensabili

istanza generica

Modifiche moduli B/C17 d’ufficio4

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



Pag. 40

Entità 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.

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.

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.

Cooperativa

Comunicazioni Amministrazione

Istanza

Accertamento



Pag. 41

Esempio

Cooperativa

Accertamento

Istanza

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

6.3.1 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

n. 10245 periodo 2007 - 2008

n. 913 Istanza di tipo B

ABC Sociale

n. 11878 periodo 2009 - 2010

n. 872 Istanza di tipo A



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

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

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



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

6.5.1 Accertamenti – note di cortesia

6.5.1.1 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’albo5 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



Pag. 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 dovuto6, 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.

6.5.2.1 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”.



Pag. 45

6.5.2.2 Visualizzazione delle note di cortesia

L’utente potrà visualizzare l’elenco delle note di cortesia inviate dall’amministrazione.



Pag. 46

6.5.3 Gestione delle istanze

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



Pag. 47



Pag. 48

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

6.5.3.2.1 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



Pag. 49

6.5.3.2.2 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



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

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

6.5.3.2.3.1 Comunicazione



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



Pag. 52

Il Nuovo Sistema consentirà la visualizzazione degli allegati alla comunicazione relativa all’istanza

selezionata



Pag. 53

6.5.3.2.3.2 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).

6.5.3.2.3.3 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).



Pag. 54

6.5.3.2.3.4 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



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



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



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

6.5.3.2.3.5 Amministratori

L’utente potrà visualizzare l’elenco degli amministrazioni con indicazione di:

Nome e cognome

CF

Carica

Periodo della carica (da/a)



Pag. 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).

6.5.3.2.3.6 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



Pag. 59



Pag. 60

6.5.3.2.3.7 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)

6.5.3.2.3.8 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



Pag. 61



Pag. 62

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

6.5.3.3.1 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 pre-

definito 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 funzionale7.

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



Pag. 63

Al termine, mediante l’apposito pulsante, potrà sottoporre alla firma del dirigente l’accettazione

dell’istanza.

6.5.3.3.2 importo non dovuto: la società ha sede in una Regione a Statuto Speciale


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.


anagrafiche inserendo i corretti periodi in cui la società ha avuto sede nella Regione a Statuto Speciale.


definito al quale il funzionario potrà aggiungere delle note esplicative per la cooperativa. Tale documento




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


dell’istanza.

6.5.3.3.3 importo non dovuto: la cooperativa è aderente ad una associazione


contributo contestato aderiva ad una associazione riconosciuta, verrà presentata all’utente la attuale

situazione anagrafica registrata sul sistema Parix- COSE.

Camera di Commercio

CCIAA

CCIAA

Camera di Commercio

Camera di Commercio

Camera di Commercio



Pag. 65


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.


definito al quale il funzionario potrà aggiungere delle note esplicative per la cooperativa. Tale documento




Pag. 66


dell’istanza.

6.5.3.3.4 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



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



Pag. 68


dell’istanza.

6.5.3.3.5 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 6.5.3.3.4 (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.



Pag. 69


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.



Pag. 70

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



Pag. 71

6.5.4 Gestioni ruoli

6.5.4.1 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 cooperative8:

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.

6.5.4.2 Gestione ricorsi

Le modalità di gestione dei ricorsi saranno oggetto di specifica in sede di Analisi Funzionale del Nuovo

Sistema.

6.5.5 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 e-mail al commissario liquidatore9.

8 attive sul Registro Imprese

9 Il testo della comunicazione sarà specifico in base al provvedimento sanzionatorio/procedura concorsuale in essere



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



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

funzionale10.

6.5.7 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 6.5.3.2.3 (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



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



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



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



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



Pag. 78

6.6.2 Architettura di dettaglio

Scheda Prodotto

Prodotto Versione

Oracle BPM Suite 11.1.1.0

Oracle SOA Suite 11.1.1.0

Oracle Enterprise Manager 11.1.1.0

Oracle Service Bus 11.1.1.6

Oracle WMS policy Manager 11.1.1.0

Oracle JRF WebService Asyncronous services 11.1.1.0

Web Logic Server 10.3.6.0

Web Center Content 11.1.1.0

Oracle Portal 11.1.1.0



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

Sicoop

DB Oracle

Cose

Parix

Portale

Coop

FoliumCS

(Div V e VI)

Adam

JDBC JDBC API

WS

Protocollo

WS

WS

WS



Pag. 80

6.7.1 Portale cooperative

6.7.1.1 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 cooperativa11

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.

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

6.7.2 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



Pag. 81

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


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.

6.7.3 Sistema gestionale Divisione V - Vigilanza

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



Pag. 82


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

6.7.4 Sistema gestionale Divisione VI provvedimenti sanzionatori

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


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 6.5.5 (Insinuazione passivo) il Nuovo Sistema notificherà la decisione

di insinuazione nel passivo della società cooperativa al commissario liquidatore della Divisione VI

competente (es. tramite e-mail, oppure aggiornamento base dati Sicoop).

6.7.5 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

6.7.6 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)



Pag. 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)

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

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

6.7.10 Schema di sintesi interazioni applicative del Nuovo Sistema



Pag. 84

L’immagine riassume le interazioni descritte nei paragrafi precedenti.

Ministero dello Sviluppo Economico · Architettura tecnica: Il risultato dell’attiità è...

Documents

Transcript of Ministero dello Sviluppo Economico · Architettura tecnica: Il risultato dell’attiità è...