Documentazione del Progetto - usl3.toscana.it · progetto si verificano alla fine di ogni fase e...

Struttura Organizzativa

Organizzazione e Progetti Tecnologici

Codice Revisione Pagina

Titolo

Documentazione di Progetto

All. 1

PA.STDG.01 n. 0 1 di 12

Azienda USL Toscana Centro – P.zza Santa Maria Nuova, 1 - Firenze V1_All_1_PA_STD_Documentazion-di_Progetto_29_05_17_FINALEv1.docx

Documentazione del Progetto

Project Documentation

Versione 0 • 29 Maggio 2017

Sectione 1. Introduzione

1.1 Descrizione La procedura PA.STDG.01 - di cui questo documento è parte integrante - descrive il processo

di gestione dei progetti ICT, fatto di strumenti, modelli, processi e best practice che consente

agli utenti di essere più efficienti ed efficaci nella gestione del progetto, indipendentemente

dalle dimensioni del progetto o della sua complessità.

La procedura è una versione semplificata della gestione dei processi di progettazione del

Project Management Institute (PMI) e di altri standard in uso nel settore IT (Information

Technology) fornisce un set di strumenti facile da usare con la finalità di aiutare l’Azienda a

standardizzare le attività di gestione e garantire il successo del progetto.

Il presente documento riporta la lista degli strumenti - modelli di documenti, tabelle e

rappresentazioni - da utilizzare per ogni fase del progetto.

Per ogni modello sono riportati la descrizione, i contenuti e la fase di riferimento.

1.2 Utilizzo Chiunque formulando e seguendo l’esecuzione di un progetto può utilizzare questi strumenti,

indipendentemente dal tipo di progetto.

Titolo

Documentazione di Progetto Codice Revisione Pagina

Titolo


All. 1

PA.STDG.01 n. 0 2 di 12


Section 2. Le fasi dei Progetti ICT

I progetti ICT di USLTC hanno 6 fasi che rappresentano il tipico ciclo di vita di un progetto.

Lo schema che segue riporta quali templat sono tipicamente creati e/o completati durante ogni

fase del ciclo di vita del progetto.1

1 Elaborato sulla base del Project Management Body of Knowledge (PMBOK), DOJ e VAT, IT Project life cycle.

Azienda USL Toscana Centro 5

Reporting

Processo di progettazione USL TC: Fasi, Milestones e documenti di riferimento

Phase 1 – Concept &

Feasibility

Phase 2 –

Planning &

Design

Phase 6 – System

Operation &

maintenance

Phase 5 –

Implementation &

Training

Phase 4 –

Installation & Test

Fasi di sviluppo di

un sistema

1 2 54 6

Milestone

revews

Documenti di

riferimento

I cambiamenti ai Sistemi Operativi sono nuovi progetti

Concept Proposal

(CP)

Prj Classification

Cost-Benefit

Analysis (CBA)

Feasibility Study

(Feas)

System Boundary

Document (SBD)

Risk management

plan

Project

Management Plan

Prj schedule

Verification and

Validation Plan

Functional

Requirements

Document

Integration

Document

Test and

Evaluation Master

Plan

Privacy Act

Notice/Impact

Assessment

Test Analysis

Report

Training Plan

Implementation

Plan

Training report

Change

Implemention Notice

Post-

Implementation plan

In process review

report

User satisfation

repert

Closeout Report

Acquisition/Develo

pment Plan

System design

document

Delivered System

Phase 3 –

Acquisition

Development

3

Approvazione

all’avvio del

progetto

Approvazione

del progetto

Approvazione

dello sviluppo

del sistema

Approvazione

alla messa in

operatività

Post

implementation

review

Approvazione al

rilascio del

sistema

Monitoraggio e Controllo Project

Registar

Project

change

request

Meeting

note

Status

Report

Scheda

progettoCartesiana

Overvew

progetti

Milestone

time ine

Titolo


Titolo


All. 1

PA.STDG.01 n. 0 3 di 12


Section 3. I documenti dei Progetti ICT

Per ogni progetto e per ogni sua fase deve essere predisposta la documentazione come segue:

1. Concept & Feasibility (Concezione e Fattibilità)

1.1. Concept Proposal (CP) (Proposta Progettuale)

1.2. Project Classification (Classificazione del Progetto)

1.3. Cost-Benefit Analysis (CBA) (Analisi Costi-Benefici)

1.4. System Boundary Document (SBD) (Documento di Confine del Sistema)

1.5. Feasibility Study (Feas) (Studio di Fattibilità)

1.6. Risk Management Plan (Piano di Gestione dei Rischi)

2. Planning & Design (Pianificazione e progettazione)

2.1. Project Management Plan (Piano di Gestione del Progetto)

2.2. Verification and Validation Plan (Piano di Verifica e Validazione)

2.3. Functional Requirements Document (Documento dei Requisiti Funzionali)

2.4. Integration Document (Documento d’integrazione)

3. Acquisition/ Development (Acquisizione e svilupppo)

3.1. Acquisition/Development Plan (Piano di acquisizione/sviluppo)

3.2. System design document (Documento di progettazione del Sistema)

3.3. Delivered System (Sistema consegnato)

4. Installation & Test (Istallazione e prova)

4.1. Test and Evaluation Master Plan (Piano generale di prova e valutazione)

4.2. Privacy Act Notice/Impact Assessment (Informativa sulla privacy / valutazione dell'impatto

4.3. Test Analysis Report (Rapporto di analisi dei Test)

4.4. Training Plan (Piano di formazione)

5. Implementation & Training (Implementazione e formazione)

5.1. Implementation Plan (Piano d’implementazione)

5.2. Training report (Rapporto di formazione)

5.3. Change Implemention Notice (Avviso di modica d’implementazione)

5.4. Post-Implementation review (Revisione post-implementazione)

6. System Operation & Maintenance (Funzionamento e manutenzione del sistema)

6.1. In process revew Report (Relazione di revisione del processso)

6.2. User Satisfation Report (Resoconto della soddisfazione degli utilizzaztori)

6.3. Close Out Reports (Rapporti di chiusura)

Gli incontri di Monitoraggio e controllo, almeno uno alla fine di ogni fase (Milestone) vengono

formalizzati attraverso l’utilizzo dei seguenti template (modelli):

Project Register (Registro di Progetto)

Meeting Notes (Appunti di riunione)

Status Report (Rapporto sullo stato)

Project Change Request (Richiesta di modifica del progetto)

Oltre ai documenti di progetto e di monitoraggio e controllo, sono predisposti e costantemente

aggiornati anche gli strumenti relativi alle gestione e reporting, destinati alle verifiche da parte della

Direzione.

Titolo


Titolo


All. 1

PA.STDG.01 n. 0 4 di 12


Section 4. Modelli/Templates di Progetto

ID Name del Modello

Documento Descrizione

Fase del

Progetto

Fase 1

1.1 *Concept Proposal

(Proposta Progettuale)

Il Documento “Concept Proposal” anche Project Charter (carta di progetto)

rappresenta il documento che autorizza formalmente il progetto; descrive il

“perché” ed il “cosa” ; contiene il razionale del progetto mettendo in evidenza

la motivazione che origina il progetto (ad es. obiettivi strategici), contiene o

può rimandare ad un Business Case (piano economico), definisce l’ambito,

costituisce il core team di progetto, crea una linea temporale stimata,

stabilisce un budget di progetto ed alloca le risorse ad esso destinate.

Individua e crea il gruppo di progetto e dà il via ufficiale al progetto.

1-Concept &

Feasibility

1.2

Project Classification

(Classificazione del

progetto)

Il Project Classification è uno strumento per assegnare al progetto un

punteggio di complessità; i fattori che concorrono nella valutazione della

complessità sono: Scopo, Tempo, Costi, Risorse, Rischi.

1-Concept &

Feasibility

1.3

Cost benefit analysis

(Analisi Costi-benefici)

L'analisi dei costi benefici (CBA), integrato con Feasibility study, se appropriato,

analizza e valuta, dal punto di vista dei costi e benefici, le soluzioni candidate

per soddisfare le esigenze aziendali. Descrive le alternative possibili, tutti i

benefici materiali ed immateriali ed i risultati delle analisi. Le alternative possibili

possono essere documentate in modo più dettagliato in un documento

separato di Studio di Fattibilità.

1-Concept &

Feasibility

1.4

System Boundary Document

(SBD)

(Documento di confine del

sistema)

Il SBD stabilisce i confini di un progetto di tecnologia informatica (IT). Il

documento riporta le finalità e gli obiettivi che il progetto IT intende soddisfare;

Dovrebbe contenere i requisiti di livello elevato, i vantaggi, le ipotesi di

business, i costi e la programmazione.

Registra le decisioni di gestione sul sistema previsto all'inizio del suo sviluppo e

fornisce indicazioni sulla sua realizzazione; fornisce i criteri e le misure di

performance per valutare se i deliverables hanno soddisfatto gli obiettivi.

1-Concept &

Feasibility

1.5 Feasibility Study (Feas)

(Studio di Fattibilità)

Il Feas Fornisce una panoramica di un requisito di businness o un'opportunità

aziendale e determina se esistono soluzioni possibili prima che siano impegnate

risorse del ciclo di vita dell’intero progetto

1-Concept &

Feasibility

1.6

Risk Management Plan

RMP)

(Piano di Gestione del

Rischio)

Il RMP Identifica i rischi del progetto e specifica i piani per ridurre o mitigare i

rischi. Includere gli elementi di identificazione, analisi, pianificazione,

monitoraggio, controllo e comunicazione. Discutere le strategie per la

mitigazione dei rischi del progetto in generale e strategie di dettaglio

specifiche che hanno un impatto significativo su tutto il progetto (ad esempio,

sviluppo parallelo, prototipazione).

1-Concept &

Feasibility

Fase 2

2.1

*Project Management Plan

(Piano di Gestione del

Progetto)

Il Piano di Project Management e uno dei documenti più importanti e deve

essere preparato per tutti i progetti. È lo strumento per documentare l'ambito

del progetto, i compiti, il programma, le risorse assegnate e le interrelazioni con

altri progetti. Il Piano di Project Management è il documento che stabilisce le

modalità di esecuzione del progetto cioè definisce "come" il progetto viene

eseguito, monitorato, controllato e chiuso.

Fornisce inoltre dettagli sulle unità funzionali coinvolte, le attività di lavoro

richieste, il costo e la pianificazione della misurazione delle prestazioni, le

milesotone e la pianificazione di riesame. Le revisioni del piano di gestione del

progetto si verificano alla fine di ogni fase e quando le informazioni divengono

disponibili.

Sono disponibili strumenti software progettati per il Work Breakdown structures

2-Planning &

Design

Titolo


Titolo


All. 1

PA.STDG.01 n. 0 5 di 12


ID Name del Modello


Fase del

Progetto

(WBS) (WBS), grafici Gantt, diagrammi di rete e rapporti di dettaglio di attività e

dovrebbero essere utilizzati per completare il piano di gestione del progetto. La

dimensione del piano di gestione del progetto dovrebbe essere commisurata

alla dimensione e alla complessità dei sistemi e dovrebbe generalmente

contenere quanto segue

a) fare riferimento ai requisiti/esigenze ed agli obiettivi del progetto, per

ciascun requisito dovrebbe essere documentata la fonte per

consentire la tracciabilità

b) identificare e documentare i processi del progetto e le loro finalità

c) identificare le interfacce organizzative con particolare attenzione a:

- i collegamento della organizzazione del progetto e le linee di

reporting con le varie funzioni della originaria

organizzazione e le interfacce tra funzioni all'interno

dell'organizzazione del progetto;

d) integrare i piani derivanti dalla progettazione effettuata in altri

processi di progetto; questi piani includono

Il piano di qualità

Struttura di suddivisione del lavoro

Pianificazione del progetto

Progetto di budget

Piano di comunicazione

Piano di gestione del rischio,

Piano di gestione degli approvvigionamenti

tutti i piani dovrebbero essere rivisti per la coerenza e le eventuali

soluzione delle discrepanze;

e) individuare, includere o fare riferimento alle caratteristiche del

prodotto e come queste devono essere misurate e

valutate

f) fornire una linea di base per la misurazione ed il controllo

dell’avanzamento, per la pianificazione del lavoro rimanente;

devono essere preparati e pianificati anche piani per le revisioni e le

valutazioni sullo stato di avanzamento;

g) definire indicatori di prestazione e come misurarli, e prevedere una

valutazione regolare al fine di monitorare i progressi; tali valutazioni

dovrebbero:

facilitare le azioni preventive e correttive, e

confermare che gli obiettivi del progetto

rimangono validi in un ambiente di progetto che

cambia;

h) prevedere le revisioni del progetto previste dal contratto al fine di

garantire il rispetto dei requisiti specificati

i) essere riesaminato regolarmente, e anche quando si verificano

cambiamenti significativi

Il sistema di gestione della qualità del progetto dovrebbe essere documentato

o essere richiamato nel piano di qualità del progetto

dovrebbero essere stabiliti collegamenti tra il piano di qualità del progetto e le

parti applicabili della qualità

il sistema di gestione dell'organizzazione originaria per quanto possibile;

l'organizzazione del progetto dovrebbe adottare e, se necessario, adattare il

sistema di gestione della qualità le procedure dell'organizzazione originaria

Nei casi in cui esistono requisiti specifici per il sistema di gestione della qualità

da parte di altri interessati di rilievo, occorre garantire che la gestione della

qualità del progetto sia compatibile con questi requisiti

Pratiche di gestione della qualità, come documentazione, verifiche,

tracciabilità, revisioni ed audit devono essere stabilite nel corso del progetto.

2.1.1

*Project Schedule

Programma del progetto)

Il Project Schedule (inserito o richiamato nel PMP) è la pianificazione del

progetto per allineare i processi standard di Project Management. Ci sono due

formati utilizzabili: uno è foglio Microsoft Project e l'altro un foglio di calcolo di

Excel;

è stato creato per aiutare a pianificare e tenere traccia di date importanti

E’ importante scegliere lo strumento che funziona meglio per il progetto e per

l'organizzazione.

Il programma del progetto permette di collegare le date, le risorse e le

2-Planning &

Design

Azienda USL Toscana Centro 44

Diagramma GANTT (Microsoft Office)

Titolo


Titolo


All. 1

PA.STDG.01 n. 0 6 di 12


ID Name del Modello


Fase del

Progetto

informazioni del budget. Una volta popolato con le date e le risorse; gli

indicatori di prestazioni chiave (KPI), come scostamento dal calendario e % di

completamento, possono contribuire a tracciare la performance del progetto

.

2.1.2

Work Breakdown structures

(WBS) ( struttura di

ripartizione del lavoro o

(Scomposizione strutturata

del progetto)

La WBS (inserito o richiamato in PMP)di progetto è un diagramma – su più livelli

- che rappresenta la scomposizione gerarchica del lavoro da svolgere da

parte del team di progetto per realizzare i deliverables di progetto.

Le WBS vengono utilizzate per definire i risultati del progetto e stabilire la

struttura per gestire il lavoro fino al suo completamento. Una WBS è a sua volta

un deliverable chiave del progetto che organizza il lavoro del team. La

struttura di ripartizione del lavoro definisce visivamente il campo di

applicazione in blocchi gestibili che un team di progetto può comprendere,

poiché ogni livello della struttura di ripartizione del lavoro fornisce ulteriori

definizioni e dettagli

WBS si costruisce definendo tutti i risultati del progetto (prodotti, servizi, funzioni,

mezzi di sviluppo mezzi di prova, attrezzature ture…) e tutte le azioni che

concorrono a determinare tali risultati (gestione, impostazione, progettazione,

realizzazione, avviamento, integrazione, qualità…)

Il WBS si costruisce Attraverso le seguenti fasi:

1. Elencare i sub-progetti o elementi finali (hardware, servizi, attrezzature,

ecc..) nei quali si articola il progetto

2. Suddividere i sub-progetti individuati nelle parti componenti o nelle fasi

che ne costituiscono la realizzazione (strutture del progetto)

3. Suddividere ulteriormente le parti componenti o fasi sino al livello di

pacchetti di attività da attribuire a singole unità organizzative o a singole

persone

4. Strutturare i pacchetti di attività in compiti elementari che ne

costituiscono la realizzazione (il compito rappresenta l’unità

fondamentale del processo di pianificazione)

5. Attribuire i codici di riferimento ad ogni livello della WBS

6. Individuare le responsabilità organizzative per ogni pacchetto di attività

(work-package manager)

2-Planning &

Design

2.2

Verification and Validation

Plan (V&V P)

(Piano di Verifica e di

Validazione)

BACKGROUND E INTRODUZIONE

1.1 Esposizione del problema

1.2 Soluzione proposta

1.3 Riferimenti / Documenti correlati

2.0 V & V REQUISITI E CRITERI DI MISURA

2.1 Requisiti V & V e la loro importanza

2.2 Criteri di valutazione per ogni requisito

2.3 Riferimenti / Documenti correlati

3.0 FASE PER FASE del V & V PLAN

3.1 Background del progetto e informazioni di sintesi

3.2 Pianificazione delle fasi di attività del V&V

3.3 Fase di analisi dei requisiti

3.4 Fase di progettazione

3.5 Fase di sviluppo

3.6 Integrazione e fase di prova

3.7 Fase di attuazione

3.8 Fasi di funzionamento/operatività e manutenzione

2-Planning &

Design

2.3

Functional Requirements

Document (FRD)

(Documento dei requisiti

funzionali)

Il documento dei requisiti funzionali dettaglia gli specifici requisiti di progetto e

di prodotto.

Un requisito è una condizione che un’applicazione del sistema deve

soddisfare; un requisito ha le seguenti caratteristiche:

•Fornisce un vantaggio all'organizzazione; Tale vantaggio deve essere

direttamente tracciabile per gli obiettivi di business e per i processi aziendali

nel Piano IT o strategico del periodo di riferimento.

• Descrive le funzionalità che l'applicazione deve fornire in termini di business.

• Non descrive come l'applicazione fornisce tale funzionalità.

• Non descrive tali considerazioni di progettazione come hardware per

computer, sistema operativo e progettazione di database.

2-Planning &

Design

Titolo


Titolo


All. 1

PA.STDG.01 n. 0 7 di 12


ID Name del Modello


Fase del

Progetto

• Si definisce in parole non ambigue; Il suo significato deve essere chiaro e

comprensibile.

• E’ verificabile.

Il documento di requisiti funzionali (FRD) è una dichiarazione formale dei

requisiti funzionali di un'applicazione; L'FRD ha le seguenti caratteristiche:

• dimostra che l'applicazione fornisce valore per L’azienda in termini di

business secondo gli obiettivi e processi nel piano IT del periodo di riferimento;

• contiene un insieme completo di requisiti per l'applicazione. Non lascia

spazio a supposizioni o ipotesi non dichiarata nel FRD.

• È soluzione indipendente; Il FRD è una dichiarazione di ciò che l'applicazione

deve fare-non di come funziona. Il FRD non vincola gli sviluppatori ad un

progetto; per questo motivo, ogni riferimento all'uso di una tecnologia

specifica è completamente inappropriato in un FRD.

2.4

Integration Document

(Documento di

Integrazione)

Il documento di integrazione definisce le attività necessarie per integrare le

unità software e i componenti software nell'elemento insieme software. Il

documento di integrazione contiene una panoramica del sistema, una breve

descrizione dei principali compiti relativi all'integrazione, le risorse complessive

necessarie per sostenere lo sforzo d’integrazione. Il piano viene sviluppato

durante la fase di sviluppo e viene aggiornato durante l'integrazione e la fase

di prova; La versione finale è fornita nella fase di implementazione.

2-Planning &

Design

Fase 3

3.1

Acquisition/Development

Plan

(Piano di acquisizione e

sviluppo )

Il Piano di Acquisizione/Sviluppo è un documento che mostra come tutte le

risorse umane del governo - hardware, software e telecomunicazioni, insieme

ai servizi di supporto per i contratti - siano acquisiti durante la vita del progetto.

Il piano assicura che le risorse necessarie possano essere ottenute e disponibili

al momento della loro necessità. Il piano comprende un calendario delle

milestone che elenca le attività per il completamento e le consegne da

produrre con apposite date di completamento stimato.

Il piano riporta anche i dettagli della fornitura e le specifiche di attuazione del

contratto (livelli, modalità e tempi)

3-Acquisition/

Development

3.2

System Design Document

(documento di

progettazione del sistema)

Il documento di progettazione del sistema è strutturato secondo l’indice che

segue:

1.0 Introduzione

1.1 Finalità ed Obiettivi

1.2 Riepilogo esecutivo del progetto

1.2.1 Panoramica del sistema

1.2.2 Vincoli di progettazione

1.2.3 Futuro e contingenze

1.3 Organizzazione del documento

1.4 Punti di contatto

1.5 Riferimenti del progetto

1.6 Glossario

2.0 Architettura del sistema

2.1 Architettura hardware del sistema

2.2 Architettura del software di sistema

2.3 Architettura delle comunicazioni interne

3.0 Progettazione di file e database

3.1 File di sistema di gestione del database

3.2 File di sistema di gestione non database

4.0 Interfaccia uomo-macchina

4.1 Ingressi

4.2 Uscite

5.0 Progettazione dettagliata

5.1 Disegno hardware dettagliato

5.2 Progettazione dettagliata del software

5.3 Progettazione dettagliata delle comunicazioni interne

6.0 Interfacce esterne

6.1 Architettura dell'interfaccia

6.2 Interfaccia Progettazione dettagliata

3-Acquisition/

Development

Titolo


Titolo


All. 1

PA.STDG.01 n. 0 8 di 12


ID Name del Modello


Fase del

Progetto

7.0 Controlli di integrità del sistema

3.3 Delivered System

Specifiche tecniche e operative dell’applicativo rilasciato così come definite

nel progetto esecutivo e successive modificazioni

3-Acquisition/

Development

Fase 4

4.1

Test and Evaluation Master

Plan (TEMP)

(Piano generale di prova e

valutazione)

Il TEMP identifica le funzioni e le attività necessarie affinché tutti gli aspetti del

sistema siano adeguatamente testati e che il sistema possa essere

implementato con successo. Il TEMP documenta l'ambito, il contenuto, la

metodologia, la sequenza, la gestione e le responsabilità delle attività di prova.

Il TEMP descrive le attività di verifica dell’integrazione dei sottosistemi, i test sul

sistema, la verifica di accettazione degli utenti e i test di sicurezza in livelli di

dettaglio progressivamente più alti, via via che il sistema viene sviluppato.

Il TEMP fornisce indicazioni per la gestione delle attività di test, inclusi

l'organizzazione, le relazioni e le responsabilità. Le procedure di prova possono

essere incluse nella TEMP o in un documento separato a seconda delle

dimensioni del sistema. Gli utenti aiutano nello sviluppo del TEMP nel descrivere

la natura e l'estensione dei test ritenuti necessari. Questo fornisce una base per

la verifica dei risultati dei test e la convalida del sistema. Il processo di

convalida garantisce che il sistema sia conforme ai requisiti funzionali previsti e

che le altre applicazioni o sottosistemi non siano compromessi.

Viene sviluppato un rapporto di analisi dei test ad ogni livello di prova per

registrare i risultati dei test e certificare la disponibilità per la successiva

implementazione del sistema

I problemi, le carenze, le modifiche e gli affinamento identificate durante il test

o l'implementazione dovrebbero essere monitorate nel controllo della

configurazione e testate utilizzando le stesse procedure di prova descritte nel

TEMP.

In questa fase potrebbe essere necessario aggiungere test specifici al piano e

altre documentazioni potrebbero essere necessarie per aggiornare

l'implementazione. Le modifiche apportate vengono notificate a colui che ha

avviato la richiesta di modifica e agli utenti del sistema e sono gestite come

parte del processo di controllo della configurazione.

4-Installation &

Test

4.2

Privacy Act Notice/Impact

Assessment

(Avviso sulla privacy /

Valutazione dell'impatto)

Per qualsiasi sistema con funzione ufficiale di registrazione (in base ai criteri

stabiliti dalla legge sulla protezione dei dati personali), verrà comunicato alle

strutture/ enti preposti. La comunicazione identifica lo scopo del sistema;

descrive l'uso di routine e quali tipi di informazioni e dati sono contenuti nei suoi

record; descrive dove e come si trovano i record ed individua chi è il System

Manager.

La registrazione del sistema deve far parte dei deliverable richiesti nella fase di

analisi dei requisiti di sviluppo del sistema.

La valutazione dell'impatto sulla privacy viene anch’essa effettuata in questa

fase. Si tratta di una valutazione scritta dell'impatto che l'implementazione del

sistema proposto potrebbe avere sulla privacy

4-Installation &

Test

4.3 Test Analysis Report

(Rapporto di analisi dei test)

Il rapporto di analisi dei test documenta i test del software - unità / modulo,

l'integrazione del sottosistema, il sistema, l'accettazione dell'utente e la

sicurezza - come definito nel piano di prova. Il rapporto di analisi dei test

registra i risultati dei test, presenta le funzionalità e le carenze per la revisione e

fornisce un mezzo per valutare la progressione del software nella fase

successiva dello sviluppo o di verifica. I risultati di ciascun tipo di test vengono

aggiunti al documento di sviluppo del software per il modulo o il sistema in

esame. I rapporti vengono creati come richiesto per le fasi successive.

L'insieme dei report di analisi di test fornisce una base per assegnare la

responsabilità per la correzione del deficit e il follow-up, nonché per la

preparazione di una dichiarazione di completamento del progetto.

I moduli del rapporto di prova di un problema vengono generati come

richiesto e sono allegati ai report di analisi dei test durante le verifiche a livello

dell’integrazione o superiori. Il carattere dei problemi riscontrati, a partire dai

test di integrazione, verrà tracciato e segnalato al controllo della

4-Installation &

Test

Titolo


Titolo


All. 1

PA.STDG.01 n. 0 9 di 12


ID Name del Modello


Fase del

Progetto

configurazione.

4.4 Training Plan

(piano di formazione)

Il piano di formazione descrive gli obiettivi, le esigenze, ed il curriculum che

devono essere affrontati quando si addestrano gli utenti sul nuovo sistema. Il

piano presenta le attività necessarie per sostenere lo sviluppo dei materiali

formativi, il coordinamento degli orari di formazione, la riserva di personale e le

strutture, la pianificazione delle esigenze di formazione e altre attività legate

alla formazione.

Le attività formative sono sviluppate per insegnare al personale utente l'utilizzo

del sistema come specificato nei criteri di formazione.

Per sviluppare un piano di formazione e necessario fare riferimento ad uno

schema che preveda i target di destinazione e gli argomenti su cui deve

essere condotta la formazione sulla base delle esigenze; comprende anche la

strategia di formazione come saranno affrontati gli argomenti. Queste

informazioni includono il formato del programma di formazione, l'elenco degli

argomenti da coprire, i materiali, l'ora, i requisiti di spazio e gli orari proposti.

Prevede anche di discutere con la Qualità in termini di test, valutazione del

corso, feedback e modifica / miglioramento del corso.

4-Installation &

Test

Fase 5

5.1 Implementation Plan

(Piano d’implementazione)

Il piano di implementazione descrive come il sistema verrà distribuito, installato

e trasferito in un sistema operativo. Il piano contiene una panoramica del

sistema, una breve descrizione dei principali compiti relativi

all'implementazione, le risorse complessive necessarie per sostenere lo sforzo di

implementazione (come hardware, software, strutture, materiali e personale) e

ogni requisito di attuazione nel sito specifico. Il piano viene sviluppato durante

la fase di progettazione ed è aggiornato durante la fase di sviluppo; La

versione finale viene fornita nella fase di integrazione e prove ed è utilizzata

come guida durante la fase di implementazione.

5-Implementation

& Training

5.2 Training report Documenti di registrazione della formazione e dell’addestramento 5-Implementation

& Training

5.3 Change Implemention

Notice

Modulo di notifica di una richiesta di cambiamento (Vedi anche documenti di

monitoraggio)

5-Implementation

& Training

5.4

Post-Implementation review

(Revisione Post

Implementazione)

La revisione post-implementazione viene utilizzata per valutare l'efficacia dello

sviluppo del sistema dopo che il sistema è in produzione per un periodo di

tempo (normalmente sei mesi).

Gli obiettivi sono determinare se il sistema fa quello che è progettato per fare:

Supporta l'utente come richiesto in modo efficace ed efficiente? La revisione

dovrebbe valutare quanto sia efficace il sistema in termini di funzionalità,

prestazioni e costi rispetto ai benefici, nonché valutare l'efficacia delle attività

di sviluppo del ciclo di vita che hanno prodotto il sistema. I risultati delle

revisioni possono essere utilizzati per rafforzare il sistema come pure le

procedure di sviluppo.

La revisione viene programmata per seguire il rilascio del sistema o di una

revisione, per un periodo di tempo appropriato per consentire la

determinazione dell'efficacia del sistema. Un membro del gruppo di sviluppo

funzionale o di altri membri dell'organizzazione partecipa alla revisione. Il

proponente del sistema assicura che tutta la documentazione sia accessibile e

che tutto il personale necessario possa partecipare alla revisione.

Il revisore e un team assegnato raccolgono le informazioni necessarie per la

revisione post-implementazione, intervistando gli utenti finali ed i loro manager,

amministratori di sistema e personale operativo.

Il report viene quindi preparato e fornito all'organizzazione che lo ha richiesto

ed ai sistemi informativi, che possono utilizzare congiuntamente i risultati per

avviare altre azioni.

5-Implementation

& Training

Fase 6

6.1

In process revew Report

(Relazione di revisione del

processo )

Lo scopo della revisione in process è di valutare la performance del sistema e

la soddisfazione dell'utente. Questo processo di revisione si verifica

6-System

Operation &

Maintenance

Titolo


Titolo


All. 1

PA.STDG.01 n. 0 10 di 12


ID Name del Modello


Fase del

Progetto

ripetutamente per garantire l’efficienza economica del sistema e che continui

a soddisfare le esigenze funzionali dell'utente. Il report fornisce una descrizione

del processo di revisione, della sua messa a fuoco e dei risultati. Il report può

anche essere utilizzato per documentare le approvazioni del management per

ulteriori miglioramenti o sviluppo del sistema in esame.

A seconda della tempistica e del focus della revisione, può comportare l'analisi

del tempo di risposta del sistema, della capacità dei dati, delle nuove

tecnologie disponibili, delle funzioni aziendali e della continua soddisfazione

degli utenti del sistema

6.2

User Satisfation Report

(Report di soddisfazione

degli utenti)

L'indagine per la valutazione della soddisfazione degli utenti viene utilizzata per

raccogliere i dati necessari per analizzare la soddisfazione dell'utente attuale

con le prestazioni di un'applicazione esistente. L'indagine viene fatta

annualmente o secondo necessità. Il modello disponibile propone i contenuti

per la revisione della soddisfazione dell'utente.

6-System

Operation &

Maintenance

6.3

*Close Out Report

(Rapport di chiusura)

(Project Closure & Lessons

Learned)

(Documento di chiusura del

progetto e Lezioni apprese)

Il Project Closure formalizza il completamento del progetto;

al termine di ogni progetto è necessario predisporre una relazione di chiusura

che rappresenta la conclusione ufficiale di un progetto; i fondi e le risorse non

saranno più necessari e le attività operative continueranno normalmente.

Alla chiusura, il team di revisione riesamina l'intero progetto in base ai tanti

documenti e registri e confronta le caratteristiche pianificati con i risultati

ottenuti. I contratti sono formalmente chiusi e termina l'approvvigionamento

delle risorse per il progetto.

Il documento Lessons Learned viene utilizzato per identificare e preservare le

lezioni apprese su ogni progetto; lo scopo è quello di aiutare la condivisione

della conoscenza maturata dal team di progetto con l'esperienza. Un

programma di successo delle Lessons Learned aiuterà i team di progetto a

ripetere le soluzioni auspicabili ed evitare risultati indesiderati.

6-System

Operation &

Maintenance

Section 5. Modelli/Templates di Monitoraggio e Controllo

Monitor & Control

*Project Register

(Registro di progetto)

Il registro di progetto è uno strumento che viene utilizzato per catturare e

tenere traccia delle informazioni chiave del progetto, rendendo più facile il

monitoraggio, il controllo e traccia i dettagli del progetto per tutta la durata

del progetto

Monitor & Control

*Project Meeting Notes

(PMN) (Appunti di riunione

di progetto)

Il modulo Meeting Note viene utilizzato per documentare e comunicare le

note/appunti per tutte le riunioni di progetto

Monitor & Control

*Project Status Report

(Rapporto di stato del

progetto)

Il Rapporto di stato viene utilizzato per comunicare la salute generale del

progetto per il core team di progetto e le parti chiave interessate (stakeholder)

per tenere tutti aggiornati sull'avanzamento del progetto.

Monitor & Control

*Project Change Request

(PCR)

(Richiesta di modifica del

progetto)

Il Project Change Request (PCR) viene utilizzato dal Project Manager per

richiedere una modifica agli obiettivi del progetto, al programma, ai costi, alle

tappe /milestones) e /o ai risultati del progetto(deliverables).

Monitor & Control

Titolo


Titolo


All. 1

PA.STDG.01 n. 0 11 di 12


Section 6. Modelli/Templates di Gestione e Reporting

REPORTING

Struttura Programmi e i

Progetti ICT

I programmi ed i progetti sono identificati da un nome sintetico ed un codice

“parlante” composto da:

• Sigla del programma

• Sigla del sottoprogramma (se non presente, si mette x)

• Numero progressivo del progetto (punto 0: Luglio 2016)

• Numero progressivo del sotto-progetto

Esempio: Progetto Anagrafe Medici di Medicina Generale (ANAG_X_3.1)

Reporting

Elenco /Tavola dei progetti

ICT Attivi

La tabella contiene gli elementi base per l’identificazione del progetto e viene

costantemente aggiornata quale strumento di sintesi a supporto della

Direzione per garantire il monitoraggio dello stati di avanzamento del lavoro.

• Tipo di progetto (A/B)

• Ambito (se tipo A) / Programma (se tipo B)

• Nome del progetto

• Codice del progetto (se tipo B)

• Ente che ha in carico il management del progetto

(ESTAR/RT/Azienda/…)

• Project Manager

• Referente di Progetto (se tipo A)

• Livello di priorità (se tipo A)

• Livello di complessità (da calcolare sia per progetti di tipo A che di tipo

B)

• Data prevista di chiusura

Reporting

Overvew progetti attivi

La tabella permette una visione d’insieme di più progetti ed una

rappresentazione immediata della progetto in corso e del suo stato (in corso,

fermo, criticità, nodi da sciogliere, ecc) utilizzando strumenti “visual” colori e

simboli.

Le colonne contengono :

• Codice e Nome del progetto



B)

• Project Manager


• Fase in cui si trova il progetto

• Stato del progetto

• Data di avvio

• Data prevista di completamento

•

Reporting

Scheda di sintesi del

progetto (da rivedere)

Tavola singola che riporta in sintesi le informazioni essenziali del progetto quali:

• Tipo di progetto (A/B)

• Ambito (se tipo A) / Programma (se tipo B)

• Nome del progetto

• Codice del progetto (se tipo B)

• Ente che ha in carico il management del progetto

(ESTAR/RT/Azienda/…)

• Project Manager


• Descrizione sintetica con indicati Obiettivo e benefici attesi.

• Eventuale articolazione in Sotto-progetti



B)

• Processi/ strutture/coinvolte

• Stato/Fase corrente del progetto

• Rispetto del cronoprogramma

• Milestones

• Data prevista di chiusura

Reporting

PMI Chiusura

DoJ

Trend ID Progetto progetto Ambito PrioritàREFERENTE DI

PROGETTO

Data Inizio

progetto

Concezione/avvi

o

Sviluppo

cencettuale Pianificazione

Analisi dei

requisiti Progettazione Sviluppo

Integrazione e

test

Implementazion

e

Operatività e

manutenzione

Messa a

disposizione

Scadenza

progetto

USLTC

Phase 3 –

Acquisition

Development

Phase 4 –

Installation &

Test

Phase 5 –

Implementation

& Training

1xxx A

xxxx

2yyy S

3zzz R

4

S

A: Amministravio

S: Sanitario

R: Reti e Sistemi

Phase 6 – System Operation &

Maintenance

Monitoraggio e Controllo

Phase 1 – Concept & Feasibility Phase 2 – Planning & Design

Concezione Pianificazione Esecuzione

= conclusa

= in corso

= da fare

= nodo da sciogliere

= criticità

= concluso

= in corso

= fermo

Titolo


Titolo


All. 1

PA.STDG.01 n. 0 12 di 12


• Documentazione di riferimento

Milestone Timeline/

(Sequenza temporale delle

tappe fondamentali)

Lo strumento Milestone Timeline viene utilizzato per una rappresentazione

"visiva" della programmazione (time line) allineata alle tappe fondamentali

(Milestone)

Un Timeline può essere creato utilizzando un'applicazione di diagrammi. è utile

per presentare un programma visual del progetto.

Una volta creato il programma (Project Schedule), i risultati chiave e le tappe

dovrebbero essere mappati e allineati alla timeline predisposto secondo

quando previsto dal programma nel progetto.

Reporting

Diagramma di Gant

Il diagramma di Gantt è lo strumento da utilizzare per monitorare in tempo

reale il rispetto dei tempi di progetto ed individuare tempestivamente quei

ritardi che possono comportare uno slittamento della data di fine progetto.

Il diagramma di Gantt consente di rappresentare sinteticamente lo

svolgimento temporale del progetto considerando anche la propedeuticità tra

le varie attività e la correlazione tra di esse. Consente inoltre di evidenziare le

“milestones” ovvero quelle attività che se completate in ritardo causeranno

certamente lo slittamento della data di completamento del progetto.

L’aggiornamento del cronoprogramma e la sua condivisione/diffusione è in

carico al PjM. In figura è riportato a fini illustrativi un esempio di diagramma di

Gantt.

Reporting

Cartesiana indicatori

Il diagramma cartesiano tempi/costi consente di avere una panoramica

immediata della capacità di gestione dei progetti nel suo complesso in termini

di capacità di rispettare sia i tempi che il budget di progetto. Sull’asse delle

ascisse è rappresentata la percentuale corrente di budget utilizzata fino

rispetto a quella inizialmente prevista, mentre sull’asse delle ordinate è

rappresentato il tempo trascorso rispetto a quanto previsto dal

cronoprogramma. L’origine degli assi è 0%, ovvero un progetto che si trova in

essa ha rispettato esattamente tempi e budget. I progetti che si trovano nel

primo quadrante hanno sforato sia i tempi che il budget, quelli che si trovano

nel secondo quadrante hanno sforato il budget ma non i tempi, quelli che si

trovano nel terzo quadrante hanno contenuto sia il budget che i tempi, infine i

progetti che si trovano nel quarto quadrante hanno rispettato il budget ma

non i tempi.

In figura è riportato un esempio di diagramma cartesiano con l’interpretazione

dei quattro quadranti

Reporting

*Questi modelli sono altamente raccomandati indipendentemente dalle dimensioni del progetto o dalla complessità.

Active QAT Projects

Total Project Cost

Quadrant II: Within budget and Over-schedule

(Target) Quadrant III: Within budget and Within schedule

Quadrant IV: Over budget and Within schedule

Original budget/original schedule

43

Legend

Project which is within budget and within schedule

Project which is over budget and within schedule or within budget and behind schedule

Project which is over budget and behind schedule

100%

4

8

Quadrant I: Over-budget and Over-schedule

41-100%

-10

0%

26

10

0%

Pro

ject

Sch

edu

le

2527

44

51

3

52

1

2

11

50

9

38

42

48

5

17

Includes only projects reported as more than 32% complete

60

49

12

18

46

21

1319

20

28

37

45

47

Project reviewed by SAO/QAT; SAO Report 14-020 Published Feb 2014

Documentazione del Progetto - usl3.toscana.it · progetto si verificano alla fine di ogni fase e...

Documents

Transcript of Documentazione del Progetto - usl3.toscana.it · progetto si verificano alla fine di ogni fase e...