ACI Informatica S.p.A. Capitolato tecnico per …...ACI INFORMATICA S.p.A. Gara per l’affidamento...

ACI INFORMATICA S.p.A.

Gara per l’affidamento del servizio di progettazione, realizzazione e manutenzione di componenti software nell’ambito delle applicazioni per la gestione del Sistema Federazione ACI

Pagina 1 di 46

ACI Informatica S.p.A. Capitolato tecnico per l’affidamento del servizio di progettazione,

realizzazione e manutenzione di componenti software nell’ambito delle applicazioni per la gestione del Sistema Federazione ACI

Allegato n. 5 al Disciplinare di gara



Pagina 2 di 46

Indice

1 Premessa ........................................................................................................................... 4

2 Definizioni .......................................................................................................................... 5

3 Descrizione del Sistema Federazione ACI ...................................................................... 6

3.1 Sottosistema Associazioni .......................................................................................................... 6

3.1.1 Descrizione del contesto ..................................................................................................... 6

3.1.2 Il quadro dei servizi............................................................................................................. 6

3.1.3 Architettura di riferimento .................................................................................................. 7

3.1.3.1 Tecnologia ...................................................................................................................... 7

3.1.3.2 Interfacce con gli utenti ............................................................................................ 8

3.1.3.3 Interfacce con altre applicazioni ............................................................................. 8

3.1.4 Architettura applicativa ....................................................................................................... 9

3.1.5 Le applicazioni ....................................................................................................................... 10

3.1.6 Gli utenti ........................................................................................................................... 12

3.1.7 Le dimensioni tecniche del Sistema Associazioni ................................................................. 12

3.2 Sottosistema Contabilità per gli AACC ................................................................................... 13

3.2.1 Descrizione del contesto ................................................................................................... 13

3.2.2 Il quadro dei servizi........................................................................................................... 13

3.2.3 Architettura di riferimento ..................................................................................................... 14

3.2.3.1Tecnologia ........................................................................................................................ 14

3.2.3.2 Interfacce con gli utenti .............................................................................................. 16

3.2.3.3 Interfacce con altre applicazioni ............................................................................... 16

3.2.4 Architettura Applicativa ......................................................................................................... 17

3.2.4.1 Applicazioni .................................................................................................................... 17

3.2.4.2 Utenti ............................................................................................................................... 17

3.2.4.3 Le dimensioni tecniche del sottosistema Contabilità per AACC .................................... 17

3.3 Sottosistema Pratiche .................................................................................................................... 19

3.3.1 Descrizione del contesto ........................................................................................................ 19

3.3.2 Il quadro dei Servizi ............................................................................................................... 19


3.3.3.1 Tecnologia .................................................................................................................... 19

3.3.3.2 Interfaccia con gli utenti ............................................................................................. 20

3.3.3.3 Interfacce con altre applicazioni ............................................................................... 20


3.3.4.1 Le Applicazioni ............................................................................................................ 20

3.3.4.2 Utenti ............................................................................................................................... 20

3.3.4.3 Le dimensioni tecniche del Sistema Pratiche .................................................................. 21

3.4 Sottosisema CSAI ........................................................................................................................ 22

3.4.1 Descrizione del contesto ........................................................................................................ 22

3.4.2.Il quadro dei Servizi ............................................................................................................... 22


3.4.3.1 Tecnologia .................................................................................................................... 22



Pagina 3 di 46

3.4.3.2 Interfaccia con gli utenti ............................................................................................. 23

3.4.3.3 Interfacce con altre applicazioni ..................................................................................... 23


3.4.4.1 Applicazioni .................................................................................................................. 24

3.4.4.2 Utenti ............................................................................................................................. 25

3.4.4.2 Le dimensioni tecniche del Sistema CSAI .............................................................. 25

4 Oggetto della fornitura .................................................................................................... 26

5 Durata della fornitura e piano di subentro .................................................................... 26

5.1 Durata della fornitura ............................................................................................................... 26

5.2 Piano di subentro ...................................................................................................................... 26

6 Modalità di dimensionamento delle attività .................................................................. 27

7 Sede e strumenti di lavoro .............................................................................................. 28

8 Ambienti di sviluppo ....................................................................................................... 29

8.1 Sottosistema Associazioni............................................................................................................. 29

8.2 Sottosistema Contabilità AACC ................................................................................................... 30

8.3 Sottosistema Pratiche .................................................................................................................... 30

8.4 Sottosistema CSAI ........................................................................................................................ 30

9 Modalità di conteggio dei function point ....................................................................... 31

10 Standard della qualità ..................................................................................................... 32

10.1 Profilo della qualità del Sistema Informativo FEDERAZIONE ACI .................................. 32

10.2 Standard della qualità per il codice sorgente ........................................................................ 37

11 Modalità di affidamento delle attività ............................................................................. 37

12 Servizi Informatici ............................................................................................................ 38

12.1 Nuovi sviluppi ...................................................................................................................... 38

12.1.1 Descrizione .................................................................................................................... 38

12.1.2 Modalità di consegna intermedia e finale...................................................................... 38

12.1.2.1 Consegna intermedia ................................................................................................. 38

12.1.2.2 Consegna finale ......................................................................................................... 38

12.1.3 Collaudo ........................................................................................................................ 39

12.2 Manutenzione evolutiva,adeguativa,migliorativa ................................................................. 40

12.2.1 Descrizione .................................................................................................................... 40

12.2.2 Modalità di consegna intermedia e finale...................................................................... 40

12.2.2.1 Consegna intermedia ................................................................................................. 40

12.2.2.2 Consegna finale ......................................................................................................... 41

12.2.3 Collaudo ........................................................................................................................ 41

12.3 Supporto tecnico nella definizione dei requisiti informatici. ................................................ 42

13 Sostituzione del personale dell’impresa ....................................................................... 43

14 Modifiche in corso d’opera ............................................................................................. 43

15 Risorse professionali ...................................................................................................... 44

16 Stima dei function point e dei giorni/persona richiesti ................................................ 45

17 Allegati ............................................................................................................................. 46



Pagina 4 di 46

1 Premessa ACI avvalendosi della propria Impresa tecnico-operativa, denominata ACI Informatica, provvede ad erogare i servizi verso i Soci dell’Automobile Club attraverso una rete distribuita su tutto il territorio nazionale di Automobile Club Provinciali e di Delegazioni ACI. Eroga anche servizi per la gestione delle attività proprie di ogni singolo Automobile Club necessarie a garantire il corretto funzionamento degli stessi all’interno della Federazione ed il rispetto degli adempimenti di legge previsti nei confronti della Pubblica Amministrazione. Eroga i servizi legati all’associazionismo direttamente agli utenti attraverso Internet.



Pagina 5 di 46

2 Definizioni

ACI Automobile Club Italia AC Automobile Club Provinciale AACC Automobile Club Provinciali FP Function Point (Punti funzione secondo lo standard IFPUG 4.3) IFPUG International Funcion Point Users Group PRA Pubblico Registro Automobilistico STA Sportello Telematico dell’Automobilista. Applicazione telematica per la presentazione

di formalità al PRA congiuntamente alle pratiche verso DTT nell’ambito del progetto di cooperazione tra ACI e DTT.

TT Trouble Ticket: scheda elettronica contenente tutte le informazioni inerenti la richiesta del cliente dei servizi del Sistema Federazione ACI (Delegazione, AC Provinciale) RS232 Standard di definizione di porte seriali VPOS Virtual POS Payment System VAS Servizi a valore aggiunto IBAN Codice contenete le coordinate bancarie complete di un conto corrente bancario



Pagina 6 di 46

3 Descrizione del Sistema Federazione ACI

3.1 Sottosistema Associazioni

3.1.1 Descrizione del contesto Il sistema per la gestione delle associazioni permette la vendita dei prodotti e servizi previsti dall’automobile Club D’Italia per i propri Associati. Le associazioni possono essere acquisite e gestite attraverso: La rete di vendita ACI (Automobile Club, da adesso in avanti denominati AACC e Delegazioni) Reti di vendita esterne (multicanalità) Internet (direttamente dal cittadino)

3.1.2 Il quadro dei servizi

La gestione del parco associativo prevede l’erogazione dei servizi di seguito riassunti:

• Acquisizione / Gestione delle associazioni presso : o i punti di vendita ACI (AACC e Delegazioni) o punti di servizi esterni ad ACI (Multicanalità) o direttamente dall’utente finale tramite canale internet

• Produzione e recapito ai soci ACI del materiale sociale previsto dal regolamento ACI (tessera associativa, rivista sociale)

• Gestione dei contratti per il rinnovo automatico dell’associazione e del pagamento delle tasse

automobilistiche attraverso: o Servizi erogati dall’AC tramite il sistema informativo o Gestione accordi tra ACI e soc. Partner (Diners / Citibank)

• Gestione delle campagne di loyalty (nazionali e locali) alle quali possono partecipare i soci ACI • Produzione statistiche:

o Nazionali (Datamart associazioni ) o Locali (cruscotto statistico in uso presso AACC e Delegazioni) o Gestione riepiloghi contabili per AACC

Gestione riepiloghi contabili per AACC



Pagina 7 di 46

3.1.3 Architettura di riferimento

3.1.3.1 Tecnologia

Dal punto di vista tecnologico le applicazioni sviluppate nel sistema “ASSOCIAZIONI” fanno riferimenti alle due seguenti specifiche: J2EE Microsoft .Net In entrambi i casi le due tecnologie vengono applicate ad applicazioni basate sul modello web a tre livelli (Three-tiers). Le interfacce utente sono di tipo web based. La logica di business viene incapsulata in componenti intermedi riusabili. I dati vengono memorizzati in database dedicati. Gli altri standard applicati, in entrambi gli scenari tecnologici sono: XML,DHTML.



Pagina 8 di 46

Più nel dettaglio è possibile dire che le applicazioni costruite su piattaforma J2EE, rispondono al pattern MVC(Model View Controller), che si compone dei seguenti strati: Una interfaccia utente sviluppata secondo le specifiche JSP; ovvero combinando codice server-side di tipo JAVA, con codice JavaScript e DHTML sul lato client. Nel pattern MVC tale strato rappresenta il View. Uno strato intermedio tra l’interfaccia e lo strato di business che si occupa di smistare le richieste utente ai vari componenti della business logic.Questo strato è costituito da una serie di servlet JAVA. Nel pattern MVC tale strato rappresenta il Controller. Uno strato di business interamente composto da beans JAVA, che incapsulano le regole aziendali dell’applicazione. Nel pattern MVC tale strato rappresenta il Model.Questo strato fornisce inoltre, attraverso strati SOAP(servizi web) accesso ai dati dei soci da parte di altre applicazioni. L’ultimo strato è rappresentato dalla base di dati, che si occupa di memorizzare tutti i dati relativi ai soci. Si tratta di una istanza Oracle 9i e l’accesso ai dati avviene attraverso package PL/SQL. Per quanto riguarda le applicazioni Microsoft, queste sono di tipo Web, realizzate su framework .Net con linguaggio VB.NET. Le applicazioni adottano un sistema multistrato così composto: Una interfaccia utente sviluppata secondo le specifiche ASP.NET; ovvero combinando codice server-side di tipo .NET (Vb.NET), con codice JavaScript e DHTML sul lato client. Lo strato business è rappresentato da un insieme di classi dette appunto “classi business” che incapsulano le regole aziendali dell’applicazione, sviluppate sfruttando il framework .NET con linguaggio VB.NET. Di questo strato inoltre, fanno parte applicazioni SOAP(servizi web) che garantiscono l’’interfacciamento dati provenienti da altre procedure. L’ultimo strato, quello considerato più “basso” dall’architettura multi-layer è rappresentato dal data-layer, anch’esso composta da un insieme di classi, denominate “classi data”. A questo strato sono delegate tutte le operazioni riguardanti l’inserimento e la modifica dei dati sull’archivio dati.

3.1.3.2 Interfacce con gli utenti Le interfacce utente delle applicazioni del sistema “Associazioni” sono di tipo web, consultabile attraverso un browser Internet in grado di processare codice DHTML. Le applicazioni dispongono di un foglio di stile (CSS- Cascading Style Sheet) per la formattazione grafica di tutte le pagine, in modo tale da assumere una certa uniformità e linearità. I siti web di tutte le applicazioni sono organizzati in tre frame: Frame di testata con le informazioni di accounting Frame di sinistra con le principali funzioni Frame centrale di lavoro.

3.1.3.3 Interfacce con altre applicazioni Le applicazioni del sistema “Associazioni” forniscono verso le altre applicazioni una serie di interfacce per la consultazione dei dati relativi ai soci. Dal punto di vista tecnologico le interfacce possono dividersi in due categorie:

Interfacce RMI(EJB), per l’accesso da parte di applicazioni JAVA



Pagina 9 di 46

Interfacce http(SOAP), per l’accesso da parte di applicazioni la cui piattaforma tecnologica sia diversa da quella JAVA.

Inoltre, vengono utilizzati dai prodotti del sistema “ASSOCIAZIONI” i servizi messi a disposizione dall’ applicazione “GT- Gestione Tabelle”, per la consultazione dei dati comuni, quali località e porti. La comunicazione fra le due applicazione avviene attraverso la specifica RMI(EJB).

3.1.4 Architettura applicativa

Ufficio Provinciale (AC)

Gestione Associazioni

Contratti On Line

Cruscotto statistico locale

Ufficio Delegazione

Gestione Associazioni

Statistiche Delegazione

Sistema Centrale / soc. gruppo ACI

Data Mart

Back office

Loyalty nazionale

Gestione Catalogo Prodotti Contratti On Line

Rinnovi Automatici

Portale ACI rete

Loyalty locale

Loyalty POS

Multicanalità /Internet

Gestione associazioni

Assetti AC

Gestione Associazioni Gestione promozioni

Telethon

Autoscuole

Telethon



Pagina 10 di 46

3.1.5 Le applicazioni SOCIO WEB L’applicazione garantisce la gestione delle associazioni di tipo individuale e aziendale attraverso la vendita di prodotti e servizi presente nel catalogo nazionale e nel catalogo personalizzato di ogni singolo AACC CATALOGO PRODOTTI E SERVIZI L'applicazione 'Catalogo Socio Web' ha lo scopo di coadiuvare gli Automobile Club Provinciali nella definizione dei prodotti, servizi e promozioni che andranno a formare l'offerta correlata all'associazione ACI nei punti vendita di pertinenza di ogni singolo Automobile Club. CRUSCOTTO STATISTICO LOCALE Il prodotto premette di acquisire e gestire in un'unica banca dati tutte le informazioni inerenti i Soci (prodotti dalla Sede e dalle Delegazioni), i Clienti (AC e Delegazioni dirette) e i Servizi locali gestiti dall’AC con i relativi valori economici. Attraverso GEA è possibile effettuare l’Analisi economica e contabile della rete di vendita e dei servizi venduti dalla rete oltre a fornire il supporto all’analisi statistica ed alle azioni di marketing (liste, etichette, lettere, telemarketing, gestione tessere e contratti in scadenza). SOCIO .NET Socio.Net premette di acquisire le associazioni ACI da internet. Fruiscono di questo servizio:

• il SITO ACI.IT. dove sono gestite esclusivamente le associazioni di tipo individuale. Il prodotto prevede il pagamento della quota associativa tramite carta di credito.

• Partner di ACI non appartenenti alla INTRANET e per i quali il prodotto viene customizzato in

funzione del tipo di prodotto che possono vendere e nelle modalità di pagamento ed assegnazione del SOCIO all’A.C. di competenza.

COL Le principali funzionalità del prodotto possono essere suddivise in due sottosistemi:

• il sottosistema di front-end • il sottosistema di back.office

Il sottosistema di front-end, in uso presso la sede centrale dell’ACP e di tutte le delegazioni, provvede alla gestione dei contratti che il cliente può stipulare per il rinnovo automatico della tessera associativa e per il pagamento automatico della tassa automobilistica per i veicoli. Al momento della stipula del contratto il prodotto interagisce con:

• sistema SOCI per: o importare le informazioni del socio che intende stipulare il contratto o verificare i dati sull’associazione e calcolare l’importo da sottoporre al cliente

• sistema TASSE per controllare i dati sul veicolo per il quale si intende contrattualizzare il pagamento

automatico della tassa automobilistica e calcolare l’importo dovuto.



Pagina 11 di 46

Il sottosistema di back-office permette la gestione del servizio di rinnovo delle tessere e di pagamento della tassa automobilistica. Tale sottosistema è attivabile esclusivamente dalla sede centrale dell’AC e agisce su tutti i contratti stipulati dalle delegazioni appartenenti all’AC stesso. BACK-OFFICE L’applicazione di back office garantisce i seguenti servizi:

• Esecuzione Rinnovi automatici • Produzione flussi contabili per associazioni • Gestione flussi tessere per produzione ed invio plastiche associative • Gestione flussi riviste sociali • Gestione flussi per Carta di credito (Barclays) • Gestione flussi Loyalty / IP • Gestione flussi ACI Global • Gestione flussi (nuovi e rinnovi) da SARA Assicurazioni • Gestione flussi Banca Sara per emissione carte prepagate (Tessera Multifunzione) • Gestione flussi per ALA SERVICE

DATA MART ASSOCIAZIONI Data mart per l’analisi statistica sulle associazioni ACI Data mart per l’analisi statistica sulle prestazioni ACI Global erogate ai soci ACI INFOACI Il prodotto consente la gestione dei messaggi massivi (SMS, E-Mail). Ha una interfaccia che consente la definizione di modelli, la importazione dei file dei destinatari del messaggio, la schedulazione degli invii, la analisi statistica degli invii effettuati. Il prodotto fornisce inoltre dei servizi richiamabili da applicazione per l’integrazione App. to App. Attualmente gli utenti sono interni ad ACI Informatica TELETHON Il prodotto consente la raccolta di donazioni a favore di TELETHON. L’applicazione è disponibile sulla INTRANET ACI. L’applicazione è inoltre integrata in SOCIO WEB (gestionale SOCI a disposizione della rete di vendita AC). Utenti del prodotto sono costituiti dalla rete di vendita AC. Autoscuole – Circuito Ready To Go (R2G) Il prodotto WEB è destinato alle Autoscuole appartenenti al circuito Ready To Go. Consente il rilascio di una associazione ACI (tessera Giovani – OKKEI) agli iscritti al corso di guida. II prodotto consente inoltre l’invio tramite e-mail di un attestato di frequenza al corso che da diritto al patentando di fruire di sconti ed agevolazioni varie. Il Patentando per stampare l’attestato deve preventivamente compilare un questionario. Il prodotto consente una serie di analisi statistiche. ABSCARD Gestione delle campagne di fidelity nazionali e locali (ACP) per i soci ACI.

• gestione dei microchip presenti sulle tessere associative • definizione e la gestione delle campagne di loyalty • gestione dei flussi di scambio con i partner individuati per le campagne di loyalty



Pagina 12 di 46

SERVIZI ACIRETE Il prodotto costituisce un punto di incontro tra l'amministrazione AciRete, il personale commerciale che opera sul territorio, ed i responsabili di ACP e delegazioni. Tramite il prodotto stesso, l’amministrazione di ACI Rete gestisce il servizio di Direct Mailing verso i soci in scadenza (invito al rinnovo) ed i soci scaduti (sollecito al rinnovo).

3.1.6 Gli utenti Gli utenti che hanno accesso al sistema di gestione delle associazioni, sono definiti centralmente nel sistema di autenticazione ed è da questo che vengono autenticati. Il sistema gestisce le seguenti classi di utenti:

• gli utenti di delegazione (1.500 delegazioni) • gli utenti di AC provinciale (106 AACC) • gli utenti che operano in multicanalità (punti di servizio esterni alla rete ACI)

Il primo è un utente che può gestire solo i dati del proprio ufficio(delegazione), mentre il secondo è abilitato alla gestione dei dati di tutte le delegazioni della provincia. All’ interno dello stesso ufficio, sia esso una semplice delegazione, o una sede provinciale, viene applicata una ulteriore suddivisione, fra Responsabile e Operatore, con il secondo che ha una lista di funzioni ridotte rispetto a tutte quelle messe a disposizione della applicazione. Per quanto riguarda il data mart, l’utilizzo è rivolto agli utenti della Direzione Centrale Soci. Per questa tipologia di utenti esiste una gestione delle utenze e della sicurezza realizzata utilizzando Business Objects Administrator che, con differenti livelli di abilitazione, garantisce l’accesso alle viste di informazioni specifiche.

3.1.7 Le dimensioni tecniche del Sistema Associazioni Descrizione Valore Grandezza Basi dati (giga byte) 84

Numero di record in linea per le basi dati operazionali 206.000.000 circa

Profondità storica delle informazioni 6 anni Utenti connessi sulle basi dati operazionali con servizi on-line 3000 circa Associazioni gestite annualmente 1.100.000 circa Uffici (Automobile Club Provinciali) 106 Uffici (Delegazioni) >1300 Uffici (Punti servizio Multicanalità) 8 Utenti QTA Automobile Club Provinciali 106 Delegazioni > 1.300 Punti di Servizio Multicanalità 8



Pagina 13 di 46

3.2 Sottosistema Contabilità per gli AACC

3.2.1 Descrizione del contesto La Suite GSA è il sistema realizzato da ACI Informatica per la gestione dei servizi amministrativo / contabili degli Automobile Club. Il sistema, con l’entrata in vigore del nuovo regolamento di contabilità (gennaio 2011) ha subito un profondo cambiamento che ha comportato la riscrittura dell’applicazione GSAWeb e la realizzazione dell’applicazione GSAWeb2. La transizione dal vecchio al nuovo regolamento comporta comunque, per tutto il 2011, la coesistenza fra la vecchia e la nuova applicazione. A seguito della chiusura del consuntivo 2010 (aprile 2011), la vecchia applicazione verrà utilizzata unicamente per la consultazione e stampa dei dati pregressi. Il nuovo sistema contabile ha come riferimento normativo il nuovo regolamento di contabilità che rende obbligatoria l’integrazione della contabilità economico / patrimoniale con la contabilità analitica (ispirata alle linee guida co.an. - aprile 2004). Sulla base di questo vincolo le applicazioni GSAWeb e CoAnNet sono state unificate (sia nella parte gestionale che nella parte Data Base). I sistemi alimentanti (GSASoci, GSABP-Beni patrimoniali, GSAPD-Personale Dipendente) verranno adeguati per integrarsi con il nuovo applicativo GSAWeb2. Sintesi del quadro normativo: Delibera consiglio generale per l’adozione del Nuovo Regolamento di contabilità 2009; NORMATIVA‘Circolare Sede Centrale del 2-7-2009, prot. 0032922/09 – adozione del Nuovo Regolamento di Amministrazione e Contabilità degli Automobile Club Contabilità Economico/Patrimoniale (COGE) - codice civile. Contabilità Fiscale (TUIR, legge IVA – DPR 633/72)

3.2.2 Il quadro dei servizi Il sistema integra la Contabilità Economico / Patrimoniale e gli adempimenti di carattere Fiscale (registri IVA, liquidazione mensile, gestione ritenuta d’acconto, ecc.). Gestisce tutte le fasi amministrative previste dal regolamento di contabilità degli AACC: Budget Annuale, ciclo passivo (gestione atti amministrativi, richiesta d’acquisto, ordine d’acquisto, entrata/merci, gestione documenti passivi, pagamenti e quietanza), ciclo attivo (ordine di vendita, uscita/merci, gestione documenti attivi, incassi e quietanza), Bilancio di Esercizio. Alimenta in tempo reale la contabilità analitica per Attività e Centri di Costo. La contabilità analitica viene alimentata sia dai dati contabili provenienti da GSAWeb2 che da dati extra-contabili che vengono elaborati ed inviati verso GSAWeb2 attraverso i Sistemi Alimentanti, da adeguare al nuovo regolamento nel corso del 2011: GSABp – Beni Patrimoniali (inventario e cespiti) GSASoci – Integrazione sistema associazioni e contabilità SOCI GSAPd – Personale Dipendente (stipendi del personale dendente) Le applicazioni si integrano in un portale della contabilità (denominato GSASuite) che ha lo scopo di gestire le funzioni ed i dati comuni, le funzioni di integrazione e le interfacce di comunicazione fra i moduli software nonché con il portale aziendale TITANO.



Pagina 14 di 46

3.2.3 Architettura di riferimento Il sistema si compone dei seguenti moduli: GSASuite, GSAWeb2, GSAWeb, Co.An.NET, GSABp, GSASoci, GSAPd, GSAPLUS.

3.2.3.1Tecnologia Dal punto di vista tecnologico le applicazioni del sistema “contabile” sono divisibili nei seguenti gruppi: GSASuite GSAWeb2 GSAWEB Co.An.NET GSABp GSAPd GSASoci L’applicazione GSASuite è di tipo Distribuited Three-Tier, pertanto a tre livelli (GUI, Business Logic, Data Access Layer), con comunicazione tra i livelli remotabile. Il database è costituito dalle tabelle e dai dati comuni delle applicazioni contabili GSAWeb, GSAWeb2, CoAnNet, GSABp, GSAPd, GSASoci. La comunicazione e l’integrazione con i dati delle diverse applicazioni avviene mediante l’utilizzo di componenti COM+. Mediante questa soluzione è infatti possibile consentire ad applicazioni realizzate con tecnologie diverse e per piattaforme diverse di dialogare tra loro. GSASuite utilizza il browser I.E. vers. 8.0 o superiore come ambiente di gestione dell’applicazione. L’interfaccia utente è scritta in linguaggio .NET. Le pagine ASP.net contengono e attivano i controlli formali (residenti in file Javascript inclusi nelle pagine) e richiamano le DLL (residenti sull’application server) che gestiscono i processi di business. Le applicazioni sono state sviluppate in architettura web secondo il modello a tre livelli: Presentation Business Logic Data Base

Sistemi alimentanti Contabilità Analitica



Pagina 15 di 46

PRESENTATION BUSINESS DATI

WEB

BROWSER

Application

Server

HTTP Connettori

Presentation (interfaccia utente) Le applicazioni utilizzano il browser I.E. vers. 8.0 o superiore come ambiente di gestione dell’applicazione. L’interfaccia utente è scritta in linguaggio ASP (GSAWeb) ed in .Net (GSAWeb2, CoAnNet e sistemi alimentanti). Le pagine ASP e .NET contengono e attivano i controlli formali (residenti in file Javascript inclusi nelle pagine) e richiamano le DLL (residenti sull’application server ) che gestiscono i processi di business. L’applicazione sfrutta i meccanismi di cache del browser per velocizzare l’accesso ai dati: sul client vengono scaricati, dal web server, file in formato XML, contenenti repliche dei dati relativi a tabelle del Data Base (tipologiche e tabelle con bassa frequenza di aggiornamento ma di largo utilizzo in consultazione). Business Logic Sull’application server risiede parte della logica di business (regole) dell’applicazione. Il linguaggio utilizzato per la scrittura dei componenti di business è Visual Basic 6. La funzione principale demandata alle DLL (per standard di sviluppo è stata compilata una DLL per macro entità) è quella di gestire: Regole di Business Attivazione e controllo delle transazioni . Attivazione delle stampe . Data Base I dati vengono memorizzati in appositi database dipartimentali SQL Server 2008. L’accesso ai dati avviene attraverso stored-procedures L’applicazione Co.An.NET è di tipo Distribuited Three-Tier, pertanto a tre livelli (GUI, Business Logic, Data Access Layer), con comunicazione tra i livelli remotabile. Il database costituisce una “integrazione” del database di GSAWeb con l’aggiunta di tabelle/campi relativi alla contabilità analitica. L’Import-Export di dati verso GSAWeb (o eventuali altre applicazioni di contabilità) avviene mediante una interfaccia Web Service. Mediante questa soluzione è infatti possibile consentire ad applicazioni realizzate con



Pagina 16 di 46

tecnologie diverse e per piattaforme diverse di dialogare in modo univoco con una applicazione remota come Co.An.NET. CoAnNet utilizza il browser I.E. vers. 8.0 o superiore come ambiente di gestione dell’applicazione. L’interfaccia utente è scritta in linguaggio ASP.net. Le pagine ASP.net contengono e attivano i controlli formali (residenti in file Javascript inclusi nelle pagine) e richiamano le DLL (residenti sull’application server) che gestiscono i processi di business. Le applicazione GSABp, GSAPd, GSASoci sono di tipo Distribuited Three-Tier, pertanto a tre livelli (GUI, Business Logic, Data Access Layer), con comunicazione tra i livelli remotabile. Il database costituisce una “integrazione” del database di GSASuite, GSAWeb e CoAnNet con l’aggiunta di tabelle / campi specifiche dell’applicazione (inventario, categorie, stati d’uso dei beni, ecc.). L’Import-Export di dati verso GSAWeb e CoAnNet (o eventuali altre applicazioni di contabilità) avviene mediante l’utilizzo di componenti COM+. Mediante questa soluzione è infatti possibile consentire ad applicazioni realizzate con tecnologie diverse e per piattaforme diverse di dialogare tra loro. GSABp, GSAPd, GSASoci utilizzano il browser I.E. vers. 6.0 o superiore come ambiente di gestione dell’applicazione. L’interfaccia utente è scritta in linguaggio .NET. Le pagine ASP.net contengono e attivano i controlli formali (residenti in file Javascript inclusi nelle pagine) e richiamano le DLL (residenti sull’application server) che gestiscono i processi di business. .

3.2.3.2 Interfacce con gli utenti Dal punto di vista dell’interfaccia con gli utenti le applicazioni del sistema “contabile” sono divisibili nei seguenti gruppi: GSASuite (GSAWeb, GSAWeb2, CoAnNet e sistemi alimentanti) GSAWeb, GSAWeb2, CoanNET, Nuovo GSAWeb e Sistemi Alimentanti sono stati sviluppati in ambiente web, architettura di riferimento adottata su tutti i prodotti della Federazione. Presupposto imprescindibile è la presenza di postazioni di lavoro abilitate ad operare sulla intranet ACI. Il prodotto inoltre è integrato con il sistema di autenticazione e portale TITANO. La scelta web consente il collegamento anche da postazioni esterne alla realtà ACI che su richiesta dell’AC vengono abilitate all’utilizzo del prodotto (es. postazione di lavoro presso l’ufficio del consulente contabile).

3.2.3.3 Interfacce con altre applicazioni Dal punto di vista dell’ interfaccia con altre applicazioni, GSAWeb si interfaccia con l’applicazione per la gestione della contabilità analitica, denominata CoAnNet. GSAWeb in sostanza rappresenta il sistema alimentante Contabilità Generale (COGE) di CoAnNet. In GSAWeb le regole di integrazione fra la contabilità finanziaria e la contabilità economico/patrimoniale hanno consentito l’individuazione di un unico interfaccia di collegamento con la contabilità analitica. Il colloquio tra le due applicazioni avviene attraverso uno strato http(SOAP).



Pagina 17 di 46

3.2.4 Architettura Applicativa

3.2.4.1 Applicazioni

3.2.4.2 Utenti Le tipologie di utenti sono gli uffici ragioneria degli AC, gli studi di consulenza, o qualsiasi altra postazione distaccata autorizzata dall’AC.

3.2.4.3 Le dimensioni tecniche del sottosistema Contabilità per AACC

Portale - GSASuite

Descrizione Valore

Grandezza Basi dati (giga byte) 137,00 MB

Numero di record in linea per le basi dati operazionali 656870

Profondità storica delle informazioni 10 anni circa

Utenti connessi sulle basi dati operazionali con servizi on-

line 200 circa

Contabilità web - GSAWEB

GSAWeb

GSA PdGSA Bp GSA Soci

Contabilità SoW

SoW

SIAC/SAP

Gestione docum.

GSA Suite

Sistemi Alimentanti

TITANO

GSAWeb2



Pagina 18 di 46

Descrizione Valore





line 200 circa

Contabilità web - GSAWEB 2

Descrizione Valore





line 200 circa

Sistemi alimentanti GSAPd; GSASoci; GSABp

Descrizione Valore





line 200 circa

Contabilità analitica - COANNET

Descrizione Valore





line 200 circa

Sedi QTA

Automobile Club Provinciali 105



Pagina 19 di 46

3.3 Sottosistema Pratiche

3.3.1 Descrizione del contesto Il sistema Pratiche permette la gestione delle pratiche automobilistiche, seguendone l’iter intero consentendo la presentazione delle informazioni presso i sistemi PRA e DTT attraverso il colloquio con lo Sportello Telematico dell’Automobilista.

3.3.2 Il quadro dei Servizi Il sistema Pratiche permette la gestione dei seguenti servizi:

• Gestione delle pratiche automobilistiche e della produzione dei documenti fiscali previsti dalla normativa. • Gestione degli elenchi di pratiche (per colloquio con STA e DTT) • Gestione della Cassa e delle chiusure di fine giornata • Statistiche sulle pratiche lavorate


3.3.3.1 Tecnologia PraticheLight è un’applicazione di ACI Informatica che permette la gestione delle pratiche automobilistiche, seguendone l’iter intero. PraticheLight si integra con il mondo PRA e DTT, attraverso uno strato http(SOAP), oltre a possedere insite delle funzionalità proprie del mondo A.C.I. . L’applicazione è sviluppata secondo il modello client-server. E’ stato utilizzato come ambiente di sviluppo Microsoft VisualBasic 6.0 sp5.

PRESENTATION

BUSINESS

DATI

WINDOWS

FORM

Connettori

Lo schema mostra le integrazioni possibili con PraticheLight. .



Pagina 20 di 46

3.3.3.2 Interfaccia con gli utenti L’interfaccia utente è costituita da una serie di form, che si rifanno a quelli standard del sistema operativo Micorosft Windows.

3.3.3.3 Interfacce con altre applicazioni L’interfacciamento con lo STA (Cooperante e Copernico2) è possibile attraverso il programma STA++ e lo scambio dei dati avviene tramite dei file xml. Il programma consente di selezionare le pratiche per le quali sarà creato il relativo file. Questo collegamento è bidirezionale perché è possibile aggiornare in modo automatico i dati delle pratiche di Pratiche Light con i dati ritornati dallo STA. E’ altresì possibile il collegamento diretto con il DTT attraverso il programma STA++Prenota.


3.3.4.1 Le Applicazioni Pratiche,Light prevede un menu suddiviso in :

Pratiche Procedure che permettono l’inserimento e la gestione delle pratiche, compresa la stampa dei vari modelli e dei documenti fiscali. Si possono anche creare i file xml per il colloquio con lo STA. Tabelle Gestione di tutte le tabelle di base (con e senza importi), dei parametri agenzia, delle tipologie di pratica, degli utenti. Elenchi Gestione completa degli elenchi, cioè insiemi di pratiche su cui si possono effettuare operazioni comuni (stampa dei modelli in modulo continuo, spesatura degli importi, creazione dei file xml, ecc.). Inoltre può essere creato il file per il colloquio con il DTT. Cassa Comprende tutta l’operatività gestionale del magazzino del funzionario delegato, la gestione degli estratti conto per l’emissione di un solo documento fiscale a fronte di una serie di pratiche ed altre operazioni di carattere contabile. Chiusure Comprende tutte le stampe di fine giornata, sia quelle di entrata che di uscita per tenere sotto controllo la situazione (contabile e non) dell’ufficio. Statistiche Le tre statistiche presenti, in quanto completamente parametriche, permettono di coprire e soddisfare la totalità delle richieste dei clienti. Servizi Comprende funzioni particolari, quali il salvataggio dei dati, lo sblocco delle pratiche (utile in caso di malfunzionamenti o perdite di corrente).

3.3.4.2 Utenti

Il prodotto è utilizzato dalle Delegazioni ACI per la gestione delle pratiche automobilistiche. Nel menu Tabelle è presente la funzione Utenti che permette l’inserimento di tutti i soggetti che potranno utilizzare il prodotto con le relative abilitazioni/limitazioni. Esiste anche l’utente Administrator (creato di default) che è colui che può accedere a qualsiasi funzione



Pagina 21 di 46

3.3.4.3 Le dimensioni tecniche del Sistema Pratiche

Descrizione Valore

Grandezza Basi dati (giga byte)** N.D.

Numero di record in linea per le basi dati operazionali N.D.

Profondità storica delle informazioni (anni) N.D.

Utenti connessi sulle basi dati operazionali con servizi on-line 130

Movimenti gestiti annualmente N.D

Uffici 130

** non valutabile perché le banche dati sono localizzate per ogni ufficio



Pagina 22 di 46

3.4 Sottosisema CSAI

3.4.1 Descrizione del contesto Il sistema CSAI è di supporto alla gestione delle licenze sportive ACI-CSAI (Auto e Karting) e alla gestione delle gare motoristiche. Si colloca quindi all’interno della regolamentazione dettata dall’”Annuario CSAI” che, oltre ai regolamenti strettamente legati all’attività sportiva, detta le norme di gestione delle licenze CSAI.

3.4.2.Il quadro dei Servizi Il prodotto permette la gestione delle licenze sportive e delle posizioni anagrafiche relative. Utenti e fruitori dei servizi sono: gli operatori della CSAI Centrale di Roma gli Uffici Sportivi degli Automobile Club Provinciali Le funzionalità legate alle Gare sono rivolte ai licenziati “Organizzatori CSAI” per: inserimento gare automobilistiche nel del calendario sportivo gestione del modulo di richiesta di iscrizione delle gare al calendario FIA Le suddette funzionalità sono estese, per il completamento dell’iter di gestione e di validazione, agli: AA.CC. Delegati Regionali Sotto Commissioni sportive CSAI Ufficiali di Gara per la designazione dei collegi sportivi


3.4.3.1 Tecnologia La tecnologia di riferimento per le applicazioni è J2EE. Essa viene utilizzata nel contesto di una progettazione articolata sul modello delle applicazioni web a tre livelli. I tre suddetti livelli sono rappresentati dalle interfacce utente ‘Web-Based’, quindi le logiche di ‘business’ incapsulate in componenti riusabili e, infine, l’accesso ai dati isolato. In alcune eccezioni legate sostanzialmente alle funzionalità del prodotto “Licenze” (Intranet) il 2° e 3° livello sono unificati. Sono applicati gli standard tecnologici per i componenti utilizzati ‘Jsp’ e ‘Servlet’. L’interfaccia utente è Web-Based e realizzata mediante ‘jsp’ e ‘servlet’; il 2° livello (logiche di ‘business’) è fondamentalmente rappresentato da classi ‘Java’ mentre il terzo livello, di accesso ai dati, si concretizza in classi ‘Java’ che si interfacciano con ‘Stored Procedures’ del RDBMS Oracle.



Pagina 23 di 46

3.4.3.2 Interfaccia con gli utenti Le interfacce sono tutte Web-Based e fruibili o comunque integrabili all’interno di contesti sia Intranet che Internet. Le interfacce, nel dettaglio, sono realizzate mediante l’utilizzo di fogli di stile (CSS) contestualmente, per quello che riguarda le interfacce funzionali, a ‘jsp’ contenti codice ‘server’ e interfaccia utente. Le modalità di navigazione sono ‘user-friendly’ e presuppongono attualmente per “CSAI - Gare” l’utilizzo soltanto di pagine ‘jsp’, mentre è ancora in uso per la Intranet “CSAI – Licenze” la gestione dell’interfaccia mediante ‘Frame’.

3.4.3.3 Interfacce con altre applicazioni

Attualmente gestisce interfacce on l’applicazione CS New e con i Servizi Soci; il dialogo è assicurato nel primo caso via http, via http o RMI per i Servizi Soci.



Pagina 24 di 46


3.4.4.1 Applicazioni

ACI CSAI

AA.CC.AA.CC. Delegati RegionaliDelegati RegionaliACIACI

Dir

ezio

ne

Cen

tral

e C

SA

I, D

irez

ion

e C

entr

ale

CS

AI,

So

tto

Co

mm

issi

on

iS

ott

oC

om

mis

sio

ni S

po

rtiv

eS

po

rtiv

e

Gestione Licenze

Gestione Anagrafica Licenziati

Gestione Tabelle Centrali

Gestione Gare (Controllo Completo)

Inserimento Gare

Gestione Licenze

Gestione Anagrafica Licenziati

Intranet Licenze

Internet Gare e Calendari

Validazione data gara

NullaOsta Gare

ORGANIZZATORI CSAIORGANIZZATORI CSAI

Inserimento Gare

Visualizzazione Stato

Gare

Visualizzazione Calendario

Internet Gare e Calendari



Internet Gare e Calendari Internet Gare e Calendari

Visualizzazione

Calendario

Aggiornamento Propria Posizione

Anagrafica

Intranet Licenze

Richiesta di Iscrizione Gare a Calendario FIA

Le macro-funzionalità inserite nel contesto sono due: CSAI – Licenze Auto e Karting CSAI – Gare Auto e Karting Le funzionalità presenti nell’applicazione Intranet CSAI Licenze sono le seguenti : Gestione Licenze Inserimento Licenza Rinnovo Licenza Annullamento Licenza Modifica Licenza (p.e. Qualifiche) Consultazione licenze sia in corso che storiche Gestione Anagrafica Inserimento Titolare Modifica Titolare Gestione Tabelle



Pagina 25 di 46

Stampe Attestato Provvisorio Estrazioni Regionale e Nazionali Storico Titolari Storico Licenze Prestampati Gestione propria ‘Password’ Le funzionalità presenti nell’applicazione Internet CSAI “Gare e Calendari” sono le seguenti : Gare e calendari Inserimento Nuova gara Visualizzazione stato gare Visualizzazione Calendario Gestione propria posizione anagrafica Gestione propria ‘PassWord’ Inserimento NullaOsta Modifica data gara Assegnazione Validità sportiva Inserimento a calendario Richiesta di iscrizione gare a Calendario FIA

3.4.4.2 Utenti

Attualmente il prodotto “CSAI – Licenze” è rilasciato alla CSAI Centrale ed ai 106 uffici sportivi degli AA.CC. per complessive 210 utenze. Hanno autorizzazione all’accesso al prodotto “CSAI – Gare” i licenziati “Organizzatori CSAI” e i delegati regionali per complessive 383 utenze circa.

3.4.4.2 Le dimensioni tecniche del Sistema CSAI

Descrizione Valore Grandezza Basi dati (giga byte) 1 Numero di record in linea per le basi dati operazionali 3.700.000 circa Profondità storica delle informazioni 9 anni Utenti connessi sulle basi dati operazionali con servizi on-line 600 circa



Pagina 26 di 46

4 Oggetto della fornitura Oggetto della gara sono le attività di completamento della progettazione e realizzazione di componenti software riguardanti i Sistemi e Servizi FEDERAZIONE ACI, identificati con Servizi Informatici, che sono:

• I nuovi sviluppi • manutenzione evolutiva/a manutenzione adeguativa/ migliorativa • Il supporto tecnico nella definizione dei requisiti informatici

5 Durata della fornitura e piano di subentro

5.1 Durata della fornitura

I servizi oggetto della fornitura dovranno essere erogati per un periodo di 36 mesi a decorrere dalla data di presa in carico delle attività, oltre al periodo residuo della garanzia di 12 mesi che l’Impresa aggiudicataria dovrà assicurare sulle attività di sviluppo e di manutenzione evolutiva.

5.2 Piano di subentro

Di seguito sono riportate le modalità di subentro da parte dell’Impresa aggiudicataria con l’obiettivo di garantire ad ACI INFORMATICA la continuità di erogazione dei servizi oggetto del presente capitolato. La durata massima entro cui dovrà essere completato il piano di subentro è di tre mesi dalla data di “inizio attività. Durante questi tre mesi il personale dell’Impresa aggiudicataria, per acquisire le competenze necessarie all’erogazione dei servizi contrattualmente previsti e raggiungere il necessario livello di autonomia operativa, sarà affiancato dal personale dell’Impresa che attualmente fornisce i servizi oggetto del presente capitolato, alla quale spetta assicurare la manutenzione del software e le attività necessarie all’operatività dei sistemi, e dal personale di ACI INFORMATICA. Sono a carico dell’Impresa e non devono comportare nessun onere per ACI INFORMATICA i costi del personale impiegato durante il periodo di subentro. Sarà compito dell’Impresa aggiudicataria redigere il piano di subentro, da presentare nell’ambito dell’Offerta Tecnica, in cui devono essere definiti: - l’organizzazione per la gestione della fase di affiancamento fino alla presa in carico; - la descrizione dei tempi e delle modalità di attuazione della fase suddetta; - il dimensionamento delle risorse per lo svolgimento delle attività di affiancamento per ogni specifico servizio

richiesto da ACI Informatica (Nuovi sviluppi, Manutenzione Evolutiva/ Adeguativa /Migliorativa, Supporto tecnico nella definizione dei requisiti informatici), in termini di competenze del personale impiegato e giorni lavorativi complessivamente dedicati;



Pagina 27 di 46

- tempificazione degli incontri per la verifica dello stato di avanzamento delle attività. 5.3 Affiancamento finale

Nel corso dell’esecuzione del contratto, anche per fine attività, in maggior misura negli ultimi tre mesi di validità del contratto stesso, l’Impresa dovrà, su richiesta Aci Informatica, trasferire a personale Aci Informatica, o a terzi da essa designati il know-how sulle attività condotte, al fine di rendere l’eventuale prosecuzione delle attività quanto più efficace possibile, secondo un programma formativo che preveda ad esempio docenze, sessioni riassuntive, sessioni di lavoro congiunto, presentazioni su funzioni, disegno, codice e documentazione dei sistemi oggetto di fornitura.

E’ pertanto richiesto all’Impresa di predisporre un piano di lavoro di dettaglio delle attività di trasferimento di know how e le relative modalità di erogazione. Tale piano di lavoro è soggetto all’approvazione di Aci Informatica, l’onere di predisposizione è a carico dell’Impresa e dovrà tenere conto delle eventuali proposte che l’Impresa potrà fare in sede di offerta.

Nelle fasi di affiancamento l’Impresa dovrà, se richiesto, ospitare il personale del nuovo fornitore in affiancamento nell’operatività quotidiana di manutenzione correttiva e gestione, senza peraltro che il nuovo fornitore abbia la possibilità di eseguire direttamente le attività, ossia di effettuare training on the job. A parte l’ospitalità in affiancamento che è gratuita, altre eventuali attività concordate e pianificate saranno remunerate, a consumo.

6 Modalità di dimensionamento delle attività

A. Relativamente ai servizi:

• Nuovi sviluppi • Manutenzione evolutiva/ adeguativa/ migliorativa

gli incarichi all’Impresa verranno articolati in singoli affidamenti. La dimensione di ciascun affidamento verrà espressa in function point o in giorni/persona. Per quanto concerne le attività di manutenzione evolutiva, sono previste le seguenti tipologie di intervento: - Major release, per interventi che prevedono un effort maggiore di 30 giorni/persona, e che saranno espressi in

Function Point - Minor release, per interventi che prevedono un effort fino a 30 giorni/persona. Il numero dei function point di ogni singolo affidamento, stimato al termine della fase di analisi effettuata da ACI INFORMATICA, verrà riportato nei verbali di affidamento e potrà essere rideterminato in occasione di eventuali richieste di modifiche in corso d’opera. Il calcolo dei “function point” verrà effettuato secondo le modalità riportate nel capitolo 9, che l’Impresa fin d’ora dichiara espressamente di accettare.



Pagina 28 di 46

B. Relativamente al servizio di supporto tecnico nella definizione dei requisiti informatici gli interventi verranno misurati in giorni/persona della durata standard di 8 ore giornaliere ovvero a “corpo nel caso di attività pianificabili; questi interventi verranno stimati al termine della fase di analisi preliminare effettuata da ACI INFORMATICA, verranno riportati nei verbali di affidamento e potranno essere rideterminati in occasione di eventuali richieste di modifiche in corso d’opera.

7 Sede e strumenti di lavoro

Le prestazioni si potranno svolgere completamente o in parte sia presso la sede di ACI INFORMATICA sia presso la sede dell’impresa. La definizione della sede verrà esplicitata da ACI INFORMATICA al momento del conferimento dei singoli affidamenti. Le stazioni di lavoro per il proprio personale, necessarie per l’espletamento delle attività affidate, comprensive dei necessari strumenti software, dovranno essere messe a disposizione dall’Impresa. Le stazioni di lavoro dovranno essere dotate di tool diversi a secondo dei servizi sui quali saranno impegnate le singole persone. - per i Servizi Informatici (Nuovi sviluppi, Manutenzione Evolutiva/ Adeguativa /Migliorativa, Supporto tecnico

nella definizione dei requisiti informatici): 1. piattaforma J2EE

o Microsoft Office o Rational XDE o Rational Application Developer 6 (RAD 6) o Websphere MQ o Oracle Client o Allround Automations PL/SQL Developer o Rational Clear Case (installazione client e licenze server) o Microsoft Visual Source Safe o Antivirus o SO Windows XP Pro o Windows 7 Enterp..

2. piattaforma .Net o Microsoft Office o Oracle Client o Allround Automations PL/SQL Developer o Microsoft Visual Source Safe o Microsoft Visual Studio 6 sp5 o Microsoft Visual Studio .Net 2002 o Microsoft SQL Server 2000 o Crystal Reports o Antivirus o SO Windows 7 Enterp.

Le versioni dei tool saranno indicate al momento dell’aggiudicazione della gara. L’accesso ai locali ACI INFORMATICA, nonché la disponibilità degli ambienti di produzione saranno regolati come segue:

• Orario normale attività lavorativa Dalle ore 8,00 alle ore 18,00 (con presenza di 8 ore esclusa l’ora del pasto) di tutti i giorni feriali dal lunedì al venerdì con elasticità di 1 ora in entrata.



Pagina 29 di 46

• Servizio al di fuori dell’orario normale

ACI INFORMATICA può richiedere prestazioni aggiuntive sia al di fuori del normale orario di servizio sia nelle giornate di sabato, domenica e festivi infrasettimanali.

Per le eventuali attività svolte presso la sede dell’Impresa, quando ciò si renderà necessario, ACI INFORMATICA provvederà, ferme restando le responsabilità dell’Impresa, all’invio degli aggiornamenti necessari per mantenere l’allineamento con l’evoluzione dell’ambiente di sviluppo e test. ACI INFORMATICA fornirà all’Impresa le caratteristiche tecniche e operative necessarie al collegamento telematico, i cui oneri saranno totalmente a carico dell’Impresa. L’Impresa dovrà mettere a disposizione nei propri locali l’ambiente ove verrà installato l’apparato router, e il suo backup, di accesso ai server di ACI INFORMATICA. Il router, fornito da ACI INFORMATICA, al fine di garantire i livelli di sicurezza degli accessi vigenti in ACI INFORMATICA, sarà configurato e gestito da personale specializzato di ACI INFORMATICA. La linea di connessione dovrà essere CDN non inferiore ai 2Mbs e dovrà essere predisposto un backup della linea su tecnologia ADSL. La connessione ai servizi centrali dovrà avvenire esclusivamente tramite protocollo TCP/IP. Gli orari di collegamento per attività interattive vanno dalle ore 8,00 alle ore 18,00 di tutti i giorni feriali, dal lunedì al venerdì. Il collegamento comunque dovrà essere disponibile h24 su 365 giorni l’anno per far fronte alle richieste di prestazioni aggiuntive sopra esposte.

8 Ambienti di sviluppo

Di seguito sono descritti gli ambienti di sviluppo per la produzione. In particolare, si specifica che per poter operare con i repository di ACI Informatica saranno fornite delle apposite chiavi di accesso (Login e Password). ACI Informatica, al fine di garantire il rispetto dei livelli di sicurezza, si riserva di effettuare qualsiasi controllo sia sistematico sia estemporaneo, anche presso i posti di lavoro dell’impresa, sul corretto uso delle Password assegnate, riservandosi altresì di revocarle a suo insindacabile giudizio.

8.1 Sottosistema Associazioni

• Linguaggio Java ed ambiente di sviluppo Rational Application Developer 6 (RAD 6), • Websphere MQ • Rational Clear Case • Microsoft Visual Source Safe • Librerie Open Source di supporto alla realizzazione (struts, iText, ecc.), • Linguaggio PL/SQL ed ambiente di sviluppo Allround Automations PL/SQL Developer • Crystal Reports

L’ architettura adottata per le applicazioni del sottosistema ASSOCIAZIONI ACI è basato sulla piattaforma J2EE e adotta un modello a tre livelli (presentation, business logic, data layer).



Pagina 30 di 46

In particolare il livello presentation è realizzato lato server con pattern MVC; come Application Server è utilizzato “Websphere Application Server” e come Data Server “Oracle”. Le interfacce utilizzate sono: Web Services, http(s), RMI/IIOP, tutto con trattamento dati XML. Esclusivamente per il prodotto COL , l’architettura di riferimento è la seguente

• Linguaggio VB ed ambiente di sviluppo Microsoft Visual Studio 6 sp5 • Linguaggio VB .Net ed ambiente di sviluppo Microsoft Visual Studio .Net 2002 • Microsoft Visual Source Safe • Crystal Reports

8.2 Sottosistema Contabilità AACC

• Linguaggio VB ed ambiente di sviluppo Microsoft Visual Studio 6 sp5 • Linguaggio VB .Net ed ambiente di sviluppo Microsoft Visual Studio .Net 2008 • Microsoft Visual Source Safe • Crystal Reports

L’architettura adottata per le applicazioni del sottosistema CONTABILITA’ AACC è basato sulla piattaforma Microsoft e adotta sia il modello a tre livelli (presentation, business logic, data layer) che quello client/server. Le interfacce utilizzate sono: Web Services.

8.3 Sottosistema Pratiche

• Linguaggio VB ed ambiente di sviluppo Microsoft Visual Studio 6 sp5 • Microsoft Visual Source Safe

L’architettura adottata per le applicazioni del sottosistema Pratiche è basato sulla piattaforma Microsoft e adotta il modello client/server. Le interfacce utilizzate sono: Web Services.

8.4 Sottosistema CSAI

• Linguaggio Java ed ambiente di sviluppo Rational Application Developer 6 (RAD 6), • Websphere MQ • Rational Clear Case • Microsoft Visual Source Safe • Librerie Open Source di supporto alla realizzazione (struts, iText, ecc.), • Linguaggio PL/SQL ed ambiente di sviluppo Allround Automations PL/SQL Developer • Crystal Reports

L’ architettura adottata per le applicazioni del sottosistema CSAI è basato sulla piattaforma J2EE e adotta un modello a tre livelli (presentation, business logic, data layer).



Pagina 31 di 46

In particolare il livello presentation è realizzato lato server con pattern MVC; come Application Server è utilizzato “Websphere Application Server” e come Data Server “Oracle”. Le interfacce utilizzate sono: Web Services, http(s), RMI/IIOP, tutto con trattamento dati XML.

9 Modalità di conteggio dei function point

Per la produzione software, il numero di Function Point di ogni intervento verrà riportato nei verbali di affidamento e potrà essere rideterminato in occasione di eventuali richieste di modifiche in corso d’opera che raggiungano una differenza maggiore del 10%, in più o in meno, rispetto a quanto indicato nei verbali. La stima dei Function Point non riguarda l’intero ciclo di vita del software ma solo le fasi che vanno dalla progettazione tecnica fino al system test. Le tipologie di Function Point previsti nell’ambito di ogni specifico intervento di sviluppo o di manutenzione evolutiva saranno: FP ADD, per la realizzazione di nuove funzionalità FP CHG, per la modifica di funzionalità esistenti FP DLE, per la rimozione di funzionalità esistenti Il numero di Function Point da realizzare nell’ambito di ogni specifico intervento, di sviluppo o di manutenzione evolutiva verrà calcolato con le seguenti modalità: (Numero FP) = (FP Ifpug) * (Fr) dove : (FP Ifpug) è il numero dei function point valutato applicando la metodologia IFPUG 4.3 Unadjusted Function Point Method in conformità allo standard ISO/IEC 14143. (Fr) è il fattore di riuso che sarà applicato per tener conto del riuso funzionale e tecnico (es. riutilizzo di strutture dati e parti di codice allo scopo di realizzare nuovi componenti tecnici da utilizzare per la costruzione di nuove funzionalità logiche) secondo la tabella riportata. Livello di riuso % di codice uguale Fattore di riuso Nullo 0 1 Basso 10 0,85 Medio 10 – 20 0,70 Alto 30 0,50 Molto Alto > 50 0,30

Esempio FP a consuntivo = 1000 FR = 0,70 FP riconosciuti = 1000 x 0,70 = 700 Per la determinazione del corrispettivo dovuto a fronte di ogni intervento, il conteggio dei Function Point sarà effettuato a consuntivo, sul software realizzato, applicando la formula sopra descritta.



Pagina 32 di 46

− i FP di tipo ADD saranno remunerati “a prezzo intero”, vale a dire all’importo unitario dell’aggiudicazione, a

partire dalla base d’asta di € 145,00; − i FP di tipo CHG saranno remunerati al 50% dell’importo unitario di aggiudicazione;

i FP di tipo DEL saranno remunerati al 10% dell’importo unitario di aggiudicazione

10 Standard della qualità

Nei paragrafi successivi sono elencati gli standard di qualità che l’Impresa è tenuta a rispettare. Un eventuale mancato rispetto degli standard da parte dell’Impresa comporterà l’applicazione delle penali previste nel contratto.

10.1 Profilo della qualità del Sistema Informativo FEDERAZIONE ACI

Nelle attività riportate nel presente capitolato il fornitore prende atto e si impegna a rendere operative tutte le azioni possibili per garantire il rispetto dei requisiti della qualità sotto riportati validi per il Sistema Informativo Federazione ACI. Il profilo della qualità di seguito richiesto si intende valido per tutti i prodotti. a) Funzionalità - capacità di fornire servizi tali da soddisfare, in determinate condizioni, requisiti funzionali espliciti o impliciti (il software fa ciò per il quale è stato acquistato). In questa caratteristica della Qualità rientrano le seguenti sottocaratteristiche:

� Adeguatezza (la presenza di funzioni appropriate per compiti specifici che supportano gli obiettivi dell’utente);

� Funzionalità (la capacità di fornire risultati corretti in accordo con i requisiti dati dall’utente); � Interoperabilità (la capacità di interagire con altri sistemi); � Aderenza agli standard (l’aderenza del software a prescrizioni di legge, convenzioni o regolamenti) � Sicurezza (la capacità di proteggere programmi e dati da accessi non autorizzati e di consentire

quelli autorizzati). Per questa caratteristica si richiede un livello di attenzione alto, soprattutto nella fase di analisi e progettazione. Questo perché all’inizio, durante la raccolta ed analisi dei requisiti, la qualità è specificata dai requisiti utente, soprattutto da un punto di vista “esterno” e funzionale. Mentre, nella fase di progettazione, la qualità esterna di traduce in un disegno tecnico, confrontandosi con il punto di vista degli sviluppatori sulla qualità interna del software e completandosi con i requisiti “impliciti” che il software deve rispettare. Questo significa che tutte le funzionalità descritte nei documenti di Specifica devono essere richiamabili; il software deve funzionare come descritto nella documentazione e le condizioni di attivazione delle funzioni devono corrispondere a quanto descritto nel manuale d’uso. Gli indicatori della qualità relativi alla Funzionalità che sono stati individuati e ritenuti maggiormente significativi sono riportati nella tabella seguente.

Indicatore

Caratteristica di Qualità

(Funzionalità)

Descrizione

Valore soglia

A01

Adeguatezza Presenza e correttezza del maggior numero possibile di funzioni specifiche per l’uso cui il prodotto è destinato.

Vengono presi in considerazione i documenti che l’Impresa dovrà produrre a corredo degli affidamenti. Saranno sottoposti a verifica tramite la check list riportata in allegato 1.

Il punteggio medio risultante dall’analisi della documentazione non dovrà essere inferiore a:

• 3 nella media generale; • 2,5 nel punteggio medio dei singoli

fattori qualitativi.

A02

Accuratezza dell’output Percentuale dei risultati errati o degli effetti non corretti delle elaborazioni rispetto al numero totale dei risultati o delle elaborazioni effettuate.

Viene calcolata la percentuale di errori rilevati in fase di collaudo in rapporto alle dimensioni delle applicazioni. La metrica utilizzata è indicata in sede di affidamento del lotto.

≤ 2 errori ogni 100 FP collaudati.



Pagina 33 di 46

A03

Interoperabilità Capacità del software di interagire con altri sistemi specificati

Qualora richiesto dalle Specifiche di prodotto, deve poter essere realizzato ed integrato per il corretto funzionamento con altre componenti. Il dettaglio dei sistemi con cui è necessaria l’interoperabilità è descritto nei paragrafi “3.1.3.3, 3.2.3.3, 3.3.3.3 “Interfacce con altre applicazioni”.

In fase di Collaudo verrà verificato il corretto funzionamento ed integrazione con altre

componenti.

A04 Aderenza agli standard Aderenza del software a prescrizioni di legge, convenzioni o regolamenti

Il quadro istituzionale specifico e il quadro normativo di riferimento è quello specifico del Regolamento Associativo ACI e di Contabilità Pubblica.

In fase di Collaudo verrà verificata l’aderenza al quadro normativo di riferimento.

A03 Sicurezza Capacità di rendere accessibili i dati riservati, personali e/o sensibili solo agli utenti autorizzati

Qualora richiesto dalle Specifiche di prodotto, deve poter essere realizzato ed integrato per il corretto funzionamento tramite l’accesso al Portale ACI Titano.

In fase di Collaudo verrà verificato il corretto funzionamento ed integrazione tramite l’accesso

al portale ACI Titano.

b) Affidabilità - capacità di mantenere le prestazioni stabilite nelle condizioni e nei tempi fissati (il software reagisce bene a variazioni esterne). In questa caratteristica della Qualità rientrano le seguenti sottocaratteristiche:

� Maturità (la capacità di evitare fermi dell’applicazione – failure - a seguito di malfunzionamenti - fault);

� Tolleranza ai guasti (la capacità di mantenere determinati livelli di prestazione in caso di malfunzionamenti - non degrado);

� Ripristinabilità (la capacità e la velocità, in caso di malfunzionamenti, di ripristinare dei livelli di prestazione predeterminati e di recuperare i dati);

� Aderenza agli standard (l’aderenza del software a standard di affidabilità) Per questa caratteristica si richiede un livello di attenzione alto, sia dal punto di vista della “qualità interna” che dal punto di vista della “qualità in uso” (in altre parole il livello con cui il prodotto si dimostra utile all’utente nel suo effettivo contesto d’utilizzo). L’attenzione è posta nella capacità del prodotto di dare efficacia ed efficienza al lavoro dell’utente, a fronte di una sicurezza di utilizzo e di una soddisfazione nel far uso del prodotto poiché non può esservi qualità percepita positivamente dall’utente senza che vi sia una buona qualità intrinseca al codice e buone prestazioni. Questo significa che il prodotto non deve consentire l’immissione di input dannosi o incorretti e non deve consentire il danneggiamento o la perdita di dati. Gli indicatori della qualità relativi all’Affidabilità che sono stati individuati e ritenuti maggiormente significativi sono riportati nella tabella seguente.

Indicatore


(Affidabilità)

Descrizione

Valore soglia

A02

Maturità Frequenza di anomalie dovute ad errori software

Viene calcolata la percentuale di errori rilevati in fase di collaudo (fornendo dati di input validi) in rapporto alle dimensioni delle applicazioni. La metrica utilizzata è indicata in sede di affidamento del lotto.

≤ 2 errori ogni 100 FP collaudati. Tolleranza ai guasti Capacità di mantenere uno specificato livello di funzionalità anche in caso di errori sw o anomalie dei flussi di input

Viene calcolata la percentuale di errori rilevati in fase di collaudo (fornendo casi negativi in input) in rapporto alle dimensioni delle applicazioni. La metrica utilizzata è indicata in sede di affidamento del lotto.

A05 Ripristinabilità Ripristinabilità delle informazioni

Viene verificato in fase di collaudo il numero delle volte in cui è ≤ 1 ripristino ogni 50 anomalie riscontrate.



Pagina 34 di 46

critiche gestite dal software necessario ripristinare la base dati a fronte di una anomalia

A06

Aderenza agli standard Aderenza del software a standard di affidabilità

Devono essere rispettate le Linee Guida del documento “Naming & Coding Conventions per Java” (allegato 2). E’ previsto l’uso di uno strumento che permette di controllare lo stile di scrittura del codice, al fine di garantire uno standard di leggibilità elevato (quale ad esempio check-style).

Non è ammesso codice sorgente senza formattazione da check-style.

c) Usabilità – capacità di essere compreso, appreso, usato con soddisfazione dall’utente in determinate condizioni d’uso (il software gestisce bene l’interazione con gli utenti). In questa caratteristica della Qualità rientrano le seguenti sottocaratteristiche:

� Comprensibilità (la capacità di ridurre l’impegno richiesto agli utenti per capirne il funzionamento e le modalità di utilizzo);

� Apprendibilità (la capacità di ridurre l’impegno richiesto agli utenti per impararlo ad usare); � Operabilità (la capacità di mettere in condizione gli utenti di farne uso per i propri scopi e

controllarne l’uso); � Interfaccia utente (la capacità di essere piacevole per l’utente che ne fa uso); � Aderenza agli standard (l’aderenza del software a standard di usabilità).

Per questa caratteristica si richiede un livello di attenzione alto, soprattutto dal punto di vista della “qualità in uso”, su come il prodotto si dimostra utilizzabile all’utente nel suo effettivo contesto d’utilizzo. Questo significa che domande e messaggi del prodotto devono essere facilmente comprensibili dall’utente; messaggi di errore devono aiutare a correggere il problema, con l’ausilio della opportuna documentazione; la tipologia dei messaggi (errori, warnings, domande, risposte, ecc.) deve essere chiaramente individuabile; i formati dei campi di input e dei reports devono essere facilmente comprensibili dall’utente; l’esecuzione di una operazione deve essere annullabile (deve essere reversibile la modifica di dati); un utente deve poter apprendere come chiedere servizi al prodotto leggendo la documentazione e le funzioni di help. Gli indicatori della qualità relativi all’Usabilità che sono stati individuati e ritenuti maggiormente significativi sono riportati nella tabella seguente.

Indicatore


(Usabilità)

Descrizione

Valore soglia

A07

Comprensibilità Sforzo richiesto agli utenti per comprendere i concetti logici del software e la loro applicabilità

Vale quanto descritto nei paragrafi 3.1.3.2, 3.2.3.2, 3.3.3.2, “Interfacce con gli utenti”.

Sia in fase di verifica della documentazione, sia in fase di Collaudo non sono ammesse

modalità diverse da quanto descritto nei paragrafi “3.3.2. Interfacce con gli utenti”.

Apprendibilità Sforzo richiesto all’utente per imparare ad usare il sistema

Operabilità Sforzo richiesto all’utente per utilizzare il sistema

Interfaccia utente Gradevolezza dell’interfaccia utente Aderenza agli standard Aderenza del software a standard di usabilità



Pagina 35 di 46

d) Efficienza – rapporto fra prestazioni e quantità di risorse utilizzate, in condizioni definite di funzionamento (il software usa bene le risorse disponibili); In questa caratteristica della Qualità rientrano le seguenti sottocaratteristiche:

� Tempi di risposta (la capacità di mantenere adeguati tempi di risposta, tempi di elaborazione e throughput rates per eseguire le funzioni richieste, sotto determinate condizioni);

� Uso di risorse (l’utilizzo di una quantità e di una tipologia di risorse adeguate per eseguire le funzioni richieste, sotto determinate condizioni);

� Aderenza agli standard (l’aderenza del software a standard di efficienza). Per questa caratteristica si richiede un livello di attenzione alto, soprattutto dal punto di vista “qualità in uso”, su come il prodotto si dimostra efficiente all’utente nel suo effettivo contesto d’utilizzo. Questo significa che l’utente deve essere avvisato di possibili tempi di risposta lunghi per operazioni che esegue il prodotto a fronte di sue richieste. Gli indicatori della qualità relativi all’Efficienza che sono stati individuati e ritenuti maggiormente significativi sono riportati nella tabella seguente.

Indicatore


(Efficienza)

Descrizione

Valore soglia

A08

Tempi di risposta Capacità del software di rispondere, elaborare e fornire dati in output nei tempi previsti

Qualora richiesto verrà definito nelle Specifiche di prodotto.

In fase di Collaudo verrà effettuata opportuna misurazione secondo quanto previsto dalle

Specifiche di prodotto. Nel caso di MEV (manutenzione evolutiva)

e di MAC (manutenzione adeguativa/correttiva) i tempi di risposta non dovranno essere mai

inferiori ai tempi di risposta prima della modifica.

A09

Uso di risorse Quantità di risorse utilizzate ed al relativo tempo di utilizzo

Viene verificato l’utilizzo della quantità e della tipologia di risorse affinché sia adeguato ad eseguire le funzioni richieste.

In fase di Collaudo viene verificato che l’utilizzo delle risorse sia quello

previsto dai documenti di Specifica e che avvenga nel rispetto dell’Architettura di

riferimento descritta nei paragrafi “3.1.3.1., 3.2.3.1, 3.3.3.1 - Tecnologia”.

Aderenza agli standard Aderenza del software a standard di efficienza

e) Manutenibilità – capacità di essere modificato con un impegno contenuto (per evoluzioni e/o correzioni o adeguamenti); In questa caratteristica della Qualità rientrano le seguenti sottocaratteristiche:

� Analizzabilità (la capacità di limitare l’impegno richiesto per diagnosticare carenze o cause di malfunzionamenti, o per identificare parti da modificare);

� Modificabilità (la capacità di limitare l’impegno richiesto per modificare, rimuovere errori o sostituire componenti);

� Stabilità (la capacità di ridurre il rischio di comportamenti inaspettati a seguito della effettuazione di modifiche);

� Facilità di testing (la capacità di essere facilmente testato per validare le modifiche apportate); � Aderenza agli standard (l’aderenza del software a standard di manutenibilità).

Per questa caratteristica si richiede un livello di attenzione alto, soprattutto dal punto di vista della “qualità interna”, e rappresenta la misura in cui il codice software possiede una serie di attributi statici, indipendentemente dall’ambiente di utilizzo e dall’utente. Questo significa che ciò che deve essere fatto per manutenere il prodotto deve essere conforme alla documentazione allegata e devono essere mantenuti i valori di soglia richiesti. Gli indicatori della qualità relativi alla Manutenibilità che sono stati individuati e ritenuti maggiormente significativi sono riportati nella tabella seguente.



Pagina 36 di 46

Indicatore

CARATTERISTICA DI QUALITÀ

(MANUTENIBILITÀ)

Descrizione

Valore soglia

A10 Analizzabilità Sforzo necessario per individuare quali componenti hanno causato un’anomalia

Viene presa in considerazione la percentuale di commenti significativi all’interno del codice sviluppato.

La percentuale di commenti significativi non deve essere inferiore al 10% delle linee di istruzione.

A11 Modificabilità Sforzo necessario per gli interventi sui componenti che hanno causato un’anomalia

Vengono presi in considerazione i commenti all’interno del codice sviluppato, relativamente alle strutture di controllo.

Non sono ammessi componenti che abbiano strutture di controllo senza commenti.

A02

Stabilità Rischio di effetti inattesi delle modifiche

Viene calcolata la percentuale di errori rilevati in fase di collaudo (test di regressione) in rapporto alle dimensioni delle applicazioni. La metrica utilizzata è indicata in sede di affidamento del lotto.

≤ 2 errori ogni 100 FP collaudati.

A01

Facilità di testing Sforzo necessario per validare il software modificato

Vengono presi in considerazione i documenti che l’Impresa dovrà produrre a corredo degli affidamenti. Saranno sottoposti a verifica tramite la check list riportata in allegato 1.

Il punteggio medio risultante dall’analisi della documentazione non dovrà essere inferiore a:

• 3 nella media generale; • 2,5 nel punteggio medio dei singoli

fattori qualitativi.

A06

Aderenza agli standard Aderenza del software a standard di manutenibilità

Devono essere rispettate le Linee Guida del documento “Naming & Coding Conventions per Java” (allegato 2). E’ previsto l’uso di uno strumento che permette di controllare lo stile di scrittura del codice, al fine di garantire uno standard di leggibilità elevato (quale ad esempio check-style).

Non è ammesso codice sorgente senza formattazione da check-style

f) Portabilità – facilità con cui il software può essere trasferito da un ambiente operativo ad un altro. In questa caratteristica della Qualità rientrano le seguenti sottocaratteristiche:

� Adattabilità ai cambiamenti (la capacità di adattarsi a nuovi ambienti operativi limitando la necessità di apportare modifiche);

� Installabilità (la capacità di ridurre l’impegno richiesto per installarlo in un particolare ambiente operativo);

� Coesistenza (la capacità di coesistere con altri software nel medesimo ambiente, condividendo risorse);

� Ricollocabilità (la capacità di capacità di essere utilizzato al posto di un altro software per svolgere gli stessi compiti nello stesso ambiente);

� Aderenza agli standard (l’aderenza del software a standard di portabilità). Per questa caratteristica si richiede un livello di attenzione alto, soprattutto dal punto di vista della “qualità interna”, e rappresenta la misura in cui il codice software risulta il più possibile indipendente dalla piattaforma su cui è stato realizzato. Questo significa che l’utente deve poter effettuare l’installazione seguendo le istruzioni allagate; gli ambienti hardware e software descritti nella documentazione devono essere sufficienti a completare l’installazione; il prodotto deve poter essere rimovibile dal computer in modo automatico. Gli indicatori della qualità relativi alla Portabilità che sono stati individuati e ritenuti maggiormente significativi sono riportati nella tabella seguente.

Indicatore


(Portabilità)

Descrizione

Valore soglia

A12 Adattabilità ai cambiamenti Possibilità di adattare il software ad ambienti diversi senza applicare

Vale quanto descritto nei paragrafi “3.1.3.1, 3.2.3.1, 3.3.3.1. Tecnologia”.

In fase di Collaudo viene verificato che il requisito sia quello

previsto e



Pagina 37 di 46

azioni diverse da quelle previste a tale scopo

che rispetti l’Architettura di riferimento descritta nei paragrafi

“3.1.3.1, 3.2.3.1, 3.3.3.1. Tecnologia”.

A13 Installabilità Sforzo necessario per installare il software in un ambiente specificato

Qualora richiesto dalle Specifiche di prodotto, devono essere realizzate funzioni specifiche di installazione e/o disinstallazione del pacchetto.

Presenza e corretto funzionamento di funzioni specifiche

di installazione e/o disinstallazione.

A12

Coesistenza Capacità del software di coesistere con altri prodotti sulla stessa piattaforma

Vale quanto descritto nei paragrafi “3.1.3.1, 3.2.3.1, 3.3.3.1. Tecnologia”.

In fase di Collaudo viene verificato che il requisito sia quello

previsto e che rispetti l’Architettura di riferimento

descritta nei paragrafi “3.1.3.1, 3.2.3.1, 3.3.3.1. Tecnologia”..

Ricollocabilità Sforzo necessario a sostituire un altro software diverso da quello che si sta progettando Aderenza agli standard Aderenza del software a standard di portabilità

10.2 Standard della qualità per il codice sorgente

Devono essere rispettati i seguenti parametri della qualità per il codice sorgente:

1. Documentazione La percentuale di commenti significativi non deve essere inferiore al 10% delle linee di istruzione, inoltre tutte le strutture di controllo devono essere commentate. 2. Difettosità La percentuale di errori rilevati in fase di collaudo in rapporto alle dimensioni delle applicazioni ed alla metrica utilizzata ed indicata in sede di affidamento del lotto non deve superare i 2 errori ogni 100 FP collaudati 3. Rispetto degli standard Devono essere rispettate le Linee Guida del documento Naming & Coding Conventions per Java (allegato2). E’ previsto l’uso di uno strumento che permette di controllare lo stile di scrittura del codice, al fine di garantire uno standard di leggibilità elevato (quale ad esempio check-style).

11 Modalità di affidamento delle attività

L’Impresa potrà operare sulle singole attività solo dopo che ACI INFORMATICA ne avrà comunicato il formale affidamento. L’incarico verrà formalizzato mediante un Verbale di Affidamento nel quale verranno indicati: il numero dei function point stimati o dei giorni/persona stimati ed i risultati attesi. Nel Verbale di affidamento saranno altresì indicati gli standards della qualità da applicare in base a quanto riportato nel capitolo 10.



Pagina 38 di 46

Il Verbale di affidamento ed i documenti ad esso allegati riporteranno i prodotti che ACI INFORMATICA consegnerà all’Impresa in fase di conferimento del singolo affidamento e i prodotti che l’Impresa dovrà consegnare ad ACI INFORMATICA al termine della fase di progettazione, quando prevista, e/o al termine delle attività di realizzazione.

12 Servizi Informatici

12.1 Nuovi sviluppi

12.1.1 Descrizione

Comprende le attività di progettazione, realizzazione, test e rilascio di nuovi componenti informatici. Inoltre comprende la manutenzione correttiva dei soli sviluppi in garanzia. La validità della manutenzione correttiva ha durata pari a quella del contratto e comunque per un periodo non inferiore a 12 mesi dalla data di collaudo positivo dei prodotti consegnati senza alcun onere aggiuntivo per ACI INFORMATICA e comprende tutti gli interventi volti all’eliminazione dei malfunzionamenti del software applicativo, ovvero al ripristino delle funzionalità previste, a fronte di errori o incongruenze. Le attività si articoleranno in singoli affidamenti conferiti formalmente di volta in volta da ACI INFORMATICA all’Impresa con le modalità definite al capitolo 11.

12.1.2 Modalità di consegna intermedia e finale

12.1.2.1 Consegna intermedia

ACI INFORMATICA può richiedere la consegna intermedia dei prodotti, al fine di effettuare verifiche in corso d’opera. Tutti i prodotti intermedi saranno riportati nel Verbale di Affidamento e dovranno essere consegnati dall’Impresa entro le date stabilite, per ciascun affidamento, nel Verbale stesso. La consegna di tali prodotti dovrà essere formalizzata tramite l’apposito Verbale di Consegna intermedia. ACI INFORMATICA effettuerà in proprio la verifica della congruenza dei prodotti consegnati dall’Impresa con le specifiche fornite da ACI INFORMATICA e della completa corrispondenza dei prodotti di progettazione con i prodotti previsti nel Verbale di Affidamento. L’avvenuta validazione o eventuali incongruenze riscontrate durante la verifica saranno comunicate all’Impresa per consentire la tempestiva prosecuzione delle attività, nel rispetto delle date specificate nel Verbale di Affidamento. In questo caso l’Impresa effettuerà le necessarie modifiche a proprio esclusivo carico senza oneri aggiuntivi per ACI INFORMATICA e senza che questo possa costituire motivo di ritardo nella consegna finale dei prodotti. I prodotti non verranno accettati fino a quando tutte le anomalie non saranno rimosse.

12.1.2.2 Consegna finale

La quantità di funzionalità effettivamente realizzate verrà valutata a consuntivo con la misurazione dei Function Point effettuata secondo quanto riportato nel capitolo 9; oppure con la misurazione dei giorni/persona equivalenti.



Pagina 39 di 46

Il software prodotto dovrà essere consegnato ad ACI INFORMATICA secondo le modalità che verranno comunicate all’Impresa all’atto dell’affidamento. I prodotti dovranno essere consegnati dall’Impresa entro le date stabilite per ciascun incarico nel Verbale di Affidamento. Tutta la documentazione dovrà essere redatta in lingua italiana. La consegna dei prodotti dovrà essere formalizzata tramite l’apposito Verbale di Consegna finale. Alle date di consegna dei prodotti da parte dell’Impresa, ACI INFORMATICA provvederà ad immettere tali prodotti nell’ambiente di test del sistema informativo e ad effettuare un esame finalizzato a verificare la completa corrispondenza dei prodotti consegnati con quanto previsto; l’esito di tale esame verrà comunicato all’Impresa anche ai fini di una tempestiva rimozione delle eventuali anomalie riscontrate. Le anomalie riscontrate durante tale fase determineranno la non accettazione di tutti i prodotti software consegnati. L’Impresa effettuerà le modifiche a proprio esclusivo carico. Le consegne effettuate dopo la fase di rimozione degli errori dovranno comunque contenere sempre la totalità dei prodotti software previsti. I prodotti software non verranno accettati fino a quando tutte le anomalie non saranno state rimosse.

12.1.3 Collaudo

Entro 30 giorni dalla data di consegna del singolo affidamento, ACI INFORMATICA procederà al collaudo dei prodotti realizzati. La data del collaudo verrà tempestivamente comunicata all’Impresa. Il collaudo di ciascun affidamento riguarderà in particolare la corrispondenza dei prodotti consegnati dall’Impresa con quanto concordato nel Verbale di Affidamento, la loro congruenza con le specifiche fornite e il rispetto degli standard della qualità. Il collaudo si svolgerà con le seguenti modalità:

• esecuzione dei test funzionali; • verifica della rispondenza ai requisiti non funzionali; • verifica della corretta applicazione dei parametri della qualità; • verifica della documentazione consegnata.

Al termine del collaudo, se l’esito risulterà positivo, sarà redatto l’apposito Verbale di Accettazione. Al Verbale di Accettazione, anche ove non sia riscontrata la necessità di ulteriori interventi correttivi sui prodotti consegnati, si dovranno comunque allegare tutte le segnalazioni di anomalie/malfunzionamenti riscontrate durante il collaudo, anche se già rimossi. Nel caso, invece, il collaudo si concluda con esito negativo, sarà redatto il Rapporto di Collaudo che riporterà l’elenco degli errori riscontrati, i corrispondenti interventi correttivi e la data della nuova seduta di collaudo. Gli oneri relativi agli errori imputabili all’opera dell’Impresa saranno a carico dell’Impresa stessa. Alle nuove sedute di collaudo si procederà secondo le modalità previste dal presente paragrafo. Al fine di rispettare le date di consegna concordate con l’Impresa, nel caso di collaudo conclusosi con esito negativo, ACI INFORMATICA potrà decidere, a proprio insindacabile giudizio, di portare comunque il prodotto in ambiente di esercizio dopo aver eventualmente applicato in proprio le correzioni ritenute opportune. In questo caso



Pagina 40 di 46

l’Impresa sarà comunque tenuta ad effettuare gli interventi correttivi nei tempi riportati nel Verbale di Accettazione, e verranno applicate le penali previste nel contratto.

12.2 Manutenzione evolutiva,adeguativa,migliorativa

12.2.1 Descrizione

Gli interventi consistono nell’apportare modifiche puntuali alle applicazioni che costituiscono il sistema informativo esistente per migliorare le prestazioni o la manutenibilità, adeguare l’applicazione a un ambiente modificato, adattare l’applicazione a seguito di cambiamenti normativi, o aggiungere nuove funzionalità. Nell’ambito di tali interventi sono comprese le attività di:

• manutenzione evolutiva: interventi alle procedure ed ai prodotti volti a modificare le funzionalità esistenti o introdurre nuove funzioni;

• manutenzione migliorativa: modifiche alle procedure ed ai programmi volte a preservare l’efficienza al variare delle condizioni e dei carichi di lavoro del sistema informativo;

• manutenzione adeguativa: modifiche alle procedure ed ai programmi volte ad assicurare la costante aderenza alla evoluzione dell’ambiente tecnologico del sistema informativo;

Inoltre il servizio comprende la manutenzione correttiva in garanzia delle applicazioni/prodotti modificate. La validità della manutenzione correttiva in garanzia ha durata pari a quella del contratto e comunque per un periodo non inferiore a 12 mesi dalla data di collaudo positivo dei prodotti consegnati senza alcun onere aggiuntivo per ACI INFORMATICA e comprende tutti gli interventi volti all’eliminazione dei malfunzionamenti del software applicativo riscontrati durante le operazioni di collaudo o durante l’esercizio, ovvero al ripristino tempestivo delle funzionalità previste, a fronte di errori o incongruenze. Il servizio si articolerà in affidamenti conferiti formalmente di volta in volta da ACI INFORMATICA all’Impresa, con le modalità definite al capitolo 11.

12.2.2 Modalità di consegna intermedia e finale

12.2.2.1 Consegna intermedia

ACI INFORMATICA può richiedere la consegna intermedia dei prodotti, al fine di effettuare verifiche in corso d’opera. Tutti i prodotti intermedi saranno riportati nel Verbale di Affidamento e dovranno essere consegnati dall’Impresa entro le date stabilite, per ciascun affidamento, nel Verbale stesso. La consegna di tali prodotti dovrà essere formalizzata tramite l’apposito Verbale di Consegna intermedia. ACI INFORMATICA effettuerà in proprio la verifica della congruenza dei prodotti consegnati dall’Impresa con le specifiche fornite da ACI INFORMATICA e della completa corrispondenza dei prodotti di progettazione con i prodotti previsti nel Verbale di Affidamento. L’avvenuta validazione o eventuali incongruenze riscontrate durante la verifica saranno comunicate all’Impresa per consentire la tempestiva prosecuzione delle attività, nel rispetto delle date specificate nel Verbale di Affidamento. In questo caso l’Impresa effettuerà le necessarie modifiche a proprio esclusivo carico senza oneri aggiuntivi per ACI INFORMATICA e senza che questo possa costituire motivo di ritardo nella consegna finale dei prodotti. I prodotti non verranno accettati fino a quando tutte le anomalie non saranno rimosse.



Pagina 41 di 46

12.2.2.2 Consegna finale

La quantità di funzionalità effettivamente realizzate verrà valutata a consuntivo con la misurazione dei Function Point effettuata secondo quanto riportato nel capitolo 9; oppure con la misurazione dei giorni/persona equivalenti. Il software prodotto dovrà essere consegnato ad ACI INFORMATICA secondo le modalità che verranno comunicate all’Impresa all’atto dell’affidamento. I prodotti dovranno essere consegnati dall’Impresa entro le date stabilite per ciascun incarico nel Verbale di Affidamento. Tutta la documentazione dovrà essere redatta in lingua italiana. La consegna dei prodotti dovrà essere formalizzata tramite l’apposito Verbale di Consegna finale. Alle date di consegna dei prodotti da parte dell’Impresa, ACI INFORMATICA provvederà ad immettere tali prodotti nell’ambiente di test del sistema informativo e ad effettuare un esame finalizzato a verificare la completa corrispondenza dei prodotti consegnati con quanto previsto al paragrafo 12.2.1; l’esito di tale esame verrà comunicato all’Impresa anche ai fini di una tempestiva rimozione delle eventuali anomalie riscontrate. Le anomalie riscontrate durante tale fase determineranno la non accettazione di tutti i prodotti software consegnati. L’Impresa effettuerà le modifiche a proprio esclusivo carico. Le consegne effettuate dopo la fase di rimozione degli errori dovranno comunque contenere sempre la totalità dei prodotti software previsti. I prodotti software non verranno accettati fino a quando tutte le anomalie non saranno state rimosse.

12.2.3 Collaudo

Entro 30 giorni dalla data di consegna del singolo affidamento, ACI INFORMATICA procederà al collaudo dei prodotti realizzati. La data del collaudo verrà tempestivamente comunicata all’Impresa. Il collaudo di ciascun affidamento riguarderà in particolare la corrispondenza dei prodotti consegnati dall’Impresa con quanto concordato nel Verbale di Affidamento, la loro congruenza con le specifiche fornite e il rispetto degli standard della qualità. Il collaudo si svolgerà con le seguenti modalità:

• esecuzione dei test funzionali; • verifica della rispondenza ai requisiti non funzionali; • verifica della corretta applicazione dei parametri della qualità; • verifica della documentazione consegnata.

Al termine del collaudo, se l’esito risulterà positivo, sarà redatto l’apposito Verbale di Accettazione. Al Verbale di Accettazione, anche ove non sia riscontrata la necessità di ulteriori interventi correttivi sui prodotti consegnati, si dovranno comunque allegare tutte le segnalazioni di anomalie/malfunzionamenti riscontrate durante il collaudo, anche se già rimossi. Nel caso, invece, il collaudo si concluda con esito negativo, sarà redatto il Rapporto di Collaudo che riporterà l’elenco degli errori riscontrati, i corrispondenti interventi correttivi e la data della nuova seduta di collaudo. Gli oneri relativi agli errori imputabili all’opera dell’Impresa saranno a carico dell’Impresa stessa.



Pagina 42 di 46

Alle nuove sedute di collaudo si procederà secondo le modalità previste dal presente paragrafo. Al fine di rispettare le date di consegna concordate con l’Impresa, nel caso di collaudo conclusosi con esito negativo, ACI INFORMATICA potrà decidere, a proprio insindacabile giudizio, di portare comunque il prodotto in ambiente di esercizio dopo aver eventualmente applicato in proprio le correzioni ritenute opportune. In questo caso l’Impresa sarà comunque tenuta ad effettuare gli interventi correttivi secondo quanto riportato nel Verbale di Accettazione, e verranno applicate le penali previste nel contratto.

12.3 Supporto tecnico nella definizione dei requisiti informatici.

Su richiesta di ACI INFORMATICA esplicitata al momento del singolo affidamento, l’Impresa dovrà inoltre fornire prestazioni professionali di supporto nella definizione dei requisiti informatici che verranno retribuite sulla base delle risorse effettivamente impegnate. Per tali attività, l’Impresa metterà a disposizione i necessari strumenti di lavoro secondo quanto previsto al capitolo 7. Il servizio di consulenza relativo al supporto tecnico nella definizione dei requisiti informatici, verrà di norma prestato presso le sedi di ACI INFORMATICA, salvo diversa richiesta esplicitata da ACI INFORMATICA nel verbale di affidamento. Questa tipologia di attività di consulenza, non di tipo continuativo, dovrà essere prestata su richiesta esplicitata da ACI INFORMATICA. La rendicontazione sarà effettuata in giorni persona su specifici piani di lavoro con rispetto dei tempi, dimensioni dell’ impegno e prodotti da realizzare che comunque saranno sottoposti ad approvazione da parte di ACI I nformatica. Si esplicitano nel dettaglio le attività di supporto attese :

• Raccolta, analisi e definizione dei requisiti utente • Definizione dei requisiti informatici • Definizione dei requisiti di qualità del prodotto (sottocaratteristiche di qualità norma ISO 9126-1) • Formalizzazione dei requisiti secondo gli standard aziendali preposti

L’attività di definizione dei requisiti informatici, in particolare, è volta a determinare :

o i requisiti delle funzioni; per ogni funzione occorre descrivere: • le regole della funzione (che cosa fa), le eventuali dipendenze con altre funzioni

(sincronismi, parallelismi, sequenze, iterazioni ecc.) e le condizioni di avvio; • i messaggi in input e la loro origine; • i messaggi in output e la loro destinazione; • gli accessi ai dati.

o i requisiti dei dati; per ogni entità deve essere descritto: • gli attributi dell’entità specificando quali sono gli attributi chiave, i possibili valori che gli

attributi possono assumere; • le relazioni o dipendenze statiche con le altre entità; • i vincoli di integrità; • il ciclo di vita dell’entità dalla creazione di un’occorrenza alla sua cancellazione

o le correlazioni; sono qui di seguito riportate le correlazioni richieste: • “funzioni” e “entità” per evidenziare come ogni entità sia trattata da almeno una funzione;



Pagina 43 di 46

• “entità” e “informazioni” per evidenziare come le informazioni definite nei requisiti organizzativi siano “risolte” per mezzo di entità (o oggetti esterni);

• “funzioni” e “unità organizzative” per evidenziare quale unità organizzativa esegue una determinata funzione;

o l’analisi delle criticità e dei vincoli; la tipologia dei problemi può essere la più varia e può, ad esempio, riguardare:

• relazioni con altri progetti; • aspetti progettuali legati all’organizzazione non ancora definiti; • criticità in termini di incapacità di soddisfare un requisito del progetto; • vincoli tecnologici, organizzativi, normativi che comportano un degrado della soluzione.

13 Sostituzione del personale dell’impresa

Il personale impiegato per i servizi richiesti potrà essere cambiato solamente in casi eccezionali e con adeguata motivazione che preventivamente deve essere comunicata ad ACI INFORMATICA. Il numero di sostituzioni nell’arco della durata del contratto è regolato dal seguente livello di servizio:

Indicatore Livello di servizio

Sostituzione delle risorse impiegate per il contratto

E’ consentito un numero di sostituzioni, nell’arco della durata del contratto, non superiore al 10% sia del numero di persone messe a disposizione complessivamente dall’Impresa sia del numero di risorse per singole tipologie professionali.

Il personale sostituito deve essere affiancato dal nuovo personale per almeno 15 giorni lavorativi, senza alcun onere per ACI INFORMATICA.

14 Modifiche in corso d’opera

ACI INFORMATICA potrà richiedere all’Impresa di apportare modifiche in corso d’opera ai prodotti previsti in ciascun affidamento. In tale evenienza, ACI INFORMATICA e l’Impresa definiranno di comune accordo l’impegno necessario per attuare dette variazioni, che potranno anche comportare la variazione del numero di Function Point o del numero di giorni/persona delle risorse umane da impiegare e la ridefinizione delle date di consegna dei prodotti.



Pagina 44 di 46

15 Risorse professionali

Per le attività previste dal presente Capitolato, l’Impresa dovrà mettere a disposizione le risorse in conformità a quanto previsto nei Verbali di Affidamento, in termini di figure professionali richieste, quantità di risorse per ogni figura professionale, date previste per l’inizio delle singole attività. Per i Servizi Informatici, in funzione della tipologia di attività da svolgere, le risorse vengono classificate nelle seguenti figure professionali:

• ICT Project Manager: deve garantire la realizzazione dei progetti assegnati assicurando il raggiungimento degli obiettivi definiti, monitorandone lo stato di avanzamento ed intervenendo con eventuali azioni correttive. Possiede le conoscenze di base dell’ambiente di produzione e degli strumenti utilizzati per la progettazione e realizzazione. Le competenze tecniche richieste sono: capacità di applicare tecniche di project management, capacità di applicare metodologie di organizzazione del lavoro, conoscenza dei concetti relativi al Software Engineering, conoscenza delle metodologie di analisi, valutazione e controllo dei costi. È richiesta un’esperienza di almeno 10 anni in attività di coordinamento di progetti ICT nonché l’esperienza di coordinamento di progetti di grandi dimensioni.

• Software Engineer Senior J2EE: Fornisce supporto alle attività di analisi, progettazione e implementazione

per gli interventi di sviluppo. Possiede una conoscenza profonda dell’ambiente di produzione (inteso nel suo complesso tecnologico) e degli strumenti indicati per la progettazione e realizzazione. Ha le seguenti competenze tecniche: capacità di analisi e progettazione di applicazioni complesse, perfetta conoscenza dei principali linguaggi di modellazione (UML, notazioni ER), ottima conoscenza dei linguaggi di programmazione (con particolare riguardo per java, javascript e PL/SQL) e delle tecnologie correlate (in particolare corba, ejb, xml, web services, ecc.), sicurezza nell’uso delle basi di dati. Ha un’esperienza di almeno 5 anni in attività di analisi, progettazione e implementazione di sistemi software.

• Software Engineer Senior .Net: Fornisce supporto alle attività di analisi, progettazione e implementazione per gli interventi di sviluppo. Possiede una conoscenza profonda dell’ambiente di produzione (inteso nel suo complesso tecnologico) e degli strumenti indicati per la progettazione e realizzazione. Ha le seguenti competenze tecniche: capacità di analisi e progettazione di applicazioni complesse, perfetta conoscenza dei principali linguaggi di modellazione (UML, notazioni ER), ottima conoscenza dei linguaggi di programmazione (con particolare riguardo per VB, ASP, VB.Net, ASP.Net, javascript, vbscript, T-SQL) e delle tecnologie correlate (web services, ecc.), sicurezza nell’uso delle basi di dati. Ha un’esperienza di almeno 5 anni in attività di analisi, progettazione e implementazione di sistemi software.

• Software Engineer J2EE: devono essere in grado di produrre, a partire dalle specifiche dei requisiti informatici, le specifiche tecniche di sistema e di realizzare software. Le competenze tecniche richieste sono: progettazione O.O. mediante l'utilizzo del linguaggio UML (e.g., Sequence Diagram, Collaboration Diagram, Class Diagram), conoscenza di Rational XDE, progettazione di applicazioni J2EE, progettazione base dati in Oracle, conoscenza dei linguaggio PLSQL, progettazione di web services. È richiesta un’esperienza di almeno 3 anni in attività di analisi e progettazione.

• Software Engineer .Net: devono essere in grado di produrre, a partire dalle specifiche dei requisiti

informatici, le specifiche tecniche di sistema e di realizzare software. Le competenze tecniche richieste sono: progettazione O.O. mediante l'utilizzo del linguaggio UML (e.g., Sequence Diagram, Collaboration Diagram, Class Diagram), conoscenza di Rational XDE, progettazione di applicazioni .Net, progettazione



Pagina 45 di 46

base dati in SQL Server, conoscenza dei linguaggio T-SQL, progettazione di web services. È richiesta un’esperienza di almeno 3 anni in attività di analisi e progettazione.

ACI INFORMATICA ha la facoltà di esaminare le risorse messe a disposizione per verificare la corrispondenza tra le conoscenze e le esperienze maturate e i requisiti richiesti e la generale idoneità a lavorare nell’ambito del progetto. Qualora, per l’esecuzione di un affidamento, alle risorse messe a disposizione dall’Impresa fosse necessario un addestramento specifico sulle procedure adottate in ACI INFORMATICA, sarà a cura di ACI INFORMATICA provvedere all’addestramento mentre l’Impresa metterà a disposizione le risorse a titolo gratuito per tutta la durata dell’addestramento.

16 Stima dei function point e dei giorni/persona richiesti

Nell’ambito degli affidamenti complessivi di cui al presente appalto, le quantità stimate dei function point e dei giorni persona dei livelli professionali di cui al precedente capitolo 16 sono i seguenti:

a) Function point MEV : 2.100 b) Giorni/persona ICT Project Manager 150 c) Giorni/persona Software Engineer Senior J2EE 1.890 d) Giorni/persona Software Engineer Senior .Net 1.260 e) Giorni/persona Software Engineer J2EE 1.890 f) Giorni/persona Software Engineer .Net 1.260

Con riferimento al numero sopra stimato di interventi in GG/PP delle figure professionali di cui alle precedenti lett. a), b), c), d), e) f), g), il dimensionamento stimato per le singole attività è il seguente:

A. Il servizio di Nuovi Sviluppi per totali 380 GG/P, soprattutto nel primo periodo della fornitura, con il seguente mix di figure professionali:

MEV (Fasi alte del ciclo)

Figura Professionale % Utilizzo

ICT Project Manager 8,0 %

Software Engineer Senior 92,0 %

B. Manutenzione evolutiva, adeguativa, migliorativa, per totali 5.670 GG/PP con il seguente mix di figure

professionali


ICT Project Manager 2,0 %

Software Engineer Senior 42,0 %

Software Engineer 56,0 %



Pagina 46 di 46

C. Supporto tecnico nella definizione dei requisiti informatici totali 400 GG/PP con il seguente mix di figure professionali

Attività Informatiche


Software Engineer Senior 100 %

17 Allegati

Formano parte integrante e sostanziale del presente Capitolato tecnico i seguenti allegati:

Numero Allegato 1 Check list per la valutazione documentale 2 Linee Guida Naming & Coding Conventions per Java

ACI Informatica S.p.A. Capitolato tecnico per …...ACI INFORMATICA S.p.A. Gara per l’affidamento...

Documents

Transcript of ACI Informatica S.p.A. Capitolato tecnico per …...ACI INFORMATICA S.p.A. Gara per l’affidamento...