APPENDICE 3 ALLE CONDIZIONI DI FORNITURA CICLI E PRODOTTI

Come indicato nelle Condizioni di Fornitura, le attività realizzative (servizi di sviluppo e manutenzione di software ad hoc, sviluppo, parametrizzazione e personalizzazione di soluzioni e/o piattaforme e manutenzione adeguativa) sono svolte prevalentemente presso le sedi del Fornitore (salvo diversa richiesta di Inail) e sono di completa responsabilità del Fornitore stesso. Pertanto, l’Impresa adotterà le migliori soluzioni – in termini di organizzazione, strumenti, metodologie, risorse, tecniche di controllo e validazione, ecc. - al fine di consegnare i prodotti richiesti completamente rispondenti alle esigenze espresse dall’Inail e alle caratteristiche di qualità del software e della documentazione a corredo.

2 I CICLI DI SVILUPPO DEL SOFTWARE

Nel seguito vengono descritti i modelli di sviluppo (per convenzione definiti “Cicli” nel prosieguo del documento) da utilizzare nell’ambito della fornitura.

In accordo con le prescrizioni contenute all’interno delle Condizioni di Fornitura, i modelli descritti sono validi sia per le attività di Sviluppo e MEV di software ad hoc, sia per le attività di Sviluppo, parametrizzazione e personalizzazione di soluzioni e/o piattaforme, sia per le attività di Manutenzione Adeguativa (MAD).

Le tabelle che descrivono i cicli contengono le seguenti colonne:

• Fase: contiene le fasi in cui è scomposto il ciclo di sviluppo;

• Prodotto di fase: contiene i prodotti di output della singola fase, la cui descrizione è riportata nel capitolo dedicato al contenuto dei prodotti;

• Criterio di uscita: contiene gli atti, formali o sostanziali, che determinano la fine della fase. Si precisa quanto segue:

• La scelta del ciclo di sviluppo da adottare è demandata ad Inail all’atto dell’attivazione dell’intervento sulla base delle indicazioni fornite nelle Condizioni di Fornitura;

• Ciascun ciclo di sviluppo adottato comprenderà stima, pianificazione, qualità, review, risk management e consuntivazione e tutti i requisiti generali e specifici richiesti dalle Condizioni di Fornitura;

• I criteri di uscita di “Validazione” delle singole fasi includono anche l’approvazione/validazione dei prodotti di fase da parte dell’Inail, pertanto nel Piano di lavoro dell’Intervento deve essere data tale evidenza;

• Per il criterio di uscita “Consegna”, qualora ci siano specifiche esigenze dell’Amministrazione, si può procedere alla fase successiva anche attraverso l’approvazione di alcuni dei prodotti previsti, fermo restando l’obbligo del Fornitore di completare la consegna dei restanti prodotti successivamente;

• Per il criterio di uscita “Esito positivo collaudo” e “verifica della documentazione” non si potrà procedere alla fase successiva prima dell’approvazione di INAIL;

• Alcuni prodotti di fase sono opzionali, in ragione della specificità dell’intervento, e comunque da prodursi su indicazione dell’Inail. Tali prodotti sono evidenziati con “(EV)”; tutti gli altri sono da considerarsi requisito minimo.

• Per alcuni cicli di sviluppo, adottati per accelerare i tempi di realizzazione, taluni prodotti di fase potranno essere consegnati sotto forma di note operative oppure in forma ridotta rispetto agli standard previsti: tali prodotti sono evidenziati con “(FR)”. In tali casi, i suddetti prodotti dovranno essere consegnati nella versione completa al termine della fase di documentazione.

2.1 Ciclo di sviluppo completo

La tabella riporta per ciascuna fase i prodotti richiesti ed il criterio di uscita.

Fase	Prodotto di fase – Ciclo Completo	Criterio di uscita
Definizione	Documento di Vision	Validazione Definizione
	Casi d’uso
	Piano di Lavoro dell’Intervento
	Piano della qualità dell’Intervento1 (EV)
	Specifica dei Requisiti
	Modulo per conteggio PF (stima iniziale)
	Rapporto indicatori di qualità dell’Intervento
	Prototipo (EV)
Analisi	Piano di Lavoro dell’Intervento	Validazione Analisi
	Specifiche
	Piano di test
	Prototipo (EV)
	Campione Tecnico (EV)
	Convalida sulla tecnologia (EV)
	Modulo per conteggio PF (conteggio di revisione - Analisi)
	Rapporto indicatori di qualità dell’Intervento
	Altri documenti (EV)
Disegno	Piano di Lavoro dell’Intervento	Validazione Disegno (verifica di conformità)
	Disegno di dettaglio
	Piano di test
	Documentazione dati
	Modulo per conteggio PF (conteggio di revisione - Disegno)
	Rapporto indicatori di qualità dell’Intervento
	Piano di collaudo
	Prototipo (EV)
	Campione Tecnico (EV)
	Altri documenti (EV)
Realizzazione	Piano di Lavoro dell’Intervento	Consegna software e documentazione
	Codice sorgente
	Rapporto di esecuzione dei test
	Documentazione utente
	Manuale di gestione applicativo
	Modulo per conteggio PF (conteggio consuntivo – misura dell’intervento)
	Lista Oggetti Software (EV)
	Rapporto indicatori di qualità dell’Intervento
	Demo sulle novità del sistema (EV)
	Certificazione di rilascio al collaudo funzionale e di integrazione
	Altri documenti2 (EV)

1 Quando l’Intervento ha caratteristiche specifiche o va in deroga al Piano della Qualità generale.

Fase	Prodotto di fase – Ciclo Completo	Criterio di uscita
Collaudo Funzionale	Verbale di collaudo	Esito positivo collaudo funzionale e di verifica della documentazione (Verifica di conformità)
	Pacchetto di deploy (software e documentazione)
Documentazione	Documentazione applicativa	Approvazione
	Piano della Sicurezza
	Rapporto indicatori di qualità dell’intervento
Collaudo Non Funzionale	Verbale di collaudo	Esito positivo collaudo non funzionale (Verifica di conformità)
	Rapporto indicatori di qualità dell’intervento
Avvio in esercizio	Rapporto indicatori di qualità dell’Intervento	Messa in esercizio del software, apertura dell’applicazione agli utenti e rapporto del periodo di osservazione (Verifica di Conformità)

2 Può includere la predisposizione di documenti di sintesi di Area.

2.2 Ciclo di sviluppo ridotto

È applicabile per obiettivi di dimensioni limitate, sia in termini di effort progettuale che in termini temporali.

In questo processo le attività relative ad analisi e disegno sono raggruppate in un’unica fase e il documento “Specifiche dell’intervento” conterrà sia gli aspetti funzionali e non funzionali sia gli aspetti tecnici. I documenti di analisi e di disegno a livello applicazione dovranno essere consegnati completi e corretti entro la fase di avvio in esercizio. L’assenza anche di un solo documento – sia a livello di intervento, sia applicazione, sia sistema – non permetterà la chiusura della fase e comporterà una verifica di conformità negativa.

Fase	Prodotto di fase – Ciclo Ridotto	Criterio di uscita
Definizione	Documento di Vision	Validazione Definizione
	Casi d’uso
	Piano di Lavoro dell’Intervento
	Piano della qualità dell’Intervento (EV)
	Specifica dei Requisiti
	Modulo per conteggio PF (stima iniziale)
	Rapporto indicatori di qualità dell’Intervento
	Prototipo (EV)
Analisi e Disegno	Piano di Lavoro dell’Intervento	Validazione Analisi e Disegno (Verifica di conformità)
	Specifiche dell’intervento
	Piano di test
	Piano di collaudo
	Convalida sulla tecnologia (EV)
	Documentazione dati
	Prototipo (EV)
	Campione Tecnico (EV)
	Modulo per conteggio PF (stima di revisione)
	Rapporto indicatori di qualità dell’Intervento
	Altri documenti (EV)
Realizzazione	Piano di Lavoro dell’Intervento	Consegna software e documentazione
	Codice sorgente
	Rapporto di esecuzione dei test
	Documentazione utente
	Manuale di gestione applicativo
	Modulo per conteggio PF (conteggio a consuntivo – misura dell’intervento)
	Lista Oggetti Software (EV)
	Rapporto indicatori di qualità dell’Intervento
	Demo sulle novità del sistema (EV)
	Certificazione di rilascio al collaudo funzionale e di integrazione
	Altri documenti (EV)
Collaudo Funzionale	Verbale di collaudo	Esito positivo collaudo funzionale e di verifica della documentazione (Verifica di conformità)
Collaudo Funzionale	Pacchetto di deploy (software e documentazione)
Documentazione	Documentazione applicativa	Approvazione

Fase	Prodotto di fase – Ciclo Ridotto	Criterio di uscita
	Piano della Sicurezza
	Rapporto indicatori di qualità dell’intervento
Collaudo Non Funzionale	Verbale di collaudo	Esito positivo collaudo non funzionale (Verifica di Conformità)
Collaudo Non Funzionale	Rapporto indicatori di qualità dell’Intervento
Avvio in esercizio	Rapporto indicatori di qualità dell’Intervento	Messa in esercizio del software, apertura dell’applicazione agli utenti e rapporto del periodo di osservazione (Verifica di Conformità)

2.3 Ciclo di sviluppo breve

È costituito da un numero ridotto di fasi in cui la documentazione di definizione, analisi, disegno e realizzazione potranno preliminarmente assumere la caratteristica di un addendum, di note operative o di verbali, mentre la documentazione di area e di applicazione dovrà essere prodotta solo dopo il collaudo dell’Amministrazione, nella relativa fase di documentazione.

Le caratteristiche di questo ciclo di sviluppo si possono così riassumere:

- è presente una fase di definizione molto accurata attraverso la realizzazione di prototipo e mockup che verrà successivamente perfezionato; la stima iniziale non sarà, dunque, rivista nella fase “analisi-disegno-realizzazione”;

- è presente un’unica fase che raggruppa “analisi”, “disegno” e “realizzazione” in cui i singoli prodotti di fase previsti per le corrispondenti fasi del ciclo completo vengono sostituiti da documenti incrementali condivisi con l’Amministrazione sotto forma di verbale;

- è prevista una fase di documentazione che strutturerà nei formati standard i contenuti di analisi e disegno individuati nelle fasi precedenti e rilascerà tutti i documenti a livello di applicazione e di sistema.

Fase	Prodotto di fase – Ciclo Breve	Criterio di uscita
Definizione	Documento di Vision	Validazione Definizione
	Piano di Lavoro dell’Intervento
	Piano della qualità dell’Intervento (EV)
	Verbale dei requisiti
	Rapporto indicatori di qualità dell’Intervento
	Modulo per conteggio PF (stima iniziale)
Analisi Disegno e Realizzazione	Piano di Lavoro dell’Intervento	Validazione Analisi e Disegno (Verifica di conformità) Consegna software e documentazione
	Verbale di Analisi e Disegno3
	Rapporto di esecuzione dei test4 (FR)
	Piano di collaudo
	Convalida sulla tecnologia (EV)
	Documentazione dati
	Codice sorgente
	Manuale di gestione applicativo5 (FR)
	Modulo per conteggio PF (conteggio consuntivo – misura dell’intervento)
	Lista Oggetti Software (EV)
	Rapporto indicatori di qualità dell’Intervento
	Demo sulle novità del sistema6 (FR)
	Certificazione di rilascio al collaudo funzionale e di

3 Dal documento dei requisiti seguirà un approfondimento delle specifiche funzionali e tecniche (disegno) attraverso e-mail, videoconferenze, specializzazione del prototipo, ecc.. sempre sottoposte all’approvazione dell’Amministrazione. Periodicamente o per contenuti omogenei verranno redatti verbali di consolidamento delle specifiche, a tutti gli effetti questi verbali rappresenteranno il riferimento per la realizzazione del sw.

4 Sarà in formato ridotto, prevedendo i test correlati ai requisiti espressi. I contenuti saranno comunque concordati con il responsabile di progetto dell’Amministrazione.

5 Inizialmente anche sotto forma di note operative

6 Può essere sostituita da una descrizione sintetica delle novità del sistema

Fase	Prodotto di fase – Ciclo Breve	Criterio di uscita
	integrazione
	Altri documenti (EV)
Collaudo Funzionale	Verbale di collaudo	Esito positivo collaudo funzionale e di verifica della documentazione (Verifica di conformità)
Collaudo Funzionale	Pacchetto di deploy (software e documentazione)
Collaudo Non Funzionale	Verbale di collaudo	Esito positivo collaudo non funzionale (Verifica di Conformità)
Collaudo Non Funzionale	Rapporto indicatori di qualità dell’Intervento
Documentazione	Piano di Lavoro dell’Intervento	Esito positivo della verifica della documentazione
	Rapporto indicatori di qualità di Intervento
	Specifica dei Requisiti
	Specifiche
	Documentazione utente
	Piano della Sicurezza
	Disegno di dettaglio
	Manuale di gestione applicativo7
Avvio in esercizio	Rapporto indicatori di qualità dell’Intervento	Messa in esercizio del software, apertura dell’applicazione agli utenti e rapporto del periodo di osservazione (Verifica di Conformità)

7 Qualora nelle precedenti fasi fosse stata consegnata una nota operativa.

2.4 Ciclo di sviluppo a fase unica

Nel caso di ciclo a fase unica, le attività che vanno dalla Definizione al Collaudo vengono conglobate in un’unica fase di responsabilità del Fornitore, che si conclude con l’accettazione del software sviluppato e/o della documentazione presentata, effettuata da parte del responsabile dell’Amministrazione.

La formalizzazione dei requisiti può avvenire in forma di verbale.

L’intervento potrà considerarsi chiuso solo dopo la consegna della documentazione aggiornata dell’intera applicazione a cui si riferisce l’intervento.

Tale documentazione potrà essere prodotta dopo la consegna del software salvaguardando comunque gli aspetti relativi alla messa in esercizio, le cui indicazioni potranno preliminarmente assumere la caratteristica di un addendum o di note operative.

L’allineamento o la predisposizione della documentazione di applicazione e/o di area applicativa ed il Rapporto Indicatori di Qualità dell’Intervento saranno previsti esplicitamente nel Piano di Lavoro dell’Intervento; la consegna della documentazione dovrà avvenire al massimo entro un mese solare dalla consegna del software, nel corso della fase di Documentazione.

Anche per il ciclo a fase unica, nel caso di sviluppo software, è prevista la fase di Avvio in esercizio, nel corso della quale viene monitorato il software sviluppato.

Proprio per la natura di questi interventi, non è possibile ipotizzare una loro pianificazione nell’arco della fornitura, e quindi è richiesto al Fornitore un adeguato grado di flessibilità nella propria organizzazione al fine di garantire la realizzazione con tempi di intervento estremamente brevi.

2.5 Ciclo di sviluppo iterativo

Il processo di sviluppo iterativo è caratterizzato da fasi di specifica/sviluppo/test ciclici e da rilasci incrementali. Può essere impiegato dal Fornitore nei casi in cui:

• l’amministrazione abbia esigenze temporali stringenti, per cui almeno parte delle funzionalità necessarie deve essere rilasciata con urgenza;

• l’utenza non abbia espresso compiutamente i requisiti, oppure essi non sono stabili e devono essere verificati con il coinvolgimento attivo dell’utenza nel processo stesso;

• l’Istituto intenda adottare metodologie Agile (quali ad esempio la Scrum).

Nei casi evidenziati, com’è ovvio, le possibilità di riuso sono minime: data l’urgenza e/o l’assenza di requisiti stabili, la verifica di esistenza di moduli o programmi già realizzati non è percorribile.

Nel processo iterativo le funzionalità richieste vengono rilasciate per gruppi – non necessariamente omogenei - nelle varie iterazioni, fino al completamento dei lavori. In ogni iterazione si aggiungono nuove funzionalità e/o si modificano le funzionalità rilasciate in precedenza, se l’utenza ha affinato, attraverso l’uso sperimentale delle stesse, i propri requisiti. Anche la documentazione viene scritta in modo incrementale, aggiungendo paragrafi sulle varie funzionalità man mano che esse vengono rilasciate. Andando avanti nelle varie iterazioni, il rischio connesso all’incertezza dei requisiti diminuisce, e il valore del software rilasciato aumenta.

In caso di adozione, quale sottospecifica del ciclo iterativo, di una metodologia Agile, dovranno essere prodotti i Deliverable previsti dalla metodologia adottata, sulla base di quanto definito nel Piano di qualità dell’intervento.

Fasi e prodotti del processo iterativo sono rappresentati nella tabella che segue.

Fase		Prodotto di fase di default, ove non specificati prodotti differenti in base alla metodologia adottata	Criterio di uscita
Definizione		Documento di Vision	Validazione Definizione
		Casi d’uso
		Piano di Lavoro dell’Intervento8
		Piano di qualità dell'Intervento9
		Modulo per conteggio PF (stima iniziale)
		Rapporto indicatori di qualità dell’Intervento
		Specifica dei requisiti utente (iniziali)
Iterazioni	Analisi	Specifica dei requisiti utente (affinamento)	Validazione Analisi
		Piano di Lavoro dell’Intervento (affinamento)
		Specifiche10
		Piano di test11

8 Il Piano di Lavoro dell’Intervento identifica le priorità nell’implementazione che determineranno l’oggetto delle singole iterazioni.

9 Quando l’Intervento ha caratteristiche specifiche o va in deroga a regole inserite nel Piano della Qualità generale. 10 Si intende la Specific a delle funzionalità da realizzare e/o modificare nella singola iterazione

11 Si intende il Piano di Test della singola iterazione

Fase		Prodotto di fase di default, ove non specificati prodotti differenti in base alla metodologia adottata	Criterio di uscita
		Modulo per conteggio PF12
	Realizzazione	Disegno di dettaglio (EV)	Consegna software e documentazione
		Modello dei dati (EV)13
		Codice sorgente
		Piano di collaudo
		Documentazione utente
		Piano della Sicurezza
		Manuale di Gestione applicativo
		Rapporto di esecuzione dei test
		Modulo per conteggio PF (conteggio consuntivo – misura dell’intervento)
		Demo sulle novità del sistema (EV)
		Rapporto indicatori di qualità dell’Intervento
	Validazione	Codice sorgente validato	Validazione
		Certificazione di rilascio al collaudo funzionale e di integrazione (EV)
		Feedback dell’utenza14
Collaudo Funzionale		Verbale di collaudo	Esito positivo collaudo funzionale e di verifica della documentazione
		Pacchetto di deploy (software e documentazione)
Collaudo Non Funzionale		Verbale di collaudo	Esito positivo collaudo non funzionale (Verifica di Conformità)
		Rapporto indicatori di qualità dell’Intervento
Avvio in esercizio 15		Rapporto indicatori di qualità di Intervento	Messa in esercizio del software, apertura dell’applicazione agli utenti e rapporto del periodo di osservazione (Verifica di Conformità)
		Documentazione di Intervento, di applicazione, di sistema

Nel processo iterativo, la remunerazione del fornitore è calcolata sommando i PF rilasciati nella prima iterazione (conteggiati come sviluppo) ai PF delle iterazioni successive (conteggiati come MEV: ADD nuove funzionalità, CHG funzionalità modificate, DEL funzionalità rimosse).

12 Per la prima iterazione si tratta di un conteggio di sviluppo, per le successive di MEV

13 Alcuni rilasci di documenti sono eventuali, giacché la singola iterazione deve essere mantenuta circoscritta (anche temporalmente) e focalizzata sull’incremento che le compete, altrimenti l’onere diventa eccessivo.

14 Il feedback deve essere rilevato per tutte le iterazioni tranne l’ultima.

15 L’avvio della fase è vincolato all’accettazione del collaudo

2.6 Ciclo di sviluppo ad hoc

Per attività progettuali legate a sperimentazioni o a produzione di prototipi o in caso di Servizi di supporto specialistico le cui caratteristiche non consentano l’applicazione dei cicli sopra descritti, sarà possibile definire cicli di sviluppo “ad hoc”, da formalizzare nel Piano di qualità dell’intervento, che aderiscano il più possibile alle peculiarità delle attività progettuali stesse e dei prodotti da realizzare.

Sarà possibile definire fasi specifiche, prevedere iterazioni di fasi o di interi cicli, individuare prodotti specifici di ciascuna fase, che possono consistere anche in versionamenti successivi e incrementali di uno stesso oggetto/documento.

Deve essere comunque sempre prevista una fase iniziale di definizione nella quale il Fornitore dovrà produrre i documenti necessari a descrivere compiutamente contesto e caratteristiche peculiari dell’intervento nonché fornire una stima iniziale dell’intervento. Tra i documenti da produrre è obbligatorio prevedere il Piano di Qualità dell’Intervento.

3 LE FASI PROGETTUALI

3.1 Definizione

La fase di Definizione è volta ad identificare e dettagliare le necessità dell’utente, ed è caratterizzata dai seguenti obiettivi:

• Descrivere le finalità dell’intervento e le esigenze dell’utente, anche in rapporto al sistema esistente e ad eventuali suoi vincoli, carenze o criticità;

• 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

• Definire la soluzione tecnologica;

• Indicare il ciclo di sviluppo da adottare, tutti i prodotti attesi e se necessario prevedere un piano della qualità dell’Intervento;

• Proporre la pianificazione delle attività, in termini di stima di tempi, risorse e effort realizzativo (secondo la metrica adottata) e gestione del rischio;

• Realizzare i prodotti di fase.

In questa fase, laddove necessario/richiesto dall’Inail, dovranno essere definiti i processi ciclici da attivarsi specificando chiaramente le attività di verifica e di collaudo.

Nella fase di definizione dovranno essere individuati:

- le eventuali componenti da realizzare in ottica di riuso in altri progetti / in altre aree applicative

- le eventuali componenti da riutilizzare da altri progetti / aree applicative

- le funzionalità che dovranno essere realizzate sotto forma di API.

L’attività di raccolta requisiti, nei casi in cui fosse richiesta interazione con gli utenti finali, verrà svolta congiuntamente con il personale dell’Inail ed il Fornitore ne dovrà curare la verbalizzazione.

La fine della fase di Definizione è rappresentata dall’attivazione che prevede anche l’approvazione di tutti i documenti di fase: con l’attivazione l’Inail autorizza a proseguire nelle attività, secondo la stima e la pianificazione proposte.

Il Fornitore è tenuto a condividere con l’Inail i contenuti dei documenti e dell’eventuale prototipo, man mano che questi vengono realizzati.

Per il dettaglio dei prodotti di fase si rimanda ai cicli di sviluppo descritti nei paragrafi precedenti. Il documento di Specifica dei Requisiti potrà essere validato anche da parte dell’utente finale.

3.2 Analisi

La fase di Analisi è volta a definire, in modo completo ed esaustivo, l’applicazione e/o le funzioni da realizzare e/o modificare, con riferimento ai processi individuati e alle modalità con cui tali processi risulteranno visibili all’utente.

La responsabilità della fase è del Fornitore.

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;

• 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 e definire una matrice di tracciabilità requisito-test;

• Individuare i rischi di progetto e definire le azioni correttive;

• Realizzare i prodotti di fase;

• Aggiornare, in caso di modifiche intercorse, i prodotti delle fasi precedenti. La fase ha in input i documenti prodotti nella fase di definizione.

Anche durante la fase di Analisi il Fornitore dovrà verbalizzare gli incontri con gli utenti.

Qualora tecnicamente e funzionalmente possibile, e laddove richiesto dall’Inail, il documento di Specifiche dovrà essere corredato dalla realizzazione di un prototipo che rappresenti almeno le modalità di navigazione e il layout delle interfacce; tali prodotti saranno oggetto di verifica da parte dell’Istituto.

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

La successiva fase di Disegno potrà comunque iniziare all’avvenuta approvazione anche del solo documento di Specifiche.

Per il dettaglio dei prodotti di fase si rimanda ai cicli di sviluppo descritti nei paragrafi precedenti.

Nel corso della fase di Analisi potrà essere necessario produrre sia il paper prototype sia lo

storyboard del sito web.

La fine della fase è definita dall’approvazione di tutti i documenti di fase, sottolineando che il documento di Specifiche ed il prototipo (se previsto) saranno sottoposti a verifica da parte dell’Inail e anche da parte dell’utente finale.

Qualora durante la fase di Analisi vi sia necessità di rivedere i requisiti descritti nella Specifica dei Requisiti, l’Inail valuterà l’opportunità di condividere tali modifiche anche con l’utente finale; il Fornitore è conseguentemente tenuto all’aggiornamento del relativo documento.

3.3 Disegno

La fase di Disegno è volta a tradurre tutte le caratteristiche della soluzione in specifiche tecniche di dettaglio necessarie alla generazione dei prodotti finali.

La responsabilità della fase è del Fornitore. 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 fase ha in input i documenti prodotti nelle fasi precedenti.

Per taluni Obiettivi può essere prevista, nel periodo iniziale della fase, la realizzazione di un prototipo più evoluto che permetta di svolgere verifiche tecniche.

La fine della fase è definita dalla consegna dei documenti sottolineando che l’avvenuta consegna non esclude la possibilità di dover apportare modifiche, in tempi successivi alla fine della fase, a fronte delle verifiche effettuate dall’Inail. Laddove richiesto dall’Istituto, la consegna può essere sostituita dall’approvazione dei prodotti della fase in ragione della dimensione, criticità e tipologia dell’intervento considerato.

Per il dettaglio dei prodotti di fase si rimanda ai cicli di sviluppo descritti nei paragrafi precedenti.

3.4 Analisi e Disegno

La fase qui descritta è applicata unicamente al ciclo di sviluppo ridotto e sostituisce le fasi di Analisi e di Disegno precedentemente descritte.

La responsabilità della fase è del Fornitore.

La fase di Analisi e Disegno è volta a definire in modo completo ed esaustivo l’applicazione da realizzare, sia per quanto riguarda gli aspetti funzionali sia per gli aspetti tecnici, sostanzialmente rispettando gli obiettivi ed i contenuti già descritti per le fasi di Analisi e di Disegno. Inoltre, la documentazione di applicazione e/o area applicativa dovrà comunque essere riallineata ed aggiornata dandone esplicita evidenza nel Piano di lavoro.

La fase ha in input i documenti prodotti nella fase di Definizione.

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

La successiva fase di realizzazione potrà comunque iniziare all’avvenuta approvazione anche del solo documento di specifiche dell’intervento.

Per il dettaglio dei prodotti di fase si rimanda ai cicli di sviluppo descritti nei paragrafi precedenti.

3.5 Realizzazione

La fase di Realizzazione è volta a generare i componenti software e le basi dati necessarie alla efficace ed efficiente operatività del sistema oggetto di sviluppo.

La responsabilità della fase è del Fornitore.

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;

• Predisporre l’ambiente di collaudo, effettuando le opportune attività di test per verificarne la correttezza,

• Aggiornare, in caso di modifiche intercorse, i prodotti delle fasi precedenti.

• Misurare gli Indicatori di Qualità dell’Intervento.

La fase ha in input i documenti prodotti nelle fasi precedenti.

La fine della fase è definita dalla consegna dei prodotti di fase e dalla relativa approvazione da parte dell’Inail. Si precisa inoltre che l’Inail potrà richiedere oltre ai documenti previsti anche la documentazione delle verifiche effettuate dal Fornitore.

3.6 Analisi, Disegno e Realizzazione

Questa fase, tipica del ciclo “a fase unica”, è caratterizzata da una continua interazione tra Fornitore, Committente ed Amministrazione al fine di definire in modo completo ed esaustivo i requisiti e l’applicazione da realizzare, sia per quanto riguarda gli aspetti funzionali che tecnici, sostanzialmente rispettando gli obiettivi ed i contenuti già descritti alle fasi di “definizione”, “analisi”, “disegno” e “realizzazione”.

I contenuti dovranno essere condivisi sotto forma di verbali anche incrementali secondo una pianificazione congiunta tra Committente e fornitore.

Al termine di questa fase il fornitore dovrà 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.

3.7 Collaudo Funzionale e non Funzionale

La fase di Collaudo del software realizzato è di responsabilità dell’INAIL, con l’eventuale supporto di terze parti da esso autorizzate, che agirà come unica interfaccia nei confronti del Fornitore.

Saranno oggetto di verifica durante il periodo di collaudo tutti i prodotti della fase realizzativa sopra indicati.

La fase di Collaudo include il supporto, da parte del Fornitore, alla predisposizione dell’ambiente di collaudo, la verifica della corretta predisposizione, il supporto all’INAIL per lo svolgimento del collaudo stesso, la rimozione delle anomalie fino al momento dell’accettazione, il supporto all’installazione negli ambienti delle procedure realizzate ed il supporto alla ri-esecuzione dei test automatizzati.

Per consentire una verifica esaustiva ed efficace dei prodotti realizzati, il Fornitore deve predisporre un Piano di Collaudo progettato in conformità con le procedure e le metodologie standard dell’Istituto, il quale potrà essere derivato dai piani di test e dovrà contenere almeno le seguenti informazioni:

- strategia, metodologia e obiettivi del collaudo;

- pianificazione temporale del collaudo;

- specificazione dei requisiti e dei vincoli dell’ambiente di collaudo;

- caratteristiche dell’hardware e del software di base previste per il collaudo;

- oggetti sottoposti a test.

Il piano di collaudo dovrà prevedere l’esecuzione delle diverse tipologie di test per la verifica di tutti i requisiti e standard presenti nella fornitura, nel rispetto delle indicazioni dell’Istituto e delle metriche di qualità sul processo di test e collaudo:

- collaudo funzionale;

- collaudo di integrazione;

- collaudo non funzionale (ovvero di certificazione).

Il Piano di collaudo, inoltre, dovrà descrivere l’ordine e i relativi criteri di ingresso e di uscita di ogni fase di test nel collaudo, modulati sulle classi di rischio, nonché le modalità di sospensione, di gestione delle non conformità e le caratteristiche degli ambienti utilizzati.

Si sottolinea che tutti i prodotti di fase sono parte integrante della fornitura, la quale non potrà in nessun caso essere collaudata se non saranno stati consegnati/approvati tutti i prodotti previsti nel Piano di Lavoro della fornitura. Questi prodotti comprendono gli output specifici delle varie fasi, quali conteggio Punti Funzione, distinta prodotti di consegna, rilevazione dei requisiti di qualità, accesso ai test negli strumenti di test, ecc.

Il sistema di test e collaudo completo dei test pianificati (documentati e consegnati dal fornitore nei relativi piani di test) sarà predisposto dall’Amministrazione per la prima fase del collaudo funzionale, con il supporto del fornitore secondo gli standard e strumenti dell’Istituto e sulla base dei piani e le specifiche di test precedentemente consegnati ed approvati.

In fase di esecuzione del collaudo il Fornitore dovrà fornire il supporto pieno per l’illustrazione del sistema realizzato e per gli interventi diagnostici e correttivi richiesti, secondo le modalità e i tempi indicati dal piano di collaudo e dai documenti contrattuali.

Per specifici progetti potrà essere richiesta dall’Amministrazione una diversa modalità di erogazione del supporto durante l’esecuzione.

La fase di collaudo potrà, in relazione alla scomposizione del piano di lavoro, essere suddivisa in singole sessioni di collaudo relative ad ogni singolo rilascio previsto. Solo in caso d’indipendenza funzionale dei prodotti ciò potrà comportare l’emissione di verbali parziali di collaudo ed eventuali rapporti di collaudo parziali.

Nel caso di dipendenza funzionale di singole componenti sviluppate, fermo restando la necessità di collaudi parziali, sarà necessaria un’attività di collaudo dell’integrazione dei rilasci stessi. Allo scopo di predisporre tale attività il Fornitore dovrà consegnare la completa documentazione dei vincoli tra le componenti ed il piano d’integrazione delle stesse.

L’accettazione della fornitura sarà comunque dipendente dall’esito positivo di tutte le sessioni di collaudo previste.

I test di integrazione sono svolti anche con l’obiettivo di verificare la corretta integrazione con l’ambiente di esercizio previsto o già esistente, oltre alla conformità con i requisiti di prodotto.

L’esito positivo del collaudo di certificazione consente l’esecuzione delle verifiche e validazioni per la certificazione ed accettazione finale della fornitura, le quali prevedono l’esecuzione di test specifici

per la verifica dei requisiti non funzionali e del rispetto degli standard dell’Istituto (prestazioni, sicurezza, qualità, accessibilità).

Questa fase del collaudo prevede l’esecuzione di test funzionali selezionati per la loro caratteristica di evidenziare gli aspetti prestazionali richiesti e, nel caso di interventi correttivi o di manutenzione, di verificare la non regressione, ossia che le funzioni introdotte non alterino il funzionamento del sistema nel suo complesso.

Le prestazioni attese devono essere conformi ai requisiti di prodotto in relazione al dimensionamento dell’ambiente utilizzato, in termini di accessi concorrenti, carichi di rete e popolamento congruente delle basi dati.

L’oggetto del collaudo è inoltre esteso a tutta la documentazione contrattualmente richiesta (manuale utente, manuali di gestione, ecc.).

Le informazioni sui risultati dei test effettuati prima e dopo il collaudo, rispetto al livello di rischio e copertura dei requisiti e registrati nel sistema di test e collaudo, sono inseriti nel catalogo delle applicazioni utilizzato per la gestione in esercizio.

I collaudi si intenderanno positivi per effetto del superamento di tutte le prove previste, secondo le modalità e i tempi indicati dal piano di collaudo e dai documenti contrattuali, con particolare riferimento alle metriche di qualità inerenti la fase di collaudo.

Dove previsto, si richiede il supporto da parte del Fornitore per la consegna del software verso le strutture dell’Istituto che devono gestire l’esercizio applicativo. Questa attività dovrà essere svolta secondo una pianificazione concordata.

La verifica con esito positivo della fornitura termina con l’emissione di un Verbale di Collaudo positivo, che sancisce la conformità ai requisiti del prodotto software configurato.

Analogamente i collaudi dei singoli interventi di manutenzione successivi al rilascio, dovranno verificare il corretto funzionamento delle singole funzioni in coerenza ai requisiti richiesti e che le funzioni introdotte non alterino il funzionamento del sistema nel suo complesso.

Gli standard documentali dei prodotti di fase saranno concordati con l’Istituto e recepiti nel Piano di Qualità della fornitura.

La fase di certificazione finale per la messa in produzione della fornitura e l’accettazione finale, sarà eseguita in ambienti messi a disposizione dall’INAIL.

3.8 Documentazione

I cicli di sviluppo “breve” e “a fase unica” sono generalmente adottati per accelerare i tempi di realizzazione, attribuendo una priorità maggiore alle attività realizzative rispetto agli aspetti documentali.

Questo implica che alcuni prodotti di fase, in accordo con l’Amministrazione, potranno essere consegnati sotto forma di note operative oppure in forma ridotta rispetto agli standard previsti e condivisi.

Al termine positivo della fase di Collaudo, i suddetti prodotti dovranno essere consegnati nella versione completa e saranno oggetto di valutazione da parte dell’Amministrazione.

3.9 Avvio in esercizio

La fase parte dal rilascio in esercizio e prosegue fino al termine del periodo di osservazione, stabilito nel piano della qualità dell’Intervento.

Scopo della fase di avvio in esercizio è quella di monitorare il software sviluppato/modificato dall’intervento per poterne verificare la qualità (attraverso gli indicatori previsti in Appendice 4 alle Condizioni di Fornitura “Indicatori di qualità”) misurata nel periodo di osservazione. Nel corso di tale fase il Fornitore dovrà garantire il supporto all’Inail per la risoluzione dei problemi.

Al termine della fase è prevista la consegna del Rapporto degli indicatori di qualità aggiornato. La fase si conclude con la valutazione della qualità del software avviato in esercizio.

Dopo la valutazione sarà avviata la relativa verifica di conformità e, a seguito dell’esito positivo della verifica, sarà rilasciata la certificazione della corretta esecuzione del servizio relativamente ai prodotti oggetto di valutazione.

4 CONTENUTI DEI PRODOTTI DA REALIZZARE

In fase di esecuzione contrattuale, l’Inail condividerà con il Fornitore i propri standard che dovranno essere utilizzati per la consegna dei prodotti di seguito descritti. In assenza di standard, il Fornitore dovrà presentare e condividere con l’Amministrazione una proposta di modello che sarà utilizzato nel corso della fornitura.

Tutti i prodotti in formato testo devono contenere nelle prime pagine almeno le seguenti informazioni:

• Area (laddove applicabile),

• Estremi del contratto,

• Nome del prodotto,

• Data consegna,

• Numero della versione,

• Nominativo della persona che ha redatto il documento,

• Nominativo della persona che ha approvato il documento,

• Nominativo della persona che ha validato il documento,

• Numero di pagine,

• Nome del file, che deve rispettare lo standard Inail,

• Tabella riepilogativa delle revisioni, indicando il numero della revisione, le parti modificate/aggiunte, la descrizione della modifica e la relativa data.

I documenti relativi all’area applicativa dovranno essere mantenuti aggiornati al rilascio di qualsiasi intervento/Obiettivo relativo all’area applicativa stessa, indipendentemente dal ciclo di sviluppo adottato; tali documenti saranno pertanto unici per Area applicativa e verranno aggiornati di volta in volta.

I documenti relativi ad una applicazione di una area applicativa dovranno essere mantenuti aggiornati al rilascio di qualsiasi intervento/Obiettivo relativo all’applicazione indipendentemente dal ciclo di sviluppo adottato, tali documenti saranno pertanto unici per applicazione e verranno aggiornati di volta in volta.

I documenti riferiti al singolo intervento verranno prodotti ed aggiornati durante il ciclo di sviluppo dell’intervento stesso ed i loro contenuti dovranno essere integrati, organici e congrui con i contenuti degli altri prodotti di area o applicazione previsti dal ciclo di sviluppo utilizzato. Inoltre i documenti di intervento dovranno essere redatti ad un livello di completezza tale da:

• Consentire l’approvazione da parte dell’Inail e dell’utente (ove previsto);

• Consentire lo svolgimento della successiva fase;

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

4.1 Lettera di consegna

La lettera di consegna deve accompagnare qualsiasi consegna ufficiale di prodotto (documenti, software, ecc.).

Essa deve contenere almeno le seguenti informazioni:

• Mittente/i;

• Codice della lettera;

• Oggetto, facendo riferimento alla precisa attività contrattuale (esempio fase per gli obiettivi, periodo per le attività continuative, ecc.);

• Elenco di tutti i prodotti consegnati e, per ognuno di essi:

• Percorso del portale in cui sono stati pubblicati o della cartella del CMA per i prodotti software;

• Codice del documento;

• Versione e data;

• Tipo documento;

Per le consegne relative ad attività progettuale è necessario allegare l’elenco dei prodotti previsti dal ciclo di sviluppo adottato evidenziando per ogni prodotto:

• La non applicabilità della consegna;

• Se è oggetto della consegna in corso;

• Se è stato oggetto di una consegna precedente.

4.2 Piani della Qualità16

4.2.1 Piano della Qualità Generale

Il piano della Qualità è il documento che precisa le particolari modalità operative, le risorse e le sequenze delle attività relative alla qualità di un determinato prodotto, progetto, o servizio.

Il Fornitore deve predisporre un Piano della Qualità Generale che:

• Fornisca lo strumento per collegare i requisiti specifici dei servizi contrattualmente richiesti con le procedure generali del sistema qualità del Fornitore già esistenti;

• Espliciti le disposizioni organizzative e metodologiche adottate dal Fornitore, allo scopo di raggiungere gli obiettivi tecnici e di qualità contrattualmente definiti;

• Dettagli i metodi di lavoro messi in atto dal Fornitore, facendo riferimento o a procedure relative al proprio sistema o a procedure sviluppate per lo specifico contratto, a supporto delle attività in esso descritte, in questo caso da allegare al piano;

• Garantisca il corretto e razionale evolversi delle attività contrattualmente previste, nonché la trasparenza e la tracciabilità di tutte le azioni messe in atto dalle parti in causa.

Nella redazione del piano il Fornitore terrà come guida lo schema di riferimento di seguito descritto.

1. Scopo del piano della qualità

(Contiene le finalità del Piano della Qualità ed individua il Sistema di Gestione della Qualità da utilizzare per la fornitura).

2. Documenti applicabili e di riferimento

(Contiene l'elenco completo dei:

• documenti contrattualmente vincolanti,

16 Si precisa che, qualora all’interno della documentazione contrattuale fosse riportato “Piano della qualità”, tale dicitura è da intendere entrambi il “Piano della Qualità generale” ed il “Piano della Qualità dell’Intervento”.

• documenti il cui contenuto è parte integrante del piano e che sono allegati al piano stesso (ad es. standard di documenti del Fornitore, standard di rendicontazione degli indicatori di qualità, procedure/istruzioni definite o personalizzate per il contratto, ecc.),

• documenti che costituiscono un riferimento per quanto esposto nel presente Piano della Qualità).

3. Glossario

(Contiene tutte le abbreviazioni, gli acronimi, le definizioni che sono utilizzate all'interno del Piano della Qualità).

4. Organizzazione della fornitura

(Contiene l'organigramma del gruppo di lavoro impegnato sul contratto (con l'identificazione del responsabile utente finale ed ufficio di riferimento, dei responsabili delle varie attività della fornitura in particolare del referente di area, del Coordinatore delle attività gestionali e del Referente tecnologico, del responsabile dei controlli da svolgere, del responsabile della gestione configurazione e del responsabile dell'assicurazione qualità) e le relazioni con le altre organizzazioni coinvolte nella fornitura.

A ciascun ruolo indicato nell'organigramma, deve essere associata una precisa responsabilità, in modo che ciascun componente del gruppo di lavoro abbia ben chiari i ruoli, i compiti, le responsabilità ed i poteri nell'ambito del contratto. Utilizzare una matrice, denominata “matrice delle responsabilità”, per sintetizzare le responsabilità assegnate).

5. Ciclo di sviluppo del software applicativo

(Descrive il ciclo di sviluppo del software applicativo, le fasi in cui è suddiviso, i criteri di uscita delle fasi, e l'insieme della documentazione da produrre.

Qualora si utilizzino diversi cicli di vita, suddividere il paragrafo in sottoparagrafi relativi ai diversi cicli di vita previsti).

6. Ciclo di erogazione dei servizi

(Contiene la definizione del ciclo di erogazione di ciascun servizio contrattuale, la descrizione dei processi coinvolti nel ciclo e l'insieme della documentazione da produrre).

7. Metodi, tecniche e strumenti

7.1. Progettazione del software applicativo

(Contiene la descrizione delle metodologie, le tecniche e gli strumenti che si intendono adottare per la progettazione, la realizzazione del software applicativo).

7.2. Scrittura e documentazione del software applicativo

(Contiene la descrizione degli standard che si intendono adottare per la stesura del codice sorgente e per la stesura dei commenti nel codice sorgente).

7.3. Progettazione ed esecuzione dei test

(Riporta le linee guida ed i principi ispiratori per la progettazione ed esecuzione delle sessioni di test sia per i nuovi sviluppi che per le MEV).

7.4. Erogazione dei servizi

(Descrive le metodologie, le tecniche e gli strumenti che si intendono adottare per l'erogazione dei servizi).

7.5. Standard documentali

(Contiene l’elenco degli standard da utilizzare per preparare i documenti della fornitura).

8. Requisiti di qualità

8.1. Identificazione dei requisiti di qualità

(Contiene la chiara e non ambigua identificazione degli indicatori di qualità. Per questo è necessario definire:

• gli attributi di qualità relativi a ciascun prodotto ed i livelli di servizio relativi a ciascun servizio;

• gli indicatori con cui misurare gli attributi ed i livelli identificati;

• i valori limite ritenuti accettabili con cui confrontare le misure degli attributi di qualità e dei livelli di servizio effettuate sulla base di indicatori definiti).

8.2. Procedura per la valutazione della qualità

(Definisce la procedura per la valutazione della qualità dei prodotti e/o servizi. La procedura deve esplicitare:

• modalità di misura o di rilevamento dei dati;

• modalità di calcolo e di aggregazione delle misure (per il computo di indicatori derivati);

• frequenza delle misure;

• periodi temporali di riferimento;

• le regole con cui si perviene ai giudizi di Approvazione Incondizionata / Approvazione con Riserva / Non Approvazione di un prodotto e/o un servizio considerando i risultati delle misure relative ai singoli attributi di qualità associati al prodotto e/o livelli di servizio associati al servizio).

9. Registrazioni della qualità

(Identifica tutte le registrazioni della qualità, sia quelle previste dal sistema di gestione della qualità adottato, sia specificatamente previste per l'attuazione del contratto, necessarie a supportare le attività di gestione del contratto e di assicurazione della qualità.

Inoltre descrive le modalità di identificazione, archiviazione, protezione, reperibilità delle registrazioni della qualità ed il periodo previsto di mantenimento delle registrazioni).

10. Verifiche ispettive

(Definisce le modalità con cui effettuare le visite ispettive interne sulle attività della fornitura).

11. Riesami, verifiche e validazioni

(Contiene l'elenco dei controlli da effettuare (riesami, test, verifiche e validazioni, valutazioni, ecc.) per le attività della fornitura, e le modalità di esecuzione dei controlli comprensive sia degli strumenti da utilizzare e sia della modulistica di rendicontazione dei risultati).

12. Segnalazione di problemi ed azioni correttive

(Contiene la descrizione delle specifiche procedure previste per la gestione di problemi quali malfunzionamenti e non conformità. La descrizione deve comprendere la casistica, la modulistica di supporto prevista, i ruoli e le responsabilità delle risorse coinvolte).

13. Controllo della configurazione del software

(Contiene la descrizione dei criteri, delle procedure e degli strumenti adottati per il controllo - immissione, salvaguardia e catalogazione - e la consultazione delle versioni degli elementi software).

14. Controllo dei sub-fornitori

(Delinea le procedure e gli accorgimenti da adottare per il controllo dei sub-fornitori in termini sia di valutazione preventiva che di controllo di quanto fornito).

15. Raccolta e salvaguardia dei documenti

(Contiene la descrizione della procedura per la gestione, conservazione e salvaguardia della documentazione di progetto, nonché il periodo di mantenimento previsto della documentazione).

16. Formazione ed addestramento

(Contiene la descrizione delle attività di formazione inerenti al contratto. Tali attività riguardano sia gli eventuali aggiornamenti tecnici a cui sottoporre le risorse del Fornitore che lavorano per l'espletamento del contratto, sia l'addestramento degli utenti all'uso dei prodotti/servizi contrattualmente previsti).

17. Gestione del prodotto fornito dal cliente

(Descrive le modalità di gestione dei prodotti e degli strumenti forniti dall’Inail).

18. Gestione dei rischi

(Contiene la descrizione della metodologia e delle modalità operative di identificazione e controllo dei rischi).

19. Analisi dei dati per il miglioramento

(Descrive le modalità di rilevazione, analisi e rendicontazione dei dati per le attività legate al miglioramento interno).

4.2.2 Piano della Qualità dell’Intervento

Nella redazione del Piano il Fornitore terrà come guida lo schema di riferimento di seguito descritto, evidenziando sia le caratteristiche qualitative relative a specifici progetti e sia le eventuali deroghe a quanto previsto nel Piano della Qualità Generale.

Schema di riferimento per i contenuti:

1. Descrizione dell’Intervento;

2. Scopo del piano della qualità

(elenca le motivazioni e le peculiarità dell’Intervento per le quali è richiesto il documento);

3. Documenti applicabili e di riferimento specifici dell’Intervento;

4. Ruoli e Responsabilità;

5. Ciclo di sviluppo

(Descrive il ciclo di sviluppo dell'Intervento, le fasi in cui è suddiviso, i criteri di uscita delle fasi, l'insieme della documentazione da produrre ed eventualmente le attività richieste al Fornitore in fase di collaudo/accettazione);

6. Metodi, tecniche e strumenti specifici dell’Intervento

(Contiene l'indicazione dei metodi, delle tecniche, degli strumenti, degli standard di prodotto specifici dell'Intervento solo se diversi da quelli descritti nel Piano della Qualità generale);

7. Indicatori di qualità specifici dell'Intervento

(Contiene gli attributi di qualità con riferimento alle metriche, ai valori limite -Valore di soglia - definiti negli indicatori di qualità, e gli eventuali indicatori di prestazione specifici per l’Intervento, se diversi da quelli descritti nel Piano della Qualità generale);

8. Riesami, verifiche e validazioni specifici dell’Intervento (Contiene l'elenco dei controlli da effettuare (riesami, test, verifiche e validazioni, valutazioni, ecc.), per l'Intervento e le modalità di esecuzione dei controlli, comprensive degli strumenti da utilizzare e della modulistica di rendicontazione dei risultati, se diversi da quelli descritti nel Piano della Qualità generale).

4.3 Rapporti indicatori di qualità

4.3.1 Rapporto Indicatori di qualità della fornitura

È il documento che fornisce i risultati della rilevazione degli indicatori di qualità della fornitura, esclusi gli indicatori di qualità rendicontati nel Rapporto Indicatori di qualità di Intervento.

Il documento deve prevedere una parte di dati analitici ed una di dati di sintesi. Per la parte analitica ciascun indicatore deve contenere almeno:

• La scheda dell’indicatore così come prevista nell’Appendice 4 alle Condizioni di Fornitura - “Indicatori di qualità” o offerta dal Fornitore in offerta tecnica;

• il periodo di riferimento della misura;

• il riferimento agli strumenti di misura utilizzati;

• i dati rilevati;

• il valore rilevato dell’indicatore di qualità;

• l’eventuale scostamento dal valore di soglia;

• l’eventuale razionale di scostamento dai valori di soglia.

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

• Codice e descrizione della metrica;

• Esito della metrica;

• L’eventuale legame con gli indici 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.

4.3.2 Rapporto indicatori di qualità dell’Intervento

Il rapporto indicatori di qualità dell’Intervento dovrà includere almeno il seguente contenuto minimo:

• riferimento al contratto, area applicativa, Intervento;

• per ciascun indicatore applicabile occorre specificare:

• 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 è necessario allegare al documento Rapporto Indicatori di qualità dell’Intervento i report sulla qualità del software, contenenti i risultati della rilevazione. Tali report costituiranno parte integrante ed essenziale del documento.

4.4 Piani di Lavoro

4.4.1 Piano di Lavoro Generale

Il Piano di Lavoro Generale deve contenere attività, tempi e impegno specificati per ogni servizio con la seguente articolazione:

• Il Piano di Subentro (a inizio fornitura);

• Il Piano di Trasferimento di know-how;

• Il Piano di Lavoro per la Manutenzione Correttiva.

4.4.1.1 Piano di Subentro

Il Piano di Subentro conterrà il dettaglio delle attività che devono essere espletate ad inizio fornitura, la relativa tempificazione e le stime di impegno.

Esso sarà prodotto in via propedeutica per la presa in carico e riportato anche nel Piano di Lavoro Generale.

In particolare dovranno essere esplicitate le risorse professionali ed il loro successivo impiego nei servizi della fornitura, le attività, i tempi, gli strumenti offerti e quanto necessario alla completa presa in carico di tutti i servizi della fornitura nonché alla predisposizione degli ambienti, degli strumenti, delle soluzioni, dei sistemi e delle migliorie offerte.

Per le risorse impiegate nei servizi a carattere continuativo e per tutte le figure di Responsabili eventualmente previste dovranno essere forniti i relativi Curricula Vitae.

Coerentemente con le caratteristiche offerte dal Fornitore e concordate con l’Inail, il Piano riporterà:

• Xxxxxx, nome, descrizione delle attività di subentro;

• prodotti delle singole attività;

• nominativo dei referenti delle attività;

• puntamento ai paragrafi dell’offerta tecnica in cui è descritta l’attività (ove applicabile) e/o ai paragrafi delle Condizioni di Fornitura e delle relative appendici in cui l’attività è richiesta;

• impegno in GGPP, stimato ed effettivo, suddiviso per mese e figura professionale, ove applicabile;

• il GANTT delle attività, contenente:

• date di inizio e fine, previste ed effettive, delle singole attività;

• date di consegna, previste ed effettive, dei singoli prodotti.

Il Piano di Subentro dovrà rispettare i requisiti minimi espressi nelle Condizioni di Fornitura.

4.4.1.2 Piano di Trasferimento di know-how

Il Piano di Trasferimento di know-how deve contenere il dettaglio delle attività, la relativa tempificazione e le stime di impegno.

Tale piano dovrà descrivere obbligatoriamente le seguenti fasi/documenti:

• Presentazione esaustiva degli aspetti organizzativi, amministrativi e tecnici della fornitura, dei processi di riferimento, dell’architettura generale del sistema nonché delle architetture di ogni singola area applicativa e/o applicazione;

• Consegna di tutti gli oggetti software al fine di permettere la predisposizione di un ambiente operativo parallelo;

• Estrazione, verifica e consegna di tutti i documenti previsti dal presente contratto;

• Predisposizione di quadri di sintesi architetturali e funzionali;

• Predisposizione di questionari e sessioni di domande/risposte per verificare il grado di apprendimento sia sugli ambienti tecnologici, sia funzionali e tecnici;

• Presentazione degli aspetti di criticità di ogni servizio/area applicativa con l’esposizione chiara delle soluzioni proposte ed attuate durante la fornitura;

• Presentazione delle modalità organizzative, degli obiettivi e delle risorse impiegate. Inoltre, coerentemente con le caratteristiche del know how da trasferire, il Piano riporterà:

• Codice e nome delle attività di trasferimento di know how;

• Prodotti delle singole attività;

• Impegno in GGPP, stimato ed effettivo, ove applicabile, suddiviso per mese e figura professionale;

• GANTT delle attività, contenente:

• date di inizio e fine, previste ed effettive, di ogni attività;

• date di consegna, previste ed effettive, di ogni prodotto.

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

• data a cui si riferisce lo stato di avanzamento;

• percentuale di avanzamento delle singole attività;

• razionali di ripianificazione, scostamento eventuale delle date, dell’impegno e del volume;

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

Allegato al piano dovrà essere sempre presente il Rendiconto Risorse, come meglio oltre specificato.

4.4.1.3 Piano di Lavoro per la Manutenzione Correttiva

Il Piano di Lavoro per la Manutenzione Correttiva conterrà il dettaglio delle attività previste nel mese in apertura corredate dalla relativa tempificazione e, laddove previsto dalle Condizioni di Fornitura, le stime di impegno.

In particolare, il Piano deve riportare:

• orario di servizio ordinario, ore di estensione e di reperibilità previste ed effettive;

• elenco delle attività con relativa descrizione, comprensivo di tutti i trasferimenti in esercizio degli obiettivi;

• eventuali prodotti delle singole attività;

• impegno in GGP, stimato ed effettivo, suddiviso per figura professionale;

• nominativo del referente di ogni attività.

• un GANTT delle attività, contenente:

• date di inizio e fine, previste ed effettive, di ogni attività,

• date di consegna, previste ed effettive, di ogni prodotto.

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

• data a cui si riferisce lo stato di avanzamento;

• percentuale di avanzamento delle singole attività;

• data di chiusura effettiva;

• razionali di ripianificazione, scostamento eventuale delle date, dell’impegno e del volume;

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

Il piano dovrà essere corredato del relativo Rendiconto Risorse, come meglio oltre specificato.

4.4.2 Piano di Lavoro dell’Intervento

Il Piano di Lavoro dell’Intervento, relativo alle attività di carattere progettuale, contiene il dettaglio delle attività di ogni singola fase del singolo Intervento, la relativa tempificazione e le stime di impegno.

A fronte di ripianificazioni autorizzate dall’Inail, dovrà essere predisposta una nuova versione del Piano di lavoro. L’aggiornamento dello stato di avanzamento delle attività, su richiesta dell’Inail, non determina una nuova versione del documento.

Coerentemente con le caratteristiche dei singoli obiettivi o attività, con i cicli di sviluppo definiti e con lo stato temporale (piano iniziale o aggiornamento), il Piano di lavoro dell’Intervento riporterà:

• Nominativo del Responsabile di Progetto responsabile dell’Intervento;

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

• ciclo di sviluppo adottato;

• elenco delle fasi, delle singole attività con relative date di inizio e fine, dei prodotti di fornitura previsti con le relative date di consegna, previste ed effettive; in particolare, per la fase di realizzazione, deve essere data evidenza delle attività di test di modulo, di integrazione e prestazionali;

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

• impegno, stimato ed effettivo dell’effort progettuale, ove applicabile suddiviso per fase/attività e per figura professionale;

• gruppo di lavoro previsto;

• 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; in particolare, per la fase di realizzazione, deve essere data evidenza delle attività di test di modulo, di integrazione e prestazionali;

• 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’Inail. 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);

• eventuali attività di certificazione del software, secondo le modalità descritte nelle Condizioni di Fornitura;

• 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 l’Intervento abbia ripercussioni sulle funzionalità di altre aree applicative.

• impegno, stimato ed effettivo dell’effort progettuale, ove applicabile suddiviso per fase/attività e per figura professionale;

• gruppo di lavoro previsto;

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. Si precisa che:

• le date di consegna dei singoli prodotti di fase potranno variare per ciascun Intervento, anche con date intermedie nell’ambito della fase;

• le date finali delle varie fasi devono essere comprensive, ad esempio, anche dell’eventuale tempo di approvazione dei prodotti;

• dovrà essere esplicitata, quale attività separata all’interno della relativa fase, l’attività di test (o verifica, validazione, review);

• nel caso di Obiettivi che prevedano la suddivisione in sotto-Obiettivi, inoltre, il piano dovrà dettagliare, anche in termini di stime, ogni singolo sotto-Intervento;

• nel caso di Obiettivi che prevedano un ciclo di sviluppo iterativo, il piano dovrà esplicitare le date previste per gli incontri di verifica.

4.4.3 Piano di Lavoro Riepilogativo

Il Piano di Lavoro Riepilogativo, coerentemente con le proprie caratteristiche, è un documento che riepiloga l’ultima pianificazione degli obiettivi in corso e sospesi. Il documento è organizzato in due sezioni:

• la prima contiene il GANTT con le principali milestone (inizio e fine di ogni fase dell’Intervento);

• la seconda contiene la gestione delle criticità/vincoli che emergono dal GANTT.

4.4.4 Rendiconto risorse

Il Rendiconto delle risorse è un riepilogo mensile, a corredo del Piano di lavoro Generale, che dovrà contenere per ogni servizio/attività per cui è previsto:

• una parte analitica, che dettagli

• elenco del personale impiegato dal Fornitore con l’indicazione del profilo professionale ricoperto, specificando il possesso di eventuali certificazioni o credenziali offerte o richieste dalle Condizioni di Fornitura;

• dettaglio in ore del tempo impiegato da ciascuna risorsa per ogni attività svolta, specificando l’eventuale estensione o reperibilità;

• una parte sintetica, in maniera automatica, a partire dal rendiconto risorse – parte analitica, dovrà essere aggiornato il riepilogo a livello di anno/mese, fornendo in particolare:

• macro attività a carattere continuativo (il livello di aggregazione delle singole attività sarà concordato con il Responsabile di Progetto);

• mese/anno di riferimento;

• giorni impiegati per ogni macro attività, distinti per figura professionale;

• eventuali giorni di estensione e/o reperibilità, distinti per figura professionale (ove applicabile).

4.5 Specifica dei Requisiti

La specifica deve contenere i requisiti sia non funzionali che funzionali, pena la non consegnabilità, la non accettabilità, l’emissione di rilievo e le altre sanzioni derivanti dal conseguente ritardo nella chiusura della fase.

Lo standard da utilizzare sarà consegnato al Fornitore successivamente alla stipula del contratto.

Qualora per l’Intervento non sia richiesta la realizzazione del prototipo e/o del Campione Tecnico, nel documento Specifica dei Requisiti deve essere formalizzato il motivo della non applicabilità.

A partire dalle specifiche dei requisiti di intervento (o documenti similari) viene redatto il documento “Specifica dei requisiti di applicazione” con la finalità di avere un documento unico che contenga tutti i requisiti funzionali e non funzionali, di una data applicazione.

4.6 Verbale dei requisiti

È un documento che contiene la descrizione sintetica dei requisiti, funzionali e non, espressi dall’utente.

È un documento di Intervento redatto sotto forma di verbale.

4.7 Specifiche

Sono previste due tipologie del documento:

• Specifiche di Intervento,

• Specifiche di applicazione.

I documenti differiscono per l’ambito di riferimento: il primo l’Intervento, il secondo l’intera applicazione.

Entrambi i documenti contengono in modo completo ed esaustivo l’analisi dei requisiti funzionali e non funzionali e descrivono il prototipo e/o il campione tecnico, laddove previsti.

Per la descrizione di dettaglio dei contenuti nonché per il template da utilizzare nella predisposizione del documento, lo standard Inail sarà consegnato al Fornitore successivamente alla stipula del contratto.

Si precisa, inoltre, che il livello di completezza richiesto deve essere tale da:

• consentire l’approvazione da parte dell’Inail;

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

• consentire lo svolgimento della successiva fase di disegno di dettaglio;

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

• garantire la tracciabilità con quanto descritto nel documento di requisiti.

Il documento “Specifiche di applicazione” viene aggiornato a partire dalle specifiche funzionali di intervento (o documenti similari) con la finalità di avere un documento unico che contenga tutte le informazioni previste per il documento di specifica funzionale di intervento.

4.8 Specifiche dell’intervento

Il documento “specifiche dell’intervento” conterrà sia gli aspetti funzionali sia gli aspetti tecnici, pertanto racchiuderà in un unico documento ed in formato sintetico quanto previsto nei rispettivi documenti di specifiche funzionali e di disegno di dettaglio.

4.9 Disegno di dettaglio

Sono previste due tipologie del documento Disegno di dettaglio:

• Disegno di dettaglio di Intervento,

• Disegno di dettaglio di applicazione.

I documenti differiscono per l’ambito di riferimento: il primo l’Intervento, il secondo l’intera applicazione.

Entrambi i documenti contengono una specifica in cui le funzionalità sono trasformate ed organizzate in moduli elaborativi strutturati. È compresa nel disegno di dettaglio la documentazione dello schema logico e fisico dei dati.

Ad esempio, per i vari moduli, devono essere trattati:

• 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 lo schema 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.

Deve comunque essere garantita la tracciabilità con il documento di Specifica Funzionale e Specifica dei Requisiti e del glossario. I dati contenuti nel documento devono essere sempre tenuti aggiornati.

Il documento “Disegno di dettaglio di applicazione” viene aggiornato a partire dal disegno di dettaglio di intervento (o documenti similari) con la finalità di avere un documento unico che contenga tutte le informazioni previste per il documento di disegno di dettaglio di intervento.

4.10 Piano della Sicurezza

Il documento dovrà essere consegnato nella fase di presa in carico e dovrà essere aggiornato nel corso del contratto qualora si presentino variazioni tecnologiche significative e/o modifiche all’architettura di sicurezza che potrebbero incidere sulla capacità di mantenere gli obiettivi di sicurezza o portare alla modifica del livello di sicurezza complessivo ovvero aggiornamenti delle prescrizioni minime di sicurezza nel rispetto della normativa di riferimento ovvero a seguito dei risultati delle attività di audit.

Il documento deve contestualizzare e dettagliare l’approccio metodologico e l’organizzativo che il Fornitore intende adottare per la gestione della sicurezza.

A titolo esemplificativo e non esaustivo il documento dovrà contenere le seguenti sezioni e informazioni:

- Obiettivi,

- Politiche di sicurezza,

- Sistema ISMS adottato,

- Organizzazione,

- Inventario e classificazione delle informazioni,

- Gestione delle risorse umane,

- Gestione della sicurezza fisica e ambientale,

- Gestione delle Operazioni e delle Comunicazioni,

- Controllo accessi,

- Acquisizione di sistemi, sviluppo e manutenzione,

- Gestione degli incidenti di Sicurezza,

- Business Continuity Management,

- Compliance e audit,

- Attività di sviluppo e manutenzione,

- Asset Inventory,

- Analisi dei rischi,

- Piano di gestione dei rischi.

4.11 Business Impact Analysis

Il Fornitore dovrà supportare Inail nella predisposizione del documento di BIA anche aggiornando, per tutta la durata del contratto, le informazioni ivi contenute a fronte dell’introduzione di nuovi sistemi/applicazioni o di mutate esigenze, ovvero su richiesta dell’Istituto.

La BIA ha lo scopo di determinare le conseguenze derivanti dal verificarsi di un evento critico e di valutare l’impatto di tale evento sull’operatività di Inail.

Lo svolgimento di una BIA prevede i passi descritti nel seguito:

- individuazione delle procedure amministrative e dei servizi critici;

- identificazione dell’insieme delle risorse informatiche e del personale coinvolto nelle procedure e servizi critici;

- analisi dell’impatto dell’indisponibilità prolungata (e relativa individuazione degli obiettivi di ripristino);

- determinazione delle strategie di ripristino opportune. Gli obiettivi di ripristino sono individuati dai seguenti parametri:

- Recovery Time Objective (RTO): indica per quanto tempo Inail può sopportare l'interruzione o il degrado prestazionale della procedura o servizio resosi indisponibile a fronte di un evento;

- Recovery Point Objective (RPO): indica in quale misura Inail può sopportare la perdita di dati associati alla procedura o servizio in esame.

La BIA contiene quindi le seguenti informazioni minime:

- identificazione delle esigenze generali di continuità operativa;

- approccio adottato;

- caratterizzazione delle procedure e servizi dell'amministrazione;

- caratterizzazione dei sistemi informatici;

- identificazione delle esigenze di continuità operativa dei sistemi informatici (obiettivi RTO, RPO);

- priorità di intervento.

4.12 Campione tecnico

Il campione tecnico è la realizzazione, adottando gli strumenti e l’architettura previsti per l’intero sistema, di una funzionalità completa del 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 intervento che dovrà essere sempre previsto per gli interventi strategici e per gli interventi con almeno 100 PF, salvo diversa richiesta di INAIL.

4.13 Prototipo

Il prototipo è rivolto alla esplicitazione dell’interfaccia utente, in termini di layout e di modalità di utilizzo dell’applicazione. In tal caso la documentazione delle interfacce prevista nel documento Specifiche Funzionali 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.

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

Nelle fasi iniziali del ciclo di sviluppo, in accordo con l’Amministrazione, il prototipo può essere realizzato anche attraverso l’utilizzo di fogli Excel o di presentazioni in Powerpoint, in quanto finalizzato a condividere con l’utente finale il “look-and-feel” delle pagine che saranno realizzate e i percorsi di navigazione. Nella fase di Disegno, il prototipo dovrà invece evolvere e consentire all’utente finale di percepire quale sarà il risultato finale della realizzazione.

Nell’ambito del ciclo di sviluppo iterativo, il prototipo può evolversi e arricchirsi durante il ciclo di sviluppo dell’Intervento, fino a diventare la realizzazione del sistema.

4.14 Codice sorgente

Per codice sorgente si intende genericamente l’insieme degli oggetti software, realizzati o sottoposti a manutenzione; a titolo esemplificativo e non esaustivo quindi:

• Programmi,

• tracciati e definizioni dati,

• schermi di input/output,

• pagine web,

• procedure,

• job,

• query,

• script (anche gli script relativi ai test automatizzati),

• utility di modifica/aggiornamento dati.

Fanno parte del codice sorgente le procedure di consegna e trasferimento oggetti per gli ambienti di configuration management, nonché le procedure di creazione delle tabelle ed i relativi job di caricamento dati (per intero DB e/o porzioni secondo criteri definiti) anche per gli ambienti di sviluppo, manutenzione, collaudo ed esercizio.

Fanno parte del codice sorgente, inoltre, l’help on-line e l’eventuale codice di test e collaudo.

In generale, il codice sorgente dovrà includere anche il codice per la distribuzione automatizzata, comprensivo di:

• procedura di installazione (setup applicazione e/o patch),

• procedura di disinstallazione,

• parametri di configurazione dell’ambiente su cui l’applicazione sarà installata.

Il codice sorgente di nuova realizzazione (anche nuovo codice all’interno di programmi preesistenti) dovrà essere redatto in conformità agli standard previsti e comunque sempre secondo le indicazioni presenti nella documentazione ufficiale dei linguaggi utilizzati.

Non è consentito l’uso di istruzioni (o funzioni) proprietarie o caratteristiche di singole piattaforme. Laddove applicabile, l'interrogazione di sistemi/componenti dovrà avvenire mediante funzionalità/interfacce/API standard rese disponibili dai linguaggi/prodotti in uso.

Si richiama inoltre l’attenzione al rispetto, nella stesura del codice, agli standard in vigore, sia per formalismi di redazione, sia per l’adozione dei prodotti individuati dall’Inail, sia per il loro corretto utilizzo.

4.15 Casi d’uso

L’INAIL richiede al fornitore di utilizzare i Casi d’Uso come strumento primario per la raccolta dei requisiti, in particolar modo funzionali. La compilazione dei Casi d’Uso è tendenzialmente effettuata dal personale INAIL competente per materia, ovvero quando il personale INAIL non sia in grado di compilarlo direttamente, dal Fornitore sempre congiuntamente al suddetto personale INAIL. Il Caso d’Uso si intende valido per le successive fasi quando sia conforme allo standard adottato da INAIL e sia stato validato dal personale INAIL competente per materia.

Pertanto si richiede al Fornitore di mettere a disposizione risorse che abbiano un’elevata competenza ed esperienza nell’esplicitazione dei requisiti attraverso l’utilizzo dei Casi d’Uso sia di tipo business che di tipo system.

L’insieme dei Casi d’Uso compilati deve coprire il 100% delle funzionalità dell’applicazione o del servizio da sviluppare, viceversa non è ammesso lo sviluppo di alcuna funzionalità che non sia stata preventivamente descritta in un Caso d’Uso.

4.16 Documento di Vision

Nel documento di Vision, come previsto dagli standard INAIL, sono riportate le informazioni di seguito (a titolo non esaustivo):

- definizione del contesto attuale;

- descrizione delle esigenze;

- vincoli;

- numero e tipologia degli utenti coinvolti;

- indicazioni generali della soluzione, sia in termini funzionali che architetturali;

- dati trattati, in forma di schema concettuale iniziale, nonché stima iniziale dei volumi;

riferimenti a ulteriore documentazione di interesse prodotta o preesistente (esempio: definizione dei requisiti nella documentazione contrattuale, studi di fattibilità, resoconti riunione, ecc.).

4.17 Piano di Test

Il Piano di Test è un documento che accompagna ogni Intervento lungo tutto il ciclo di sviluppo, 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.

Il template di riferimento da utilizzare nella predisposizione del documento sarà consegnato al Fornitore in corso di esecuzione del contratto.

Il piano dovrà contenere tutte le misurazioni relativi agli indicatori richiesti per la verifica della qualità intrinseca del software, sia se già definiti nell’appendice indicatori di qualità sia in funzione della specificità dell’intervento e dell’aggiornamento degli standard Inail di qualità del software.

In particolare già dalle prime fasi dovranno essere allegati al piano di test i seguenti test non funzionali riguardanti l’accessibilità, sicurezza applicativa e performance e ulteriori caratteristiche di qualità sul modello ISO 25010.

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

Lo standard da utilizzare è quello previsto da INAIL.

Al termine della fase di realizzazione, dovrà essere consegnato il “Rapporto di esecuzione dei test”, che rappresenta il piano di test con l’evidenza dei test effettuati e del relativo risultato.

4.18 Piano di collaudo

Il piano di collaudo è un documento che può essere derivato dal piano di test e deve contenere almeno le seguenti informazioni:

- Strategia, metodologia e obiettivi del collaudo;

- Pianificazione temporale del collaudo;

- Specificazione dei requisiti e dei vincoli dell’ambiente di collaudo;

- Caratteristiche dell’hardware e del software di base previste per il collaudo;

- Oggetti sottoposti a collaudo;

- Procedure di collaudo.

4.19 Documentazione utente

La documentazione utente si intende composta dai seguenti elementi/documenti:

• Manuale utente,

• Help on line (rilasciato con il codice sorgente),

• FAQ (Frequently Asked Questions), comprensive delle relative risposte, predisposte sia per gli utenti finali che, opportunamente riviste, per il personale dedicato al Service Desk.

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 a 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 dei contenuti degli output della applicazione (es. stampe).

La descrizione delle funzionalità disponibili deve essere completo 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.

Quick Guide

La quick guide è un documento di natura sintetica che riassume le principali operazioni a disposizione dell’utente, evidenziando eventuali elementi di attenzione (es. prerequisiti per l’utilizzo, campi obbligatori, situazioni bloccanti, modalità di assistenza ecc.) che devono essere posti nell’utilizzo delle funzionalità applicative.

Help on line

Tutte le applicazioni interattive devono prevedere le funzioni di help on line, realizzati secondo i principali standard o formati esistenti, come ad es. CHM, HTML, PDF, ecc.

FAQ

Il documento di FAQ (Frequently Asked Questions), deve descrivere le risposte alle domande più frequenti, individuando soprattutto le situazioni legate all’utilizzo delle funzionalità più critiche. Lo stesso documento di FAQ dovrà essere rielaborato nell’ottica di fungere da strumento di supporto agli operatori dedicati al Service Desk, in modo da facilitare e rendere più efficiente il servizio.

4.20 Manuale di gestione applicativo

Il Manuale di gestione applicativo è lo strumento necessario al personale tecnico delle strutture preposte all’installazione ed esercizio dell’applicazione.

Tale manuale dovrà:

• Essere corredato da uno schema riepilogativo contenente informazioni anagrafiche relative all’applicazione;

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

Lo standard di riferimento per la predisposizione del documento e per la descrizione dei contenuti sarà consegnato al Fornitore successivamente alla stipula del contratto.

Piano di adeguamento degli ambienti

Il manuale di gestione applicativo dovrà contenere anche il Piano di adeguamento degli ambienti, che rappresenta il documento di supporto alle attività di trasferimento ed installazione negli ambienti di collaudo e di esercizio.

Tale piano dovrà:

• essere strutturato in sezioni relative rispettivamente all’ambiente di collaudo, all’ambiente di esercizio;

• contenere almeno le seguenti informazioni:

• Responsabile del change;

• pianificazione delle attività necessarie alla predisposizione dell’ambiente di collaudo/esercizio/manutenzione, con 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.);

• istruzioni operative, con evidenza dei riferimenti ai manuali di gestione dell’applicazione e dei server.

Documentazione delle procedure batch/DTS

In allegato al manuale di gestione applicativo, ove necessario, dovrà essere consegnata la documentazione delle procedure off line (batch, job, stored procedure, DTS, script ecc.) che è destinata ai gruppi di gestione applicativa quale supporto alle loro attività ordinarie e che 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.).

4.21 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;

- Nome e Descrizione delle Entità;

- Nome e Descrizione degli Attributi;

- mapping concettuale-logico (su tool di modellazione dati o su documento); Schema concettuale

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.

Schema logico

Lo schema logico dovrà contenere:

- Schema grafico rappresentante le relazioni;

- Vincoli di integrità;

- Relazioni fondamentali;

- Relazioni associative;

- Chiavi primarie e secondarie.

Mapping concettuale-logico

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

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.

4.22 Modulo per il conteggio dei Punti Funzione

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

Lo standard da utilizzare sarà consegnata al Fornitore successivamente alla stipula del contratto.

4.23 Report aggiornamento baseline

È il documento in cui sono contenute le informazioni relative al conteggio dei punti funzione affidati al servizio di Manutenzione Correttiva.

Il report sarà consegnato dal Fornitore nell’ambito della consegna del conteggio consuntivo (Xxxxxx per conteggio PF).

Il report deve riportare almeno le seguenti informazioni:

• baseline di partenza;

• baseline aggiornata;

• identificativo ed estremi degli obiettivi di sviluppo che hanno determinato il decremento della baseline, con i relativi punti funzione.

4.24 Lista oggetti software

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 l’Intervento.

La LOS deve essere completa di tutte le informazioni necessarie all’Inail per la gestione della configurazione attraverso gli strumenti dichiarati nei contenuti e tracciati, che l’Istituto si riserva di stabilire e di modificare a sua discrezione nel corso del contratto.

Le informazioni da fornire sono:

• codice e descrizione dell’area;

• codice e descrizione dell’Intervento;

• codice e descrizione dell’applicazione;

• data di fine garanzia.

Per ogni oggetto dovranno essere riportate le seguenti informazioni:

• codice dell’area che manutiene l’oggetto (un Intervento potrebbe trattare oggetti di altre aree applicative);

• codice dell’Applicazione che manutiene l’oggetto;

• progressivo della funzione che manutiene l’oggetto;

• progressivo della funzione che utilizza l’oggetto;

• dato di riferimento, nel caso di entità o relazione;

• nome elemento;

• piattaforma (es.: VM, UNIX, …);

• linguaggio completo di versione;

• tipo oggetto;

• dimensione (ove applicabile);

• dimensione dei commenti;

• radice percorso (ove applicabile);

• directory (ove applicabile);

• primo modulo chiamante (flag che indica se il modulo è il primo chiamante).

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.

Lo standard da utilizzare sarà consegnato al Fornitore in corso di esecuzione del contratto.

4.25 Convalida sulla tecnologia

Il documento attesta la conformità di quanto analizzato / progettato 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à generale o di Intervento).

È un documento di intervento. Tale documento dovrà esplicitare:

- il nome e la release dei prodotti utilizzati;

- i puntuali riferimenti (manualistica, best practices, indicazioni specifiche, ecc.) su cui si baserà la realizzazione;

- la dichiarazione del Fornitore di utilizzare i prodotti secondo le specifiche valide per le versioni indicate.

4.26 Demo sulle novità del sistema

Per ogni evoluzione/modifica del sistema, il Fornitore deve produrre una demo che illustri dettagliatamente agli utenti le modifiche intervenute. Dietro richiesta dell’Inail, la demo deve essere personalizzata per ogni tipologia di utente.

4.27 Altri documenti

Il prodotto di fase “altri documenti” comprende specifici output nelle varie fasi legati alle peculiarità dell’Intervento quali protocollo di colloquio con altre applicazioni e/o organismi, documento dell’architettura generale delle applicazioni, parametri di rilevazione dei requisiti di qualità aggiuntivi e specifici, piano di rischio, analisi d’impatto, schemi di parametrizzazioni, ecc. Questo prodotto di fase, laddove opportuno, deve essere aggiornato in tutte le fasi successive a quella di realizzazione od in cui viene prodotto.

Document Metadata

Table of Contents

APPENDICE 3 ALLE CONDIZIONI DI FORNITURA CICLI E PRODOTTI

Document Metadata