Contract

Il processo di sviluppo o manutenzione consiste in una sequenza strutturata di fasi che può essere definito in accordo a una metodologia o a uno standard in cui sono stabiliti ruoli, modalità di esecuzione e comunicazione, controlli e rilasci. Il prodotto software è composto da un codice sorgente, da un eseguibile, da tabelle di configurazione e da documentazione connessa.

Nell’ambito della fornitura i processi di sviluppo software sono sia di tipo tradizionale a cascata sia di tipo iterativo/incrementale anche in riferimento a quanto indicato nel Piano Triennale per l’informatica nella Pubblica Amministrazione 2019-2021. La scelta del processo di sviluppo da adottare è demandata all’Ente all’atto dell’attivazione del Progetto.

Il Processo adottato dovrà essere formalizzato nel Piano di Progetto, documento obbligatorio a prescindere dal processo di sviluppo di adotta per il progetto. Nel Piano di Progetto, in relazione ad interventi di sviluppo di nuove applicazioni, il Fornitore dovrà prevedere le seguenti ulteriori fasi:

▪ Fase di stress test o performance test. I parametri di performance saranno definiti con l’Ente.

▪ Fase di verifica e approvazione dei dati migrati da parte dell’Ente, ove prevista la sostituzione di una applicazione.

▪ Fase di predisposizione di un remediation plan, un piano di back-out (piano di risanamento) per garantire che i servizi possano essere ripristinati alle precedenti condizioni di lavoro. Questo piano dovrà comprendere le fasi e le azioni da seguire per ripristinare la situazione iniziale prima che la modifica inizi ad essere attuata. In questo modo, anche se l'attuazione della modifica non ha successo, l'attuazione può essere invertita seguendo le fasi del piano di back-out.

▪ Fase di formazione:

– degli utenti delle applicazioni;

– dei referenti dell’Ente;

– degli operatori di Service Desk.

Indipendentemente dal processo adottato i criteri di uscita di fase sono:

▪ “Attivazione”, “Approvazione” ed “Accettazione” includono anche l’approvazione/validazione dei prodotti di fase, pertanto nel Piano di lavoro di Progetto deve essere data tale evidenza;

▪ “Consegna” può essere sostituito dall’approvazione di uno o più prodotti della relativa fase, qualora il responsabile dell’Ente lo ritenga opportuno e comunque non implica di per sé l’accettazione dei prodotti di fase.

1.1 Fasi e Documenti del Processo di sviluppo software a cascata

Le fasi e i documenti per il modello a cascata sono sintetizzati nella tabella che segue.

Fase	Prodotto di fase	Criterio di uscita
Definizione	Piano di Progetto (stima FP iniziale)	Attivazione
	Prototipo (se previsto)
	Specifica dei Requisiti funzionali e non funzionali (rif Guida AgID)
Analisi	Specifiche funzionali	Approvazione (Verifica di Conformità)
	Prototipo (se previsto)
	Piano di test
	Convalida sulla tecnologia
	Conteggio FP di revisione
Disegno	Disegno di dettaglio	Approvazione (Verifica di Conformità)
	Documentazione dati
	Piano di test
	Campione tecnico (se previsto)
Realizzazione	Codice sorgente	Consegna
	Piano di test e Piano di Collaudo
	Documentazione utente
	Documentazione delle procedure batch/DTS
	Manuale di gestione applicativo
	Manuale di gestione server
	Conteggio FP consuntivo
	Report di inventario funzionale
	Lista Oggetti Software
	Report indici qualità del software
	Piano di adeguamento degli ambienti
Collaudo	Prodotto Software	Accettazione (Verifica di Conformità)
Documentazione	Piano di Progetto	Consegna
	Rapporto indicatori di qualità di Progetto
	Documento di sintesi di Area
	Specifiche requisiti di applicazione
	Specifiche funzionali di applicazione
	Disegno di dettaglio di applicazione
Avvio in esercizio	Piano di Progetto	Valutazione difettosità all’avvio per il periodo di osservazione (Verifica di Conformità)
Avvio in esercizio	Rapporto indicatore di qualità

Nelle fasi di definizione, analisi e altre equivalenti, è richiesto al fornitore una forte e costante interazione con il personale dell’Ente al fine di pervenire in tempi comunque brevi alla formalizzazione completa del Progetto.

In generale le modifiche intercorse in una determinata fase comportano l’aggiornamento dei prodotti delle fasi precedenti impattati dalle modifiche stesse.

Per tutte le fasi per cui viene richiesta l’interazione con l’Ente e/o utenti, il fornitore ne dovrà curare la verbalizzazione.

Si precisa che la responsabilità di tutte le fasi, ad eccezione di quella di collaudo, ove comunque il fornitore dovrà fornire appropriato supporto all’Ente, è del fornitore.

1.1.1 Definizione

Gli scopi principali della fase di definizione sono:

▪ descrivere formalmente il sistema attuale e individuare problemi, vincoli, carenze e peculiarità di ogni funzione analizzata;

▪ definire un modello del sistema da realizzare che rappresenti la struttura logica in termini di comportamento complessivo, informazioni da trattare, funzioni da svolgere o a cui fornire supporto;

▪ concordare le modalità tecniche di realizzazione, nonché l’applicabilità di alcuni prodotti (prototipo e campione tecnico, convalida della tecnologia, ecc.);

▪ definire l’infrastruttura del sistema e la soluzione tecnologica;

▪ proporre la pianificazione delle attività, in termini di stima di tempi, risorse e effort realizzativo (secondo la metrica adottata);

▪ realizzare i prodotti di fase.

La fase può avere in input documenti preesistenti quali studi di fattibilità, verbali di riunioni, bozze di requisiti, nonché, se applicabile, la documentazione dei sistemi esistenti.

La fine della fase è rappresentata dall’approvazione di tutti i documenti di fase (attività inclusa nel criterio di fase “attivazione”).

Con l’attivazione l’Ente autorizza a proseguire nelle attività, secondo la stima e la pianificazione proposte dal fornitore.

1.1.2 Analisi

I principali obiettivi della fase di analisi sono:

▪ descrivere formalmente l’applicazione e/o le funzioni da sviluppare in termini di esigenze funzionali dell’utenza e di esigenze non funzionali, in

modo chiaro, esaustivo e sistematizzato, compresa la descrizione logica delle interconnessioni con altri sistemi/applicazioni/apparati/aree applicative;

▪ individuare la soluzione applicativa e tecnologica adeguata al soddisfacimento delle esigenze funzionali e non funzionali di cui sopra, con particolare attenzione a facilitarne la comprensione da parte delle strutture tecniche, applicative ed amministrative;

▪ individuare i requisiti non funzionali secondo la classificazione dei requisiti della Guida tecnica all’uso di metriche per il software applicativo sviluppato per conto delle pubbliche amministrazioni di AgID;

▪ validare e dettagliare la pianificazione e la stima dell’effort motivando eventuali scostamenti;

▪ progettare il test con particolare attenzione all’individuazione delle tipologie di test (es. stress test, test accessibilità, test sulla corretta predisposizione dell’ambiente di collaudo, ecc…), dei criteri di scelta dei test da automatizzare, individuare la base dati necessaria per il test, eventuali criticità note;

▪ individuare i rischi di progetto e definire le azioni correttive;

▪ realizzare i prodotti di fase.

La fine della fase è definita dall’approvazione di tutti i documenti di fase.

Dopo l’approvazione sarà avviata la relativa verifica di conformità e, per esito positivo della verifica, sarà rilasciata la certificazione della corretta esecuzione del servizio relativamente ai prodotti oggetto di approvazione.

1.1.3 Disegno

Gli scopi principali della fase di disegno sono:

▪ descrivere ogni elemento da realizzare, le modalità d'integrazione con gli altri elementi, i vincoli e i controlli cui devono essere sottoposti gli elementi;

▪ descrivere tutti i dati trattati raggruppati per insiemi logici (schema logico e fisico dei dati) e rappresentare il mapping con lo schema concettuale;

▪ dettagliare le modalità di interconnessione con altri sistemi/applicazioni/aree applicative/apparati;

▪ progettare i test;

▪ validare e dettagliare la pianificazione motivando eventuali scostamenti;

▪ realizzare i prodotti di fase;

▪ aggiornare, in caso di modifiche intercorse, i prodotti delle fasi precedenti.

La fine della fase è definita dalla consegna dei documenti sottolineando che l’avvenuta consegna non esclude la possibilità di dover apportare modifiche ai documenti a fronte delle verifiche effettuate dall’Ente.

La consegna, qualora il responsabile di progetto dell’Ente lo ritenga opportuno, può essere sostituita dall’approvazione dei prodotti della fase in ragione della dimensione, criticità e tipologia del Progetto.

1.1.4 Realizzazione

Gli scopi principali della fase di realizzazione sono:

▪ effettuare l’implementazione del sistema, producendo il codice sorgente;

▪ eseguire i test e relativo codice di test;

▪ realizzare i prodotti di fase;

▪ consegnare alla gestione della configurazione i componenti realizzati e la relativa documentazione;

▪ aggiornare, in caso di modifiche intercorse, i prodotti delle fasi precedenti;

▪ predisporre l’ambiente di collaudo, effettuando le opportune attività per verificarne la correttezza.

La fine della fase è definita dalla consegna dei prodotti di fase, sottolineando che l’avvenuta consegna non implica di per sé accettazione.

1.1.5 Verifica del software realizzato

La fase di verifica del software realizzato è di responsabilità dell’Ente che agirà come unica interfaccia nei confronti del Fornitore.

Saranno oggetto di verifica tutti i prodotti delle fasi precedenti afferenti il singolo lotto.

La fase di verifica comprende da parte del fornitore il supporto alla verifica del software realizzato, la rimozione delle anomalie fino al momento dell’accettazione, il supporto all’installazione delle procedure realizzate negli ambienti di esercizio e manutenzione (definizione e caricamento della base dati, installazione del software applicativo, personalizzazione del software di base, ecc) ed il supporto alla ri-esecuzione dei test automatizzati.

1.1.6 Collaudo

La fase di collaudo del software realizzato è di responsabilità dell’Ente che agirà come unica interfaccia nei confronti del Fornitore.

Saranno oggetto di verifica durante il periodo di collaudo tutti i prodotti delle fasi precedenti.

La fase di collaudo comprende da parte del fornitore il supporto al collaudo stesso, la rimozione delle anomalie fino al momento dell’accettazione, il supporto all’installazione delle procedure realizzate negli ambienti di esercizio e manutenzione (definizione e caricamento della base dati, installazione del software applicativo, personalizzazione del software di base, ecc) ed il supporto alla ri-esecuzione dei test automatizzati.

La fase si conclude con l’accettazione del software.

Dopo l’accettazione sarà avviata la relativa verifica di conformità e, per esito positivo della verifica, sarà rilasciata la certificazione della corretta esecuzione del servizio relativamente ai prodotti oggetto di accettazione.

1.1.7 Documentazione

La fase di documentazione ha la finalità di standardizzare e strutturare nei documenti ufficiali quanto previsto dalle fasi precedenti.

I requisiti minimi per la documentazione prodotta dal Fornitore che verranno verificati dall’Ente ai fini dell’approvazione sono:

▪ completezza e accuratezza,

▪ correttezza,

▪ fruibilità,

▪ aderenza e coerenza con lo standard (struttura e contenuti) di Specifiche funzionali riportato al § 4.6.

La fine della fase è definita dalla consegna dei prodotti di fase, sottolineando che l’avvenuta consegna non implica di per sé accettazione.

1.1.8 Avvio in esercizio

La fase parte dalla messa in esercizio e prosegue fino al termine del periodo di osservazione come definito nel Capitolato tecnico.

Scopo della fase è quello di monitorare il software sviluppato/modificato dal progetto per poterne verificare la difettosità nei primi tre mesi di esercizio. Nel corso di tale fase il fornitore di sviluppo dovrà garantire adeguato supporto all’Ente e al servizio di gestione dell’esercizio delle applicazioni per la risoluzione dei problemi.

La fase si conclude al termine del periodo di avvio in esercizio come fissato dal Capitolato tecnico per esito positivo della verifica, in caso contrario è prevista una penale.

Si precisa che qualora la messa in esercizio del software avvenga negli ultimi tre mesi di durata del contratto il periodo di monitoraggio del software sviluppato/modificato si concluderà alla scadenza contrattuale.

1.2 Processo di sviluppo iterativo/incrementale

Questo processo impone un alto grado di sinergia e collaborazione tra le strutture dell’Amministrazione e quelle del Fornitore. Nel Processo iterativo devono essere in linea generale, previste:

▪ una fase iniziale nella quale il Fornitore dovrà produrre i documenti necessari a descrivere compiutamente contesto e caratteristiche peculiari del progetto nonché fornire una stima iniziale dell’intervento.

▪ una sequenza successiva di brevi iterazioni e relative a unità di prodotto auto-consistente e significativa a durata predefinita che comprendono: l’analisi dei requisiti di dettaglio, la progettazione, la realizzazione, il test.

▪ una fase finale di collaudo nonché l’installazione per il rilascio in esercizio.

Alla fine di ogni iterazione, sono previsti momenti intermedi di controllo, per attuare in corso d’opera attività di verifica di aderenza delle componenti progettate e realizzate nell’iterazione ai requisiti definiti. Tali verifiche sono propedeutiche alla fase di Collaudo, sono effettuate dal Fornitore in totale autonomia garantendo allo stesso tempo la completa trasparenza verso ENAC.

Tra i documenti da produrre è obbligatorio predisporre il Piano di Progetto nel quale il Fornitore dovrà indicare in maniera chiara di quanto previsto del processo concordato con l’Ente in termini di fasi e deliverable.

Per l’uso più efficace delle metriche di dimensionamento del software in FP di attività di sviluppo che prevedano processi iterativi, nel seguito sono sintetizzate le indicazioni specifiche da seguire:

▪ per quanto riguarda i Punti Funzione:

– la prima iterazione deve essere trattata come uno sviluppo (considerando nella stima tutti gli elementi come ADD)

– le successive iterazioni come interventi di manutenzione evolutiva (quindi conteggiando punti funzione ADD, CHG e DEL); a ogni iterazione si misura solo la porzione di software che è stata rilasciata.

▪ alcune iterazioni potrebbero includere correzioni di difetti riscontrati in iterazioni precedenti, oppure interventi migliorativi di caratteristiche non funzionali (usabilità, prestazioni, ecc.). In questi casi sono necessarie metriche non funzionali per quantificare gli interventi.

1.3 Accettazione/Approvazione

L’Ente sottopone ad Accettazione/Approvazione tutti i prodotti previsti per i servizi al fine di verificare la rispondenza dei prodotti stessi ai requisiti stabiliti (funzionali e non funzionali).

Le anomalie/malfunzionamenti/disallineamenti dovranno essere tempestivamente risolte dal Fornitore per permettere la prosecuzione delle attività, entro comunque i tempi definiti dai livelli di servizi. Eventuali ritardi nella risoluzione delle anomalie riscontrate comporteranno l’applicazione delle sanzioni contrattualmente previste.

Nel caso si verifichino situazioni “anomale” che, a giudizio dell’Ente, sia per numerosità sia per gravità, sia per non rispetto dei tempi massimi indicati dall’Ente per la risoluzione delle anomalie, non consentano lo svolgimento o la prosecuzione delle attività l’Ente procederà alla sospensione del progetto e lo slittamento del termine della fase sarà a totale carico del Fornitore comportando le azioni contrattuali previste.

I nuovi termini di consegna dei prodotti verranno indicati dall’Ente ed entro tali termini il Fornitore dovrà procedere alla consegna della versione corretta dei prodotti stessi. In caso di 2 sospensioni sul medesimo progetto l’Ente si riserva la facoltà di dichiarare non approvabile il prodotto oggetto di verifica per inadempimento del Fornitore e l’Ente potrà valutare il risarcimento dei danni all’Ente e l’eventuale risoluzione del Contratto.

All’atto dell’accettazione dei prodotti del progetto, in caso in cui sia possibile procedere all’accettazione/approvazione dei prodotti, verrà redatto e sottoscritto dall’Ente il verbale di accettazione. Tale documento sarà utilizzato in fase di Verifica di Conformità.

Le attività di accettazione vengono pianificate nella fase di Collaudo. Tale fase è di responsabilità dell’Ente: l’esecuzione dei test di collaudo avverrà in contraddittorio con il fornitore che è tenuto a dare supporto all’Ente, senza alcun onere aggiuntivo.

Al termine del collaudo, verrà redatto il verbale di collaudo con allegati i casi di test eseguiti ed il relativo esito. Tali dati determineranno il valore

dell’indicatore di qualità “Tasso di Casi di test eseguiti in collaudo con esito negativo”.

Si precisa che qualora il valore rilevato dell’indicatore sia inferiore al 10%, non si ha una formale sospensione del collaudo e l’Ente darà un termine molto limitato (indicativamente un termine di 3 giorni lavorativi) per riconsegnare il software corretto e verranno riprese le attività di collaudo senza alcuna ripianificazione.

Diversamente, qualora il valore rilevato dell’indicatore sia superiore al 10%, verrà sospeso il collaudo. L’Ente ed il fornitore concorderanno il tempo di sospensione ed a tale periodo sarà applicato l’apposito indicatore di qualità.

Nel caso di 2 sospensioni sulla medesima attività/fase/prodotto, l’Ente si riserva di risolvere il contratto per inadempimento del fornitore.

In caso di progetti realizzativi molto piccoli in termini di punti funzione, per i quali non si addice la misurazione in termini percentuali della difettosità (casi di test indicativamente inferiori a 50), sarà l’Ente a stabilire le soglie di difettosità fisiologica e le modalità di sospensione del collaudo.

1.4 Assenza di Virus

Tutti i prodotti consegnati su supporti ottici o in via telematica dovranno essere esenti da virus. L’Ente si riserva di verificare l’assenza di virus secondo le modalità e gli strumenti che riterrà più opportuni.

1.5 Verifiche di conformità

Il soggetto deputato dall’Ente all’esecuzione delle attività di verifica di conformità, dopo aver acquisito la documentazione tecnico-funzionale dei servizi (sia a carattere continuativo che progettuale), procederà a certificare la corretta esecuzione degli stessi. Della verifica di conformità si darà apposita comunicazione al fornitore che potrà parteciparvi. Al termine della suddetta verifica verrà data comunicazione formale al fornitore.

2 CONTENUTI DI MASSIMA DEI DOCUMENTI

I prodotti di fase sono obbligatori.

Tutti i documenti dovranno essere usabili e particolarmente curati negli aspetti di:

▪ comprensibilità e fruibilità dei contenuti,

▪ coerenza dei contenuti con i documenti rispetto alle eventuali fasi precedenti,

▪ completezza e accuratezza dei contenuti,

▪ aderenza e coerenza del documento con gli standard di qualità di ENAC.

Tutti i documenti prodotti dovranno essere mantenuti aggiornati al rilascio di qualsiasi intervento relativo all’area applicativa stessa indipendentemente dal processo di sviluppo adottato, tali documenti saranno pertanto unici per area applicativa e verranno aggiornati di volta in volta.

I documenti riferiti al singolo progetto (ad esempio di manutenzione) verranno prodotti ed aggiornati durante il processo di sviluppo del progetto stesso ed i loro contenuti dovranno essere integrati, organici e congrui con i contenuti degli altri prodotti esistenti dell’applicazione. Inoltre, i documenti di progetto dovranno essere redatti ad un livello di completezza tale da:

▪ consentire l’approvazione da parte dell’Ente;

▪ consentire lo svolgimento della successiva fase;

▪ garantire la tracciabilità con quanto descritto nei documenti collegati (esempio specifiche requisiti e specifiche funzionali, ecc.).

2.1 Piano di lavoro del Progetto

Il Piano di lavoro del Progetto, relativo alle attività di carattere progettuale, contiene il dettaglio delle attività di ogni singola fase, la relativa tempificazione e le stime di impegno.

È un documento specifico dell’intervento.

L’aggiornamento dello stato di avanzamento delle attività, su richiesta dell’Ente, non determina una nuova versione del documento.

Coerentemente con i processi di sviluppo definiti e con lo stato temporale (piano iniziale o aggiornamento), il Piano di lavoro riporterà:

▪ il nominativo del capo progetto;

▪ codice, nome, descrizione dell’intervento e, se significativo, relativo stato (sospeso, cancellato, ecc.);

▪ processo di sviluppo adottato;

▪ impegno, stimato ed effettivo, secondo la metrica applicabile (PF o giorni persona) per il progettuale. Nel caso di obiettivi a giorni persona l’impegno deve essere suddiviso per fase/attività e per figura professionale;

▪ il gruppo di lavoro ed il relativo mix nel caso di obiettivi in g/p.

▪ il gantt delle attività, contenente:

– elenco delle fasi e delle singole attività con relative date di inizio e fine, previste ed effettive;

– prodotti di fornitura delle singole fasi e prodotti intermedi delle singole attività, anche semilavorati, con relative date di consegna, previste ed effettive.

▪ il gantt dovrà contenere anche l’attività di approvazione dei prodotti di fase, ove prevista, riportando le date di inizio e fine concordate con l’Ente. Pertanto, le date finali delle varie fasi devono essere comprensive anche dell’eventuale tempo di approvazione dei prodotti;

▪ all’interno del gantt dovranno essere esplicitate le seguenti attività:

– attività di test (o verifica, validazione, review);

– attività di predisposizione e relativa verifica degli ambienti di collaudo ed esercizio;

– attività di trasferimento del know-how al gruppo di gestione applicativa;

– attività per il passaggio di conoscenze ai referenti di aree integrate, ove il progetto abbia ripercussioni sulle funzionalità di altre aree applicative.

▪ nel caso di obiettivi che prevedano la suddivisione in lotti, inoltre, il piano dovrà dettagliare, anche in termini di stime, ogni singolo lotto;

Per la parte di stato di avanzamento le informazioni da riportare riguardano:

▪ percentuale di avanzamento delle singole attività;

▪ data a cui si riferisce lo stato di avanzamento;

▪ razionali di ripianificazione

▪ scostamento eventuale delle date, dell’impegno e del volume;

▪ xxxxxxx/criticità e relative azioni da intraprendere e/o intraprese.

Per gli obiettivi misurati con la metrica “giorni/persona” il piano di lavoro dovrà essere corredato del Rendiconto Risorse (per i contenuti cfr relativo paragrafo).

2.2 Specifica dei requisiti

Contiene la descrizione dei requisiti, funzionali e non, emersi nella fase di definizione delle esigenze utente.

Qualora per il progetto non sia richiesta la realizzazione del prototipo e/o del campione tecnico nel documento specifiche dei requisiti deve essere formalizzato il motivo della non applicabilità.

2.3 Verbale dei requisiti

È un documento che contiene la descrizione sintetica dei requisiti, funzionali e non, espressi dall’utente redatto sotto forma di verbale.

2.4 Specifica Funzionale

È un documento di progetto che contiene in modo completo ed esaustivo l’analisi dei requisiti sia relativamente ai processi ed alle modalità con cui tali processi risulteranno visibili agli utenti finali, sia al disegno logico dei dati secondo il modello relazionale, sia per quanto riguarda gli aspetti non funzionali (architettura, sicurezza, accessibilità, vincoli, prestazioni, ecc.), sia alla documentazione delle interfacce (includere esempi di layout delle principali schermate utente,ecc.), sia nei casi in cui è previsto l’utilizzo di un prototipo.

Il livello di completezza richiesto deve essere tale da:

▪ consentire la produzione del Piano di test senza necessità di ulteriori approfondimenti;

▪ consentire la stima in Punti Funzione del volume di software da sviluppare e/o da modificare.

2.5 Disegno di dettaglio

Il documento contiene una specifica in cui le funzionalità sono trasformate ed organizzate in moduli elaborativi strutturati.

È compresa nel disegno di dettaglio la documentazione del disegno logico e fisico dei dati, inoltre per i vari moduli, devono essere trattati, ad esempio:

▪ descrizione delle funzioni svolte

▪ tipologia (on-line, batch, etc..)

▪ indicazioni sulla riutilizzabilità del componente

▪ parametri scambiati con altri componenti

▪ parametri di attivazione

▪ accessi agli archivi/base dati

▪ controlli e diagnostica

▪ algoritmi di calcolo per ciascuna entità.

Per quanto riguarda il disegno logico dei dati, la tecnica di rappresentazione può variare in funzione del DBMS utilizzato.

In ogni caso dovranno essere prodotte le matrici d’uso (o matrici CRUD) degli archivi da parte dei moduli software (concettualmente simili alle matrici Funzioni/Entità prodotte nei precedenti documenti).

Nei casi critici, per dimensioni delle basi dati e/o frequenza di utilizzo, deve essere indicata la frequenza prevista per il tipo d’uso che il modulo fa degli archivi/basi dati, le frequenze totali per tipo d’uso relative a ciascun archivio/tabella della base dati, le frequenze totali per tipo d’uso per ciascun componente.

Per quanto riguarda il caricamento iniziale dei dati, dovranno essere indicati:

▪ gli archivi fisici/basi dati da dove prendere i dati e il loro tracciato

▪ i tracciati dei dati da caricare manualmente

▪ le relazioni tra archivi fisici/basi dati e schemi logici

▪ i volumi trattati, con dettaglio sulla occupazione di memoria e spazio disco

▪ le modalità di inizializzazione degli archivi/basi dati.

2.6 Campione tecnico

Il campione tecnico è la realizzazione di una funzionalità completa del sistema, adottando gli strumenti e l’architettura previsti per l’intero sistema. Tale campione tecnico ha come scopo la verifica della fattibilità tecnica ed in particolare:

▪ quella delle scelte previste

▪ l’effettuazione di test sistemistici

▪ la definizione di particolari modalità realizzative da adottare.

È un documento di progetto che dovrà essere sviluppato laddove tecnicamente opportuno.

2.7 Prototipo

La prototipazione assume aspetti diversi in funzione delle caratteristiche dei singoli interventi.

Sviluppi eseguiti con linguaggi procedurali

In tale caso il prototipo è un elemento rivolto solamente alla esplicitazione dell’interfaccia utente, in termini di layout e di modalità di utilizzo

dell’applicazione. In tal caso la documentazione delle interfacce riporterà la sola stampa delle videate del prototipo.

Tale prototipazione deve comprendere almeno:

▪ i layout delle interfacce di colloquio

▪ il percorso di navigazione

Lo strumento di realizzazione del prototipo può differire dagli strumenti che verranno utilizzati per la realizzazione del sistema.

Sviluppi eseguiti in modalità object- oriented

Nel caso di obiettivi sviluppati in modalità object oriented il prototipo assume una importanza rilevante. Il fine principale è consolidare i requisiti e garantire la completa usabilità del sistema.

La prototipazione deve poter consentire :

▪ l’eliminazione di eventuali dubbi di fattibilità del progetto;

▪ una migliore comprensione dei requisiti;

▪ un eventuale test di sistema, nella sua complessità.

Il prototipo si evolve e si arricchisce durante tutto il ciclo di sviluppo del progetto, fino a diventare la realizzazione del sistema; dovrà essere realizzato adottando gli strumenti e l’architettura previsti per il sistema.

È un documento di applicazione o di area, a seconda dell’indicazione del capo progetto dell’Ente.

2.8 Piano di Test

Il Piano di Test è il documento che accompagna ogni Progetto lungo tutto il ciclo di vita, ed è pertanto un documento che si evolve nel tempo.

Ha lo scopo di definire test specifici, tramite i quali, saranno sottoposti a verifica i prodotti della realizzazione, con particolare riguardo alla loro validazione rispetto ai requisiti dell’utente, nonché documentare il loro esito.

Nel Piano di Test devono essere necessariamente compresi i test relativi alla verifica della corretta predisposizione dell’ambiente di collaudo.

2.9 Documentazione utente

La documentazione utente, rivolta all’utente finale delle applicazioni, è composta dal Manuale utente e dall’help on line (rilasciato con il codice sorgente).

È una documentazione di applicazione.

Manuale utente

Il manuale utente deve fornire una descrizione generale dell’applicazione e una guida operativa all’utilizzo delle singole funzionalità utilizzabili.

La descrizione deve contemplare:

▪ la tipologia di utenza cui è destinata e le funzioni abilitate per ciascuna tipologia;

▪ gli eventuali flussi di dati scambiati con altri sistemi informativi o con specifiche tipologie di utenze;

▪ le modalità di attivazione e chiusura della “sessione di lavoro”;

▪ descrizione delle funzioni e della navigazione tra di esse;

▪ la spiegazione dettagliata dell’uso delle singole funzioni di interfaccia utente (comprensiva della funzione di richiamo dell’help);

▪ la descrizione degli algoritmi di calcolo utilizzati;

▪ la descrizione dei contenuti degli output della applicazione (es. stampe).

▪ La descrizione delle funzionalità disponibili deve essere completa dell’elenco di tutti i codici d’errore previsti, della messaggistica ad essi associata e delle azioni da intraprendere a fronte di ciascuna segnalazione.

▪ Nel caso in cui l’applicazione preveda un utilizzo diretto dei dati da parte dell’utente, deve essere inserita anche la descrizione dettagliata della struttura dei dati interessati.

Help on line

▪ Tutte le applicazioni interattive devono prevedere le funzioni di help on line.

2.10 Manuale di gestione applicativo

Il Manuale di gestione applicativo è lo strumento necessario alle strutture preposte all’installazione ed esercizio dell’applicazione.

È un documento di applicazione.

È un manuale rivolto a personale tecnico. Tale manuale dovrà essere corredato di uno schema riepilogativo contenente informazioni anagrafiche relative all’applicazione, tra le quali i riferimenti a eventuali codici di strumenti di inventario applicativo (esempio INFAP per il MEF), la dimensione e tipologia del DB, la dipendenza con altre applicazioni, i modelli di interfaccia, i tool utilizzati per lo sviluppo, ecc.

Per quello che riguarda gli ambienti di collaudo ed esercizio il documento dovrà esplicitare i parametri di personalizzazione dei prodotti, le modalità di attuazione dei livelli di protezione dei dati, le modalità di accesso al sistema e

alle transazioni, le soluzioni tecniche necessarie alla realizzazione di tali modalità.

2.11 Manuale di gestione server

Il Manuale di gestione server, strumento necessario alle strutture preposte all’installazione ed esercizio dell’apparecchiatura e rivolto a personale tecnico, dovrà essere eventualmente integrato con le opportune informazioni relative al software realizzato/modificato.

2.12 Piano di adeguamento degli ambienti

Il Piano di adeguamento degli ambienti è il documento di supporto alle attività di trasferimento ed installazione in ambiente di collaudo, di esercizio e di correttiva.

Viene strutturato in tre sezioni relative rispettivamente all’ambiente di collaudo, all’ambiente di esercizio e all’ambiente di correttiva.

Deve contenere almeno le seguenti informazioni:

▪ il responsabile del change;

▪ descrizione di tutte le attività necessarie alla predisposizione dell’ambiente di collaudo/esercizio/correttiva (con l’evidenza delle date di inizio e di completamento) e dei relativi referenti (sia tecnici che applicativi);

▪ qualificazione del progetto e degli elementi di configurazione coinvolti (DB, utenze, Application Server, directory, ecc...);

▪ specifica delle istruzioni operative evidenziando i riferimenti ai manuali di gestione dell’applicazione e dei server.

2.13 Documentazione dati

La documentazione dati di area contiene la descrizione e la rappresentazione della base dati dell’area, esplicita eventuali collegamenti con la base dati di altre aree o le regole tecniche con cui l’applicazione scambia flussi informativi di dati con altre applicazioni.

È un documento di area.

La documentazione dati di area è obbligatoriamente articolata nelle seguenti componenti:

▪ Modello dei dati;

▪ Dizionario dati.

Modello dei dati

Il modello dei dati è composto da:

▪ Glossario che dovrà contenere:

– descrizione di tutti gli oggetti degli schemi concettuali;

– descrizione di tutti gli oggetti degli schemi logici;

– mapping schema concettuale- logico.

▪ schema concettuale e logico su tool di modellazione dati (ad esempio Xxxxx)

▪ I file dovranno essere forniti in formato ER1.

▪ I modelli dati contenuti nei file dovranno comprendere:

– Diagramma E/R ;

– Nome e Descrizione delle Entità;

– Nome e Descrizione degli Attributi;

– Mapping Entità/Tabella e Attributo/Xxxxxxx.

▪ mapping concettuale-logico: su tool di modellazione dati Xxxxx o su documento;

▪ schema fisico: su tool di modellazioni dati Xxxxx;

▪ dizionario dati: inserito negli opportuni campi dei DBMS.

Lo schema concettuale dovrà contenere le seguenti informazioni:

▪ schema grafico rappresentante le entità e l’associazione tra esse intercorrenti;

▪ nome (e/o codice) e descrizione del significato delle entità;

▪ nome (e/o codice) e descrizione del significato delle associazioni intercorrenti tra le entità;

▪ nome (e/o codice) e descrizione del significato degli attributi appartenenti alle singole entità e associazioni.

Lo schema logico dovrà contenere:

▪ Schema grafico rappresentante le relazioni;

▪ Vincoli di integrità;

▪ Relazioni fondamentali;

▪ Relazioni associative;

▪ Chiavi primarie e secondarie.

Il mapping concettuale-logico dovrà contenere la corrispondenza tra le entità e associazioni descritte nello schema concettuale e le relazioni descritte nello schema logico.

Lo schema fisico dovrà contenere:

▪ indicazione del metodo di accesso utilizzato;

▪ bloccaggio di ciascun data-set;

▪ clausole di storage;

▪ descrizione dei dati interni del DBMS (tabelle, indici, ecc.) che realizzano la struttura prevista.

Dizionario dati

Il dizionario dati dovrà contenere:

▪ Nome della tabella

▪ Nome dell’attributo

▪ Indicazione della chiave primaria

▪ Indicazione di eventuale chiave esterna

▪ Tipo e dimensione dell’attributo (char, number, date ecc.)

▪ Descrizione dell’attributo

▪ Dominio

▪ nel caso di campi calcolati l’algoritmo che valorizza il campo

▪ riferimenti a controlli applicativi (anche a mezzo di trigger) che insistono sul campo

▪ descrizione dei codici di errore di tutti i controlli.

2.14 Modulo per stima/conteggio FP

Tale documentazione è costituita da moduli in cui devono essere riportate le informazioni per il conteggio delle dimensioni in Punti Funzione dell’intervento.

2.15 Report di inventario funzionale

Con tale report si fornisce evidenza, a fronte di un progetto di sviluppo e/o manutenzione, dell’aggiornamento della baseline dell’Inventario applicativo.

2.16 Report sulla qualità del software

È il report prodotto con strumenti specifici per evidenziare il rispetto degli indicatori sulla qualità del software. Tale report si deve presentare ogni qualvolta il progetto ha i requisiti previsti per il calcolo degli indicatori di qualità, così come previsti dall’Appendice “Indicatori di qualità”.

2.17 Lista oggetti software

Se il software viene rilasciato in un ambiente di configuration utilizzato e messo a disposizione dall’Ente, la lista degli oggetti software sarà composta dall’elenco dei moduli sorgenti consegnati nei branch, presenti nel sistema di configuration, per cui la consegna di tale lista può non essere necessaria.

Negli altri casi il documento di Lista Oggetti Software (LOS) deve contenere un elenco di tutti gli oggetti software realizzati, modificati o resi obsoleti nell’ambito delle attività riguardanti il progetto.

La LOS deve essere completa di tutte le informazioni necessarie per la gestione della configurazione.

Devono essere raggruppati separatamente gli oggetti relativi a sw di supporto e/o di test quali script di deploy, script di test, procedure relative alla predisposizione dell’ambiente di collaudo e/o di esercizio ecc.

2.18 Documentazione delle procedure batch

La documentazione delle procedure off line (batch, job, stored procedure, script ecc.) è destinata ai gruppi di gestione applicativa quale supporto alle loro attività ordinarie.

Si articola nei componenti di seguito riportati.

Elenco delle procedure

L’elenco delle procedure fornisce una descrizione generale delle procedure e una guida operativa per la loro schedulazione, ordinaria e straordinaria. La descrizione deve contemplare:

▪ codice identificativo della procedura,

▪ descrizione sintetica,

▪ puntamento al manuale utente,

▪ evento per l’attivazione della schedulazione (ad es. calendario, richiesta utente ecc.),

▪ ambiente,

▪ vincoli procedurali,

▪ periodicità,

▪ note eventuali,

▪ puntamento al documento di procedura.

Documento di procedura

Il documento di procedura deve fornire la descrizione operativa di ogni procedura, in particolare deve riportare:

▪ elenco di tutti i componenti che la costituiscono (job, Stored procedure, DTS ecc),

▪ diagramma di flusso dei componenti (flow chart),

▪ matrice componenti/base dati,

▪ per ogni componente, eventuali parametri da fornire in input per l’esecuzione, l’elenco di tutti gli output e del loro significato (file, stampe ecc), l’elenco dei codici di errore, vincoli fisici di schedulazione e le istruzioni operative in caso di malfunzionamento (es. job di recovery, possibilità di eliminazione, ecc.).

2.19 Rapporto Indicatori di qualità

È il documento che riporta le informazioni relative agli indicatori di qualità raggiunti con il progetto.

Il documento deve prevedere dei dati analitici e dei dati di sintesi.

▪ Per la parte analitica, per ciascun indicatore, deve contenere almeno :

– La scheda dell’indicatore così come prevista nell’appendice “Livelli di servizio”;

– il periodo di riferimento della misura;

– riferimento agli strumenti di misura utilizzati;

– i dati rilevati;

– il valore rilevato dell’indicatore di qualità;

– eventuale scostamento dal valore di soglia;

– eventuale razionale di scostamento dai valori di soglia.

– nel caso degli indicatori relativi alla qualità del codice rilevabili con tool è necessario allegare al documento Rapporto indicatori di sicurezza e qualità anche i Report prodotti con il tool utilizzato per la verifica del software. Tali report costituiranno parte integrante del documento.

▪ La parte sintetica deve popolarsi in automatico a partire dalla parte analitica, evidenziare le metriche che hanno superato il valore soglia e contenere almeno le informazioni riportate di seguito:

– Codice e descrizione della metrica

– Esito della metrica

– L’indicazione se è previsto un indice di prestazione

– Aspetto da valutare

– Unità di misura

– Periodo di riferimento

– Dati da rilevare

– Regole di campionamento

– Formula

– Fonte dei dati

– Frequenza di misurazione

– Azioni contrattuali

– Eccezioni.

2.20 Convalida sulla tecnologia

Il documento attesta la conformità di quanto realizzato e/o modificato alle indicazioni del produttore della tecnologia/prodotto stesso. Esso dovrà essere prodotto per gli obiettivi che fanno uso di specifiche ed individuate tecnologie/prodotti (come riportati nel Piano della qualità).

Tale documento dovrà esplicitare:

▪ il nome e la release dei prodotti utilizzati;

▪ i puntuali riferimenti (manualistica, best practices, indicazioni specifiche, ecc.) su cui è stata basata la realizzazione;

▪ la dichiarazione del fornitore di utilizzare i prodotti secondo le specifiche valide per le versioni indicate.

▪ L’eventuale sottoscrizione da parte del produttore della tecnologia/prodotto dovrà essere presente sullo stesso documento.

Document Metadata

Table of Contents

Contract

Document Metadata