Scheda descrittiva del programma SI_POAT_DAGL
ceduto in riuso
Presidenza del Consiglio dei Ministri – Dipartimento per gli Affari
Giuridici e Legislativi
1
SEZIONE 1 – CONTESTO ORGANIZZATIVO1.1 Generalità
1.1.1 Identificazione e classificazione dell’amministrazione cedente Ä Amministrazione cedente
Presidenza del Consiglio dei Ministri – Dipartimento per gli Affari Giuridici e Legislativi
Ä Amministrazione cedente – Sigla: PCM - DAGL
Ä Tipologia di Amministrazione cedente: Amministrazione centrale
1.1.2 Identificazione e classificazione dell’Oggetto Ä Oggetto offerto in riuso
Sistema gestionale on-line a supporto della digitalizzazione dei processi di analisi di impatto ed alla digitalizzazione delle pratiche di better regulation, realizzato nell’ambito del POAT-DAGL
Ä Oggetto offerto in riuso - Sigla SI_POAT_DAGL
Ä Tipologia di Oggetto offerto in riuso:
Altro: Applicativo a supporto del processo di Normazione Ä Note: Nessuna
Ä Collocazione funzionale dell’Oggetto.
L’Oggetto realizza funzioni a livello di:Processo
Ä Tipologia di licenza dell’Oggetto offerto: Software libero
Ä Modalità di implementazione dell’Oggetto ceduto in riuso:
Realizzazione ex-novo su specifiche dell’amministrazione Ä Oggetto/i di cessione in riuso: Oggetto o parte di esso
1.1.3 Referenti dell’amministrazione cedente
Ä Responsabile dei sistemi informativi
• Nome e cognome:
• Indirizzo:
• Tel/Cel:
• e-mail:
Andrea Bertagnoli
Via della Mercede, 96 – 00187 Roma 06.6779.4097
a.bertagnoli@palazzochigi.it Ä Referente/i di
progetto
• Nome e cognome:
• Indirizzo:
• Tel/Cel:
• e-mail:
Amadio Salvi
Piazza Colonna, 370 – 00187 Roma 06.6779.3440
a.salvi@governo.it Ä Referente/i
amministrativo
• Nome e cognome:
• Indirizzo:
• Tel/Cel:
• e-mail:
Edoardo Cervone
Piazza Colonna, 370 – 00187 Roma 06.6779.4724
e.cervone@governo.it
1.2 Scenario di riuso
1.2.1 Ambito amministrativo interessato
Pubblicazione in rete di Norme, di Avvisi, Bandi e Gare Trasparenza
1.2.2 Utenti fruitori dell’Oggetto
Numero totale di Utenti che utilizzano l’Oggetto: 400
Ä Contesto organizzativo
Il SI_POAT_DAGL consente l’applicazione delle principali tecniche di miglioramento della normazione, quali: Analisi di Impatto della Regolazione (AIR), Valutazione di Impatto della Regolazione (VIR), Analisi Tecnico/Normativa (ATN) e Drafting Normativo. L’applicazione traduce dunque in termini informatici le principali competenze del Servizio AIR del Dipartimento per gli Affari Giuridici e Legislativi (DAGL) della Presidenza del Consiglio dei Ministri (PCM).
Ä Obiettivi perseguiti
Favorire le attività di consultazione delle fonti statistiche rilevanti, delle variabili di contesto più significative, degli strumenti operativi più idonei ai fini dell’analisi e del miglioramento dei processi di normazione (schede di rilevazione, check list di monitoraggio, manuali, linee guida, relazioni, modelli di valutazione)
Supportare la digitalizzazione dei processi di analisi e valutazione d’impatto condotti sia dalle Amministrazioni nazionali che dalle Regioni
Favorire lo sviluppo di una comunità in ottica divulgativo-formativa (forum, questionari on- line, notice and comment, moduli e-learning)
Gestire e rendere disponibili esiti, output e deliverables del progetto Ä Aspetti dimensionali
Numero totale di Function Point dell’Oggetto: 1.050
Altro: circa 250 classi Java e 17.000 LOC Java e circa 175 classi Ruby e 6000 LOC Ruby.
1.2.3 Descrizione delle funzionalità
Il modulo gestionale consente un’ efficace gestione informatizzata di numerosi processi, sia direttamente connessi all’AIR e alle altre tecniche di better regulation, sia di carattere accessorio, cui potranno essere associati specifici sottomoduli dell’applicazione.
Nome Descrizione Dati
Input Output Ricognizione dei
fabbisogni normativi
Vengono gestiti e controllati i provvedimenti e/o istanze normative in atto presso i singoli settori Procedure di
consultazione on line
Gestire procedure di consultazione on line le attraverso lo strumento del notice & comment,
pubblicando tutta la documentazione relativa al provvedimento oggetto di consultazione, nonché i risultati della stessa
Redazione dell’ATN L’utente viene supportato nella redazione dell’ATN attraverso una apposita griglia metodologica disponibile nel sottomodulo gestionale relativo all’Analisi tecnico normativa Definizione di
processi di AIR e VIR
L’utente viene supportato nella definizione di processi di AIR e VIR attraverso la consultazione di documenti metodologici e best practice, collegamenti a banche dati esterne organizzate per ambiti tematici e attraverso la possibilità di scaricare “schede tipo” compilabili Consultare e/o
scaricare i dati importati nel sistema
Consultare e/o scaricare i dati importati nel sistema da banche dati esterne e organizzati per ambiti tematici
Elaborazione di indicatori a supporto delle valutazioni
I dati presenti nel sistema potranno essere utilizzati come base per l’effettuazione delle analisi ed elaborazione di indicatori a supporto delle valutazioni
1.2.4 Servizi o procedure implementati/e
Nome servizio Descrizione sintetica Destinatari del servizio (**)
Portale di front- end
Divulgazione della documentazione, delle notizie, degli eventi inerenti le attività di better regulation
Consultazione pubblica mediante sondaggi, questionari, forum e notice & comments
Cittadini Imprese
Liberi professionisti Personale della PA Altre PA
CMS del
Portale Gestione dei contenuti del Portale Personale della PA
Consultazioni Gestione delle proposte normative e delle consultazioni pubbliche o ad accesso riservato
Cittadini Imprese
Liberi professionisti Personale della PA Altre PA
Pannello di controllo
Gestione delle configurazioni e delle utenze del sistema
Personale della PA
Normazione Censimento del fabbisogno normativo e delle schede normative
Personale della PA Altre PA
ATN Gestione delle informazioni relative ai processi di ATN
Personale della PA Altre PA
AIR/VIR Gestione delle informazioni relative ai processi di AIR/VIR
Personale della PA Altre PA
Cruscotto personale
Utilità di gestione banche dati, elaborazione indicatori, interrogazione dei dataset esposti da ISTAT
Personale della PA Altre PA
1.2.5 Tipologia di contratto
La piattaforma è stata realizzata nell’ambito del più generale Progetto Operativo di Assistenza Tecnica (POAT) avente ad oggetto “Assistenza tecnica alle Regioni dell’obiettivo convergenza per il rafforzamento delle capacità di normazione”. Il contratto è stato stipulato, a seguito dell’esperimento di una gara europea, con un RTI fra Ernst&Young, PA Advice, Consorzio MIPA e Luiss Management. Le attività di progettazione e sviluppo informatico sono state curate all’interno del RTI dalla PA Advice. L’applicazione è nella piena titolarità della PCM-DAGL che ne può pienamente disporre senza alcuna limitazione avendo proprietà e piena disponibilità del codice sorgente.
1.2.6 Tipologia di benefici economici ottenuti dall’amministrazione con l’uso dell’Oggetto
Ä Diretti :
Altro: tracciamento del processo normativo e del ciclo della normazione
Ä Indiretti :
Altro: incremento della trasparenza delle politiche attuate
1.2.7 Amministrazioni che riutilizzano l’Oggetto
Nell’ambito del POAT DAGL, l’applicazione è già in uso presso le quattro Regioni dell’Obiettivo Convergenza (Calabria, Campania, Puglia e Sicilia), presso le quali sono in atto personalizzazioni del sistema, che ne adattino contenuti e funzionalità alle specifiche esigenze.
1.2.8 Amministrazioni interessate al riuso dell’Oggetto
Possono essere interessate al riuso della piattaforma ulteriori Amministrazioni regionali, grandi Comuni, Amministrazioni centrali ed Enti Indipendenti (quali le Authority).
1.2.9 Amministrazioni idonee al riuso dell’Oggetto Comuni grandi
Province Regioni
Amministrazioni centrali
1.2.10 Motivazioni che indussero l’amministrazione a implementare l’Oggetto Norma primaria
Regolamento nazionale
1.2.11 Costi sostenuti per l’implementazione e la manutenzione dell’Oggetto Ä Costo totale dell’Oggetto, (analisi e specifica requisiti, progettazione tecnica, codifica,
test e integrazione, installazione, esercizio) € 240.000 di cui interni, 0 €
Ä Costo esterno dell’Oggetto, (componenti proprietarie utilizzate dall’Oggetto ceduto in riuso, quali, ad esempio, RDBMS, Middleware, Componenti specializzati, etc) € 0 Ä Costo annuo della manutenzione correttiva: € n.a. di cui:
• costi interni, € n.a
• costi esterni, € n.a
Ä Nota: Nessuna
1.2.12 Time line del progetto
Ä Durata dell’intero progetto: 24 mesi
Ä Data di primo rilascio: aprile/ 2012 Ä Data di rilascio ultima evolutiva: n.a/ n.a Ä Data di rilascio ultima correttiva: n.a/ n.a
1.2.13 Link al sito dove è descritto l’intero progetto che ha prodotto l’Oggetto http://www.qualitanormazione.gov.it
1.2.14 Competenze sistemistiche e applicative richieste per l’installazione dell’Oggetto.
Elencare di seguito le competenze sistemistiche necessarie per installare e gestire l’Oggetto Conoscenza dei sistemi operativi Linux, delle interfacce di rete e delle modalità di conduzione operativa di tali sistemi in esercizio di produzione.
Conoscenza degli ambienti e le applicazioni basati su Java Virtual Machine e l'interprete Ruby
Conoscenza degli applicativi Red HAT Jboss, Apache Http web server, Mod Rails.
Conoscenza dei DBMS MySQL e Oracle
1.2.15 Vincoli relativi all’installazione ed alla fruizione dell’Oggetto
La piattaforma è completamente compatibile con i sistemi operativi Linux e potrebbe non essere completamente compatibile con i sistemi operativi Windows, e' pertanto vivamente consigliato l'utilizzo di sistemi Linux.
1.2.16 Elementi di criticità
Nessun elemento di criticità riscontrato
1.2.17 Punti di forza
Sistema di Single Sign-On basato sul prodotto open source Josso attraverso il quale è possibile integrare, sotto un unico strumento di autenticazione, componenti sviluppati con tecnologie differenti
Sistema centralizzato di gestione configurabile delle notifiche via email Integrazione con le banche dati esposte da ISTAT
Supporto alla definizione di indicatori per AIR e VIR anche con strumenti e formule di statistica avanzata
1.2.18 Livello di conoscenze/competenze ICT del personale dell’amministrazione cedente
Medio
1.2.19 Disponibilità dell’amministrazione cedente Fornire assistenza ICT all’amministrazione utilizzatrice
1.2.20 Modalità di riuso consigliate Riuso in cessione semplice
2
SEZIONE 2 – CONTESTO APPLICATIVO2.1 Qualità globale della documentazione di progetto
2.1.1 Documentazione disponibile Analisi e progettazione del portale di front-end Analisi della piattaforma gestionale di back-end Progettazione della piattaforma gestionale di back-end Manuale utente
Manuale di installazione e gestione Piano di test e collaudo
2.1.2 Livello di documentazione
Documentazione complessivamente esauriente e completa
2.2 Requisiti
2.2.1 Specifica dei requisiti funzionali
La specifica dei requisiti funzionali: è disponibile e contiene i capitoli indicati nella tabella seguente anche se ordinati in modo diverso;
Descrizione capitolo %
Glossario delle definizioni e acronimi utilizzati o riferimento al glossario del progetto 100 Attori coinvolti, con la specificazione del numero e della tipologia degli utenti coinvolti 100
Classificazione dei requisiti funzionali 50
Codifica (attributi) dei requisiti funzionali 0
Correlazione alle specifiche dei casi d’uso 0
Eventi coinvolti nel requisito 50
Componenti hardware e Oggetto dell’architettura complessiva del sistema che si intende realizzare
100
Analisi dei dati - schema concettuale iniziale 100
Analisi dei dati - stima iniziale dei volumi 100
Evidenza e descrizione delle modifiche in corso d’opera 100
Riferimenti a ulteriore documentazione di interesse prodotta o preesistente 100
2.2.2 Specifica dei requisiti non funzionali
La specifica dei requisiti non funzionali: non è disponibile
2.2.3 Specifica dei requisiti “inversi”
La specifica dei requisiti inversi: non è disponibile 2.2.4 Casi d’uso
La specifica dei casi d’uso correlata ai requisiti funzionali: non è disponibile
3
SEZIONE 3 – CONTESTO TECNOLOGICO3.1 Progettazione
3.1.1 Studio di fattibilità
Lo studio di fattibilità: non è disponibile
3.1.2 Architettura logico funzionale dell’Oggetto
L’architettura logico funzionale dell’Oggetto: è disponibile, è descritta in modo discorsivo e contiene i capitoli indicati nella tabella seguente anche se ordinati in modo diverso
Descrizione capitolo %
Descrizione dei sottosistemi funzionali 100
Descrizione, per ciascun sottosistema, del modello logico-funzionale del Oggetto:
o Sottosistemi applicativi, 100
o Strutture di dati e relativi attributi 100
Descrizione, per ciascun sottosistema, del modello delle responsabilità funzionali (comportamento statico del sw):
o Classi che lo compongono, con relativi metodi e attributi 0
o Casi d’uso dell’applicazione 0
Descrizione, per ciascun sottosistema, del modello dei processi eseguito dal sistema/Oggetto (comportamento dinamico dell’Oggetto):
o Interfacce verso altri sistemi/programmi 100
o Esposizione di interfacce standard di interoperabilità 100 o Indipendenza delle componenti applicative utilizzate, ovvero presenza di criticità 100 o Impiego di interfacce utente aderenti agli standard di usabilità 100 o Indipendenza delle classi di interfaccia dal browser utilizzato 100 o Indipendenza delle classi di accesso dal RDBMS utilizzato 100 Descrizione, per ciascun sottosistema, del modello comportamentale (diagramma degli
stati) dove sono referenziati gli eventuali riferimenti normativi delle procedure amministrative informatizzate
0
Ä Descrizione dell’architettura software
Il sistema è basato su due componenti principali: il portale di front-end e il gestionale di back- end. Questi due elementi condividono il sistema di gestione delle utenze, basato su Josso.
Entrambi, inoltre, poggiano sul gestore documentale che, trasversalmente a tutto il sistema, gestisce la persistenza dei dati
3.1.3 Architettura hardware dell’Oggetto
L’architettura hardware dell’Oggetto: : è disponibile, è descritta in modo discorsivo e contiene i capitoli indicati nella tabella seguente anche se ordinati in modo diverso
Descrizione capitolo %
Parametri dimensionali minimi:
o Potenza di calcolo 100
o RAM 100
Sistema operativo 100
Deployment del sistema/Oggetto 100
Middleware 100
Librerie esterne 100
RDBMS 100
Ä Descrizione dell’architettura hardware L'Architettura del sistema è organizzata a tre livelli.
1)Livello di presentazione: Web Server, implementato con Apache HTTPD
2)Livello di applicazione: Application Server, implementato con Red Hat jboss e Mod Rails 3)Livello dei DATI: Data Server, implementato con il DBMS scelto es. MySQL, Oracle L'architettura può essere scalata ad ogni singolo livello o a più livelli. La piattaforma nella totalità è distribuibile in ambienti virtualizzati.
3.1.4 Architettura TLC dell’Oggetto
L’architettura di telecomunicazione dell’Oggetto: non è disponibile
3.2 Realizzazione
3.2.1 Manualistica disponibile Manuale utente
Manuale di installazione e gestione del sistema
3.2.2 Case – Computer aided software engineering Nessun Case
3.2.3 Ciclo di sviluppo Rational Unified Process
3.2.4 Standard utilizzati
Per il testing della sicurezza si è fatto riferimento a OWASP
3.2.5 Linguaggio di programmazione
Il portale di front-end è stato sviluppato in Ruby on Rails.
Il gestionale di back-end è stato sviluppato in Java/J2EE
3.3 Test e collaudo
3.3.1 Specifiche dei test funzionali e non funzionali Le specifiche dei test dell’Oggetto: non sono disponibili
3.3.2 Livello di copertura dei test rispetto ai requisiti da valutare
Al fine di valutare quantitativamente il livello di copertura dei test rispetto ai requisiti da valutare, l’amministrazione cedente fornisce le seguenti coppie di valori in suo possesso:
Ä Numero totale di requisiti funzionali: n.a
Ä Numero di requisiti funzionali sottoposti a test: n.a Ä Numero totale di requisiti non funzionali: n.a.
Ä Numero di requisiti non funzionali sottoposti a test n.a
3.3.3 Piano di test;
Il piano di test dell’Oggetto: è disponibile, è descritto in modo discorsivo e contiene i capitoli indicati nella tabella seguente anche se ordinati in modo diverso
Descrizione capitolo %
Glossario delle definizioni e acronimi utilizzati o riferimento al glossario del progetto 100 Tecniche utilizzate per la progettazione e l’esecuzione dei test 100 Tipologie di test cui sarà sottoposto ogni componente dell’Oggetto, con i criteri di ingresso e uscita da ogni test
100 Il processo di testing adottato - Attività e Sottoattività previste 100
Componenti dell’Oggetto da sottoporre a verifica 100
Livello di copertura dei test 100
Metriche da utilizzare 0
Numero di cicli di test previsti 0
Livello di rischio (classe di rischio) associato a ogni test 0
Legame eventuale con altri processi presenti nell’Oggetto 100
Mappatura con requisiti (funzionali e non) e gli attributi definiti 0 Risorse professionali e strumentali che verranno impiegate per l’effettuazione di
ogni test (ruoli e responsabilità)
0 Modalità di esecuzione, di registrazione dei risultati dei test, dei difetti rilevati e di rendicontazione dei test
100
Modalità di gestione delle anomalie 0
Pianificazione temporale dei test con indicazione del tempo stimato per l’esecuzione di ogni singolo test
0 Riferimenti eventuali a ulteriore documentazione di interesse prodotta o preesistente 100
3.3.4 Specifiche di collaudo
Le specifiche di collaudo dell’Oggetto: sono disponibili, descritte in modo discorsivo e contengono i capitoli indicati nella tabella seguente anche se ordinati in modo diverso
Descrizione capitolo %
Strategia, metodologia e obiettivi del collaudo 100
Specificazione dei requisiti dell’hardware e dell’Oggetto di base e dei vincoli dell’ambiente di collaudo
100 Documentazione dei casi di test:
o Setup ( requisiti per avviare il test ) 100
o Sequenza delle azioni da svolgere utente/macchina 100
o Riesecuzione (eventuale) per condizioni diverse 0
o Altre verifiche per accertare l’esito dei test 0
Elenco dei test con evidenza della copertura rispetto ai requisiti e al rischio 0 Descrizione dei test formali, funzionali, non funzionali da eseguire, con particolare attenzione ai test specifici per la validazione dei requisiti
100 Descrizione dei test automatici eventualmente realizzati e delle modalità di impiego 0
Le metriche ed indicatori di qualità e relative soglie 0
I criteri di accettazione da parte dell’Amministrazione 100
I contenuti previsti nei verbali di collaudo 100
3.4 Installazione, uso e manutenzione
3.4.1 Procedure di installazione e configurazione
Le procedure di installazione e configurazione dell’Oggetto: sono disponibili, descritte in modo discorsivo e contengono i capitoli indicati nella tabella seguente anche se ordinati in modo diverso
Descrizione capitolo %
Verifiche preliminari e ex post 100
Livelli di automazioni necessari 100
Procedure di caricamento o porting della base informativa 100
3.4.2 Manuale di gestione
Il manuale di gestione dell’Oggetto: è disponibile ed è descritto in modo discorsivo Ä Indice del manuale di gestione
1) Introduzione alla gestione e alla conduzione operativa del sistema 2) Verifiche e controlli
2.1) Check List periodica 2.2) Check list quotidiana 3) Procedure di
3.1)startup 3.2)Shutdown 3.3) restart
4) Risoluzione e diagnosi dei problemi comuni;
5) Report periodico sullo stato del sistema
3.4.3 Manuale utente
Il manuale utente fornisce una descrizione generale dell’applicazione e una guida operativa all’utilizzo delle singole funzionalità dell’Oggetto utilizzabili dall’utente.
Il manuale utente dell’Oggetto: è disponibile ed è descritto in modo discorsivo Ä Indice del manuale utente
1. Introduzione 2. Portale di front-end
2.1 Il portale
2.2 Amministrazione Portale di front-end (CMS) 3. Gestionale di back-end
3.1 Gestione Normazione 3.2 Gestione Consultazioni 3.3 Modulo AIR/VIR 3.4 Modulo ATN
3.5 Il Cruscotto Personale 3.6 Il Pannello di Controllo
4
SEZIONE 4 – QUALITÀ DELL’OGGETTO4.1 Piano di qualità
4.1.1 Contenuti del piano
Il piano di qualità dell’Oggetto: non è disponibile
4.1.2 Descrizione della qualità
Sviluppo nel rispetto della metodologia RUP.
Utilizzo di un sistema di ticketing per la definizione della road map e il tracciamento delle issue e e dei bug da implementare/risolvere per ciascuna versione/milestone del software Rispetto della normativa vigente sull’accessibilità delle applicazioni per le Pubbliche Amministrazioni
4.2 Profilo di qualità dell’Oggetto
Al fine di valutare quantitativamente gli attributi per la valutazione della qualità dell’Oggetto, l’amministrazione cedente fornisce i seguenti valori in suo possesso:
4.2.1 Modularità
Ä Numero di componenti auto consistenti dell’Oggetto: 3 Ä Numero totale di componenti dell’Oggetto: 4
4.2.2 Funzionalità
4.2.2.1 Interoperabilità - Protocolli di comunicazione
Ä Numero dei protocolli di comunicazione dei sistemi/programmi con i quali l’applicazione deve poter colloquiare: 1
Ä Numero dei protocolli di comunicazione correttamente implementati (ovvero che hanno superato i relativi test) all’interno dell’Oggetto: _1
4.2.3 Maturità
Il valore del requisito è determinato dalla concorrenza dei seguenti attributi elementari.
4.2.3.1 Densità dei guasti durante i test Ä Numero di guasti rilevati durante i test: 0 Ä Numero di casi di test eseguiti: circa 400
4.2.3.2 Densità dei guasti
Ä Numero di guasti rilevati durante il primo anno di esercizio dell’Oggetto: 0 Ä Numero totale di FP dell’Oggetto: 1.050
4.2.4 Usabilità
Il valore del requisito è determinato dalla concorrenza dei seguenti attributi elementari.
4.2.4.1 Comprensibilità – Completezza delle descrizioni Ä Numero di funzioni descritte nel manuale utente: 8 Ä Numero totale di funzioni: 8
4.2.4.2 Apprendibilità - Esecuzione delle funzioni
Ä Numero di funzioni che sono state eseguite correttamente dall’utente consultando la documentazione: 8
Ä Numero di funzioni provate: 8
4.2.4.3 Apprendibilità- Help on-line
Ä Numero di funzioni per le quali l’help on-line è correttamente posizionato: n.a Ä Numero di funzioni provate: n.a
4.2.4.4 Configurabilità
Ä Numero totale di parametri di configurazione: circa 20 Ä Numero totale di funzioni: 8
4.2.5 Manutenibilità
Il valore del requisito è determinato dalla concorrenza dei seguenti attributi elementari.
4.2.5.1 Conformità allo standard di Progettazione
Ä Numero di deviazioni dagli standard di progettazione n.a Ä Numero dei diagrammi progettuali realizzati n.a
4.2.5.2 Conformità agli standard di codifica
Ä Numero di deviazioni dallo standard di codifica n.a Ä Numero di linee di codice esaminate: n.a
4.2.5.3 Analizzabilità - Generale
Ä Numero totale di commenti: circa 500
Ä Numero totale di linee di codice: circa 23.000
4.2.5.4 Testabilità - Generale
Ä Numero di funzioni con associato almeno un caso di test: 8 Ä Numero totale di funzioni elementari: 8
4.2.5.5 Testabilità - Automatismi
Ä Numero di casi di test automatizzati con opportune funzioni di test interne:n.a Ä Numero totale di casi di test: n.a
4.2.6 Portabilità
Il valore del requisito è determinato dalla concorrenza dei seguenti attributi elementari.
4.2.6.1 Adattabilità– Strutture dei dati
Ä Numero di strutture dati trasferibili tra DB commerciali senza modifiche 4 Ä Numero totale strutture dati: 4
4.2.6.2 Adattabilità – Funzioni e organizzazione
Ä Numero di funzioni indipendenti dalla organizzazione dell’amministrazione:8 Ä Numero totale di funzioni: 8
4.2.6.3 Installabilità Generale
Ä Numero di step di installazione descritti nel manuale di installazione 12 Ä Numero totale di step di installazione 12
4.2.6.4 Installabilità - Automatizione delle procedure
Ä Numero di step automatizzati descritti nel manuale di installazione:4 Ä Numero totale di step di installazione 12
4.2.6.5 Installabilità - Multiambiente
Ä Numero totale degli ambienti operativi nel quale l’Oggetto può essere installato per i quali l’Oggetto dispone di funzioni di installazione 1
Ä Numero totale degli ambienti operativi su cui può essere installato 1
5
SEZIONE 5 – FORMAZIONE5.1 Costi sostenuti per la formazione
• Costo totale della formazione: € 50.000
• Costi interni: € 0 di cui:
Ä Costi per i docenti, € 0
Ä Costi per il materiale didattico, € 0
• Costi esterni: € 50.000 di cui:
Ä Costi per i docenti, € 45.000
Ä Costi per il materiale didattico, € 5.000
5.2 Dati quantitativi
Numero di giorni di formazione in aula per utente erogati: 10 Numero di giorni di “training on the job” per utente erogati,: 150 Numero totale di utenti formati 400
Numero totale di dipendenti dell’ufficio o sezione o area o direzione o dipartimento o ……
utilizzatori dell’Oggetto descritto nella presente scheda 400
Numero totale di docenti interni impegnati nella formazione in aula: 0 Numero di docenti interni impegnati nella attività di training on the job: 0 Numero di docenti esterni impegnati nella formazione in aula: 10
Numero di docenti esterni impegnati nella formazione training on the job: 20___
5.3 Descrizione dell’azione formativa
La formazione ha avuto luogo nell’ambito del POAT “Assistenza tecnica alle Regioni dell’obiettivo convergenza per il rafforzamento delle capacità di normazione” ed ha coinvolto a vario titolo gli utenti delle Regioni Convergenza (Calabria, Campania, Puglia e Sicilia), nell’ambito del più complessivo aggiornamento professionale previsto dal POAT.
5.4 Materiale didattico
Per la predisposizione del materiale didattico:
• sono stati descritti i profili utente dell’applicativo;
• sono stati descritti i profili di competenza necessari;
