Project planning and implementation according ECSS ST-M-10

Appunti sulla pianificazione e la realizzazione di un
progetto in ambito spaziale secondo gli standard ECSS
Fonte: standard ECSS-M-ST-10C Rev. 1 del 6 marzo 2009
by Mario Gentili

Space project management - Project planning and Implementation
1
1 Sommario
1 GLOSSARIO ..............................................................................................................................................3
2 PROJECT PLANNING.................................................................................................................................5
2.1 INTRODUZIONE........................................................................................................................................... 5
2.2 SCOPO ED OBIETTIVI DEL PROGETTO ............................................................................................................... 5
2.3 ASSESSMENT RISORSE.................................................................................................................................. 5
2.4 RIUSO ...................................................................................................................................................... 5
2.5 VALUTAZIONE DEL RISCHIO ........................................................................................................................... 6
2.6 APPROCCIO DI SVILUPPO .............................................................................................................................. 6
2.7 RISULTATI DEL PROGETTO............................................................................................................................. 6
2.8 REQUISITI E VINCOLI DEL CLIENTE ................................................................................................................... 6
2.9 DOCUMENTI DEI REQUISITI DEL PROGETTO (PRD)............................................................................................. 6
2.10 PROJECT MANAGEMENT PLAN ....................................................................................................................... 6
3 PROJECT ORGANIZATION.........................................................................................................................8
3.1 INTRODUZIONE........................................................................................................................................... 8
3.2 STRUTTURA ORGANIZZATIVA ......................................................................................................................... 8
3.3 COMUNICAZIONE E REPORTING ..................................................................................................................... 8
3.4 AUDITS..................................................................................................................................................... 8
4 PROJECT BREAKDOWN STRUCTURES .......................................................................................................9
4.1 INTRODUZIONE........................................................................................................................................... 9
4.2 ALBERO DELLE FUNZIONI -FUNCTION TREE ....................................................................................................... 9
4.3 ALBERO DELLE SPECIFICHE - SPECIFICATION TREE............................................................................................... 9
4.4 ALBERO DEL PRODOTTO - PRODUCT TREE ........................................................................................................ 9
4.5 WORK BREAKDOWN STRUCTURE (WBS) ....................................................................................................... 10
4.6 WORK PACKAGE (WP) .............................................................................................................................. 10
4.7 ORGANIZATION BREAKDOWN STRUCTURE (OBS) ............................................................................................ 10
5 PROJECT PHASING – PROJECT CVS ......................................................................................................... 11
5.1 INTRODUZIONE......................................................................................................................................... 11
5.2 RAPPORTO TRA ACCORDI COMMERCIALI E FASI DEL PROGETTO ........................................................................... 12
5.3 LE FASI DI PROGETTO................................................................................................................................. 13
5.3.1 Phase 0 (Mission analysis/needs identification).............................................................................. 13
5.3.1.1 Attività principali .................................................................................................................................... 13
5.3.1.2 Review associate .................................................................................................................................... 13
5.3.2 Phase A (Feasibility) ........................................................................................................................ 13
5.3.3 Phase B (Preliminary definition)...................................................................................................... 14
5.3.4 Phase C (Detailed definition)........................................................................................................... 15
5.3.5 Phase D (Qualification and production) .......................................................................................... 15
5.3.6 Phase E (Operations/utilization)...................................................................................................... 16
5.3.7 Phase F (Disposal)............................................................................................................................ 17

2
6 ALLEGATI ............................................................................................................................................... 18
6.1 A- PROJECT MANAGEMENT PLAN (PMP) – DRD............................................................................................ 18
6.1.1 Contenuti del documento:............................................................................................................... 18
6.2 B - PRODUCT TREE - DRD .......................................................................................................................... 20
6.3 C - WORK BREAKDOWN STRUCTURE (WBS) – DRD........................................................................................ 21
6.4 D - WORK PACKAGE (WP) DESCRIPTION – DRD............................................................................................. 22
6.5 E - PROGRESS REPORT – DRD..................................................................................................................... 23
6.6 F - ECSS MANAGEMENT BRANCH DOCUMENTS DELIVERY PER REVIEW ................................................................. 24
6.7 G -DOCUMENTI PERIODICI O A SEGUITO DEL VERIFICARSI DI UN INCIDENTE ........................................................... 25
6.8 H - WBS LIVELLO DI DETTAGLIO .................................................................................................................. 26
7 BIBLIOGRAPHY....................................................................................................................................... 27

3
1 Glossario
Sigla Descrizione
AR acceptance review
B/L baseline
CBCP current baseline cost plan
CDR critical design review
CRR commissioning result review
DRD document requirements definition
DRL document requirements list
EAC estimate at completion
EGSE electrical ground support equipment
ELR end-of-life review
ETC estimate to completion
FRR flight readiness review
GSE ground support equipment
ILS integrated logistic support
ITT invitation to tender
LRR launch readiness review
MCR mission close-out review
MDR mission definition review
MGSE mechanical ground support equipment
N/A not applicable
OBCP original baseline cost plan
OBS organizational breakdown structure
ORR operational readiness review
PDR preliminary design review
PMP project management plan
PRD project requirements documents
PRR preliminary requirements review
QR qualification review
RFP request for proposal
RFQ request for quote

4
SRR system requirements review
WBS work breakdown structure
WP work package

5
2 Project planning
2.1 Introduzione
La pianificazione e l’implementazione di un progetto spaziale è l’insieme delle attività che
permettono di realizzare l’intero ciclo di vita del progetto stesso, dal suo inizio alla sua fine. Le
attività devono tener conto della catena cliente-fornitore e ricevono input da tutte le fasi del
progetto e prevedono la stretta cooperazione tra tutti i domini del progetto stesso.
Un progetto o sistema spaziale, è sempre contraddistinto da tre
segmenti (vedere ECSS-E-ST-70):
• space segment,
• ground segment,
• launch service segment.
In linea di principio, una proposta per avviare un progetto spaziale può
avere origine da qualsiasi parte. Tuttavia, coloro i quali più
comunemente danno origine ad un progetto spaziale (sponsor) sono:
• singoli governi o cooperazione tra un certo numero di governi;
• agenzie spaziali nazionali o internazionali, singolarmente o collettivamente;
• comunità scientifiche nazionali o internazionali;
• operatori di sistemi spaziali commerciali.
2.2 Scopo ed obiettivi del progetto
Lo scopo e gli obiettivi del progetto sono definiti dallo sponsor nel documento mission statement (il
Project Management Institute-PMI, www.PMI.com, parla di project charter) che include i parametri
chiave di prestazione, i requisiti e i vincoli tecnici e programmatici da applicare al progetto.
Normalmente sono coordinati con il top level customer, se ne è stato assegnato uno.
2.3 Assessment risorse
Si tratta della fase, effettuata congiuntamente tra cliente e fornitore, tesa a valutare la disponibilità
di:
• know-how scientifico e tecnologico,
• tecnologia necessaria,
• risorse umane,
• formazione,
per attuare il progetto.
Il risultato di questa valutazione fornisce significative indicazioni su risorse, costi e tempi del progetto
e alla successiva valutazione del rischio tecnico e programmatico.
2.4 Riuso
Si tratta di fase tesa a valutare il riutilizzo di prodotti esistenti e viene generalmente eseguita come
risposta diretta a un requisito del cliente.
Analogamente alla fase di assessment, il risultato di questa valutazione fornisce significative
indicazioni su risorse, costi e tempi del progetto e alla successiva valutazione del rischio tecnico e
programmatico.

6
2.5 Valutazione del rischio
Le valutazioni iniziali dei rischi tecnici e programmatici di un progetto sono eseguite dal cliente, sulla
base degli input dello sponsor del progetto rispetto allo scopo e agli obiettivi del progetto, insieme ai
vincoli tecnici e programmatici identificati da applicare al progetto. La valutazione iniziale viene
successivamente ampliata regolarmente per includere altri parametri rilevanti, man mano che
diventano disponibili e man mano che il progetto matura. Valutazioni di rischio complete sono
condotte a ogni revisione del progetto principale.
2.6 Approccio di sviluppo
L’approccio di sviluppo per un progetto è definito congiuntamente dal cliente e dal fornitore per
conformarsi documento di mission statement ai requisiti e ai vincoli della missione
2.7 Risultati del progetto
Il cliente ha la responsabilità di definire i prodotti consegnabili, necessari per soddisfare la mission
statement dello sponsor.
2.8 Requisiti e vincoli del cliente
I requisiti e i vincoli del cliente sono preparati dal cliente in base alle uscite delle precedenti fasi (da
1.2 a 1.7). Sono esplicitati in un formato adatto per l’applicazione diretta in un bando di gara (ITT -
Invitation To Tender). Riguardano i requisiti tecnici e programmatici, nonché i vincoli politici,
commerciali e industriali da applicare al progetto e rappresentano, collettivamente, i documenti dei
requisiti del progetto (PRD – Project Requirement Documents).
2.9 Documenti dei requisiti del progetto (PRD)
I documenti dei requisiti del progetto (PRD) sono parte integrante di un bando di gara, o di una
richiesta di proposta (RFP – Request For Proposal) o una richiesta di preventivo (RFQ – Request For
Quote) preparata e rilasciata da un cliente a potenziali fornitori. Il PRD, in genere, comprende:
• statement of work (è il project charter del PMI),
• requisiti tecnici documentati in nella Specifica dei Requisiti tecnici, come definito in ECSS-E-
ST-10-06,
• requisiti di gestione,
• requisiti di ingegneria,
• requisiti di garanzia del prodotto,
• requisiti programmatici,
• altri requisiti specifici del progetto (ad esempio distribuzione geografica, filosofia del modello
da applicare),
• elenco dei requisiti dei documenti (DRL – Document Requirement List),
• requisiti di gara.
2.10 Project management plan
Il Piano di Progetto iniziale (o top level PMP - Project Management Plan) è l’insieme dei documenti o
dei piani che devono essere sviluppati per ognuno dei domini (il PMI li chiama Aree di conoscenza) di
un progetto. Generalmente si articola nei piani relativi a:
ID Area di conoscenza
1 Gestione dell’integrazione di prj

7
ID Area di conoscenza
2 Gestione dell’ambito (scope)
3 Gestione dei Tempi
4 Gestione dei Costi
5 Gestione della Qualità
6 Gestione delle Risorse umane
7 Gestione della Comunicazione
8 Gestione dei Rischi
9 Gestione degli Approvvigionamenti
10 Gestione degli Stakeholders

8
3 Project organization
3.1 Introduzione
L’istituzione di un’organizzazione ben strutturata e coerente per attuare un progetto, a tutti i livelli
nella catena di clienti-fornitori, è un fattore chiave per garantire un approccio gestionale efficace ed
efficiente. Ad ogni livello nella catena cliente-fornitore, un’organizzazione di progetto può essere
costruita come un team di progetto autonomo, che contiene tutte le discipline necessarie all’interno
della struttura del team o, più spesso, può essere costruita attorno a un team di progetto principale
che racchiude le funzioni chiave del progetto, e che si rivolge all’esterno per la fornitura di altre
competenze, attività o servizi.
• Ogni cliente e fornitore deve individuare il proprio responsabile di progetto, che, tra l’altro,
ha l’autorità di firmare gli accordi commerciali.
• Se il progetto ha collegamenti con altri progetti, ogni cliente e fornitore deve individuare il
responsabile delle relazioni.
• Se un cliente o fornitore impiega consulenti o altri specialisti per assisterlo nello svolgimento
delle sue funzioni, devono essere definiti i ruoli, le responsabilità e l’autorità di questi
consulenti e specialisti.
• Quando un cliente fornisce un prodotto a un fornitore, deve individuare il responsabile di
prodotto per la fornitura.
3.2 Struttura organizzativa
È essenziale che la struttura organizzativa del progetto sia organizzata in modo da includere tutte le
competenze necessarie per implementare il progetto con funzioni ben definite, nonché chiare linee
di comunicazione e reporting, inter-relazioni e interfacce. Tutti gli attori del progetto, al di sotto del
top level customer e al di sopra del (i) fornitore (i) di più basso livello, hanno il ruolo sia di fornitori,
sia di clienti, e le loro strutture organizzative devono soddisfare entrambi i ruoli.
La struttura organizzativa fornisce una chiara e inequivocabile definizione e assegnazione dei ruoli e
delle responsabilità individuali assieme all’identificazione delle necessarie autorità per
l’implementazione dell’organizzazione del progetto (sia interna al gruppo di lavoro, sia esterna, in
caso di ricorso a fornitori esterni).
3.3 Comunicazione e reporting
Efficaci mezzi di comunicazione sono strumenti essenziali per garantire un’interazione chiara ed
efficiente tra tutti gli attori del progetto, nonché tra il team di progetto e le sue interfacce esterne. La
tecnologia dell’informazione è il mezzo principale per lo scambio di informazioni. La comunicazione
serve inizialmente per fornire chiarezza sugli obiettivi e gli obiettivi del progetto e, successivamente,
per supportare il lavoro quotidiano del team di progetto. Le relazioni periodiche sono uno strumento
importante per lo scambio di informazioni relative allo stato di avanzamento del progetto
3.4 Audits
Gli audit sono attività indipendenti di verifica e controllo per assicurare che i processi e le procedure
del progetto raggiungano gli obiettivi prefissati nei tempi e modi previsti dal piano di progetto. Sono
fondamentali per individuare aree di criticità e si esplicano in richieste di modifica (change request)
che in genere portano ad azioni correttive e/o azioni preventive.

9
4 Project breakdown structures
4.1 Introduzione
La Project breakdown structures fornisce le basi di una conoscenza comune del progetto tra tutti gli
attori del progetto e consiste nella scomposizione di attività complesse in attività più semplici da
gestire. La metodologia di implementazione è quella descritta nel seguito.
4.2 Albero delle funzioni -Function tree
L’albero delle funzioni consiste nella suddivisione delle prestazioni del sistema in funzioni. Ogni
funzione è scomposta in sotto-funzioni indipendentemente dal tipo di prodotti coinvolti. L’approccio
"funzione" viene applicato durante la fase di avvio del progetto o durante la fase di definizione del
sistema.
4.3 Albero delle specifiche - Specification tree
L’albero delle specifiche definisce la relazione gerarchica di tutte le specifiche dei requisiti tecnici per
i diversi elementi di un sistema o prodotto.
4.4 Albero del prodotto - Product tree
L’albero del prodotto è la suddivisione del progetto in livelli successivi di prodotti o elementi
hardware e software, articolati per eseguire le funzioni identificate nell’albero delle funzioni.
Tuttavia, l’albero delle funzioni e l’albero del prodotto non si rispecchiano necessariamente l’un
l’altro. La struttura del prodotto include i modelli di sviluppo, il Ground Support Equipment - GSE, gli
strumenti di integrazione e le apparecchiature di prova e gli elementi esterni necessari per
convalidare il prodotto finale e la documentazione dell’Integrated Logistic Support - ILS. Comprende
items sottoposti al controllo della configurazione del cliente e items che sono oggetto di una specifica
dei requisiti tecnici. L’albero del prodotto costituisce la base per l’elaborazione della struttura di
ripartizione del lavoro del progetto. Esempio:
Space
System
Space Segment Ground Segment
PayloadPlatform GSE
Mission Control
Center
Payload Control
Center
Communications
System
Structure
Thermal control
On-board power
supply
Attitude control
Data handling
Instrument 1 MGSE
EGSEInstrument 2
Instrument 3

10
4.5 Work breakdown structure (WBS)
La WBS è la struttura principale utilizzata nella gestione di un progetto e fornisce un quadro per la
gestione dei costi, della pianificazione e della realizzazione tecnica. Divide il progetto in pacchetti di
lavoro gestibili, organizzati in base alla natura del lavoro, suddividendo il lavoro totale da eseguire in
livelli crescenti di dettaglio.
La WBS deriva dalla struttura del prodotto, i cui elementi selezionati vengono estesi per includere
funzioni di supporto (ad esempio gestione, ingegneria, garanzia del prodotto) e servizi associati (ad
esempio, strutture di test). Esempio:
Space System
Space Segment Ground Segment
PayloadPlatform GSE
Mission Control
Center
Payload Control
Center
Communications
System
Structure
Thermal control
On-board power
supply
Attitude control
Data handling
Instrument 1 MGSE
EGSEInstrument 2
Instrument 3
Management
tasks
Engineering
tasks
Product
Assurance
tasks
Support function extensions
4.6 Work package (WP)
Un WP è un qualsiasi elemento della WBS che può essere misurato e gestito per la pianificazione, il
monitoraggio e il controllo.
I pacchetti di lavoro di controllo sono identificati dal fornitore a quel livello della WBS in cui è
richiesta la visibilità e il controllo e per il quale deve essere fornito un report. I pacchetti di lavoro di
controllo rappresentano lo scope totale del progetto e sono concordati con il cliente.
Il lavoro di ciascun fornitore è esplicitamente identificato nella WBS da almeno un WP di controllo.
4.7 Organization breakdown structure (OBS)
L’OBS descrive l’organizzazione del progetto proposta, compresa le interfacce e le responsabilità
contrattuali, in contrapposizione alla struttura dell’organizzazione aziendale, che invece descrive gli
aspetti funzionali dell’azienda. L’OBS di progetto mostra il personale chiave e le responsabilità
assegnate per ogni pacchetto di lavoro nella WBS.

11
5 Project phasing – Project CVS
5.1 Introduzione
Il ciclo di vita di un progetto spaziale prevede sempre le seguenti sette fasi:
FASE DESCRIZIONE NOTE
1- Phase 0 - Mission analysis/needs identification Le tre fasi 0, A, e B si focalizzano
principalmente su:
• l’elaborazione dei requisiti funzionali e
tecnici del sistema e l’identificazione
dei concetti di sistema per conformarsi
alla mission statement, tenendo conto
dei vincoli tecnici e programmatici
identificati dallo sponsor del progetto
e dal cliente principale (top customer),
• l’identificazione di tutte le attività e
risorse da utilizzare per sviluppare i
segmenti space e ground del progetto,
• le valutazioni iniziali del rischio tecnico
e programmatico,
• avvio di attività di pre-sviluppo.
2- Phase A - Feasibility
3- Phase B - Preliminary Definition
4- Phase C - Detailed Definition Le fasi C e D comprendono tutte le attività
da svolgere al fine di sviluppare e
qualificare i prodotti dei space e ground
segment.5- Phase D - Qualification and Production
6- Phase E - Utilization
La fase E comprende tutte le attività da
svolgere al fine di avviare, commissionare,
utilizzare e mantenere gli elementi propri
dello space e ground segment associato.
7- Phase F - Disposal (smaltimento)
La fase F comprende tutte le attività da
svolgere al fine di smaltire, in sicurezza,
tutti i prodotti propri dello space segment
e del ground segment associato.

12
Al termine delle attività principali e delle revisioni relative alla configurazione del progetto, vengono
stabilite le baseline di riferimento (vedere ECSS-M-ST-40).
Ciascuna delle fasi del progetto termina con delle milestone finali che si esplicitano nella forma di
documenti di revisione (review) del progetto, il cui esito determina la disponibilità del progetto a
passare alla fase successiva. I requisiti relativi all’organizzazione e allo svolgimento delle revisioni
sono forniti nell’ECSS M ST-10-01.
Ad eccezione della Mission Definition Review - MDR che normalmente coinvolge solo il project
initiator (lo sponsor) del progetto e il top level customer, tutte le altre revisioni del progetto, in
genere, vengono eseguite da tutti gli attori del progetto nella catena cliente-fornitore.
Dalla Preliminary Requirement Review - PRR al Preliminar Design Review - PDR, la sequenza delle
review è top-down, a partire dal cliente di livello superiore e dal suo fornitore di livello superiore, e
proseguendo lungo la catena di clienti-fornitori fino al fornitore di livello più basso.
Di contro, dal Critical Design Review - CDR all’AR, la sequenza delle review viene invertita in bottom-
up: a partire dal fornitore/cliente di livello più basso verso il fornitore/cliente di primo livello. Questo
cosiddetto "modello V" è illustrato nella seguente figura:
Project Initiator System Operator
2nd Level Customer
Top Level Customer
1st Level Customer
nth Level Customer
Lowest Level Supplier
nth Level Supplier
2nd Level Supplier
1st Level Supplier
MDR
PRR/SRR/PDR
PDR
PDR
PDR CDR/QR/AR
CDR/QR/AR
CDR/QR/AR
CDR/QR/AR
CRR
5.2 Rapporto tra accordi commerciali e fasi del progetto
Un accordo commerciale può coprire una singola fase di progetto, ovvero un raggruppamento
sequenziale di fasi o sotto fasi del progetto (ad esempio fase B1 / fase B2, fase B2 / fase C1 / fase C2),
in base a fattori come disponibilità di finanziamento, gare competitive, programma, rischio
percepito. Indipendentemente dall’approccio utilizzato per definire l’ambito dei singoli accordi
commerciali, tutti i progetti spaziali seguono essenzialmente le fasi del progetto classico.

13
5.3 Le fasi di progetto
5.3.1 Phase 0 (Mission analysis/needs identification)
Questa è un’attività svolta principalmente dal project initiator, dal top level customer e dai principali
rappresentanti degli utenti finali.
5.3.1.1 Attività principali
• produrre la mission statement in termini di identificazione e caratterizzazione dei bisogni di
missione, prestazioni attese, affidabilità e obiettivi di sicurezza e vincoli operativi della
missione rispetto all’ambiente fisico e operativo,
• sviluppare la specifica dei requisiti tecnici preliminari,
• identificare i razionali della missione,
• effettuare una valutazione preliminare degli aspetti programmatici supportata da studi di
mercato ed economici, a seconda dei casi,
• eseguire una valutazione preliminare del rischio.
5.3.1.2 Review associate
Mission definition review (MDR). La valutazione di questa review è usata per verificare la maturità
del progetto di passare alla successiva fase A.
L’obiettivo principale della MDR è di rilasciare la mission statement e valutare la specifica preliminare
dei requisiti tecnici e degli aspetti programmatici.
5.3.2 Phase A (Feasibility)
Si tratta di un’attività condotta principalmente dal top level customer e da uno o più fornitori di
primo livello. I risultati di questa fase sono riportati direttamente al project initiator e ai
rappresentanti degli utenti finali per la loro condivisione e approvazione.
• stabilire la versione iniziale del management plan, del system engineering plan e del product
assurance plan di progetto,
• elaborare i razionali di sistema e l’iniziale architettura di sistema per confrontarla con i
bisogni identificati, per individuare eventuali livelli di incertezza e rischi,
• definire l’albero delle funzioni,
• valutare la fattibilità tecnica e programmatica dei possibili concetti identificando i vincoli
relativi all’implementazione, ai costi, alle pianificazioni, all’organizzazione, alle operazioni,
alla manutenzione, alla produzione e allo smaltimento,
• identificare le tecnologie critiche e proporre attività di pre-sviluppo,
• quantificare e caratterizzare elementi critici per fattibilità tecnica ed economica,
• proporre i modelli alla base del sistema e le soluzioni tecniche, inclusa la filosofia del modello
e l’approccio di verifica, da elaborare ulteriormente durante la fase B,
• elaborare la valutazione del rischio.
La Preliminary Requirement Review (PRR). Gli obiettivi principali della PRR sono:
• versione iniziale dei piani di:
o management,

14
o system engineering,
o product assurance,
• specifica dei requisiti tecnici,
• conferma della fattibilità tecnica e programmatica dell’impostazione del sistema,
• selezione di strumenti, tecniche soluzioni tecniche, inclusa la filosofia del modello e
l’approccio di come effettuare le verifiche ed i controlli.
5.3.3 Phase B (Preliminary definition)
• completare e aggiornare la versione iniziale del management plan, del system engineering
plan e del product assurance plan di progetto,
• definire la pianificazione iniziale del progetto (GANTT),
• definire il piano iniziale dei costi,
• definire la struttura organizzativa preliminare (OBS),
• confermare le soluzioni tecniche per il sistema,
• condurre studi "trade-off" e selezionare il concetto di sistema preferito, insieme alle
soluzioni tecniche preferite,
• realizzare la progettazione preliminare del progetto,
• determinare il programma di verifica,
• identificare e definire interfacce esterne,
• preparare le specifiche di livello successivo e i relativi documenti di accordo commerciale,
• avviare lavori di pre-sviluppo su tecnologie critiche o aree di progettazione del sistema,
• iniziare qualsiasi approvvigionamento di articoli,
• preparare il piano di smaltimento dei detriti spaziali,
• sviluppare il piano della sicurezza,
• completare il product tree, la WBS e l’albero delle specifiche,
• finalizzare il project management, engineering and product assurance plan,
• definire la baseline master schedule,
• aggiornare il piano dei rischi.
Sono due le review della fase B:
• la system requirements review (SRR), che ha per obiettivi:
o rilascio dell’aggiornamento delle specifiche dei requisiti tecnici,
o assessment della progettazione iniziale,
o assessment del programma di verifica iniziale.
• la preliminary design review (PDR), che ha per obiettivi:
o verifica della progettazione preliminare del concetto selezionato e delle soluzioni
tecniche individuate per rispondere ai requisiti di progetto e di sistema,
o versione finale dei piani di:
▪ management,
▪ system engineering,
▪ product assurance,
o rilascio del product tree, della WBS e dell’albero delle specifiche,
o rilascio del piano di verifica (inclusa la filosofia del modello).

15
5.3.4 Phase C (Detailed definition)
• realizzazione delle versioni finali della progettazione a tutti i livelli della catena cliente-
fornitore.
• Produzione e sviluppo del piano dei test e dei criteri per la prequalificazione come richiesto
dal modello selezionato per il sistema e dalla strategia di verifica,
• completamento dell’assemblaggio, dell’integrazione e della pianificazione dei test per il
sistema e le sue parti costitutive,
• definizione dettagliata di interfacce interne ed esterne,
• rilascio del preliminare manuale utente,
• aggiornamento del piano dei rischi.
La critical design review (CDR) i cui obiettivi principali sono:
• i piani di qualificazione e di validazione per i critical item,
• la conferma della validità delle interfacce esterne,
• rilascio della progettazione finale,
• rilascio dei piani di assemblaggio, di integrazione e di test,
• rilascio dei prodotti hw/sw di volo e dei loro piani di assemblaggio e test,
• rilascio del manuale utente.
5.3.5 Phase D (Qualification and production)
• completamento delle attività di test e di verifiche,
• completamento della fornitura dell’assemblaggio e del test dell’hw/sw di volo e del relativo
ground segment,
• completamento dei test di interoperabilità tra lo space e il ground segment,
• preparazione dell’acceptance test.
Sono tre:
• la qualification review (QR), che ha per obiettivi:
o confermare che il processo di verifica ha dimostrato che il progetto, inclusi i margini,
soddisfi i requisiti applicabili,
o verificare che le registrazioni di verifica siano complete a tutti i livelli della catena
cliente-fornitore,
o verificare l’accettabilità di tutte le deroghe e deviazioni.
o verificare la configurazione funzionale durante la quale:
o rilasciare dei file master di produzione per le produzioni di serie.
o ottenere l’accettazione, da parte del cliente finale, del file di produzione della serie.
• la acceptance review (AR), che ha per obiettivi:
o confermare che il processo di verifica ha dimostrato che il prodotto è privo di errori
di lavorazione ed è pronto per il successivo utilizzo operativo,
o verificare che le registrazioni di verifica dell’accettazione siano complete a tutti i
livelli della catena cliente-fornitore,

16
o verificare che tutti i prodotti consegnabili siano disponibili secondo l’elenco di articoli
consegnabili approvati,
o verificare il prodotto "as-built" corrisponda al prodotto "as-designed",
o verificare l’accettabilità di tutte le deroghe e le deviazioni.
o verificare che l’Acceptance Data Package sia completo.
o autorizzare la consegna del prodotto.
o rilasciare il certificato di accettazione.
• la operational readiness review (ORR), che ha per obiettivi:
o verificare la disponibilità delle procedure operative e la loro compatibilità con il
sistema di volo,
o verificare la disponibilità dei team operativi,
o accettare e rilasciare il ground segment per le operazioni.
5.3.6 Phase E (Operations/utilization)
• Eseguire tutte le attività a livello di space e ground segment ai fini del lancio della missione,
• condurre tutti i lanci e le operazioni orbitali iniziali,
• eseguire attività di verifica in orbita (compresa la messa in servizio),
• eseguire tutte le operazioni in orbita al fine di raggiungere gli obiettivi della missione,
• esegui tutte le attività proprie del ground segment per sostenere la missione,
• eseguire tutte le altre attività di supporto a terra al fine di sostenere la missione,
• completa il piano di smaltimento.
Sono 4:
• la flight readiness review (FRR) che si consegna prima del lancio, e che ha per obiettivi:
o la revisione che i segmenti di volo e di terra, inclusi tutti i sistemi di supporto come i
sistemi di tracciamento, i sistemi di comunicazione e i sistemi di sicurezza siano
pronti per il lancio,
• la launch readiness review (LRR), che si attua immediatamente prima del lancio, e che ha per
obiettivi:
o verificare la disponibilità al lancio del veicolo di lancio e dei segmenti di spazio e di
terra, compresi tutti i sistemi di supporto come i sistemi di tracciamento, i sistemi di
comunicazione e il sistemi di sicurezza
o fornire l’autorizzazione per procedere al lancio.
• la commissioning result review (CRR), che si attua dopo il completamento delle attività della
fase di messa in orbita, e che ha per obiettivi:
o l’attivazione delle operazioni di routine / utilizzo. Questa review viene eseguita dopo
il completamento di una serie di test in orbita progettati per verificare che tutti gli
elementi del sistema stiano funzionando entro i parametri prestazionali specificati. Il
completamento riuscito di questa revisione viene in genere utilizzato per
contrassegnare il passaggio formale del sistema al project initiator del progetto o
all’operatore del sistema.
• la end-of-life review (ELR) rilasciata a completamento della missione, ha per obiettivi:
o la verifica che la missione abbia completato tutte le operazioni e i servizi previsti,

17
o la verifica che tutti gli elementi posti in orbita siano configurati per permettere il loro
smaltimento in sicurezza.
5.3.7 Phase F (Disposal)
• Implementare il piano di smaltimento.
La mission close-out review (MCR) che ha come obiettivo:
• verificare ed assicurare il completamento con successo di tutte le attività del piano di
smaltimento.

18
6 Allegati
6.1 A- Project management plan (PMP) – DRD
Il PMP si realizza per definire lo scopo della missione e per fornire una breve introduzione al sistema
di gestione del progetto.
6.1.1 Contenuti del documento:
Introduzione
Contiene una descrizione dello scopo, dell’obiettivo e del motivo che ne richiede la preparazione (ad
esempio programma o riferimento e fase del progetto).
Documenti applicabili e di riferimento
Contiene la lista dei documenti applicabili e di riferimento utilizzati per la stesura del PMP.
Obiettivi e vincoli del progetto
Contiene la lista degli obiettivi e dei vincoli funzionali e non funzionali del progetto.
Organizzazione del Progetto
Contiene l’organizzazione del progetto come da §2. In particolare, deve esplicitare:
• Il project manager (sia del cliente, sia del fornitore),
• se il progetto ha collegamenti con altri progetti, ogni cliente e fornitore deve individuare il
responsabile delle relazioni,
• se un cliente o fornitore impiega consulenti o altri specialisti per assisterlo nello svolgimento
delle sue funzioni, devono essere definiti i ruoli, le responsabilità e l’autorità di questi
consulenti e specialisti,
• se il cliente fornisce un prodotto a un fornitore, deve individuare il responsabile di prodotto
per la fornitura.
Project breakdown structures
Il paragrafo contiene la struttura del prodotto (product tree) per tutti i prodotti del progetto. Da
tener presente che:
• le regole per l’identificazione degli articoli del prodotto devono essere uniformi all’interno
dello stesso progetto,
• ogni prodotto deve avere un’identificazione univoca all’interno del product tree,
• l’identificazione deve rimanere invariata durante la vita del prodotto, a meno che una
modifica non causi una interruzione di intercambiabilità,
• l’albero del prodotto deve essere soggetto all’approvazione del cliente,
• l’albero del prodotto deve essere soggetto a controllo di configurazione.
• il fornitore deve stabilire la WBS per il sua parte di lavoro, incorporando la WBS di ciascuno
dei suoi fornitori di livello inferiore, in conformità all’allegato C.
• le funzioni di supporto (gestione, ingegneria, garanzia del prodotto) devono essere
identificabili in relazione ai relativi elementi dell’albero del prodotto,
• la WBS sarà soggetta all’approvazione del cliente,

19
• il fornitore deve evidenziare le descrizioni dei pacchetti di lavoro (WP) della sua WBS in
conformità all’allegato D. Ogni WP deve avere un unico responsabile,
• il fornitore deve individuare la propria OBS di competenza, che include:
o l’interfaccia e le responsabilità contrattuali tra i soggetti coinvolti,
o il personale chiave e le parti responsabili assegnate per ciascuno WP della WBS.
Gestione della configurazione, comunicazione e documentazione
Il paragrafo deve contenere gli strumenti e i metodi adottati per la gestione della configurazione e
della comunicazione tra le parti coinvolte, come definito nell’ECSS-M-ST-40, Allegato A.
Se la gestione della configurazione, la gestione delle informazioni e della documentazione è
contenuta in un piano specifico, allora qui si possono evidenziare gli elementi chiave e fare
riferimento ai documenti piano specifici.
Cost and schedule management
Il paragrafo deve contenere l’approccio di gestione dei costi e della pianificazione, come definito in
ECSS-M-ST-60.
Se la gestione dei costi e dei tempi è contenuta in un piano specifico, allora qui si possono
evidenziare gli elementi chiave e fare riferimento ai documenti specifici del piano.
Integrated logistic support
Il paragrafo deve contenere l’approccio di supporto logistico integrato individuato per il progetto,
come definito in ECSS-M-ST-70.
Risk management
Il paragrafo deve contenere una breve descrizione dell’approccio utilizzato per la gestione del rischio
che sarà descritto in dettaglio nel piano di gestione del rischio a lungo termine, come definito
nell’ECSS-M-ST-80, allegati A e B.
Product assurance management
Il paragrafo deve contenere una breve descrizione dell’approccio utilizzato per la gestione del
product assurance, in genere descritto in dettaglio nel piano di product assurance.
Engineering management
Il paragrafo deve contenere l’approccio di engineering management, compresa la suddivisione
proposta in discipline ingegneristiche e le interfacce tra queste discipline, come definito nell’ECSS-E-
ST-10, allegato D.
Se la gestione di engineering management è contenuta in un piano specifico, allora qui si possono
evidenziare gli elementi chiave e fare riferimento ai documenti specifici del piano.

20
6.2 B - Product tree - DRD
L’obiettivo del documento del product tree (PT) è descrivere, in un singolo documento, la
suddivisione gerarchica di un prodotto consegnabile fino a un livello concordato tra il cliente e il
fornitore.
L’albero del prodotto fa parte della progettazione del progetto. È il punto di partenza per selezionare
gli elementi di configurazione (come specificato in ECSS-M-ST-40) e stabilire la struttura di
ripartizione del lavoro. È una struttura di base per stabilire l’albero delle specifiche (come definito in
ECSS-E-ST-10).
Introduzione
Contiene una descrizione dello scopo e degli obiettivi del documento (per esempio, fasi e riferimenti
del progetto)
Contiene la lista dei documenti applicabili e di riferimento utilizzati per la stesura del PT.
Tree structure
Il PT fornisce la scomposizione dei prodotti di livello inferiore che costituiscono il prodotto
consegnabile. Per ogni articolo identificato nell’albero del prodotto, devono essere fornite le
seguenti informazioni:
• codice di identificazione,
• nome dell’elemento,
• fornitore,
• specifica applicabile.
Il PT deve essere presentato o sotto forma di diagramma grafico o forma di una struttura indentata
dove il prodotto finale (cioè al livello superiore dell’albero) viene scomposto in prodotti di livello
inferiore.
Ogni articolo prodotto selezionato come elemento di configurazione deve essere identificato
nell’albero del prodotto. Quando vengono utilizzati prodotti ricorrenti da precedenti progetti spaziali,
questi devono essere identificati nella struttura ad albero.

21
6.3 C - Work breakdown structure (WBS) – DRD
L’obiettivo della WBS è fornire, in un singolo documento, un quadro di assieme del progetto
relativamente alle attività di gestione dei costi e dei tempi (come definito nell’ECSS M ST-60) e per la
gestione del contenuto tecnico. La WBS è utile a tutti gli attori del progetto per:
comparare diverse offerte di gara e gestire, di conseguenza, negoziazioni tra i fornitori,
ottimizzare la distribuzione del lavoro tra i diversi fornitori;
monitorare il programma del progetto.
Informazioni sulla determinazione del livello appropriato di dettaglio in WP della WBS fare
riferimento al documento ECSS-M-ST-10, allegato H.
Introduzione
Contiene una descrizione dello scopo e degli obiettivi del documento (per esempio, fasi e riferimenti
del progetto)
Contiene la lista dei documenti applicabili e di riferimento utilizzati per la stesura del PT.
Tree structure
La WBS deve fornire una ripartizione logica ed esaustiva degli elementi della struttura del prodotto,
che include le funzioni di supporto definite dal cliente (ad esempio gestione del progetto, ingegneria,
supporto alla garanzia del prodotto) necessarie per produrre i prodotti finali (modelli di sviluppo e di
volo) e i servizi necessari al progetto. Deve essere utilizzato uno schema di codifica per gli elementi
WBS che rappresenta la struttura gerarchica quando viene visualizzato in formato testo.
Deve essere individuato un sistema di codifica comune per facilitare le comunicazioni tra tutti gli
attori del progetto,
La WBS identificherà tutti i WP di controllo. I pacchetti di lavoro di controllo possono essere
ulteriormente suddivisi dal fornitore in diversi pacchetti di lavoro più dettagliati.
L’insieme dei pacchetti di lavoro deve coprire l’intero ambito di lavoro.

22
6.4 D - Work package (WP) description – DRD
L’obiettivo dei WP è descrivere il contenuto dettagliato di ciascun elemento della WBS come definito
nell’ECSS-M-ST-10, allegato C.
La descrizione del WP deve contenere i seguenti elementi:
• nome del progetto e fase del progetto,
• Titolo WP,
• identificazione univoca di ciascun WP e numero di rilascio,
• fornitore o entità responsabile delle prestazioni del WP,
• Nome e organizzazione del responsabile del WP,
• paese del fornitore,
• link al PT,
• descrizione degli obiettivi del WP,
• descrizione dei compiti,
• elenco degli input necessari per raggiungere i compiti,
• interfacce o collegamenti con altre attività o WP,
• elenco di vincoli, requisiti, norme e regolamenti,
• lista delle uscite previste,
• lista di prodotti,
• luogo di consegna,
• evento di avvio del WP, compresa la data,
• evento di fine del WP, compresa la data,
• compiti esclusi.

23
6.5 E - Progress report – DRD
L’obiettivo del Progress report (PR), anche detto Stato Avanzamento Lavori (SAL), è fornire a tutti gli
attori del progetto evidenza reale sullo stato del progetto.
È una fotografia hic et nunc del progetto.
Il PR deve contenere le seguenti informazioni:
• la valutazione, da parte del responsabile di progetto, della situazione attuale in relazione alle
previsioni e ai rischi, ad un livello di dettaglio concordato tra i soggetti interessati,
• lo stato di avanzamento del lavoro eseguito dal fornitore,
• stato e previsioni sulle prestazioni chiave concordate e sui parametri chiave di progettazione,
• evidenza di andamenti e scostamenti negativi nelle prestazioni tecniche e programmatiche e
proposte di azioni correttive,
• aggiornamento della pianificazione ed evidenza di eventuali azioni correttive da
intraprendere,
• un rapporto consolidato che scaturisce dai rapporti sullo stato dei fornitori di livello inferiore,
• progressi su tutte le azioni a partire dal precedente PR.
Output del PR è la conferma della baseline di progetto o il suo aggiornamento in una nuova baseline.

24
6.6 F - ECSS management branch documents delivery per review
La Tabella F-1 fornisce le informazioni relative ai documenti deliverable delle diverse fasi di un
progetto spaziale.
Questa tabella costituisce una prima indicazione per il contenuto del pacchetto di dati in varie
revisioni. Il contenuto completo di tale pacchetto di dati è stabilito come parte dell’accordo
commerciale, che definisce anche la consegna del documento tra recensioni.

25
6.7 G -Documenti periodici o a seguito del verificarsi di un incidente
La Tabella G-1 elenca i documenti periodici o a seguito del verificarsi di un incidente.

26
6.8 H - WBS livello di dettaglio
La principale sfida associata allo sviluppo della WBS è quella di determinare il bilanciamento tra la
necessità di suddivisione il progetto in parti più elementari e le attività necessarie alla raccolta e al
reporting delle parti stesse. Un livello eccessivo di WBS può portare a livelli di manutenzione e
reporting non realistici e, di conseguenza, a un progetto inefficiente e costoso.
Tra le diverse domande che sorgono quando si sviluppa una WBS, una importante è: la WBS
dovrebbe essere ulteriormente scomposta?
Una possibile guida potrebbe essere il seguente elenco di domande. Se alla maggior parte delle
domande è possibile rispondere SÌ, l’elemento WBS analizzato dovrebbe essere scomposto. Al
contrario, se alla maggior parte delle domande è possibile rispondere NO, non è necessario. Se le
risposte sono approssimativamente 50/50, è necessario un ulteriore giudizio.
• È necessario migliorare la valutazione delle stime dei costi o della misurazione dei progressi
dell’elemento della WBS?
• C’è più di un responsabile per l’elemento della WBS?
• Il contenuto dell’elemento della WBS include più di un tipo di processo di lavoro o produce
più di un risultato finale?
• È necessario valutare i tempi dei processi di lavoro interni all’elemento della WBS?
• È necessario valutare il costo dei processi di lavoro o dei deliverable interni all’elemento
WBS?
• Ci sono relazioni tra i deliverable di due o più elementi della WBS?
• Vi sono significative lacune temporali nell’esecuzione dei processi di lavoro interne
all’elemento WBS?
• I requisiti delle risorse cambiano nel tempo all’interno di un elemento WBS?
• Esistono criteri di accettazione che portano a risultati intermedi, applicabili prima del
completamento dell’intero elemento WBS?
• Esistono rischi identificati che richiedono un’attenzione specifica per un sottoinsieme
dell’elemento WBS?
• Un sottoinsieme del lavoro da eseguire all’interno dell’elemento della WBS può essere
organizzato come un’unità separata?

27
7 Bibliography
ECSS-S-ST-00 ECSS system – Description, implementation and general
requirements
ECSS-E-ST-10 Space engineering – System engineering general
requirements
ECSS-E-ST-40 Space engineering – Software general requirements
ECSS-E-ST-70 Space engineering – Ground systems and operations
ECSS-M-ST-10-01 Space project management – Organization and conduct of
reviews
ECSS-M-ST-60 Space project management – Cost and schedule
management
ECSS-M-ST-70 Space project management – Integrated logistic support
ECSS-M-ST-80 Space project management – Risk management
ECSS-Q-ST-10 Space product assurance – Product assurance
management

Project planning and implementation according ECSS ST-M-10

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Project planning and implementation according ECSS ST-M-10

Ähnlich wie Project planning and implementation according ECSS ST-M-10 (20)

Mehr von Mario Gentili

Mehr von Mario Gentili (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (16)

Project planning and implementation according ECSS ST-M-10