Vanadia Marco - Tesi Di Laurea Ingegneria Informatica - Politecnico Di Bari

Politecnico di Bari
DIPARTIMENTO DI INGEGNERIA ELETTRICA E DELLINFORMAZIONE

Corso di Laurea Triennale in Ingegneria Informatica e dellAutomazione
Tesi in Ingegneria del Software
Sviluppo software di gestione dei processi di garanzia di qualita` e

tracciamento delle non conformita` di progetti dellindustria
aerospaziale secondo gli standard ECSS/ESA
Relatore: Candidato:
Prof.ssa Ing. Marina Mongiello Marco Vanadia
Matricola 509591
Correlatore:
Dott. Ing. Francesco Nocera
Anno Accademico 20152016

Questo documento stato rilasciato con licenza Creative Commons Attribu-
zione Non commerciale Non opere derivate 4.0 Internazionale c b e d (CC
BY-NC-ND 4.0). Per leggere il testo integrale della licenza si pu visitare il sito
web https://creativecommons.org/licenses/by-nc-nd/4.0/legalcode o spedi-
re una lettera a Creative Commons, 171 Second Street, Suite 300, San Francisco,
California, 94105, USA. Il testo anche disponibile in italiano, in formato ridotto,
allindirizzo web https://creativecommons.org/licenses/by-nc-nd/4.0/deed.
it.
La tesi stata scritta in LATEX sul sistema operativo Linux Mint Debian Edition
(LMDE) con distribuzione TEXLive 2016 e Microsoft Windows con distribuzione
MiKTeX 2.9 e editor di testo TexStudio 2.12 con classe classisthesis [Mie13] e mo-
difiche ArsClassica[Pan11], grazie alle guide del Gruppo Utilizzatori Italiano di
TEXe LATEXdel forum del guIt e allo scambio virtuoso di aiuti della comunit di
http://tex.stackexchange.com/.
Le eccezionali immagini dellESA utilizzate per gli inserti sono rilasciate pub-
blicamente sul portale ESA sotto licenza Creative Commons c b aAttribuzione
Condividi allo stesso modo 3.0 IGO. Per leggere il testo integrale della licenza
si pu visitare il sito allindirizzo web https://creativecommons.org/licenses/
by-sa/3.0/igo/.
Limmagine che presenta il Processo Unificato di Sviluppo Iterativo ed Evoluti-
vo unopera di M. C. Escher, Rettili, litografia del 1943.
La fotografia della Terra nel prologo stata ripresa il 7 dicembre 1972 da Harri-
son Schmitt o Ron Evans dellequipaggio della missione NASA/Apollo 17 diretto
verso la Luna, da una distanza di circa 29.000 km.
possibile scaricare lintero codice sorgente di questo documento, compre-
si i codici scritti per realizzare le figure, allURL https://github.com/mova77/
poliba-tesi-triennale.
Marco Vanada,
Bari, 28 marzo 2017
Dedicato a Giulia.
Nessun calcolatore 9000 ha mai commesso un errore o alterato uninformazione.
Noi siamo, senza possibili eccezioni di sorta, a prova di errore, incapaci di sbagliare.
elaboratore Hal 9000
2001: A Space Odyssey
Stanley Kubrick, 1968
,
So di non sapere
Socrate
INDICE
prologo xvii
i processo unificato xxiii

processo unificato xxv
1 Elaborati delle Discipline UP . . . . . . . . . . . . . . . . . . . xxvii
.
1 visione 3
1.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Opportunit di business . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Formulazione del problema . . . . . . . . . . . . . . . . . . . . 5
1.4 Concorrenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Parti interessate . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Stima dello sforzo di sviluppo (Modello COCOMO II) . . . . . 11
2 regole di dominio 15
2.1 Gli standard ECSS . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Principi di Garanzia di Prodotto . . . . . . . . . . . . . . . . . . 17
2.3 Principi di Garanzia di Qualit . . . . . . . . . . . . . . . . . . 19
2.4 Principi per sistemi di controllo delle non conformit . . . . . 20
2.5 Principi di gestione della configurazione e dellinformazione . 23
3 glossario 27
3.1 Termini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Termini abbreviati . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 Dizionario dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 modello dei casi duso 45
4.1 Casi duso di Account Management . . . . . . . . . . . . . . . . 46
4.2 Casi duso di Project Management . . . . . . . . . . . . . . . . 50
4.3 Casi duso di Action Item Management . . . . . . . . . . . . . 56
4.4 Casi duso di Meeting Management . . . . . . . . . . . . . . . . 59
4.5 Casi duso di Document Management . . . . . . . . . . . . . . 62
4.6 Casi duso di Configuration Management . . . . . . . . . . . . 66
4.7 Casi duso di Inspection Report Management . . . . . . . . . . 72
4.8 Casi duso di Non Conformance Report Management . . . . . 75
5 specifiche supplementari 83
5.1 Requisiti FURPS+ . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.2 Fattori architetturali . . . . . . . . . . . . . . . . . . . . . . . . . 91
6 modello di dominio 97
6.1 Modellazione classi concettuali . . . . . . . . . . . . . . . . . . 98
6.2 Modellazione macchine a stati . . . . . . . . . . . . . . . . . . . 102
7 modello dei dati 105
7.1 Modello concettuale . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.2 Normalizzazione modello concettuale . . . . . . . . . . . . . . 120
7.3 Mappatura da modello concettuale a modello logico relazionale124
vii
viii indice
8 architettura software 129

8.1 Rappresentazione architetturale . . . . . . . . . . . . . . . . . . 129
8.2 Decisioni architetturali . . . . . . . . . . . . . . . . . . . . . . . 129
9 modello di implementazione 133
9.1 Schema relazionale SQL . . . . . . . . . . . . . . . . . . . . . . 133
10 piano di sviluppo del software 147
10.1 Piano delle Fasi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
ii appendici 149
esa space engineering 151
bibliografia 157
ELENCO DELLE FIGURE
Figura 1 ESA Concurrent Design Facility . . . . . . . . . . . . . xix

Figura 2 Discipline del Processo Unificato . . . . . . . . . . . . x . xvi
Figura 3 Discipline del sistema degli standard ECSS . . . . . . . 17
Figura 4 Attivit di Configuration Management . . . . . . . . . 24
Figura 5 Diagramma UML casi duso di Account Management 46
Figura 6 Diagramma UML casi duso di Project Management 51
Figura 7 Diagramma UML casi duso di gestione Action Item . 56
Figura 8 Diagramma UML casi duso di gestione Meeting . . . 59
Figura 9 Diagramma UML casi duso di Document Manage-
ment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figura 10 Diagramma UML casi duso di Configuration Ma-
nagement . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figura 11 Diagramma UML casi duso di gestione Inspection
Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Figura 12 Diagramma UML casi duso di gestione Non Con-
formance Report . . . . . . . . . . . . . . . . . . . . . 76
Figura 13 Diagramma UML delle classi concettuali Account
Management . . . . . . . . . . . . . . . . . . . . . . . . 98
Figura 14 Diagramma UML delle classi concettuali Project Ma-
nagement . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Figura 15 Diagramma UML delle classi concettuali Meeting e
Action Item Management . . . . . . . . . . . . . . . . 99
Figura 16 Diagramma UML delle classi concettuali Document
Management . . . . . . . . . . . . . . . . . . . . . . . . 99
Figura 17 Diagramma UML delle classi concettuali Inspection
Report Management . . . . . . . . . . . . . . . . . . . 100
Figura 18 Diagramma UML delle classi concettuali Configu-
ration Management . . . . . . . . . . . . . . . . . . . 100
Figura 19 Diagramma UML delle classi concettuali Noncon-
formance Report Management . . . . . . . . . . . . 101
Figura 20 Diagramma UML macchina a stati Action Item . . . . 102
ix
E L E N C O D E L L E TA B E L L E
Tabella 2 Architettura moduli e servizi di Sapienza ECLIPSE . . 6

Tabella 3 Obiettivi e problemi fondamentali per le parti inte-
ressate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Tabella 4 Attori e loro interessi nel sistema . . . . . . . . . . . . . 10
Tabella 5 COCOMO II.2000 Early Design Model . . . . . . . . . . 11
Tabella 6 paradigma dei riferimenti a documenti e record . . . . 41
Tabella 7 Elenco tipi di documento . . . . . . . . . . . . . . . . . 123
Tabella 8 Piattaforme Businees Process Management (BPM) . . . 130
ELENCO DEI CODICI
Codice 1 Definizione schema SQL . . . . . . . . . . . . . . . . . . 133
ELENCO CASI DUSO
UC1 Manage Account . . . . . . . . . . . . . . . . . . . . . . . . . 46

UC2 Manage Company . . . . . . . . . . . . . . . . . . . . . . . . . 48
UC3 Manage Custom Information . . . . . . . . . . . . . . . . . . 49
UC4 Manage Personal Information . . . . . . . . . . . . . . . . . 50
UC5 Manage Project . . . . . . . . . . . . . . . . . . . . . . . . . . 50
UC6 Manage Repository . . . . . . . . . . . . . . . . . . . . . . . . 52
UC7 Manage Project Members . . . . . . . . . . . . . . . . . . . . 53
UC8 Manage Roles and Permissions . . . . . . . . . . . . . . . . . 54
UC9 Manage Reference Paradigm . . . . . . . . . . . . . . . . . . . 55
UC10 Manage Action Item . . . . . . . . . . . . . . . . . . . . . . . 56
UC11 Work on Action Item . . . . . . . . . . . . . . . . . . . . . . . 58
UC12 Manage Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . 59
UC13 Review Minutes of Meeting . . . . . . . . . . . . . . . . . . . 61
UC14 Manage Document . . . . . . . . . . . . . . . . . . . . . . . . 62
UC15 Review Document . . . . . . . . . . . . . . . . . . . . . . . . . 64
UC16 Apply Digital Sign . . . . . . . . . . . . . . . . . . . . . . . . . 66
UC17 Navigate Product Tree . . . . . . . . . . . . . . . . . . . . . . 66
UC18 Manage Configuration Item . . . . . . . . . . . . . . . . . . . 68
UC19 Manage Part and Assembly . . . . . . . . . . . . . . . . . . . 70
UC20 Manage Manufactured Part . . . . . . . . . . . . . . . . . . . 71
UC21 Manage Inspection Report . . . . . . . . . . . . . . . . . . . . 72
UC22 Close Inspection Report . . . . . . . . . . . . . . . . . . . . . 75
UC23 Manage Non Conformance Report . . . . . . . . . . . . . . . 75
UC24 Review Non Conformance Report . . . . . . . . . . . . . . . 79
E L E N C O E N T I T / R E L A Z I O N I
ER1 Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

ER2 Employee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
ER3 Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
ER4 Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
ER5 Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
ER6 Reference Template . . . . . . . . . . . . . . . . . . . . . . . . 107
ER7 Employment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
ER8 Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
ER9 ActionItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
ER10 Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
ER11 Meeting_Attendant . . . . . . . . . . . . . . . . . . . . . . . . 109
ER12 Meeting_ActionItem . . . . . . . . . . . . . . . . . . . . . . . 110
ER13 Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
ER14 Document_Author . . . . . . . . . . . . . . . . . . . . . . . . 110
ER15 Document_Revisor . . . . . . . . . . . . . . . . . . . . . . . . 111
ER16 ConfigurationItem . . . . . . . . . . . . . . . . . . . . . . . . 111
ER17 ConfigurationItem_Responsible . . . . . . . . . . . . . . . . . 111
ER18 ConfigurationItem_Attachment . . . . . . . . . . . . . . . . 112
ER19 Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
ER20 Part_Attachment . . . . . . . . . . . . . . . . . . . . . . . . . 113
ER21 Material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
ER22 Part_Material . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
ER23 Finishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
ER24 Part_Finishing . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
ER25 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
ER26 Part_Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
ER27 Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
ER28 Part_Property . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
ER29 ManufacturedPart . . . . . . . . . . . . . . . . . . . . . . . . 115
ER30 Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
ER31 InspectionReport . . . . . . . . . . . . . . . . . . . . . . . . . 116
ER32 InspectionReport_ActionItem . . . . . . . . . . . . . . . . . . 116
ER33 NonConformanceReport . . . . . . . . . . . . . . . . . . . . . 117
ER34 NCR_Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
ER35 NCR_Witness . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
ER36 NCR_ReviewBoardMeeting . . . . . . . . . . . . . . . . . . . . 118
ER37 NCR_ActionItem . . . . . . . . . . . . . . . . . . . . . . . . . 118
ER38 NCR_ConfigurationItem . . . . . . . . . . . . . . . . . . . . . 119
ER39 NCR_Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
ER40 NCR_ManufacturedPart . . . . . . . . . . . . . . . . . . . . . 119
ER41 PhoneNumber . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
ER42 EmailAddress . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
ER43 Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
ER44 CustomField . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
ER45 Employee_PhoneNumber . . . . . . . . . . . . . . . . . . . . . 122
ER46 Employee_EmailAddress . . . . . . . . . . . . . . . . . . . . . 122
ER47 Employee_CustomField . . . . . . . . . . . . . . . . . . . . . . 122
xi
SOMMARIO
Il caso di studio oggetto di Tesi lesecuzione del Processo Unifica-

to di ingegneria del software per lanalisi e progettazione orientata agli
oggetti di un sistema software di gestione di progetti a supporto dei pro-
cessi di garanzia di qualit e tracciamento delle non conformit dei pro-
dotti dellindustria aerospaziale secondo gli standard dellEuropean Space
Agency (ESA).
ABSTRACT
Unified Process Software Engineering of Project Management System

for Quality Assurance and Non-conformance Control of Space Engineer-
ing Products on European Space Agency requirements
xiii
Homo faber fortunae suae
(loc. latina)1
Il filosofo artefice del proprio destino.
visione delluomo di Giordano Bruno
Naturalmente, vi sono casi in cui solo un individuo fuori dal comune

avr la percezione di un sistema che condiziona la vita di molte persone,
un sistema che prima di allora non era stato nemmeno riconosciuto come tale;
individui del genere spesso dedicano la loro vita a convincere gli altri
che quel sistema esista realmente, e che se ne dovrebbe uscire!
Gdel, Escher, Bach: uneterna ghirlanda brillante
Douglas R. Hofstadter[Hof90]
RINGRAZIAMENTI
Ringrazio la mia famiglia senza il cui sostegno non sarei mai potuto
arrivare a concludere questo lungo percorso.
Bari, 28 marzo 2017

Marco Vanada
1 rielaborazione di Faber est suae quisque fortunae, Epistulae ad Caesarem senem de re pubblica
(De rep., 1, 1, 2) attribuita nellopera di Sallustio al console Appio Claudio Cieco
xv
PROLOGO
Sostenere e promuovere, per scopi esclusivamente pacifici,

la cooperazione tra gli Stati europei nella ricerca e tecnologia spaziale
e loro applicazioni, con lintento di usarle per scopi scientifici e operativi
Art.2 Convenzione dellESA
(30 ottobre 1980)
Oggi le attivit spaziali sono volte al servizio dei cittadini, ed i cittadini

chiedono un miglioramento della loro qualit della vita sulla Terra.
Desiderano sicurezza e benessere economico, ma
desiderano anche di poter sognare,
per poter incrementare le loro conoscenze e
per poter invogliare le nuove generazioni ad
interessarsi della scienza e della tecnologia.
Jean-Jacques Dordain
(direttore generale ESA dal 2003 al 2015)
Lo Spazio la frontiera dellumanit.
Il mio progetto di Tesi ispirato dalla curiosit umana, dal piacere del-
la scoperta e dal desiderio di mettere in campo tutta la passione per la
scienza e la tecnologia e applicare le conoscenze acquisite di ingegnere
informatico ad un caso di business reale e poter dare il mio contributo a
spingere oltre la frontiera.
Le attivit dellAgenzia Spaziale Europea, organizzazione internazio-
nale fondata nel 1975 per lo sviluppo dei progetti spaziali di 22 Stati Mem-
bri, hanno ricadute nelle nostre vite: dalle previsioni meteo alle comuni-
cazioni cellulari e satellitari, ai sistemi di posizionamento e navigazione
delle flotte, allosservazione della terra, al supporto allagricoltura, alla
sperimentazione scientifica nei materiali e scienze della vita.
Il nostro futuro dipende dalla gestione oculata delle risorse del nostro
pianeta e capire le interazioni complesse dellintera ecosfera richiede una
prospettiva globale che solo lo spazio pu dare. Le nostre conoscenze
sul cambiamento climatico, limpatto delle attivit umane nellatmosfera,
come il buco nello strato di ozono, sono possibili solo da misure effettuate
dallo spazio. I satelliti meteo da soli fanno risparmiare centinaia di milioni
xvii
xviii prologo
di euro ogni anno, e i lanciatori spaziali che li mettono in orbita triplicano

i ritorni dellinvestimento.
Guardando pi lontano e in profondit, gli astronomi, assieme ai fisici
delle alte energie, sono gli esseri umani che pi e meglio di altri stanno
comprendendo la struttura dellUniverso e quindi noi stessi.
I programmi dellESA per le osservazioni della Terra, i lanciatori, la ricer-
ca scientifica, le applicazioni umane e il volo spaziale pongono idealmente
lEuropa in prima linea nelle sfide tecnologiche, politiche e ambientali del
mondo del futuro.
Negli anni a venire, ci sar spazio per gli ingegneri che vogliano accetta-
re la sfida su quattro aree principali: la ricerca della conoscenza scientifica,
migliorare la qualit della vita, fare parte delleccellenza nellindustria eu-
ropea, superare le frontiere di ogni genere nellUnione europea e le nazioni
del mondo.
Come Esploratori su questa Terra, che da lass. . .
. . . bellissima, senza frontiere n confini

Jurij Alekseevic Gagarin
primo uomo nello Spazio (12 aprile 1961)
Marco Vanada
prologo xix
evoluzione dellingegneria dei sistemi spaziali

La progettazione e produzione di sistemi spaziali coinvolge una moltitu-
dine di discipline ingegneristiche ognuna con la sua visione del sistema da
realizzare, con i suoi modelli e processi di analisi, progettazione, verifica e
validazione.
Per elaborare un modello consistente del sistema necessario integrare
lingegneria dei sistemi in differenti domini specifici: ingegneria mecca-
nica, sistemi di propulsione, sistemi di guida e navigazione, controllo di
orbita e assetto, ingegneria termica, aerotermodinamica, effetti dellam-
biente spaziale, ingegneria elettrica e elettronica, comunicazione e sensori
in radio frequenza, avionica, ingegneria del software, ingegneria dei re-
quisiti, gestione dati, ingegneria gestionale, gestione operazioni, gestione
di progetto, pianificazione e logistica, stima dei costi, gestione e controllo
della qualit.
Nel 1996 lESA, ha costruito apposite strutture per consentire a team di Concurrent
esperti di diverse discipline di applicare i metodi dellingegneria concor- Design Facility
rente alla progettazione delle future missioni spaziali: le Concurrent Desi-
gn Facility (CDF)[12], simili per concezione a quelle ispirate dal progetto
TeamX della NASA/JPL. Equipaggiate con reti di computer, dispositivi
multimediali e strumenti software, facilitano la rapida e efficace interazio-
ne di ingegneri esperti in ogni dominio, per assicurare risultati consistenti
e di qualit in tempi minori.
Pochi anni prima, nel 1993, stata istituita lorganizzazione European European
Cooperation for Space Standardization (ECSS) per formalizzare i requisiti Cooperation for
Space
per i progetti spaziali e costituire un singolo e coerente insieme di standard
Standardization
normativi per tutti i sistemi spaziali sviluppati e operanti in Europa. (ECSS)
La standardizzazione lo strumento per ridurre i rischi, i costi e mi-
gliorare sia la qualit che lesecuzione dei programmi spaziali. Ladozione
di standard aperti lunica scelta razionale al problema del miglioramen-
to nei processi di gestione industriali e alla produzione, comunicazione e
verifica delle informazioni; non ragionevole forzare ladozione di nuovi
strumenti e procedure in un settore verticale come lindustria aerospaziale
costituita da una costellazione di imprese, incluse piccole e medie imprese,
Figura 1: ESA Concurrent Design Facility, ESTEC in Noordwijk, Olanda. ESA

c
xx prologo
e consorzi, istituti di ricerca e universit.

La definizione degli standard promuove linnovazione tecnologica e la
ricerca di nuove soluzioni e sviluppo di strumenti capaci di governare la
complessit.
Lo scopo del sistema di standardizzazione ECSS definire e sviluppare
un insieme consistente di requisiti, pi di 20 mila, e principi per linge-
gneria dei sistemi spaziali, la gestione dei progetti e la garanzie di qualit
e sostenibilit. Gli standard coprono ogni disciplina dallingegneria dei
sistemi hardware, al software, ai processi e le attivit di progettazione spa-
ziale, la pianificazione e gestione dei costi e dei rischi nellintero ciclo di
vita dei progetti, il controllo di qualit per garantire la sicurezza, lintegrit
funzionale, la compatibilit, la sostenibilit di tutti gli elementi di progetto
(fig. 3 a pagina 17).
Alba Informatica Nonostante mezzo secolo dagli albori dellEra Informatica, e lincredi-
bile rivoluzione digitale esplosa negli anni 90, con la diffusione pervasi-
va del personal computing e il World Wide Web, gli strumenti disponibili
per produrre, comunicare e scambiare le informazioni sono risultati ina-
deguati nella gestione di progetti industriali che coinvolgono decine di
organizzazioni e migliaia di addetti.
Sistemi Lutilizzo di strumenti come word processor, fogli di calcolo e posta
informativi elettronica, per quanto abbiano incrementato lefficienza dei singoli, sono
documentbased
sistemi informativi incentrati sui documenti che presentano questi incon-
venienti:
spesso sono causa di duplicazione dei dati, rischio di inconsistenze

e controlli manuali inefficienti e proni allerrore;
il contenuto e la forma di presentazione sono strettamente legate e

fisse, non possibile ottenere pi viste degli stessi dati;
la creazione di riferimenti incrociati allinterno di un documento e

tra documenti diversi e in diversi formati unoperazione manuale;
difficoltosa lestrazione affidabile dellinformazione da parte di

strumenti automatici;
i metadati sono impliciti non processabili dalle macchine.
La documentazione redatta in formato ipertestuale e multimediale e i

pi recenti sistemi di gestione delle configurazioni e il controllo di versione
hanno mitigato il problema, quando questo circoscritto allarea ristretta
di una disciplina ingegneristica, ma risultano ancora inadeguati per gestire
la complessit di decine di discipline che devono concorrere in un progetto
spaziale di unimpresa distribuita.
Le organizzazioni utilizzano strumenti diversi per motivi strategici, sto-
rici e culturali. Ognuna adotta i propri processi specializzati e gli strumen-
ti allo stato dellarte nel proprio dominio specifico o secondo le proprie
possibilit. Spesso i subappaltatori sono costretti ad utilizzare tecnolo-
gie e procedure diversificate per adeguarsi a vari capocommessa. Inoltre
prologo xxi
spesso i progetti spaziali hanno lunga durata, misurata in anni, e raramen-

te possibile forzare un cambiamento in corso dopera allinterno di una
organizzazione o tra organizzazioni diverse.
Il trend di ricerca degli ultimi anni, in molti domini industriali, e in parti- Model-based
colare nella comunit aerospaziale, si diretto verso ladozione del nuovo System
Engineering
paradigma del Model-based System Engineering (MBSE) per lingegne-
ria concorrente e collaborativa multidisciplinare di ingegneria dei siste-
mi. La definizione data dallInternational Council on Systems Engineering
(INCOSE):
Model-based systems engineering (MBSE) is the formalized appli-

cation of modeling to support system requirements, design, analysis,
verification and validation activities beginning in the conceptual desi-
gn phase and continuing throughout development and later life cycle
phases. INCOSE SE Vision 2020 (INCOSE-TP-2004-004-02),
Sept. 2007
I vantaggi dellapproccio basato sui modelli semantici sono: Sistemi

informativi
possibilit di costituire fonti coese di dati e informazioni per ridurre modelbased
le inconsistenze;
contenuti e presentazione disaccoppiati;
la possibilit di realizzare viste multiple degli stessi dati, specifiche

di ogni disciplina;
la creazione automatica di collegamenti tra entit del modello;
la generazione automatica di documentazione di report;
lestrazione automatica affidabile dellinformazione;
la memorizzazione esplicita di metadati processabili meccanicamen-

te;
la possibilit di trasformare i modelli in ulteriori modelli per ottenere

nuovi livelli di complessit e automazione.
Nel 2010 e 2011 ECSS ha lanciato due iniziative complementari per la

standardizzazione dei modelli concettuali dei dati secondo il MBSE pub-
blicando i Technical Memorandum (TM) ECSS-E-TM-23A Space system
data repository e ECSS-E-TM-25A Engineering design model data exchange
(CDF).
Un modello definito in ECSS come una rappresentazione fisica o astratta
di aspetti rilevanti di un elemento o un processo[ECSS-S-ST-00-01C] e pu
riferirsi a istanze di un prodotto, a modelli statici o strutturali, a modelli
dinamici o funzionali, a modelli dei dati e metamodelli, a modelli di
infrastrutture per la modellazione, a modelli di processi.
xxii prologo
Entrambe i TM hanno lo scopo di costruire il consenso nella comuni-

t industriale aerospaziale europea circa la necessit di adottare un cam-
bio di paradigma nei processi e nella gestione dei dati per ottenere un
efficiente ed efficace ingegnerizzazione concorrente e collaborativa multi
disciplinare di sistemi spaziali.
Lo standard ECSS-E-TM-25A Engineering design model data exchange
Engineering (CDF) si focalizza sui requisiti e i principi alla base dello scambio e condi-
design model data visione dei dati nelle fasi Phase 0 e A di progettazione concorrente. Lam-
exchange
biente Open Concurrent Design Server (OCDS) la prima implementa-
zione di questo TM che ha lo scopo di definire il modello concettuale e
architetturale dei sistemi di scambio dei dati, le discipline e i ruoli e tutte
le propriet di tali sistemi.
Space system data Lo standard ECSS-E-TM-23A Space system data repository stabilisce le
repository specifiche formali del modello concettuale dei dati, per lintero ciclo di
vita di un progetto di sistema spaziale, e la struttura semantica dei da-
ti di ingegneria dei sistemi. Il progetto Virtual Spacecraft Design (VSD)
stato il prototipo per lapplicazione dei principi dellapproccio model
based necessario per valutare i potenziali miglioramenti del processo di
progettazione dei sistemi basato su modelli semantici.
Conceptual Data Per ottenere linteroperabilit semantica tra applicazioni software distri-
Model buite, il modello concettuale di ogni applicazione deve essere conforme al
modello specificato nello standard. Sono definite le interfacce di dati stan-
dardizzate e indipendenti da ogni specifica piattaforma in modo tale da
consentire linteroperabilit tra archivi dati space system data repository
gestiti da diverse parti interessate.
Il modello concettuale dei dati una mappa della conoscenza che mette
in relazione tipi di oggetti, con le loro caratteristiche e propriet. La cono-
scenza di istanze particolari espressa in termini di relazioni elementari,
vincoli e regole di inferenza. Tutti gli elementi di un sistema spaziale sono
mappati: i requisiti, la decomposizione funzionale, architetturale e struttu-
rale, la definizione delle interfacce, dei processi operativi. Ogni disciplina
coinvolta nei processi di progettazione e validazione di un progetto spa-
ziale stabilisce i propri modelli concettuali per formare una rete semantica
o ontologia.
Parte I
P R O C E S S O U N I F I C ATO
Caso di Studio
Sviluppo Software
oevolu rat
ivoevo
iv
tiv lu
olutivoite
ti v
o it e r a t
oi oi
te te
ra r
ev t
iv
oe
vo
lutiv
ol lu
oev
ut tiv
iv oit
o
o e r a ti v
ev
iter o
a ti v
P R O C E S S O U N I F I C ATO
Vediamo che la programmazione unarte,

perch richiede conoscenza, applicazione, abilit e ingegno,
ma soprattutto per la bellezza degli oggetti che produce.
Donald Ervin Knuth
Il Processo Unificato applicato nella presente Tesi disciplina le attivit

di sviluppo di sistemi software fondate sullanalisi e progettazione orien-
tata agli oggetti. Lanalisi parte dallindagine del problema e dalla raccolta
dei requisiti guidata dallassegnazione di responsabilit agli oggetti del
dominio. La progettazione definisce larchitettura degli oggetti software
che collaborano per soddisfare tali requisiti.
Il ciclo di sviluppo procede per iterazioni successive di durata prefissata
nelle quali si eseguono un insieme di attivit afferenti a diverse discipline
(fig. 2).
Ogni attivit produce elaborati che vengono ampliati e raffinati ad
ogni iterazione. Il sistema sviluppato cresce in modo incrementale e adat-
tivo: i modelli di analisi e progettazione si evolvono, si arricchiscono e
raffinano sulla base di feedback continui ad ogni iterazione.
La pianificazione delle iterazioni di sviluppo guidata dal rischio: si
anticipa lidentificazione e la ricerca delle soluzioni architetturali e proget-
tuali che possano attenuare i rischi maggiori.
Le iterazioni del ciclo di sviluppo sono organizzate in quattro fasi prin-
cipali:
ideazione
Iterazione iniziale in cui viene eseguita una indagine del caso di stu-
dio al fine di stabilire la portata del progetto e una visione gene-
rale con una analisi dei casi duso e requisiti funzionali pi critici,
per elaborare delle stime approssimative dello sforzo e determinare
la fattibilit economica e sostenere la decisione di proseguire con il
progetto.
elaborazione
Ad ogni iterazione lanalisi dei requisiti viene approfondita, la mag-
gior parte viene scoperta e stabilizzata; vengono raffinati gli scenari
duso partendo da quelli pi importanti; si esegue lanalisi orientata
agli oggetti modellando il dominio informativo, ovvero le informa-
zioni e le relazioni che devono essere gestite dal software, e si de-
finisce il modello di interazione con le sequenze di operazioni del
sistema, e loro contratti, e le comunicazioni tra oggetti; la proget-
tazione, limplementazione e i test con codice di qualit a livello di
xxv
xxvi processo unificato
produzione parte dal nucleo principale pi rischioso dellarchitettura

software.
costruzione
Stabilizzati i requisiti lo sviluppo evolutivo si concentra sulla proget-
tazione orientata agli oggetti guidata dalle responsabilit, con lappli-
cazione di design pattern e principi GRASP, e sullimplementazione
guidata dai test che dal codice sorgente produce ad ogni iterazione
una release eseguibile stabile sottoinsieme del prodotto finale.
transizione
Ultime iterazioni di sviluppo che giunge a compimento con le ultime
implementazioni guidate dai feedback degli utenti e dei test e con il
rilascio finale del prodotto eseguibile.
Modellazione di business
Requisiti
Progettazione
Implementazione
Test
Rilascio
Gestione delle Confi-
gurazioni e Modifiche
Gestione del progetto
Infrastruttura
Figura 2: Discipline del Processo Unificato
La pratica di analisi, modellazione, sviluppo e gestione di un processo

iterativo ed evolutivo presume e accetta il cambiamento ed evita di tenta-
re di specificare in modo completo e corretto linsieme dei requisiti per
ottenere un progetto definitivo prima di iniziare limplementazione.
Il team di sviluppo anzich speculare su requisiti e progetto i pi com-
pleti e corretti possibili, rischiando di essere sopraffatto dalla complessit
e dalla paralisi da analisi, procede a realizzare rapidamente nelle prime
iterazioni un sottoinsieme significativo di requisiti iniziali, anticipando le
decisioni pi critiche e rischiose per il progetto appartenenti al nucleo
dellarchitettura.
Ottenendo feedback sin dalle prime attivit di analisi, progettazione, im-
plementazione e test tutte le parti interessate chiariscono la propria visione
del sistema software, hanno indicazioni pratiche per trovare, modificare e
migliorare i requisiti, migliorando la comprensione del progetto.
Anticipare la costruzione da la possibilit di valutare un sistema parziale
ed un modo abile per scoprire cosa ha valore per le parti interessate e
guida e rende visibili i progressi.
1 elaborati delle discipline up xxvii
1 elaborati delle discipline up

1.1 Modellazione del Business
modello di dominio Rappresenta le classi concettuali di oggetti impor-

tanti per il dominio di interesse, le associazioni tra classi e loro attribu-
ti. Una astrazione visuale di oggetti reali o concetti fondamentali del
dominio.
regole di dominio Descrive regole e politiche che trascendono il parti-

colare progetto software e a cui qualunque applicazione nel dominio del
business si deve conformare.
1.2 Requisiti
modello dei casi duso Descrive i requisiti funzionali definiti dallin-

sieme degli scenari di utilizzo del sistema, analizzati in modo parziale
nella fase di ideazione e dettagliati ad ogni iterazione nellelaborazione
successiva.
specifiche supplementari Raccoglie i requisiti non funzionali che co-

stituiscono attributi di qualit fondamentali per il sistema e che hanno
un impatto significativo sullarchitettura. Riassume inoltre caratteristiche
generali e vincoli ulteriori.
glossario Elenca i termini chiave, per ridurre le ambiguit tra le parti

interessate su termini tecnici o specifici del dominio. Registra il dizionario
dei dati, con requisiti specifici su attributi, valori ammessi e validazione
dei dati.
lista e piano di gestione dei rischi Descrive i rischi aziendali, tec-

nici e di calendario e le azioni per mitigarli e le reazioni per rispondervi.
prototipi Chiarisce la visione e valida alcune idee tecniche con limple-

mentazione di proof of concept e prototipi dellinterfaccia utente.
1.3 Progettazione
architettura software Analizza i fattori che hanno uninfluenza signi-

ficativa sullarchitettura del sistema, limpatto di possibili punti di varia-
zione richiesta dal cliente e punti di evoluzione futura, identificate le prio-
rit guidate dai rischi, ricercate le soluzioni alternative sin dalle iterazioni
iniziali.
modello dei dati Definisce il modello concettuale delle informazioni

che il sistema deve gestire in modo persistente in termini di Entit e Rela-
zioni. Il modello concettuale viene mappato sul modello logico relazionale
normalizzato in terza forma normale.
xxviii processo unificato
1.4 Implementazione
modello di implementazione Comprende tutto il codice sorgente ne-

cessario a generare il software e la documentazione, comprensivo della
definizione di classi e interfacce descritte in linguaggio orientato agli og-
getti, la definizione dei dati nel modello relazionale o ad oggetti, i file di
supporto, come le guide e manuali.
1.5 Test
modello dei casi di test Raccoglie il codice sorgente di sviluppo gui-

dato dai test (TDD) con lo scopo di verificare le unit del sistema, linte-
grazione tra elementi architetturali, le verifiche di interfaccia con sistemi
esterni e i test di accettazione del funzionamento complessivo del sistema.
1.6 Rilascio
documentazione utente Contiene la documentazione per lutente pro-

dotta iterativamente per garantire che le caratteristiche e funzionalit svi-
luppate siano chiaramente documentate e aggiornate allultimo rilascio del
software.
piano di rilascio Descrive le procedure di rilascio del software sullin-

frastruttura, la gestione degli aggiornamenti e delle configurazioni.
1.7 Gestione del progetto
piano di sviluppo del software Ipotesi sommarie sulla durata e lo

sforzo di sviluppo nelle fasi, con indicazione delle risorse impiegate.
piano delliterazione Descrive le attivit da realizzare nelle iterazione

successiva, di iterazione in iterazione.
1.8 Infrastruttura
scenario di sviluppo Descrive la personalizzazione del processo di svi-

luppo UP con le pratiche e degli elaborati utilizzati nelle varie fasi e la
pianificazione delle iterazioni successive.
Where all began
Copyright Contains modified Copernicus Sentinel data (2017), processed by ESA
Sicilian snow
Released
10/02/2017 10:00 am
Description
Part of the Italian island of Sicily is pictured in this false-colour image from the Sentinel-2A satellite.
This image was captured on 8 January during a period of unusual cold and snowfall across parts of southern Europe. As
a consequence the mountains of Sicily are visible in white across the northern part of the island. While Italys northern
regions experienced little snowfall this winter, the central and southern areas have seen abnormally cold conditions
and snowfall in mountainous areas.
Mount Etna, an active volcano, is visible at upper right. Positioned over the zone where the African plate collides with
and slips under the Eurasian plate, Etnas frequent eruptions are often accompanied by large lava flows, smoke and
ash.
Sentinel-2 provides optical data for land and vegetation monitoring. Its main instrument has 13 spectral bands, and
this false-colour image was processed including the near-infrared channel which explains why vegetation appears
red.
The varying shades of red and other colours across the entire image indicate how sensitive the instrument is to
differences in chlorophyll content. This is used to provide key information on plant health; brighter reds indicate
healthier vegetation.
Sentinel-2 is a two-satellite mission for Europes Copernicus programme. While the first satellite was launched in June
2015, its Sentinel-2B twin is set for launch from French Guiana on 7 March 2017 at 01:49 GMT.
This image is featured on the Earth from Space video programme.
Source
http://www.esa.int/spaceinimages/Images/2017/02/Sicilian_snow
1 VISIONE
Champions arent made in gyms.

Champions are made from something
they have deep inside them:
a desire, a dream, a vision.
Muhammad Al
Cronologia revisioni
Iterazione Descrizione
I.1 Ideazione elaborato Visione, opportunit e concorrenza
1.1 introduzione
Si vuole realizzare un sistema informativo software per la gestione di
progetti dellindustria aerospaziale, a supporto dei processi di garanzia di
qualit e tracciamento delle non conformit, secondo gli standard dellESA/
ECSS.
1.2 opportunit di business

Le parti interessate soffrono la mancata gestione di tali processi per las-
senza sul mercato di soluzioni a basso costo, ad esclusione di un prodotto
concorrente di seguito esaminato.
Il portale web ESA-STAR[ESAb] delle gare pubbliche di appalto dellESA,
che ha sostituito da marzo 2016 il sistema EMITS[ESAa], riporta un data-
base di pi di 2.000 piccole e medie imprese (SME) dellindustria aerospa-
ziale che hanno stabilito rapporti di collaborazione con lESA[ESAc].
Ogni impresa nella catena clientefornitore dellindustria aerospazia-
le europea, dai primi appaltatori con rapporti diretti con ESA ai sub
appaltatori, sono vincolati agli standard ECSS che dettano requisiti nor-
mativi.
I seguenti requisiti offrono una opportunit di business che viene valu-
tata nel presente documento di Visione:
3
4 visione
Standard Req. Description

[ECSS-M-ST-10-01C] 5.2.2.1 Communication and reporting:
Requirements on customers and suppliers
A The top level customer shall:

1 specify a reporting system for the
project;
2 specify an action monitoring sy-
stem for the project.
B Each customer and supplier in the

customer-supplier chain shall imple-
ment and maintain the project repor-
ting an action monitoring systems.
[ECSS-Q-ST-10-09C] 5.1 Nonconformance processing require-

ments:
Detection and immediate actions
g. The supplier shall ensure traceability

between the NCR and the quality and
manufacturing records related to the
nonconforming item.
5.5.2 Documentation
Nonconformance database
a. The supplier should maintain a databa-

se of nonconformances.
3. As an electronic tool for complete
NCR processing.
[ECSS-Q-ST-10C] 5.2.8 PA programme implementation

Nonconformance control
a. The supplier shall establish and main-

tain a nonconformance control sy-
stem in conformance with ECSS-Q-
ST-10-09C Nonconformance control
system.
[ECSS-Q-ST-20C] 5.2.2 Nonconformance control system

a. The supplier shall implement a non-
conformance control system in confor-
mance with [ECSS-Q-ST-10-09C].
1.3 formulazione del problema 5
Standard Req. Description

[ECSS-E-ST-10C] 5.6.1 System engineering integration and
control:
Management of system engineering activi-
ties
e. The system engineering organization

shall ensure the availability of product
and process data which enables the
complete system to be produced, te-
sted, delivered, operated, maintained,
and properly disposed of.
5.6.3 Engineering Data
1. The system engineering organization

shall define the engineering data to be
stored in a data repository.
2. The system engineering function shall

ensure that engineering data can be
exchanged in electronic form between
the different organizations in charge of
the elements of the product decompo-
sition levels via agreed and validated
interfaces.
1.3 formulazione del problema

Le parti interessate lamentano le lacune nella gestione delle non confor-
mit in assenza di prodotti di project management ritagliati sulle specifiche
degli standard ECSS.
La mancata gestione dei principi di gestione delle non conformit (v. 2.4
a pagina 20) causa una grave perdita di efficienza nei processi di gestione
di progetti spaziali e il non soddisfacimento dei requisiti di Garanzia
della Qualit (v. 2.3) e Garanzia di Prodotto (v. 2.2) mettono a rischio
lintera competitivit aziendale sul mercato o in casi catastrofici mettono a
rischio interi programmi spaziali coinvolgendo in ritardi di gestione altre
imprese della catena clientefornitore.
6 visione
Tabella 2: Architettura moduli e servizi di Sapienza ECLIPSE
DCCM Document Configuration & Change Management

RID Review Idem of Discrepancy
AIM Action Items Management
Application
NCTS Non Conformance Tracking System
modules
RISK Risk Management
VCS Verification Control System
EKD Engineering Knowledge Database
JAIL User Repository and Authentication
PAM Project Administration Module
Core
FLO Business Process Workflow Management
Services
AUDE Audit logs
META Metadata Builder
1.4 concorrenza
Sul mercato sono disponibili numerosi sistemi software di project ma-
nagement che offrono strumenti di comunicazione e collaborazione per la
gestione documentale, organizzazione del lavoro e attivit, gestione dei
workflow e processi di business, sistemi di issue/bug tracking. Fra que-
sti solo uno, a nostra conoscenza, specificatamente progettato tenendo
conto dei requisiti ECSS per lindustria aerospaziale: Nonconformance
Tracking System (NCTS) di Sapienza Consulting.
Lapplicazione web rilasciata per la prima volta nel 2005, ha supporta-
to 29 progetti ESA e pi di 5.000 utenti nella registrazione, segnalazione
e revisione di pi di 20.000 non conformit di prodotto1 . NCTS stato
supportato e promosso dallESA come strumento principale per limple-
mentazione dei processi di gestione delle non conformit secondo gli stan-
dard rilevanti dellECSS, in particolare i requisiti specificati nello standard
ECSS-Q-ST-10-09C Nonconformance control system.
Nel 2009 Sapienza ha integrato e aggiornato il tool software basato sugli
standard ECSS per ottenere una suite di applicazioni software modulare
nominata Eclipse[Ben+10] per il Project Management (PM), Product As-
surance (PA) e Quality Assurance (QA). Larchitettura a layer implemen-
ta i processi di business in moduli applicativi dedicati e le funzioni di
supporto in un layer di servizi di base (tab. 2).
1 About the Nonconformance Tracking System (NCTS)

http : / / www . esa . int / Our _ Activities / Space _ Engineering _ Technology / About _ the _
Nonconformance_Tracking_System_NCTS
1.5 parti interessate 7
Tabella 3: Obiettivi e problemi fondamentali per le parti interessate
Obiettivo alto Pri. Problemi Soluzioni

livello
scambio dati alta impossibile standardizzare interoperabilit a livello semanti-
il formato dei dati e data- co indipendente da una specifica
base per lintera industria tecnologia di implementazione
aerospaziale
gestione con- alta duplicazione dei docu- necessario applicare il control-
figurazioni e menti porta inconsisten- lo di versione e la gestione delle
controllo di ze e controlli manuali configurazioni ai modelli semantici
versione inefficienti
generazione alta documenti privi di riferi- i metadati nei modelli consentono
automatica menti o inseriti manual- di generare automaticamente docu-
rapporti mente e informazione non mentazione di report come trasfor-
estraibile automaticamente mazione di modelli mantenendo tut-
ti i riferimenti e potenzialmente
inferendone di nuovi
1.5 parti interessate

1.5.1 Obiettivi di alto livello
I workshop dei requisiti con esperti del settore e indagini di mercato

hanno portato allidentificazione degli obiettivi e problemi fondamentali
(tab. 3) da realizzare in un software di gestione della garanzia di qualit e
tracciamento delle non conformit per progetti dellindustria aerospaziale.
Durante il ciclo di vita di un dato elemento del sistema spaziale, i dati Scambio dei dati
vengono scambiati tra differenti portatori di interesse per vari scopi, ad
esempio:
nella fase iniziale di appalto vengono scambiati tra clienti e poten-
ziali fornitori documenti invitation to tender (ITT)/request for
proposal (RFP), con la specifica dei requisiti;
vengono sottomesse le proposte dai potenziali fornitori ai clienti;
tra fornitori e clienti vengono elaborati e scambiati documenti di
progettazione, analisi dei costi e pianificazione attraverso lintero
ciclo di vita del prodotto, pacchetti dati con preliminary design
review (PDR), detailed design review (DDR), critical design
review (CDR);
vengono scambiate informazioni interdisciplinari ad esempio tra
lingegneria di sistemi termici e strutturali, tra lingegneria software
e delle operazioni;
viene consegnato il progetto finale e i dettagli delle operazioni assie-
me al prodotto finale consegnato da un fornitore ad un cliente;
loperatore di un prodotto riporta i dati di telemetria e lo storico delle
attivit di telecomando e le procedure eseguite durante le operazioni
per scopi di valutazione e ricerca dei problemi.
8 visione
Lo scambio dei dati pu avvenire:
una tantum con il trasferimento di un insieme di dati da un data re-

pository e importato in un altro con un trasferimento di file (requisiti
[ECSS-M-ST-40C] 4.3.2.6 e ECSS-E-ST-70-31C 6.1);
dinamicamente scambiando dati tra due o pi sistemi informativi

software, ad esempio tramite interfacce web services.
Problema Lo scambio dei dati affidabile ed efficiente tra sistemi informativi ri-
chiede interfacce comuni tra le diverse parti coinvolte. Per contro pra-
ticamente impossibile standardizzare gli strumenti di gestione e archivio
delle basi dati dellintera industria aerospaziale, per i diversi obiettivi di
business tra clienti e fornitori, lesistenza di sistemi legacy e per limpatto
dei costi e dei tempi di sviluppo di applicazioni software.
Non desiderabile standardizzare gli strumenti perch il mercato li-
bero promuove linnovazione e la competizione sana tra gli sviluppato-
ri di soluzioni, di cui beneficiano tutti gli utilizzatori e lintero settore
industriale.
Inoltre non possibile richiedere ai subappaltatori e i fornitori di basso
livello ladozione e lutilizzo del completo set di strumenti di gestione
dei processi utilizzati dai loro clienti e i primi appaltatori. Acquisire e
mantenere le conoscenze necessarie per lutilizzo di ogni strumento spesso
implica costi proibitivi di licenza e di formazione, in particolare per le
piccole e medie imprese.
Soluzione La standardizzazione dello scambio dei dati deve essere ottenuta al li-
vello semantico. Per garantire che standardizzazione abbia successo sul
lungo periodo in un mondo tecnologico in rapida evoluzione necessario
definirne una implementazione indipendente da ogni specifica tecnologia,
come ad esempio formato dei file XML/XSD, API o protocolli basati su
Web Services.
Linteroperabilit semantica consente di superare il concetto di reposi-
tory unico contenente tutti i dati del sistema spaziale in un database mo-
nolitico e centralizzato, ma piuttosto di ottenere la federazione di basi di
dati disperse geograficamente e temporalmente ma logicamente integrate
in un modo che lo scambio di dati sia possibile ed affidabile. I dati non
vengono duplicati ma linformazione distribuita e i riferimenti ad oggetti
esterni sono persistenti.
1.5.2 Obiettivi utente
Ogni stakeholder ha interesse nel suo contesto disciplinare ad eseguire le

attivit pianificate dai propri processi di ingegneria del sistema aerospa-
ziale. Questa vista consiste nel sottoinsieme degli elementi del sistema di
rilevanza per la parte interessata. In tab. 4 sono riportati gli interessi degli
attori.
1.5 parti interessate 9
1.5.3 Riepilogo caratteristiche del sistema
Sistema di Account Management
Sistema di Project Management
Sistema di Action Item Management
Sistema di Meeting Management
Sistema di Document Management
Sistema di Configuration Management
Sistema di Inspection Report Management
Sistema di Non Conformance Report Management
Il dettaglio delle funzionalit nellelaborato modello dei casi du-

so (cap. 4 a pagina 45). Gli attributi di qualit, come usabilit, affida-
bilit, prestazioni, sostenibilit e ulteriori vincoli sono documentati nelle
specifiche supplementari (cap. 5 a pagina 83).
10 visione
Tabella 4: Attori e loro interessi nel sistema
Attore Obiettivo
Account Gestire account utenti e societ
Manager Gestire campi custom
Project Gestire i progetti
Manager Assegnare membri ai progetti
Gestire e assegnare ruoli e permessi
Gestire il repository e workflow documenti
Ricevere notifiche di operazioni richieste/concluse
Action Item Gestire, assegnare, revisionare Action Item
Manager Ricevere notifiche di operazioni richieste/concluse
Configuration Gestire il ciclo di vita del prodotto
Manager Gestire configurazioni di elementi, parti, manufatti
Generare baseline di prodotto
Quality Gestire e ispezionare manufatti
Assurance Gestire rapporti di ispezione
Member Gestire rapporti di non conformit
Convocare consigli di revisione di non conformit
(NRB)
Assegnare le azioni correttive e preventive
Registrare le disposizioni del NRB
Project Member Autenticare identit
Gestire il proprio account utente personale
Ottenere accesso alle informazioni in base al ruolo
Ricevere notifiche di operazioni richieste/assegnate
Operare sugli Action Item assegnati
Pianificare e gestire verbali riunioni
Visualizzare, gestire, revisionare, firmare documenti
Accedere alla struttura gerarchica a pi livelli del
prodotto
Gestire la documentazione di progetto di parti del
prodotto
Generare la distinta base di parti assemblate
Visualizzare i rapporti di ispezione e non conformit
1.6 stima dello sforzo di sviluppo (modello cocomo ii) 11
1.6 stima dello sforzo di sviluppo

Stima dello sforzo richiesto elaborata in fase di ideazione basata sul
modello COCOMO II Early Model[Boe+09] in tab. 5.
Tabella 5: COCOMO II.2000 Early Design Model
Function Points UFP 150

Language % BK
Java 60% 53
SQL 20% 27
JS 12% 35
XML 5% 15
HTML 3% 20
SIZE 6,4125
Precedentedness PREC 6,2
Development Flexibility FLEX 5,07
Architecture/Risk Resolution RESL 7,07
Team Cohesion TEAM 4,38
Process Maturity PMAT 6,5 CMM Level 2
Personnel Capability PERS 1,26
Analyst Capability ACAP 3
Programmer Capability PCAP 4
Personnel Continuity PCON 2
Product Reliability and Complexity RCPX 0,83
Required Software Reliability RELY 3
Data Size DATA 3
Documentation match to life-sycle needs DOCU 3
Product Complexity CPLX 3
Required Usability RUSE 0,95
Platform Difficulty PDIF 1,29
Execution Time Constraint TIME 3
Main Storage Constraint STOR 5
Platform Volatility PVOL 3
Personnel Experience PREX 1,12
Applications Experience APEX 3
Platform Experience PLEX 3
Language and Tool Experience LTEX 5
Facilities FCIL 1,1
Use of Software Tools TOOL 4
Multisite Development SITE 4
Required development Schedule SCED 1,43
Scale Factor SF1 22,44
Exponent B2 1,2152
Effort Multiplier EM3 2,26
Breakage BRAK 0
Adapted Source Lines of Code ASLOC 0
Automated Translation AT 50%
Calculation PM4 63,35
TDEV 18,15 months
3 EM = PERS RCPX RUSE PDIF PREX FCIL SCED

4 PM = EM A [(1 + BRAK/100) SIZE]B + [(ASLOC AT/100)/AT PROD]
Namib Desert
Credit KARI/ESA
Namib Desert
Released
10/02/2017 10:00 am
Description
Koreas Kompsat-2 satellite captured this image over the sand seas of the Namib Desert on 7 January 2012. The blue
and white area is the dry river bed of the Tsauchab. Black dots of vegetation are concentrated close to the rivers
main route, while salt deposits appear bright white. Running through the river valley, a road connects Sossusvlei to
the Sesriem settlement. At the roads 45th kilometre, seen at the lower-central part of the image, a white path shoots
off and ends at a circular parking area at the base of a dune. This is Dune 45, a popular tourist stop on the way to
and from Sossusvlei. In this image, there appears to be some shadow on the western side. From this we can deduce
that the image was acquired during the late morning.
ESA supports Kompsat as a Third Party Mission, meaning it uses its ground infrastructure and expertise to acquire,
process and distribute data to users.
This image is featured on the Earth from Space video programme.
Source
http://www.esa.int/spaceinimages/Images/2013/04/Namib_Desert
2 REGOLE DI DOMINIO
I.1 Studio degli standard ECSS
E.1 Raccolta e selezione regole di dominio da standard ECSS
Si individuano e registrano nellelaborato Regole di Dominio i requisiti

provenienti dagli standard ECSS che costituiscono il contesto normativo di
riferimento per le organizzazioni dellindustria spaziale europea.
I seguenti documenti costituiscono il sottoinsieme degli standard ECSS
contenenti disposizioni e requisiti di riferimento per il dominio applicativo
oggetto di tesi:
ECSS-S-ST-00C Description, implementation and general re-
quirements
Introduzione al sistema degli standard ECSS, la struttura in branche
e discipline, i processi di gestione, garanzia e ingegneria dei prodotti
spaziali, il modello cliente-fornitore nei programmi spaziali.
ECSS-S-ST-00-01C Glossary of terms
Definizioni dei termini utilizzati negli standard ECSS (v. glossario
cap. 3).
ECSS-Q-ST-10C rev.1 Product assurance management
Requisiti di gestione della garanzia di prodotto per progetti spaziali.
ECSS-Q-ST-10-09C Nonconformance control system
Requisiti per il controllo delle non conformit.
ECSS-Q-ST-20C rev.1 Quality assurance
Requisiti per la garanzia di qualit di prodotti e progetti spaziali.
ECSS-M-ST-10C rev.1 Project planning and implementation
Identificazione e struttura di tutte le attivit e informazioni richieste
per la revisione di progetti spaziali.
ECSS-M-ST-10-01C Organization and conduct of reviews
Elementi principali di pianificazione e esecuzione di progetti spazia-
li.
ECSS-M-ST-40C rev.1 Configuration and information manage-
ment
I requisiti e i processi per la gestione delle informazioni e documen-
tazione e configurazione di prodotto in progetti spaziali.
15
16 regole di dominio
2.1 gli standard ecss

Il sistema di standard ECSS stato sviluppato con uno sforzo cooperativo
dellAgenzia Spaziale Europea, le agenzie spaziali nazionali e dalle asso-
ciazioni industriali europee per costituire, applicare e mantenere il rife-
rimento normativo comune per la gestione, lingegneria, la garanzia di
qualit e la sostenibilit di progetti spaziali.
Linsieme completo dei documenti che costituiscono gli standard ECSS
ha i seguenti obiettivi generali:
ottenere programmi spaziali e progetti economicamente pi conve-
nienti in Europa in termini di prestazioni tecniche, economicit del
ciclo produttivo e consegne puntuali;
migliorare la competitivit del settore spaziale europeo;
migliorare la qualit e la sicurezza dei progetti e prodotti spaziali;
ridurre il rischio e garantire linteroperabilit e la compatibilit di
interfaccia mediante lapplicazione di requisiti e metodi comprovati
e riconosciuti;
facilitare la comunicazione chiara e non ambigua tra tutte le parti
coinvolte nello sviluppo e gestione di sistemi spaziali, in un formato
idoneo per linclusione in documenti giuridicamente vincolanti;
Il sistema degli standard ECSS si sviluppa in discipline strutturate in
tre branche principali di space project management, space engineering, e space
product assurance a cui si aggiunge la space sustainability (fig. 3).
Vi sono tre tipi di documenti:
standards che costituiscono documenti normativi contenenti i re-
quisiti delle attivit di una specifica disciplina. Ciascun requisito
identificato univocamente per la massima tracciabilit ed costitui-
to da una affermazione verificabile di ci che necessario rispettare,
supportata da un testo descrittivo utile a definirne il contesto.
I requisiti in questi standard sono definiti in termini degli obiettivi
che dovrebbero essere ottenuti piuttosto che sul come organizzare e
eseguire le operazioni necessarie. Questo consente di applicare i me-
todi e le strutture organizzative esistenti quando queste sono efficaci,
e di evolvere quando necessario senza modificare gli standard.
handbooks documenti non normativi di supporto che raccolgono

linee guida e buone pratiche su una disciplina specifica o una tecnica,
una tecnologia, un processo, una attivit.
technical memoranda che forniscono informazioni utili per la co-

munit spaziale su specifici argomenti. Registrano e presentano in-
formazioni che non sono oggetto di standard o che non sono abba-
stanza mature per essere pubblicate come standard o handbook.
Ogni documento ha un nome del tipo:
2.2 principi di garanzia di prodotto 17
Figura 3: Discipline del sistema degli standard ECSS
ECSS-<X>-<Tipo>-<Numero><Versione>
dove X rappresenta la branca (P, M, Q), il tipo (ST, HB, TM), il numero
una o due coppie di cifre, la versione una lettera da A a seguire.
2.2 principi di garanzia di prodotto

Lo standard ECSS-Q-ST-10C rev.1 Product assurance management intro-
duce allinsieme dei requisiti per la definizione delle garanzie di prodotto
da operare attraverso le fasi di ogni progetto spaziale.
principi generali Il primo obiettivo della Product Assurance (PA)

assicurare che i prodotti dellindustria spaziale raggiungano i definiti
obiettivi di missione in modo sicuro, valido e affidabile.
Limpegno per la qualit di tutta lorganizzazione la chiave per la qua-
lit del prodotto e il successo della missione spaziale. La gestione del-
la garanzia di prodotto completamente incorporata nella gestione del

progetto e riceve la massima priorit.
Lidentificazione precoce di aspetti potenzialmente dannosi per il suc-
cesso e la sicurezza della missione, e una prevenzione efficace dei costi di
qualsiasi conseguenza negativa sono i principi di base per i requisiti ECSS
di garanzia di prodotto.
La gestione della PA integra le attivit di diverse discipline di garanzia
di prodotto definite negli standard ECSS del ramo Q:
Q-20 Garanzia di qualit
Q-30 Affidabilit
Q-40 Sicurezza
Q-60 Componenti elettrici, elettronici e elettromeccanici (EEE)
Q-70 Materiali, parti meccaniche e processi
Q-80 Garanzia prodotti software
pianificazione programma di pa Dettagli della pianificazione di un

programma di PA sono specificati nei requisiti a cui si rimanda nello
standard che indirizzano nei seguenti aspetti:
definizione di una organizzazione per la garanzia di prodotto con
lallocazione di adeguate risorse, personale e strutture;
definizione dei requisiti di garanzia di prodotto per i fornitori di
livello inferiore;
definizione di un piano di garanzia di prodotto che descriva il pro-
gramma di PA e come questo soddisfi i requisiti e gli obiettivi di
progetto.
implementazione programma di pa I requisiti per limplementazio-

ne di un programma di garanzia di prodotto sono specificati nello stan-
dard e coprono i seguenti aspetti:
Gestione e controllo delle attivit di PA previste dalle discipline di
garanzia di prodotto
Reportistica dei progressi di tutti gli aspetti importanti per la garan-
zia di prodotto
Gestione delle verifiche, degli elementi critici, delle non conformit
e degli allarmi
Supporto alla gestione dei rischi, in coordinamento con le funzioni
di project management
Supporto alla documentazione e controllo dei dati, registri di qualit
e gestione delle configurazioni
Controllo dei fornitori di livello inferiore per assicurare limplemen-
tazione dei requisiti di PA da parte dei fornitori
2.3 principi di garanzia di qualit 19
2.3 principi di garanzia di qualit

Lo standard ECSS-Q-ST-20C rev.1 Quality assurance definisce i principi
di gestione della garanzia di qualit.
principi di qa management Il primo obiettivo della gestione della

Quality Assurance (QA) assicurare che nei progetti sia stabilito, man-
tenuto e implementato un programma di garanzia di qualit a copertura
del progetto di missione e della progettazione, sviluppo e produzione di
sistemi spaziali.
Tutti i requisiti di QA sono specificati attraverso la definizione e limple-
mentazione di adeguati metodi e procedure.
Il personale che determina le performance e incide sulla qualit del
prodotto addestrato e certificato in funzione delle esigenze di progetto.
principi generali Lattuazione delle seguenti attivit, indipendenti

dalle fasi, garantita dalla QA per tutto il lasso di tempo dei progetti:
controllo degli elementi critici

controllo delle non conformit
gestione degli allarmi
controllo dei timbri
tracciabilit
metrologia e taratura
movimentazione, stoccaggio e conservazione
controllo statistico della qualit (se richiesto da contratto).
principi di progettazione e verifica Gli obiettivi della QA sono

assicurare che:
1. venga impostato un insieme di regole e metodi di progettazione che

sia coerente con le tecniche e le tecnologie di progetto;
2. siano stati definiti e implementati metodi, procedure e trovati stru-
menti al fine di dimostrare che ogni requisito applicabile sia verifica-
to attraverso uno o pi dei seguenti metodi: lanalisi, lispezione, il
test di prova, la revisione del design, la verifica di controllo;
3. il progetto sia realizzabile e replicabile e che il prodotto risultan-
te possa essere verificato e fatto funzionare nei limiti di servizio
richiesti;
4. le attivit di progettazione e di verifica siano pianificate in modo
coerente e logico;
5. il processo di verifica sia completo e includa evidenti prove di test,
modelli di prova e la logica di verifica;
6. sia definito e implementato un metodo di qualificazione per dimo-

strare che loggetto operi soddisfacentemente nellambiente previsto.
Tutte le attivit di appalto, tra cui la selezione delle fonti, la documenta-

zione relativa alle gare di appalto, la vigilanza delle fonti di approvvigio-
namento e i controlli di ispezione sono sotto controllo per assicurare che
tutti i prodotti e servizi acquistati siano conformi ai requisiti.
principi di produzione, assemblaggio e integrazione Tutte le

operazioni di produzione, assemblaggio e integrazione sono pianificate e
eseguite in coordinamento con controlli e test per garantire che i prodotti
forniti siano costruiti, assemblati e integrati per la configurazione di base
approvata.
Sono identificati in modo tempestivo i processi speciali e le nuove tec-
nologie e dovrebbero essere attuate adeguate attivit di valutazione o di
qualificazione nel rispetto del programma generale.
principi di collaudo Gli impianti e le apparecchiature di prova ven-

gono validate prima del loro utilizzo al fine di garantire la conformit ai
requisiti di progetto.
Tutti i test sono eseguiti in conformit con le procedure documentate e
rilasciate ed i risultati sono registrati integralmente.
principi di accettazione e di consegna Lobiettivo di garanti-

re che un processo di accettazione e consegna sia implementato in mo-
do da consentire di dimostrare e documentare la conformit del prodotto
consegnato.
principi per lequipaggiamento di supporto a terra I requisiti

di progettazione, produzione, consegna e manutenzione per lequipaggia-
mento di supporto a terra (ground support equipment (GSE)) sono definiti
e implementati per consentire la testabilit, la disponibilit, la sicurezza,
la durata di vita, operativit e capacit di interfacciarsi come necessario
con il segmento spaziale in modo sicuro.
2.4 principi per sistemi di controllo delle non

conformit
Lo standard ECSS-Q-ST-10-09C Nonconformance control system definisce
i requisiti di un sistema di controllo delle non conformit.
Lo standard si applica a ogni livello della catena cliente-fornitore ad
ogni prodotto e fornitura non conforme ai requisiti di progetto.
Lo standard applicabile durante lintero ciclo di vita del progetto
come definito nello standard ECSS-M-ST-10C rev.1 Project planning and
implementation.
2.4 principi per sistemi di controllo delle non conformit 21
Lo standard pu essere adattato alle caratteristiche specifiche e ai vincoli

di un progetto spaziale in conformit con [ECSS-S-ST-00C].
principi e obiettivi Il processo di identificazione ed elaborazione de-

gli elementi non conformi pu essere applicato ad ogni livello della catena
cliente-fornitore. Il processo prevede:
azioni correttive contro la causa principale per evitare future ricor-

renze in altri prodotti;
una pronta e effettiva comunicazione tra fornitori e clienti;
la prevenzione delloccorrenza della non conformit, dallanalisi dei

registri di non conformit agli insegnamenti che se ne possono trarre.
individuazione e intervento immediato Quando viene scoperta una

non conformit il responsabile per la PA di progetto la analizza per identifi-
care la sua estensione e la causa. Inoltre stabilisce immediati interventi per
prevenire luso non autorizzato dellelemento non conforme. La non con-
formit viene documentata nel modulo di nonconformance report (NCR)
e sottoposta al Nonconformance Review Board (NRB) interno.
consiglio di revisione delle non conformit Il consiglio di re-

visione delle non conformit interno investiga le cause e le conseguen-
ze della non conformit e classifica la non conformit come maggiore o
minore.
Per le non conformit minori si dispone come segue:
Ritornare al fornitore: questa disposizione si applica solo ad

elementi non conformi provenienti da fornitori.
Usare cos com: lelemento pu essere utilizzato senza elimina-

re la non conformit.
Rilavorare: possibile recuperare lelemento per essere completa-

mente conforme ai requisiti specificati. Ulteriore lavoro viene ese-
guito per preparare lelemento alla rilavorazione (ad esempio la ri-
mozione di una parte difettosa e pulizia). In nessun caso il risul-
tato di precedenti processi applicati o precondizioni di altri pro-
cessi da applicare successivamente devono essere influenzati dalla
rilavorazione.
Rottamare: loggetto non recuperabile con una rilavorazione o

riparazione, per motivi tecnici o economici.
Riparare: possibile recuperare lelemento affinch risponda ai re-

quisiti duso atteso anche se non conforme ai requisiti specificati in
origine.
La procedura di riparazione una delle seguenti:

1. Procedura di riparazione standard o certificata: per le proce-

dure di riparazione che sono state approvate in anticipo dal cliente
per usi previsti.
2. Procedura di riparazione specifica: procedure di riparazione che

sono state disposte per la specifica non conformit e sono state ap-
provate dal NRB.
Ogni procedura di riparazione include le verifiche necessarie a controllare
i risultati della riparazione.
Le non conformit maggiori sono sottoposte al customer NRB.
consiglio di revisione delle non conformit con il cliente In

principio il NRB con il cliente segue lo stesso processo del NRB interno.
In aggiunta, viene valutato se la non conformit ha impatto su requisiti di
clienti di livello superiore. Se cos, questi clienti di livello superiore sono
coinvolti nei seguenti NRB. La necessit di stabilire una deroga alla non
conformit viene identificata e raccomandata in questi NRB.
possibile tenere molteplici NRB interni o con i clienti prima che venga
chiuso un rapporto di non conformit.
azioni correttive e preventive Durante i consigli di revisione delle

non conformit, che siano interni o con il cliente, vengono determinate le
azioni correttive per eliminare le cause delle non conformit. Le azioni
preventive sono identificate per evitare il verificarsi della non conformit
in elementi simili.
implementazione delle azioni e chiusura della non conformit

Il fornitore esegue le azioni correttive e/o preventive come da disposizioni
del NRB.
Non appena tutte le azioni sono state eseguite e verificate, il respon-
sabile per la PA del fornitore chiude la gestione della non conformit e
informa il cliente.
documentazione Il fornitore documenta la sua implementazione del

sistema di controllo delle non conformit.
La reportistica interna e il trattamento delle non conformit del fornitore
sono aperte e visibili alla revisione del cliente e non ritardano lelaborazio-
ne delle non conformit nel rispetto di questo standard.
Il fornitore pu mantenere un database delle maggiori e minori non
conformit per:
1. provvedimenti seguenti al NCR,
2. generare elenchi di stato delle non conformit [ECSS-Q-ST-10-09C]
all.B,
3. processare elettronicamente le non conformit.
Il complesso delle informazioni memorizzate dovrebbe essere sufficiente
a consentire una analisi statistica e tendenziale.
2.5 principi di gestione della configurazione e dellinformazione 23
2.5 principi di gestione della configurazione

e dellinformazione
Lo standard Lo standard ECSS-M-ST-40C rev.1 Configuration and infor-
mation management descrive i processi e definisce i requisiti per la gestione
delle informazioni, della documentazione e la configurazione di prodotti
nellambito di un progetto o programma spaziale.
principi di gestione delle configurazioni La gestione della confi-

gurazione e la gestione dellinformazione e documentazione sono processi
interconnessi nella gestione dei progetti. Le principali attivit di questi
processi, rappresentate in figura 4, sono:
gestione e pianificazione;
implementazione di attivit di configuration management, quali iden-

tificazione della configurazione, controllo della configurazione, reso
conto degli stati, verifica e controllo;
implementazione delle attivit di information/documentation manage-

ment, quali la creazione, raccolta, revisione, distribuzione, memoriz-
zazione e recupero, e archiviazione.
La gestione della configurazione il processo necessario a stabilire e
mantenere un registro consistente delle caratteristiche fisiche e funzionali
di un prodotto in confronto ai suoi requisiti progettuali e operativi. La
gestione della configurazione applicata attraverso tutti il ciclo di vita di
un prodotto e consente di:
conoscere in ogni momento la descrizione tecnica di un prodotto per
mezzo di documentazione approvata;
registrare e controllare levoluzione della descrizione tecnica di un

prodotto;
fornire tracciabilit dellevoluzione della descrizione tecnica del pro-

dotto;
garantire la consistenza delle interfacce interne;
verificare e dimostrare a tutti gli attori che la documentazione e

rimane lesatta immagine del prodotto che descrive;
identificare la configurazione corrente di base e la configurazione

del prodotto come costruito, per registrare le discrepanze rilevate
durante la produzione, distribuzione o utilizzo e la predisposizione
ad altri usi;
consentire ad ogni attore di conoscere le possibilit operative e i

limiti di ogni elemento del prodotto e, in caso di non conformit,
conoscere quali elementi sono affetti.
Figura 4: Attivit di Configuration Management (fonte [ECSS-M-ST-40C] fig.4.1)
principi di gestione dellinformazione e documentazione La

gestione dellinformazione e documentazione il processo che consente
la pronta ed effettiva creazione, raccolta, revisione, distribuzione, memo-
rizzazione e archiviazione delle informazioni del progetto. Per ottenere
questo obiettivo, tutte le informazioni registrate sono gestite elettronica-
mente.
La gestione dellinformazione e documentazione applicata attraverso
lintero ciclo di vita del progetto e consente di:
garantire la correttezza, laccessibilit, la rapida disponibilit, latten-

dibilit e la sicurezza delle informazioni fornite a tutti gli attori sia
interni che esterni al progetto;
garantire la coerenza complessiva delle informazioni di progetto,
facilitandone in tal modo luso efficace e efficiente;
garantire che tutti gli attori che necessitano accesso allinformazione
siano consapevoli della sua disponibilit, i mezzi di accesso, e relativi
metodi e procedure;
supportare la comunicazione nel programma/progetto.
Pillars of Creation
Credit NASA, ESA/Hubble and the Hubble Heritage Team
Pillars of Creation
Release date 5 January 2015, 23:15
The NASA/ESA Hubble Space Telescope has revisited one of its most iconic and popular images: the Eagle Nebulas Pillars of Creation. This image
shows the pillars as seen in visible light, capturing the multi-coloured glow of gas clouds, wispy tendrils of dark cosmic dust, and the rust-coloured
elephants trunks of the nebulas famous pillars.
The dust and gas in the pillars is seared by the intense radiation from young stars and eroded by strong winds from massive nearby stars. With
these new images comes better contrast and a clearer view for astronomers to study how the structure of the pillars is changing over time.
About the Object

Name: Eagle Nebula, M 16, Messier 16
Type: Milky Way : Nebula : Type : Star Formation
Distance: 7000 light years
Constellation: Serpens Cauda
Category: Nebulae
Credit: NASA, ESA/Hubble and the Hubble Heritage Team
Source
http://www.spacetelescope.org/news/heic1509/
3 GLOSSARIO
Ogni linguaggio un alfabeto di simboli

il cui uso presuppone un passato che
glinterlocutori condividono.
LAleph
Jorge Luis Borges
I.1 Definizione termini e abbreviazioni da standard ECSS
E.1 Raffinamento termini e definizione dizionario dati
Il Glossario lelaborato della disciplina di analisi dei requisiti di UP

che elenca i termini chiave per il dominio dellapplicazione selezionati
dagli standard ECSS di riferimento.
Nella fase di ideazione sono state raccolte definizioni e descrizioni dei
termini pi significativi per ridurre i problemi di comunicazione tra le
parti interessate e le possibili ambiguit nellanalisi dei requisiti.
Nelle iterazioni successive il glossario stato raffinato ed esteso per
contenere un dizionario dei dati che tenga traccia di attributi, formato,
relazioni, valori ammessi e regole di validazione.
3.1 termini
Termini generali standard ECSS-S-ST-00-01C Glossary of terms
assembly
<act> physically combining parts, components, equipment or seg-
ment elements to form a larger entity
business agreement
legally binding agreement, for the supply of goods or services, be-
tween two or more actors in the customersupplier chain
NOTE Business agreements are recorded in a variety of forms, such
as:
Contracts,
Memoranda of understanding,
27
28 glossario
Inter-governmental agreements,
Inter-agency agreements,
Partnerships,
Bartering agreements, and
Purchase orders.
conformance
fulfilment of a requirement
customer
organization or person that receives a product as part of a business
agreement
NOTE A customer can be internal or external to the supplier organi-
zation.
defect
non-fulfilment of a requirement related to an intended or specified
use
NOTE 1 The distinction between the concepts defect and nonconfor-
mance is important as it has legal connotations, particularly those
associated with product liability issues. Consequently the term de-
fect should be used with extreme caution.
NOTE 2 The intended use as intended by the customer can be af-
fected by the nature of the information, such as operating or mainte-
nance instructions, provided by the supplier.
dependability
the extent to which the fulfilment of a required function can be justi-
fiably trusted
NOTE 1 Its main components are reliability, availability and main-
tainability.
NOTE 2 Dependability shall be considered in conjunction with safety.
design
<result> set of information that defines the characteristics of a prod-
uct
design
<activity> process used to generate the set of information defining
the characteristics of a product
NOTE The design is completed at CDR closure
deviation
formal authorization to depart from the originally specified require-
ments for a product, prior to its production
NOTE Waiver is an a posteriori decision whereas deviation is an a
priori decision with respect to the production phase.
3.1 termini 29
failure
the event resulting in an item being no longer able to perform its
required function
NOTE "Failure" is an event, as distinguished from "fault" which is a
state.
function
intended effect of a product
normative
providing requirements for activities or their results
NOTE 1 A normative document covers documents such as stan-
dards, technical specifications, codes of practice and regulations.
NOTE 2 A normative reference" incorporates requirements from a
cited publication into a normative document.
performance
quantifiable characteristics of a function
procedure
documented way to carry out an activity or process in a controlled
manner
process
set of interrelated or interacting activities which transform inputs
into outputs
NOTE Inputs to a process are generally outputs of other processes.
product
result of a process
NOTE 1 There are four generic product categories:
services
software
hardware
processed materials.
NOTE 2 Adapted from ISO 9000:2005.
product tree
hierarchical breakdown of a product into successive levels of product
project
set of coordinated and controlled activities with start and finish dates,
undertaken to achieve an objective conforming to specific require-
ments, including constraints of time, cost and resources
quality
degree to which a set of characteristics of a product or process fulfils
requirements
30 glossario
requirement
documented demand to be complied with
supplier
organization or person that provides a product as part of a business
agreement
NOTE A supplier can be internal or external to the customer organi-
zation.
tailoring
process by which standards are made applicable to a specific project
by selection of existing requirements, with or without modification,
or addition of new ones
test
measurement of product characteristics, performance or functions
under representative environments
validation
process which demonstrates that the product is able to accomplish
its intended use in the intended operational environment
NOTE 1 The status of the product following validation is validated.
NOTE 2 Verification is a pre-requisite for validation.
verification
process which demonstrates through the provision of objective ev-
idence that the product is designed and produced according to its
specifications and the agreed deviations and waivers, and is free of
defects
NOTE 1 A waiver can arise as an output of the verification process.
NOTE 2 Verification can be accomplished by one or more of the
following methods: analysis (including similarity), test, inspection,
review of design.
NOTE 3 The status of the product following verification is verified.
waiver
formal authorization to accept products which during production,
or after having been submitted to inspection or tests, are found to
depart from specified requirements
NOTE 1 Deviation is an a priori decision whereas waiver is an a
posteriori decision with respect to the production phase.
NOTE 2 The term concession is synonymous and may be used for
materials as per Q-ST-70C.
work breakdown structure

hierarchical representation of the activities necessary to complete a
project
3.1 termini 31
Termini standard ECSS-Q-ST-10-09C Nonconformance control sy-

stem
alert
formal notification to users, informing them of failure or nonconfor-
mance of items, already released for use or not, which could also be
present on other items already delivered [e.g. items with identical
design concept, materials, components or processes]
NOTE An alert can also be raised when a deficiency in the specified
requirements, which can affect the fitness for purpose in the defined
application, has been identified.
corrective action
action to eliminate the cause of a detected nonconformance, or other
undesirable situation
NOTE 1 There can be more than one cause for a non-conformance.
NOTE 2 Corrective action is taken to prevent recurrence whereas
preventive action is taken to prevent occurrence.
critical item
potential threat to the schedule, cost, performance and quality of a
project or programme that is controlled by a specific action plan in
order to mitigate emanating risks and to prevent undesirable conse-
quences
NOTE Examples of critical items are:
item not qualified or validated for the application in question
(or has caused problems previously which remained unresolved).
item for which it is difficult to demonstrate design performance.
item highly sensitive to the conditions under which it is pro-
duced or used (e.g. contamination, radiation).
item having the potential to degrade the quality of the product
significantly, and hence the ability of the end-product to accom-
plish defined mission objectives.
item for which major difficulties or uncertainties are expected
in the procurement, manufacturing, assembly, inspection, test,
handling, storage and transportation, that have the potential to
lead to a major degradation in the quality of the product
inspection
conformance evaluation by observation and judgement accompanied
as appropriate by measurement, testing or gauging
[ISO 9000:2005]
major nonconformances
nonconformances which can have an impact on the customers re-
quirements in the following areas and cases:
32 glossario
safety of people or equipment,

operational, functional or any technical requirements imposed by the
business agreement,
reliability, maintainability, availability,
lifetime,
functional or dimensional interchangeability,
interfaces with hardware or software regulated by different busi-
ness agreements,
changes to or deviations from approved qualification or accep-
tance test procedures,
project specific items which are proposed to be scrapped.
minor nonconformances
nonconformances which by definition cannot be classified as major
NOTE For example, the following EEE discrepancies after deliv-
ery from the manufacturer can be classified as minor:
random failures, where no risk for a lot-related reliability or qual-
ity problem exists;
if the form, fit or function are not affected;
minor inconsistencies in the accompanying documentation.
nonconformance
non-fulfilment of a requirement
NOTE The term nonconformity is synonymous but deprecated.
preventive action
action to eliminate the cause of a potential nonconformance or other
undesirable potential situation
NOTE 1 There can be more than one cause for a potential non-
conformance.
NOTE 2 Preventive action is taken to prevent occurrence whereas
corrective action is taken to prevent recurrence.
repair
action to correct a defect of a product that leads to a configuration
item change
NOTE 1 Unlike rework, repair affects or modifies parts of the defec-
tive product.
NOTE 2 An NCR needs to be raised for the CI change.
rework
action to correct a defect of a product that does not lead to a config-
uration item change
NOTE 1 Unlike repair, rework does not affect or modify parts of the
defective product.
NOTE 2 No NCR needs to be raised.
3.1 termini 33
Termini standard ECSS-Q-ST-10C rev.1 Product assurance manage-

ment
acceptance
<process> that part of the verification process which demonstrates
that the product meets specified acceptance margins
approval
formal agreement by a designated management official to use or ap-
ply an item or proceed with a proposed course of action
NOTE 1 Approvals must be documented.
NOTE 2 Approval implies that the approving authority has verified
that the item conforms to its requirements.
audit
systematic, independent and documented process for obtaining au-
dit evidence and evaluating it objectively to determine the extent to
which audit criteria are fulfilled
NOTE 1 Internal audits, sometimes called first-party audits, are con-
ducted by, or on behalf of, the organization itself for management
review and other internal purposes, and may form the basis for an
organizations declaration of conformity. In many cases, particularly
in smaller organizations, independence can be demonstrated by the
freedom from responsibility for the activity being audited.
NOTE 2 External audits include those generally termed second- and
third-party audits. Second-party audits are conducted by parties hav-
ing an interest in the organization, such as customers, or by other
persons on their behalf. Third-party audits are conducted by ex-
ternal, independent auditing organizations, such as those providing
certification/registration of conformity to ISO 9001 or ISO 14001.
NOTE 3 When quality and environmental management systems are
audited together, this is termed combined audit.
NOTE 4 When two or more auditing organizations cooperate to au-
dit a single auditee jointly, this is termed joint audit.
[ISO 9000:2005]
product assurance
discipline devoted to the study, planning and implementation of ac-
tivities intended to assure that the design, controls, methods and
techniques in a project result in a satisfactory degree of quality in a
product
qualification
that part of verification which demonstrates that the product meets
specified qualification margins
NOTE This can apply to personnel, products, manufacturing and
assembly processes.
34 glossario
quality assurance
part of quality management focused on providing confidence that
quality requirements will be fulfilled
[ISO 9000:2005]
review
activity undertaken to determine the suitability, adequacy and effec-
tiveness of the subject matter to achieve established objectives
NOTE 1 Review can also include the determination of efficiency.
NOTE 2 Examples are: management review, design and develop-
ment review, review of customer requirements and nonconformity
review.
[ISO 9000:2005]
risk
undesirable situation or circumstance that has both a likelihood of
occurring and a potential negative consequence on a project
NOTE 1 Risks are inherent to any project, and can arise at any time
during the project life cycle.
NOTE 2 Predictability and control of events facilitate risk reduction.
NOTE 3 The terms risk assessment, risk mitigation and risk
control are in common use in ECSS.
safety
state where an acceptable level of risk is not exceeded
NOTE Risk relates to:
fatality,
injury or occupational illness,
damage to launcher hardware or launch site facilities,
damage to an element of an interfacing manned flight system,
the main functions of a flight system itself,
pollution of the environment, atmosphere or outer space, and
damage to public or private property.
traceability
ability to track the history, location or application by means of docu-
mented records
NOTE When considering a product, traceability can relate to:
the origin of materials and parts,
the processing history, or
the distribution and location of the product after delivery.
3.1 termini 35
Termini standard ECSS-Q-ST-20C rev.1 Quality assurance
inspectability
ability of an item of being inspected
NOTE Inspectability includes provisions for the followings aspects:
Definition of inspection including acceptance or rejection crite-

ria, expressed in an unambiguous and quantified manner.
Part and component accessibility for inspection
Definition of tolerance methods for dimensional inspection per-
formance (e.g. functional tolerances).
producibility
ability of an item of being producible
NOTE Producibility includes provisions for the following aspects:
Design simplification and standardization, reduction in part

types and part number.
Guidelines for selection of preferred parts, materials and pro-
cesses.
Unambiguous definitions of the requirements and limits to be
used.
Definition of tolerance build-up methods, in order to simplify
manufacturing, assembly, inspection.
Standardization of interfaces.
Part accessibility for assembly and inspection.
Definition of design criteria consistent with the capability of
manufacturing processes.
Definition of design methods to ensure that the cleanliness re-
quirements are compatible with the capability of related clean-
liness procedures and facilities.
testability
ability of an item of being tested
NOTE Testability includes provisions for the followings aspects:
Definition of test requirements, including acceptance or rejec-

tion criteria, expressed in an unambiguous and quantified man-
ner.
Part and component accessibility for test.
Definition of recommended design techniques to facilitate fault
detection, identification and location (e.g. test points, modular-
ity, built-in test software, and feedback loops).
36 glossario
Termini standard ECSS-M-ST-10-01C Organization and conduct of

reviews
consumer
body specifying a project or (product) through a high level require-
ment document (such as mission statement or SFS and STS) and pro-
viding the necessary financial resources for its realization.
review authority
body appointed by the consumer organization, having the mandate to is-
sue recommendations to the customer and issue decisions relating to the re-
view process
NOTE This is also referred to as the review board.
review item discrepancy (rid)
issue, identified by a reviewer, that is not compliant with a require-
ment, a review objective or a design goal
review prerequisite
conditions necessary to be fulfilled prior to the start of the review
review team
body appointed by the review authority, having the mandate to eval-
uate the status of the project under review
review team leader
person responsible for the review team activities and issuing the re-
view team report
Termini standard ECSS-M-ST-10C rev.1 Project planning and imple-

mentation
discipline
specific area of expertise within a general subject
NOTE The name of the discipline normally indicates the type of ex-
pertise (e.g. in the ECSS System, system engineering, mechanical en-
gineering, software and communications are disciplines within the
Engineering domain)
Termini standard ECSS-M-ST-40C rev.1 Configuration and informa-

tion management
configuration
interrelated functional and/or physical characteristics of a product
defined in configuration documents subject to configuration manage-
ment
NOTE Adapted from ISO 10007:2003.
3.1 termini 37
configuration baseline
approved status of requirements and design of a product at a project
key milestone that serves as a reference for activities throughout the
life cycle of the product
NOTE Adapted from ISO 10007:2003.
configuration control
coordinated activities for controlling modifications to a configuration
baseline
NOTE Requests for deviation are also considered modifications to a
baseline.
configuration document
document that defines the requirements for function, design, build,
production, and verification for a configuration item
NOTE For space standards, configuration documents can include
documents relating to operation and disposal of the configuration
item.
configuration identification
coordinated activities to establish rules for configuration item selec-
tion, configuration baseline content definition, and product and doc-
ument identifiers definition
configuration item
aggregation of hardware, software, processed materials, services or
any of its discrete portions, that is designated for configuration man-
agement and treated as a single entity in the configuration manage-
ment process
NOTE A configuration item can contain other configuration item(s).
configuration management
activity for establishing and maintaining consistent records of the
performance parameters of a product and its functional and physical
attributes compared to product design and operational requirements
NOTE 1 Configuration management is applied throughout the entire
life cycle of the product (i.e. development, production, deployment,
operation and disposal).
change control
activity for control of changes or departures to the product after for-
mal approval of its configuration baseline
NOTE Adapted from ISO 10007.
information/documentation management
process for ensuring timely and effective creation, collection, review, de-
livery, storage, and archiving of project information
38 glossario
information system
set of resources, procedures and data required in support of project
management processes
metadata
metadata are structured, encoded data that describe characteristics of in-
formation bearing entities to aid in the identification, discovery, as-
sessment, and management of the described entities
NOTE Adapted from Committee on Cataloguing Task Force on
metadata Summary Report.
product item
element of the product tree having a unique identifier
self-signed certificate
certificate auto-generated by the signer
technical data package

ZIP file containing structured collection of files with their related meta-
data, to be exchanged between information systems
NOTE Adapted from ISO10303 AP232 TDP definition.
3.2 termini abbreviati 39
3.2 termini abbreviati
AI Action Item MIP mandatory inspection

point
AIT Assembly, Integration and
Test MOM minutes of meeting
AIV Assembly, Integration and MGSE mechanical ground
Verification support equipment
AOCS Attitude and Orbit NRB Nonconformance Review
Control System Board
B/L baseline
N/A not applicable
CI Configuration Item
OTS offtheshelf
CM Configuration Manage-
PA Product Assurance
ment
CP change proposal PCV physical configuration ver-
ification
CR change request
PMP parts, materials and
EEE electrical, electronic and processes
electromechanical
QA Quality Assurance
EGSE electrical ground support
equipment RAMS reliability, availability,
maintainability and safety
FDIR failure detection isolation
and recovery RID review item discrepancy
FMEA failure modes and effects TM Technical Memorandum
analysis
TRB test review board
FMECA failure modes, effects and
criticality analysis VCB verification control board
GSE ground support WBS Work Breakdown

equipment Structure
KIP key inspection point WP work package
40 glossario
3.3 dizionario dei dati

3.3.1 password
Stringa alfanumerica criptata o salt-hashed.
3.3.2 custom fields
Campi descrittivi personalizzati.
3.3.3 Codici di impresa
company tax identification number

Codice univoco fiscale di impresa
esa registration number

Codice univoco rilasciato dallESA per le imprese dellindustria ae-
rospaziale che hanno stabilito rapporti di collaborazione o parteci-
pato a gare pubbliche di appalto dellESA registrate nel database
ESA-STAR1
emits code
Codice univoco rilasciato dallESA per imprese dellindustria aero-
spaziale registrate nel database EMITS2
3.3.4 Codice UUID
Codice Identificativo Univoco Universale (UUID) 3 composto da 128-

bit, 32 caratteri esadecimali, utilizzato per identificare il progetto in una
infrastruttura software distribuita in assenza di un sistema centralizzato
di coordinamento che possa garantire lunivocit.
Il formato di stampa di un codice UUID costituito da cinque gruppi
separati da trattini, nella forma 8-4-4-4-12 per un totale di 36 caratteri (32
esadecimali e quattro trattini).
La stringa che rappresenta un UUID versione 4 deve soddisfare la se-
guente espressione regolare:
[a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[a-b8-9][a-f0-9]{3}-[a-f0-9]{12}
3.3.5 Reference Paradigm
Un riferimento univoco costruito sulla base di un paradigma adottato

nel progetto. Il paradigma definisce la regola di costruzione del riferimen-
1 ESA System for Tendering And Registration https://esastar-emr.sso.esa.int/

2 EMITS Open Invitations To Tender (ITTs) http://emits.sso.esa.int/
3 RFC 4122 https://tools.ietf.org/html/rfc4122
3.3 dizionario dei dati 41
to derivato per composizione di vari campi e contatori progressivi indicati

in tabella 6.
Tabella 6: Campi utilizzabili nel paradigma dei riferimenti a documenti e record
Campo Formato Descrizione Validazione

Project.Acronym Stringa acronimo del progetto
Company.Acronym Stringa acronimo dellazienda dellau- 3 o 4 lettere
tore del documento
Document.Type Enum codice tipo documento selezio- 2 lettere
nato da una lista predefinita
per vari tipi di documento (per
esempio: v. 7 a pagina 123)
Employee.Number Stringa codice autore, univoco per ogni 3 cifre
dipendente di una azienda
Employee.Documents Stringa un contatore progressivo dei 3 cifre
documenti creati da un autore
in un progetto
Project.Documents Stringa un contatore progressivo dei 3 cifre
documenti creati in un progetto
Document.Issue Intero issue del documento
Document.Revision Intero revisione del documento
3.3.6 Codici seriali elementi Product Tree
Un configuration item identificato univocamente dallcodice:
configuration item code
Una parte o parte assemblata identificata univocamente dallinsie-

me del configuration item code e dal part number + versione:
configuration item code + part number version
Un manufatto identificato univocamente dal codice univoco:
configuration item code + part number version + batch serial number
3.3.7 Codice AIT
Riferimento a Assembly, Integration and Test (AIT) in un inspection re-

port (IRPT) per futuro punto di evoluzione per modulo di gestione verifica
e testing.
Cluster Westerlund 2
Credit NASA, ESA, the Hubble Heritage Team (STScI/AURA), A. Nota (ESA/STScI), and the Westerlund 2 Science Team
Cluster Westerlund 2
Release date 23 April 2015, 15:15
This NASA/ESA Hubble Space Telescope image of the cluster Westerlund 2 and its surroundings has been released to celebrate Hubbles 25th year
in orbit and a quarter of a century of new discoveries, stunning images and outstanding science.
The images central region, containing the star cluster, blends visible-light data taken by the Advanced Camera for Surveys and near-infrared
exposures taken by the Wide Field Camera 3. The surrounding region is composed of visible-light observations taken by the Advanced Camera for
Surveys.
The original observations of Westerlund 2 were obtained by the science team: Antonella Nota (ESA/STScI), Elena Sabbi (STScI), Eva Grebel and
Peter Zeidler (Astronomisches Rechen-Institut Heidelberg), Monica Tosi (INAF, Osservatorio Astronomico di Bologna), Alceste Bonanos (National
Observatory of Athens, Astronomical Institute), Carol Christian (STScI/AURA) and Selma de Mink (University of Amsterdam). Follow-up observations
were made by the Hubble Heritage team: Zoltan Levay (STScI), Max Mutchler, Jennifer Mack, Lisa Frattare, Shelly Meyett, Mario Livio, Carol Christian
(STScI/AURA), and Keith Noll (NASA/GSFC).
About the Object

Name: Gum 29, RCW 49, Westerlund 2, WR 20a
Type: Milky Way : Star : Grouping : Cluster : Open
Milky Way : Nebula
Constellation: Carina
Category: Nebulae Star Clusters
Source
4 MODELLO DEI CASI DUSO
I.1 Raccolta casi duso nel primo workshop dei requisiti in fase
di ideazione
E.1 Prima iterazione di elaborazione, dettaglio dei casi duso
principali
E.2 Seconda iterazione di elaborazione, dettaglio di ulteriori
casi duso
Lelaborato Modello dei Casi duso, nellambito della disciplina dei re-
quisiti, raccoglie in forma scritta i casi duso che descrivono come possa es-
sere utilizzato il sistema per soddisfare gli obiettivi dei suoi utenti. Questo
lapproccio sistematico principale definito nel processo unificato per indi-
viduare, documentare e tracciare i requisiti funzionali e comportamentali
del sistema che si vuole sviluppare.
Un caso duso raccoglie scenari di utilizzo correlati tra loro dal soddi-
sfacimento di un obiettivo specifico per un attore che interagisce con il
sistema. Ogni scenario un particolare percorso duso di successo o insuc-
cesso descritto da una sequenza di interazioni tra il sistema e uno o pi
attori. Secondo le linee guida sono scritti in modo conciso e completo e
in stile essenziale evitando i dettagli di interazione con linterfaccia uten-
te e concentrandosi sullo scopo reale dellutente e sulle responsabilit del
sistema.
45
46 modello dei casi duso
4.1 casi duso di account management
Account Management
Account Management
UC4: Manage
Personal Information
Project Member
UC1: Manage Account
include
UC3: Manage
Custom Information
Account Manager
include
UC2: Manage Company
Figura 5: Diagramma UML casi duso di Account Management
4.1.1 Caso duso UC1: Manage Account
Portata: Applicazione / Sistema di Account Management

Livello: Obiettivo utente
Attore primario: Account Manager
Attore finale: Utente generico del sistema
Parti interessate e interessi:
User Vuole autenticare la propria identit per ottenere accesso al
sistema e ottenere le autorizzazioni associate al proprio ruolo.
Account Manager Vuole consentire laccesso al sistema solo ad
utenti identificati dal sistema di autenticazione (ad esempio trami-
te un account definito da username e password). Vuole attribui-
re agli utenti le autorizzazioni necessarie ad operare nel sistema
limitatamente ai permessi associati al loro ruolo.
Pre-condizioni: LAccount Manager identificato e autenticato.
Garanzia di successo o post-condizioni:
Il Sistema ha creato/modificato/cancellato lAccount dellUtente.
Il Sistema di Notifica invia una mail allUtente per dare informa-
zione delloperazione avvenuta.
Il Sistema di Auditing memorizza il log delloperazione.
Scenario principale di successo:
1. LAccount Manager accede alla dashboard di gestione degli Account.

4.1 casi duso di account management 47
2. Il Sistema visualizza lelenco degli utenti attualmente registrati nel

sistema.
3. LAccount Manager effettua una operazione di gestione Account
utente.
Estensioni:
*a. LAccount Manager annulla loperazione. Il Sistema non registra

alcuna modifica allo stato dellAccount utente e ritorna al punto 2.
*b. LAccount Manager cambia il progetto su cui operare la gestione

utenti. Il Sistema chiede conferma di abbandonare eventuali opera-
zioni pendenti.
3a. LAccount Manager esegue loperazione di inserimento nuovo Ac-

count utente.
1. LAccount Manager imposta i campi username, seleziona da un
elenco la company, seleziona il tipo di Account utente (v. Di-
zionario Dati 3.3.1 a pagina 40)
2. LAccount Manager inserisce o fa generare dal Sistema una pass-
word provvisoria che viene comunicata via email allutente.
3. LAccount Manager pu opzionalmente pre-impostare alcuni
campi addizionali di informazioni personali eseguendo UC4: Ma-
nage Personal Information o definendo campi custom ese-
guendo UC3: Manage Custom Information (v. Dizionario
Dati 3.3.2).
3b. LAccount Manager esegue loperazione di modifica di un Account

utente esistente.
1. LAccount Manager modifica uno o pi campi dellAccount, o
i ruoli associati allAccount, o pu eseguire la procedura per
reimpostare la password.
3c. LAccount Manager esegue loperazione di cancellazione di un Ac-

count utente esistente.
1. Il Sistema disabilita lAccount utente impedendo laccesso ma
mantenendo traccia di tutte le informazioni precedentemente
registrate dallutente nel sistema.
Frequenza di ripetizione: Alcune decine di volte per ogni fase iniziale

di un nuovo progetto per la creazione di nuovi Account. Poche esecuzioni
per nuovi inserimenti o modifiche ad Account esistenti di progetti in corso.
Raramente sono richieste cancellazioni/disattivazioni.
Problemi aperti:
LUtente autenticato ha un accesso limitato al sistema fino a quando

non viene assegnato ad un progetto con un ruolo.
Potrebbe essere richiesta una procedura di importazione per agevo-

lare un numero maggiore di inserimenti o di passaggio da sistemi
legacy.
Possibile integrazione con servizi di directory su protocollo LDAP.
4.1.2 Caso duso UC2: Manage Company

Account Manager Vuole gestire la base di dati delle societ della
catena clienti/fornitori e partner. Vuole memorizzare informazioni
che identificano le societ a cui far riferimento nei documenti e nei
profili utente.
Pre-condizioni: Il Project Manager identificato e autenticato.
Il Sistema ha creato/modificato/cancellato la Company.
1. Account Manager accede alla dashboard di gestione degli Account.

2. Il Sistema visualizza lelenco delle societ attualmente registrate nel
sistema consentendo di filtrare per progetto corrente e altri attributi.
3. LAccount Manager effettua una operazione di gestione di Company.
Estensioni:

alcuna modifica allo stato della Company e ritorna al punto 2.
*b. LAccount Manager cambia il progetto su cui operare la gestione

delle societ. Il Sistema chiede conferma di abbandonare eventuali
operazioni pendenti.
3a. LAccount Manager esegue loperazione di inserimento nuova Com-

pany.
1. LAccount Manager imposta i campi di Company (v. Diziona-
rio Dati 3.3.3 a pagina 40)
2. LAccount Manager pu inserire opzionalmente campi custo-
mizzati associati alla Company eseguendo UC3: Manage Cu-
stom Information.
3b. LAccount Manager esegue loperazione di modifica di una Compa-

ny esistente.
4.1 casi duso di account management 49
1. LAccount Manager modifica i campi della Company

2. LAccount Manager pu inserire o modificare campi customiz-
zati per la Company eseguendo UC3: Manage Custom Infor-
mation.
3c. LAccount Manager esegue loperazione di cancellazione di una Com-

pany esistente.
1. Il Sistema controlla che nessuna entit sia in relazione con la
Company prima di procedere con la cancellazione.
4.1.3 Caso duso UC3: Manage Custom Information

Livello: Obiettivo sottofunzione
Account Manager Vuole personalizzare Account utente e Compa-
ny con campi custom.
Project Member del sistema possono inserire tali informazioni ag-
giuntive nei record e documenti.
Pre-condizioni: LAccount Manager identificato e autenticato.
Il Sistema ha aggiunto/modificato/eliminato i campi custom dalla
base di dati.
1. LAccount Manager effettua una operazione di inserimento/modifi-

ca/cancellazione di campo custom.
Estensioni:

alcuna modifica ai campi custom. Si ritorna al punto di estensione.
1a. Il Sistema non pu cancellare un campo custom utilizzato da un

record per integrit referenziale. Si ritorna al punto di estensione.
1b. Il Sistema non pu modificare un campo custom utilizzato da un

record per integrit referenziale. Si ritorna al punto di estensione.
Problemi aperti:
I campi custom non essendo standardizzati vanno gestiti in modo

da definire in caso di importazione/esportazione/sincronizzazione
della base di dati con sistemi esterni.
4.1.4 Caso duso UC4: Manage Personal Information

Attore primario: Project Member
Project Member Vuole gestire le informazioni del proprio profilo
autonomamente.
Pre-condizioni: Il Project Member identificato e autenticato.
Il Sistema ha inserito/modificato/cancellato informazioni personali
dellutente.
1. Il Project Member accede al proprio profilo.

2. Il Sistema visualizza le informazioni attualmente registrate nel siste-
ma e consente la modifica dei campi personali.
3. Project Member aggiorna le proprie informazioni personali.
Estensioni:
*a. Il Project Member annulla loperazione. Il Sistema non registra alcu-

na modifica allo stato del profilo e ritorna al punto 2.
4.2 casi duso di project management

4.2.1 Caso duso UC5: Manage Project
Portata: Applicazione / Sistema di Project Management

Attore primario: Project Manager
Project Manager Vuole creare e gestire un progetto, configurare i
suoi attributi generali, assegnare gli utenti come membri del pro-
getto specificandone i ruoli, impostare la cartella Repository dei
documenti e impostarne i workflow di gestione.
Il Sistema ha creato/modificato Project, i membri associati, i ruoli
e permessi, i workflow documentali.
Il Sistema di Auditing memorizza il log delle operazioni.
1. Il Project Manager accede alla dashboard di gestione di Progetto.

4.2 casi duso di project management 51
Project Management
Project Management
UC6: Manage
Repository
UC7: Mana-
include ge Project
Members
include
UC5: Manage Project
include
include UC8: Manage
Roles and
Project Manager
Permissions
UC9: Manage
Reference
Paradigm
Figura 6: Diagramma UML casi duso di Project Management
2. Il Sistema visualizza lelenco dei progetti gestiti dal Project Mana-

ger e i dettagli del progetto corrente (se presente).
3. Il Project Manager effettua una operazione di creazione di un nuovo
Progetto:
1. Il Project Manager imposta i campi acronym, title, type, descrip-
tion, status. (v. Dizionario Dati 3.3.4 a pagina 40).
2. Il Project Manager seleziona il customer da un elenco di company
o esegue UC2: Manage Company per aggiungere il cliente del
progetto.
3. Il Project Manager esegue UC9: Manage Reference Paradigm
per impostare i paradigma di gestione dei riferimenti dei docu-
menti e record.
4. Il Project Manager esegue UC6: Manage Repository per impo-
stare la cartella Repository con accesso ristretto ai membri del
progetto che conterr tutti i documenti di progetto.
5. Il Project Manager esegue UC7: Manage Project Members per
assegnare i membri al progetto indicando i loro ruoli. Se neces-
sario definire o modificare ruoli e permessi esegue UC8: Mana-
ge Roles and Permissions.
Estensioni (flussi alternativi):
*a. Il Project Manager cambia il progetto su cui operare la gestione. Il
Sistema chiede conferma di abbandonare eventuali operazioni pen-
denti.
*b. Il Project Manager annulla loperazione. Il Sistema non registra

alcuna modifica allo stato del progetto e ritorna al punto 2.
Frequenza di ripetizione: La creazione di un nuovo progetto con tutte
le impostazioni iniziali viene eseguita raramente (meno di una volta al
mese). Le modifiche alle impostazioni difficilmente avvengono pi di una
volta a settimana.
4.2.2 Caso duso UC6: Manage Repository

Project Manager Vuole impostare il Repository, la cartella conte-
nente tutti i record e i documenti creati nellambito di un progetto.
Il Sistema ha creato/modificato il Repository.
1. Il Project Manager effettua una operazione di gestione sul Reposito-
ry.
*a. Il Project Manager annulla loperazione. Il Sistema non registra alcu-
na modifica allo stato del repository e ritorna al punto di estensione.
1a. Il Project Manager esegue loperazione di creazione del Repository,

necessaria per poter creare record e documenti nel progetto.
1. Il Project Manager imposta il percorso radice del Repository.
2. Il Sistema crea la cartella impostando i permessi di accesso (v.
varianti tecnologiche).
3. Il Sistema crea le sotto cartelle per i vari tipi di record impostan-
do i permessi.
1b. Il Project Manager esegue loperazione di modifica del Repository.

1. Il Project Manager modifica il percorso radice del Repository.
2. Il Sistema sposta il contenuto della cartella con tutti i contenuti
nel nuovo percorso mantenendo i permessi.
Frequenza di ripetizione: Loperazione di impostazione del percorso di

Repository viene effettuata raramente, contestualmente alla creazione di
un nuovo progetto.
Problemi aperti: La procedura di installazione potrebbe prevedere lim-
postazione del percorso del Repository.
4.2.3 Caso duso UC7: Manage Project Members

Attore finale: Project Member
Project Manager Vuole assegnare i Project Member al progetto
definendo i ruoli ricoperti.
Project Member Vuole ottenere accesso alle informazioni dei pro-
getti ai quali stato assegnato.
Il Sistema ha creato/modificato/cancellato la partecipazione di uno
o pi utenti del sistema come membri del progetto e registrato i loro
ruoli.
1. Il Project Manager effettua una operazione di gestione dei membri

del progetto.
*a. Il Project Manager annulla loperazione. Il Sistema non registra alcu-

na modifica allo stato del membri del progetto e ritorna al punto di
estensione.
1a. Il Project Manager esegue loperazione di assegnazione di un nuovo

Project Member al Project.
1. Il Project Manager seleziona da un elenco di utenti il mem-
bro da assegnare al progetto oppure esegue UC1: Manage Ac-
count.
2. Il Project Manager seleziona da un elenco di ruoli il ruolo rico-
perto dal membro del progetto oppure esegue UC8: Manage
Roles and Permissions.
3. Il Project Manager ripete il passo precedente fino a quando ha
assegnato tutti i ruoli ricoperti dal membro di progetto.
1b. Il Project Manager esegue loperazione di attribuzione di un ruolo

aggiuntivo per un membro del progetto.
1. Il Project Manager seleziona da un elenco di ruoli il ruolo rico-
perto dal membro del progetto oppure esegue UC8: Manage
Roles and Permissions.
assegnato tutti i ruoli ricoperti dal membro di progetto.
1c. Il Project Manager esegue loperazione di revoca di un ruolo di un

membro del progetto / elimina un membro dal progetto.
1. Il Project Manager revoca lattribuzione di un ruolo per un mem-
bro del progetto.
eliminato i ruoli ricoperti dal membro di progetto.
* Se non restano attribuiti altri ruoli il membro non potr acce-
dere ulteriormente alle risorse del progetto. Le precedenti ri-
sorse create o modificate dallutente rimangono disponibili nel
sistema.
4.2.4 Caso duso UC8: Manage Roles and Permissions

Project Manager Vuole definire i ruoli che possibile ricoprire nel-
lambito di progetto. Vuole attribuire ai ruoli i permessi di accesso
ai record e documenti.
Project Member Vuole ottenere accesso alle informazioni del pro-
getto secondo i permessi assegnati al proprio ruolo.
Il Sistema ha creato/modificato/cancellato la definizione del ruolo e
i permessi relativi.
1. Il Project Manager effettua una operazione di gestione dei ruoli e

permessi
*a. Il Project Manager annulla loperazione. Il Sistema non registra al-

cuna modifica allo stato dei ruoli del progetto e ritorna al punto di
estensione.
1a. Il Project Manager esegue loperazione di creazione di un nuovo

Role nel progetto eventualmente duplicando un ruolo predefinito.
1. Il Project Manager definisce un nuovo ruolo impostando un eti-
chetta e attribuendo i permessi fra quelli resi disponibili dal
Sistema.
1b. Il Project Manager esegue loperazione di modifica di un ruolo esi-

stente.
1. Il Project Manager modifica letichetta del ruolo e/o modifica le
impostazioni dei permessi associati al ruolo.
1c. Il Project Manager esegue loperazione di cancellazione di un ruolo

dal progetto.
1. Il Sistema elimina il ruolo se questo non assegnato a nessun
membro del progetto.
4.2.5 Caso duso UC9: Manage Reference Paradigm

Project Manager Vuole identificare ogni documento e record con
un riferimento univoco definito da un protocollo o paradigma, basa-
to su regole configurabili, consistente nellambito di un progetto.
Il Sistema ha modificato il protocollo che regola i riferimenti di do-
cumenti e record.
1. Il Project Manager esegue loperazione di modifica del paradigma di
creazione dei riferimenti a documenti e record.
1. Il Project Manager definisce la stringa che costituisce il para-
digma componendola utilizzando i vari campi per gli acroni-
mi di progetto e tipo di documento e i contatori progressivi (v.
Dizionario Dati tab. 6 a pagina 41).
*a. Il Project Manager annulla loperazione. Il Sistema non registra al-
cuna modifica allo stato del paradigma dei riferimenti e ritorna al
punto di estensione.
Problemi aperti:
Se il paradigma viene modificato i documenti precedentemente crea-
ti possono contenere riferimenti non consistenti con il nuovo paradig-
ma. Per continuare ad essere validi senza modifica dei documenti
necessario mantenere nella base dei dati i riferimenti antecedenti alla
modifica immutati.
4.3 casi duso di action item management
Action Item Management

Action Item Management
UC11: Work on
Action Item
Project Member
Assign
Action Item
include
UC10: Manage
Action Item
Action Item Manager include
Review
Action Item
Figura 7: Diagramma UML casi duso di gestione Action Item
4.3.1 Caso duso UC10: Manage Action Item
Portata: Applicazione / Sistema di Action Item Management

Action Item Manager Vuole avviare il workflow di gestione di un
Action Item. Vuole inizializzarne i campi e assegnarne la lavora-
zione ad un membro del progetto. Vuole revisionare il campo verifi-
cation dellAction Item quando la lavorazione segnata come com-
pletata per lapprovazione, e la chiusura dellAI, o rifiutare con una
motivazione per riaprire la lavorazione dellAI. Vuole ritirare un AI
che non stato chiuso per interrompere la lavorazione.
Project Member Vuole ricevere una notifica quando gli viene asse-
gnato un Action Item. Vuole accedere agli AI del progetto e poter
operare sui campi degli AI che gli sono assegnati. Vuole segnare
come completi gli AI di cui completa lesecuzione e verifica.
Pre-condizioni: LAction Item Manager identificato e autenticato.
Il Sistema ha creato/modificato/cancellato i campi dellAction Item.
Il Sistema di Notifica invia una mail allUtente per dare informa-
zione delloperazione avvenuta.
4.3 casi duso di action item management 57
1. LAction Item Manager accede agli Action Item nella dashboard

di progetto o a quelli associati a specifici MOM, NRB o IRPT.
2. Il Sistema visualizza lelenco degli Action Item.
3. LAction Item Manager effettua una operazione di gestione di un
Action Item.
*a. Lutente annulla loperazione. Il Sistema non registra alcuna modifi-
ca allo stato dellAction Item.
1a. Il Action Item Manager tramite un link accede direttamente allo
specifico Action Item.
3a. LAction Item Manager esegue loperazione di creazione di un nuovo
Action Item.
1. Il Sistema crea un riferimento univoco per il nuovo AI in base al
paradigma di progetto attribuendo un numero progressivo. Lo
status dellAI impostato su Initialized.
2. LAI Manager imposta i campi title, description, start date, deadli-
ne, priority.
3b. LAction Item Manager esegue loperazione di assegnazione dellAction
Item ad un membro del progetto.
1. LAction Item Manager seleziona da un elenco di membri del
progetto un Project Member a cui assegnare lAI oppure ese-
gue UC7: Manage Project Members per assegnare un nuovo
membro al progetto.
2. Il Sistema imposta i campi assigner e assignee.
3. Il Sistema invia una notifica allassignee dellavvenuta assegna-
zione dellAI.
3c. LAction Item Manager esegue loperazione di revisione dellAction
Item.
1. LAction Item Manager revisiona lAI e decide se accettare la
verifica o se rifiutare, fornendo una spiegazione del rifiuto.
2. Il Sistema imposta lo status su Closed se la revisione stata
accettata o su Rejected se stata rifiutata.
3. Il Sistema invia una notifica allassignee dellesito della revisione
dellAI e per conoscenza al Project Manager.
3d. LAction Item Manager esegue loperazione di ritiro di un Action
Item.
1. LAction Item Manager interrompe la lavorazione dellAI
2. Il Sistema imposta lo status su Withdrawn.
3. Il Sistema notifica lassignee di abbandonare la lavorazione dellAI.
4.3.2 Caso duso UC11: Work on Action Item
Portata: Applicazione / Sistema di Action Item Management

Project Member Vuole eseguire il processo di lavorazione di un
Action Item. Vuole accedere agli AI del progetto e poter operare su
gli AI che gli sono assegnati. Vuole indicare gli AI di cui completa
lesecuzione e verifica.
Action Item Manager Vuole ricevere una notifica quando com-
pletata la lavorazione dellAction Item.
Il Sistema ha creato/modificato/cancellato i campi dellAction Item.
Il Sistema di Notifica invia le notifiche allAction Item Manager
per dare informazione delloperazione avvenuta.
1. Il Project Member accede agli Action Item nella dashboard di pro-

getto o quelli specifici di un MOM, NRB o IRPT o quelli assegnati
direttamente al Project Member presenti nella dashboard personale.
2. Il Sistema visualizza lelenco degli Action Item evidenziando quel-
li che gli sono stati assegnati, la loro priorit e quelli vicini alla
deadline.
3. Il Project Member esegue unoperazione di lavorazione di un Ac-
tion Item.
*a. Il Project Member annulla loperazione. Il Sistema non registra

alcuna modifica allo stato dellAction Item.
1a. Il Project Member tramite un link accede direttamente allo specifico

Action Item.
3a. Il Project Member visualizza il contenuto di un Action Item.
3b. Il Project Member avvia lelaborazione dellAction Item che gli

stato assegnato.
1. Il Project Member avvia o riprende la lavorazione dellAction
Item
2. Il Sistema imposta il campo status su Started.
3. Il Sistema notifica assigner dellavvenuta presa in carico dellAI.
3c. Il Project Member interrompe lelaborazione dellAction Item che

gli stato assegnato.
4.4 casi duso di meeting management 59
1. Il Project Member interrompe la lavorazione dellAction Item.

2. Il Sistema imposta il campo status su Paused.
3d. Il Project Member conclude lelaborazione dellAction Item che gli

stato assegnato.
1. Il Project Member completa lelaborazione dellAction Item
compilando obbligatoriamente il campo verification con le sue
conclusioni.
2. Il Sistema imposta il campo status su Completed ad indicare
che lAI pronto per la revisione.
3. Il Sistema notifica lassigner del completamento dellelaborazio-
ne e invia la richiesta di revisione dellAI.
4.4 casi duso di meeting management
Meeting Management
Meeting Management
Edit Minutes
of Meeting
UC10: Manage
Action Item
include
include
Request Review
UC12: Manage include of Meeting
Meeting
Project Member include
UC13: Review
include Minutes of
Meeting
Close Meeting
Review
Figura 8: Diagramma UML casi duso di gestione Meeting
4.4.1 Caso duso UC12: Manage Meeting
Portata: Applicazione / Sistema di Meeting Management

Project Member Vuole pianificare un Meeting nellambito di un

progetto.
Action Item Manager Vuole ricevere una notifica quando com-
pletata la lavorazione dellAction Item creato nel Meeting.
Il Sistema ha creato/modificato/cancellato i campi dellMeeting, re-
gistrato i partecipanti, lagenda e i verbali.
Il Sistema di Notifica invia le notifiche ai partecipanti del Meeting.
1. Il Project Member accede alla dashboard nel progetto corrente o

quella personale.
2. Il Sistema visualizza nel calendario di progetto e in quello personale
i Meeting programmati evidenziando quelli di cui si organizzatori
o invitati e quelli in corso.
3. Il Project Member esegue unoperazione di gestione di un Meeting.

alcuna modifica allo stato del Meeting.

Meeting.
3a. Il Project Member visualizza il contenuto di un Meeting di cui

autore o di cui ha ricevuto linvito a partecipare.
3b. Il Project Member pianifica un nuovo Meeting.

1. Il Project Member stabilisce la data, lagenda e il luogo della
riunione.
2. Il Project Member pu allegare dei file da visionare nel campo
attachments.
3. Il Project Member seleziona lelenco dei partecipanti tra i mem-
bri del progetto.
4. Il Sistema imposta lo status su Planned.
5. Il Sistema di notifica invia un invito al meeting ai partecipanti
(campo attendants).
3c. Il Project Member conferma o meno la partecipazione ad un Mee-

ting al quale stato invitato.
1. Il Project Member risponde allinvito confermando o meno la
partecipazione.
4.4 casi duso di meeting management 61
2. Il Sistema registra la risposta nel Meeting. Il pianificatore del

meeting pu visualizzare lo stato delle conferme di partecipa-
zione.
3d. Il Project Member redige i verbali di un Meeting.

1. Il Sistema imposta/reimposta lo status del Meeting su Opened
2. Il Project Member compila o modifica i verbali della riunione
nel campo minutes. Se i verbali erano gi stati approvati
necessario avviare un nuovo processo di revisione eseguendo
UC13: Review Minutes of Meeting.
3. Il Project Member pu allegare dei file nel campo attachments a
cui fare riferimento nei minutes.
3e. LAction Item Manager dispone lelenco degli Action Items associa-
ti al meeting eseguendo UC10: Manage Action Item. Di default
lautore sar lassigner dellAI.
4.4.2 Caso duso UC13: Review Minutes of Meeting

Attore finale: Project Manager
Project Member Vuole avviare il processo di revisione dei verbali
per ottenere lapprovazione dei partecipanti di un meeting. Vuole
generare i verbali firmati digitalmente al termine del processo di
revisione.
Project Manager Vuole ricevere notifica della chiusura finale di
ogni meeting.
Pre-condizioni:
Il Project Member identificato e autenticato.
Il campo minutes contenente i verbali devono essere stati compilati.
Il Sistema ha chiuso e firmato digitalmente i verbali del meeting.
Il Sistema di Notifica invia al Project Manager informazione della
chiusura di un Meeting.
1a. Il Project Member avvia il processo di revisione dei verbali del

Meeting. I verbali nel campo minutes devono essere stati compilati.
1. Il Project Member seleziona uno o pi partecipanti al meeting
di cui richiesta lapprovazione delle minutes.
2. Il Sistema imposta il campo status su Review per indicare che il

meeting in attesa di approvazione dei verbali.
3. Il Sistema notifica gli attendees selezionati della richiesta di ap-
provazione.
1b. Il Project Member risponde ad una richiesta di revisione dei verbali

di un Meeting in stato di Review.
1. Il Project Member risponde approvando o rigettando le minutes.
2. Il Sistema registra la risposta nel Meeting. Il pianificatore del
meeting pu visualizzare lo stato delle approvazioni.
3. Il Sistema imposta lo status del meeting su Closed quando i
verbali sono stati approvati da tutti i revisori.
1c. Il Project Member esegue loperazione di chiusura di un Meeting

concluso con lapprovazione dei verbali.
1. Il Sistema imposta lo status delle minutes su Released.
2. Il Sistema genera i verbali firmati digitalmente eseguendo UC16: Ap-
ply Digital Sign.
3. Il Sistema registra i verbali firmati digitalmente.
4. Il Sistema invia notifica al Project Manager lesito del meeting.
Requisiti speciali:
La procedura di apposizione della firma digitale al documento di

report garantisce lautenticit e integrit del documento.
4.5 casi duso di document management

4.5.1 Caso duso UC14: Manage Document
Portata: Applicazione / Sistema di Document Management

Project Member Vuole creare, modificare, allegare un Document
di progetto. Vuole richiedere la revisione e approvazione di un
documento.
Il Sistema ha creato/modificato/allegato/cancellato/posto in revi-
sione/ firmato digitalmente un documento.
4.5 casi duso di document management 63
Document Management
Document Management
View Document
Create Document
include
include Modify
Document
include
UC14: Manage
Document Request
include
Document
Project Member Review
include
include
UC15: Review
Release Document
Document
include
UC16: Apply
Digital Sign
UC6: Manage
Repository
Project Manager UC9: Manage

Reference Paradigm
Figura 9: Diagramma UML casi duso di Document Management
1. Il Project Member accede ai documenti nella dashboard nel proget-

to corrente o ai documenti nella dashboard personale o a qualunque
documento associato alle rich text area in ogni tipo di record.
2. Il Sistema visualizza i documenti nel repository del progetto o lelen-
co dei documenti di cui il Project Member autore o quelli associati
al record.
3. Il Project Member esegue unoperazione di gestione di un Docu-
mento.

alcuna modifica allo stato del Document.

Document.
3a. Il Project Member visualizza il contenuto di una rich text area o

apre un Document di progetto.
3b. Il Project Member esegue loperazione di creazione di un nuovo

Document.
1. Il Sistema inizializza i campi author, la data di creazione, la
versione con issue e revision.
2. Il Project Member imposta i campi type, title, status.
3. Il Project Member allega il file che costituisce la prima versione
o seleziona un Template, un documento preimpostato, da cui
partire.
4. Il Sistema crea un riferimento univoco per il documento, basa-
to sul paradigma impostato a livello di progetto (v. Diziona-
rio Dati 3.3.5), che pu essere derivato dai metadati e numeri
progressivi univoci di documento per autore e progetto.
5. Il Sistema carica nel repository di progetto la prima versione
del documento. Il file viene salvato nella cartella dei documenti
o pertinente al tipo di record. Il nome del file contiene come
prefisso il riferimento univoco del documento.
3c. Il Project Member esegue loperazione di modifica di un Docu-

ment.
1. Il Sistema aggiunge il Project Member agli autori e imposta il
campo date modified.
2. Il Project Member pu modificare i campi metadati.
3. Il Project Member modifica il contenuto della rich text area o
allega una nuova versione del file.
4. Il Sistema incrementa il campo revision.
5. Il Sistema crea un nuovo riferimento univoco per la nuova revi-
sione del documento.
6. Il Sistema carica nel repository di progetto la nuova versione
del documento. Il file viene salvato nella cartella dei documenti
o quella pertinente al tipo di record. Il nome del file contiene
come prefisso il riferimento univoco del documento.
4.5.2 Caso duso UC15: Review Document

Project Member Vuole avviare il processo di revisione di un do-
cumento modificato per ottenere lapprovazione dei revisori. Vuole
generare il documento firmato digitalmente al termine del processo
4.5 casi duso di document management 65
di revisione. Vuole ricevere notifica del rilascio finale del documento

firmato.
Pre-condizioni:
Il Sistema ha posto in revisione il documento, rilasciato e firmato
digitalmente il documento revisionato.
Il Sistema di Notifica invia al Project Member informazione della
richiesta di revisione, lesito della revisione, il rilascio del documento
firmato.
1a. Il Project Member avvia il processo di revisione di un Document.

1. Il Project Member seleziona uno o pi membri del progetto
a cui richiedere la revisione del documento. La lista pre
popolata con gli autori del documento e precedenti revisori del
documento.
2. Il Sistema imposta il campo status su Review per indicare che il
documento sotto revisione.
3. Il Sistema notifica i revisori della richiesta di revisione del do-
cumento.
1b. Il Project Member risponde ad una richiesta di revisione di un

Document in stato Review.
1. Il Project Member approva o rigetta la revisione del documento
fornendo delle motivazioni indicate nel campo remarks.
2. Il Sistema notifica allautore lesito della revisione.
1c. Il Project Member esegue loperazione di rilascio del Document

revisionato e approvato.
1. Il Sistema imposta lo status del documento su Released.
2. Il Sistema genera il documento firmato digitalmente eseguendo
UC16: Apply Digital Sign.
3. Il Sistema registra il documento firmato digitalmente.
4. Il Sistema notifica gli autori e revisori del rilascio del documento
firmato.
Requisiti speciali:
La procedura di apposizione della firma digitale al documento ga-

rantisce lautenticit e integrit del documento.
4.5.3 Caso duso UC16: Apply Digital Sign
Portata: Applicazione / Sistema di Document Management

Project Member Vuole che un documento sottoposto a revisione e
di cui siano approvate le modifiche sia rilasciato e memorizzato con
firma digitale per garantirne autenticit e integrit.
Pre-condizioni:
Il documento da firmare in stato Released.
Il Sistema di Crittografia ha applicato la firma digitale al docu-
mento.
1. Il Sistema esegue il processo di firma digitale del documento.

2. Il Sistema memorizza nel repository del progetto il documento fir-
mato digitalmente.
4.6 casi duso di configuration management
4.6.1 Caso duso UC17: Navigate Product Tree
Portata: Applicazione / Sistema di Configuration Management

Project Member Vuole accedere alla struttura gerarchica ad albero
del Product Tree per gestire il processo di Configuration Mana-
gement con le attivit previste dal ciclo di vita del prodotto. Vuole
identificare, trattare, gestire, confrontare:
aggregati di hardware, software, materiali, servizi o loro porzio-
ni discrete come entit singole definite in un Configuration
Item identificate da un codice CI.
le parti e la combinazione di parti (assembly) come entit singo-
le definite in un Part identificate dalla composizione del codice
di Configuration Item e da un part number comprensivo di
versione.
4.6 casi duso di configuration management 67
Configuration Management
Configuration Management
Generate
Product
Baseline
include
UC19: Manage
Part and Assembly
include
UC17: Navigate
Product Tree
Project Member
include
include
UC18: Manage
Configuration
Item
Configuration Manager
UC20: Manage
Manufactured
Part
QA Member
Figura 10: Diagramma UML casi duso di Configuration Management
i manufatti come entit singole definite in un Manufactured

Part identificato dalla composizione di un codice Configura-
tion Item, da un part number comprensivo di versione e da un
batch e serial number.
Il Sistema ha dato accesso alla struttura del Product Tree.
1. Il Project Member accede al Product Tree nella dashboard di pro-
getto.
2. Il Sistema visualizza la struttura ad albero che costituisce il Product
Tree per consentire laccesso ai vari livelli della gerarchia: i Confi-
guration Item, le parti Part o parti assemblate, le Manufactured
Part. Il Project Member pu applicare filtri e effettuare ricerche.
3. Il Project Member naviga la struttura ad albero:
pu esplodere o contrarre i nodi Configuration Item per acce-
dere alle parti Part o parti assemblate;
pu esplodere o contrarre i nodi Part per accedere ai Manu-

factured Part.

Configuration Item, Part, Manufactured Part.
2a. Il Project Member filtra:

i Configuration Item per tipologia o stato.
i Part per tipologia o stato.
i Manufactured Item per stato.
2b. Il Project Member ricerca:

i configuration item per ci code
le parti e gli assiemi di parti per part number
i manufatti per batch e serial number.
4.6.2 Caso duso UC18: Manage Configuration Item

Attore primario: Configuration Manager
Configuration Manager Vuole gestire il processo di Configura-
tion Management con le attivit previste dal ciclo di vita del pro-
dotto. Vuole identificare, trattare, gestire, confrontare aggregati di
hardware, software, materiali, servizi o loro porzioni discrete come
entit singole definite in un Configuration Item identificate da un
codice CI. Vuole documentare i requisiti funzionali, progettuali, co-
struttivi, produttivi e di verifica di un Configuration Item. Vuole
generare la distinta base (Configuration Baseline) di una confi-
gurazione approvata che possa essere usata come riferimento. Vuole
controllare le modifiche alla configurazione rispetto alla distinta base
(Configuration Change & Control).
Pre-condizioni: Il Configuration Manager identificato e autenticato.
Il Sistema ha creato/modificato/cancellato i campi del Configuration
Item, o la struttura del Product Tree.
1. Il Configuration Manager naviga, filtra, ricerca, seleziona un Con-

figuration Item nel Product Tree eseguendo il caso duso UC17: Na-
vigate Product Tree.
2. Il Configuration Manager effettua una operazione di gestione di un

Configuration Item.
ca allo stato del Configuration Item e del Product Tree.
2a. Il Configuration Manager esegue loperazione di creazione di un
nuovo Configuration Item.
1. Il Sistema crea un identificativo univoco nel progetto (CI code)
per il nuovo CI e il riferimento al CI padre (o la radice). Lo
status dellCI impostato sul valore di default Active.
2. Il CI Manager imposta i campi name, description, type (v. Model-
lo dei Dati ConfigurationItem).
3. Il CI Manager pu assegnare uno o pi responsabili del CI
eseguendo il flusso alternativo 2c.
4. Il CI Manager pu allegare documenti, disegni e datasheet co-
me attachments.
2b. Il Configuration Manager esegue loperazione di modifica di un Con-
figuration Item.
1. Il CI Manager pu modificare i campi name, description, type.
2. Il CI Manager pu modificare lelenco dei responsabili del CI
eseguendo il flusso alternativo 2c.
3. Il CI Manager pu modificare lelenco degli allegati attachments.
2c. Il Configuration Manager assegna uno o pi responsabili per il Con-
figuration Item tra i membri del progetto.
1. Il Configuration Manager seleziona da un elenco di membri del
progetto uno o pi Project Member responsabili del CI oppu-
re esegue UC7: Manage Project Members per assegnare un
nuovo membro al progetto.
2. Il Sistema invia una notifica ai responsabili dellavvenuta asse-
gnazione del CI e per conoscenza al Project Manager.
2d. Il Configuration Manager ritira un Configuration Item dal Product
Tree.
1. Il Configuration Manager sospende lutilizzo del CI.
2. Il Sistema imposta lo status su Withdrawn.
3. Il Sistema notifica i membri del progetto nellelenco responsibles
di non utilizzare il CI.
Requisiti speciali:
Un Configuration Item ritirato dal Product Tree rimane registrato
nel sistema per tracciabilit e per confronto con versioni e modifiche
successive.
4.6.3 Caso duso UC19: Manage Part and Assembly

Attore finale: Configuration Manager
Configuration Manager Vuole gestire il processo di Configura-
tion Management con le attivit previste dal ciclo di vita del pro-
dotto. Vuole identificare, trattare, gestire, confrontare le parti e la
combinazione di parti (assembly) come entit singole definite in un
Part identificate dalla composizione del codice di Configuration
Item e da un Part Number comprensivo di versione.
Project Member Vuole documentare i requisiti funzionali, proget-
tuali, costruttivi, produttivi e di verifica di un Part allegando do-
cumenti di progetto e disegni, memorizzando lelenco dei materiali,
delle finiture, dei processi.
Pre-condizioni: Il Configuration Manager identificato e autenticato.
Il Sistema ha creato/modificato/cancellato i campi del Part, o la
struttura del Product Tree.
1. Il Project Member naviga, filtra, ricerca, seleziona un Part nel

Product Tree eseguendo il caso duso UC17: Navigate Product
Tree.
2. Il Project Member effettua una operazione di gestione di un Part.

ca allo stato del Part e del Product Tree.
2a. Il Configuration Manager esegue loperazione di creazione di una

nuova Part.
1. Il Sistema crea un identificativo Part Number univoco nel proget-
to per la nuova parte. Se parte di un assieme (assembly) viene
impostato il riferimento tra la parte assemblata e la parte pa-
dre. Part sempre riferito ad un Configuration Item. I campi
status e version vengono inizializzati.
2. Il CI Manager imposta i campi name, type, weight.
3. Il CI Manager imposta il campo description che pu essere un
documento o disegno o datasheet allegato (v. Dizionario Dati
3.3.6).
4. Il CI Manager pu selezionare i materiali, le finiture, i processi.
5. Il CI Manager pu allegare documenti, disegni e datasheet co-

me attachments.
2b. Il Project Member esegue loperazione di modifica di un Part.

1. Il Configuration Manager carica una nuova versione del dise-
gno o datasheet.
2. Il Sistema crea una nuova versione della parte con il campo
version incrementato.
3. Se il Configuration Manager ha completato la progettazione
della parte imposta il campo status su Released.
2c. Il Configuration Manager esegue loperazione di generazione di una

baseline di prodotto (product configuration baseline (PCB)).
1. Il Configuration manager ha completato la progettazione della
parte e, in caso di parte assemblata, di ogni sottoparte, tutte in
stato Released.
2. Il Sistema genera una Product Baseline con la versione corren-
te di ogni parte.
2d. Il Project Member esegue loperazione di creazione della distinta

base (Bill of Material) di un Assembly.
1. Il Sistema genera un rapporto con lelenco di tutte le parti e
sottoparti di una parte assemblata.
2e. Il Configuration Manager ritira un Part dal Product Tree.

1. Il Configuration Manager sospende lutilizzo della parte o as-
sembly.
2. Il Sistema imposta lo status su Superseded.
Problemi aperti: La possibilit di gestire il versioning di record e docu-

menti una caratteristica critica per larchitettura del sistema.
4.6.4 Caso duso UC20: Manage Manufactured Part

Attore primario: Quality Assurance Member
Configuration Manager Vuole eseguire il processo di Configu-
ration Management con le attivit previste nel ciclo di vita del
prodotto spaziale.
Quality Assurance Member Vuole identificare, trattare, gestire, con-
frontare i manufatti come entit singole definite in un Manufactu-
red Part identificato dalla composizione di un codice Configura-
tion Item, da un part number comprensivo di versione e da un batch
e serial number.
Pre-condizioni: Il QA Member identificato e autenticato.

Il Sistema ha creato/modificato/cancellato i campi del Manufactu-
red Part.
1. Il QA Member naviga, filtra, ricerca, seleziona un Manufactured

Part nel Product Tree eseguendo il caso duso UC17: Navigate
Product Tree.
2. Il QA Member effettua una operazione di gestione di un Manufac-
tured Part.

ca allo stato del Manufactured Part.
2a. Il QA Member esegue loperazione di creazione di una nuovo Ma-

nufactured Part usualmente prima o durante un rapporto di ispe-
zione (IRPT).
1. Il QA Member imposta gli identificativi seriali batch number e
serial number univoci nel progetto per il nuovo Manufactured
Part relativo ad un specifico Configuration Item e Part.
2. Il QA Member imposta i campi description, status, manufacturer.
2b. Il QA Member ispeziona e approva un Manufactured Part.

1. Il QA Member approva lutilizzo della parte fabbricata.
2. Il Sistema imposta il campo status su Approved.
2c. Il QA Member ritira un Manufactured Part dal Product Tree.

1. Il QA Member sospende lutilizzo della parte fabbricata.
2. Il Sistema imposta lo status su Rejected.
4.7 casi duso di inspection report management

4.7.1 Caso duso UC21: Manage Inspection Report
Portata: Applicazione / Sistema di Inspection Report Management

4.7 casi duso di inspection report management 73
Inspection Report Management

Inspection Report Management
View Inspection
Report
UC10: Manage
Project Member Action Item
include
UC17: Navigate
Product Tree include
include
UC21: Manage
Inspection Report
QA Member include
include
UC22: Close
Inspection Report
UC23: Manage Non
Conformance
Report
Figura 11: Diagramma UML casi duso di gestione Inspection Report
Quality Assurance Member Vuole gestire i rapporti di ispezione di

parti e componenti per valutare la conformit, ovvero il soddisfaci-
mento dei requisiti, per osservazione e giudizio basato su misure, ve-
rifiche e criteri di accettazione o rifiuto espressi in modi non ambigui
e quantificabili, nei margini di tolleranza.
Vuole identificare, classificare, tracciare, gestire prontamente le non
conformit, per fornire ai consigli di revisione delle non conformi-
t tutte le informazioni necessarie ad approntare azioni correttive e
preventive.
Il Sistema ha creato/modificato/cancellato i campi del Inspection
Report.
1. Il QA Member accede agli Inspection Reports (IRPT) nella dash-
board di progetto o personale.
2. Il Sistema visualizza lelenco degli IRPT.
3. Il QA Member effettua una operazione di gestione di un IRPT.
ca allo stato del Inspection Report.
1a. Il QA Member tramite un link accede direttamente allo specifico

IRPT.
3a. Il Project Member esegue loperazione di visualizzazione di un In-

spection Report.
1. Il Sistema visualizza il rapporto di ispezione redatto dal QA
Member con lelenco degli elementi ispezionati e in presenza
di non conformit dei rapporti NCR e le azioni correttive e
preventive stabilite dal NRB.
3b. Il QA Member esegue loperazione di creazione di un nuovo Inspec-

tion Report.
1. Il Sistema crea un riferimento univoco per il nuovo IRPT in base
al paradigma di progetto attribuendo un numero progressivo.
Lauthor impostato automaticamente e lo status dellIRPT
impostato su Open.
2. Il QA Member imposta i campi title, type, la data di ispezione
date, la struttura o facility luogo dellispezione (v. Dizionario
Dati 3.3.7).
3. Il QA Member predispone un elenco di Inspected Items sele-
zionando gli elementi dal Product Tree. Usualmente i Confi-
guration Item e i Part sono gi presenti nel sistema e ritro-
vabili per navigazione o ricerca per codice CI e part number
eseguendo UC17: Navigate Product Tree. I manufatti oggetto
di ispezione usualmente richiedono linserimento dei codici se-
riali, batch number e serial number, ottenuti durante lispezione e
inputati nel sistema eseguendo UC20: Manage Manufactured
Part.
4. Il QA Member crea un nuovo documento, eventualmente utiliz-
zando un template per IRPT, o allega un documento preimpo-
stato per il campo report eseguendo UC14: Manage Document.
3c. Il QA Member esegue loperazione di creazione di un Non-conformance

Report.
1. Il QA Member identifica una non conformit durante una ispe-
zione che viene documentata creando un nuovo rapporto di
non conformit eseguendo UC23: Manage Non Conforman-
ce Report. Il nuovo NCR sar automaticamente prepopolato
con lInspected Item non conforme e creata lassociazione con
lIRPT.
2. Il Sistema visualizza nellIRPT lelenco di tutti gli Action Item
con le azioni correttive e preventive stabilite dal NRB a seguito
del NCR risultato dellispezione.
4.8 casi duso di non conformance report management 75
4.7.2 Caso duso UC22: Close Inspection Report

Quality Assurance Member Vuole generare il rapporto finale di
ispezione in cui si concluso il processo di gestione delle non confor-
mit di parti e componenti con la chiusura dei rapporti NCR e di cui
siano state intraprese e concluse tutte azioni correttive e preventive
(AI).
Project Manager Vuole ricevere notifica della chiusura finale di
ogni rapporto di ispezione.
Pre-condizioni:
Il QA Member identificato e autenticato.
Tutti i rapporti di non conformit associati allIRPT risultano in stato
Closed assieme a tutti i rispettivi Action Item.
Il Sistema ha chiuso e firmato digitalmente lInspection Report.
Il Sistema di Notifica invia al QA Manager informazione della
chiusura di un Inspection Report.
1. Il QA Member esegue loperazione di chiusura di un Inspection

Report.
1. Il Sistema imposta il campo status su Closed.
2. Il QA Member esegue UC16: Apply Digital Sign per firmare
digitalmente lInspection Report.
3. Il Sistema invia una notifica al Project Manager dellesito del
rapporto di ispezione.
4.8 casi duso di non conformance report ma-

nagement
4.8.1 Caso duso UC23: Manage Non Conformance Report
Portata: Applicazione / Sistema di Non Conformance Management

Attore primario: QA Member
Non Conformance Report Management

Non Conformance Report Management
View Non
Conformance
Report
Project Member
UC12: Manage
Meeting
include UC10: Manage

Action Item
include
UC23: Manage
Non Conformance
Report include
QA Member Request
NCR Review
include include
Release NCR
UC24: Review Non
Conformance Report
Figura 12: Diagramma UML casi duso di gestione Non Conformance Report
QA Member Vuole eseguire il processo di Non Conformance Ma-

nagement con le attivit previste nel ciclo di vita dal progetto spa-
ziale ad ogni livello della catena clientefornitore. Vuole identificare,
elaborare, tracciare le non conformit di elementi, parti e manufatti
prodotti. Vuole redarre prontamente rapporti per analizzare, investi-
gare, classificare, documentare le non conformit. Vuole comunicare
e sottoporre i rapporti NCR ai consigli di revisione NRB interni e con
il cliente per approntare e disporre azioni correttive e preventive.
Il Sistema ha creato/modificato/posto in revisione/firmato digital-
mente un rapporto di non conformit.
Il Sistema di Notifica invia le notifiche ai membri del NRB.
1. Il QA Member accede ai Non Conformance Report nella dash-

board nel progetto corrente o ai rapporti NCR nella dashboard per-
sonale o ai rapporti NCR generati in un Inspection Report.
2. Il Sistema visualizza i rapporti di non conformit nel repository del
progetto o lelenco dei rapporti NCR di cui il Project Member
autore o quelli associati allIRPT.

3. Il Project Member esegue unoperazione di gestione di un Non
Conformance Report.
*a. Il QA Member annulla loperazione. Il Sistema non registra alcuna

modifica allo stato del Non Conformance Report.
1a. Il QA Member tramite un link accede direttamente allo specifico

Non Conformance Report.
3a. Il Project Member esegue loperazione di visualizzazione di un

Non Conformance Report di progetto contenuto in una rich text
area o aprendo il documento.
3b. Il QA Member esegue loperazione di creazione di un nuovo Non

Conformance Report con un primo set di informazioni preliminari
da sottoporre al consiglio di revisione delle non conformit interno.
1. Il Sistema inizializza i campi author, la data di creazione, lo sta-
tus su Initialized. Se il caso duso viene invocato nella gestione
di un Inspection Report lelenco degli elementi non conformi
viene preimpostato con lInspected Item.
2. Il QA Member imposta i campi title e type.
3. Il QA Member seleziona una o pi combinazioni di Configura-
tion Item, Part e Manufactured Part per formare lelenco de-
gli elementi non conformi eseguendo UC17: Navigate Product
Tree.
Il rapporto di non conformit relativo ad un Configuration
Item, identificato da codice CI, si intende applicato a tutte le
parti, parti assemblate, e manufatti con codici part number e se-
riali batch e serial number in relazione con il Configuration Item
non conforme.
Similmente il rapporto di non conformit relativo ad un Part,
identificato da codice part number, si intende applicato a tutte le
parti assemblate e ai manufatti con codici part number e seriali
batch e serial number in relazione con la parte o parte assemblata
non conforme.
Un manufatto trovato non conforme durante un ispezione usual-
mente richiede linserimento del codice seriale, batch number e se-
rial number, ottenuto durante lispezione e inputato nel sistema
eseguendo UC20: Manage Manufactured Part.
4. Il QA Member seleziona uno o pi testimoni (witnesses) presen-
ti durante la scoperta della non conformit, il luogo in cui si
verificata (facility), lattivit (activity) in corso di svolgimento
quando si verificata.
5. Il QA Member allega il file che costituisce la prima versione del

rapporto o seleziona un Template, un documento di rapporto
preimpostato, da cui partire.
6. Il Sistema crea un riferimento univoco per il rapporto NCR, ba-
sato sul paradigma impostato a livello di progetto (v. Diziona-
rio Dati 3.3.5), che pu essere derivato dai metadati e numeri
progressivi univoci di rapporto NCR per autore e progetto.
7. Il Sistema carica nel repository di progetto la prima versione del
rapporto. Il file viene salvato nella cartella dei rapporti o perti-
nente al tipo di record. Il nome del file contiene come prefisso
il riferimento univoco del documento.
3c. Il QA Member convoca il consiglio di revisione delle non conformit

(NRB) per la revisione del NCR.
1. Il QA Member pianifica una riunione per convocare i membri
del NRB eseguendo UC12: Manage Meeting.3b. Il primo con-
siglio convocato sempre di tipo interno, ai successivi consigli
possono prendere parte anche i clienti di livelli superiori.
3d. I membri del Non Conformance Review Board modificano il Non

Conformance Report nei consigli di revisione eseguendo le attivit
del processo di analisi, classificazione, revisione e controllo delle non
conformit. possibile che il consiglio di revisione sia convocato
pi volte, sia internamente che coinvolgendo i clienti, per definire
e revisionare le azioni e le disposizioni da mettere in atto per la
gestione delle non conformit e arrivare a chiudere il rapporto.
1. Il NRB valuta le cause e lestensione delle non conformit e se
hanno impatto sui requisiti di clienti di livello superiore questi
entrano a far parte del NRB. Un QA Member pianifica la succes-
siva riunione per convocare il NRB esteso ai clienti eseguendo
UC12: Manage Meeting 3b.
2. Il QA Member appronta e assegna le azioni correttive e pre-
ventive rispettivamente per eliminare le cause e per evitare il
verificarsi delle non conformit in elementi simili, come stabili-
te dal consiglio di revisione interno o con il cliente, eseguendo
UC10: Manage Action Item.
3. Il QA Member registra le disposizioni stabilite dal consiglio di
revisione interno o con il cliente per gli elementi non conformi:
Return to Supplier per elementi non conformi da ritorna-
re al fornitore;
Use As Is per elementi che possono essere utilizzati senza
eliminare la non conformit;
Rework per elementi che possibile recuperare nello stato
conforme ai requisiti specificati;
Repair per elementi che possibile recuperare ai requisiti

duso atteso anche se non conforme ai requisiti specificati
in origine;
Scrap per elementi che non possibile recuperare con una
rilavorazione o riparazione, per motivi tecnici o economici.
Il Sistema pone lo status del NCR su Disposition. A meno di
ulteriori modifiche, il rapporto permane in tale stato fino a che
tutti gli Action Item creati contestualmente al NCR sono stati
elaborati e portati positivamente a chiusura.
4. Il QA Member modifica il contenuto del rapporto nella rich text
area o allega una nuova versione del documento.
5. Il Sistema crea un nuovo riferimento univoco per la nuova re-
visione del documento di rapporto con il campo revision incre-
mentato.
6. Il Sistema carica nel repository di progetto la nuova versione
del documento. Il file viene salvato nella cartella dei rapporti
o quella pertinente al tipo di record. Il nome del file contiene
come prefisso il riferimento univoco del rapporto.
7. Il Project Member redige i verbali del meeting del consiglio di
revisione eseguendo UC12: Manage Meeting.3d.
8. Il Project Member richiede la revisione dei verbali del mee-
ting ai membri del NRB eseguendo UC13: Review Minutes of
Meeting.1a.
4.8.2 Caso duso UC24: Review Non Conformance Report

Attore finale: Quality Assurance Manager
Quality Assurance Member Vuole avviare il processo di revisione
del rapporto di non conformit per ottenere lapprovazione dei mem-
bri del NRB dopo che siano state elaborate e concluse tutte azioni
correttive e preventive (AI). Vuole generare il rapporto finale di non
conformit firmato digitalmente al termine del processo di revisione.
Quality Assurance Manager Vuole ricevere notifica della chiusura
finale di ogni rapporto di non conformit.
Pre-condizioni:
Il QA Member identificato e autenticato.
Tutti gli Action Item associati al rapporto di non conformit NCR
risultano in stato Closed.
Il Sistema ha chiuso e firmato digitalmente il Non Conformance

Report.
Il Sistema di Notifica invia al QA Manager informazione della
chiusura di un Non Conformance Report.
1a. Il Sistema avvia il processo di revisione del rapporto NCR quan-

do tutti gli Action Item creati contestualmente al NCR sono stati
elaborati e portati positivamente a chiusura.
1. Il Sistema imposta lo status dellNCR su Review per indicare
che il rapporto di non conformit in attesa di approvazione
finale prima della chiusura.
2. Il Sistema notifica i membri dellultimo NRB della richiesta di
approvazione del NCR.
1b. Un membro del NRB risponde ad una richiesta di revisione del

rapporto NCR.
1. Il Project Member risponde approvando o rigettando il rapporto
di non conformit.
2. Il Sistema registra la risposta nel rapporto che riporta lo stato
delle approvazioni.
3. Il Sistema imposta lo status del NCR su Closed quando il rap-
porto stato approvato da tutti i membri del NRB.
1c. Il QA Member esegue loperazione di pubblicazione di un Non Con-

formance Report approvato.
1. Il Sistema imposta il campo status del report su Released.
2. Il QA Member esegue UC16: Apply Digital Sign per firmare
digitalmente il NCR.
3. Il Sistema registra il rapporto NCR firmato digitalmente.
4. Il Sistema invia una notifica al QA Manager dellesito del rap-
porto di non conformit.
The magnetic field along the Galactic plane
Credit ESA/Planck Collaboration. Acknowledgment: M.-A. Miville-Deschenes, CNRS Institut dAstrophysique Spatiale, Universite Paris-XI, Orsay,
France
The magnetic field along the Galactic plane
Released
15/12/2014 12:00 pm
Description
While the pastel tones and fine texture of this image may bring to mind brush strokes on an artists canvas, they are in fact a visualisation of data from
ESAs Planck satellite. The image portrays the interaction between interstellar dust in the Milky Way and the structure of our Galaxys magnetic
field. Between 2009 and 2013, Planck scanned the sky to detect the most ancient light in the history of the Universe the cosmic microwave
background. It also detected significant foreground emission from diffuse material in our Galaxy which, although a nuisance for cosmological studies,
is extremely important for studying the birth of stars and other phenomena in the Milky Way.
Among the foreground sources at the wavelengths probed by Planck is cosmic dust, a minor but crucial component of the interstellar medium
that pervades the Galaxy. Mainly gas, it is the raw material for stars to form. Interstellar clouds of gas and dust are also threaded by the Galaxys
magnetic field, and dust grains tend to align their longest axis at right angles to the direction of the field. As a result, the light emitted by dust grains
is partly polarised it vibrates in a preferred direction and, as such, could be caught by the polarisation-sensitive detectors on Planck.
Scientists in the Planck collaboration are using the polarised emission of interstellar dust to reconstruct the Galaxys magnetic field and study its
role in the build-up of structure in the Milky Way, leading to star formation.
In this image, the colour scale represents the total intensity of dust emission, revealing the structure of interstellar clouds in the Milky Way. The
texture is based on measurements of the direction of the polarised light emitted by the dust, which in turn indicates the orientation of the magnetic
field. This image shows the intricate link between the magnetic field and the structure of the interstellar medium along the plane of the Milky Way.
In particular, the arrangement of the magnetic field is more ordered along the Galactic plane, where it follows the spiral structure of the Milky Way.
Small clouds are seen just above and below the plane, where the magnetic field structure becomes less regular.
From these and other similar observations, Planck scientists found that filamentary interstellar clouds are preferentially aligned with the direction
of the ambient magnetic field, highlighting the strong role played by magnetism in galaxy evolution. The emission from dust is computed from a
combination of Planck observations at 353, 545 and 857 GHz, whereas the direction of the magnetic field is based on Planck polarisation data at
353 GHz.
Source
http://www.esa.int/spaceinimages/Images/2014/12/The_magnetic_field_along_the_Galactic_plane
5 S P E C I F I C H E S U P P L E M E N TA R I
La Qualit come unonda.

Quel lavoro di Qualit che pensavi nessuno avrebbe notato
viene notato eccome, e chi lo vede si sente un pochino meglio:
probabilmente trasferir negli altri questa sua sensazione
e in questo modo la Qualit continuer a diffondersi.
Lo Zen e larte della manutenzione della motocicletta
Robert M. Pirsig[PV90]
I.1 Raccolta caratteristiche alto livello nel primo workshop dei
requisiti di ideazione
E.1 Catalogazione dei requisiti su modello FURPS+
E.2 Raffinamento requisiti architetturali non funzionali
Nellelaborato Specifiche Supplementari, secondo lapproccio sistema-

tico del processo unificato, sono state raccolte progressivamente ad ogni
iterazione le caratteristiche funzionali generali non esprimibili nel Model-
lo dei Casi duso e tutti quei requisiti che non riguardano specifiche fun-
zionalit del sistema ma che costituiscono attributi di qualit che hanno
grande influenza sullarchitettura del sistema.
Per ridurre il rischio di trascurare qualche aspetto importante del si-
stema si applicato il modello di classificazione dei requisiti FURPS+1 .
Sono stati individuati in tal modo ulteriori requisiti funzionali e carat-
teristiche non espresse nei casi duso; sono stati classificati attributi di
qualit come lusabilit, laffidabilit, le prestazioni e la sostenibilit, che
influenzano larchitettura del sistema; sono stati individuati altri vincoli di
progettazione, implementazione e di interfaccia.
1 Robert Grady. Practical Software Metrics for Project Management and Process Improvement.
Prentice-Hall, 1992.
83
84 specifiche supplementari
5.1 requisiti furps+

5.1.1 Funzionalit
notifiche
R1 Il sistema deve fornire supporto per la notifica allutente di at-
tivit intercorse nel sistema in sua assenza o eventi in tempo reale
che coinvolgono risorse con le quali in relazione o di cui diretto
destinatario.
reporting
R2 Il sistema deve creare report e documenti in formato stampabile
contenenti riferimenti ipertestuali navigabili nel formato elettronico.
security
R3 Il sistema deve consentire laccesso solo ad utenti che autenticano
la propria identit, ad esempio tramite username e password.
R4 Il sistema deve permettere laccesso alle risorse di progetto attra-

verso Access Control List (ACL): tali regole consentono o negano
operazioni sui diversi tipi di risorsa.
R5 Il sistema deve associare a ogni ruolo i permessi che determinano

le operazioni possibili sulle date risorse. Ad ogni utente deve essere
possibile attribuire pi ruoli che determinano complessivamente le
operazioni possibili sulle risorse.
R6 Informazioni segrete come le password devono essere conser-

vate o trasmesse in forma crittografata. Non devono poter essere
conosciute nemmeno dallamministratore del sistema.
tagging
R7 Il sistema fornisce supporto per creare riferimenti univoci ai re-
cord, applicando paradigmi personalizzabili che utilizzano i campi
e attributi del record e numeri progressivi.
R8 Il sistema consente di navigare i riferimenti ipertestuali (tag) defi-

niti per utenti e record del sistema. (v. R11)
versioning
R9 Il sistema deve fornire supporto per la gestione di versione dei
record (versioning). Ogni volta che si modifica un record viene
creata automaticamente una nuova versione del record.
workflow
R10 Il sistema deve fornire supporto per la gestione dei processi di
revisione dei documenti (approval workflow). Alla modifica di
5.1 requisiti furps+ 85
un documento viene creata una nuova revision ed possibile avvia-

re un processo di richiesta di approvazione della modifica rivolta a
un pool di membri del progetto. Quando tutti i membri approvano
le modifiche proposte viene creata una nuova edizione (issue) del
documento.
5.1.2 Usabilit
accessibilit
R11 Il sistema deve consentire di inserire facilmente nei campi del-
lapplicazione tag per creare riferimenti a:
utenti, utilizzando il simbolo @ seguito dal nome utente,
record del progetto, usando il simbolo # seguito dal riferimento
secondo il paradigma adottato dal progetto.
R12 Il sistema deve consentire di inserire facilmente nei campi rich

text dellapplicazione immagini e link a file caricati, integrati nel testo
con operazioni semplici come copia e incolla o drag&drop.
R13 Le notifiche non lette devono essere presentate in modo eviden-

ziato nellelenco delle notifiche per attrarre lattenzione dellutente.
Il numero delle notifiche non lette deve essere evidente nellinterfac-
cia utente.
consistenza
R14 Lapplicazione deve dare accesso a tutti i membri del progetto e
ai clienti utilizzando lo stesso indirizzo web. Ogni utente autenticato
visualizza in modo consistente le informazioni in base al proprio
ruolo sia che abbia un collegamento diretto ad un server interno sia
che acceda dallesterno.
estetica
R15 Il sistema deve offrire un interfaccia grafica responsiva e reattiva
in linea con gli attuali livelli di qualit della user experience delle
applicazioni web.
R16 Il contrasto e la dimensione dei font utilizzati nellinterfaccia

grafica dellapplicazione web non devono affaticare la visione degli
utenti.
guida in linea
R17 Il sistema deve fornire aiuto tramite guida in linea accessibi-
le dallinterfaccia utente circa il contenuto dei form e i processi di
gestione documentale con riferimenti ai termini degli standard ECSS.
manuale utente
R18 Il sistema deve fornire la documentazione daiuto per luten-
te: il manuale duso utente e il manuale per lamministrazione del
sistema.
5.1.3 Affidabilit
disponibilit
R19 Le edizioni enterprise a pagamento del software devono offri-
re livelli di servizio timeup conformi agli accordi (service level
agreement (SLA)).
integrit
R20 Il sistema deve poter certificare lintegrit dei record che hanno
seguito un processo di revisione apponendo la firma digitale.
logging
R21 Il sistema deve utilizzare un servizio di logging per consentire
il debugging dellapplicazione nella fase di sviluppo e di rilascio.
capacit di recupero
R22 Il sistema deve consentire la definizione di una politica di bac-
kup personalizzabile e lesecuzione programmata in dati giorni della
settimana. (v. R23)
5.1.4 Prestazioni
tempo di recupero
R23 Il sistema deve essere ripristinato da un precedente backup
minimizzando i tempi di recupero. (v. R22)
tempo di risposta
R24 Lapplicazione web deve avere dei tempi di risposta ragionevo-
li per lutente. Attese di uno o due secondi nel caricamento delle
pagine sono tollerabili.
throughput
R25 Il sistema deve supportare lutilizzo concorrente di decine di uti-
lizzatori contemporanei per ogni installazione su server onpremise e
migliaia di utilizzatori su servizi Cloud in modalit multitenant.
5.1.5 Sostenibilit
verificabilit
R26 Il sistema deve eseguire il processo di auditing in modo siste-
matico, indipendente e documentato per ottenere evidenze delle-

secuzione di ogni operazione degli utenti e del sistema conservan-
done traccia secondo i criteri aziendali in conformit agli standard
industriali adottati (es. ISO 9000, ISO 9001.) (v. audit)
configurabilit
R27 I file caricati nel sistema informativo devono essere memorizzati
su un repository configurabile, ad esempio database, file system loca-
le, nel file system di rete, server FTP, sistema di controllo di versione
distribuito.
R28 Lutente pu impostare il proprio account personale per sce-

gliere se ricevere le notifiche del sistema oltre che nella dashboard
personale anche via email. Ad esempio quando gli viene assegnato
un AI, viene invitato in un meeting, viene richiesta lapprovazione
per una modifica ad un report.
installabilit
R29 Il sistema deve essere progettato per essere installato come un
servizio web accessibile su un server interno aziendale (on premise) o
sfruttando servizi di hosting esterni (Cloud).
localizzazione
R30 Il sistema deve presentare linterfaccia utente e il manuale di
amministrazione del sistema in lingua inglese. I termini chiave del
dominio devono essere riportati in lingua inglese come definiti negli
standard ECSS.
R31 Il manuale utente e la procedura di installazione del sistema

possono supportare le principali lingue europee. I termini chiave del
dominio devono essere riportati in lingua inglese come definiti negli
standard ECSS.
scalabilit
R32 Il sistema deve essere in grado di gestire grandi volumi dati per
mantenere lo storico delle versioni dei record e documenti.
testabilit
R33 Il processo di sviluppo deve essere guidato dai test di verifica
delle unit, di integrazione e di interfaccia.
5.1.6 Ulteriori requisiti
Vincoli di progettazione
Raffinamento dei vincoli determinati nellanalisi che forniscono una pri-
ma soluzione indipendente dallimplementazione.
gestione degli eventi

R34 I processi possono prevedere una scadenza di lelaborazione di
un record. Il sistema deve notificare per tempo gli attori interes-
sati dellavvicinarsi di tali scadenze inviando automaticamente dei
promemoria.
gestione dei file

R35 Il sistema deve creare per ogni progetto una cartella dedicata
sul file server nel percorso del repository (v. R27). Ogni documento
caricato appartenente al progetto contenuto in tale cartella.
R36 Ogni documento allegato a ogni tipo di record deve essere me-
morizzato in una sottocartella della cartella di progetto (v. R35) dedi-
cata al tipo di record (AI, MOM, IRPT, NCR, . . . ).
R37 Ogni documento caricato nel file server deve essere rinomina-
to per includere un prefisso contenente un riferimento basato su
un paradigma definito (ad esempio il tipo di record e un numero
progressivo).
grafica
R38 Le dashboard che presentano le informazioni di progetto e per-
sonali possono presentare pannelli contenenti grafici di analisi stati-
stica e tendenziale delle performance.
information exchange
R39 Il sistema deve supportare limportazione e lesportazione dei
technical data package (TDP) in formato XML e archivio ZIP.
licensing
R40 Il sistema rilasciato sotto licenza open source (permesso dauto-
re), include il codice sorgente, che pu essere utilizzato, studiato, mo-
dificato, distribuito, ceduto, senza discriminazioni, senza restrizioni,
lasciando intatti i diritti morali sullopera.
R41 Il sistema deve essere licenziato a pagamento per servizi di uti-

lizzo enterprise ed essere disponibile in diverse edizioni. Le licenze
consentono di acquisire diritti di utilizzo in base a criteri che limita-
no il numero di utenti, il numero di Core/CPU, il server clustering,
laccesso ai moduli non di base, laccesso a servizi Cloud/ibridi, il
tipo di supporto tecnico/helpdesk.
mail
R42 Il sistema deve fornire servizio di posta elettronica per linvio di
messaggi diretti ad utenti del sistema per la notifica e la richiesta di
intervento necessaria nei processi di gestione delle non conformit e
workflow di approvazione e revisione dei documenti.
persistence
R43 Il sistema deve supportare i servizi di objectrelational mapping
(ORM) per la persistenza dei dati compatibile con i database dei
maggiori vendor.
resource management
R44 Il sistema deve fornire informazioni indicative delle risorse di
storage impegnate nel repository dei documenti e la quantit di
banda utilizzata nei trasferimenti di rete.
scheduling
R45 Il sistema deve offrire servizi di pianificazione e schedulazione
di operazioni:
timeconsuming come il backup
cpuconsuming come la crittografia per la firma digitale
networkconsuming come linvio di mail a numerosi utenti
system management
R46 Il sistema deve offrire supporto per strumenti di gestione, mo-
nitoring e configurazione a runtime.
time services
R47 Il sistema deve memorizzare e riportare le informazioni tem-
porali sul riferimento del tempo coordinato universale UTC (ISO
8601).
gestione delle transazioni

R48 Il sistema deve garantire che lesecuzione concorrente di ogni
transazione nella base di dati sia nel rispetto delle propriet ACID:
atomicit: ogni transazione una unit atomica indivisibile di
lavoro che deve applicare tutti i suoi effetti al commit o lasciare
la base di dati nello stato precedente alla sua esecuzione in caso
di abort
consistenza: ogni transazione non deve violare i vincoli di inte-
grit
isolamento: ogni transazione eseguita indipendentemente dal-
le altre concorrenti
durabilit: ogni transazione andata a commit garantisce la per-
sistenza delle modifiche nella base di dati
Vincoli di implementazione
componenti di terze parti
R49 Il sistema deve far uso di tecnologie e componenti opensource.
linguaggi di implementazione
R50 Il sistema di backend pu essere sviluppato su piattaforma
Java Enterprise Edition e framework Spring.
R51 Il sistema di frontend pu essere sviluppato su piattaforma a

libera scelta. I pi promettenti sono realizzati in linguaggio JS come
Angular JS, Node.JS, React, VueJS, Polymer, Meteor, JQuery oppure
in linguaggio Java: JSP/JSTL, GWT, Vaadin, Spring MVC
piattaforma di supporto
R52 Il sistema di accounting deve poter supportare e integrarsi in
futuro con sistemi di autenticazione basata su protocollo LDAP o
OpenID.
resource limits
R53 Il sistema deve fornire supporto alla gestione di quote di spazio
nel repository e quote di invio email del sistema di notifica.
standard di conformit
R54 Il sistema deve essere conforme ai requisiti normativi conte-
nuti negli standard ECSS, per le discipline e i principi applicabili
e i processi operati a ogni livello della catena clientefornitore del
progetto/programma spaziale.
Vincoli di interfaccia
formati di interfaccia
R55 Il sistema deve offrire servizi di presentazione, accesso e trasfe-
rimento dello stato delle risorse con architettura REST. Ogni risorsa
deve essere identificata e localizzata da un URL.
5.2 fattori architetturali 91
5.2 fattori architetturali

Si esegue lanalisi architetturale dei requisiti per identificare i fattori che
influenzano larchitettura del sistema, individuare i possibili punti di va-
riazione e evoluzione del sistema, stabilire le priorit, anticipare la ricerca
di soluzioni.
Identificati i requisiti che hanno un impatto significativo sullarchitettu-
ra si analizzano le alternative e si prendono decisioni architetturali che
soddisfino scenari di qualit misurabile.
Sicurezza Sistema di Autenticazione

Fattore Supporto a servizi di autenticazione terzi disponibili in
ambiente di produzione
Requisiti R3, R52
Misure e scenari di Quando il sistema installato in un ambiente di produ-
qualit zione in cui sia presente un sistema di autenticazione, ad
es. server LDAP, possibile lintegrazione
Punti di variabilit
Flessibilit corrente richiesto un sistema di autenticazione integrato nel
prodotto
Evoluzione futura richiesto un sistema di autenticazione che si integri
con sistemi terzi
Impatto del fattore Richiesto per il successo del prodotto. Ridotto sforzo
amministrativo.
Impatto alto sul sistema di autenticazione
Priorit per il successo Media Difficolt o rischi Alta
Funzionalit Sistema di Notifica
Fattore Supporto allambiente di lavoro collaborativo mediante
notifica online di eventi
Requisiti R1, R8, R11, R13, R15, R34
Misure e scenari di Quando lutente online deve essere aggiornato in real
qualit time dal sistema di notifica del cambio di stato di oggetti,
azioni di altri utenti su documenti di cui si coautori,
scadenze e riunioni, citazioni tagging.
Punti di variabilit
Flessibilit corrente Il sistema di notifica inizialmente si pu limitare allinvio
di e-mail
Evoluzione futura: Il sistema di notifica deve essere integrato nellUI. En-
tro un anno la maggioranza degli utenti utilizzer brow-
ser compatibili con la tecnologia WebSocket che sempli-
fica limplementazione di un sistema di comunicazione
asincrona integrata nellUI.
Impatto del fattore Richiesto per laccettazione del prodotto: migliore
esperienza utente.
Ha impatto sul sistema di notifica e UI
Priorit per il successo Media Difficolt o rischi Media
Funzionalit Sistema di gestione documentale

Fattore Supporto alla generazione automatica di documentazio-
ne di riepilogo (report)
Requisiti R2
Misure e scenari di Quando vengono conclusi i processi di gestione di va-
qualit ri record del sistema possibile generare documenti di
rapporto che contengano tutte le informazioni raccolte
nel processo documentale
Punti di variabilit
Flessibilit corrente Non richiesto al momento per laccettazione del
prodotto
Evoluzione futura Verr richiesta la generazione automatica dei rappor-
ti perch evita il lavoro manuale e il rischio di
inconsistenze nella documentazione
Impatto del fattore Richiesto per il successo del prodotto.
Impatto alto sul progetto a larga scala.
Priorit per il successo Media Difficolt o rischi Media

Fattore Supporto alla firma digitale dei documenti
Requisiti R20
Misure e scenari di Quando vengono conclusi i processi di revisione
qualit il sistema deve poter apporre la firma digitale ai
documenti
Punti di variabilit
Flessibilit corrente Desiderata per le release successive del prodotto
Evoluzione futura La gestione documentale con firma digitale un requisi-
to che pu diventare obbligatorio per vincoli contrattua-
li tra clienti e fornitori per la tracciabilit, integrit, non
ripudio dei documenti.
Impatto del fattore La funzionalit di firma digitale una caratteristica criti-
ca per il successo del prodotto per lalto valore aggiunto
per lutente.
Un sistema di crittografia a chiave asimmetrica con ge-
stione dei certificati per lapposizione di firme elettro-
niche ai documenti un componente software di no-
tevole complessit con un alto rischio di difficolt di
implementazione, integrazione e riuso.
Priorit per il successo Alta Difficolt o rischi Alta
5.2 fattori architetturali 93

Fattore Supporto al versioning dei documenti
Requisiti R9, R32
Misure e scenari di Quando vengono modificati i documenti e i record il
qualit sistema deve conservare lo storico delle versioni pre-
cedenti con memoria completa dello stato comprese le
relazioni con altri record.
Punti di variabilit
Flessibilit corrente Supporto richiesto
Evoluzione futura Nessuna
Impatto del fattore Richiesto per laccettazione del prodotto.
Impatto alto sul progetto su persistenza e scalabilit del
volume di dati.
Configurabilit Sistema di project management
Fattore Supporto alla gestione e personalizzazione dei workflow
Requisiti R10
Misure e scenari di Societ dellindustria aerospaziale nella catena cliente
qualit fornitore fino ai primi appaltatori richiedono varianti
nella gestione dei processi aziendali: necessario ga-
rantire flessibilit e supporto alla personalizzazione e
modellazione dei workflow.
Punti di variabilit
Flessibilit corrente richiesto il supporto per la gestione del processo di
revisione documentale come descritto nei casi duso.
Evoluzione futura Il supporto a sistemi di BPM necessario per raggiunge-
re la massima flessibilit e scalabilit del sistema. Stru-
menti di modellazione dei processi consentono di pro-
gettare i processi aziendali e non essere vincolati a
workflow forzati dal sistema. La gestione dei proces-
si consente il riuso di modelli di processo, levoluzione
dei workflow e lintegrazione con altre applicazioni di
business.
Impatto del fattore Richiesto per il successo del prodotto.
Impatto alto sul progetto a larga scala.
The Bubble Nebula
Credit NASA/ESA/Hubble Heritage Team

The Bubble Nebula
Release date 21/04/2016 5:00 pm
The Bubble Nebula, also known as NGC 7635, is an emission nebula located 8.000 light-years away. This stunning new image was observed by the
NASA/ESA Hubble Space Telescope to celebrate its 26th year in space.
No matter how many times we look at the Bubble Nebula, we do not tire of its beauty. It was discovered in 1787 by the great astronomer, William
Herschel. Back then it would have appeared as nothing more than a faint black-and-white smudge in the eyepiece of his telescope. Here we see it
in the most magnificent of colours thanks to the NASA/ESA Hubble Space Telescope.
The Bubble Nebula really is a bubble. It is being blown into this shape by the bright star known as SAO20575, which sits just to the left of centre in
this image. This is a giant star of 1020 times the mass of the Sun.
The star is pumping out a fearsome torrent of ultraviolet radiation, causing the surrounding gases to glow like a fluorescent light. But it is not this
ultraviolet radiation that is blowing the bubble. Instead, it is being created by SAO20575s stellar wind.
A stellar wind is a high-speed flow of particles streaming away from the star. As they collide with the gas atoms and molecules in the surrounding
cloud they push them away, creating this luminous bubble.
The Hubble Space Telescope took this image using its Wide Field Camera 3 (WFC3). It is a combination of four images that have been combined to
give this full-colour view. Previous Hubble images of the nebula have captured only part of the nebula. Here at last, its full extent can be seen and
appreciated.
Lying 8000 light-years away, the nebula now reaches some 10 light-years in diameter and continues to expand at more than 100 000 km/h. A
puzzle is why the star that created it is not at the bubbles centre. Perhaps this indicates that the interstellar gases are denser in one direction than
the other, and so the bubble cannot expand so quickly in that direction.
This is Hubbles 26th anniversary photo. It remains a smooth science machine, returning impressive images and great science. Every year the space
telescope spends time capturing a spectacular view of the cosmos, which is then released on or around 24 April to commemorate its launch on
that day in 1990.
Happy birthday Hubble!
About the Object

Name: Bubble Nebula, NGC 7635
Type: Milky Way : Nebula : Appearance : Emission : H II Region
Constellation: Cassiopeia
Category: Nebulae
Credit: NASA, ESA/Hubble and the Hubble Heritage Team
Source
6 MODELLO DI DOMINIO
E.1 Elaborazione dei diagrammi delle classi concettuali
Lelaborato Modello di Dominio, della disciplina di UP di modellazio-

ne del business, mostra una astrazione visuale composta di classi concet-
tuali rappresentanti oggetti o concetti importanti per il dominio di interes-
se. Il modello di dominio raffigura nei diagrammi delle classi della nota-
zione UML le classi concettuali rappresentanti oggetti del dominio, i loro
attributi e le associazioni tra classi. Si vuole modellare oggetti del mondo
reale o concetti utili nel dominio di interesse pertanto non sono rappresen-
tati gli oggetti software dotati di responsabilit; non un modello di dati
che devono essere memorizzati in modo persistente.
La modellazione orientata agli oggetti del dominio riduce il salto rap-
presentazionale con gli oggetti software dotati di informazioni e responsa-
bilit che saranno ispirati e progettati nello strato di dominio nel Modello
di Progetto.
Le classi concettuali modellate sono state individuate nella fase di ela-
borazione dallanalisi dei requisiti riusando modelli esistenti1 , utilizzando
elenchi di categorie note2 , identificando nomi e locuzioni nominali nel
Modello dei Casi duso.
1 Martin Fowler. Analysis Patterns: Reusable Object Models. Addison-Wesley, 1996. isbn:
978-0-201-89542-1.
2 Craig Larman. Applicare UML e i pattern. Analisi e progettazione orientata agli oggetti. A cura
di Luca Cabibbo. 4a ed. Pearson Italia S.p.A., 2016, p. 708. isbn: 9788891901033, cap. 12.6.
97
98 modello di dominio
6.1 modellazione classi concettuali
Project
Role * * 1 customer
* Company
Employee
name
name Account acronym
surname 1 1 address
type
email * 1 ESA registration number
username
photo legal tax number
password
phone EMITScode
mobile logo
Employment website
employee number
*
job description 1
Figura 13: Diagramma UML delle classi concettuali Account Management
* *
Employee * * Project Role
acronym * * type
title
*
type
customer * description *
Company
1 status Permission
1
Repository 1
Figura 14: Diagramma UML delle classi concettuali Project Management

6.1 modellazione classi concettuali 99
Project 1
1 Inspection Report
*
*
Action Item 0..1
* reference
* 1 assigner *
title
organizer Employee description
1 verification
start date
attendee * * 1 assignee deadline
* priority
status
* * MOM approved
*
* Meeting
0..1
reference
title datapackage Document
type 1 *
*
date
agenda 1
place
status 1 minutes 1
1
Figura 15: Diagramma UML delle classi concettuali Meeting e Action Item
Management
Reference Template * 1 Project Employee

1
1 * author
*
Document
* reference
*
title
Repository type
1 * docfile
status
issue
revision
Figura 16: Diagramma UML delle classi concettuali Document Management

Action Item Project Employee
1
* 1 author
*
Inspection Report
reference
0..1 title *
type Nonconformance Report
report 1 *
date
facility
0..1
status
AIT
*
* inspected item
Manifactured Item NC item
1
Figura 17: Diagramma UML delle classi concettuali Inspection Report

Management
Employee Project 1
Company
responsible * 1
0..* 0..* manufacturer 1
child assembly
* *
*
Configuration Item Part
Manifactured Item
* name name
description * description * description
status status status
1
type 1 type 1
1 1
1
1 * attachment 1 Serial
CI Code Document * Part Number
batch
attachment
part no serial
Figura 18: Diagramma UML delle classi concettuali Configuration Manage-

ment
6.1 modellazione classi concettuali 101
Employee Project Action Item

*
author 1 0..* witness 1
*
*
Nonconformance Report
* 0..1
reference
* title
*
type
NRB Meeting 1 impact * 1 Inspection Report
* date
facility
activity
report
status
*
* NC item
Configuration Item
Figura 19: Diagramma UML delle classi concettuali Nonconformance Report

Management
6.2 modellazione macchine a stati

La modellazione delle macchine a stati aiuta la comprensione e la defi-
nizione dei sistemi informatici in cui richiesto il controllo dei processi
e la modellazione della navigazione della UI dellapplicazione web e del
controllo del flusso delle pagine in una sessione clientserver.
Alcuni oggetti del dominio presentano un comportamento complesso
in cui la reazione agli eventi dipende dallo stato delloggetto. In un dato
stato loggetto reagisce ad alcuni eventi. La transizione da uno stato al
successivo si ha quando si verifica un evento, eventualmente sotto certe
condizioni ed eseguendo una particolare azione.
Action Item
Assigned
Created
assign
start
Started Completed Closed

complete accept
withdraw [verification]
restart
restart
Withdrawn
pause reject[explanation]
Paused Rejected
Figura 20: Diagramma UML macchina a stati Action Item

Voyager Golden Record
Credit Public domain
Voyager Golden Record
Release date 1977
The Voyager Golden Record contains 115 images plus a calibration image and a variety of natural sounds, such as those made by surf, wind, and
thunder, and animal sounds, including the songs of birds and whales. The record additionally features musical selections from different cultures and
eras, spoken greetings in fifty-nine languages, and printed messages from President Jimmy Carter and U.N. Secretary-General Kurt Waldheim. The
items were selected for NASA by a committee chaired by Carl Sagan of Cornell University.
After NASA had received criticism over the nudity on the Pioneer plaque (line drawings of a naked man and woman), the agency chose not to allow
Sagan and his colleagues to include a photograph of a nude man and woman on the record. Instead, only a silhouette of the couple was included.
Here is an excerpt of President Carters official statement placed on the Voyager spacecraft for its trip outside the Solar System, June 16, 1977:
We cast this message into the cosmos . . . Of the 200 billion stars in the Milky Way galaxy, some perhaps many may have inhabited
planets and space faring civilizations. If one such civilization intercepts Voyager and can understand these recorded contents, here is
our message: This is a present from a small distant world, a token of our sounds, our science, our images, our music, our thoughts,
and our feelings. We are attempting to survive our time so we may live into yours. We hope some day, having solved the problems
we face, to join a community of galactic civilizations. This record represents our hope and our determination and our goodwill in a
vast and awesome universe.
Source
https://en.wikipedia.org/wiki/Contents_of_the_Voyager_Golden_Record
7 M O D E L LO D E I DAT I
The key, the whole key,

and nothing but the key,
so help me Codd.
mnemonic to remember the third normal form (3NF)
of a normalized database
Raymond F. Boyce & Edgar F. Codd
E.1 Elaborazione modello concettuale dei dati
E.2 Elaborazione modello logico relazionale dei dati
Lelaborato Modello dei Dati, nella disciplina di progettazione UP,

comprende la progettazione del modello concettuale degli schemi Entit
Relazione della base di dati e la mappatura al modello logico relazionale
e normalizzazione del modello logico.1
Il modello dei dati descrive le informazioni che il sistema oggetto di tesi
deve gestire in modo persistente, ovvero le informazioni che devono essere
memorizzate alla fine dellesecuzione di ogni caso duso, mentre non
interessato anche alle informazioni transienti che devono essere gestite
durante lesecuzione dei casi duso.
7.1 modello concettuale

7.1.1 Entit ER1: Company
Entit Company
Chiave primaria uid

Chiavi candidate emits_bidder_code, vat_id
Attributi acronym, name, type, description, website,
logo
Attributi composti address
Business rules
1 P. Atzeni. Basi di dati. Modelli e linguaggi di interrogazione. Collana di istruzione scientifica.
Serie di informatica. McGraw-Hill Education, 2013. isbn: 9788838668005. url: https :
//books.google.it/books?id%09=%207sG2nQEACAAJ; P. Atzeni et al. Basi di dati. 4a ed.
Collana di istruzione scientifica. Serie di informatica. McGraw-Hill Education, 2014, p. 784.
isbn: 9788838665875.
105
106 modello dei dati
BR1: vincolo integrit campo emits_bidder_code univoco

BR2: vincolo integrit campo vat_id univoco
BR3: vincolo dominio campo enumerativo type = { prime, subcontractor,
customer, supplier, partner }
BR4: vincolo dominio campo website formato URL2
BR5: vincolo dominio campo logo formato binario
7.1.2 Entit ER2: Employee
Entit (debole) Employee
Chiave primaria (company, uid)

Attributi name, surname, photo
Attributi multivalore email, phone, custom_fields
Business rules
BR6: vincolo dominio campo photo formato binario
BR7: vincolo integrit campi company riferimento a Company
7.1.3 Entit ER3: Account
Entit Account
Chiave primaria username

Chiavi esterne (company, employee)
Attributi type, password
Business rules
BR8: vincolo integrit campo (company,employee) riferimento a
Employee
BR9: vincolo dominio campo enumerazione
type = { user, manager, admin, partner, customer }
BR10: (asserzione) validazione campo password:
lunghezza minima 8 caratteri alfanumerici
contenere almeno 3 tipi di caratteri tra: maiuscole, mi-
nuscole, numeri o caratteri interpunzione
7.1.4 Entit ER4: Project
Entit Project
Chiave primaria uid

Chiavi candidate uuid
Chiavi esterne customer
Attributi status, acronym, title, description
Business rules
7.1 modello concettuale 107
BR11: vincolo dominio campo UUID v. Dizionario Dati 3.3.4

BR12: vincolo integrit campo repository riferimento a Reposito-
ry Repository
BR13: vincolo integrit campo customer riferimento a Company
BR14: vincolo dominio campo enumerativo
status = { Proposal, Submitted, Negotiation, Rejected,
Open, Paused, Closed, Withdrawn }
7.1.5 Entit ER5: Repository
Entit Repository
Chiave primaria (project, uid)

Chiave candidata uri
Chiave esterna project
Attributi type
Business rules
BR15: vincolo integrit campo project riferimento a Project
type = { file system, network share, ftp, sftp, ...}
BR17: vincolo integrit campo uri univoco
BR18: vincolo dominio campo uri formato URI (RFC 3986)
7.1.6 Entit ER6: Reference Template
Entit Reference Template

Chiave esterna project
Attributi template
Business rules
BR20: vincolo dominio campi template v. Dizionario Dati 3.3.5
BR21: trigger on update template
7.1.7 Relazione ER7: Employment
Relazione Employee - Company
Cardinalit N:1
Partecipazione obbligatoria
Chiave primaria (employee, company)
Chiavi esterne (company, employee), company
Attributi employee_number, description
Business rules

Employee
BR23: vincolo integrit campo company riferimento a Company
7.1.8 Relazione ER8: Role
Relazione Employee - Project
Cardinalit N:N
Partecipazione Obbligatoria
Chiave primaria (company, employee, project)
Chiavi esterne (company, employee), project
Attributi type
Business rules
Employee
type = {project manager, deputy manager, configuration
manager, AIT manager, QA manager, AIT engineer, QA engineer,
system engineer, mechanical engineer, thermal engineer,
testing engineer, electronic engineer, support, customer}
7.1.9 Entit ER9: ActionItem
Entit (debole) Action Item

Chiavi esterne project, (company, assigner), (company,
assignee)
Attributi status, title, description, priority
start_date, deadline, end_date
Attributi derivati reference
Business rules
BR28: vincolo integrit campo (company,assigner) riferimento a
Employee
BR29: vincolo integrit campo (company,assignee) riferimento a
Employee
status = { Initiated, Started, Paused, Completed, Rejected,
Closed, Withdrawn }
priority = { Low, Medium, High }
BR32: vincolo integrit campo derivato reference univoco
BR33: regola validazione campo derivato reference v. Dizionario

Dati 3.3.5
7.1.10 Entit ER10: Meeting
Entit (debole) Meeting

Chiavi esterne project, (company, organizer), (project,
agenda), (project, minutes)
Attributi status, title, type, start_date, end_date
Business rules
BR34: vincolo integrit campo (company,organizer) riferimento a
Employee
BR35: vincolo integrit campo (project,agenda) riferimento a Do-
cument
BR36: vincolo integrit campo (project,minutes) riferimento a Do-
cument
status = { Planned, Open, Review, Closed }
Dati 3.3.5
BR40: regola validazione campi start_date <= end_date
7.1.11 Relazione ER11: Meeting_Attendant
Relazione Meeting - Employee
Cardinalit N:N
Partecipazione non obbligatoria
Chiave primaria (project, meeting, company, attendee)
Chiavi esterne (project, meeting), (company, attendee)
Business rules
BR41: vincolo integrit campo (project,meeting) riferimento a Mee-
ting
BR42: vincolo integrit campo (company,attendee) riferimento a
Employee
7.1.12 Relazione ER12: Meeting_ActionItem
Relazione Meeting - ActionItem
Cardinalit N:N
Chiave primaria (project, meeting, actionitem)
Chiavi esterne (project, meeting), (project, actionitem)
Business rules
BR43: vincolo integrit campo (project,meeting) riferimento a Mee-
ting
BR44: vincolo integrit campo (project,actionitem) riferimento
a ActionItem
7.1.13 Entit ER13: Document
Entit (debole) Document

Chiavi esterne project, (project, repository)
Attributi status, title, type, date, issue, revision
Business rules
BR46: vincolo integrit campo (project, repository) riferimento
a Repository
Dati 3.3.5
status = { Draft, Review, Released }
BR50: vincolo dominio campo enumerativo type nellelenco in tab. 7.
7.1.14 Relazione ER14: Document_Author
Relazione Document - Employee
Cardinalit N:N
Chiave primaria (project, document, company, author)
Chiavi esterne (project, document), (company, author)
Business rules
BR51: vincolo integrit campo (project,document) riferimento a
Document
BR52: vincolo integrit campo (company,author) riferimento a Em-
ployee
7.1.15 Relazione ER15: Document_Revisor
Relazione Document - Employee
Cardinalit N:N
Chiave primaria (project, document, company, revisor)
Chiavi esterne (project, document), (company, revisor)
Attributi remarks
Business rules
BR53: vincolo integrit campo (project,document) riferimento a
Document
BR54: vincolo integrit campo (company,revisor) riferimento a Em-
ployee
7.1.16 Entit ER16: ConfigurationItem
Entit (debole) ConfigurationItem
Chiave primaria (project, ci_code)

Chiavi esterne project, parent_ci_code
Attributi status, name, description, type
Business rules
BR56: vincolo integrit campo (project, parent_ci_code) rif. a
ConfigurationItem
type = { Hardware, Software, MGSE, EGSE}
status = { Active, Withdrawned }
Dati 3.3.5
7.1.17 Relazione ER17: ConfigurationItem_Responsible
Relazione ConfigurationItem - Employee
Cardinalit N:N
Chiave primaria (project, ci_code, company, responsible)
Chiavi esterne (project, ci_code), (company, responsible)
Business rules
BR61: vincolo integrit campo (project, ci_code) riferimento a
ConfigurationItem
BR62: vincolo integrit campo (company,responsible) riferimento

a Employee
7.1.18 Relazione ER18: ConfigurationItem_Attachment
Relazione ConfigurationItem - Document
Cardinalit N:N
Chiave primaria (project, ci_code, attachment)
Chiavi esterne (project, ci_code), (project, attachment)
Business rules
BR63: vincolo integrit campo (project,ci_code) riferimento a Con-
figurationItem
BR64: vincolo integrit campo (project,attachment) riferimento
a Document
7.1.19 Entit ER19: Part
Entit (debole) Part
Chiave primaria (project, ci_code, part_number)

Chiave candidata (project, ci_code, part_number, version)
Chiavi esterne (project, ci_code), (project, parent_ci_code,
parent_part)
Attributi version, status, name, description, type
Business rules
BR65: vincolo integrit campi (project, ci_code) riferimento a
ConfigurationItem
BR66: vincolo integrit campo (project, parent_ci_code, parent_part)
riferimento a Part
BR67: vincolo integrit campo (project, ci_code, part_number,
version) univoco
type = {Part, Assembly, Circuit Board, EEE Part, Software}
status = { Preliminary, Released, Superseded }
Dati 3.3.5
7.1.20 Relazione ER20: Part_Attachment
Relazione Part - Document
Cardinalit N:N
Chiave primaria (project, ci_code, part_number, attachment)
Chiavi esterne (project, ci_code, part_number), attachment
Business rules
BR72: vincolo integrit campo (project, ci_code, part_number)
riferimento a Part
BR73: vincolo integrit campo attachment riferimento a Document
7.1.21 Entit ER21: Material
Entit Material
Chiave primaria (uid)

Attributi type, name, description
7.1.22 Relazione ER22: Part_Material
Relazione Part - Material
Cardinalit N:N
Chiave primaria (project, ci_code, part_number, material)
Chiavi esterne (project, ci_code, part_number), material
Business rules
riferimento a Part
BR75: vincolo integrit campo material riferimento a Material
7.1.23 Entit ER23: Finishing
Entit Finishing

7.1.24 Relazione ER24: Part_Finishing
Relazione Part - Finishing
Cardinalit N:N
Chiave primaria (project, ci_code, part_number, finishing)
Chiavi esterne (project, ci_code, part_number), finishing
Business rules
riferimento a Part
BR77: vincolo integrit campo finishing riferimento a Finishing
7.1.25 Entit ER25: Process
Entit Process

Chiavi esterne project
7.1.26 Relazione ER26: Part_Process
Relazione Part - Process
Cardinalit N:N
Chiave primaria (project, ci_code, part_number, process)
Chiavi esterne (project, ci_code, part_number), process
Business rules
riferimento a Part
BR79: vincolo integrit campo process riferimento a Process
7.1.27 Entit ER27: Property
Entit Property

Attributi type, name
Business rules
type = { acoustical, atomic, chemical, electrical, environmental,
magnetic, manufacturing, mechanical, optical, radiological,
thermal }
7.1.28 Relazione ER28: Part_Property
Relazione Part - Property
Cardinalit N:N
Chiave primaria (project, ci_code, part_number, property)
Chiavi esterne (project, ci_code, part_number), property
Attributi value
Business rules
riferimento a Part
BR82: vincolo integrit campo property riferimento a Property
7.1.29 Entit ER29: ManufacturedPart
Entit (debole) ManufacturedPart
Chiave primaria (project, ci_code, part_number, part_version,

batch_number, serial_number)
Chiavi esterne (project, ci_code, part_number, part_version),
(company, manufacturer)
Attributi status, description
Business rules
BR83: vincolo integrit campi project, ci_code, part_number, part_version
rif. a Part
BR84: vincolo integrit campo composto (batch_number, serial_number)
univoco
BR85: vincolo integrit campo (company, manufacturer) riferimen-
to a Company
status = { Pending, Approved, Rejected }
Dati 3.3.5
7.1.30 Entit ER30: Facility
Entit (debole) Facility

Chiavi esterne project
Attributi address
Business rules

7.1.31 Entit ER31: InspectionReport
Entit (debole) InspectionReport

Chiavi esterne project, (company, author), (project, report),
(project, facility)
Attributi status, title, type, description
Business rules

BR91: vincolo integrit campo (company, author) riferimento a Em-
ployee
BR92: vincolo integrit campo (project, facility) riferimento a
Facility
BR93: vincolo integrit campo (project, report) riferimento a Do-
cument
type = { Incoming, Outcoming, KIP, MIP, Audit, Other }
status = { Open, Closed }
Dati 3.3.5
7.1.32 Relazione ER32: InspectionReport_ActionItem
Relazione InspectionReport - ActionItem
Cardinalit 1:N
Chiave primaria (project, irpt, actionitem)
Chiavi esterne (project, irpt), (project, actionitem)
Business rules
BR98: vincolo integrit campo (project, irpt) riferimento a In-

spectionReport
BR99: vincolo integrit campo (project, actionitem) riferimento
a ActionItem
7.1.33 Entit ER33: NonConformanceReport
Entit (debole) NonConformanceReport

Chiavi esterne project, (company, author), (project, report),
(project, facility)
Attributi status, title, type, impact, date, activity
Business rules

BR101: vincolo integrit campo (company, author) riferimento a Em-
ployee
Facility
BR103: vincolo integrit campo (project, report) riferimento a Do-
cument
type = { Hardware, Software, EEE, Operational }
impact = { Minor, Major }
status = { Initiated, Disposition, Review, Closed, Withdrawn}
Dati 3.3.5
7.1.34 Relazione ER34: NCR_Facility
Relazione NonConformanceReport - Facility
Cardinalit N:1
Chiave primaria (project, ncr, facility)
Chiavi esterne (project, ncr), (project, facility)
Business rules
BR109: vincolo integrit campo (project, ncr) riferimento a Non-

ConformanceReport
Facility
7.1.35 Relazione ER35: NCR_Witness
Relazione NonConformanceReport - Employee
Cardinalit N:N
Chiave primaria (project, ncr, witness)
Chiavi esterne (project, ncr), (company, witness)
Business rules
BR111: vincolo integrit campo (project, ncr) rif. a NonConfor-
manceReport
BR112: vincolo integrit campo (company, witness) riferimento a
Employee
7.1.36 Relazione ER36: NCR_ReviewBoardMeeting
Relazione NonConformanceReport - Meeting
Cardinalit 1:N
Chiave primaria (project, ncr, meeting)
Chiavi esterne (project, ncr), (project, meeting)
Attributi disposition
Business rules
BR113: vincolo integrit campo (project,ncr) riferimento a Non-
ConformanceReport
BR114: vincolo integrit campo (project, meeting) rif. a Meeting
BR115: vincolo integrit campo enumerativo
disposition = { Return to Supplier, Use as is, Rework,
Repair, Scrap }
7.1.37 Relazione ER37: NCR_ActionItem
Relazione NonConformanceReport - ActionItem
Cardinalit 1:N
Chiave primaria (project, ncr, ai)
Chiavi esterne (project, ncr), (project, ai)
Business rules
ConformanceReport
BR117: vincolo integrit campo (project, ai) rif. a ActionItem
7.1.38 Relazione ER38: NCR_ConfigurationItem
Relazione NonConformanceReport - ConfigurationItem
Cardinalit 1:N
Chiave primaria (project, ncr, ci)
Chiavi esterne (project, ncr), (project, ci)
Business rules
ConformanceReport
BR119: vincolo integrit campo (project, ci) riferimento a Confi-
gurationItem
7.1.39 Relazione ER39: NCR_Part
Relazione NonConformanceReport - Part
Cardinalit 1:N
Chiave primaria (project, ncr, part)
Chiavi esterne (project, ncr), (project, ci, part)
Business rules
ConformanceReport
BR121: vincolo integrit campo (project, ci, part) riferimento a
Part
7.1.40 Relazione ER40: NCR_ManufacturedPart
Relazione NonConformanceReport - ManufacturedPart
Cardinalit 1:N
Chiave primaria (project, ncr, ci, part, batch, serial)
Chiavi esterne (project, ncr), (project, ci, part, batch,
serial)
Business rules
ConformanceReport
BR123: vincolo integrit campo (project, ci, part, batch, serial)
riferimento a ManufacturedPart
7.2 normalizzazione modello concettuale

7.2.1 Analisi ridondanze
Lattributo derivato reference nelle entit ActionItem, Meeting, Do-

cument, ConfigurationItem, Part, ManufacturedPart deve essere mo-
dificato da un trigger se cambia il template che definisce il reference para-
digm.
7.2.2 Eliminazione generalizzazioni
La generalizzazione Meeting si risolve trasformando la figlia debole

NCR Review Board in una relazione con chiave esterna verso lentit pa-
dre Meeting, conservando gli attributi e relazioni di NCR Review Board,
ovvero disposition e la chiave esterna verso lentit NonConformance-
Report.
7.2.3 Eliminazione attributi composti
Attributo composto address di Company e in Facility partizionato

in entit Address con attributi atomici country, state_province_region,
zip_postalcode, city, address_line1, address_line2 e riferimenti allen-
tit Address in Company e Facility
7.2.4 Accorpamento/partizionamento di entit/associazioni
Attributo composto multivalore phone di Employee partizionato in

nuova entit PhoneNumber e nuova relazione 1:N tra Employee e
PhoneNumber
Attributo multivalore email di Employee partizionato in nuova en-

tit EmailAddress e nuova relazione 1:N tra Employee e EmailAd-
dress
Attributo multivalore custom fields di Employee partizionato in

nuova relazione 1:N tra Employee e CustomField
Attributi employee_number e description della relazione Employ-

ment accorpati in Employee
7.2.5 Entit ER41: PhoneNumber
Entit PhoneNumber

Attributi type, country_code, area_code, local_number
Business rules
7.2 normalizzazione modello concettuale 121
BR124: vincolo dominio campo country_code formato3 alfanumeri-

co 3 caratteri
BR125: asserzione campo country_code + area_code + local_number
formato alfanumerico max 15 caratteri
type = { home, work, fax, mobile, video, pager }
7.2.6 Entit ER42: EmailAddress
Entit EmailAddress
Chiavi (uid)
Attributi email_address
Business rules
BR127: (asserzione) validazione campo email_address formato4 <lo-
calname>@<FQDN>
7.2.7 Entit ER43: Address
Entit Address
Chiavi (uid)
Attributi address_line1, address_line2, city,
state_province_region, zip_postalcode, country
Business rules
BR128: (asserzione) validazione campo enumerativo country = { na-
zioni }
7.2.8 Entit ER44: CustomField
Entit CustomField
Chiavi (uid)
Attributi type, name, value
Business rules
type = {string, integer, date, time, timestamp, double
...}
3 E.164, ITU-T recommendation https://www.itu.int/rec/T-REC-E.164/en

7.2.9 Relazione ER45: Employee_PhoneNumber
Relazione Employee - PhoneNumber
Cardinalit 1:N
Chiave primaria (company, employee, phone)
Chiavi esterne (company, employee), phone
Businees rules
BR130: vincolo integrit campo (company,employee) rif. a Employee
BR131: vincolo integrit campo phone riferimento a PhoneNumber
7.2.10 Relazione ER46: Employee_EmailAddress
Relazione Employee - EmailAddress
Cardinalit 1:N
Chiave primaria (company, employee, email)
Chiavi esterne (company, employee), email
Businees rules
BR133: vincolo integrit campo email riferimento a EmailAddress
7.2.11 Relazione ER47: Employee_CustomField
Relazione Employee - CustomField
Cardinalit 1:N
Chiave primaria (company, employee, customfield)
Chiavi esterne (company, employee), customfield
Businees rules
BR135: vincolo integrit campo customfield riferimento a Custom-
Field
7.2 normalizzazione modello concettuale 123
Tabella 7: Elenco tipi di documento
AR acceptance review MRD mission requirements docu-

CDR critical design review ment
CIDL configuration item data list NCR nonconformance report
CIL critical items list PCB product configuration base-

line
CP change proposal
PDR preliminary design review
CR change request
PRR preliminary requirements
DDF design definition file
review
DDR detailed design review
PTR post test review
DJF design justification file
QR quality review
DML declared materials list
QSL qualification status list
DMPL declared mechanical parts
RFA request for approval
list
RFD request for deviation
DPL declared processes list
RFP request for proposal
DRD document requirements
definition RFW request for waiver
DRL document requirements list RID review item discrepancy
EIDP end item data package SRD system requirements docu-

ment
ELR endoflife review
SRR system requirements
IDM information documenta-
review
tion management
TDP technical data package
IRD interface requirements
document TRR test readiness review
IRPT inspection report VCD verification control

document
ITT invitation to tender
WP work package
MOM minutes of meeting
7.3 mappatura da modello concettuale a mo-

dello logico relazionale
Relazioni ottenute dal mapping relazionale5 :
emits_bidder_code, :::::::
LR1. Company(uid, ::::::::::::::::::: vat_id, acronym, name,
type, description, website, logo, address)
LR2. Employee(company, uid, name, surname, photo, employee_number,

description)
LR3. Account(username, company, employee, type, password)
LR4. Address(uid,address_line1, address_line2, city, state_province_region,

zip_postalcode, country)
LR5. EmailAddress(uid, email_address)
LR6. Employee_EmailAddress(company, employee, mail)
LR7. PhoneNumber(uid, type, country_code, area_code, local_number)
LR8. Employee_PhoneNumber(company, employee, phone)
LR9. CustomField(uid, type, name, value)
LR10. Employee_CustomField(company, employee, customfield)
LR11. Project(uid, uuid,

::::
customer_company, status, acronym, title,
description)
LR12. Repository(project, uid, ::::

uri, type)
LR13. Reference Template(project, uid, template)
LR14. Role(project, company, employee, type)
LR15. ActionItem(project, uid, company, assigner, assignee, .reference,

.......
status, title, description, priority, start_date, end_date,
deadline)
LR16. Meeting(project, uid, organizer, agenda, reference,

. . . . . . . status,
title, description, priority, start_date, end_date)
LR17. Meeting_Attendant(project,meeting,company,attendee)
LR18. Meeting_ActionItem(project,meeting,actionitem)
LR19. Document(project, uid, repository, reference,

. . . . . . . status,
title, type, date, issue, revision)
LR20. Document_Author(document,author)
5 Legenda: chiave primaria, :::::
chiave:::::::::
candidata, chiave esterna, .campo
. . . . . . . .derivato
.........
7.3 mappatura da modello concettuale a modello logico relazionale 125
LR21. Document_Revisor(document,revisor,remarks)
LR22. ConfigurationItem(project, ci_code, parent_ci, reference,

.......
status, name, type, description)
LR23. ConfigurationItem_Responsible(configurationitem,responsible)
LR24. ConfigurationItem_Attachment(configurationitem,attachment)
LR25. Part(project, ci_code, part_number, version, parent_part,

reference,
. . . . . . . status, name, description, type)
LR26. Part_Attachment(project,ci_code,part_number,attachment)
LR27. Material(uid, type, name, description)
LR28. Part_Material(project,ci_code,part_number,material)
LR29. Finishing(uid, type, name, description)
LR30. Part_Finishing(project,ci_code,part_number,finishing)
LR31. Process(uid, type, name, description)
LR32. Part_Process(project,ci_code,part_number,process)
LR33. Property(uid, type, name)
LR34. Part_Property(project,ci_code,part_number,property,value)
LR35. ManufacturedPart(project, ci_code, part_number, part_version,

batch_number, serial_number, manufacturer, reference,
. . . . . . . status,
description)
LR36. Facility(project,uid,address)
LR37. InspectionReport(project, uid, company,author, report,

facility, reference,
....... status, title, type, description)
LR38. InspectionReport_ActionItem(project,irpt,actionitem)
LR39. NonConformanceReport(project, uid, author, report, facility,

reference,
. . . . . . . status, title, type, impact, date, activity)
LR40. NCR_Facility(project,ncr,facility)
LR41. NCR_Witness(project,ncr,witness)
LR42. NCR_ReviewBoardMeeting(project,ncr,meeting,disposition)
LR43. NCR_ActionItem(project,ncr,actionitem)
LR44. NCR_ConfigurationItem(project,ncr,configurationitem)
LR45. NCR_Part(project,ncr,ci,part)
LR46. NCR_ManufacturedPart(project,ncr,ci,part,manufactured)
Hubbles sharpest view of the Orion Nebula
Credit NASA, ESA, M. Robberto (Space Telescope Science Institute/ESA) and the Hubble Space Telescope Orion Treasury Project Team
Hubbles sharpest view of the Orion Nebula
Release date 11 January 2006, 16:00
This dramatic image offers a peek inside a cavern of roiling dust and gas where thousands of stars are forming. The image, taken by the Advanced
Camera for Surveys (ACS) aboard NASA/ESA Hubble Space Telescope, represents the sharpest view ever taken of this region, called the Orion
Nebula. More than 3,000 stars of various sizes appear in this image. Some of them have never been seen in visible light. These stars reside in a
dramatic dust-and-gas landscape of plateaus, mountains, and valleys that are reminiscent of the Grand Canyon.
The Orion Nebula is a picture book of star formation, from the massive, young stars that are shaping the nebula to the pillars of dense gas that may
be the homes of budding stars. The bright central region is the home of the four heftiest stars in the nebula. The stars are called the Trapezium
because they are arranged in a trapezoid pattern. Ultraviolet light unleashed by these stars is carving a cavity in the nebula and disrupting the
growth of hundreds of smaller stars. Located near the Trapezium stars are stars still young enough to have disks of material encircling them. These
disks are called protoplanetary disks or proplyds and are too small to see clearly in this image. The disks are the building blocks of solar systems.
The bright glow at upper left is from M43, a small region being shaped by a massive, young stars ultraviolet light. Astronomers call the region a
miniature Orion Nebula because only one star is sculpting the landscape. The Orion Nebula has four such stars. Next to M43 are dense, dark pillars
of dust and gas that point toward the Trapezium. These pillars are resisting erosion from the Trapeziums intense ultraviolet light. The glowing
region on the right reveals arcs and bubbles formed when stellar winds - streams of charged particles ejected from the Trapezium stars - collide
with material.
The faint red stars near the bottom are the myriad brown dwarfs that Hubble spied for the first time in the nebula in visible light. Sometimes called
failed stars, brown dwarfs are cool objects that are too small to be ordinary stars because they cannot sustain nuclear fusion in their cores the
way our Sun does. The dark red column, below, left, shows an illuminated edge of the cavity wall.
The Orion Nebula is 1,500 light-years away, the nearest star-forming region to Earth. Astronomers used 520 Hubble images, taken in five colours,
to make this picture. They also added ground-based photos to fill out the nebula. The ACS mosaic covers approximately the apparent angular size
of the full moon.
The Orion observations were taken between 2004 and 2005.
About the Object

Name: Messier 42, Messier 43, Orion Nebula
Type: Milky Way : Nebula : Type : Star Formation
Constellation: Orion
Category: Nebulae
Credit: NASA, ESA, M. Robberto ( Space Telescope Science Institute/ESA) and the Hubble Space Telescope Orion Treasury Project Team
Source
8 ARCHITETTURA SOFTWARE
No keyboard detected
Press F1 to resume
Messaggio di un vecchio BIOS per PC
E.1 Analisi architetturale
8.1 rappresentazione architetturale

Lelaborato Architettura software, della disciplina di progettazione
di UP, documenta le idee principali alla base dellarchitettura software. A
seguito dellanalisi dei requisiti sono stati identificati i fattori che hanno
uninfluenza significativa sullarchitettura del sistema, individuati i pos-
sibili punti di variazione ed evoluzione, stabilite le priorit, ricercate le
soluzioni alternative pi importanti per larchitettura per mitigare i rischi
maggiori sin dalle iterazioni iniziali.
8.2 decisioni architetturali

8.2.1 Promemoria tecnico per problema: configurabilit sistema di
Project Management
Riepilogo Soluzione: Valutazione BPM Engine per la modellazione

ed esecuzione dei workflow
Fattori: Supporto alla personalizzazione dei workflow di gestione docu-
mentale
Problema: Sono disponibili framework e BPM engine che consentono di
modellare ed eseguire processi aziendali. Esperti analisti di processi azien-
dali possono modellare in notazione visuale BPMN 2 (standard OMG) i
workflow della gestione documentale per adattarli alle proprie esigenze
per la massima flessibilit.
La decisione tra progettare un sistema che implementa un workflow
hard-coded e ladozione di un motore di gestione ed esecuzione di proces-
si aziendali programmabile richiede di valutare i seguenti aspetti:
129
130 architettura software
complessit delle regole: le regole che definiscono il proprio processo

sono semplici, complicate, vincolate o configurabili?
volatilit del processo: quanto frequentemente cambia il processo? chi
pu cambiarlo?
integrazione richiesta: il processo realizzato utilizzando servizi ete-
rogenei? o possibile implementarlo nello stesso software?
sincrono/asincrono: i processi di lunga esecuzione richiedono la gestio-
ne di azioni asincrone?
attivit umane il processo coinvolge interazioni umane, con task asse-
gnati o inoltrati a persone in base ai loro ruoli/responsabilit?
monitoring del processo: che livello di controllo necessario sulle istan-
ze eseguite? necessario laudit delle azioni?
gestione errori: come reagire agli errori in un processo monitorato?
riprovando lesecuzione?
Soluzione: Implementare il processo di gestione documentale model-
lando il flusso della navigazione delle pagine come una macchina a stati e
applicando il pattern ModelViewController (MVC).
Il framework per applicazioni web Spring MVC progettato per gestire
lo stato, il workflow e la validazione garantendo la massima flessibilit e
il minimo accoppiamento.
Motivazione: Al momento si giudica il processo di gestione documen-
tale elaborato nei casi duso sufficientemente stabile e relativamente com-
plesso da non richiedere un livello di flessibilit tale da dover offrire nella
prima milestone il supporto ad un sistema di gestione dei workflow basato
su BPM Engine.
Alternative considerate: I seguenti framework opensource offrono piat-
taforme di sviluppo di Businees Process Management (BPM) per la mo-
dellazione ed esecuzione di processi di business in notazione BPMN 2.0:
integrabili nella piattaforma Spring.
Tabella 8: Piattaforme Businees Process Management (BPM)

Platform Model Int. REST Container License
Activiti BPMN 2.0 Spring, X JNDI, Apache 2.0
https://www.activiti.org/ LDAP, JMX Docker
Flowable BPMN 2.0, Spring, CDI, X JNDI, Apache 2.0
http://www.flowable.org/ DMN 1.1, LDAP, JMX Docker
Form
jBPM BPMN 2.0 Spring, CDI, X JNDI, Apache 2.0
http://www.jbpm.org/ Ejb, OSGi Docker
Camunda BPMN 2.0 Spring, CDI, X JNDI, Apache 2.0
https://camunda.org/ CMMN 1.1 LDAP, JMX Docker
DMN 1.1
Mystic Mountain
Credit NASA, ESA, M. Livio and the Hubble 20th Anniversary Team (STScI)
Mystic Mountain
Release date 23 April 2010, 10:00
This craggy fantasy mountaintop enshrouded by wispy clouds looks like a bizarre landscape from Tolkiens The Lord of the Rings. The NASA/ESA
Hubble Space Telescope image, which is even more dramatic than fiction, captures the chaotic activity atop a pillar of gas and dust, three light-years
tall, which is being eaten away by the brilliant light from nearby bright stars. The pillar is also being assaulted from within, as infant stars buried
inside it fire off jets of gas that can be seen streaming from towering peaks.
This turbulent cosmic pinnacle lies within a tempestuous stellar nursery called the Carina Nebula, located 7500 light-years away in the southern
constellation of Carina. The image celebrates the 20th anniversary of Hubbles launch and deployment into an orbit around the Earth.
Scorching radiation and fast winds (streams of charged particles) from super-hot newborn stars in the nebula are shaping and compressing the pillar,
causing new stars to form within it. Streamers of hot ionised gas can be seen flowing off the ridges of the structure, and wispy veils of gas and dust,
illuminated by starlight, float around its towering peaks. The denser parts of the pillar are resisting being eroded by radiation.
Nestled inside this dense mountain are fledgling stars. Long streamers of gas can be seen shooting in opposite directions from the pedestal at
the top of the image. Another pair of jets is visible at another peak near the centre of the image. These jets, (known as HH 901 and HH 902,
respectively, are signposts for new star birth and are launched by swirling gas and dust discs around the young stars, which allow material to slowly
accrete onto the stellar surfaces.
Hubbles Wide Field Camera 3 observed the pillar on 1-2 February 2010. The colours in this composite image correspond to the glow of oxygen
(blue), hydrogen and nitrogen (green), and sulphur (red).
Credit: NASA, ESA, M. Livio and the Hubble 20th Anniversary Team (STScI)
About the Object

Name: Carina Nebula, HH 901, HH 902
Type: Milky Way : Nebula : Type : Jet Formation
Constellation: Carina
Category: Nebulae
Credit: NASA, ESA, M. Robberto ( Space Telescope Science Institute/ESA) and the Hubble Space Telescope Orion Treasury Project Team
Source
9 M O D E L LO D I I M P L E M E N TA Z I O N E
Sono convinto che linformatica abbia molto in comune con la fisica. Entrambe si
occupano di come funziona il mondo a un livello abbastanza fondamentale.
La differenza, naturalmente, che mentre in fisica devi capire
come fatto il mondo, in informatica sei tu a crearlo.
Rivoluzionario per caso
Linus Torvalds
E.2 Elaborazione modello logico relazionale dei dati
Lelaborato Modello di Implementazione, nella disciplina di imple-

mentazione UP, comprende tutto il codice sorgente necessario a generare
il software, comprensivo dei test, la definizione dei dati nel linguaggio
SQL, le pagine web HTML/JSP/XML e i file di supporto, come le guide e
manuali.
9.1 schema relazionale sql
Codice 1: Definizione schema SQL

1 CREATE TABLE Address(
2 uid INTEGER PRIMARY KEY,
3 address_line1 VARCHAR(256),
4 address_line2 VARCHAR(256),
5 city VARCHAR(64),
6 _ _
state province region VARCHAR(64),
7 zip_postalcode VARCHAR(8),
8 country VARCHAR(64)
9 );
10
11 CREATE TABLE Company(
13 emits_bidder_code VARCHAR(16) UNIQUE,
14 vat_id VARCHAR(16) UNIQUE,
15 acronym VARCHAR(16),
16 name VARCHAR(256),
17 type VARCHAR(16),
18 description VARCHAR(256),
19 website VARCHAR(256),
133
134 modello di implementazione
20 logo BLOB,
21 address INTEGER,
22 FOREIGN KEY(address)
23 REFERENCES Address(uid),
24 CONSTRAINT CHK_company_type
25 CHECK (VALUE IN("prime", "subcontractor", "customer", -
, "supplier", "partner"))
26 );
27
28 CREATE TABLE Employee(
29 company INTEGER,
30 uid INTEGER,
32 surname VARCHAR(64) NOT NULL,
33 middlename VARCHAR(64),
34 photo BLOB,
35 employee_number VARCHAR(16),
37 PRIMARY KEY (company, uid),
38 FOREIGN KEY (company) REFERENCES Company(uid)
39 );
40
41 CREATE TABLE Account(
42 username VARCHAR(64) PRIMARY KEY,
43 company INTEGER,
44 employee INTEGER,
45 type VARCHAR(8),
46 password VARCHAR(32) NOT NULL,
47 FOREIGN KEY (company)
48 REFERENCES Company(uid),
49 FOREIGN KEY (company, employee)
50 REFERENCES Employee(company,uid),
51 CONSTRAINT CHK_account_type
52 CHECK (VALUE IN("user", "manager", "admin", "partner", -
, "customer"))
53 );
54
55 CREATE TABLE EmailAddress(
57 email_address VARCHAR(256) NOT NULL
58 );
59
60 CREATE TABLE Employee_EmailAddress(
61 company INTEGER,
63 email INTEGER,
64 PRIMARY KEY (company, employee, email)
67 FOREIGN KEY (email)
68 REFERENCES EmailAddress(uid)
69 );
70
9.1 schema relazionale sql 135
71 CREATE TABLE PhoneNumber(

72 company INTEGER,
74 uid INTEGER,
75 type VARCHAR,
76 country_code VARCHAR(3),
77 area_code VARCHAR(15) ,
78 local_number VARCHAR(15) NOT NULL,
79 PRIMARY KEY (company, employee, uid),
82 CONSTRAINT CHK_phone_type
83 CHECK (VALUE IN("home", "work", "fax", "mobile", -
, "video", "pager"),
84 CONSTRAINT CHK_phone
85 CHECK (CHAR_LENGTH(country_code) + -
, CHAR_LENGTH(area_code) + -
, CHAR_LENGTH(local_number) < 16)
86 );
87
88 CREATE TABLE CustomField(
91 name VARCHAR(32) NOT NULL,
92 value VARCHAR(256) NOT NULL,
93 CONSTRAINT CHK_customfield_type
94 CHECK (VALUE IN("string", "integer", "date", "time", -
, "timestamp")
95 );
96
97 CREATE TABLE Employee_CustomField(
98 company INTEGER,
100 customfield INTEGER,
101 PRIMARY KEY (company, employee, customfield),
103 REFERENCES Employee(company,uid)
104 );
105
106 CREATE TABLE Project(
108 uuid VARCHAR(32) UNIQUE,
109 customer INTEGER,
110 status VARCHAR(32),
111 acronym VARCHAR(16),
112 title VARCHAR(256),
114 FOREIGN KEY(customer)
116 CONSTRAIT project_status
117 CHECK (VALUE IN("Proposal", "Submitted", "Negotiation", -
, "Rejected", "Open", "Paused", "Closed", -
, "Withdrawn"))
118 );
119
120 CREATE TABLE Repository(
121 project INTEGER,
122 uid INTEGER,
124 uri VARCHAR(2048),
125 PRIMARY KEY(project, uid),
126 FOREIGN KEY(project)
127 REFERENCES Project(uid),
128 CONSTRAIT repository_type
129 CHECK (VALUE IN("file system", "network share", "ftp", -
, "sftp")
130 );
131
132 CREATE TABLE ReferenceTemplate(
134 uid INTEGER,
135 template VARCHAR(256) NOT NULL,
138 REFERENCES Project(uid)
139 );
140
141 CREATE TABLE Role(
143 company INTEGER,
146 PRIMARY KEY(project, company, employee),
149 FOREIGN KEY(company, employee)
150 REFERENCES Employee(company, uid),
151 CONSTRAINT CHK_role_type
152 CHECK (VALUE IN("Project Manager", "Deputy Manager", -
, "Configuration Manager", "AIT Manager", "QA -
, Manager", "AIT Engineer", "QA Engineer", "System -
, Engineer", "Mechanical Engineer", "Thermal -
, Engineer", "Testing Engineer", "Electronic -
, Engineer", "Support", "Customer")),
153 );
154
155 CREATE TABLE ActionItem(
157 uid INTEGER,
158 assigner_company INTEGER,
159 assigner INTEGER,
160 _
assignee company INTEGER,
161 assignee INTEGER,
163 priority VARCHAR(8),

166 start_date DATE,
167 end_date DATE,
168 deadline DATE,
169 reference VARCHAR(64) UNIQUE,
173 FOREIGN KEY(assigner_company, assigner)
175 FOREIGN KEY(assignee_company, assignee)
177 CONSTRAINT CHK_ActionItem_status
178 CHECK (VALUE IN ("Initiated", "Started", "Paused", -
, "Completed", "Rejected", "Closed", "Withdrawn")),
179 CONSTRAINT CHK_ActionItem_priority
180 CHECK (VALUE IN ("Low", "Medium", "High"))
181 );
182
183 CREATE TABLE Meeting(
185 uid INTEGER,
187 organizer INTEGER,
188 agenda INTEGER,
189 minutes INTEGER,
193 start_date DATE,
194 start_time TIME,
195 end_date DATE,
196 end_time TIME,
201 FOREIGN KEY(company, organizer)
203 FOREIGN KEY(project, agenda)
204 REFERENCES Document(project, uid),
205 FOREIGN KEY(project, minutes)
207 CONSTRAINT CHK_meeting_status
208 CHECK (VALUE IN ("Planned", "Open", "Review", "Closed")),
209 CONSTRAINT CHK_meeting_dates
210 CHECK ( DATEDIFF(day, start\_date, end\_date) >= 0 )
211 );
212
213 CREATE TABLE Meeting_Attendant(
215 meeting INTEGER,
217 attendee INTEGER,

218 PRIMARY KEY(project, meeting, company, attendee),
219 FOREIGN KEY(project, meeting)
220 REFERENCES Meeting(project, uid),
221 FOREIGN KEY(company, attendee)
222 REFERENCES Employee(company, uid)
223 );
224
225 CREATE TABLE Meeting_ActionItem(
226 project INTEGER
228 actionitem INTEGER,
229 PRIMARY KEY(project, meeting, actionitem),
231 REFERENCES Meeting(project, uid),
232 FOREIGN KEY(project, actionitem)
233 REFERENCES ActionItem(project, uid)
234 );
235
236 CREATE TABLE Document(
238 uid INTEGER,
239 repository INTEGER,
242 type CHAR(4),
243 date DATETIME,
244 issue INTEGER,
245 revision INTEGER,
250 FOREIGN KEY(project, repository)
251 REFERENCES Repository(project, uid),
252 CONSTRAINT CHK_document_status
253 CHECK (VALUE IN ("Draft", "Review", "Released")),
254 CONSTRAINT CHK_document_type
255 CHECK (VALUE IN ("AR", "CDR", "CIDL", "CIL", "CP", -
, "CR", "DDF", "DDR", "DJF", "DML", "DMPL", "DPL", -
, "DRD", "DRL", "EIDP", "ELR", "IRD", "IRPT", -
, "MOM", "MRD", "NCR", "PDR", "PRR", "PTR", "QR", -
, "QSL", "RFA", "RFD", "RFP", "RFW", "RID", "SRD", -
, "SRR", "TDP", "TRR", "VCD", "WP"))
256 );
257
258 CREATE TABLE Document_Author(
260 document INTEGER,
262 author INTEGER,
263 PRIMARY KEY(project, document, company, author),
264 FOREIGN KEY(project, document)

266 FOREIGN KEY(company, author)
268 );
269
270 CREATE TABLE Document_Revisor(
272 document INTEGER,
274 revisor INTEGER,
275 remarks VARCHAR(2048),
276 PRIMARY KEY(project, document, company, revisor),
277 FOREIGN KEY(project, document)
279 FOREIGN KEY(company, revisor)
281 );
282
283 CREATE TABLE ConfigurationItem(
285 ci_code VARCHAR(32),
286 parent_ci VARCHAR(32),
292 PRIMARY KEY(project, ci_code),
295 FOREIGN KEY(project, parent_ci)
296 REFERENCES ConfigurationItem(project, ci_code),
297 CONSTRAINT CHK_configurationitem_status
298 CHECK (VALUE IN ("Active", "Withdrawned")),
299 CONSTRAINT CHK_configurationitem_type
300 CHECK (VALUE IN ("Hardware", "Software", "MGSE", "EGSE"))
301 );
302
303 CREATE TABLE ConfigurationItem_Responsible(
307 responsible INTEGER,
308 PRIMARY KEY(project, ci_code, company, responsible),
311 FOREIGN KEY(company, responsible)
313 );
314
315 CREATE TABLE ConfigurationItem_Attachment(
318 attachment INTEGER,

319 PRIMARY KEY(project, ci_code, company, responsible),
322 FOREIGN KEY(project, attachment)
323 REFERENCES Document(project, uid)
324 );
325
326 CREATE TABLE Part(
329 part_number VARCHAR(32),
330 version VARCHAR(8),
331 parent_ci VARCHAR(32),
332 parent_part VARCHAR(32),
338 PRIMARY KEY(project, ci_code, part_number),
339 UNIQUE(project, ci_code, part_number, version),
344 FOREIGN KEY(project, parent_ci,parent_part)
345 REFERENCES Part(project, ci_code, part_number),
346 CONSTRAINT CHK_part_status
347 CHECK (VALUE IN ("Preliminary", "Released", -
, "Superseded")),
348 CONSTRAINT CHK_part_type
349 CHECK (VALUE IN ("Part", "Assembly", "Circuit Board", -
, "EEE Part", "Software"))
350 );
351
352 CREATE TABLE Part_Attachment(
356 attachment INTEGER,
357 PRIMARY KEY(project, ci_code, part_number, attachment),
358 FOREIGN KEY(project, parent_ci, part_number)
360 FOREIGN KEY(project, attachment)
361 REFERENCES Document(project, uid)
362 );
363
364 CREATE TABLE Material(
369 );
370
371 CREATE TABLE Part_Material(
373 _
ci code VARCHAR(32),
375 material INTEGER,
376 PRIMARY KEY(project, ci_code, part_number, material),
379 FOREIGN KEY(material)
380 REFERENCES Material(uid)
381 );
382
383 CREATE TABLE Finishing(
387 description VARCHAR(256)
388 );
389
390 CREATE TABLE Part_Finishing(
394 finishing INTEGER,
395 PRIMARY KEY(project, ci_code, part_number, finishing),
398 FOREIGN KEY(finishing)
399 REFERENCES Finishing(uid)
400 );
401
402 CREATE TABLE Process(
406 description VARCHAR(256)
407 );
408
409 CREATE TABLE Part_Process(
413 process INTEGER,
414 PRIMARY KEY(project, ci_code, part_number, process),
417 FOREIGN KEY(process)
418 REFERENCES Process(uid)
419 );
420
421 CREATE TABLE Property(

425 CONSTRAINT CHK_property_type
426 CHECK (VALUE IN("acoustical", "atomic", "chemical", -
, "electrical", "environmental", "magnetic", -
, "manufacturing", "mechanical", "optical", -
, "radiological", "thermal"))
427 );
428
429 CREATE TABLE Part_Property(
431 _
ci code VARCHAR(32),
433 property INTEGER
434 value VARCHAR(128),
435 PRIMARY KEY(project, ci_code, part_number, property),
438 FOREIGN KEY(property)
439 REFERENCES Property(uid),
440 );
441
442 CREATE TABLE ManufacturedPart(
446 part_version VARCHAR(8),
447 batch_number VARCHAR(32),
448 serial_number VARCHAR(32),
449 manufacturer INTEGER,
453 PRIMARY KEY(project, ci_code, part_number, part_version, -
, batch_number, serial_number),
454 FOREIGN KEY(manufacturer)
456 FOREIGN KEY(project, parent_ci, part_number, part_version)
457 REFERENCES Part(project, ci_code, part_number, -
, part_version),
458 CONSTRAINT CHK_manufacturedpart_status
459 CHECK (VALUE IN ("Pending", "Approved", "Rejected"))
460 );
461
462 CREATE TABLE Facility(
464 uid INTEGER,
465 address INTEGER,
469 FOREIGN KEY(address)
470 REFERENCES Address(uid)

471 );
472
473 CREATE TABLE InspectionReport(
475 uid INTEGER,
477 author INTEGER,
478 report INTEGER,
479 facility INTEGER,
490 FOREIGN KEY(project, report)
492 FOREIGN KEY(project, facility)
493 REFERENCES Facility(project, uid),
494 CONSTRAINT CHK_irpt_status
495 CHECK (VALUE IN ("Open", "Closed")),
496 CONSTRAINT CHK_irpt_type
497 CHECK (VALUE IN ("Incoming", "Outcoming", "KIP", "MIP", -
, "Audit", "Other"))
498 );
499
500 CREATE TABLE InspectionReport_ActionItem(
502 irpt INTEGER,
504 PRIMARY KEY(project, irpt, actionitem),
505 FOREIGN KEY(project, irpt)
506 REFERENCES InspectionReport(project, uid),
509 );
510
511 CREATE TABLE NonConformanceReport(
513 uid INTEGER,
515 author INTEGER,
516 report INTEGER,
522 impact VARCHAR(8),

523 activity VARCHAR(256),
529 FOREIGN KEY(project, report)
532 REFERENCES Facility(project, uid),
533 CONSTRAINT CHK_ncr_status
534 CHECK (VALUE IN ("Initiated", "Disposition", "Review", -
, "Closed", "Withdrawn")),
535 CONSTRAINT CHK_ncr_type
536 CHECK (VALUE IN ("Hardware", "Software", "EEE", -
, "Operational")),
537 CONSTRAINT CHK_ncr_impact
538 CHECK (VALUE IN ("Minor", "Major"))
539 );
540
541 CREATE TABLE NonConformanceReport_Facility(
543 ncr INTEGER,
545 PRIMARY KEY(project, ncr, facility),
546 FOREIGN KEY(project, ncr)
547 REFERENCES NonConformanceReport(project, uid),
549 REFERENCES Facility(project, uid)
550 );
551
552 CREATE TABLE NonConformanceReport_Witness(
554 ncr INTEGER,
556 witness INTEGER,
557 PRIMARY KEY(project, ncr, company, witness),
560 FOREIGN KEY(company, witness)
561 REFERENCES Employee(project, uid)
562 );
563
564 CREATE TABLE NonConformanceReport_ReviewBoardMeeting(
566 ncr INTEGER,
568 disposition VARCHAR(16),
569 PRIMARY KEY(project, ncr, meeting),
573 REFERENCES Meeting(project, uid)

574 CONSTRAINT CHK_ncrnrb_disposition
575 CHECK (VALUE IN("Return to Supplier", "Use as is", -
, "Rework", "Repair", "Scrap"))
576 );
577
578 CREATE TABLE NonConformanceReport_ActionItem(
580 ncr INTEGER,
582 PRIMARY KEY(project, ncr, actionitem),
587 );
588
589 CREATE TABLE NonConformanceReport_ConfigurationItem(
591 ncr INTEGER,
592 co_code VARCHAR(32),
593 PRIMARY KEY(project, ncr, co_code),
596 FOREIGN KEY(project, co_code)
597 REFERENCES ConfigurationItem(project, ci_code)
598 );
599
600 CREATE TABLE NonConformanceReport_Part(
602 ncr INTEGER,
605 PRIMARY KEY(project, ncr, co_code, part_number),
608 FOREIGN KEY(project, co_code, part_number)
609 REFERENCES Part(project, ci_code, part_number)
610 );
611
612 CREATE TABLE NonConformanceReport_ManufacturedPart(
614 ncr INTEGER,
617 batch_number VARCHAR(32),
618 serial_number VARCHAR(32),
619 serial
620 PRIMARY KEY(project, ncr, co_code, part_number, batch_number, -
, serial_number),
623 FOREIGN KEY(project, co_code, part_number, batch_number, -
, serial_number)
624 REFERENCES ManufacturedPart(project, ci_code, -
, part_number, batch_number, serial_number)
625 );
10 PIANO DI SVILUPPO DEL
SOFTWARE
I.1 Piano della prima iterazione di elaborazione
E.1 Pianificazione degli elaborati nelle fasi e iterazioni
10.1 piano delle fasi
Disciplina Pratica Elaborato I E C T

Modellazione modellazione agile, modello di dominio E.1
del Business workshop requisiti
Requisiti modello dei casi duso I.1 E.12
workshop requisiti,
visione I.1 E.1
esercizio visione,
specifiche I.1 E.1
votazione a punti
supplementari
glossario I.1 E.1
Progettazione modellazione agile, Modello di Progetto I.1 E.1
sviluppo guidato architettura software E.12
dai test modello dei dati E.12
Implementazione sviluppo guidato dai modello di implementa- E.2
test, sviluppo a coppie, zione
integrazione continua,
design pattern
Test bug tracking, svilup- Modello dei Casi di Test
po guidato dai test,
integrazione continua
Rilascio feedback utente, for- Modello Documentazio-
mazione, bug tracking, ne Utente
sviluppo guidato dai
test, integrazione con-
tinua
Piano di Rilascio
Gestione del gestione del piano di sviluppo del I.1 E.12
progetto progetto agile, software
riunioni Scrum Piano di Iterazione I.1 E.1
Piano di Rischio
Infrastruttura integrazione continua Configurazione Ambien- E.2
te di Sviluppo
147
Parte II
APPENDICI
ESA Space Engineering A
(b) Hardness test Released 29/06/2016 4:49 pm Copy-

(a) Unpacking Galileo quartet Released 09/09/2016 2:27 right STFCS. Kill The ESARAL Advanced Manufac-
pm Copyright ESA-CNES-ARIANESPACE/Optique Video turing Laboratory on Harwell Campus, UK, assesses new
du CSG - J DURRENBERGER One of four new Galileo material processes, joining techniques and 3D printing
satellites is unpacked after arrival in the S1A payload technologies for application in space. Some materials
preparation building at Guiana Space Centre in French are put through experiments that test their mechan-
Guiana. The quartet will now be prepared for a shared ical properties. For example, a sample is placed in a
launch this November by Ariane 5 the first for Europes hardness machine with an indenter to apply pressure.
satnav constellation. The deformations are examined to deduce the materials
hardness.
(c) Examining every detail Released 29/06/2016 2:06 pm (d) ATV-4 docking system test Released 12/10/2012
Copyright STFCS. Kill The ESARAL Advanced Man- 12:22 pm Copyright ESA/CNES/Arianespace/Optique
ufacturing Laboratory on Harwell Campus, UK, assesses Video du CSG Engineers test ATV Albert Einsteins
new material processes, joining techniques and 3D print- docking system in Kourou, French Guiana. By using
ing technologies for application in space. The Scanning a plate that reproduces the passive part on the In-
Electron Microscope allows microstructural observation ternational Space Station the complete capture and
of internal porosity, cracks, defects and grain morphology docking sequence can be tested mechanically on Earth.
as well as compositional analysis using Energy Dispersive Each spacecraft can deliver up to 7 tonnes of cargo to
X-ray Spectroscopy. the International Space Station including supplies and
equipment, water, air, nitrogen, oxygen and fuel.
(e) MSG-3 Solar Panel check Released 16/05/2012 9:46

am Copyright ESA/CNES/Arianespace/Optique Video
du CSG - J.M. Guillon In the cleanroom at Europes (f) Herschel telescope mirror at ESTEC Re-
spaceport, the Guiana Space Centre, in Kourou, French leased 08/02/2008 3:01 pm Copyright ESA
Guiana, the third Meteosat Second Generation satellite The gigantic telescope of ESAs Herschel in-
undergoes a solar panel check. MSG-3 is planned for frared space observatory as it was being pre-
launch in June 2012. MSG-3 is the third in a planned pared for assembly with its spacecraft. Her-
series of four satellites operated by Eumetsat, the Euro- schel uses the largest mirror ever flown in
pean Organisation for the Exploitation of Meteorological space.
Satellites.
(b) T6 ion thruster firing The eerie blue exhaust trail of

(a) Tower of Vega Looking up from the bottom of the an ion thruster during a test firing. A quartet of these
mobile launch gantry for ESAs Vega launcher in French highly efficient T6 thrusters is being installed on ESAs
Guiana, as captured by photographer Edgar Martins. BepiColombo spacecraft to Mercury at ESAs ESTEC Test
Centre in Noordwijk, the Netherlands.
(d) Multigen Arabidopsis Charles Darwin first described

how plant stems grow in a corkscrew fashion, but how it
(c) 30% efficient multi-junction solar cell happens was unclear. The Multigen experiment on the
The design seen here is a thin version International Space Station showed in 2007 it is driven
of the European 3G30 triple-junction gal- by an interplay of light and gravity driving cell signals in
lium arsenide solar cell. Produced by Azur the plants. The Aradopsis plants were grown in ESAs Eu-
Space Solar Power, it is one of the most ropean Modular Cultivation System - a miniature green-
efficient in the world. house to probe how plants grow in weightlessness.
(f) Inspecting JWSTs primary mirror Before a spacecraft

goes into space it must undergo rigorous testing to confirm
it can withstand the violent vibrations and sounds during
launch. For the powerful 6.5 m-diameter telescope of the
James Webb Space Telescope, or JWST, making the same
(e) Silicon pore optics stacks Stacks of carefully measurements both before and after a simulated launch
polished, coated and cut silicon wafers nor- is a vital part of confirming its optics will not be adversely
mally used to manufacture integrated circuits affected by the real launch.
that will focus X-rays inside ESAs Athena space
observatory, due for launch in 2028.
Philaes instruments
Released 20/12/2013 4:37 pm
Copyright ESA/ATG medialab
Description Rosetta will deploy the Philae lander to the surface of comet 67P/Churyumov-Gerasimenko for in situ
analysis with its 10 instruments:
APXS Alpha Proton X-ray Spectrometer (studying the chemical composition of the landing site and its potential
alteration during the comets approach to the Sun)
CIVA Comet Nucleus Infrared and Visible Analyser (six cameras to take panoramic pictures of the comet
surface)
CONSERT COmet Nucleus Sounding Experiment by Radiowave Transmission (studying the internal structure of the
comet nucleus with Rosetta orbiter)
COSAC The COmetary SAmpling and Composition experiment (detecting and identifying complex organic
molecules)
PTOLEMY Using MODULUS protocol (Methods Of Determining and Understanding Light elements from Unequivocal
Stable isotope compositions) to understand the geochemistry of light elements, such as hydrogen, carbon,
nitrogen and oxygen.
MUPUS MUlti-PUrpose Sensors for Surface and Sub-Surface Science (studying the properties of the comet surface
and immediate sub-surface)
ROLIS Rosetta Lander Imaging System (providing the first close-up images of the landing site)
ROMAP Rosetta Lander Magnetometer and Plasma Monitor (studying the magnetic field and plasma environment
of the comet)
SD2 Sampling, drilling and distribution subsystem (drilling up to 23 cm depth and delivering material to onboard
instruments for analysis)
SESAME Surface Electric Sounding and Acoustic Monitoring Experiment (probing the mechanical and electrical
parameters of the comet)
(a) Philaes instruments

Schiapparelli
Released 28 October 2015
Copyright ESA/ATG medialab
Description Because Schiaparelli is primarily demonstrating technologies needed for landing, it does not have a long
scientific mission lifetime: it is intended to survive on the surface for just a few days by using the excess energy capacity
of its batteries. However, a set of engineering and scientific sensors will analyse the local environment during descent
and after landing.
This artists impression shows the interior of the Schiaparelli entry, descent and landing demonstrator module. Schiaparelli,
part of the ExoMars 2016 mission, was launched together with the Trace Gas Orbiter on 14 March 2016 and will arrive
at the Red Planet in October.
Schiaparelli carries a small science payload, called DREAMS (Dust Characterisation, Risk Assessment, and Environment
Analyser on the Martian Surface), to study the environment.
DREAMS consists of a suite of sensors to measure the local wind speed and direction (MetWind), humidity (DREAMS-H),
pressure (DREAMS-P), atmospheric temperature close to the surface (MarsTem), the transparency of the atmosphere
(Solar Irradiance Sensor, SIS), and atmospheric electric fields (Atmospheric Radiation and Electricity Sensor; MicroARES)
at Mars. The payload will operate on the surface of Mars for 28 sols.
In addition, there is an investigation known as AMELIA, for entry and descent science data collection using the spacecraft
engineering sensors. A separate instrumentation package, COMARS+, will monitor the heat flux on the back cover of
Schiaparelli as it passes through the atmosphere.
A compact array of laser retroreflectors, INRRI, is attached to the zenith-facing surface of Schiaparelli. This can be used
as a target for Mars orbiters to laser-locate the module.
A UHF antenna is used for communicating with the Trace Gas Orbiter.
(a) Schiaparelli Module

ACRONIMI
3NF third normal form

ACL Access Control List
BPM Businees Process Management
BPMN Business Process Modeling Notation
CDF Concurrent Design Facility
ECSS European Cooperation for Space Standardization
EMITS Electronic Mailing Invitation to Tender System
ESA European Space Agency
ESA-STAR ESA System for Tendering And Registration
ESCC European Space Components Coordination
FQDN Fully Qualified Domain Name
FTP File Transfer Protocol
INCOSE International Council on Systems Engineering
ISO International Organization for Standardization
LDAP Lightweight Directory Access Protocol
MBSE Model-based System Engineering
MVC ModelViewController
NC Nonconformance
NCTS Nonconformance Tracking System
OCDS Open Concurrent Design Server
OOA/D Object-oriented Analysis/Design
ORM objectrelational mapping
OMG Object Management Group
SLA service level agreement
SME Small to Mediumsized Enterprise
UP Unified Process
UTC Coordinated Universal Time
UUID Universally Unique Identifier
TDD Test Driven Development
VSD Virtual Spacecraft Design
155
BIBLIOGRAFIA
[Atz+14] P. Atzeni et al. Basi di dati. 4a ed. Collana di istru-

zione scientifica. Serie di informatica. McGraw-Hill
Education, 2014, p. 784. isbn: 9788838665875.
[Atz13] P. Atzeni. Basi di dati. Modelli e linguaggi di interro-
gazione. Collana di istruzione scientifica. Serie di in-
formatica. McGraw-Hill Education, 2013. isbn: 9788838668005.
url: https : / / books . google . it / books ? id % 09 =
%207sG2nQEACAAJ.
[Bac+10] Felix Bachmann et al. Documenting Software Archi-
tectures: Views and Beyond. Second. Addison-Wesley
Professional, 2010.
[Ben+10] A. Bennetti et al. ECLIPSE, an Emerging Standar-
dized Modular, Secure and Affordable Software Tool-
set in Support of Product Assurance, Quality Assu-
rance and Project Management for the Entire Eu-
ropean Space Industry (from Innovative SMEs to
Primes and Institutions). In: DASIA 2010 Data Sy-
stems In Aerospace. Vol. 682. ESA Special Publica-
tion. Ago. 2010, p. 5.
[DEB10] Hans Peter De Koning, Harald Eisenmann e Massi-
mo Bandecchi. Evolving standardization suppor-
ting model based systems engineering. In: 4th In-
ternational Workshop on System & Concurrent Engi-
neering for Space Applications (SECESA 2010). 1. 2010.
[Eck06] B. Eckel. Thinking in Java vol. 1 Fondamenti. Vol. 1.
Thinking in Java. Pearson, 2006. isbn: 9788871923031.
url: https : / / books . google . it / books ? id % 09 =
%20DGVZ76n9ExsC; B. Eckel. Thinking in Java vol. 2
Tecniche avanzate. Vol. 2. Thinking in Java. Pearson,
2006. isbn: 9788871923048. url: https : / / books .
google.it/books?id%09=%20QRU4- 1JwN2kC; B. Ec-
kel, G. Piriou e M. Tripolini. Thinking in Java vol.
3 Concorrenza e interfacce grafiche. Vol. 3. Thinking
in Java. Pearson, 2012. isbn: 9788871926780. url:
https : / / books . google . it / books ? id % 09 = %208 -
HbG0XAUeYC.
[EMd09] H. Eisenmann, J. Miro e H.P. de Koning. MBSE
for European Space-Systems Development. In: IN-
COSE Insight, Special Edition on Model-Based Systems
Engineering (dic. 2009).
157
158 Bibliografia
[Fow10] Martin Fowler. UML distilled. Guida rapida al lin-

guaggio di modellazione standard. A cura di Baresi.
Trad. da Gaburri. 4a ed. Pearson, Addison-Wesley,
2010, p. 256. isbn: 9788871925981.
[Fow96] Martin Fowler. Analysis Patterns: Reusable Object Mo-
dels. Addison-Wesley, 1996. isbn: 978-0-201-89542-
1.
[Gam+08] Erich Gamma et al. Design Patterns. Elementi per il
riuso di software a oggetti. 1a ed. Pearson Paravia Bru-
no Mondadori S.p.A., 2008. isbn: 9788871921501.
[Gra92] Robert Grady. Practical Software Metrics for Project
Management and Process Improvement. Prentice-Hall,
1992.
[Hor04] C.S. Horstmann. Progettazione del software e design
pattern in Java. Apogeo education. Apogeo, 2004.
isbn: 9788850321575. url: https://books.google.
it/books?id%09=%20oxz0HmpOKvkC.
[JBR99] Ivar Jacobson, Grady Booch e James Rumbaugh.

The Unified Software Development Process. A cura di
Mass Reading. Addison-Wesley, 1999, p. 512. isbn:
9780201571691.
[Kru95] P. Kruchten. Architectural Blueprints The 4+1
View Model of Software Architecture. In: IEEE
Software 12 (6 nov. 1995), pp. 4250.
[Lar16] Craig Larman. Applicare UML e i pattern. Analisi e
progettazione orientata agli oggetti. A cura di Luca
Cabibbo. 4a ed. Pearson Italia S.p.A., 2016, p. 708.
isbn: 9788891901033.
[Pre08] Roger S. Pressman. Principi di ingegneria del soft-
ware. 5a ed. McGraw-Hill Education, 2008, p. 750.
isbn: 9788838664182. url: http : / / www . catalogo .
mcgraw-hill.it/catLibro.asp?item_id=2269.
[Rad12] Tijs Rademakers. Activiti in Action: Executable Bu-

siness Processes in BPMN 2.0. Greenwich, CT, USA:
Manning Publications Co., 2012. isbn: 9781617290121.
[Wal14] C. Walls. Spring in Action. Manning Publications
Company, 2014. isbn: 9781617291203. url: https :
//books.google.it/books?id%09=%201kHsnAEACAAJ.
Standard ECSS 159
standard ecss
[] ECSS Abbreviated terms. ECSS. url: http : / / ecss .
nl/home/ecss-glossary-abbreviations/.
[] ECSS Terms and definitions. ECSS. url: http://ecss.

nl/home/ecss-glossary-terms/.
[ECSS-E-ST-10-02C] ECSS-E-ST-10-02C Verification. This Standard esta-

blishes the requirements for the verification of a
space system product. It defines the fundamental
concepts of the verification process, the criteria for
defining the verification strategy and specifies the
requirements for the implementation of the verifi-
cation programme. ECSS, 6 mar. 2009. url: http://
ecss.nl/standard/ecss-e-st-10-02c-verification/
(visitato il 12/10/2016).
[ECSS-E-ST-10C] ECSS-E-ST-10C System engineering general requi-
rements. This standard specifies the systems engi-
neering implementation requirements for space sy-
stems and space products development. ECSS, 6 mar.
2009. url: http://ecss.nl/standard/ecss-e-st-
10c-system-engineering-general-requirements/
[ECSS-E-TM-10-23A] ECSS-E-TM-23A Space system data repository. This
Technical Memorandum specifies the semantics of
the data needed to support the engineering pro-
cesses as specified in ECSS standards, thereby ena-
bling the concept of a space system data repository
to capture all engineering data produced during
the complete space system lifecycle. ECSS, 25 nov.
2009. url: http://ecss.nl/hbstms/ecss-e-tm-10-
23a- space- system- data- repository/ (visitato il
12/10/2016).
[ECSS-E-TM-10-25A] ECSS-E-TM-25A Engineering design model data ex-
change (CDF). This Technical Memorandum, under
the ECSS-E-10 System Engineering in the enginee-
ring branch of ECSS series of documents, defines
the recommendations for model based data exchan-
ge for the early phases of engineering design. ECSS,
20 ott. 2010. url: http://ecss.nl/hbstms/ecss-
e- tm- 10- 25a- engineering- design- model- data-
exchange-cdf-20-october-2010/ (visitato il 12/10/2016).
[ECSS-M-ST-10-01C] ECSS-M-ST-10-01C Organization and conduct of re-

views. This Standard provides means for identify-
ing and structuring all of the activities and infor-
mation required in a project review. ECSS, 15 nov.
160 Bibliografia
2008. url: http://ecss.nl/standards/ecss-m-st-

10-01c-organization-and-conduct-of-reviews/
[ECSS-M-ST-10C] ECSS-M-ST-10C rev.1 Project planning and imple-
mentation. This Standard describe the key elements
of project planning and implementation and identi-
fying the top level requirements and products that
together provide a coherent and integrated project
planning across the 3 ECSS branches. ECSS, 6 mar.
2009. url: http://ecss.nl/standards/ecss-m-st-
10c-rev-1-project-planning-and-implementation/
[ECSS-M-ST-40C] ECSS-M-ST-40C rev.1 Configuration and information
management. The scope of this standard is to de-
scribe the processes and provide the requirements
for managing the information/documentation and
configuration of products within a space program-
me or project. ECSS, 6 mar. 2009. url: http : / /
ecss . nl / standards / ecss - m - st - 40c - rev - 1 -
configuration-and-information-management/ (vi-
sitato il 12/10/2016).
[ECSS-Q-ST-10-09C] ECSS-Q-ST-10-09C Nonconformance control system.
This Standard defines the requirements for the con-
trol of nonconformances. ECSS, 31 lug. 2008. url:
http : / / ecss . nl / standards / ecss - q - st - 10 -
09c - nonconformance - control - system/ (visitato
il 12/10/2016).
[ECSS-Q-ST-10C] ECSS-Q-ST-10C rev.1 Product assurance management.
This document defines the Product assurance ma-
nagement requirements for space projects. ECSS,
15 mar. 2016. url: http : / / ecss . nl / standards /
ecss - q - st - 10c - rev - 1 - product - assurance -
management-15-march-2016/ (visitato il 12/10/2016).
[ECSS-Q-ST-20C] ECSS-Q-ST-20C rev.1 Quality assurance. This Stan-

dard defines the quality assurance (QA) require-
ments for the establishment and implementation
of a Quality Assurance programme for products
of space projects. ECSS, 1 mar. 2013. url: http :
/ / ecss . nl / standards / ecss - q - st - 20c - rev - 1 -
quality - assurance - 1 - march - 2013/ (visitato il
12/10/2016).
[ECSS-Q-ST-80C] ECSS-Q-ST-80C Software product assurance. This
Standard defines a set of software product assu-
rance requirements to be used for the development
and maintenance of software for space systems. ECSS,
Risorse online 161
6 mar. 2009. url: http : / / ecss . nl / standards /

ecss - q - st - 80c - software - product - assurance/
[ECSS-S-ST-00-01C] ECSS-S-ST-00-01C Glossary of terms. ECSS, 1 ott.
2012. url: http : / / ecss . nl / standards / ecss - s -
st-00-01c-glossary-of-terms-1-october-2012/
[ECSS-S-ST-00C] ECSS-S-ST-00C Description, implementation and ge-
neral requirements. ECSS, 31 lug. 2008. url: http://
ecss.nl/standards/ecss-s-st-00c-description-
implementation- and- general- requirements- 31-
july-2008/ (visitato il 12/10/2016).
risorse online
[12] What is the CDF? ESA. 31 Lug. 2012. url: http://
www.esa.int/Our_Activities/Space_Engineering_
Technology/CDF/What_is_the_CDF.
[BRV11] C. Beccari, U. Rossetti e P. Valabrega. Saper Comu-

nicare. Cenni di scrittura tecnico-scientifica. A cura di
Italy Politecnico di Torino Torino. 2011. url: https:
/ / didattica . polito . it / tesi / SaperComunicare .
pdf.
[ESAa] ESA, cur. EMITS Open Invitations To Tender (ITTs).

url: http://emits.sso.esa.int/ (visitato il 02/11/2016).
[ESAb] ESA, cur. ESA System for Tendering And Registration.
url: https://esastar-emr.sso.esa.int/ (visitato
il 02/11/2016).
[ESAc] ESA, cur. SME Database. url: http : / / smed . esa .
int/ (visitato il 02/11/2016).
[ESA16] ESA, cur. About the Nonconformance Tracking System

(NCTS). ESTEC. 5 Gen. 2016. url: http : / / www .
esa . int / Our _ Activities / Space _ Engineering _
Technology/About_the_Nonconformance_Tracking_
System_NCTS (visitato il 10/10/2016).
[Gre13] E. Gregorio. Il pacchetto frontespizio. 2013. url: http:

//texdoc.net/texmf-dist/doc/latex/frontespizio/
frontespizio.pdf.
[Mie13] A. Miede. A classic thesis style. 2013. url: http://

texdoc.net/texmf-dist/doc/latex/classicthesis/
ClassicThesis.pdf.
162 Bibliografia
[Pan11] T. Pantieri L. ands Gordini. Larte di scrivere con LA-

TEX. 2011. url: http : / / www . lorenzopantieri .
net/LaTeX_files/ArteLaTeX.pdf.
[Tan13] Till Tantau. The TikZ and PGF Packages. Manual for
version 3.0.0. 20 Dic. 2013. url: http://sourceforge.
net/projects/pgf/.
LIBERATORIA ALLA CONSULTAZIONE
DELLA TESI DI LAUREA
DI CUI ALLART.4 DEL REGOLAMENTO DI ATENEO
PER LA CONSULTAZIONE DELLE TESI DI LAUREA
(D.R. n. 479 del 14/11/2016)
Il sottoscritto Vanada Marco, nato a Bari il 22 gennaio 1977, matricola

509591, iscritto al Corso di Laurea Triennale in Ingegneria Informatica e
dellAutomazione (D.M. 270/04), autore della presente Tesi di Laurea in
Ingegneria del Software dal titolo:
Sviluppo software di gestione dei processi di garanzia di qualit e

tracciamento delle non conformit di progetti dellindustria
aerospaziale secondo gli standard ECSS/ESA
Keyword: Unified Process, Software Engineering, ESA, project management, non

conformance, process, quality, assurance, aerospace, industry
autorizza
la consultazione della presente tesi, fatto divieto a chiunque di riprodurre

in tutto o in parte quanto in essa contenuto.
Bari, 28 marzo 2017
Marco Vanada

Vanadia Marco - Tesi Di Laurea Ingegneria Informatica - Politecnico Di Bari

Uploaded by

Document Information

Original Title

Copyright

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Vanadia Marco - Tesi Di Laurea Ingegneria Informatica - Politecnico Di Bari

Uploaded by

Copyright:

Politecnico di Bari

DIPARTIMENTO DI INGEGNERIA ELETTRICA E DELLINFORMAZIONE

Tesi in Ingegneria del Software

Sviluppo software di gestione dei processi di garanzia di qualita` e

Anno Accademico 20152016

i processo unificato xxiii

8 architettura software 129

Figura 1 ESA Concurrent Design Facility . . . . . . . . . . . . . xix

Tabella 2 Architettura moduli e servizi di Sapienza ECLIPSE . . 6

ELENCO DEI CODICI

Codice 1 Definizione schema SQL . . . . . . . . . . . . . . . . . . 133

ELENCO CASI DUSO

UC1 Manage Account . . . . . . . . . . . . . . . . . . . . . . . . . 46

ER1 Company . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Il caso di studio oggetto di Tesi lesecuzione del Processo Unifica-

Unified Process Software Engineering of Project Management System

Naturalmente, vi sono casi in cui solo un individuo fuori dal comune

Bari, 28 marzo 2017

Sostenere e promuovere, per scopi esclusivamente pacifici,

Oggi le attivit spaziali sono volte al servizio dei cittadini, ed i cittadini

Lo Spazio la frontiera dellumanit.

di euro ogni anno, e i lanciatori spaziali che li mettono in orbita triplicano

. . . bellissima, senza frontiere n confini

evoluzione dellingegneria dei sistemi spaziali

Figura 1: ESA Concurrent Design Facility, ESTEC in Noordwijk, Olanda. ESA

e consorzi, istituti di ricerca e universit.

spesso sono causa di duplicazione dei dati, rischio di inconsistenze

il contenuto e la forma di presentazione sono strettamente legate e

la creazione di riferimenti incrociati allinterno di un documento e

difficoltosa lestrazione affidabile dellinformazione da parte di

i metadati sono impliciti non processabili dalle macchine.

La documentazione redatta in formato ipertestuale e multimediale e i

spesso i progetti spaziali hanno lunga durata, misurata in anni, e raramen-

Model-based systems engineering (MBSE) is the formalized appli-

I vantaggi dellapproccio basato sui modelli semantici sono: Sistemi

contenuti e presentazione disaccoppiati;

la possibilit di realizzare viste multiple degli stessi dati, specifiche

la creazione automatica di collegamenti tra entit del modello;

la generazione automatica di documentazione di report;

lestrazione automatica affidabile dellinformazione;

la memorizzazione esplicita di metadati processabili meccanicamen-

la possibilit di trasformare i modelli in ulteriori modelli per ottenere

Nel 2010 e 2011 ECSS ha lanciato due iniziative complementari per la

Entrambe i TM hanno lo scopo di costruire il consenso nella comuni-

Vediamo che la programmazione unarte,

Il Processo Unificato applicato nella presente Tesi disciplina le attivit

produzione parte dal nucleo principale pi rischioso dellarchitettura

Figura 2: Discipline del Processo Unificato

La pratica di analisi, modellazione, sviluppo e gestione di un processo

1 elaborati delle discipline up

modello di dominio Rappresenta le classi concettuali di oggetti impor-

regole di dominio Descrive regole e politiche che trascendono il parti-

modello dei casi duso Descrive i requisiti funzionali definiti dallin-

specifiche supplementari Raccoglie i requisiti non funzionali che co-

glossario Elenca i termini chiave, per ridurre le ambiguit tra le parti

lista e piano di gestione dei rischi Descrive i rischi aziendali, tec-

prototipi Chiarisce la visione e valida alcune idee tecniche con limple-

architettura software Analizza i fattori che hanno uninfluenza signi-

modello dei dati Definisce il modello concettuale delle informazioni

modello di implementazione Comprende tutto il codice sorgente ne-

modello dei casi di test Raccoglie il codice sorgente di sviluppo gui-

documentazione utente Contiene la documentazione per lutente pro-

piano di rilascio Descrive le procedure di rilascio del software sullin-

1.7 Gestione del progetto

piano di sviluppo del software Ipotesi sommarie sulla durata e lo

piano delliterazione Descrive le attivit da realizzare nelle iterazione