ACI Informatica S.p.A.

Transcript

1 ACI Informatica S.p.A. Capitolato tecnico per la progettazione, realizzazione e manutenzione di componenti software del Sistema Tasse Automobilistiche. Allegato n. 5 Pagina 1 di 29

2 INDICE 1 PREMESSA DESCRIZIONE DEL SISTEMA TASSE Descrizione del contesto Il quadro dei servizi L architettura di riferimento L architettura tecnologica Interfacce con gli utenti Interfacce con altre applicazioni L architettura applicativa Le applicazioni Gli utenti Le dimensioni tecniche del Sistema OGGETTO DELLA FORNITURA DURATA DELLA FORNITURA E PIANO DI SUBENTRO Durata della fornitura Piano di subentro Affiancamento finale MODALITÀ DI DIMENSIONAMENTO DELLE ATTIVITÀ SEDE E STRUMENTI DI LAVORO AMBIENTI DI PRODUZIONE MODALITÀ DI CONTEGGIO DEI FUNCTION POINT STANDARD DI QUALITÀ Profilo di qualità del Sistema Informativo Tasse Standard di qualità per il codice sorgente Pagina 2 di 29

3 9.3 Standard di qualità per la documentazione a corredo MODALITÀ DI AFFIDAMENTO DELLE ATTIVITÀ SERVIZI INFORMATICI Sviluppo software ad hoc e manutenzione evolutiva Descrizione Modalità di consegna intermedia e finale Collaudo Manutenzione adeguativa Descrizione Modalità di consegna intermedia e finale Collaudo Manutenzione correttiva Supporto tecnico nella definizione dei requisiti informatici SOSTITUZIONE DEL PERSONALE DELL IMPRESA MODIFICHE IN CORSO D OPERA RISORSE PROFESSIONALI STIMA DEI FUNCTION POINT E DEI GIORNI/PERSONA RICHIESTI ALLEGATI...28 Pagina 3 di 29

4 1 Premessa ACI avvalendosi delle propria Impresa tecnico-operativa, denominata ACI Informatica, gestisce per conto di alcune Regioni a Statuto Ordinario e delle due Province Autonome di Trento e Bolzano i servizi di Gestione delle Tasse Automobilistiche. Garantisce sia presso gli Uffici Provinciali ACI sia attraverso la rete di Agenzie e Delegazioni, una presenza distribuita su tutto il territorio nazionale per erogare i servizi anzidetti. Eroga informazioni ad utenti della Pubblica Amministrazione Centrale e Locale. Eroga alcuni servizi direttamente agli utenti attraverso Internet. 2 Descrizione del Sistema Tasse 2.1 Descrizione del contesto Il sistema informatico Tasse è di supporto all erogazione dei Servizi offerti da ACI nell ambito della riscossione e del controllo delle Tasse Automobilistiche. Per questo ne eredita completamente il quadro normativo di riferimento. Sempre in questo ambito è da considerare anche il quadro contrattuale di ACI nei confronti delle Regioni e Province Autonome con Esso in qualunque modo convenzionate. 2.2 Il quadro dei servizi L insieme delle convenzioni stipulate tra ACI e le Regioni/Province Autonome definisce le regole attraverso le quali si consente di accedere alle informazioni contenute negli Archivi Tributari o di estrarre dati variamente aggregati, in ragione delle specifiche esigenze del richiedente. L ambito dei servizi ACI è rivolto sia direttamente al cittadino sia a Pubbliche Amministrazioni Centrali e Locali. 2.3 L architettura di riferimento L architettura tecnologica Lo schema che segue, pur se limitato ai 3 principali sottosistemi (archivi tributari, versamenti, riscossione), esemplifica l architettura di riferimento per le applicazioni. Pagina 4 di 29

5 http PDS http http Uff.ACI Application Server http http Application Server Application server WebRiscossione WebTasse WebTariffario Ejb Tariffario WebGestione Versamenti WebPosizione tributaria Ejb Application server Ejb Ejb Application server Ejb Consultazione Posizione Tributaria Ejb Application server Ejb Servizio bollo Ejb Controllo di Merito Gestione Versamenti MQ MQ La tecnologia di riferimento per le applicazioni sviluppate nell ambito del sistema TASSE è J2EE. Essa viene usata sempre nel contesto di una progettazione articolata sul modello delle applicazioni web a tre livelli (three-tiers), standard per la produzione del software in azienda. Requisiti fondamentali di aderenza a tale modello sono la realizzazione di interfacce utente web-based, la separazione e l incapsulamento della logica di business in specifici componenti riusabili e l isolamento del livello d accesso ai dati. Lo specifico tecnologico comprende, tra l altro, l applicazione degli standard riconosciuti per XML, DHTML, jsp e servlet, ejb: Pagina 5 di 29

6 Più nel dettaglio, è possibile affermare che le applicazioni del sistema TASSE si compongono, di norma, di un livello di presentazione realizzato attraverso una interfaccia web costruita con XML, DHTML, jsp e servlet (jakarta struts), di un livello di business realizzato da una serie di componenti riusabili fondati su ejb (session bean, message driven bean) e web services, e di un livello dati costruito interfacciando funzioni custom (stored procedures) del RDBMS (oracle) con ejb (stateless session bean) Interfacce con gli utenti Le interfacce che le applicazioni del sistema TASSE offrono verso gli utenti sono, come già detto, sempre interfacce web based. Esse possono essere rese disponibili in un contesto intranet, extranet o internet, realizzando all occorrenza, implementazioni specifiche che tengono conto delle particolari esigenze legate al tipo d utenza o all ambiente tecnologico. Tutte le applicazioni del sistema TASSE sono integrate o integrabili con sistemi di autenticazione centralizzati e quindi consentono una fruibilità indirizzata attraverso un portale d accesso singolo o la loro integrazione nel quadro di altre applicazioni anche esterne (tipicamente di clienti ACI che fungono da concentratori d accesso). Il layout grafico è normalmente tenuto separato dai dati e dalle regole proprie della presentazione ed è applicato dinamicamente, a mezzo di fogli di stile specializzati (Cascading Style Sheets - CSS scritti per il singolo dispositivo in uso all utente, la configurazione e la tipologia di sistema, ecc.), su un contenuto informativo espresso alla radice in un formato intermedio (XHTML). Per quel che riguarda le modalità di interfacciamento proprio dell utente, ovvero della sua interazione con la specifica applicazione, accanto ai requisiti classici di usabilità, omogeneità ed accessibilità (specifiche WAI), alla progettazione di layout e di meccanismi di navigazione il più possibile user-friendly e non dispersivi, particolare enfasi viene data alla possibilità, per le applicazioni gestionali, di poter fruire di una doppia modalità di acquisizione dei dati, una sviluppata attraverso le convenzionali sequenze di maschere html da riempire manualmente, l altra attraverso l importazione (upload) di singoli file strutturati (xml o a lunghezza fissa). La prima modalità di interazione non presuppone conoscenze tecniche di alcun tipo (se non quelle eventualmente legate al contesto della particolare applicazione ed alle interfacce web in generale), la seconda, invece, assume la disponibilità di file costruiti ad hoc secondo gli schemi di volta in volta pubblicati e, quindi, la capacità di creare tali file. Il vantaggio della prima modalità è un certo tipo di compilazione assistita (vincolata, cioè, dalle regole imposte sulle maschere), quello della seconda è una maggiore velocità Pagina 6 di 29

7 di comunicazione di dati evidentemente già disponibili (ad esempio ad altre applicazioni che l utente potrebbe avere in dotazione e dalle quali dovrebbe essere possibile implementare procedure di esportazione direttamente nel formato richiesto). Più in generale, essendo lo scopo di tutte le applicazioni gestionali del sistema TASSE quello di risolvere, da un lato, l accesso al proprio business e, dall altro, quello di garantire l integrazione con gli strumenti del business dell utente, le modalità di interazione utente prevedono sempre estensioni nel senso dell interoperabilità Interfacce con altre applicazioni Tutte le applicazioni del sistema TASSE offrono, accanto alle tradizionali interfacce end-user, alcune specifiche interfacce di collegamento o di programmazione per l integrazione con sistemi esterni (business to business - b2b) o semplicemente per il riuso dei componenti elementari di business in contesti diversi all interno dello stesso sistema TASSE o degli altri sistemi aziendali. Tali interfacce sono tutte basate sullo scambio di comandi e dati strutturati, di norma, in XML e sono esportate secondo i sistemi standard delle chiamate ai servizi riusabili (tipicamente secondo i protocolli di RPC per essi più comuni nell ambito java RMI, SOAP), ai server web (metodi GET e POST) o ai più svariati sistemi di messaging (stream dati su code, ftp, ecc.). Particolare enfasi è posta comunque, nel sistema TASSE, sull integrazione delle specifiche parti funzionali delle singole applicazioni all interno del più ampio contesto dell architettura orientata ai servizi (Service Oriented Architecture SOA) che l azienda sta realizzando, in special modo per quel che riguarda le possibilità di coordinamento ed orchestrazione delle singole componenti del business da parte degli idonei strumenti previsti (Enterprise Service Bus ESB). 2.4 L architettura applicativa Le applicazioni Il Sistema è composto dai seguenti sottosistemi: Archivi tributari: gestione degli archivi tributari delle Regioni/Province Autonome convenzionate con ACI. Gli archivi vengono alimentati con i dati provenienti dal Pubblico Registro Automobilistico, dal Dipartimento Trasporti Terrestri e dalle stesse Regioni/P.P.A.A.. Contiene i dati tecnico/fiscali dei veicoli ed i dati anagrafici e di residenza dei loro proprietari. Negli archivi sono anche contenuti gli importi dovuti a titolo di tassa per ogni singolo veicolo. Fa parte del sottosistema l applicazione Controllo di merito che verifica la congruità tra i pagamenti provenienti dal sottosistema Versamenti ed i dati contenuti negli archivi tributari. Infine il sottosistema gestisce il tariffario di tutte le Regioni/P.P.A.A. convenzionate. Versamenti: gestione degli archivi regionali/provinciali dei pagamenti effettuati a titolo di tassa automobilistica. Gli archivi vengono alimentati con i dati provenienti da tutti gli intermediari della riscossione presenti sul territorio nazionale. Fa parte del sottosistema l applicazione che fornisce alle singole Regioni/P.P.A.A. convenzionate i rendiconti contabili per la verifica del corretto riversamento degli importi riscossi dai singoli esattori. Infine il sottosistema permette la verifica delle compensazioni tra Regioni a seguito di pagamenti fatti al di fuori della Regione di competenza. Inoltre il sottosistema gestisce la verifica della quadratura tra i versamenti ed i riepiloghi trasmessi dall ente Poste per riscossioni off line. Esenzioni/Sospensioni: gestione degli archivi regionali/provinciali delle esenzioni/sospensioni d imposta a qualsiasi titolo concesse dalle Amministrazioni titolari del tributo. Riscossione: gestione di tutte le richieste di calcolo del dovuto provenienti da qualsiasi intermediario abilitato alla riscossione. Gestione completa della riscossione on line della tassa tramite l utilizzo dei canali previsti: agenzie di pratiche auto, internet, call centre telefonico, terminali Bancomat, ecc.. Procedure di supporto agli adempimenti contabili: controllo e ripartizione dei flussi di cassa, legati alla riscossione delle tasse automobilistiche presso i punti di servizio ACI. Fatturazione delle attività di assistenza che vengono svolte presso i punti di servizio ACI. Inoltre il sottosistema gestisce la verifica della quadratura tra i versamenti ed i riepiloghi trasmessi dall ente Poste per riscossioni off line. Contenzioso: gestione dell archivio delle posizioni debitorie per omesso, insufficiente o tardivo pagamento. Gestione delle comunicazioni ai contribuenti morosi nelle diverse fasi del recupero della tassa evasa. Pagina 7 di 29

8 Rimborsi e compensazioni: gestione delle richieste di rimborso presentate dai contribuenti a seguito di pagamenti eccedenti la tassa dovuta. In luogo del rimborso può essere richiesta la compensazione del maggior importo versato con l importo dovuto per un diverso periodo tributario. Erogazione statistiche: gestione degli archivi statistici e degli strumenti decisionali per la fornitura agli utenti abilitati di informazioni variamente aggregate relative a tutti gli aspetti della gestione della tassa Gli utenti Sono utenti del Sistema: L Agenzia delle Entrate Le Regioni/Province Autonome La Direzione Centrale Servizi Delegati dell ACI gli Uffici Provinciali dell ACI le Delegazioni ACI le Agenzie di pratiche automobilistiche che si avvalgono di ACI come polo telematico gli Istituti di credito abilitati alla riscossione delle T.A. (anche tramite terminali ATM o sistemi di home banking) il Centro di Assistenza Tasse Automobilistiche la Centrale Operativa i cittadini abbonati al servizio Ricorda scadenza i cittadini che accedono ai servizi Tasse on-line via Internet. 2.5 Le dimensioni tecniche del Sistema La base dati Archivi Tributari ha una dimensione di circa 27 milioni di veicoli con un incremento annuo di 1 milione di veicoli. L archivio, in linea 24 ore tutti i giorni, viene quotidianamente aggiornato con movimenti e acceduto per il calcolo della tassa automobilistica (nei giorni di maggior carico a.e. 31 Gennaio sull archivio possono essere effettuati accessi). La base dati Versamenti ha una dimensione di 30 milioni di pagamenti con un incremento annuo di 30 milioni di pagamenti. L archivio, in linea 24 ore tutti i giorni, viene aggiornato dal servizio di riscossione on line e dai pagamenti provenienti dagli intermediari della riscossione. Nei giorni di maggior carico si prevede un aggiornamento di pagamenti. I pagamenti registrati in archivio vengono immediatamente sottoposti a controllo di merito. La dimensione dell intero sistema è stimata in punti funzione. 3 Oggetto della fornitura Oggetto della fornitura sono le attività legate alla realizzazione di componenti software riguardanti i Sistemi e Servizi Tasse: Sviluppo software ad hoc e Manutenzione evolutiva (MEV) Manutenzione adeguativa (MAD) Manutenzione correttiva (MAC) Supporto tecnico nella definizione dei requisiti informatici 4 Durata della fornitura e piano di subentro 4.1 Durata della fornitura I servizi oggetto della fornitura dovranno essere erogati per un periodo di 36 (trentasei) mesi a far data dalla presa in carico delle attività da parte dell Impresa. Pagina 8 di 29

9 4.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 delle attività. L Impresa aggiudicataria dovrà presentare nei tempi previsti dal contratto un elenco delle risorse che saranno messe a disposizione per l esecuzione di tale attività. Durante questo periodo 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 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 specifica attività richiesta da ACI Informatica (sviluppo software ad hoc e Manutenzione Evolutiva, Manutenzione adeguativa, Manutenzione Correttiva, Supporto tecnico nella definizione dei requisiti informatici), in termini di competenze del personale impiegato e giorni lavorativi complessivamente dedicati; tempificazione degli incontri per la verifica dello stato di avanzamento delle attività. 4.3 Affiancamento finale Nel corso dell esecuzione del contratto, anche per fine attività, in maggior misura negli ultimi due 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. Il piano di affiancamento finale dovrà essere presentato dall Impresa al massimo tre mesi prima della scadenza prevista del contratto. 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. 5 Modalità di dimensionamento delle attività A. Relativamente ai servizi: Sviluppo software ad hoc e Manutenzione evolutiva (MEV) Manutenzione adeguativa Pagina 9 di 29

10 Manutenzione correttiva gli incarichi all Impresa verranno articolati in singoli affidamenti. La dimensione di ciascun affidamento verrà espressa in function point e/o giorni persona per lo sviluppo software ad hoc e per la MEV, a canone per ciascun punto funzione affidato per la manutenzione correttiva e in giorni/persona o a corpo per la manutenzione adeguativa. 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 8, che l Impresa fin d ora dichiara espressamente di accettare. Si precisa che fino ad un massimo del 20% di quanto dimensionato contrattualmente per le attività di sviluppo software ad hoc e MEV potrà essere affidato in giorni/persona in luogo di function point. Sarà facoltà di ACI INFORMATICA ricorrere alla misurazione in giorni/persona in luogo di quella in function point. Il ricorso a tale misurazione verrà esplicitato in fase di conferimento dell affidamento. In tal caso, ai fini della determinazione delle prestazioni professionali richieste, si farà riferimento a quanto previsto al capitolo 14. B. Relativamente al servizio: 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. 6 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. Tali stazioni di lavoro dovranno essere dotate dei seguenti tool: Microsoft Office, Rational XDE, IBM Rational Software Development Platform, Rational ClearCase, Oracle Client, PLSQL Developer, Antivirus Trend Micro 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 del servizio 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. 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ò sia necessario, ACI INFORMATICA provvederà, fermo restando le responsabilità dell Impresa, all invio degli aggiornamenti necessari per mantenere l allineamento con l evoluzione dell ambiente di sviluppo e test. Pagina 10 di 29

11 ACI INFORMATICA fornirà alla Impresa le caratteristiche tecniche e operative necessarie al collegamento telematico, i cui oneri saranno totalmente a carico della Impresa. La 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. 7 Ambienti di produzione Gli ambienti di produzione del software sono: Linguaggio Java ed ambiente di sviluppo IBM Rational Application Developer (RAD6), Librerie Open Source di supporto alla realizzazione (struts, jetspeed, ecc.), Sistema Operativo Unix con database Oracle. Il modello architetturale adottato per le applicazioni Tasse è basato sulla piattaforma J2EE e adotta un modello a tre livelli (presentation, business logic, data layer). 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. 8 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. L impresa potrà peraltro essere attivata a richiesta del committente anche nelle fasi alte del ciclo. Tale coinvolgimento verrà misurato in GG/P e secondo il mix di risorse professionali riportato nel capitolo 15 successivo. Il numero di Function Point da realizzare nell ambito di ogni specifico intervento verrà calcolato con le seguenti modalità: (Numero FP) = (FP Ifpug) * (Fr) dove : (FP Ifpug) è il numero dei function point valutato applicando la metodologia IFPUG Unadjusted Function Point Method in conformità allo standard ISO/IEC 14143, alla quale per i sistemi GUI si applicheranno le Linee guida per il conteggio Function Point IFPUG per sistemi G.U.I, (vedi Allegato 16 al presente Capitolato) o la metodologia di stima anticipata Early & quick function Point V. 2.0 e successive. Pagina 11 di 29

12 (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. Esempio: Livello di riuso % di codice uguale Fattore di riuso Nullo 0 1,00 Basso 10 0,85 Medio ,70 Alto 30 0,50 Molto Alto > 50 0,30 FP a consuntivo = 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. (A questo proposito si deve tener presente che la valutazione economica dei Function Point non riguarda l intero ciclo di vita dei software ma solo le fasi che vanno dalla progettazione tecnica fino al system test) 9 Standard di qualità Nei paragrafi successivi vengono 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. 9.1 Profilo di qualità del Sistema Informativo Tasse 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 dei Servizi Tasse. Il profilo della qualità di seguito richiesto si intende valido per tutti i prodotti, poiché questi hanno caratteristiche molto simili tra di loro (linguaggi utilizzati, logica di business, piattaforme ed architettura tecnologica, ecc.). a) Funzionalità - capacità di fornire servizi tali da soddisfare, in determinate condizioni, requisiti funzionali espliciti o impliciti (il software fa ciò per fare 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); Accuratezza dell output (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. Pagina 12 di 29

13 Gli indicatori della qualità relativi alla Funzionalità che sono stati individuati e ritenuti maggiormente significativi sono riportati nella tabella seguente. Indicatore A01 A02 A03 A04 A03 Caratteristica di Qualità (Funzionalità) Adeguatezza Presenza e correttezza del maggior numero possibile di funzioni specifiche per l uso cui il prodotto è destinato. Accuratezza dell output Percentuale dei risultati errati o degli effetti non corretti delle elaborazioni rispetto al numero totale dei risultati o delle elaborazioni effettuate. Interoperabilità Capacità del software di interagire con altri sistemi specificati Aderenza agli standard Aderenza del software a prescrizioni di legge, convenzioni o regolamenti Sicurezza Capacità di rendere accessibili i dati riservati, personali e/o sensibili solo agli utenti autorizzati Descrizione 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 15. 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. Qualora richiesto dalle Specifiche di prodotto, deve poter essere realizzato ed integrato sia per il corretto funzionamento con altre componenti, sia per il corretto funzionamento tramite l accesso al Portale delle applicazioni Tasse. Il quadro istituzionale specifico e il quadro normativo di riferimento è quello specifico delle Tasse Automobilistiche Regionali. Qualora richiesto dalle Specifiche di prodotto, deve poter essere realizzato ed integrato per il corretto funzionamento tramite l accesso al Portale delle applicazioni Tasse. Valore soglia 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. 2 errori ogni 100 FP collaudati. In fase di Collaudo verrà verificato sia il corretto funzionamento ed integrazione con altre componenti, sia il corretto funzionamento ed integrazione tramite l accesso al Portale delle applicazioni Tasse. In fase di Collaudo verrà verificata l aderenza al quadro normativo di riferimento. In fase di Collaudo verrà verificato il corretto funzionamento ed integrazione tramite l accesso al Portale delle applicazioni Tasse. 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. Pagina 13 di 29

14 Indicatore A02 A05 A06 Caratteristica di Qualità (Affidabilità) Maturità Frequenza di anomalie dovute ad errori software Tolleranza ai guasti Capacità di mantenere uno specificato livello di funzionalità anche in caso di errori sw o anomalie dei flussi di input Ripristinabilità Ripristinabilità delle informazioni critiche gestite dal software Aderenza agli standard Aderenza del software a standard di affidabilità Descrizione 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. 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. Viene verificato in fase di collaudo il numero delle volte in cui è necessario ripristinare la base dati a fronte di una anomalia Devono essere rispettate le Linee Guida del documento Naming & Coding Conventions per Java (allegato 17). 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 checkstyle). Valore soglia 2 errori ogni 100 FP collaudati. 1 ripristino ogni 50 anomalie riscontrate. 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 imparare ad usarlo); 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. Pagina 14 di 29

15 Indicatore A07 Caratteristica di Qualità (Usabilità) Comprensibilità Sforzo richiesto agli utenti per comprendere i concetti logici del software e la loro applicabilità 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à Descrizione Le specifiche dei singoli affidamenti riportano i requisiti di usabilità richiesti Valore soglia Sia in fase di verifica della documentazione, sia in fase di Collaudo non sono ammesse modalità diverse da quanto descritto nelle Specifiche dei singoli affidamenti. 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 A08 A09 Caratteristica di Qualità (Efficienza) Tempi di risposta Capacità del software di rispondere, elaborare e fornire dati in output nei tempi previsti Uso di risorse Quantità di risorse utilizzate ed al relativo tempo di utilizzo Aderenza agli standard Aderenza del software a standard di efficienza Descrizione Qualora richiesto verrà definito nelle Specifiche di prodotto. Viene verificato l utilizzo della quantità e della tipologia di risorse affinché sia adeguato ad eseguire le funzioni richieste. Valore soglia In fase di Collaudo verrà effettuata opportuna misurazione secondo quanto previsto dalle Specifiche di prodotto. Nel caso di manutenzione evolutiva/adeguativa e di manutenzione correttiva) i tempi di risposta non dovranno essere mai superiori ai tempi di risposta prima della modifica. 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 nel paragrafo 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); Pagina 15 di 29

16 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. Indicatore A10 A11 A02 A01 A06 CARATTERISTICA DI QUALITÀ (MANUTENIBILITÀ) Analizzabilità Sforzo necessario per individuare quali componenti hanno causato un anomalia Modificabilità Sforzo necessario per gli interventi sui componenti che hanno causato un anomalia Stabilità Rischio di effetti inattesi delle modifiche Facilità di testing Sforzo necessario per validare il software modificato Aderenza agli standard Aderenza del software a standard di manutenibilità Descrizione Viene presa in considerazione la percentuale di commenti significativi all interno del codice sviluppato. Vengono presi in considerazione i commenti all interno del codice sviluppato, relativamente alle strutture di controllo. 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. 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 15. Devono essere rispettate le Linee Guida del documento Naming & Coding Conventions per Java (allegato 17). 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 checkstyle). Valore soglia La percentuale di commenti significativi non deve essere inferiore al 10% delle linee di istruzione. Non sono ammessi componenti che abbiano strutture di controllo senza commenti. 2 errori ogni 100 FP collaudati. 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. 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 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. Pagina 16 di 29

17 Gli indicatori della qualità relativi alla Portabilità che sono stati individuati e ritenuti maggiormente significativi sono riportati nella tabella seguente. Indicatore A12 A13 A12 Caratteristica di Qualità (Portabilità) Adattabilità ai cambiamenti Possibilità di adattare il software ad ambienti diversi senza applicare azioni diverse da quelle previste a tale scopo Installabilità Sforzo necessario per installare il software in un ambiente specificato Coesistenza Capacità del software di coesistere con altri prodotti sulla stessa piattaforma 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à Descrizione Vale quanto descritto nel paragrafo 2.3 Architettura di riferimento. Qualora richiesto dalle Specifiche di prodotto, devono essere realizzate funzioni specifiche di installazione e/o disinstallazione del pacchetto. Vale quanto descritto nel paragrafo Valore soglia In fase di Collaudo viene verificato che il requisito sia quello previsto dai documenti di Specifica e che rispetti l Architettura di riferimento descritta nel paragrafo 2.3 Architettura di riferimento. Presenza e corretto funzionamento di funzioni specifiche di installazione e/o disinstallazione. In fase di Collaudo viene verificato che il requisito sia quello previsto dai documenti di Specifica e che rispetti l Architettura di riferimento descritta nel paragrafo Standard di qualità per il codice sorgente Devono essere rispettati i seguenti parametri di 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 conferimento del singolo affidamento 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 (allegato 17). 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). Verranno forniti alcuni documenti che regolano le modalità architetturali con cui devono essere realizzate le applicazioni web, i servizi ejb, l accesso a componenti centralizzati (Single Sign On, servizigic, tabelle ecc.). L introduzione nelle applicazioni di librerie java esterne (jar) dovrà essere preventivamente autorizzato da Aci Informatica. 9.3 Standard di qualità per la documentazione a corredo I documenti che l Impresa dovrà produrre a corredo degli affidamenti per Sviluppo software ad hoc e, Manutenzione Evolutiva, saranno sottoposti a verifica tramite la check list riportata in allegato 15. Il punteggio medio risultante dall analisi così effettuata non dovrà essere inferiore: a 3 nella media generale; a 2,5 nel punteggio medio dei singoli fattori qualitativi. Pagina 17 di 29

18 10 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: per le attività di sviluppo software ad hoc e di manutenzione evolutiva il numero dei function point stimati o dei giorni/persona stimati; per le attività di manutenzione adeguativa il numero dei giorni/persona stimati o l indicazione di affidamento a corpo; per le attività di manutenzione correttiva il numero di function point affidati a canone, per le attività di supporto nella definizione dei requisiti informatici il numero di giorni/persona stimati. Nel Verbale di affidamento saranno altresì indicati gli standard di qualità da applicare in base a quanto riportato nel capitolo 9. Al verbale di affidamento saranno allegati i seguenti documenti: Nel caso di sviluppo software ad hoc e MEV, la Specifica dei requisiti informatici (@SQDOS2 v. Allegato 2 ) Nel caso di manutenzione adeguativa, la Gestione della modifica (@SQMOMO v. Allegato 3) Nel caso di manutenzione correttiva, il foglio di anomalia (@SQMOFM v. allegato 14) 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. In particolare: Nel caso di sviluppo software ad hoc e MEV l Impresa dovrà consegnare il documento Specifiche tecniche di sistema (@SQDOT2) che formalizza l attività di progettazione, il cui standard di compilazione è riportato in allegato 1. Nel caso di manutenzione adeguativa l Impresa dovrà consegnare il documento Specifiche tecniche di sistema (@SQDOT2) opportunamente aggiornato, che formalizza l attività di progettazione, il cui standard di compilazione è riportato in allegato 1. Per tali attività l Impresa metterà a disposizione i necessari strumenti di lavoro secondo quanto previsto al capitolo Servizi Informatici 11.1 Sviluppo software ad hoc e manutenzione evolutiva Descrizione Comprende le attività di progettazione, realizzazione, test e rilascio di nuovi componenti informatici, le attività volte ad estendere un sistema applicativo modificandone o integrandone le funzionalità (in una maniera che implica la scrittura di funzioni aggiuntive o parti di funzioni, anche in sostituzione di altre già esistenti) o arricchendolo di nuove caratteristiche non funzionali (usabilità, prestazioni, ecc.) nonché la manutenzione correttiva in garanzia di durata pari a 12 mesi dalla data successiva a quella in cui sia stato positivamente superato il collaudo e comunque non oltre la fine del contratto, che sarà svolta dall Impresa senza alcun onere aggiuntivo per ACI INFORMATICA. È opportuno precisare che non rientrano in questo servizio le seguenti tipologie: i piccoli interventi di manutenzione evolutiva che comprendono modifiche anche urgenti alle funzioni, realizzate con tempi e risorse contenuti (ad esempio la modifica di una transazione o di un tabulato per una diversa prospettazione dei dati); tali modifiche non comportano alcun impatto significativo sull architettura generale delle applicazioni, sui processi o sull organizzazione del lavoro degli utenti Pagina 18 di 29

19 finali; possono comportare, a volte, una variazione, di norma molto limitata, della consistenza della baseline; la manutenzione preventiva, che riguarda le possibili non conformità che, pur non essendosi ancora manifestate, potrebbero manifestarsi. Per esempio rientrano in questa categoria i criteri di robustezza (reazione ai possibili fault provocati da manovre). Le attività si articoleranno in singoli affidamenti conferiti formalmente di volta in volta da ACI INFORMATICA all Impresa con le modalità definite al capitolo 10. Di seguito è riportata la tabella che definisce le attività e i prodotti propri di ogni fase del ciclo di vita per lo sviluppo del software. Prodotti di scambio Responsabile Modelli adottati Allegato Fase di progettazione componenti Verbale di affidamento ACI Informatica Specifiche dei requisiti informatici J2EE ACI 2 Piano di gestione della configurazione ACI 6 Specifiche tecniche di sistema J2EE 1 Piano di test 7 Verbale di consegna intermedia Impresa Rapporto di verifica specifiche tecniche ACI 8 Rapporto di verifica piano di test ACI 8 Fase di sviluppo componenti Software sviluppato Impresa Fogli di test 9 Rapporto di test 10 Manuale utente 11 Manuale di gestione 4 Manuale di installazione 12 Manuale di manutenzione 13 Verbale di consegna finale Impresa Fase di collaudo Foglio anomalia ACI 14 Rapporto di collaudo ACI Informatica Verbale di collaudo ACI Modalità di consegna intermedia e finale 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 Pagina 19 di 29

20 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 Consegna finale La quantità di funzionalità effettivamente realizzate verrà valutata a consuntivo con le misurazioni e le regole descritte nel capitolo 5 e dei Function Point effettuate secondo quanto riportato nel capitolo 8; oppure giorni/persona. 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 ; 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 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 Collaudo. Al Verbale di Collaudo, 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 20 di 29