Contract
ID 2202
GARA A PROCEDURA APERTA PER LA CONCLUSIONE DI UN ACCORDO QUADRO, AI SENSI DEL D.LGS. 50/2016 E S.M.I., AVENTE AD OGGETTO L’AFFIDAMENTO DI SERVIZI APPLICATIVI E L’AFFIDAMENTO DI SERVIZI DI SUPPORTO IN AMBITO «SANITA’ DIGITALE - Sistemi Informativi
Clinico-Assistenziali» PER LE PUBBLICHE AMMINISTRAZIONI DEL SSN
APPENDICE 4
Classificazione del documento: CONSIP PUBLIC
INDICE
1 PREMESSA 3
2 REALIZZAZIONE DI PROGETTI DIGITALI 4
3 PROCESSI E ATTIVITA’ DEL CICLO DI VITA 6
3.1 Attività 6
3.1.1 Definizione 6
3.1.2 Analisi 7
3.1.3 Disegno 7
3.1.4 Realizzazione 7
3.1.5 Verifica 8
3.1.6 Collaudo 8
3.1.7 Documentazione 8
3.2 Avvio in esercizio 9
3.3 I Cicli di Vita 9
4 CONTENUTI DEI PRODOTTI DA REALIZZARE 11
4.1 Lettera di consegna 11
4.2 Piano della Qualità Generale di Lotto 12
4.3 Piano della Qualità Specifico di Contratto Esecutivo 15
4.4 Piano della Qualità di obiettivo 16
4.5 Piano di Lavoro Generale 17
4.6 Piano di Lavoro di obiettivo 19
4.7 Piano di resa in carico e Subentro 20
4.8 Piano di Trasferimento di Know how 21
4.9 Rendiconto risorse 21
4.10 Report aggiornamento baseline 22
4.11 Report Indicatori di qualità 22
4.12 Report Indicatori di qualità di obiettivo 23
4.13 Specifiche requisiti 24
4.14 Product Backlog 24
4.15 Sprint Backlog 24
4.16 Specifiche funzionali 24
4.17 Disegno di dettaglio 24
4.18 Disegno dell’architettura 25
4.19 Re-design architetturale (migrazione al Cloud) 25
4.20 Report/Check-list di conformità 25
4.21 Codice sorgente 26
4.22 Piano di Test 26
4.23 Prototipo 27
4.24 Documentazione utente 27
4.25 Manuale di gestione applicativo 28
4.26 Manuale di gestione infrastruttura e servizi cloud 28
4.27 Piano di adeguamento degli ambienti 28
4.28 Documentazione dati 29
4.29 Modulo per conteggio FP 30
4.30 Report sulla qualità del software 30
4.31 Lista oggetti software 31
4.32 Documentazione delle procedure batch/DTS 31
4.33 Convalida sulla tecnologia 32
4.34 Demo sulle novità del sistema 32
4.35 Altri documenti 32
1 PREMESSA
L’obiettivo del presente documento è fornire uno strumento di lavoro per la realizzazione dei progetti nell’ambito dell’Accordo Quadro relativi all’affidamento di Servizi Applicativi in ambito SANITA’ DIGITALE - Sistemi Informativi Clinico-Assistenziali», con applicazione a ciascuno dei Lotti di fornitura da 1 a 4.
Nell’ambito delle indicazioni e delle raccomandazioni contenute nel Piano Triennale per l’informatica nella Pubblica Amministrazione e nelle diverse linee guida di AgID per la realizzazione e gestione dei sistemi informativi e servizi digitali nella Pubblica Amministrazione, sono descritti con carattere pratico gli accorgimenti utili per la predisposizione e gestione di un progetto digitale.
Nell’ambito dei singoli Contratti Esecutivi attivati dalle Amministrazioni, l’Amministrazione contraente indicherà al fornitore il ciclo di vita in considerazione del suo contesto organizzativo e tecnologico tenendo presente le indicazioni di riferimento contenute nel Piano Triennale.
L’Amministrazione, scegliendo un ciclo di vita agile, deve anche garantire partecipazione di proprio personale alle varie iterazioni e il rispetto delle tempistiche massime previste per l’approvazione dei prodotti.
2 REALIZZAZIONE DI PROGETTI DIGITALI
Un progetto digitale per la Pubblica Amministrazione, sia esso di realizzazione di un nuovo sistema o di evoluzione di un sistema esistente, ha come obiettivo fondamentale quello di incentivare e accrescere la relazione tra l’utilizzatore dei servizi (tipicamente i cittadini e le imprese) e l’Amministrazione erogante, garantendo a entrambe le parti coinvolte un’esperienza di qualità e il raggiungimento dei risultati desiderati nell’accesso e nella fruizione di strumenti e servizi al passo con le tecnologie moderne.
La capacità di offrire e supportare gli utenti con sistemi e applicazioni evolute, che possano raggiungere tale obiettivo, è strettamente collegata alla capacità di rinnovare l’approccio e la strategia di gestione dei progetti, favorendo l’adozione di modelli di lavoro agili in cui collaborazione, creatività e flessibilità rappresentano le caratteristiche chiavi, in contrapposizione alla rigidità dei modelli di sviluppo tradizionale.
Per mettere in pratica tali principi all’interno di un’iniziativa progettuale è necessario guidare il processo in modo strutturato, coinvolgendo continuamente gli utenti e allineando costantemente il punto di vista di tutti i soggetti coinvolti.
Nel seguito vengono richiamati sinteticamente le principali metodologie (cicli di vita) che possono essere utilizzate nell’ambito della fornitura:
• agili: rientrano in questa categoria i diversi modelli di applicazione dei principi agili tra cui le principali e più diffuse sono Scrum, XP (Extreme Programming), TDD (Test Driven Development), Lean Development, ecc. In questi modelli si segue un approccio incrementale e iterativo superando il concetto di fase;
• tradizionali: rientrano in questa categoria gli approcci classici nello sviluppo del software in cui si segue il modello a cascata e l’organizzazione delle fasi determina il ciclo (es. completo, ridotto, a fase unica, etc…). In questi modelli le attività sono organizzate in fasi distinti e sequenziali che determinano le milestone progettuali;
• ibridi: rientrano in questa categoria gli approcci misti che tentano di cogliere i benefici dei diversi modelli, armonizzando fasi e iterazioni al fine di ottenere i risultati desiderati.
Ad attivazione dell’obiettivo la scelta del ciclo di vita da adottare è demandata all’Amministrazione e per il governo della fornitura, a prescindere da tale scelta, varranno le seguenti definizioni:
• Sprint: è un periodo limitato di tempo, della durata massima di un mese, durante il quale viene creato un incremento di prodotto potenzialmente rilasciabile e utilizzabile dagli utenti dell’Amministrazione, che hanno un ruolo attivo nella verifica e validazione di quanto rilasciato; gli sprint hanno in genere una durata costante nel progetto e un nuovo sprint si avvia immediatamente dopo la conclusione del precedente.
• Fase: rappresenta uno dei momenti caratteristici in cui si articola il progetto; tipicamente le fasi sono progressive e in generale non è possibile iniziare una fase se non è completata quella precedente mediante una validazione da parte dell’Amministrazione.
• Prodotto di fase/sprint: indica i prodotti di output della singola fase/sprint, la cui descrizione è riportata nel capitolo dedicato al contenuto dei prodotti.
• Criterio di uscita: contiene gli atti, formali o no, che delimitano la fine della fase/sprint.
Qualunque sia la metodologia scelta dall’Amministrazione il fornitore deve garantire, in forme dipendenti dalla metodologia scelta:
• la consegna del Piano di Lavoro Generale e del Piano di Qualità Specifico al massimo entro dieci giorni lavorativi dalla stipula del Contratto Esecutivo;
• la congruenza delle attività di misurazione dell’impegno in giorni persona dei profili impiegati e la misurazione in metriche di prodotto;
• la gestione del progetto, della pianificazione delle risorse/attività, della misurazione della qualità interna- esterna ed in uso supportata da specifici strumenti di testing e controllo, delle review;
• la gestione dei rischi e delle comunicazioni interne ed esterne con la Amministrazione, la misurazione dei dati di produttività, la consuntivazione delle risorse per fase/sprint e per attività, per componente;
• la qualità della documentazione a corredo dell’attività di realizzazione/modifica software.
Il livello di documentazione dell’intervento e del software deve essere tale da permettere la piena comprensione e modificabilità da parte di un fornitore terzo, ed il rilascio e gestione in esercizio da parte dei gruppi competenti.
Questi documenti concorrono alla verifica di conformità.
3 PROCESSI E ATTIVITA’ DEL CICLO DI VITA
I diversi cicli di vita che l’Amministrazione può richiedere per l’erogazione di un intervento possono prevedere attività articolate in funzione della struttura organizzativa, del modello di lavoro e della tipologia di obiettivo.
Per tale ragione, al fine di dare le indicazioni minime necessarie a garantire il governo dei progetti dal loro avvio alla loro conclusione, nel presente capitolo si citano i processi fondamentali che l’Amministrazione deve necessariamente prevedere.
Tali processi non devono essere eseguiti in via sequenziale e possono essere in continua interazione e sovrapposizione tra loro in base, appunto, alle specificità del ciclo di vita adottato. Essi sono:
• Processi di avvio: comprendono le attività di preliminari all’esecuzione vera e propria e si occupano della loro definizione e relativa autorizzazione da parte dell’Amministrazione. Segnano il momento in cui il Fornitore raccoglie i requisiti, gli obiettivi del progetto/fase/sprint stabiliti dall’Amministrazione, in termini di tempo, costo e qualità.
• Processi di pianificazione: comprendono le attività di stima di tempi e costi da parte del fornitore, della definizione della modalità tramite cui raggiungere gli obiettivi di progetto/fase/sprint, sulla base dei dati raccolti dagli altri processi ed elaborati nei documenti di piano e di gestione dei rischi, che vanno approvati dall’Amministrazione.
• Processi di esecuzione: comprendono le attività del fornitore di realizzazione definite nei processi di pianificazione per progetto/fase/sprint.
• Processi di verifica e controllo: comprendono le attività del fornitore di raccolta dati sull’andamento delle attività per determinare eventuali scostamenti e la correttezza dei risultati; comprende anche le attività di verifica e accettazione dei prodotti realizzati da parte dell’Amministrazione.
• Processi di chiusura: si attuano una volta che sono stati approvati i prodotti della fase/sprint o dopo che il progetto è stato chiuso. L’Amministrazione valida i prodotti e raccoglie le informazioni utili a gestire i passi successivi.
Nell’ambito di questi processi le attività fondamentali che devono sempre essere eseguite sono descritte nel successivo paragrafo.
3.1 Attività
Le attività descritte nel seguito sono volutamente rese indipendenti dal ciclo di vita; L’Amministrazione tenga presente che esse devono essere declinate differentemente a seconda del processo in cui sono eseguite e del ciclo di vita che in dicherà nel Piano dei Fabbisogni/Richiesta di offerta.
3.1.1 Definizione
L’attività di definizione è volta a individuare e rappresentare le esigenze dell’utente, con riferimento ai processi amministrativi e alle funzioni che ne fanno parte, al fine di giungere alla definizione della soluzione applicativa e alla sua realizzazione.
Tale attività include l’insieme delle attività svolte per identificare le richieste, tra cui in particolare a seconda del contesto:
• Formulazione e classificazione dei fabbisogni di informatizzazione, sulla base dell’analisi di contesto e dei processi in ambito. Devono essere ben esplicitati e dettagliati gli attributi e le caratteristiche migliorative che si intendono porre in essere.
• Individuazione della soluzione e studio della relativa fattibilità, considerando gli aspetti tecnici, i costi legati alla realizzazione, i benefici attesi, i rischi nonché i vincoli temporali e normativi. Oltre quindi a concretizzare ed esplicitare la scelta, bisogna concentrarsi su un’analisi di congruenza ai vincoli interni o esterni per meglio poter realizzare la soluzione proposta.
3.1.2 Analisi
L’attività 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.
L’attività può essere specializzata a seconda del contesto anche in:
• Analisi della situazione attuale: per evidenziare l’obiettivo del progetto contestualizzandolo alla situazione reale, indicare e sottolineare i principali punti di criticità, facendoli assimilare correttamente nelle varie componenti del processo, indicare dei fattori critici di successo per misurare gli elementi associati più rilevanti, raccogliere le misurazioni in riferimento alle metriche caratterizzate.
• Individuazione dei vincoli: i vincoli possono essere di diverso ordine e grado, ad esempio vincoli di tipo giuridico-normativo, vincoli tecnologici, vincoli organizzativi, vincoli procedurali, ecc.
• Analisi del rischio: individuare, classificare, gestire e monitorare i rischi di progetto, che possano compromettere il raggiungimento degli obiettivi finali.
• Analisi di impatto: analizzare in dettaglio le possibili ricadute, dal punto di vista organizzativo, informativo, tecnologico oppure sulle componenti dell’Amministrazione (struttura, procedure, risorse, prodotti, personale), relative all’attuazione della soluzione proposta.
3.1.3 Disegno
L’attività di disegno è volta a tradurre tutte le caratteristiche della soluzione in specifiche tecniche di dettaglio necessarie alla generazione dei prodotti finali.
Tale attività include l’insieme delle attività svolte per progettare le soluzioni, tra cui in particolare:
• Progettazione tecnica: contiene elementi di dettaglio relativi agli elementi hardware, software ed infrastrutturali del sistema complessivo, alle relative rappresentazioni e configurazioni, in coerenza con le esigenze tecnologiche del contesto. Particolare attenzione deve essere posta sul livello di integrazione tra le diverse componenti e sulla valutazione oggettiva, il più possibile coerente alla reale condizione, del fabbisogno tecnico-organizzativo dell’Amministrazione.
• Progettazione applicativa: viene realizzata con l’obiettivo di definire l’ambito della soluzione applicativa, il suo scopo e gli elementi software di dettaglio, inclusi moduli applicativi, ecc. La progettazione applicativa deve essere coerente con i requisiti espressi nelle fasi pregresse.
L’attività di disegno deve tener conto delle indicazioni fornite dall’Amministrazione nel documento di contesto tecnologico e applicativo allegato al Piano dei Fabbisogni o Richiesta di Offerta.
3.1.4 Realizzazione
L’attività di realizzazione è volta a generare i componenti software e la base dati che realizzano il sistema, verificando inoltre la loro correttezza e funzionalità.
Tale attività include l’insieme delle attività svolte per:
• effettuare l’implementazione del sistema, producendo il codice sorgente;
• eseguire i test e relativo codice di test;
• realizzare i prodotti di fase/sprint;
• consegnare alla gestione della configurazione i componenti realizzati e la relativa documentazione;
• aggiornare, in caso di modifiche intercorse, i prodotti delle attività precedenti;
• predisporre l’ambiente di collaudo, effettuando le opportune attività per verificarne la correttezza.
Nel corso delle attività di realizzazione il Fornitore deve adottare, ove possibile, strumenti di automazione delle suddette operazioni e fornire supporto al loro utilizzo. Tale adozione è obbligatoria nel caso in cui l’Amministrazione abbia richiesto l’applicazione della metodologia DevOps.
3.1.5 Verifica
La verifica del software realizzato è di responsabilità dell’Amministrazione.
Saranno oggetto di verifica tutti i prodotti delle attività afferenti alla singola fase di un ciclo tradizionale o sprint nel caso di ciclo agile.
La verifica comprende da parte del fornitore il supporto alla verifica del software rilasciato, la tracciatura delle anomalie per la successiva risoluzione, il supporto alla gestione degli ambienti mediante gli strumenti di integrazione e rilascio continuo (o equivalenti ad es. definizione e caricamento della base dati, installazione del software, personalizzazione del software di base, ecc), compreso il supporto alla ri-esecuzione dei test automatizzati e non.
3.1.6 Collaudo
Il collaudo del software realizzato è di responsabilità della Amministrazione.
Sono oggetto di verifica durante il periodo di collaudo tutti i prodotti di attività, sprint e/o fasi rilasciati dal fornitore in precedenza e non ancora collaudati.
A seconda del ciclo di vita vale:
• tradizionale: l’attività è eseguita nell’apposita fase di collaudo pertanto nel piano di lavoro generale (o di obiettivo) il Fornitore deve dare evidenza della sua pianificazione;
• agile: l’Amministrazione deve indicare il numero di sprint e/o la periodicità dell’esecuzione in corso d’opera e definire, al termine dell’ultimo sprint, il collaudo finale in corrispondenza del quale il Fornitore provvede alla consegna di tutti i prodotti previsti, compreso l’eventuale completamento della documentazione a supporto.
Il collaudo comprende da parte del fornitore il supporto al collaudo stesso, la rimozione delle anomalie in garanzia, il supporto alla gestione degli ambienti mediante gli strumenti di integrazione e rilascio continuo (o equivalenti ad es. definizione e caricamento della base dati, installazione del software, personalizzazione del software di base, ecc) compreso il supporto alla ri-esecuzione dei test automatizzati e non.
L’attività si conclude con l’accettazione del software.
Dopo l’accettazione sarà avviata la relativa verifica di conformità e, per esito positivo della verifica, sarà rilasciata la certificazione della corretta esecuzione del servizio relativamente ai prodotti oggetto di accettazione.
3.1.7 Documentazione
L’attività di documentazione ha la finalità di riportare all’interno di documenti ufficiali quanto illustrato nel corso delle precedenti attività, preparati secondo standard e requisiti condivisi con l’Amministrazione.
Nel caso di cicli di vita tradizionali l’attività di documentazione può essere sequenziale o parallela alle precedenti
attività in base alle fasi del relativo ciclo di vita scelto, pertanto nel piano di lavoro di obiettivo sarà data evidenza della pianificazione.
Nel caso di cicli di vita agili l’attività di documentazione dovrà essere pianificata come da indicazione dell’Amministrazione e al più al termine dell’ultimo sprint e prima del collaudo finale.
3.2 Avvio in esercizio
L’avvio in esercizio è una fase che parte dalla messa in produzione e prosegue fino al termine del periodo di osservazione.
Lo scopo è monitorare il software sviluppato/modificato dall’obiettivo per poterne verificare l’affidabilità nei primi tre mesi di esercizio. Nel corso di tale periodo il fornitore di sviluppo dovrà garantire adeguato supporto all’Amministrazione e al servizio di gestione dell’esercizio delle applicazioni per la risoluzione dei problemi e dei malfunzionamenti che devono essere risolti dal servizio realizzativo che li ha generati senza oneri aggiuntivi per l’Amministrazione.
Per i cicli di vita agile l’avvio in esercizio è monitorato a partire dall’eventuale messa in esercizio dei singoli sprint collaudati.
La fase si conclude con la valutazione finale della qualità e difettosità del software avviato in esercizio.
Dopo la valutazione sarà avviata la relativa verifica di conformità e, per esito positivo della verifica, sarà rilasciata la certificazione della corretta esecuzione del servizio relativamente ai prodotti oggetto di valutazione.
3.3 I Cicli di Vita
Nel seguito viene schematizzata l’organizzazione delle attività in base ai cicli di vita da impiegare per lo sviluppo e realizzazione nell’ambito dei servizi oggetto della fornitura.
Per i cicli di vita tradizionali è indicata in particolare la Fase in cui le attività sono eseguite, mentre nel caso del ciclo di vita agile è indicato il singolo Sprint e le successive attività da pianificare su indicazione dell’Amministrazione.
Per i criteri di uscita indicati valgono le seguenti osservazioni:
• i criteri di uscita “Attivazione”, “Approvazione” ed “Accettazione” includono anche l’accettazione e la validazione dei prodotti di ogni fase, pertanto nel Piano di lavoro deve essere data tale evidenza;
• il criterio di uscita nella “Consegna” può essere sostituito dall’approvazione di uno o più prodotti della relativa fase/sprint, qualora il responsabile dell’Amministrazione lo ritenga opportuno e comunque non implichi di per sé l’accettazione dei prodotti di fase/sprint.
Nella tabella seguente sono riepilogate le varie combinazioni.
Tabella 3.1 Fasi e attività nei cicli di vita tradizionali
Cicli tradizionali | |||||||
Ciclo Completo | |||||||
Fase | Definizione | Analisi | Disegno | Realizzazione | Collaudo | Documentazione | Avvio in esercizio |
Attività | Definizione | Analisi | Disegno | Realizzazione | Collaudo | Documentazione | Avvio in esercizio |
Criterio di Uscita | Attivazione | Approvazione | Consegna | Consegna | Accettazione | Consegna | Valutazione all’avvio |
Ridotto | |||||||
Fase | Definizione | Analisi e Disegno | Realizzazione | Collaudo | Documentazione | Avvio in esercizio | |
Attività | Definizione | Analisi | Disegno | Realizzazione | Collaudo | Documentazione | Avvio in esercizio |
Criterio di Uscita | Attivazione | Approvazione | Consegna | Accettazione | Consegna | Valutazione all’avvio | |
A Fase Unica | |||||||
Fase | Unica | Collaudo | Documentazione | Avvio in esercizio | |||
Attività | Definizione | Analisi | Disegno | Realizzazione | Collaudo | Documentazione | Avvio in esercizio |
Criterio di Uscita | Consegna | Accettazione | Consegna | Valutazione all’avvio | |||
Realizzativo1 | |||||||
Fase | Realizzazione | Collaudo | Documentazione | Avvio in esercizio | |||
Attività | Realizzazione | Collaudo | Documentazione | Avvio in esercizio | |||
Criterio di Uscita | Consegna | Accettazione | Consegna | Valutazione all’avvio | |||
Tabella 3.2 Sprint e attività nei cicli di vita agili
Cicli Agili | |||||||
Fase | Sprint | Collaudo | Documentazione | Avvio in esercizio | |||
Attività | Definizione | Analisi | Disegno | Realizzazione | Collaudo | Documentazione | Avvio in esercizio |
Criterio di Uscita | Consegna | Accettazione | Consegna | Valutazione all’avvio | |||
Gli artefatti che il Fornitore deve obbligatoriamente consegnare per ogni ciclo di vita sono indicati nel Capitolato Tecnico Speciale e devono essere ulteriormente specificati dall’Amministrazione in ragione del ciclo di vita selezionato e delle peculiarità e caratteristiche dell’intervento.
1 Nel ciclo realizzativo l’Amministrazione affida al fornitore unicamente l’attività di realizzazione (comprensiva dei test sui prodotti e/o di eventuale documentazione a corredo) ed effettua in completa autonomia tutte le fasi/attività di un ciclo completo, dalla definizione dei requisiti utente fino all’avvio in esercizio.
4 CONTENUTI DEI PRODOTTI DA REALIZZARE
Qualora per i prodotti sia previsto uno standard dell’Amministrazione, il fornitore deve utilizzare detto standard; in caso contrario il fornitore propone un proprio standard che è soggetto all’accettazione da parte dell’Amministrazione.
Per quanto attiene la documentazione il fornitore deve garantire la qualità in termini di:
• accuratezza
• attualità
• coerenza
• completezza
• consistenza
Per maggiori dettagli su queste caratteristiche si rinvia alla ISO 25024.
Tutti i documenti devono contenere nelle prime pagine almeno le seguenti informazioni:
• Area
• Estremi del contratto
• Nome del prodotto
• Data consegna
• Numero della versione
• Nominativo della persona che ha redatto il documento
• Nominativo della persona che ha validato il documento
• Nominativo della persona che ha approvato il documento
• Numero di pagine
• Nome del file, che deve rispettare l’eventuale standard dell’Amministrazione
• Tabella riepilogativa delle revisioni, indicando il numero della revisione, le parti modificate/aggiunte, la descrizione della modifica e la relativa data.
Il fornitore deve aggiornare i documenti relativi:
• al Piano della Qualità Specifico di Contratto Esecutivo e ai Piani della Qualità di Obiettivo, a seguito di significativi cambiamenti di contesto in corso d’opera o, comunque, su richiesta della Amministrazione. Essi devono essere riconsegnati aggiornati a livello di intero documento, e non per le sole parti variate, e dovrà essere possibile individuare le modifiche effettuate.
• al parco applicativo, alla consegna di qualsiasi intervento/obiettivo indipendentemente dal ciclo di vita adottato;
• a una singola applicazione del parco applicativo, alla consegna di qualsiasi intervento/obiettivo relativo all’applicazione indipendentemente dal ciclo di vita adottato;
• al singolo obiettivo durante il ciclo di vita dell’obiettivo stesso e i loro contenuti dovranno essere integrati, organici e coerenti con i contenuti degli altri prodotti o applicazione previsti dal ciclo di vita utilizzato. Inoltre i documenti di obiettivo dovranno essere redatti ad un livello di completezza tale da:
o consentire l’approvazione da parte della Amministrazione e dell’utente (ove previsto);
o consentire lo svolgimento della successiva fase/sprint;
o 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 rilascio ufficiale di prodotto (documenti, software, ecc) così definito in base al ciclo di vita:
• tradizionale: il rilascio ufficiale è la consegna di un prodotto che concorre al raggiungimento di una milestone definita nel piano di lavoro generale o di obiettivo;
• agile: il rilascio ufficiale è la consegna di un prodotto che sarà sottoposto al prossimo collaudo e/o al collaudo definitivo (cfr. 3.1.6).
Essa deve contenere almeno le seguenti informazioni:
• mittente/i
• destinatario/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:
o percorso del Portale della Fornitura in cui sono stati pubblicati o del repository per i prodotti software
o codice del prodotto/documento, secondo lo standard della Amministrazione
o versione e data
o tipo documento
• per le consegne relative ad attività progettuale è necessario allegare l’elenco dei prodotti previsti dal ciclo di vita adottato evidenziando per ogni prodotto:
o la non applicabilità della consegna
o se è oggetto della consegna in corso
o se è stato oggetto di una consegna precedente.
4.2 Piano della Qualità Generale di Lotto
Il piano della Qualità Generale di Xxxxx è il documento redatto dal Fornitore che contiene indicazioni relative al governo dell’intero Lotto dell’Accordo Quadro, da cui dovrà derivare l’impostazione di ciascun Contratto Esecutivo.
Tale piano contiene, tra l’altro, la descrizione delle modalità operative, l’indicazione dei referenti del Lotto dell’AQ, le soluzioni migliorative offerte per ciascun servizio e gli strumenti di governo.
La versione generale del piano deve essere consegnata alla stipula dell’AQ e sottoposto all’approvazione di Consip S.p.A.
Il piano della qualità generale:
• fornisce lo strumento per collegare i requisiti specifici dei servizi contrattualmente richiesti con le procedure generali del sistema qualità del fornitore già esistenti;
• esplicita le disposizioni organizzative e metodologiche adottate dal fornitore, allo scopo di raggiungere gli obiettivi tecnici e di qualità contrattualmente definiti;
• dettaglia i metodi di lavoro messi in atto dal fornitore, facendo riferimento a procedure relative al proprio sistema, e per ciò descritte nel manuale qualità, o a procedure sviluppate per lo specifico contratto, a supporto delle attività in esso descritte, in questo caso da allegare al piano;
• garantisce 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, il fornitore, il Amministrazione, l'eventuale organismo di ispezione accreditato dall'Amministrazione.
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,
• 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. Governo della fornitura
(Contiene l’indicazione dei referenti dell’Accordo Quadro, delle soluzioni migliorative offerte per ciascun servizio, del monitoraggio e del program management dell’Accordo Quadro).
5. Modalità di sviluppo software
(Descrive le metodologie, linee guida, standard di sviluppo software, meccanismi di integrazione e rilascio continuo e relativi metodologie e standard di redazione della documentazione di progetto e servizio; modalità, metodologie, banche dati e strumenti per la stima ed il dimensionamento dei progetti applicativi e formazione dei gruppi di peer review e four eyes principle; repository delle best practices e use case di riferimento; cruscotto dei tempi ottimali di sviluppo, ecc.)
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 e degli strumenti che si intendono adottare per la stesura del codice sorgente, dei commenti interni al codice sorgente, al controllo del rispetto dei livelli di qualità del sw, ai cataloghi degli oggetti in riuso, alla convalida della tecnologia, linee guida per il prototipo e campione tecnico, ecc.).
7.3. Progettazione ed esecuzione dei test
(Riporta le linee guida, gli strumenti e i principi ispiratori per la progettazione ed esecuzione delle sessioni di test sia funzionali sia non funzionali, gestione delle violazioni, non conformità rispetto al quality gate definito e alle linee guida del Piano Triennale, automatizzazione test di non regressione, livello di automazione test ripetitivi o standardizzati, ecc. ).
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à sulla base dell’allegato livelli di servizi e dell’offerta migliorativa. Per questo è necessario definire:
• Gli indicatori di qualità della fornitura e dei servizi aggiornati con i livelli migliorativi dell’offerta dell’aggiudicatario e gli aggiornamenti in corso di contratto che permettono il miglioramento del livello qualitativo;
• gli strumenti di ausilio e di supporto per ogni indicatore o metrica o cruscotto di analisi e sintesi;
• i valori limite ritenuti accettabili con cui confrontare le misure degli attributi di qualità e dei livelli di servizio effettuate sulla base di indicatori/metriche).
8.2. Procedura per la valutazione della qualità dei prodotti
(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).
8.3. Procedura per la valutazione della qualità del software
(Definisce la procedura per la valutazione della qualità del sw realizzato dal fornitore. La procedura deve esplicitare:
• figure professionali responsabili della verifica della qualità software;
• modalità di misura o di rilevamento dei dati, strumenti a supporto e di ausilio;
• 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 con Riserva / Non Approvazione di un prodotto considerando i risultati delle misure relative ai singoli attributi di qualità associati al prodotto associato 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'Amministrazione).
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.3 Piano della Qualità Specifico di Contratto Esecutivo
Per ciascun Contratto Esecutivo il fornitore deve produrre un Piano della Qualità personalizzato sull’ambiente tecnologico e sugli obiettivi dell’Amministrazione. Il piano è soggetto all’approvazione dell’Amministrazione.
Tale documento deve essere prodotto a partire dal Piano della Qualità Generale dell’AQ e riportare le eventuali deroghe alle regole ereditate, la declinazione specifica per l’obiettivo del/i ciclo/i di vita selezionati2 e la necessità di eventuale supporto da parte di terzi.
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 da quanto previsto nel Piano della Qualità Generale. Nel caso in cui per un determinato capitolo non ci siano differenze rispetto al Piano di Qualità Generale dell’AQ occorre solo riportare il riferimento al suddetto piano.
1. Descrizione specifica del Contratto Esecutivo
2. Scopo del piano della qualità
(elenca le motivazioni e le peculiarità dell’obiettivo per le quali è richiesto il documento)
3. Documenti applicabili e di riferimento
4. Ruoli e Responsabilità di riferimento
5. Cicli di vita2
(Descrive i cicli di vita, l’eventuale deroga a quello previsto dal piano di qualità generale dell’AQ, le fasi/sprint in cui sono suddivisi, i criteri di uscita, l'insieme della documentazione da produrre e eventualmente le attività richieste al Fornitore per il collaudo/accettazione)
6. Metodi, tecniche e strumenti specifici dell’obiettivo
(Contiene l'indicazione dei metodi, delle tecniche, degli strumenti, degli standard di prodotto specifici dell'obiettivo solo se diversi da quelli descritti nel Piano della Qualità generale dell’AQ)
7. Indicatori di qualità specifici dell'obiettivo
(Contiene gli attributi di qualità con riferimento alle metriche, ai valori limite -Valore di soglia- definiti negli indicatori di qualità e gli eventuali ulteriori indicatori specifici per il Contratto Esecutivo, se diversi da quelli descritti nel Piano della Qualità generale dell’AQ)
8. Riesami, verifiche e validazioni
(Contiene l'elenco dei controlli da effettuare (riesami, test, verifiche e validazioni, valutazioni, ecc.) per l'obiettivo e le modalità di esecuzione dei controlli comprensive sia degli strumenti da utilizzare e sia della modulistica di rendicontazione dei risultati, se diversi da quelli descritti nel Piano della Qualità generale).
4.4 Piano della Qualità di obiettivo
Il fornitore deve produrre questo documento solo quando l’obiettivo ha caratteristiche specifiche o va in deroga a regole inserite nel Piano della Qualità Specifico ovvero quando prevede un ciclo di vita diverso da quelli previsti nel documento citato, ovvero quando l’obiettivo necessita del supporto di terzi.
Nella redazione del piano il fornitore terrà come guida lo schema di riferimento del Piano di Qualità Specifico, evidenziando sia le caratteristiche qualitative relative a specifici progetti e sia le eventuali deroghe.
Nel caso in cui, per un determinato capitolo, non ci siano differenze rispetto al Piano di Qualità Specifico occorre
2 in Contratti Esecutivi che comprendono più progetti di sviluppo, l’Amministrazione può scegliere cicli di vita diversi sui singoli progetti.
solo riportare il riferimento al suddetto piano.
4.5 Piano di Lavoro Generale
Per ciascun Contratto Esecutivo il Fornitore deve redigere un piano di Lavoro Generale composto dalle seguenti sezioni:
• Piano di progetto.
• Piano di lavoro dei servizi continuativi.
• Piano delle attività periodiche.
PIANO DELLE ATTIVITA’ PROGETTUALI
La sezione deve contenere l’elenco degli obiettivi, delle attività, degli output previsti, delle tempistiche, degli strumenti proposti e delle risorse impegnate per lo svolgimento delle attività progettuali individuate dall’Amministrazione e commissionate al fornitore.
Il piano delle attività progettuali deve essere mantenuto aggiornato durante tutto l’arco temporale del Contratto, a carico del fornitore.
Nel caso in cui per le attività sia previsto l’utilizzo di risorse per cui è necessario consegnare i CV, questi ultimi dovranno essere forniti nell’ambito di questo piano.
In particolare, il Piano deve riportare:
• Organizzazione delle fasi e/o sprint in cui è organizzato il lavoro;
• Elenco delle attività con relativa descrizione e erogazione nelle fasi/sprint;
• Orario di servizio ordinario, ore di estensione e di reperibilità previste ed effettive;
• Eventuali prodotti delle singole attività;
• Impegno in base alla metrica del servizio, stimato ed effettivo;
• Nominativo del referente di ogni attività;
• Un gantt delle attività, contenente tra le altre cose:
o Date di inizio e fine, previste ed effettive, di ogni fase/sprint;
o Date di inizio e fine, previste ed effettive, di ogni attività;
o Date di consegna, previste ed effettive, di ogni prodotto.
o Date di consegna, previste ed effettive, dei report di conformità alle soluzioni proposte in offerta tecnica (cfr. 4.20);
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 ri-pianificazione, scostamento eventuale delle date, dell’impegno e del volume;
• Xxxxxxx/criticità e relative azioni da intraprendere e/o intraprese.
Per la parte di gestione e controllo della fatturazione, fermo restando che il Fornitore dovrà rendere disponibili tutti i dati di rendicontazione in formato elettronico all’interno del Portale della Fornitura, per ogni tipologia di servizio nel piano dovranno essere evidenziati gli stati di avanzamento propedeutici alla fatturazione, che potrà avvenire a seconda della modalità di erogazione:
• a corpo o progettuale: al raggiungimento di milestone pianificate e condivise con l’Amministrazione contraente; nel caso di cicli agili potranno essere rendicontate le attività completate dal fornitore relative a sprint conclusi e collaudati positivamente dall’Amministrazione;
• a consumo: periodicamente su base mensile da definire con l’Amministrazione.
PIANO DI LAVORO DEI SERVIZI CONTINUATIVI
Il piano di lavoro dei servizi continuativi, distinto per servizio e, se del caso, per una o più applicazioni, deve contenere il dettaglio delle attività previste nel mese in apertura corredate dalla relativa tempificazione e, laddove previsto dal Piano dei Fabbisogni/Richiesta d’Offerta, 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 rilasci in esercizio degli obiettivi;
• eventuali prodotti delle singole attività;
• Impegno in base alla metrica del servizio, stimato ed effettivo, suddiviso per figura professionale (ove applicabile);
• nominativo del referente di ogni attività.
• un gantt delle attività, contenente:
o date di inizio e fine, previste ed effettive, di ogni attività
o date di consegna, previste ed effettive, di ogni prodotto.
o date di consegna, previste ed effettive, dei report di conformità alle soluzioni proposte in offerta tecnica (cfr. 4.20);
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.
Il piano dovrà essere corredato del relativo Rendiconto Risorse, come meglio specificato al paragrafo 4.9.
PIANO DELLE ATTIVITA’ PERIODICHE
Il piano delle attività periodiche deve contenere il dettaglio delle attività richieste dal Piano dei Fabbisogni/Richiesta d’Offerta e/o offerte migliorative che prevedono la consegna di deliverable nel corso della fornitura: pertanto non sono comprese le attività già presenti negli altri piani di lavoro (piano di presa in carico e subentro, piano di lavoro di obiettivo, piano di lavoro dei servizi continuativi e piano di trasferimento know-how).
Nel Piano dovranno essere esplicitate le risorse professionali ed il loro impiego nei servizi, le attività, i tempi, gli strumenti offerti e quanto necessario a rendere evidente alla Amministrazione l’applicazione di quanto richiesto dal Piano dei Fabbisogni/Richiesta d’Offerta e relative appendici.
Nel caso in cui per le attività sia previsto l’utilizzo di risorse per cui è necessario consegnare i Curricula Vitae, quest’ultimi dovranno essere forniti nell’ambito di questo Piano.
Coerentemente con le caratteristiche offerte dal fornitore e concordate con la Amministrazione, il Piano riporterà:
• codice, nome, descrizione delle attività dichiarate in offerta tecnica e/o richieste;
• le applicazioni d’interesse (ove applicabile);
• prodotti delle singole attività;
• nominativo dei referenti delle attività;
• puntamento ai paragrafi del Piano dei Fabbisogni/Richiesta d’Offerta in cui è descritta l’attività (ove applicabile);
• impegno in gp, stimato ed effettivo, suddiviso per mese e figura professionale, ove applicabile;
• il gantt delle attività, contenente:
o date di inizio e fine, previste ed effettive, delle singole attività;
o date di consegna, previste ed effettive, dei singoli prodotti;
o date di consegna, previste ed effettive, dei report di conformità alle soluzioni proposte in offerta tecnica (cfr. 4.20);
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, preventivamente concordate con la Amministrazione, scostamento eventuale delle date, dell’impegno e del volume;
• xxxxxxx/criticità e relative azioni da intraprendere e/o intraprese.
Allegato al piano dovrà essere presente, ove necessario, il Rendiconto Risorse, come meglio specificato al paragrafo 4.9.
4.6 Piano di Lavoro di obiettivo
Il fornitore deve redigere un piano di lavoro di obiettivo con il dettaglio delle attività di ogni singola fase/sprint del singolo obiettivo/progetto, la relativa tempificazione e le stime di impegno.
L’aggiornamento dello stato di avanzamento delle attività, su richiesta della dell’Amministrazione, non determina una nuova versione del documento. Viceversa il fornitore deve consegnare una nuova versione in coincidenza dei rilasci da sottoporre a collaudo (cfr. 3.1.6).
Coerentemente con le caratteristiche dei singoli obiettivi, con il ciclo di vita definito e con lo stato temporale (piano iniziale o aggiornamento), il Piano di lavoro di obiettivo riporta:
• il nominativo del capo progetto;
• codice, nome, descrizione dell’obiettivo e, se significativo, relativo stato (sospeso, cancellato, ecc.);
• ciclo di vita adottato;
• dimensione dell’impegno stimato all’avvio con esplicitazione dei dati oggettivi di riferimento e delle tecniche di stima adottate nonché il grado di incertezza3 e i fattori che ne determina l’ampiezza;
• dimensione dell’impegno misurato; nel caso di obiettivi misurati in:
o Giorni Persona: l’impegno essere suddiviso per fase/sprint e per figura professionale, con il riferimento alle componenti riusate, all’efficienza e all’efficacia raggiunta con gli elementi migliorativi dell’offerta tecnica.
o Punti Funzione: deve essere esplicitata la modalità di calcolo (manuale / automatica – i tool di supporto, i dati di controllo), il revisore certificato IFPUG, il riuso delle componenti, il rispetto dei livelli di qualità minimi, la produttività4 rilevata;
• il gantt delle attività, contenente:
3 Nel caso di metodologia agile la stima dell’impegno si baserà sulle informazioni disponibili al primo sprint
4 La metrica di produttività verrà definita a seconda del ciclo di vita scelto
o elenco delle fasi/sprint e delle singole attività con relative date di inizio e fine, previste ed effettive;
o prodotti di fornitura delle singole fasi/sprint e prodotti intermedi delle singole attività, anche semilavorati, con relative date di consegna, previste ed effettive.
o elenco dei report/check-list di conformità (cfr. 4.20) con relative date di consegna, previste ed effettive;
• il gantt contiene anche l’attività di approvazione dei prodotti di fase/sprint, ove prevista, riportando le date di inizio e fine concordate con la Amministrazione. Pertanto le date finali delle varie fasi/sprint devono essere comprensive anche dell’eventuale tempo di approvazione dei prodotti;
Il piano contiene anche la sezione stato di avanzamento in cui sono riportate le informazioni:
• percentuale di avanzamento delle singole attività;
• data a cui si riferisce lo stato di avanzamento;
• razionali di ripianificazione;
• scostamento eventuale delle date, dell’impegno e del volume;
• xxxxxxx/criticità e relative azioni da intraprendere e/o intraprese.
Per gli obiettivi misurati con la metrica “giorni/persona” il piano di lavoro per obiettivo dovrà essere corredato del Rendiconto Risorse, come meglio specificato al paragrafo 4.9.
4.7 Piano di resa in carico e Subentro
Il piano di presa in carico e Subentro, distinto per servizio e, se del caso, per una o più applicazioni, deve contenere il dettaglio delle attività che devono essere espletate ad inizio contratto, la relativa tempificazione e le stime di impegno.
In particolare dovranno essere esplicitate le risorse professionali ed il loro successivo impiego nei servizi, le attività, i tempi, gli strumenti offerti e quanto necessario al:
• subentro: ossia alla completa presa in carico di tutti i servizi (se richiesto);
• presa in carico: predisposizione degli ambienti, degli strumenti, delle soluzioni, dei sistemi e delle migliorie offerte (obbligatorio).
Per le risorse impiegate nei servizi a carattere continuativo e per tutti i referenti dovranno essere forniti i relativi Curricula Vitae.
Coerentemente con le caratteristiche offerte dal fornitore e concordate con la Amministrazione, il Piano riporterà:
• Xxxxxx, nome, descrizione delle attività di presa in carico e di subentro;
• prodotti delle singole attività;
• nominativo dei referenti delle attività;
• puntamento ai paragrafi del Piano dei Fabbisogni/Richiesta d’Offerta e relative appendici in cui l’attività è richiesta;
• impegno in gp, stimato ed effettivo, suddiviso per mese e figura professionale, ove applicabile;
• il gantt delle attività, contenente:
o date di inizio e fine, previste ed effettive, delle singole attività;
o date di consegna, previste ed effettive, dei singoli prodotti;
o date di consegna, previste ed effettive, dei report di conformità alle soluzioni proposte in offerta tecnica;
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, preventivamente concordate con la Amministrazione, 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 specificato al paragrafo 4.9.
4.8 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 deve avere i seguenti contenuti:
• 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 applicazione;
• modalità di estrazione, verifica e consegna di tutti gli oggetti software al fine di permettere la predisposizione di un ambiente operativo parallelo;
• modalità di estrazione, verifica e consegna di tutti i documenti previsti dal presente contratto;
• predisposizione di quadri di sintesi architetturali e funzionali a livello generale;
• 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/applicazione con l’esposizione chiara delle soluzioni proposte ed attuate durante la fornitura;
• presentazione delle modalità organizzative, degli obiettivi e delle risorse impiegate per il funzionamento della test factory.
Inoltre, coerentemente con le caratteristiche del know how da trasferire, il Piano riporta:
• codice, nome, delle attività di trasferimento di know how;
• prodotti delle singole attività;
• impegno in gp, stimato ed effettivo, ove applicabile, suddiviso per mese e figura professionale;
• un gantt delle attività, contenente:
o date di inizio e fine, previste ed effettive, di ogni attività;
o 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 specificato al paragrafo 4.9.
4.9 Rendiconto risorse
Il Rendiconto delle risorse è un riepilogo, analitico e sintetico, che dovrà contenere per ogni servizio/attività per cui è previsto:
per la parte analitica:
• elenco del personale impiegato dal Fornitore con l’indicazione del profilo professionale ricoperto e dell’eventuale relativa certificazione richiesta;
• dettaglio in ore del tempo impiegato da ciascuna risorsa per ogni attività svolta, specificando l’eventuale estensione o reperibilità (ove applicabile);
per la 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à definito dall’Amministrazione);
• 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.10 Report aggiornamento baseline
È il documento in cui sono contenute le informazioni relative al conteggio dei punti funzione affidati al servizio di Manutenzione Correttiva sw pregresso.
Il report descrive lo stato attuale delle baseline.
Il report deve riportare almeno le seguenti informazioni:
• Baseline di partenza;
• Baseline aggiornata.
In particolare, devono essere contenute le seguenti informazioni:
• Data
• Eventi che hanno determinato l’aggiornamento
4.11 Report Indicatori di qualità
È il documento che fornisce i risultati della rilevazione degli indicatori di qualità relativi al Contratto Esecutivo, esclusi gli indicatori di qualità eventualmente già rendicontati nel Rapporto Indicatori di qualità di obiettivo.
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 “Livelli di Servizio” e migliorata 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 in automatico 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 dell’indicatore
• Esito
• Se è previsto un indice di prestazione
• Aspetto da valutare
• Unità di misura
• Periodo di riferimento
• Dati da rilevare
• Regole di campionamento
• Formula
• Fonte dei dati
• Frequenza di misurazione
• Azioni contrattuali
• Eccezioni
Deve essere prevista una sezione con l’andamento degli indicatori nel tempo e una sezione di valutazione dei risultati raggiunti relativamente alla qualità del software.
4.12 Report Indicatori di qualità di obiettivo
È il documento che riporta le informazioni relative al rispetto dei livelli di servizio attraverso la misurazione degli indicatori di qualità raggiunti con l’obiettivo.
Il documento deve prevedere dei dati analitici e dei dati di sintesi. Per la parte analitica, per ciascun indicatore, deve contenere almeno:
• La scheda dell’indicatore così come prevista nell’appendice “Livelli di Servizio”;
• il periodo di riferimento della misura;
• riferimento agli strumenti di misura utilizzati;
• i dati rilevati;
• il valore rilevato dell’indicatore di qualità;
• (eventuale) scostamento dal valore di soglia;
• (eventuale) razionale di scostamento dai valori di soglia e tempi di ripristino
Nel caso degli indicatori relativi alla qualità del codice, è necessario allegare al documento Rapporto indicatori di qualità di obiettivo i Report prodotti con il tool utilizzato per la verifica della qualità del software. Tali report costituiranno parte integrante del documento.
La parte sintetica deve popolarsi in automatico 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 dell’indicatore
• Esito
• Se è previsto un indice di prestazione
• Aspetto da valutare
• Unità di misura
• Periodo di riferimento
• Dati da rilevare
• Regole di campionamento
• Formula
• Fonte dei dati
• Frequenza di misurazione
• Azioni contrattuali
• Eccezioni
4.13 Specifiche requisiti
È un documento che contiene la descrizione dei requisiti, funzionali e non, emersi nell’attività di definizione delle esigenze utente.
È un documento di obiettivo, redatto secondo lo standard previsto dalla Amministrazione, applicabile per i cicli di vita tradizionali.
Qualora per l’obiettivo non sia richiesta da parte dell’Amministrazione la realizzazione del prototipo e/o del campione tecnico nel documento specifiche dei requisiti deve essere formalizzato il motivo.
4.14 Product Backlog
Product Backlog rappresenta la lista ordinata dei requisiti relativi ad un prodotto sulla base di una priorità definita in relazione alle esigenze utente, al rischio, alle date in cui devono essere realizzati.
4.15 Sprint Backlog
Lo Sprint Backlog nei cicli agili è il documento che contiene la lista di storie/funzionalità che il team di sviluppo dovrà rilasciare nel corso dello sprint successivo. La lista viene definita selezionando in ordine di priorità una quantità di storie/funzionalità dal Product Backlog tale da saturare la capacità temporale e produttiva dello sprint.
4.16 Specifiche funzionali
È un documento che contiene in modo completo e esaustivo l’analisi dei requisiti sia relativamente ai processi ed alle modalità con cui tali processi risulteranno visibili agli utenti finali, sia al disegno concettuale dei dati secondo il modello relazionale, sia per quanto riguarda gli aspetti non funzionali (architettura, sicurezza, accessibilità, vincoli, prestazioni, ecc.), sia alla documentazione delle interfacce (includere esempi di layout delle principali schermate utente, ecc.), sia nei casi in cui è previsto l’utilizzo di un prototipo.
Il livello di completezza richiesto deve essere tale da:
• consentire la produzione del Piano di test senza necessità di ulteriori approfondimenti;
• consentire la stima in Punti Funzione del volume di software da sviluppare e/o da modificare;
È un documento di obiettivo, redatto secondo lo standard previsto dalla Amministrazione, applicabile per i cicli di vita tradizionali.
4.17 Disegno di dettaglio
Il documento contiene la descrizione dettagliata della modalità tecniche con cui le funzionalità sono trasformate ed organizzate in moduli strutturati.
È compresa nel disegno di dettaglio la documentazione del disegno logico e fisico dei dati, inoltre per i vari moduli, devono essere trattati, ad esempio:
• descrizione delle funzioni svolte
• tipologia (applicazione, servizio, procedura, batch, ecc.)
• indicazioni sulla riutilizzabilità
• parametri scambiati con altri moduli
• parametri di attivazione
• accessi agli archivi/base dati
• controlli e diagnostica
• algoritmi di calcolo.
Per quanto riguarda il disegno logico dei dati, la tecnica di rappresentazione può variare in funzione del DBMS utilizzato.
In ogni caso dovranno essere prodotte le matrici d’uso degli archivi/basi dati da parte dei moduli software.
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.
4.18 Disegno dell’architettura
Il documento contiene la descrizione complessiva dell’architettura del sistema, costituita dalle parti che lo costituiscono e dalle relazioni tra queste.
Il Fornitore deve riportare nel documento tutti gli elementi di progettazione e organizzare le specifiche di disegno architetturale secondo più viste (es. fisica, logica, software, di rete, di processo) e riferirle a scenari trasversali che ne illustrano i legami. Deve inoltre indicare l’aderenza alle linee guida e alle indicazioni specifiche del contesto tecnologico dell’Amministrazione (cfr. 3.1.3).
È un documento di obiettivo che nel caso dei cicli agili viene formalizzato nel corso della prima attività di documentazione utile (cfr. 3.1.7).
4.19 Re-design architetturale (migrazione al Cloud)
Il documento contiene la descrizione dettagliata della modalità tecniche con cui le funzionalità saranno trasformate ed organizzate nel processo di migrazione al Cloud.
Con riferimento ai criteri e requisiti di migrazione, stabiliti nella Roadmap di Migrazione e nella Scheda di Assessment fornita dall’Amministrazione, il Fornitore definisce:
• La nuova architettura tecnica complessiva del sistema in ottica cloud
• I servizi e le componenti sostituite/integrate con servizi cloud-native
• L’architettura dei servizi/moduli/componenti esposti dall’applicazione È un documento di obiettivo.
4.20 Report/Check-list di conformità
Rientrano in questa tipologia i documenti contenenti una lista di quesiti e/o attività da verificare ai fini di valutare
l’adeguatezza, la coerenza e l’aderenza rispetto ad ambiti specifici quali:
• le soluzioni proposte in offerta tecnica, anche per gli aspetti migliorativi, con particolare riferimento ai criteri trasversali;
• la strategia di Migrazione al Cloud e la conformità alle specifiche tecniche del Cloud Service Provider;
• i requisiti non funzionali (performance, sicurezza, compatibilità ecc…);
• i requisiti tecnologici/organizzativi/normativi.
Per ciascun report/check-list specifica di ogni ambito il Fornitore deve provvedere alla predisposizione -a partire da indicazioni e/o modelli dell’Amministrazione- e alla compilazione e consegna nel corso delle attività di erogazione dei servizi, dandone evidenza nei piani di lavoro.
A ciascun quesito può essere associato un peso che ne determina l’incidenza sulla valutazione finale.
4.21 Codice sorgente
Per codice sorgente si intende genericamente l’insieme degli oggetti software, realizzati o sottoposti a manutenzione, che sono soggetti ad esecuzione da parte di un compilatore (o analogo strumento di “program preparation”) o di un interprete (es. “job control program”, “query manager”), a titolo esemplificativo e non esaustivo quindi:
• programmi/applicazioni/app mobile/servizi
• 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 manualistica on-line, nonché l’eventuale codice di test e collaudo.
Il codice sorgente dovrà comprendere anche il codice per la compilazione (ove possibile) e le configurazioni degli strumenti per l’integrazione e rilascio continuo.
Tale codice dovrà comprendere:
• procedura di installazione (setup applicazione e/o patch)
• procedura di disinstallazione
• parametri di configurazione dell’ambiente su cui l’applicazione si deve installare.
4.22 Piano di Test
Il Piano di Test è un documento che accompagna ogni obiettivo lungo tutto il ciclo di vita, ed è pertanto un documento che si evolve nel tempo.
È un documento di obiettivo che nel caso di ciclo di vita:
• tradizionale: viene predisposto in fase di raccolta dei requisiti ed evolve per raffinamento nelle fasi successive;
• agile: viene costruito in maniera incrementale sulla base dei singoli sprint; i test sono eseguiti in sinergia al personale dell’Amministrazione, raccolti nei vari sprint e formalizzati nel corso della prima attività di documentazione utile(cfr. 3.1.7).
Il Piano di test 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.
4.23 Prototipo
La prototipazione assume aspetti diversi in funzione delle caratteristiche dei singoli obiettivi ed è utilizzata per molteplici scopi quali la verifica della fattibilità tecnica, una migliore comprensione dei requisiti e delle funzionalità e, laddove necessario, l’esecuzione di test integrati complessi.
Si può fare riferimento alle due casistiche riportate di seguito:
Caso I: il prototipo viene prodotto e adoperato per chiarire, validare e verificare la fattibilità dei requisiti di dettaglio da parte dell’utente.
Tale prototipazione deve comprendere:
• I layout delle interfacce di colloquio
• Il percorso di navigazione.
Caso II: il prototipo rappresenta la base di costruzione del sistema. In tal caso si tratta di un modello che contiene le principali caratteristiche tecniche del prodotto e può essere rappresentato dal cosiddetto campione tecnico ossia attraverso la realizzazione di una funzionalità completa, adottando gli strumenti e l’architettura previsti per un dato obiettivo.
È un prodotto di obiettivo, applicabile per i cicli di vita tradizionali in quanto nei cicli di vita agile, per definizione, ciascuno sprint comporta la realizzazione di un campione tecnico potenzialmente rilasciabile.
4.24 Documentazione utente
La documentazione utente, rivolta all’utente finale delle applicazioni, è composta dal Manuale utente e dall’help on line (rilasciato con il codice sorgente).
È una documentazione di applicazione. Manuale utente
Il manuale utente deve fornire una descrizione generale dell’applicazione e una guida operativa all’utilizzo delle singole funzionalità utilizzabili.
La descrizione deve contemplare:
• la tipologia di utenza cui è destinata e le funzioni abilitate per ciascuna tipologia;
• gli eventuali flussi di dati scambiati con altri sistemi informativi o con specifiche tipologie di utenze;
• le modalità di attivazione e chiusura della “sessione di lavoro”;
• descrizione delle funzioni e della navigazione tra di esse;
• la spiegazione dettagliata dell’uso delle singole funzioni di interfaccia utente (comprensiva della funzione di richiamo dell’help);
• la descrizione degli algoritmi di calcolo utilizzati;
• la descrizione dei contenuti degli output della applicazione (es. stampe).
La descrizione delle funzionalità disponibili deve essere completa dell’elenco di tutti i codici d’errore previsti, della messaggistica ad essi associata e delle azioni da intraprendere a fronte di ciascuna segnalazione.
Nel caso in cui l’applicazione preveda un utilizzo diretto dei dati da parte dell’utente, deve essere inserita anche la descrizione dettagliata della struttura dei dati interessati.
Help on line
Tutte le applicazioni interattive devono prevedere le funzioni di help on line.
4.25 Manuale di gestione applicativo
Il Manuale di gestione applicativo è lo strumento necessario alle strutture preposte all’installazione ed esercizio dell’applicazione.
È un documento di applicazione.
È un manuale rivolto a personale tecnico. Tale manuale dovrà essere corredato di uno schema riepilogativo contenente informazioni anagrafiche relative all’applicazione, tra le quali la dimensione e tipologia del DB, la dipendenza con altre applicazioni, i modelli di interfaccia, i tool utilizzati per lo sviluppo, ecc.
Per quello che riguarda gli ambienti di collaudo ed esercizio il documento dovrà esplicitare i parametri di personalizzazione dei prodotti, le modalità di attuazione dei livelli di protezione dei dati, le modalità di accesso al sistema e alle transazioni, le soluzioni tecniche necessarie alla realizzazione di tali modalità.
4.26 Manuale di gestione infrastruttura e servizi cloud
Il Manuale di gestione, strumento necessario alle strutture preposte all’installazione ed esercizio dell’infrastruttura e servizi cloud, è rivolto a personale tecnico e dovrà essere eventualmente integrato con le opportune informazioni relative al software realizzato/modificato.
4.27 Piano di adeguamento degli ambienti
Il Piano di adeguamento degli ambienti è il documento di supporto alle attività di installazione e configurazione in ambiente di test, collaudo o esercizio.
È un documento di obiettivo.
Tale documento viene strutturato in tre sezioni relative rispettivamente all’ambiente di test, collaudo ed esercizio. Tale documento deve contenere almeno le seguenti informazioni:
• il responsabile del change;
• descrizione di tutte le attività necessarie alla predisposizione dell’ambiente di collaudo/esercizio/correttiva (con l’evidenza delle date di inizio e di completamento) e dei relativi referenti (sia tecnici che applicativi);
• qualificazione del progetto e degli elementi di configurazione coinvolti (DB, utenze, servizi cloud e/o Application Server, directory, ecc.);
• specifica delle istruzioni operative evidenziando i riferimenti ai manuali di gestione dell’applicazione e dei server.
4.28 Documentazione dati
La documentazione dati contiene la descrizione e la rappresentazione della base dati di un’applicazione, esplicita eventuali collegamenti con la base dati di altre applicazioni o le regole tecniche con cui l’applicazione scambia flussi informativi di dati con l’esterno.
È un documento di obiettivo.
La documentazione dati è obbligatoriamente articolata nelle seguenti componenti:
• Modello dei dati;
• Dizionario dati.
Modello dei dati
Il modello dei dati è composto da:
• Glossario che dovrà contenere:
o descrizione di tutti gli oggetti degli schemi concettuali;
o descrizione di tutti gli oggetti degli schemi logici;
o mapping schema concettuale- logico.
• schema concettuale e logico su tool di modellazione dati;
I modelli dati dovranno comprendere:
• diagramma E/R;
• nome e descrizione delle Entità;
• nome e descrizione degli Attributi;
• mapping Entità/Tabella e Attributo/Xxxxxxx.
• mapping concettuale-logico: nel formato del tool di modellazione dati definito dall’Amministrazione;
• schema fisico: nel formato del tool di modellazione dati definito dall’Amministrazione;
• le informazioni contenute nel “Dizionario Dati” inserite negli opportuni campi dei DBMS. Lo schema concettuale dovrà contenere le seguenti informazioni:
• schema grafico rappresentante le entità e la relazione tra esse intercorrenti;
• nome (e/o codice) e descrizione del significato delle entità;
• nome (e/o codice) e descrizione del significato delle relazioni intercorrenti tra le entità;
• nome (e/o codice) e descrizione del significato degli attributi appartenenti alle singole entità e relazioni. Lo schema logico dovrà contenere:
• Schema grafico rappresentante le relazioni;
• Vincoli di integrità;
• Relazioni fondamentali;
• Relazioni associative;
• Chiavi primarie e secondarie.
Il mapping concettuale-logico dovrà contenere la corrispondenza tra le entità e associazioni descritte nello schema concettuale e le relazioni descritte nello schema logico.
Lo schema fisico dovrà contenere:
• indicazione del metodo di accesso utilizzato;
• bloccaggio di ciascun data-set;
• clausole di storage;
• descrizione dei dati interni del DBMS (tabelle, indici, ecc.) che realizzano la struttura prevista.
Dizionario dati
Il dizionario dati dovrà contenere:
• nome della tabella
• nome del campo
• indicazione della chiave primaria
• indicazione di eventuale chiave esterna
• tipo e dimensione del campo (char, number, date ecc.)
• descrizione del campo
• 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.29 Modulo per conteggio FP
Tale documentazione è costituita da moduli in cui devono essere riportate le informazioni per il conteggio delle dimensioni in Punti Funzione dell’obiettivo, secondo il modello standard dall’Amministrazione.
Qualora l’Amministrazione non fosse dotata di un proprio modello il Fornitore potrà proporne uno contenente almeno i seguenti elementi minimi coerenti con i requisiti indicati nel Capitolato Tecnico Speciale (cfr. 9.7):
• l’obiettivo, il tipo e la data di misura;
• l’ambito della misura e il confine dell’applicazione;
• la versione dello standard CPM di riferimento;
• le assunzioni e le scelte di misurazione;
• il risultato della misura;
• la lista di tutte le funzioni (transazionali e dati) con le rispettive classi (ADD, CHG, ecc.), tipologie (EI,EO,EQ,ILF,EIF), numero di FP assegnati.
• il riferimento ai documenti tecnici utilizzati per la misura È un documento di obiettivo.
4.30 Report sulla qualità del software
È il report contenente l’assessment della qualità intrinseca del SW finalizzato ad attestare il superamento dei livelli minimi di qualità richiesta (appendice “Livelli di servizio”) eventualmente integrato dalle proposte migliorative dei fornitori che verranno recepite nei Piani di Qualità Generali e Specifici.
Si compone con gli estratti dei tool - preferibilmente open source - approvati dalla Amministrazione, atti a rilevare le principali metriche riconosciute dagli organismi internazionali di standard quali CISQ, ISO, nonché il rispetto della normativa e linee guida indicate nel capitolato tecnico generale e speciale.
4.31 Lista oggetti software
Il software deve essere rilasciato in un ambiente di configurazione messo a disposizione dall’Amministrazione.
La lista degli oggetti software sarà composta dall’elenco dei moduli sorgenti consegnati, ordinati secondo il sistema di configuration, per cui la consegna di tale lista può non essere necessaria.
Negli altri casi il documento di Lista Oggetti Software (LOS) deve contenere un elenco di tutti gli oggetti software realizzati, modificati o resi obsoleti nell’ambito delle attività riguardanti l’obiettivo.
La LOS deve essere completa di tutte le informazioni necessarie per la gestione della configurazione.
Devono essere raggruppati separatamente gli oggetti relativi a sw di supporto e/o di test quali script di deploy, script di test, procedure relative alla predisposizione dell’ambiente di collaudo e/o di esercizio ecc.
4.32 Documentazione delle procedure batch/DTS
La documentazione delle procedure off line (batch, job, stored procedure, DTS, script ecc.) deve includere tutte le informazioni necessarie la conduzione applicativa ordinaria e straordinaria.
Tale documentazione costituisce un documento di area e 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.33 Convalida sulla tecnologia
Il documento attesta la conformità di quanto realizzato/modificato/personalizzato 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 obiettivo).
È un documento di obiettivo.
Tale documento dovrà esplicitare:
• il nome e la release dei prodotti utilizzati;
• i puntuali riferimenti (manualistica, best practices, indicazioni specifiche, ecc.) su cui è stata basata la realizzazione;
• la dichiarazione del fornitore di utilizzare i prodotti secondo le specifiche valide per le versioni indicate. L’eventuale sottoscrizione da parte del produttore della tecnologia/prodotto dovrà essere presente sullo stesso documento.
4.34 Demo sulle novità del sistema
Il prodotto contiene, sotto forma di demo o presentazione, la sintesi delle modifiche/novità intervenute in una o più applicazioni.
La demo deve essere personalizzata per ogni tipologia di utente. È un documento di obiettivo.
4.35 Altri documenti
Il prodotto di fase/sprint “altri documenti” comprende specifici output richiesti dall’Amministrazione per attività progettuali legate alle peculiarità dell’obiettivo/area/applicazione (es. protocollo di colloquio, presentazioni, ecc). Questo prodotto, laddove opportuno, deve essere mantenuto aggiornato dal fornitore per tutta la durata dell’obiettivo in cui è stato emesso la prima volta.
Nell’ambito degli “altri documenti” deve rientrare, qualora offerto per le attività di definizione e analisi (o equivalenti), anche la documentazione ad hoc da presentare all’utente ai fini della condivisione ed approvazione del lavoro.