Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
tesi di laurea specialistica
Metodologie e strumenti dell'Ingegneria dei Requisiti della
piattaforma MLA
Anno Accademico 2010/2011
relatore
Ch.mo Prof. Stefano Russo
correlatore
Ch.mo Ing. Roberto Pietrantuono
candidato
Emanuela Daria Capuano
matr. 885/223
i
A chi mi ha indicato la strada, tenendomi per mano.
A mia madre e mio padre
ii
Indice generale
Metodologie e strumenti dell'Ingegneria dei Requisiti della piattaforma MLA...................................1
Introduzione..........................................................................................................................................7
Capitolo 1...........................................................................................................................................10
1. I requisiti.........................................................................................................................................10
1.1 Pseudo requisiti...................................................................................................................11
1.2 Requisiti funzionali.............................................................................................................11
1.3 Requisiti non funzionali......................................................................................................12
1.3.1 Requisiti non funzionali di Prodotto.......................................................................14
1.3.1.1 Usability Requirements..............................................................................16
1.3.1.2 Efficency Requirements.............................................................................16
1.3.1.3 Reliability Requirements............................................................................16
1.3.1.4 Portability Requirements............................................................................17
1.3.2 Process Requirements.............................................................................................17
1.3.2.1 Requisiti di consegna.................................................................................17
1.3.2.2 Requisiti di implementazione.....................................................................18
1.3.2.3 Standards Requirements ............................................................................18
1.3.3 Requisiti Esterni.....................................................................................................18
1.4 Requisiti di dominio............................................................................................................18
1.5 Considerazioni ...................................................................................................................19
1.6 I requisiti utente e di sistema...............................................................................................20
1.7 Requisiti di interfaccia........................................................................................................21
1.8 La scrittura dei requisiti......................................................................................................22
1.9 Documento dei requisiti......................................................................................................24
1.10 La qualità del software......................................................................................................27
1.10.1 Lo standard ISO....................................................................................................28
Capitolo 2...........................................................................................................................................32
Requirements Engineering.................................................................................................................32
2.1 I rischi.................................................................................................................................32
2.2 L'ingegneria dei requisiti: definizioni ed attività................................................................34
2.3 Studio di fattibilità..............................................................................................................38
2.4 Elicitazione ed analisi dei requisiti.....................................................................................39
2.4.1 La scoperta dei requisiti..........................................................................................42
2.4.1.1 Sorgenti di informazioni.............................................................................42
2.4.1.2 Ingegneria dei requisiti basata sui punti di vista........................................43
2.4.1.3 Tecniche di elicitazione dei requisiti..........................................................44
2.4.1.3.1 Le interviste...................................................................................44
2.4.1.3.2 Scenari di interazione e casi d'uso.................................................45
2.4.1.3.2.1 Considerazioni sui casi d'uso.............................................49
2.4.2 L'analisi...................................................................................................................51
2.5 Specifica dei requisiti..........................................................................................................51
2.6 La tracciabilità dei requisiti.................................................................................................53
2.7 Convalida dei requisiti........................................................................................................56
2.8 La gestione dei requisiti......................................................................................................58
Capitolo 3...........................................................................................................................................61
Sistemi emdebbed e metodologie di sviluppo....................................................................................61
3.1 Caratteristiche dei sistemi embedded..................................................................................63
iii
3.2 Vincoli dei sistemi embedded.............................................................................................65
3.3 I requisiti di un sistema embedded......................................................................................66
3.3.1 I requisiti funzionali................................................................................................66
3.3.2 Requisiti temporali ................................................................................................67
3.3.3 Requisiti di affidabilità...........................................................................................67
3.3.4 Consumo.................................................................................................................68
3.3.5 Prestazioni..............................................................................................................68
3.3.6 Costo.......................................................................................................................68
3.4 Lo sviluppo dei sistemi embedded......................................................................................68
3.4.1 Il modello di sviluppo a cascata.............................................................................69
3.4.2 Un approccio di tipo evolutivo...............................................................................74
3.4.3 Modello a V............................................................................................................75
3.4.3.1 Le fasi del modello a V..............................................................................76
Capitolo 4...........................................................................................................................................79
Le metodologie agili...........................................................................................................................79
4.1 Il processo Agile..................................................................................................................81
4.2 Il Manifesto Agile...............................................................................................................82
4.3 Alcune metodologie agili....................................................................................................83
4.4 Metodologie tradizionali vs Metodologie agili...................................................................84
Capitolo 5...........................................................................................................................................89
La piattaforma Metropoolitana Leggera Automatica di AnsaldoBreda: un caso di studio................89
5.1 MLA....................................................................................................................................90
5.1.1 Generalità sui componenti della piattaforma..........................................................92
5.2 Il ciclo di sviluppo...............................................................................................................94
5.2.1 Planning..................................................................................................................95
5.2.2 Requirements Specification....................................................................................96
5.2.3 Architecture and Design.........................................................................................97
5.2.4 Module Design and Implementation......................................................................98
5.2.5 Analisi Statica.......................................................................................................100
5.2.6 Module Testing.....................................................................................................101
5.2.7 Integration and Validation Testing........................................................................102
5.2.8 Release .................................................................................................................103
5.2.9 Gestione della configurazione del software.........................................................104
5.3 Analisi del processo di sviluppo........................................................................................105
5.4 Problematiche connesse alla piattaforma MLA................................................................106
5.5 MetroRiyadh: un caso di studio........................................................................................108
5.5.1 Studio della documentazione esistente.................................................................109
5.5.2 Specifica................................................................................................................110
5.5.3 Verifica e validazione dei requisiti........................................................................111
5.5.4 Tracciabilità e gestione dei cambiamenti..............................................................111
5.6 Interventi...........................................................................................................................112
5.6.1 I requisiti software................................................................................................112
5.6.2 I livelli di astrazione.............................................................................................112
5.6.3 I requisiti di interfaccia.........................................................................................114
5.6.4 La scrittura dei requisiti........................................................................................117
5.6.4.1 Linee guida per la scrittura dei requisiti...................................................117
5.6.4.1.1 Strutturazione del requisito software...........................................118
5.6.4.1.2 Osservazioni.................................................................................119
5.6.4.1.3 Software High Level Requirements.............................................120
5.6.4.1.4 Low Level Software Requirements.............................................122
iv
5.6.4.1.5 Casi d'uso, scenari di interazione e gerarchie di requisiti............125
5.6.4.1.6 Interazioni con altri sottosistemi..................................................126
5.6.4.1.7 La tracciabilità.............................................................................126
Esempi.....................................................................................................................................128
Esempio 1......................................................................................................................128
Esempio 2......................................................................................................................135
Esempio 3......................................................................................................................138
Esempio 4......................................................................................................................140
5.7 IBM Rational DOORS: un tool per la Requirements Management.................................145
5.7.1 La struttura del progetto.......................................................................................145
5.7.2 Dal capitolato ai requisiti di sistema/veicolo..............................................147
5.7.3 Dai requisiti di sistema/veicolo agli HLR...................................................148
5.7.4 Dal requisito HL al requisito LL.................................................................149
5.7.5 Dai LLR ai Moduli Software......................................................................149
5.7.6 Moduli Software e Test...............................................................................150
Conclusioni.............................................................................................................................152
Appendice.........................................................................................................................................153
Scenari.....................................................................................................................................153
Suggerimenti per la scrittura dei casi d'uso.............................................................................153
Misure di qualità per la valutazione della specifia dei requisiti software (Standard IEEE 830)154
I dodici principi del software agile.........................................................................................154
SIL – Safety Integrity Level....................................................................................................156
Strumenti di supporto alla progettazione in AnsaldoBreda....................................................157
Norme adottate in AnsaldoBreda............................................................................................158
Bibliografia.......................................................................................................................................160
Indice delle illustrazioni
Illustrazione 1: Esempio di requisito funzionale................................................................................12
Illustrazione 2: Classificazione dei requisiti non funzionali .............................................................14
Illustrazione 3: Misure dei requisiti non funzionali...........................................................................15
Illustrazione 4: Esempio di requisito di usabilità...............................................................................16
Illustrazione 5: Esempio di requisiti di sistema..................................................................................21
Illustrazione 6: Modello di qualità ISO/IEC 9126.............................................................................29
Illustrazione 7: Valutazione della maturità del processo....................................................................30
Illustrazione 8: Attività dell'ingegneria dei requisiti..........................................................................32
Illustrazione 9: Evasione dei progetti IT nell'anno 2009 secondo una stima dello Standish Group. .33
Illustrazione 10: Principali cause di fallimento di un progetto...........................................................34
Illustrazione 11: Modello a spirale dell'Ingegneria dei Requisiti.......................................................35
Illustrazione 12: Le fasi del processso di ingegneria dei requisiti......................................................38
Illustrazione 13: Il processo di deduzione ed analisi dei requisiti......................................................41
Illustrazione 14: Processo di ricerca dei requisiti...............................................................................42
Illustrazione 15: Casi d'uso e ciclo di vita del software.....................................................................48
Illustrazione 16: Esempio di matrice di tracciabilità (orizzontale).....................................................54
Illustrazione 17: Tracciabilità Pre-RS e Post-RS................................................................................55
Illustrazione 18: Mutabilità dei requisiti nel tempo......................................................................58
Illustrazione 19: Evoluzione controllata dei requisiti.........................................................................60
Illustrazione 20: Incidenza percentuale dei sistemi emebedded sul costo complessivo dei prodotti. 62
Illustrazione 21: Fasi dello sviluppo software secondo il modello a cascata.....................................70
Illustrazione 22: Metodologia di sviluppo per sistemi embedded......................................................71
Illustrazione 23: Partizionamento HW/SW........................................................................................72
v
Illustrazione 24: Costo necessario per risolvere bug durante il CVS.................................................72
Illustrazione 25: Sviluppo di sistemi embedded basati su piattaforma..............................................73
Illustrazione 26: Metodologia di sviluppo software a spirale............................................................74
Illustrazione 27: Modello a V.............................................................................................................76
Illustrazione 28: Fasi dei modelli iterativi..........................................................................................80
Illustrazione 29: Fasi del waterfall model..........................................................................................80
Illustrazione 30: Fasi del processo di sviluppo Agile.........................................................................82
Illustrazione 31: Piattaforma MLA....................................................................................................92
Illustrazione 32: Architettura del TCMS............................................................................................93
Illustrazione 33: Modello a V adoperato dall'AnsaldoBreda..............................................................94
Illustrazione 34: Planning e Project Review......................................................................................95
Illustrazione 35: Requirements Specification.....................................................................................96
Illustrazione 36: Requirements Review..............................................................................................97
Illustrazione 37: Archietecture and Design........................................................................................98
Illustrazione 38: Module Design and Implementation.......................................................................99
Illustrazione 39: Detailed Design Review........................................................................................100
Illustrazione 40: Analisi Statica........................................................................................................101
Illustrazione 41: Module Testing......................................................................................................102
Illustrazione 42: Integration and Validation Testing.........................................................................103
Illustrazione 43: Release...................................................................................................................104
Illustrazione 44: Configuration Review...........................................................................................105
Illustrazione 45: Esempio di requisito funzionale di sistema di MetroRiyadh................................109
Illustrazione 46: Esempio di requisito software...............................................................................109
Illustrazione 47: Processo di definizione dei requisiti......................................................................114
Illustrazione 48: Esempio di requisito di interfaccia di comunicazione: Dataset 500......................116
Illustrazione 49: Esempio di requisito di sistema.............................................................................120
Illustrazione 50: Esempio di "sovra-specifica" nel requisito software.............................................121
Illustrazione 51: DOORS: Il Project Template.................................................................................146
Illustrazione 52: Il campo descrizione di un documento FRS..........................................................147
Illustrazione 53: Tracciabilità FRS_CapitolatoTecnico....................................................................148
Illustrazione 54: Estratto di una matrice di tracciabilità (riferimento verticale)..............................149
Illustrazione 55: Matrice di tracciabilità HLR - LLR.......................................................................149
Illustrazione 56: Esempio di tracciabilità tra LH e Moduli software...............................................150
Illustrazione 57: Esempio di tracciabilità tra Modulo Software e File Test....................................151
Indice delle tabelle
Tabella 1: Destinatari del documento dei requisiti.............................................................................24
Tabella 2: Protitype SRS outline................................................................................................25
Tabella 3: La struttura di un documento dei requisiti.........................................................................26
Tabella 4: Metodologia a cascata vs Agile (SCRUM)........................................................................85
Tabella 5: Luoghi comuni sugli approcci a cascata e Agile...............................................................86
Tabella 6: Livelli di SIL nella norma EN IEC 61508.......................................................................157
vi
6
Introduzione
Nel corso degli ultimi decenni il software ha vissuto una rapida evoluzione, fornendo
tecnologie sempre più intelligenti e, di conseguenza, prodotti sempre più complessi.
Le esperienze pregresse relative a tali sistemi hanno mostrato che lo sviluppo informale del
software non sia l'approccio più idoneo: si pensi, infatti, ai progetti di grandi dimensioni ed alle
difficoltà ad essi correlate di presentare il lavoro in tempo congruo, di non sforare il budget iniziale,
alle caratteristiche di performance ed affidabilità richiesti, nonché alla loro manutenzione.
Per poter ottenere un buon prodotto software è indispensabile gestire il relativo progetto in
maniera adeguata1 .
A tal riguardo, è necessario introdurre un'importante figura, quella del Gestore del Progetto, il
cui compito è attuare, durante il processo di sviluppo del prodotto, la pianificazione, il monitoraggio
ed il controllo di persone, processi ed eventi.
Indubbiamente, il primo passo da compiere in tal senso è quello della raccolta delle
informazioni concernenti le funzionalità che il committente richiede al prodotto che si intende
sviluppare, cioè dei requisiti.
In questo lavoro sarà approfondita una particolare branca dell Ingegneria dei Sistemi: l'
Ingegneria dei Requisiti, che rappresenta una delle attività più critiche del processo software, poichè
racchiude in sé il processo di comprensione e definizione dei servizi richiesti al sistema in esame e
l'individuazione dei vincoli operativi e di sviluppo del prodotto. Naturalmente, un errore commesso
in questa fase si riverbera nelle fasi susseguenti di progettazione ed implementazione del sistema: da
ciò se ne evince la criticità.
L'approccio adeguato per comprendere l'utilizzo di un artefatto consiste nell'individuare gli
obiettivi che esso ci consentirà di raggiungere, affinchè il sistema risulti adeguato alle aspettative
del cliente.
Molto spesso, però, le tecniche di Requirements Engineering sono adoperate solo nella fase
finale di analisi per ottemperare all'esigenza di completezza, consistenza ed, eventualmente, per
garantire una verifica automatica dei requisiti stessi, ignorandone gli obiettivi iniziali.
La letteratura riporta una molteplicità di metodi e tecniche volti alla raccolta ed alla
strutturazione dei requisiti e la scelta dell'approccio da adottare dipende dal particolare contesto nel
quale si opera.
In generale, l'Ingegneria dei Requisiti ha come obiettivo quello di sviluppare tecniche e
modelli che siano di aiuto all'analista per capire in profondità il contesto organizzativo nel quale è
1 Le problematiche che possono scaturire da una gestione non adeguata del progetto software ricadono nel ritardo della
consegna dello stesso, l'aumento dei suoi costi e la sua scarsa aderenza alle esigenze dei committenti.
7
inserito il sistema software ed a sviluppare soluzioni che siano quanto più possibile aderenti alle
esigenze riscontrate.
Pertanto, nell'ottica di dover adoperare un approccio diverso a seconda del particolare
contesto in esame, si rende ancor più indispensabile individuare gli obiettivi che il sistema deve
raggiungere, capire le motivazioni, le funzioni che dovranno essere progettate ed implementate,
nonchè i vincoli ai quali la realizzazione del sistema dovrà sottostare.
Tutto ciò è ancor più vero in un contesto nel quale i sistemi si trovano in stretta relazione con
l'ambiente in cui operano, perchè pensati per applicazioni specifiche, come i sistemi embedded (cioè
dedicati ad un'applicazione od una classe specifica di applicazioni) la cui presenza massiva sul
mercato è fonte, principalmente, di innovazione.
L' applicazione dei principi del Requirements Engineering richiede, a partire dal concetto di
"obiettivo", lo sviluppo di un'idea di "componente attivo" dotato di capacità di reazione che
dipendano dal contesto in cui opera, nonchè quella di "componente strategico", con caratteristiche di
indipendenza rispetto all'ambiente in cui il prodotto viene immesso.
Questa considerazone renderà possibile, nell'ambito dell'Ingegneria dei Requisiti, separare gli
aspetti troppo vincolati allo specifico progetto in esame da quelli più generici e, quindi, adattabili ai
membri di una stessa famiglia di prodotti.
Pertanto, ad un sistema embedded potrebbe essere conferito il requisito mancante della
versatilità e, di conseguenza, porre le basi per il riuso delle parti che godono di questa caratteristica.
Un approccio sistematico delle pratiche suggerite dall'Ingegneria del Software risulta di
grande interesse in coloro i quali abbiano intenzione di migliorare i processi già acquisiti, così da
renderli standard e minimizzare la differenza tra i processi aziendali adottati.
In effetti, la tendenza che va via via affermandosi è quella di abbandonare l'approccio legato
alle azioni correttive sulle "non conformità" riscontrate, a favore di uno basato sulla prevenzione dei
difetti sul prodotto finale, spostando l'attenzione dal prodotto al processo.
Obiettivo della tesi è tracciare un percorso che, a partire dai capisaldi dell'Ingegneria dei
Requisiti conduca verso la loro applicazione in un sistema embedded reale.
Un'interessante sezione del lavoro presentato è, infatti, frutto di un'attività svolta nell'ambito
del progetto Iniziativa Software Finmeccanica.
Essa è stata sostenuta dall'Unità di Ricerca coordinata dal Prof. Ing. Stefano Russo e svolta,
assieme all' Ing. Roberto Pietrantuno, presso la sede napoletana di AnsaldoBreda.
Tra gli alti, l'Azienda si distingue per la piattaforma MLA, un prodotto particolarmente
apprezzato dal mercato mondiale; pertanto, per garantirne la credibilità e la qualità è richiesto il
rispetto di alcuni standard e l'adozione di particolari criteri e strumenti di sviluppo.
8
Ciò ha fatto nascere una nuova consapevolezza che ha spronato l'azienda a rivedere l'intero
ciclo di vita del prodotto, così da scorgerne le criticità e gli aspetti migliorabili.
Pertanto, uno degli obiettivi da raggiungere è stato fissato nell'applicazione di metodologie e
strumenti dell'Ingegneria del Software per miglirare il processo di sviluppo della piattaforma MLA,
con particolare enfasi sulla gestione dei requisiti e la progettazione mirata alla riusabilità.
I risultati esposti in questa tesi, riguardano il progetto MetroRiyadh, del quale si è fatto un
caso di studio.
Nel seguente lavoro sarà introdotto il concetto di "requisito", ed una possibile classificazione
(Capitolo 1); sarà discusso il processo di Requirements Engineering, mostrandone i risultati
(Capitolo 2).
A partire da una panoramica sui Sistemi Embedded, verranno mostrati alcuni possibili
modelli di sviluppo (Capitolo 3), saranno confrontati i metodi tradizionali con le metodologie Agili,
per comprendere quale sia l'approccio più adeguato nei sistemi dedicati (Capitolo 4).
Tutti i concetti esposti nelle precedenti sezioni di questo lavoro troveranno riscontro in un
caso concreto, il progetto di AnsaldoBreda MetroRiyadh, per il quale, in questa prima fase di lavoro,
sono stati proposti ed attuati degli interventi di Ingegneria dei Requisiti (Capitolo 5).
La tesi è corredata da un'Appendice, in cui alcuni aspetti verranno approfonditi.
9
Capitolo 1
1. I requisiti
Il termine "requisito" ha una natura controversa2, che viene chiarita da Alan Mark Davis, uno
dei maggiori esperti di ingegneria dei requisiti, come segue:
" Se una compagnia vuole dare in appalto un grande progetto di sviluppo software, deve
definire i requisiti in modo abbastanza astratto da non predefinire alcuna soluzione. I requisiti
devono essere scritti in modo che diversi appaltatori possano fare le offerte proponendo vari metodi
per soddisfare le necessità del cliente. Quando l'appalto è stato assegnato, l'appaltatore deve
scrivere per il cliente una definizione del sistema molto dettagliata, in modo che il cliente possa
capire e verificare cosa il software farà. Entrambi questi documenti possono essere chiamati
documenti dei requisiti del sistema " [1].
La prima distinzione proposta da Davis è, dunque, quella tra requisiti utente 3, che
rappresentano l'entità (bisogni/necessità dello stakeholder 4) ad un alto livello di astrazione ed i
requisiti di sistema5 (cosa farà il sistema ed i vincoli operativi),nche ne offrono una descrizione al
un livello di maggior dettaglio.
Sebbene la distinzione tra i "ruoli" utente-sistema possa sembrare chiara, alcune volte non è
semplice attuare una separazione netta tra i due livelli descrittivi, così da cadere in errore in questa
fase del processo di sviluppo.
Una seconda classificazione dei requisiti, ancora una volta proposta da A.M. Davis, si basa
sulla pratica del triage6: secondo questo approccio, la priorità del requisito rappresenta uno dei
presupposti per stipulare un contratto tra gli stakeholder, che stabiliranno quali requisiti debbano
essere soddisfatti ed entro quali limiti di tempo e di costo.
Per meglio comprendere questo principio, potremmo immaginare di operare con un progetto
ipotetico dotato di risorse illimitate: in tal caso, pur essendo pronti a soddisfare tutte le esigenze
degli stakeholder coinvolti, sarebbe opportuno valutare gli aspetti che siano in grado di apportare
una maggiore soddisfazione e che diverrebbero prioritari.
2 In alcuni casi, un requisito è una formulazione astratta e di alto livello di un servizio che il sistema dovrebbe fornire,
oppure un vincolo di sistema; in altri casi, un requisito è visto come una definizione formale e dettagliata di una
funzione del sistema.
3 Requisiti utente: rappresentano i bisogni/necessità degli stakeholder
4 Stakeholder: Un individuo, un gruppo di persone, un'organizzazione, o altra entità direttamente o indirettamente
interessata al sistema.
5 Requisiti di sistema: definiscono le funzioni, i servizi ed i vincoli operativi del sistema in modo dettagliato. Il
documento dei requisiti ad essi relativo, noto come Documento dei Requisiti di Sistema (o Functional Requirements
Specification) , dovrebbe essere preciso nel descrivere accuratamente cosa debba essere implementato. Esso può
essere parte del contratto tra l'acquirente e lo sviluppatore.
6 Triage: Questo termine, adoperato in campo medico, consiste nel distinguere le urgenze nei pronto soccorso, così da
garantire l'intervento tempestivo ai casi inidcati come urgenti.
10
La situazione appena descritta non è realistica, dunque è ancor più evidente quanto nei progetti
concreti sia necessario ridurre la quantità dei requisiti da soddisfare così da semplificare i progetti ed
eliminare inutili sprechi di risorse. Questa considerazione comporterebbe, in definitiva, validazioni
più mirate da parte del committente e degli altri stakeholder, fornendo anche una flessibilità
maggiore
rispetto
alle
eventuali
modifiche
da
apportare
ai
requisiti.
Ciò risulta perfettamente in linea se consideriamo le ultime stime pubblicate dallo Standish Group,
dalle quali si evince che circa il 45% delle funzionalità di un sistema sia completamente inutilizzato,
ed il 19% viene utilizzato solo raramente.
Tuttavia, i requisiti rappresentano il patrimonio di progetto più importante, dal momento che
costituiscono l’anello di congiunzione tra i bisogni e le percezioni degli stakeholder e le soluzioni
tecnologiche progettate dagli esperti software.
1.1 Pseudo requisiti
Una considerazione interessante in merito alle caratteristiche richieste ad un sistema riguarda il
concetto [2] di "pseudo requisito", ovvero un requisito secondario. Vengono così indicati i vincoli
imposti dal cliente o dall' ambiente in cui opererà il sistema, come quelli sull' implementazione 7,
relativi alle interfacce8, operazioni9, packaging10, vincoli di natura legale11.
Ne sono un esempio:
"Il linguaggio di programmazione adottato dovrà essere Java",
oppure
"La piattaforma dovrà interfacciarsi con documenti scritti con MS Word su Windows XP".
Nei successivi paragrafi non verrà operata la distinzione tra requisiti primari e secondari12.
1.2 Requisiti funzionali
I requisiti funzionali si presentano come elenchi di funzionalità o servizi che il sistema deve
fornire. Essi descrivono anche il comportamento del sistema a fronte di particolari input e come
esso dovrebbe reagire in determinate situazioni.
7 Vincoli posti su come implementare il sistema, ad esempio l'utilizzo di specifici tool, di particolari piattaforme
hardware oppure di linguaggi di programmazione.
8 Vincoli di interfaccia, cioè imposti da sistemi esterni (con i quali il sistema debba comunicare) e formati di scambio
delle informazioni.
9 Possono essere prescritte le operazioni da eseguire rispetto all'amministrazione del sistema e sulla sua gestione.
10 Vincoli sul packaging riguardano la consegna del sistema.
11 I vincoli di natura legale possono far riferimento a licenze, norme e certificazioni alle quali il sistema dovrà essere
conforme.
12 Ad esempio, lo pseudo requisito di interfaccia verrà indicato come requisito di interfaccia.
11
Illustrazione 1: Esempio di requisito funzionale
Che si tratti di utente o di sistema, un requisito funzionale potrà essere formulato a diversi
livelli di dettaglio, dovendo preservare, naturalmente, la precisione della specifica.
Due importante caratteristica delle specifiche dei requisiti sono la completezza e la coerenza.
Un documento di specifica dei requisiti è completo se tutti i requisiti richiesti dagli utenti sono
definiti ed è consistente quando non vi sono requisiti in conflitto tra loro.
Sebbene per sistemi di piccole dimensioni questi risultati siano facilmente raggiungibili, per i
sistemi caratterizzati da un numero elevato di requisiti è richiesto uno sforzo maggiore.
Infatti, in questo secondo caso, la difficoltà è dovuta alla maggiore occorrenza di errori ed
omissioni, nonché alla presenza di un numero elevato di stakeholder con esigenze differenti, a volte
contrastanti, che possono non essere valutate nella prima fase di scrittura delle specifiche.
Dunque, la presenza di inconsistenze potrebbe essere scorta addirittura dopo aver consegnato il
prodotto al cliente, dando luogo a costi esorbitanti.
1.3 Requisiti non funzionali
I requisiti non funzionali rappresentano i vincoli e le proprietà/caratteristiche relative ad
sistema, come vincoli di natura temporale, vincoli sul processo di sviluppo e sugli standard da
adottare13.
Tipicamente, i requisiti non funzionali non si applicano a singole funzioni o servizi, bensì
all'intero sistema. Essi non riguardano direttamente le specifiche funzioni fornite dal sistema, ma
possono sia riferirsi a caratteristiche che si desidera il sistema presenti (come l'affidabilità, i tempi
di risposta, l'occupazione in memoria), sia definire i vincoli ai quali il sistema deve sottostare (come
la capacità dei dispositivi di I/O e la rappresentazione dei dati utilizzata nelle interfacce del sistema).
13 I requisiti non funzionali non riguardano solo il sistema software che si sta sviluppando, alcuni possono vincolare il
processo usato per sviluppare il sistema. Esempi di questo tipo sono: le specifiche degli standard di qualità da usare,
la specifica sull'uso di un particolare strumento CASE, una descrizione della lavorazione che deve essere seguita [3]
12
I requisiti non funzionali sono strettamente vincolati alle esigenze degli utenti, alle politiche
organizzative adottate, agli standard adoperati, alla necessaria modalità di interazione del relativo
sistema con altri componenti. Pertanto, essi possono essere classificati14 in:
•
requisiti di prodotto, che descrivono le caratteristiche del prodotto, in termini di usabilità 15,
efficienza16 , affidabilità17 e portabilità18;
•
requisiti organizzativi (o di processo), che derivano dalle politiche e procedure organizzative
relative al cliente ed allo sviluppatore;
•
requisiti esterni, che si riferiscono a fattori estranei al sistema ed al relativo processo di
sviluppo, come requisiti legislativi, requisiti di interoperabilità.
La classificazione proposta ha un carattere meramente teorico, poichè viene in aiuto
proponendo una visione schematica della vasta gamma di requisiti non funzionali che possono
intervenire nell'ambito di un progetto.
Infatti, nella realtà, ed ancor di più nel documento che dovrà descriverli, è praticamente
impossibile attuare una distinzione così rigida tra concetti espressi, magari nello stesso requisito,
soprattutto se si pensa alle relazioni che sussistono tra le varie tipologie di requisiti.
Pertanto, quella fornita è solo una delle possibilità di classificare i requisiti non funzionali19.
14 Ian Sommerville [4]classificò quindi i requisiti non funzionali in tre categorie principali: product, process e external,
cioè i requisiti di prodotto, di processo e requisiti esterni.
15 L'usabilità indica la semplicità di utilizzo del prodotto, pertanto, è una qualità soggettiva:
•
dipende dal contesto
•
dipende dall’esperienza
16 Un sistema è efficiente se usa memoria, CPU e altre risorse in modo proporzionato ai servizi che svolge, ovvero
senza sprechi.
17 Per affidabilità di un qualsiasi dispositivo (sistema o componente) si intende la probabilità che esso funzioni
correttamente, per un dato tempo, in certe condizioni.
18 Un sistema è 'potabile' quando può essere esportato in ambienti diversi da quello di origine.
19 Ad esempio, si potrebbero considerare non funzionali solo i requisiti di prodotto, riferendosi agli altri come "vincoli".
13
Illustrazione 2: Classificazione dei requisiti non funzionali
1.3.1 Requisiti non funzionali di Prodotto
Un requisito di prodotto specifica le caratteristiche desiderabili per un sistema, che possono
limitare la libertà20 di chi dovrà progettare e sviluppare il prodotto.
Ad esempio, un requisito di performance è espresso in maniera non oggettiva dall'utente, la
qual cosa rende difficile agli sviluppatori capire quale sia il livello di soddisfazione per l'utente.
Pertanto, quest'ultimo potrebbe essere stabilito arbitrariamente dagli stessi sviluppatori, potendo non
incotrare le effettive esigenze del committente.
Per ovviare al problema è necessario esprimere i requisiti non funzionali di prodotto in
maniera quantitativa, così da poterne fare una verifica oggettiva prima della consegna del prodotto.
Sulla
scorta
di
tali
considerazioni,
forniamo
un
esempio
di
quanto
detto:
Goal (non verificabile):
"il sistema deve essere facile da usare per controllori esperti, e deve essere tale da
20 Un esempio di requisito di prodotto vincolante potrebbe essere:
" Il sistema deve essere eseguito sia in su di un PC che su di un MAC" (portanility requirement)
Da ciò scaturisce che sarà influenzato direttamente il codice sorgente.
14
minimizzare
gli
errori
degli
utenti".
Requisito non-funzionale (verificabile):
"controllori esperti devono poter imparare a usare tutte le funzioni del sistema in max. 2 ore di
apprendimento. Dopo l’apprendimento, il controllore deve essere in grado di operare senza
commettere più di 2 errori al giorno".
Questa considerazione, però, non può prescindere della difficoltà, da parte del cliente, di
tradurre una propria esigenza in tal senso, del costo talvolta elevato dell'operazione, e
dell'impossibilità di quantificare alcune tipologie di requisiti21.
Si pensi, ad esempio, ai requisiti di performance ed a quelli di usability: i primi possono essere
formulati e quantificati in maniera esatta, cosa che non vale per i secondi che, quindi, potranno
essere descritti solo informalmente.
Illustrazione 3: Misure dei requisiti non funzionali
Non di rado, i requisiti non funzionali di prodotto entrano in conflitto tra loro (ad esempio, un
requisito di sicurezza potrebbe comportare una perdita in performance); pertanto, analizzandoli
adeguatamente, si riuscirà a comprendere la priorità di ciascuno di essi e stabilire quali strategie
adottare per prevenire i conflitti.
21 Si pensi, ad esempio, alla manutenibilità di un prodotto che non può essere quantificata.
15
Usabilità, Efficienza, Affidabilità, Portabilità sono le principali caratteristiche richieste ad un
prodotto.
1.3.1.1 Usability Requirements
I requisiti di usabilità descrivono la caratteristica di un prodotto software di essere
comprensibile ed utilizzabile agevolmente22 da parte dell'utente23. Questa tipologia di requisiti può
essere influenzata dagli aspetti funzionali, di efficacia e di affidabilità richiesti al sistema.
Essi descrivono in che modo utente e sistema debbano interagire, indirizzando tutti gli scenari
di utilizzo del prodotto, inclusa la fase di apprendimento dell'utilizzo dello strumento.
Illustrazione 4: Esempio di requisito di usabilità
1.3.1.2 Efficency Requirements
L'efficienza rappresenta una qualità interna, che si riferisce al "peso" del software sulle risorse;
spesso, essa influenza e determina le prestazioni di un sistema.
Ci si riferisce alle risorse per indicare altri prodotti software, hardware, ecc.
L'efficienza di un sistema può essere meglio compresa attraverso due tipologie derivate:
requisiti prestazionali e requisiti di spazio, di cui mostriamo alcuni esempi.
"Il risultato di un'invocazione di una query su di un database dovrà essere visualizzato entro
1,3 secondi dalla richiesta" (requisito prestazionale).
" Il codice eseguibile non può superare i 512 Kbyte di memoria" (requisito di capacità).
1.3.1.3 Reliability Requirements
La Dependability può essere definita come la credibilità di un sistema di calcolo, cioè il grado
22 Lo sforzo è commisurato al livello di conoscenza dell'utente.
23 Saranno considerati utenti gli operatori, utenti finale e gli utenti indiretti.
16
di fiducia che può essere ragionevolmente riposto nei servizi che esso offre. Essa include gli attributi
di Reliability, Availability, Safety e Security.
In particolare, la Reliability di un sistema è la misura del tempo continuativo in cui viene
fornito un servizio corretto
1.3.1.4 Portability Requirements
I requisiti di portabilità descrivono la capacità di un prodotto software di essere eseguito in
ambienti diversi, cosicché esso sia in grado di seguire l'evoluzione tecnologica. Naturalmente,
quando ci si riferisce ad un ambiente si tiene conto degli aspetti organizzativi e tecnologici (insieme
di hardware e software) che lo caratterizzano.
1.3.2 Process Requirements
Altra tipologia di requisiti non funzionali sono quelli di processo che, come suggerito dal
nome, descrivono i vincoli ai quali deve sottostare il processo di sviluppo di un sistema.
Essi derivano dalle politiche e dalle procedure dell'organizzazione del cliente e dello
sviluppatore.
Un process requirement può definire gli standard da adottare:
"Il processo di sviluppo ed i documenti consegnati saranno conformi al processo ed alle
strutture di documento descritte nello std ISO-ABCD-2007",
gli strumenti24 che dovranno essere adoperati:
" La gestione dei requisiti dovrà essere effettuata mediante il tool IBM Rational DOORS",
così come la documentazione da presentare:
"I report relativi alla gestione del sistema dovranno essere presentati al committente ogni 3
settimane".
Come suggerito dalla figura 2, i requisiti di processo danno vita a tre sotto-tipologie di
requisiti non funzionali: i requisiti di consegna, i requisiti di implementazione ed i requisiti degli
standard.
1.3.2.1 Requisiti di consegna
I requisiti di consegna impongono i vincoli sulle scadenze di consegna al committente, dai
report iniziali sino all'installazione e manutenzione, accompagnando tutto il processo di sviluppo del
sistema.
24 Un vincolo su di un processo di sviluppo potrebbe essere quello di adoperare particolari tool software.
17
1.3.2.2 Requisiti di implementazione
I requisiti di implementazione vincolano l'intera fase di realizzazione del sistema e possono
riguardare, ad esempio, la prescrizione dell'utilizzo di un particolare linguaggio di programmazione25
o di uno specifico tool software.
1.3.2.3 Standards Requirements
Altri vincoli che potranno essere imposti al processo di sviluppo di un sistema riguardano gli
standard che dovranno essere adottati per garantirne la conformità.
Per poter implementare
correttamente un requisito sugli standard sarà necessario tener conto delle ulteriori restrizioni
imposte dai requisiti esterni.
1.3.3 Requisiti Esterni
Così come suggerito dal nome, i requisiti esterni non dipendono da caratteristiche instrinseche
del sistema, né dal relativo processo di sviluppo. Essi si riferiscono a come deve avvenire
l'interazione tra il sistema ed altri sistemi (non appartenenti alla medesima organizzazione),
definiscono le norme che devono essere rispettate affinchè il sistema operi in maniera lecita, così
come le caratteristiche che il sistema deve mostrare per accogliere un maggior consenso da parte
degli utenti.
Un esempio di requisito esterno è il seguente:
" Il sistema non permetterà ai suoi operatori di conoscere alcuna informazione personale sui
clienti, eccetto il nome ed il numero di riferimento interno".
Si noti che in alcuni casi, a causa della loro natura, il soddisfacimento dei requisiti esterni è
difficilmente verificabile
Da quanto detto, questa classe di requisiti non funzionali è scomponibile in tre sotto-categorie:
requisiti di interoperabilità, requisiti etici e requisiti legislativi. I primi, probabilmente, ricalcano
maggiormente la natura di requisito poichè esprimono in che modo il sistema che si vuole sviluppare
svolgerà delle azioni, mentre i secondi ed i terzi pongono delle restrizioni non propriamente
tecniche.
1.4 Requisiti di dominio
I requisiti di dominio derivano dal dominio di applicazione del sistema, di cui rispecchiano le
caratteristiche ed i limiti. I requisiti di dominio possono rientrare in una delle due categorie
sopraccitate e, poichè hanno una natura specialistica, gli ingegneri del software possono trovare
25 Una organizzazione potrebbe esprimere l'esigenza che il processo software sia sviluppato con un particolare
linguaggio perchè è quello che viene adoperato di consueto e, pertanto, ben conosciuto.
18
difficoltà nel capire il modo in cui questi si rapportino agli altri requisiti di sistema. Se non
soddisfatti, essi potrebbero portare il sistema a non lavorare in maniera soddisfacente.
La loro definizione può includere una terminologia specifica del dominio e, naturalmente,
possono dar luogo a requisiti funzionali, così come vincolare requisiti pre-esistenti.
Consideriamo, ad esempio, un requisito di dominio per un sistema di controllo di frenata di un
treno [3].
La massima decelerazione che il software può imporre al veicolo per evitare, ad esempio, un
deragliamento sarà calcolata come segue:
Dtreno = Dcontrollo + Dgradiente
Si noti l'utilizzo di una terminologia specifica del dominio di applicazione, cioè di
un'equazione matematica, che presuppone la conoscenza del particolare sistema in esame. Un
errore, in tal senso, potrebbe essere quello di lasciar fuori dalla definizione del requisito tali aspetti,
comportando una errata implementazione dello stesso.
Ancora, non è raro che il committente consideri un requisito di dominio come implicito e nel
supporre che lo sviluppatore ne abbia cognizione, non lo esprime.
1.5 Considerazioni
L'attività di analisi e specifica dei requisiti 26 termina con la redazione di un documento, il
Software Requirements Specification, il quale dovrebbe mostrare caratteristiche di completezza 27 e
coerenza28(cfr. Appendice). Richiedere queste caratteristiche per un SRS relativo ad un sistema di
grandi dimensioni e complesso è un'impresa impegnativa, se non impossibile per due ragioni: la
prima riguarda la facilità nel commettere errori ed omissioni nello scrivere le specifiche dei
requisiti, la seconda riguarda le esigenze, a volte contrastanti, degli stakeholder coinvolti.
Per scovare le incongruenze in un documento di specifica dei requisiti è, quindi, necessaria
un'analisi attenta che, purtroppo, a volte viene effettuata solo a valle della consegna del prodotto
software al cliente.
I requisiti non funzionali specificano o limitano le proprietà complessive del sistema come le
prestazioni, la disponibilità, la protezione: spesso sono più critici dei singoli requisiti funzionali 29,
26 La fase di analisi e specifica dei requisiti si ritiene conclusa dopo che :
•
sia stato studiato il contesto e raccolte le esigenze del cliente,
•
siano analizzate le richieste per capirne la realizzabilità,
•
siano state negoziate le priorità di sviluppo.
27 Completezza: nella specifica dei requisiti indica che tutti i servizi richiesti dagli utenti siano definiti.
28 Coerenza: nella specifica dei requisiti indica che nella loro descrizione non debbano esserci termini contraddittori. Si
noti che nei sistemi grandi e complessi è praticamente impossibile raggiungere la coerenza e la completezza dei
requisiti.
29 Un utente, non trovando una corrispondenza tra una funzione che si aspetta il sistema fornisca, ha solitamente la
capacità di aggirare tale funzione, sopperendola con una simile. Ciò non accade nel caso di requisiti non funzionali
19
tanto da poter rendere il sistema inutilizzabile nel caso in cui non trovino corrispondenza nella
specifica. Infatti, essi possono essere vincolati a limiti di budget, alle politiche organizzative, di
sicurezza, privacy30, alla necessità di interoperabilità con altri sistemi software o hardware.
Una difficoltà che accompagna tali requisiti riguarda la loro verificabilità: infatti, è abbastanza
comune che gli utenti o i clienti si riferiscano ad essi come obiettivi generali che il sistema deve
perseguire, dando la libertà agli sviluppatori di interpretarli in maniera arbitraria. Questa potrebbe
essere una causa di malcontento da parte del commitente, una volta rilasciato il prodotto.
1.6 I requisiti utente e di sistema
I requisiti utente, essendo rivolti a personale non esperto, specificano solo il comportamento
esterno del sistema attraverso una descrizione chiara dei requisiti funzionali e non funzionali. In
effetti, in essi dovrebbero essere concentrati i servizi chiave che devono essere forniti (bisogni ed
esigenze degli utenti), in quanto un requisito che contiene troppe informazioni potrebbe risultare di
difficile comprensione per l'utente e, d'altro canto, limitare lo slancio degli sviluppatori verso
soluzioni innovative.
Dunque, nella definizione di tali requisiti, bisognrebbe evitare l'utilizzo di un linguaggio
specifico che descriva in che modo il sistema venga implementato, così come è sconsigliato
l'utilizzo del linguaggio naturale.
Infatti, mentre l'adozione del primo ci condurrebbe certamente ad un requisito che per
definizione non sarà di utente, l'utilizzo del linguaggio naturale, sebbene possa sembrare il mezzo
più immediato ai fini della comprensione dell'utente, proietterebbe sul requisito ottenuto tutte le sue
lacune (requisiti funzionali, non funzionali, obiettivi di sistema e di progettazione potrebbero non
essere chiaramente distinti, oppure si potrebbe definire in un unico requisito più requisiti).
Dunque, per la definizione dei requisiti utente 31 si potrebbe prediligere un linguaggio naturale,
corredato da diagrammi, che rappresenti il giusto compromesso tra formalismo e comprensibilità.
Essendo destinati agli specialisti, gli aspetti tecnici prendono forma nei requisiti di sistema, ai
quali potremmo pensare come versioni maggiormente dettagliate dei requisiti utente, dato che
esprimono cosa un sistema debba fare e sotto quali vincoli debba operare.
che, coinvolgendo l'intero sistema, non può essere eluso allo stesso modo.
30 I principali tipi di requisiti non funzionali sono: i requisiti di prodotto, i requisiti esterni, i requisiti organizzativi.
31 Durante questa attività, potrebbe essere interessante etichettare i requisiti utente a seconda dell'importanza che riveste
per l'utente, ad esempio come OBBLIGATORIO o DESIDERATO.
20
Illustrazione 5: Esempio di requisiti di sistema
In effetti, essi dovrebbero descrivere il comportamento esterno ed i vincoli operativi,
utilizzando notazioni più dettagliate rispetto a quelle adoperate per i requisiti utente.
Naturalmente, essendo un sistema scomponibile, anche i requisiti di sistema saranno
organizzati così da far riferimento al particolare sottosistema al quale si riferiscono: ciò è
indispensabile per il riuso.
In ultimo, ricordiamo che è consigliabile collocare i requisiti utente in sezioni del documento
di specifica separate da quelle di sistema, così da fornire al destinatario le informazioni di suo
interesse in una forma ad esso consona.
1.7 Requisiti di interfaccia
Solitamente, un sistema software viene calato in un contesto costituito da altri sistemi, con i
quali sarà necessario interagire. Naturalmente, per consentire lo scambio di informazioni tra il nuovo
ed i preesistenti sistemi bisognerà, innanzitutto32, definire in maniera precisa le interfacce di questi
ultimi.
La specifica delle interfacce dovrebbe essere espressa ad un alto livello di astrazione, senza
descrivere dettagli ed inoltre, le funzionalità offerte dalla specifica interfaccia potrebbero essere
espresse mediante un linguaggio tabellare, oppure linguaggio naturale strutturato.
Strutturare la specifica di un'interfaccia come un modello astratto è certamente anche un'azione
mirata al riuso.
Immaginiamo, ad esempio, che un'organizzazione si occupi di progettare e mettere in
commercio una famiglia di prodotti, che si interfacciano tutti con un sistema preesistente
32 La specifica delle interfacce dei sistemi preesistenti deve essere definita nella fase di analisi dei requisiti.
21
adoperando una particolare interfaccia, come un dataset. Quest'ultimo non dovrà essere definito ex
novo per ogni nuovo progetto, bensì potrà essere riusato.
Potremmo chiederci per quale motivo non preferire notazioni formali al posto di un linguaggio
naturale strutturato.
In linea di principio l'adozione di un metodo formale risulterebbe più idoneo alla specifica
delle interfacce, eliminandone le ambiguità; per contro, se la descrizione non venisse corredata da
ulteriori spiegazioni, risulterebbe incomprensibile.
Tipicamente, i tipi di interfaccia che potranno essere specificate in un documento dei requisiti
sono: le interfacce procedurali, strutture dati e rappresentazione dei dati.
Le interfacce procedurali riguardano le funzionalità che programmi o sottosistemi preesistenti
offriranno richiamando le procedure di interfaccia.
Le interfacce dei dati33 descrivono le strutture dati che vengono scambiate tra sottosistemi,
mentre
le interfacce di rappresentazione34 descrivono specifici pattern utilizzati per descrivere i dati di
un sottosistema preesistente.
1.8 La scrittura dei requisiti
Sebbene i requisiti utente possano essere espressi in un linguaggio naturale 35, non vale lo
stesso per i requisiti di sistema, i quali necessitano di notazioni più dettagliate e specifiche.
Infatti, l'utilizzo del linguaggio naturale richiede che ogni termine adoperato per descrivere un
requisito abbia un' accezione comune a colui che redige il documento e all' utente.
Un chiaro esempio dell'ambiguità del linguaggio naturale è fornito dallo studioso Jackson
(1995):
"Shoes must be worn"
"Dogs must be carried"
"Le scarpe devono essere indossate"
" I cani devono essere portati"
In effetti, entrambi i verbi adoperati (to wear, to carry) si prestano ad un accezione comune:
portare, pertanto il significato di ciascuna frase può essere equivocato.
In definitiva, il linguaggio naturale risulta essere eccessivamente flessibile se utilizzato nella
33 Per la descrizione delle interfacce dei dati vengono preferiti i modelli grafici.
34 Le interfacce di rappresentazione dei dati come la disposizione di bit sono molto comuni nei sistemi real time
integrati ed il modo più consono per descriverle è quello di adoperare diagrammi delle strutture corredate di
spiegazioni delle funzioni espletate da ogni gruppo di bit.
35 Nella descrizione dei requisiti utente in linguaggio naturale possono sorgere dei problemi, quali:
•
mancanza di chiarezza: alcuni termini potrebbero prestarsi a più di un'interpretazione generando
ambiguità;
•
confusione dei requisiti: potrebbe non esserci una chiara distinzione tra requisiti funzionali, non
funzionali, informazioni di progettazione, obiettivi di sistema;
•
mescolanza dei requisiti: in un requisito potrebbero essere accorpati più requisiti.
22
specifica dei requisiti. Oltre a questa caratteristica, si è riscontrato che l'adozione di tale metodo di
scrittura infici la tracciabilità e una volta definiti, i requisiti verranno collezionati in un documento
strutturato che, a vari livelli di dettaglio, dovrà essere completo e coerente.
Dunque, ottenere un buon documento di specifica richiede che i requisiti in esso contenuti
siano
descritti in modo uniforme e, per fare ciò, diviene molto utile adoperare delle linee guida che
vengono indicate in letteratura.stessa dei requisiti, nonchè la possibilità di scovare requisiti correlati
al fine di valutare l'impatto di un possibile cambiamento.
Per far fronte all'esigenza di adoperare un linguaggio idoneo, la letteratura propone l'uso del
linguaggio
naturale
strutturato,
eventualmente
corredato
da
semplici
modelli
grafici.
L'idea di base è quella di limitare la libertà 36 dell'addetto alla descrizione dei requisiti, così da
forzarlo a scrivere ciascun requisito secondo uno "schema" che
garantisca l'uniformità delle
specifiche, senza sacrificare l'espressività e la comprensibilità peculiari del linguaggio naturale.
Una volta definiti, i requisiti verranno collezionati in un documento strutturato che, a vari
livelli di dettaglio, dovrà essere completo e coerente.
Dunque, ottenere un buon documento di specifica richiede che i requisiti in esso contenuti
siano descritti in modo uniforme; per fare ciò, risulta molto utile adoperare le linee guida riportate in
letteratura.
Il punto da cui partire è quello di scegliere un formato standard ed adoperarlo per ciascun
requisito, in cui servendosi del linguaggio naturale strutturato, si esprimano le azioni attraverso la
forma "dovrà" per i requisiti obbligatori e la forma "dovrebbe" per i requisiti desiderabili.
Inoltre, bisognerà evidenziare i concetti fondamentali contenuti nel requisito, evitando, nel
caso di requisiti utente, termini troppo tecnici.
Si può, ad esempio, adoperare un modulo standard costituito dai seguenti campi:
• Funzione: indicazione della funzione che dovrà o dovrebbe essere svolta o, se vogliamo, il
nome della funzione;
• Descrizione: descrizione sintetica della funzione che dovrà o dovrebbe essere svolta;
• Input: input della funzione;
• Sorgente: entità dalla quale arriva l'input;
• Output: output della funzione;
36 Il linguaggio naturale strutturato limita la terminologia che può essere adoperata attraverso l'uso di modelli per
specificare i requisiti di sistema. Inoltre, può includere costrutti di controllo derivati dai linguaggi di
programmazione, così come schemi grafici per suddividere le specifiche. In pratica vengono usati costrutti di
controllo tiipici di linguaggi di programmazione(if-then-else, while…), forms (moduli predefiniti: nome e
descrizione della funzione, input, output, pre-condizioni, ecc.)
23
• Destinazione: entità alla quale perverrà l'output;
• Azione: descrizione dettagliata delle azioni che dovranno o dovrebbero essere svolte.
È importante che il dettaglio si riferisca a COSA debba o dovrebbe essere fatto, non al COME,
quindi alle scelte implementative;
• Richiede: indicazione delle azioni pregresse all'esecuzione della funzione corrente;
• Pre-condizioni: indicazione delle condizioni che debbano o dovrebbero sussistere prima
dell'esecuzione della funzione corrente;
• Postcondizioni: indicazione delle condizioni che debbano o dovrebbero verificarsi dopo
l'esecuzione della funzione corrente;
• Effetti collaterali: indicazione degli effetti che l'adempimento della funzione possa
comportare.
Le voci presenti nel modulo appena mostrato rappresentano solo un esempio dal quale
prendere spunto per definire uno schema di strutturazione che possa rispecchiare le specifiche
esigenze. Infatti, è possibile eliminare alcune voci o aggiungere tabelle o modelli grafici del sistema,
così da pervenire ad un formato più semplice o ad uno più ricco di informazioni.Una breve linea
guida su come scrivere i requisiti è presentata in Appendice
1.9 Documento dei requisiti
La fase di analisi e specifica termina con la redazione del Documento di Specifica dei
Requisiti Software (SRS), che rappresenta una dichiarazione ufficiale di ciò che gli sviluppatori del
sistema dovrebbero implementare.
Tabella 1: Destinatari del documento dei requisiti
Clienti
Specificano i requisiti;
Validano i requisiti se essi rispecchiano le loro esigenze;
Richiedono cambiamenti.
Manager
Usano il documento dei requisiti per pianificare l'offerta
del sistema ed il suo processo di sviluppo
Ingegneri di sistema
Adoperano i requisiti per capire le caratteristiche del
sistema da sviluppare
Ingegneri del test di sistema
Utilizzano i requisiti per sviluppare i test di controllo del
sistema.
Ingegneri della manutenzione del sistema
Usano i requisiti per comprendere la struttura del sistema e
le interazioni tra i suoi componenti
In effetti, si potrebbe pensare all'SRS come un contratto tra due contraenti (l'organizzazione
che si aggiudica il lavoro ed il committente), in quanto esso rappresenta un compromesso tra la
24
descrizione delle funzionalità che devono essere fornite al cliente, la descrizione dettagliata dei
requisiti che devono essere fornite agli sviluppatori e ai tester, nonché informazioni inerenti alla
evoluzione del sistema.
In ogni caso, il livello di dettaglio dell'SRS dipende dal particolare sistema in esame e dal
processo di sviluppo adottato37.
Nel corso degli ultimi decenni sono state fornite delle linee guida per la redazione di un
documento di specifica dei requisiti software, ne è un esempio notevole lo standard IEEE/ANSI
830-1998 che, sebbene rappresenti una struttura troppo generale per essere adottata in qualunque
contesto, offre ottimi spunti per redigere un documento di buona qualità.
Tabella 2: Protitype SRS outline
Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms and
abbreviations
1.4 References
1.5 Overview
2. Overall description
2.1 Product prospective
2.2 Product functions
2.3 User characteristics
2.4 Assumption and dependencies
3. Specific Requirements
Appendixes
Index
Si noti, però, che la definizione dei requisiti nella fase iniziale del progetto consente sì di
definire un accordo tra le parti in causa, ma non dà luogo ad un "congelamento delle specifiche".
Infatti, anche dopo la stesura del documento di specifica, durante le attività di realizzazione del
prodotto, i requisiti possono ancora cambiare a causa di diversi fattori ed anche se l'indagine iniziale
sia stata ritenuta esaustiva. Accade non di rado che nuove esigenze del cliente, cambiamenti del
mercato, nuove norme determinino un mutamento nei requisiti prcedentemente concordati.
37 Si noti che, quando il prodotto software è parte di un progetto più ampio, in cui è prevista l'interazione tra sistemi
hardware e software, bisogna definire i requisiti ad un livello di maggior dettaglio. Ciò vuol dire che i documenti
saranno più prolissi, poichè dovranno includere, se non tutti, la maggior parte delle sezioni mostrate nello standard
IEEE/ANSI 830-1998. In tali casi bisogna corredare l'SRS di un sommario completo ed un indice analitico, così da
rendere agevole ai lettori trovarvi le informazioni di cui necessitano.
25
Questa considerazione spinge taluni a pensare che, in effetti, il documento di specifica dei
requisiti sia obsoleto già al momento della sua stesura.
Per questo motivo, si potrebbe pensare di strutturare un documento dei requisiti sulla scorta
dello standard IEEE, ma con sezioni che tengano conto dell'evoluzione prevista del sistema.
Tabella 3: La struttura di un documento dei requisiti
Prefazione
Dovrebbe definire i potenziali lettori del documento e
descrivere la storia della corrente revisione, includendo
una motivazione per la creazione di una nuova versione ed
un riassunto delle modifiche apportate in ciascuna versione
Introduzione
Dovrebbe descrivere le necessità del sistema, descrivere in
breve le funzioni e spiegare come interagirà con gli altri
sistemi; descrivere come il sistema si inserisce all'interno
degli obiettivi strategici e aziendali dell'organizzazione che
ha commissionato il software
Glossario
Dovrebbe definire i termini tecnici utilizzati nel
documento. Non si dovrebbe presupporre una particolare
esperienza e competenza del lettore.
Definizione dei requisiti utente
Dovrebbe descrivere i servizi forniti agli utenti ed i
requisiti di sistema non funzionali. Per questa descrizione
si può usare il linguaggio naturale, diagrammi, o altre
notazioni che siano comprensibili al committente. Bisogna
specificare gli standard del prodotto e della lavorazione
che devono essere applicati.
Architettura del sistema
Descrizione di alto livello dell'architettura del sistema
prevista, mostrando la distribuzione delle funzioni nei vari
moduli del sistema. Si dovrebbero evidenziare i
componenti strutturali che sono stati riutilizzati
Specifiche dei requisiti di sistema
Descrizione dettagliata dei requisiti funzionali e non
funzionali. Se necessario, possono essere aggiunti ulteriori
dettagli ai requisiti non funzionali (ad esempio, le
interfacce con altri sistemi).
Modelli del sistema
Dovrebbe delineare uno o più modelli del sistema,
mostrando le relazioni tra i componenti del sistema e
l'ambiente. Possono essere diagrammi di flusso, modelli
semantici, ecc.
Evoluzione del sistema
Dovrebbe indicare i presupposti su cui si basa il sistema ed
indicare le modifiche previste, dovute all'evoluzione
dell'hardware ed ai cambiamenti delle necessità dell'utente.
Appendici
Dovrebbe fornire informazioni dettagliate relative
all'applicazione che si sta sviluppando, ad esempio le
descrizioni del database o dell'hardware. I requisiti
hardware devono definire le configurazioni minime ed
ottimali per il sistema. I requisiti del database devono
definire l'organizzazione logica delle informazioni usate
dal sistema e le relazioni tra queste.
Indice
Possono essere inclusi diversi indice nel documento: oltre
ad un indice alfabetico, potrebbe esservi un indice dei
diagrammi, delle funzioni e così via.
26
1.10 La qualità del software
Per qualità38 di un prodotto si intende la sua aderenza ai requisiti per esso richiesti, tale da
apportare un buon livello di soddisfazione in coloro che ne usuifruiranno.
Naturalmente, questa definizione si mantiene valida per il prodotto software, per il quale è
fondamentale importanza determinarne il corretto funzionamento e l' utilizzo adeguato da parte degli
utenti.
Per poter stimare la qualità del prodotto software è necessario effettuare un insieme di
valutazioni e, per fare ciò, occorrerà definire delle caratteristiche e metriche che consentano di
calcolare in maniera quanto più possibile oggettiva e precisa39 il suo livello di qualità.
Cerchiamo di comprendere cosa si intende per misurazione e dove si colloca questo concetto
nell'ambito della discussione a venire.
La misurazione è il processo di assegnazione oggettiva di un numero (o simbolo) ad una
entità del mondo reale, descrivendole secondo regole defintite, al fine di caratterizzarne uno
specifico attributo [6].
Per effettuare una misurazione è necessario aver compreso con chiarezza quali siano gli
attributi da misurare e quali entità posseggano tali attributi. Si parla, in tal caso, di comprensione
empirica. Queste definizioni si adattano al contesto in esame in considerazione del fatto che ogni
caratteristica rilevante del prodotto sarà misurata applicando metriche adeguate e verrà valutata
secondo intervalli di accettabilità e valori di soglia stabiliti.
In effetti, i criteri secondo i quali viene stimata la qualità del software sono di facile
comprensione.
Di seguito riportiamo una lista delle principali caratteristiche che rendono un software di
qualità:
• l'adeguatezza delle funzionalità alle necessità degli utenti;
• la facilità con cui il prodotto può essere installato e personalizzato in ambienti e piattaforme
differenti;
• le prestazioni fornite sia in termini di tempi di risposta che di utilizzo delle risorse;
• l'affidabilità;
• la capacità di evolvere nel tempo, così da facilitare le operazioni di manutenzione del
prodotto;
38 L'ISO 8402 definisce la qualità come "l'abilità a soddisfare le necessità degli utenti, esplicite ed implicite".
39 Si noti che le misure che riguardano il software non sono assolute come quelle delle scienze fisiche [5].
27
• il livello di sicurezza garantito rispetto agli accessi non autorizzati;
• la sicurezza dei dati, sicurezza fisica delle persone e dei beni.
1.10.1 Lo standard ISO
La presenza sempre più massiva di software nei servizi che quotidianamente ci vengono offerti
è chiaramente proporzionale all'esigenza di controllarne la qualità. Allo scopo, nel corso degli ultimi
decenni sono state emesse delle norme a supporto, tra le quali quelle della serie ISO 900040 che,
nella versione Vision 2000, propone un modello unico, adattabile a diverse tipologie aziendali (in
sostituzione alla vecchia suddivisione nelle tre norme ISO 9001, 9002, 9003.
Tra le norme di maggior rilevanza, riveste il ruolo principale il modello ISO/IEC 912641.
In esso si identificano quattro sezioni:
• Parte 1: Modello della qualità del software
• Parte 2: Metriche per la qualità esterna
• Parte 3: Metriche per la qualità interna
• Parte 4: Metriche per la qualità in uso
a ciascuna delle quali è associato un insieme di attributi.
Di seguito riportiamo una tabella riassuntiva delle caratteristiche e attributi del software
indicate dal modello.
40 La serie ISO 9000 venne pubblicata per la prima volta nel 1987, la seconda edizione venne invece rilasciata nel
1994, con piccole modifiche rispetto alla precedente.
41 Le norme sono emesse dall'ISO, l'organismo internazionale di standardizzazione (International Organization for
Standardization), al quale aderiscono moltissimi paesi al mondo e collaborano un gran numero di enti nazionalai,
anche non governativi. Tra questi ultimi, compare l'IEC, l'organo internazionale che definisce gli standard nel settore
delle tecnologie dell'informazione e comunicazione (International Electrotechnical Commission).
28
Illustrazione 6: Modello di qualità ISO/IEC 9126
L'approccio dello standard può essere rappresentato da una "catena di qualità", che mette in
risalto, attraverso le influenze/dipendenze, che la qualità di un prodotto software dipende dalla
maturità dell'organizzazione che lo produce, intesa come competenza delle persone, efficacia dei
processi ed utilizzo di metodi, tecniche e strumenti adeguati .
29
Illustrazione 7: Valutazione della maturità del processo
Quelli che vengono valutati, al fine di misurare la qualità del prodotto software, sono i requisiti
non funzionali, noti anche come "requisiti di qualità" che si esplicano nei fattori di qualità interni,
esterni ed in uso. I primi, detti anche fattori di Processo, indicano la qualità del software percepita
dagli sviluppatori; i secondi, noti anche come fattori di Prodotto, si riferiscono alla qualità percepita
dagli utenti; i terzi rappresentano l'efficacia, l'efficienza e la soddisfazione con cui determinati utenti
raggiungono specifici obiettivi in particolari ambienti [8]. Questi ultimi sono strettamente dipendenti
dal contesto, dalla capacità di percezione degli utenti del sistema, dunque non rappresentano fattori
assoluti di qualità.
Dunque, la catena di qualità indica che la qualità del processo di sviluppo influenza la qualità
interna prodotto software realizzato, la quale, a sua volta, influenza la qualità esterna del prodotto
che, infine, influenza la qualità del prodotto in uso. Queste relazioni implicano la necessità di
definire gli attributi che caratterizzano ogni tipologia di fattori di qualità e di individuare le metriche
per misurarne il livello.
Rivolgendo la nostra attenzione alla figura 7, percorrendola da sinistra verso destra, possiamo
dedurre che la valutazione della maturità del processo, nell'ottica del suo miglioramento, è un
strumento importante per ottenere un prodotto qualitativamente soddisfacente. Allo stesso modo, la
valutazione ed il miglioramento della qualità del prodotto conducono al miglioramento della qualità
in uso.
Viceversa, percorrendo la figura da destra verso sinistra, si evince che la valutazione della
qualità in uso rappresenta un vero e proprio feedback per migliorare il prodotto. Analogamente, la
valutazione della qualità di quest'ultimo (facciamo riferimento alle qualità interne ed esterne del
software) rappesenta un riscontro volto al miglioramento del processo.
Lo sviluppo del software è un'a attività basata sulla creatività e su concetti tecnici, in cui la
componente umana è la principale chiave di lettura. La definizione dei processi consente di
standardizzare le operazioni, prevede dei risultati che saranno misurabili e migliorabili.
30
Inoltre, l'adozione di strumenti a supporto consente di aumentare la produttività e la qualità.
Pertanto, la giusta combinazione di questi aspetti determinano il grado di maturità di
un'organizzazione software e, da ciò, il livello di qualità del software prodotto.
La maturità di un'organizzazione è determinata:
• dalla competenza ed esperienza delle persone;
• dalla maurità dei processi adoperati per lo sviluppo del software;
• dall'utilizzo di metriche, metodi, tecniche e strumenti a supporto delle attività di sviluppo,
che siano utili ed efficaci.
Ciascuna persona coinvolta in un progetto software contribuisce in una certa misura alla sua
qualità.
Le aree di competenza che hanno un impatto diretto nella gestione della qualità del software
sono:
• L'assicurazione della qualità: il controllo e la verifica dell'aderenza ai processi, del livello
qualitativo della conduzione del progetto e, naturalmente, di qullo raggiunto dal prodotto sviluppato;
• Gestione dei requisiti: la raccolta, l'analisi, la selezione, la documentazione la gestione delle
modifiche, la tracciabilità dei requisiti. In sintesi, la qualità del prodotto finale dipende dalla qualità
con cui i requisiti sono raccolti e interpretati, sviluppati, verificati e validati.
Usare strumenti e metodi standard per la gestione dei requisiti permette di aumentare
l’efficacia e l’efficienza del processo, migliorando la capacità di fissare gli opportuni traguardi per
l’organizzazione e riducendo l’impatto dei cambiamenti richiesti in corso d’opera sul disegno
generale.
• Ingegnerizzazione del software: la progettazione, lo sviluppo ed il test;
• La Gestione del progetto: pianificazione e controllo del progetto;
• La gestione della configurazione;
• le misurazioni: la definizione delle metriche da usare in base agli obiettivi che si vogliono
raggiungere, le misurazioni e le valutazioni dei risultati.
31
Capitolo 2
Requirements Engineering
Illustrazione 8: Attività dell'ingegneria dei requisiti
2.1 I rischi
Il rischio rappresenta la possibilità del verificarsi di una condizione svantaggiosa in relazione
alle attese ed alla scala dei valori dei soggetti coinvolti e che, una volta presentatasi, possa creare
loro dei danni.
Per la sua natura, la probabilità associata ad un rischio deve essere misurata.
La valutazione del potenziale danno associato al verificarsi di un evento, pertanto, parte dalla
comprensione della scala dei valori e del risultato atteso dagli stakeholder42 di un progetto.
Nell'ambito di un progetto, un rischio rappresenta la probabilità del non raggiungimento degli
obiettivi prefissati in termini di quantità di prodotti (numero e tipo di funzionalità, dati), di qualità
dei risultati (requisiti non funzionali), di costo e durata delle attività.
Dunque, tra le principali cause di insuccesso di un progetto emergono l'indeterminatezza,
l'ambiguità, la genericità (intesa come scarsa qualità della formulazione), la mutevolezza degli
obiettivi progettuali.
Infatti, poichè dietro una formulazione ambigua di un obiettivo possono nascondersi una
moltitudine di differenti formulazioni specifiche, essa difficilmente potrà prestarsi da guida per il
lavoro a valle. Pertanto, è necessario che ciascun obiettivo sia ben formulato, condiviso e misurabile
42 Nella corretta definizione dei requisiti, è fondamentale riconoscere e coinvolgere fin dalle
prime fasi gli stakeholder che trarranno vantaggi o svantaggi dall’esito progettuale. Tipici stakeholder da
considerare sono i committenti, gli utilizzatori diretti ed
indiretti, i partecipanti allo sviluppo, i rappresentanti dell’esercizio dei sistemi, il management ed i regolatori
esterni (autorità di vario tipo non partecipanti al progetto ma interessate al
rispetto di vincoli esterni predeterminati).
32
dalle parti interessate, cioè clienti e produttore.
Capita spesso che gruppi di progetto con esperienza e capacità tecnologiche, non presentino la
stessa attitudine a mettere a fuoco gli obiettivi da perseguire, calandoli nel contesto reale.
Questo atteggiamento è dovuto alla scarsa attenzione dedicata alla fase iniziale del progetto e
comporta un ulteriore investimento di risorse per revisionare, testare e correggere gli errori propagati
sul prodotto finale. Infatti, porre l'accento sulle attività, confondendole con i risultati, porta spesso a
trascurare soluzioni alternative meno immediate, ma talvolta più efficaci.
Causa di scarsa qualità è la difficoltà di far condividere gli obiettivi tra stakeholder con
interessi talvolta divergenti, nonchè le errate motivazioni che spingono il gruppo incaricato del
progetto a concentrarsi sullo strumento da produrre, perdendone di vista lo scopo per cui viene
richiesto.
Illustrazione 9: Evasione dei progetti IT nell'anno 2009 secondo una stima dello
Standish Group
Alcuni studi hanno mostrato che la percentuale di progetti falliti, o che hanno richiesto risorse
maggiori rispetto a quelle stanziate, sia elevatissima.
In questo scenario, un peso importate è stato attribuito agli errori nei requisiti: come è noto, la
rimozione di un errore commesso durante la fase di definizione può costare fino a 20 volte di più di
uno commesso durante la fase di realizzazione del prodotto.
Inoltre, alcune stime mostrano che un gran numero di progetti falliscono per erroti commessi
nella fase di definizione dei requisiti e ciò ha portato all'introduzione di una ben definita disciplina:
l'Ingegneria dei Requisiti.
33
Illustrazione 10: Principali cause di fallimento di un progetto
2.2 L'ingegneria dei requisiti: definizioni ed attività
"Requirements engineering is the branch of software engineering concerned with the realworld goals for, functions of, and constraints on software systems. It is also concerned with the
relationship of these factors to precise specifications of software behaviour, and to their evolution
over time and across software families" [9].
L'ingegneria dei requisiti è una sezione fondamentale del System Engineering e, come tale, è
rappresentata da un vasto insieme di attività volte al trattamento sistematico dei requisiti.
Tale disciplina non rappresenta un processo a sé stante, bensì è parte integrante del processo di
sviluppo [10]; essa vede la sua esplicazione nella "Gestione dei requisiti", che si espanderà a sua
volta nelle attività di studio di fattibilità, elicitazione, analisi, specifica e validazione.
34
Illustrazione 11: Modello a spirale dell'Ingegneria dei Requisiti
Prima di procedere ad una definizione più dettagliata delle attività coinvolte nell'ingegneria dei
requisiti, si esprimerà breve considerazione sul modello mostrato in figura 11.
La spirale indica la ciclicità delle attività svolte, in cui le risorse impiegate (in termini di lavoro
e tempo profusi) in ciascuna azione sono commisurati al particolare sistema su cui si sta lavorando
ed allo stato di avanzamento del processo. Pertanto:
• Nello stadio iniziale del processo, rappresentato dalla parte più interna della spirale, sarà
impiegato uno sforzo maggiore per la deduzione dei requisiti di alto livello aziendali, non funzionali
ed i requisiti utente.
• Nello stadio finale del processo, rappresentato dalla parte più esterna della spirale, i maggiori
sforzi saranno indirizzati alle azioni peculiari dell'ingegneria dei requisiti e, chiaramente alla
modellazione del sistema.
Si noti che il modello mostrato risulta flessibile 43 per diversi contesti e, in particolar modo,
laddove i requisiti vengono definiti a mano a mano con un livello di dettaglio maggiore, ovvero
attraverso livelli di astrazione differenti.
Descriviamo brevemente ognuna di tali attività, al fine di meglio comprendere in cosa consista
una adeguata gestione dei requisiti.
Lo studio di fattibilità consiste nel valutare se le necessità del cliente possano essere
soddisfatte con le risorse disponibili.
La Requirements Elicitation (elicitazione) consiste nella fase di comprensione e raccolta dei
requisiti provenienti dagli stakeholder principali del sistema. In questa fase bisognerà tener conto
43 Il modello a spirale mostrato non è rigidamente fissato, bensì consente di introdurre nuovi giri alla spirale, così di
uscirvi qualora l'attività di raccolta dei requisiti utente sia terminata.
35
delle esigenze mutevoli del customer, il quale, durante la vita del prodotto, potrebbe richiedere
modifiche a requisiti precedentemente valutati oppure chiederne di nuovi.
Nella System Requirements Analysis si effettua una trasformazione dei requisiti richiesti dagli
stakeholder in requisiti tecnici del sistema, i quali fungeranno da guida per il progetto del sistema
stesso. Tale fase, dunque, consiste nello stabilire quali requisiti debbano essere soddisfatti,
nell'assegnazione di una priorità ad essi [11], nonchè nella definizione di una strategia generale che
ne consenta il soddisfacimento.
L'attività di Requirements Specification consiste nel documentare in maniera adeguata i
requisiti derivanti dalle fasi precedenti, così da comunicarli agli stakeholder ed ai progettisti.
L'ultima fase consta delle attività di Verifica e Validazione: la prima riguarda la valutazione
della qualità dei requisiti, la seconda consiste nell'accertarsi che i requisiti specificati rispecchino
effettivamente i bisognI degli stakeholder.
Lo spettro delle attività svolte nell'ambito dell'ingegneria dei requisiti è molto ampio 44 e ciò
rende difficile fornire una definizione precisa di tale disciplina. Certamente, la definizione dei
requisiti di un sistema parte dal concetto di "obiettivo", mentre l'attività cardine è il modo in cui si
passa dall'obiettivo alla specifica del corrispondente sistema software.
Quanto detto è suffragato da una seconda e più tecnica definizione della disciplina:
“Requirements engineering is concerned with the identification of the goals to be achieved by
the envisioned system, the operationalization of such goals into services and constraints, and the
assignment of responsibilities for the resulting requirements to agents such as humans, devices and
software”[12].
che sposta l'interesse sulla definizione ed analisi delle motivazione e degli obiettivi della
specifica dei requisiti stessa; da qui la definizione di approccio "goal-oriented".
Per adottare questo approccio vi saranno delle azioni prelimiari da compiere e che riguardano
l'individuazione degli obiettivi che il sistema dovrà raggiungere. Naturalmente, la definizione
formale dei goal prende vita solo dopo una serie di raffinamenti 45 degli aspetti considerati in prima
battuta e, darà luogo ad obiettivi di natura e priorità differenti.
Sulla scorta di quanto appena detto, gli obiettivi rappresentano sia il punto di partenza che di
arrivo delle attività svolte, fungendo da meccanismo per l'individuazione, l'organizzazione dei
requisiti e, chiaramente, un mezzo per giustificare la presenza degli specifici requisiti in un sistema
44 Requirements Engineering: the subset of system engineering concerned with discovering, developing, tracing,
analyzing, qualifying, communicating and managing requierements that define the system at successive levels of
abstraction [13].
45 Sarà possibile raffinare gli obiettivi esplorando diverse soluzioni alternative. Infatti, una volta che sia stato
selezionato un insieme di alternative per il raggiungimento dell'obiettivo, sarà possibile elaborarle nelle fasi
successive per renderle complete e precise.
36
software.
In linea con questo approccio:
• La fase di acquisizione dei requisiti partirà dalla comprensione degli obiettivi che lo
stakeholder richiederà per il sistema: ciascuno di essi dovrà essere motivato, così come
dovranno essere definite e valutate le modalità alternative per raggiungerlo.
• Una volta stabiliti i requisiti, essi dovranno essere messi in relazione al contesto
organizzativo, cioè il sistema reale in cui essi dovranno essere calati per soddisfare le
esigenze e vincoli (ovvero obiettivi ) di contesto46.
• Si noti che l'analisi basata sugli obiettivi apporta benefici anche in termini di chiarezza dei
requisiti che potrebbero mancare di tale caratteristica.
• La tracciabilità dei requisiti evidenzierà chi li ha definiti e le motivazioni, i collegamenti tra
i requisiti in relazione tra loro;
•
La gestione dei conflitti consisterà nell' individuare e gestire gli obiettivi che hanno dato
luogo ai requisiti discordanti47 già nella fase iniziale del processo (e prima dell'attività di
design).
A partire dagli obiettivi degli stakeholder, si potranno esplorare soluzioni alternative di design
per il loro soddisfacimento: esse dovranno essere valutate in base all'importanza, ai costi ed
all'efficacia.
• Già prima che l'applicazione venga sviluppata sarà possibile valutarne la qualità della
specifica, verificando che soddisfi gli obiettivi determinati nella fase di analisi.
• Il cambiamento dei requisiti degli utenti e degli stakeholder può essere gestito definendo
nuovi obiettivi o modificando quelli esistenti. Si noti che la gestione dei cambiamenti al
livello degli obiettivi consente una più agevole gestione dei cambiamenti dei requisiti.
• Definire gli obiettivi, la tracciabilità tra essi ed i requisiti e con il design offre una maggiore
spinta verso il riuso. Infatti, lo sforzo iniziale profuso per la comprensione e la
formalizzazione degli obiettivi di un prodotto, potrebbe essere capitalizzato, sfruttando gli
aspetti comuni a prodotti simili. Naturalmente, ciò sarà possibile a patto che gli obiettivi
siano adeguatamente formalizzati, scomposti in sotto-obiettivi e tradotti in requisiti.
Nonostante la gestione dei requisiti sia decisiva nelle fasi di vita iniziali di un progetto, essa
rappresenta un processo che accompagna il progetto durante tutta la sua durata.
Del resto, mano a mano che ci si addentra nel ciclo di vita, anche i requisiti subiscono
46 Si pensi a norme interne, obiettivi di business, ecc.
47 Stakeholders may have different viewpoints on the systems and conflicting interests[14].
37
un'evoluzione, arricchendosi e specializzandosi fino, talvolta, ad indirizzarsi verso strade
non
valutate inizialmente. Essi potranno affiancarsi a nuovi requisiti, potranno essere modificati od
eliminati.
Dunque, i requisiti rappresentano il fattore che maggiormente potrà incidere sulle risorse
necessarie allo sviluppo del progetto, ed è per questo motivo che potremmo pensare al Requirements
Management come ad un processo con carattere sia tecnico che gestionale.
Infatti, se è vero che la modifica dei requisiti comporti, tipicamente, una modifica degli aspetti
tecnici legati al sistema, presumibilmente, affinchè il progetto venga portato a termine, dovrà essere
rivista anche l'assegnazione delle risorse da stanziare.
Riguardo la redazione della documentazione dei requisiti, può rilevarsi utile l'utilizzo di tool
software capaci di automatizzare le parti più ripetitive dell'attività, consentendo raggruppamenti,
estrazioni ed analisi di tracciabilità dei requisiti e di impatto dei cambiamenti.
Questi ultimi aspetti, infatti, mostrando le interrelazioni tra requisiti, consentiranno
inizialmente l'individuazione di eventuali inconsistenze e ridondanze, poi la loro risoluzione, così da
evitarne l'influenza nella fase di realizzazione del prodotto.
In definitiva, un' adeguata gestione dei requisiti è la base per abbattere la probabilità di rischio
associati ad un progetto, favorendo il riuso e la qualità.
Illustrazione 12: Le fasi del processso di ingegneria dei requisiti
2.3 Studio di fattibilità
L'azione da intraprendere prima di stabilire se un nuovo sistema sia sviluppabile è quello di
operare uno studio di fattibilità.
Le informazioni preliminari di cui si dovrà disporre saranno, dunque, i requisiti aziendali, una
38
descrizione di massima del sistema che dovrebbe essere sviluppato e un'indicazione di come esso
contribuirà al raggiungimento degli obiettivi aziendali.
Lo studio di fattibilità consiste, fondamentalmente, nell'identificare e porre al committente una
serie di quesiti in merito all'utilizzo che si vuole fare dello strumento commissionato, dall'impatto
positivo che ci si aspetta abbia sull'organizzazione, di quante e quali risorse debbano essere profuse
allo scopo.
Ed infatti, non di rado capita che un'organizzazione richieda un sistema che poi non riesca a
contribuire ai processi aziendali. Ciò può capitare a causa di requisiti espressi in maniera confusa,
oppure perchè vengono interposti ostacoli all'utilizzo proficuo dello strumento.
Dunque, i candidati a rispondere a tali domande dovrebbero essere: i manager dei dipartimenti
in cui lo strumento sarebbe adoperato,
gli ingegneri del software che mostreranno una certa
conoscenza del tipo di sistema commissionato, nonchè gli utenti finali, ovvero tutte persone
interessate, competenti e direttamente coinvolte nel progetto proposto.
Seguendo questa strada, l'azione dovrebbe condurre, passando per la raccolta e la valutazione
delle risposte fornite, all'output: il report dello studio di fattibilità. Oltre all'esito dello studio, in esso
potranno essere proposti cambiamenti negli scopi e nelle risorse allocate, nonchè nuovi spunti
(eventuali requisiti di alto livello) su cui lavorare.
2.4 Elicitazione ed analisi dei requisiti
Nella prima parte di questo capitolo è stata rivolta particolare attenzione al concetto di
obiettivo, come punto focale attorno al quale sviluppare tutta la successiva discussione.
Pertanto, si provi a ritornare su tali concetti per comprendere in che modo gli obiettivi del
cliente vadano mano a mano a trasformarsi in un prodotto finito48.
Il primo passo da compiere, in tal senso, è certamente l'apertura verso gli obiettivi che debbano
essere raggiunti e la valutazione dei vincoli ai quali essi sono sottoposti.
L'attività di elicitazione dei requisiti mira a circoscrivere i confini del sistema da sviluppare.
Pertanto, al fine di reperire le informazioni necessarie per la corretta ed esaustiva comprensione del
problema al quale fornire la soluzione software, bisognerà innanzitutto identificare gli stakeholder 49
del progetto.
Il ruolo che ciascuno stakeholder riveste in un progetto può essere molto diverso da quello di
un altro e ciò proprio in considerazione del fatto che ogni persona, o gruppo, potrà essere influenzato
in maniera differente dal sistema.
48 In effetti, se si pensasse agli interventi correttivi, piuttosto che di manutenzione, ci renderemmo conto che il prodotto
software non possa essere considerato un prodotto finito.
49 Uno stakeholder rappresenta un soggetto che, direttamente o indirettamente, sarà influenzato dal sistema in esame.
39
Di conseguenza, la fase di deduzione e comprensione dei requisiti può rivelarsi
particolarmente impegnativa, poichè gli aspetti trattati saranno quelli specifici del dominio di
applicazione, con il quale l'ingegnere del software potrebbe non avere familiarità.
Ancora, capita non di rado, che gli stakeholder non riescano ad esprimere in modo chiaro le
proprie esigenze, che vi siano conflitti tra i requisiti dichiarati dalle diverse figure, oppure di trovarsi
di fronte ad un ambiente dinamico.
Tutti gli aspetti sopraccitati convincono del fatto che, durante questa fase, sia indispendabile
avvalersi del supporto dei committenti, con i quali potrebbero nascere incomprensioni dovute
all'utilizzo da parte di questi ultimi di linguaggi troppo tecnici e punti di vista, a volte, divergenti.
D'altro canto, confrontarsi con un ambiente dinamico, in cui i requisiti cambiano rapidamente,
non consente la definizione precisa del loro numero e delle funzionalità che esprimono.
L'evoluzione, così come una cattiva comunicazione tra l'ingegnere del software ed i
committenti, può comportare una revisione nell'espressione e/o nel contenuto di un requisito;
dunque, terminato lo studio di fattibilità, le successive fasi possono richiamarsi tra loro durante tutto
il processo.
L'obiettivo di questa fase è, infatti, a fronte di una buona comprensione del dominio in cui sarà
sviluppato un sistema software, la definizione dei requisiti che esso debba essere in grado di
soddisfare.
In primo luogo, una profonda comprensione del dominio in cui il sistema opererà aiuterà anche
a calarsi nei diversi scenari che possano verificarsi nell'interazione tra sistema software ed ambiente
circostante. Inoltre, una definizione chiara ed inequivocabile dei requisiti è sicuramente decisiva per
le successive fasi di specifica, progettazione ed, infine, realizzazione del sistema.
Questi due obiettivi possono essere raggiunti in vari modi, a seconda dei fattori che dovranno
caratterizzare il prodotto finale, ma qualunqe metodo di analisi deve prevedere due azioni:
• la costruzione di un glossario ai fini della definizione del dominio;
• la redazione dei requisiti utente, relativi sia agli aspetti funzionali che non funzionali del
sistema.
Il glossario sarà un documento nel quale verranno definiti in maniera univoca tutti i termini
significativi in relazione allo specifico contesto e che verranno adoperati nella descrizione degli
obiettivi.
L'operazione attraverso la quale si perviene ad un documento siffatto consta di alcune fasi , in
ciascuna delle quali viene attuata una operazione di 'filtraggio' su di un testo iniziale, fino a
40
pervenire al glossario di dominio50, poi al glossario dei dati51 ed, infine, ai requisiti del sistema 52
software che rappresenteranno il documento di partenza per la fasi di specifica dei requisiti.
Si è parlato della disponibilità di un testo iniziale, cioè una descrizione del problema, delle
esigenze e volontà del committente, ma, in alternativa, si potrebbe pensare di reperire le
informazioni attraverso delle interviste tra committente ed analista53. Si noti, infatti, che il glossario
dovrà essere verificato ed approvato dal cliente.
Il modello di deduzione ed analisi dei requisiti al quale faremo riferminento nel corso di questo
lavoro è quello mostrato in figura 13.
Illustrazione 13: Il processo di deduzione ed analisi dei
requisiti
in cui distinguiamo le 4 attività fondamentali:
•
Scoperta dei requisiti;
•
Classificazione ed organizzazione dei requisiti;
•
Negoziazione e priorità dei requisiti;
•
Documentazione dei requisiti.
50 Il glossario di dominio conterrà tutti i termini connessi al dominio applicativo in cui il prodotto software verrà calato.
51 Il glossario dei dati conterrà tutti i dati scambiati tra 'dominio' e sistema software.
52 I requisiti di sistema software verranno fuori dopo una operazione di 'riadattamento' dei concetti rimanenti dopo le
precedenti operazioni di filtraggio.
53 Le interviste rappresentano ununo strumento attraverso il quale il Glossario potrà essere consolidato.
41
2.4.1 La scoperta dei requisiti
La sezione relativa alla scoperta potrebbe essere vista come scomponibile in altre 4
sottosezioni,
L'attività dovrà partire da una conoscenza adeguata54 del contesto in cui sarà calato il sistema,
così da poter meglio comprendere le funzionalità richieste, i limiti, le caratteristiche fisiche.
Noto il problema da risolvere, per l'ingegnere del software sarà più agevole comprendere le
motivazioni delle richieste del cliente e gli sarà consentito di ampliare le sue conoscenze nello
specifico ambito.
Illustrazione 14: Processo di ricerca dei requisiti
Inoltre, nella maggior parte dei casi, l'adozione di un nuovo sistema costituisce un valore
aggiunto in termini di business per l'organizzazione che ne ha commissionato lo sviluppo.
L'obiettivo dell'attività di scoperta dei requisiti consiste nella raccolta delle informazioni
inerenti a sistemi nuovi o preesistenti, finalizzata alla definizione dei requisiti utente e di sistema.
2.4.1.1 Sorgenti di informazioni
Per raggiungere lo scopo, l'attività dovrà partire dalla consultazione delle "sorgenti di
informazioni": la natura delle sorgenti consultate dipenderà dal tipo di sistema in esame.
Naturalmente, nel caso in cui lo sviluppo parta da zero (nessun sistema preesistente) i requisiti
dovranno essere reperiti direttamente dagli utenti e cliente. E infatti, l'idea di sviluppare il nuovo
sistema nasce da necessità proprie dell'utente, piuttosto che da esigenze di mercato (si parla, in tal
caso di Greenfield Engineering).
54 La conoscenza del dominio richiesto non deve essere ne' troppo specifica ne' troppo generica.
42
Può capitare, invece, che il lavoro debba svolgersi su di un sistema già esistente che, a causa
dell'obsolescenza o per estenderne le funzionalità, debba essere riprogettato. In tal caso le fonti di
informazioni saranno soprattutto la relativa documentazione (si parla, di Re-engineering).
Oppure, potrebbe nascere l'esigenza di riprogettare le interfacce per consentire ad un sistema
già esistente di fornire servizi in un nuovo ambiente: si pensi, ad esempio, ad un sistema legacy
lasciato inalterato, tranne che per le sue interfacce.
Sulla scorta di quanto detto, le sorgenti informative riguardano:
• gli obiettivi di business delle imprese destinatarie del prodotto,
• la conoscenza del dominio applicativo,
•
le opinioni degli stakeholder di sistemi analoghi,
•
gli ambienti operativi (ad esempio l' interoperabilità),
•
gli ambienti organizzativi (come gli aspetti logistici).
2.4.1.2 Ingegneria dei requisiti basata sui punti di vista
La presenza di un molteplicità di stakeholder che esprimeranno le loro esigenze, comporterà la
definizione di una moltitudine di obiettivi. Un stesso obiettivo, però, potrebbe essere comune a due o
più stakeholder, oppure potrebbe essere in contrasto con un altro.
Questa caratteristica fa assumere all'obiettivo una natura soggettiva, poichè la sua decisione
dipende dalla percezione e, maggiormente, dell'esperienza di chi lo esprime.
Sulla scorta di questa considerazione nasce l'ingegneria dei requisiti orientati ai punti di vista
[14], nella cui analisi i punti di vista vengono adoperati per classificare gli attori 55 (cioè gli
stakeholder) e, naturalmente, anche per valutare la copertura dei possibili (ed a volte contrastanti)
requisiti.
Seguendo questo approccio, si preferirà intervistare un numero inferiore di attori appartenenti
però a gruppi differenti, piuttosto che un numero maggiore appartenenti allo stesso gruppo e dal
quale ci si potrà aspettare un contributo minore, poichè presumibilmente condivideranno dei
requisiti.
Attuiamo una distinzione tra: punti di vista diretti, indiretti e di dominio, ciascuno dei quali
sarà caratterizzato da un proprio livello di astrazione.
I primi rappresentano coloro che si interfacciano direttamente con il sistema (persone o
sistemi): essi forniscono dei requisiti di sistema ad un buon livello di dettaglio, comprese le
55 Un attore modella un'entità esterna che comunica con il sistema:
•
utente;
•
sistema esterno;
•
ambiente fisico.
Un attore ha un unico nome ed una descrizione opzionale.
43
funzionalità e le interfacce.
I secondi rappresentano coloro che hanno la capacità di influenzare il sistema (gli stakeholder):
essi forniscono requisiti di alto livello e vincoli organizzativi.
I terzi, invece, rappresentano le caratteristiche che influenzano i requisiti del sistema (i
vincoli), dunque forniscono requisiti di dominio (ad esempio gli standard da adottare).
Ovviamente, la distinzione dei punti di vista nelle tre categorie è solo una generalizzazione di
uno scenario vasto, in cui si potrebbero scorgere tanti più punti di vista dai quali, naturalmente,
sarebbe impensabile dedurne i requisiti.
Pertanto, per un sistema bisognerà:
1) identifiare i principali e più specifici56 'punti di vista';
2) strutturare ed organizzare gerarchicamente i punti di vista;
3) identificare i punti di vista più importanti per la scoperta dei requisiti di sistema.
2.4.1.3 Tecniche di elicitazione dei requisiti
Definito il "perchè" ed il "dove", cerchiamo di capire 'come' reperire le informazioni.
La scoperta dei requisiti può avvenire mediante diverse tecniche che comprendono:
•
interviste;
•
scenari d'uso;
•
prototipi;
•
conferenze, incontri, riunioni;
•
valutazioni di sistemi concorrenti;
•
studio del problema e del dominio applicativo.
2.4.1.3.1 Le interviste
Le interviste rappresentano un valido strumento di interazione con gli attori (stakeholder) del
sistema, il cui obiettivo è quello di raggiungere una comprensione generica sul cosa il sistema dovrà
fare.
Per giungere a tale comprensione, l'intervista da svolgere si baserà su di un insieme di
domande predefinite (intervista chiusa) e domande che nascono dalle problematiche sollevate dagli
56 Per principali e specifici punti di vista si intendono:
•
fornitori e destinatari del sistema;
•
sistemi che si interfacciano direttamente con il sistema in esame;
•
norme e standard con le quali il sistema dovrà essere in linea;
•
sorgenti dei requisiti aziendali e non funzionali, che potranno diventare punti di vista utili per definire
requisiti di alto livello che potranno essere trasformati in requisiti di sistema ad un maggior livello di dettaglio;
•
punti di vista ingegneristici che forniranno la competenza su sistemi analoghi a quello che sis ta
specificando ed, eventualmente, un aiuto a semplificare il supporto al sistema.
44
stakeholder (intervista aperta).
Il suo esito dipenderà, naturalmente, dalle capacità personali dell'intervistatore, il quale dovrà
invogliare l'attore alla discussione ed alla proposta dei requisiti. Un possibile approccio potrebbe
essere quello di iniziare a lavorare assieme all'intervistato su di un prototipo, così da tener traccia dei
confini del sistema da specificare.
Le informazioni ottenute mediante un'intervista rappresenteranno solo una parte di quelle
necessarie al raggiungimento dell'obiettivo finale, altre potranno essere reperite attraverso la
consultazione di documentazioni, uteriori osservazioni e proposte degli utenti.
2.4.1.3.2 Scenari di interazione e casi d'uso
L'elicitazione dei requisiti può essere effettuata anche attraverso la definizione di scenari di
interazione con il sistema software, la qual cosa semplifica notevolmente lo sforzo degli attori, i
quali potranno riferirsi a situazioni concrete.
Le informazioni reperite adottando questa tecnica di elicitazione consentiranno di dettagliare i
requisiti descritti ad un livello troppo alto di astrazione.
Chiariamo, a questo punto il significato dello "scenario" e come esso venga descritto
Uno scenario è
“A narrative description of what people do and experience as they try to make use
of computer systems and applications” [15].
Uno scenario rappresenta una sequenza di passi che descrivono l'interazione tra il sistema (o
sue componenti) ed un attore, che dovrebbe trarre "vantaggio" dall'interazione stessa . In esso ci si
focalizzerà sul punto di vista di una persona o dispositivo che interagisce con il sistema.
Per chiarire il concetto appena esposto, facciamo riferimento all'esempio di un negozio online.
Uno scenario possibile sarà l'acquisto di un prodotto, che potrebbe essere descritto come
segue:
scenario: Acquisto di un prodotto
Il cliente naviga nel catalogo dei prodotti, seleziona il/i prodotto/i desiderati e lo/li colloca in
un carrello virtuale. Quando il cliente vorrà effettuare il pagamento dovrà prima fornire le
informazioni relative alla propria carta di credito, poi confermare l'acquisto. Il sistema controlla la
validità della carta di credito del cliente e conferma l'acquisto al cliente attraverso un messaggio di
posta elettronica.
Per ciascuno scenario bisognerà definire:
45
1) chi siano gli attori (primario57 e secondari58);
2) quali siano gli obiettivi dell'attore;
3) le precondizioni dello scenario;
4) i compiti principali dell'attore;
5) come estendere lo scenario base;
6) quali sottoscenari siano possibili;
7) quali informazioni verranno acquisite, modificate o prodotte dall'attore;
8) se l'attore debba farsi carico di informare il sistema dei cambiamenti dell'ambiente esterno e,
se si, di quali, quanto spesso e quando;
9) quali informazioni l'attore desideri ottenere dal sistema;
10) se l'attore voglia essere informato di modifiche inaspettate del sistema e, se si, ogni quanto.
Gli scenari, dunque la loro descrizione, differiscono in base al punto di vista considerato (cfr.
Appendice).
Qualora si necessiti di uno risultato più formale si potrebbe adoperare una tecnica basata sì
sugli scenari, ma più strutturata: i casi d'uso. Il caso d'uso rappresenta un insieme di scenari59
dipendenti dall'obiettivo dell'attore.
La tecnica del casi d'uso venne introdotta per la prima volta da Ivar Jacobson, uno degli autori
della notazione UML60, nel 1987; la diffusione del concetto avvenne, però, alcuni anni più tardi
(1992) [16].
Questo approccio risultò particolarmente valido perchè consente una gestione più efficiente dei
requisiti ed, inoltre, può essere adottato come una base per l'analisi, lo sviluppo del software e per il
test funzionale.
L'utilizzo dei casi d'uso consente, da un canto, di specificare ed analizzare soluzioni diverse di
design, dall'altro, essi sono espressi in modo "grossolano" e, quindi, facilmente modificabili.
Pertanto, rappresentano un buon compromesso tra il formalismo descrittivo e la
modificabilità/espandibilità desiderabili in tale ambito.
Catturando la conoscenza del problema ad un livello intermedio, i casi d'uso forniscono una
57 Un attore primario è quelli che, tipicamente fornisce per primo lo stimolo iniziale, che avvia l'esecuzione del caso
d'uso e fruisce del relativo servizio.
58 Un attore secondario, in genere, è quello che riceve comunicazioni, dati, ecc.
59 Un caso d'uso è una astrazione che rappresenta una classe di scenari.
60 UML (the Unified Modelling Language) “is a graphical language for visualizing, specifying, constructing, and
documenting the artefacts of a software-intensive system”.
UML venne concepito verso la fine degli anni '80 e l'inizio degli anni '90 da Booch Rambaugh and Jacobson come
unificazione di diverse metodologie di analisi ed object oriented. Attualmente, rappresenta lo standard industriale più
utilizzato per la specifica e la modellazione di sistemi software. Tra i numerosi costrutti offerti da UML, gli "use
case" sono considerati lo strumento concettuale per la specifica dei requisiti. Tuttavia,nella comunità dell'ingegneria
dei requisiti ci sono punti di vista discordanti riguardo l'efficacia di UML e degli use case come
supporto all'attività di analisi dei requisiti.
46
percezione concreta delle interazioni reali col sistema e, nel contempo, presentano caratteristiche di
riusabilità e flessibilità.
Tornando all'esempio del negozio online, lo scenario "Acquisto di un prodotto" descrive il
normale flusso di eventi, senza tener conto del manifestarsi di situazioni alternative. Ad esempio, il
caso in cui la carta di credito non sia valida fa in modo che il flusso di eventi subisca ad un certo
punto una deviazione. In effetti, l'obiettivo dell'attore (l'acquisto di uno o più prodotti) è la radice
comune alle possibilità "transazione eseguita" e "transazione fallita", ed allora:
•
caso d'uso: Acquisto di un prodotto;
a) scenario 1: successo della transazione
b) scenario 2: insuccesso della transazione: carta di credito non valida
Un caso d'uso è rappresentato da uno scenario base, che tipicamente corrisponde
all'avanzamento lineare del flusso di azioni ed al caso di "successo" (main success scenario), da
scenari alternativi (alternative scenario), che possono rappresentare casi di successo o di fallimento,
ma che comportano l'insorgere di complicazioni.
Infatti, nonostante non sia necessario (si pensi ai costi) analizzare nel dettaglio tutti i possibili
scenari alternativi a quello base, si rende necessario individuare ogni situazione che potrebbe
comportare un cattivo esito del caso d'uso o che richiedano contromisure ad hoc.
Si noti che, in questa fase, l'attenzione dovrà essere concentrata sull’interazione (sull'uso) e
non sulle attività interne al sistema. Infatti, un caso d'uso viene adoperato per descrivere i requisiti di
utente (cosa ci si aspetta da un sistema) ed, in particolare, rappresenta un requisito funzionale.
Esso potrà essere specificato attraverso le seguenti informazioni:
• Nome del caso d'uso;
• Attori: descrizione degli attori coinvolti nel caso d'uso;
• Entry condition: descrizione della condizione che debba verificarsi affinchè possa iniziare il
caso d'uso;
• Flusso di eventi: descrizione informale61, mediante linguaggio naturale;
• Exit condition: descrizione della condizione che debba verificarsi affinchè termini il caso
d'uso;
• Eccezioni: descrizione delle situazioni che possano causare una deviazione del flusso
normale di eventi, indicando anche le azioni da intraprendere a riguardo;
• Requisiti speciali: elenco dei requisiti non funzionali e dei vincoli.
I casi d'uso possono essere adoperati in ogni fase del ciclo di vita del software, ad esempio per
61 Si potrebbe pensare di descrivere il flusso di eventi come una successione numerata di passi.
47
controllare il sistema (nella fase di testing e di verifica) e ciò proprio sulla scorta delle informazioni
che vengono utilizzate per descriverli. Naturalmente, un'azione del genere dovrà prevedere la
descrizione di scenari che, a vari livelli di astrazione, dettaglino i flussi di eventi.
Illustrazione 15: Casi d'uso e ciclo di vita del software
Una volta individuati e definiti i casi d'uso, gli svuluppatori dovranno assicurarsi che le
funzionalità richieste al sistema siano state completamente specificate. Pertanto, bisognerà
dettagliare ciascun caso d'uso e descrivere più precisamente il comportamento che il sistema
assumerà a fronte di determinate situazioni62.
In particolare, saranno specificati:
• gli elementi manipolati dal sistema;
• le sequenze di interazione di basso livello tra l'attore ed il sistema;
• gli accessi al caso d'uso: quale attore potrà invocare il caso d'uso;
Inoltre, saranno individuati e specificati gli scenari non ancora valutati ed identificate le
relazioni (cioè le dipendenze) tra i casi d'uso. Ancora, saranno accordati i requisiti non funzionali e
gli attributi di qualità63 del prodotto, ovvero quelli visibili64 dall'utente finale, ma non direttamente
legati alle funzionalità del sistema.
Tra casi d'uso possono essere definiti tre tipi fondamentali di relazioni: estensione, inclusione e
generalizzazione.
Un caso d'uso descrive un insieme di interazioni, tra un attore ed il sistema, relative ad una
62 Condizioni di errore o limite.
63 Efficienza, usabilià, ecc.
64 Gli aspetti non visibili (come le scelte delle tecnologie da adottare per lo svilippo del sistema, il progetto del sistema
e delle metodologie), dall'utente non saranno trattati nella fase di raccolta.
48
particolare funzionalità, che potrebbe essere estesa. Dunque, attraverso la relazione di estensione si
potranno separare gli eventi "opzionali65" dal caso d'uso comune. In tal modo, il caso d'uso base sarà
più conciso e più leggibile e, anche un'eventuale modifica diverrà più agevole.
Può accadere che una funzionalità richiesta al sistema sia tanto complessa da rendere difficile
la sua risoluzione in un unico caso d'uso (si pensi ad una lunga sequenza di passi da compiere), per
cui sia necessario decomporla66. In tal modo, la stessa funzione sarà descritta come l'aggregazione di
un insieme di sotto-funzioni e, di conseguenza, il caso d'uso associato ad essa sarà decomposto in
tanti casi d'uso (più semplici) quante sono le sotto-funzioni.
Dunque, fattorizzare un "comportamento" in casi d'uso semplici e separati è ancor più
importante quando esso è comune a più Use Case. In questo modo, verrà ottimizzata la presenza di
quello condiviso, favorendo il riuso.
D'altro canto, frammentare un requisito, seppur complesso, in un numero troppo elevato di casi
d'uso, dà luogo a specifiche poco chiare per gli utenti ed i clienti.
La generalizzazione tra casi d'uso è un altro metodo di fattorizzazione, che consiste nel
raggruppare i comportamenti comuni in un caso d'uso "padre" nella definizione di casi d'uso "figli",
nei quali verranno ridefinite alcune informazioni e che erediteranno il funzionamento ed il
significato del padre.
Le relazioni tra casi d'uso mirano a ridurre più possibile la ridondanza dal modello, così da
mitigare la presenza di inconsistenze.
È importante notare che le relazioni che intercorrono tra gli attori ed i casi d'uso consentono
agli utenti ed agli sviluppatori di ridurre la complessità del modello, di aumentarne la conoscenza,
così da individuare i requisiti (che evolveranno mentre si sviluppano gli scenari).
In definitiva, la raccolta dei requisiti servirà alla costruzione del modello funzionale del
sistema
che sarà poi usato durante l’analisi per le fasi successive e che dovrà essere sottoposto ad una
validazione da parte dei committenti.
2.4.1.3.2.1 Considerazioni sui casi d'uso
Fino ad ora abbiamo discusso i casi d'uso, descrivendone le caratteristiche e le motivazioni che
hanno reso molto apprezzata tale tecnica.
È bene notare, però, che essi si prestano in maniera ottimale per descrivere le modalità di
utilizzo solo di particolari tipi di sistemi: quelli che prevedono interazioni significative con gli attori
e quelli le cui operazioni siano di tipo operativo e strutturato.
65 In tal caso la condizione eccezionale è l'ampliamento della funzionalità espressaa dal caso d'uso base.
66 Si parla di decomposizione funzionale.
49
In effetti,
l'adozione di tale approccio non risulta ottimale in sistemi come data warehouse,
sistemi CAD67, ad esempio, per i quali i casi d'uso potranno essere definiti, senza apportare, però,
benefici significativi nella specifica della maggior parte dei requisiti.
Rispetto alle specifiche di analisi tradizionalali, i casi d'uso presentano un vantaggio di fondo,
che risiede nella migliore comunicazione con il committente. Infatti, se tipicamente le prime
descrivono in maniera astratta le funzionalità interne al sistema, i casi d'uso descrivono in maniera
più concreta, sotto forma di dialogo , le interazioni (azione dell'attore – reazione del sistema).
Uno degli errori che dovrebbero essere evitati nel loro utilizzo è quello di adoperarli secondo
una logica di scomposizione funzionale troppo spinta, descrivendo al livello atomico ogni singola
funzione del sistema o di sue componenti68, per la quale essi sono inadeguati. Operare in questo
modo, infatti, farebbe perdere, principalmente, il buon livello di comunicazione con i committenti
offerto dai casi d'uso.
Un altro aspetto interessante concerne la sicurezza nel modello dei casi d'uso. Come è noto, si
tratta di un requisito non funzionale che costituisce un vincolo sentito in qualunque sistema e,
quindi, nella maggior parte dei casi d'uso.
L'approccio più tradizionale prevede di includere i relativi casi d'uso a tutti gli use case che
devono applicare i requisiti di sicurezza.
Per chiarire il concetto, consideriamo l'esempio di una segereteria online per studenti, per la
quale definizamo gli use case "autenticazione studente" (che servirà ad accertarsi che l'utente sia
effettivamente quello che dichiara di essere e per il quale il problema riguarda anche lo scambio di
messaggio con altri sistemi), "autorizzazione ad espletare la funzionalità selezionata" (si noti che, se
un utente è autorizzato a svolgere l'attività che ha selezionato, come la visualizzazione degli esami
sostenuti, ciò non vuol dire che potrà richiedere lo stesso servizio per un altro insieme di dati, come
la lista degli esemi sostenuti da un altro studente), "autorizzazione al trattamento dei dati richiesti",
ecc.
È evidente che tale approccio, sebbene molto semplice, complichi la descrizione dei casi d'uso.
Dunque, una tecnica alternativa da adoperare potrebbe essere quella di "isolare" i casi d'uso
della sicurezza dagli altri, così da avere il vantaggio di poter specificare particolari
comportamenti/requisiti.
Ritornando all'esempio precedente, dopo il riconoscimento dell'utente si potrebbe richiedere di
verificare se il profilo ad esso associato sia stato bloccato, oppure se la password sia scaduta.
67 CAD è l'acronimo di Computer Aided Design. Il computer assite la fasse di progettazione non solo cambiando
concezione del disegno (la modellazione solida crea un oggetto 3D virtualmente manipolabile sullo schermo), ma
offrendo diversi mezzi di supporto per la verifica del progetto e l'ottimizzazione della produzione [17].
68 A questo scopo possono essere adoperati approcci più consoni, come i diagrammi di flusso (activity diagram in
UML)
50
Ancora, nella redazione della sezione del documento relativo ai requisiti non funzionali, si
potrà descrivere in maniera dettagliata il comportamento che dovrà essere assunto in relazione ai
diversi casi d'uso.
Inoltre, nelle precondizioni dei caso d'uso potrebbe essere inserita una clausola standard.
Rispetto al caso mostrato, essa potrebbe essere: "l'utente autenticato ed autorizzato ad eseguire il
servizio69".
2.4.2 L'analisi
Una volta raccolti, i requisiti dovranno essere analizzati, raffinati (descrivendoli ad un livello di
astrazione più basso) e valutati.
L'analisi consente di ottenere requisiti descritti ad un opportuno livello di dettaglio e con
caratteristiche adeguate di qualità, tali da consentire la formulazione di una o più possibili soluzioni
al problema.
Definiti i confini del contesto, bisognerà individuandarne le interfacce con altri attori
(eventualmente attraverso un protitipo delle interfacce utente), così da chiarire ulteriormente gli
scenari di interazione, espressi mediante i casi d'uso, e gli altri requisiti.
Ancora, si dovranno stimare i costi, le prestazioni ed i rischi legati alla scelta di implementare i
requisiti definiti.
Nel caso in cui la valutazione della fattibilità sia positiva, sarebbe opportuno invitare i
committenti a classificare i requisiti da implementare secondo una scala di priorità70.
A questo punto, sarà possibile sviluppare i casi d'uso, individuati nella fase di elicitazione, e
produrre modelli di analisi che consentiranno di esplorare in maniera più precisa le funzionalità che
il sistema dovrà offrire ed individuare nei requisiti eventuali errori e/od omissioni.
L'ultimo passo da compiere consisterà nella creazione del glossario, già discusso
precedentemente, attraverso il quale la terminologia adottata sarà di uso comune per il team di
progetto, così come per gli stakeholder.
2.5 Specifica dei requisiti
L'attività di specifica dei requisiti rappresenta la descrizione formale di un sistema software,
inteso come prodotto che soddisfi le esigenze mostrate dall'utente, sotto i vincoli posti dallo
specifico dominio di applicazione.
69 Si noti che la seconda clausola implica la prima: se l'utente non fosse autenticato, non sarebbe autorizzato a svolgere
le azioni selezionate.
70 La classificazione dei requisiti da implementare costituisce il punto di partenza nel caso in cui si preveda un rilascio
incrementale del prodotto.
51
Tale attività confluisce in un documento di specifica dei requisiti software, appunto, per il
quale vi è la possibilità di adoperare un linguaggio formale, oppure strutturato, come abbiamo
precedentemente discusso. Esso potrà essere dotato di una semantica formale oppure convenzionale
(dunque più intuitiva) e di una sintassi controllata.
L'operazione di specifica offre, innanzitutto, la possibilità di tradurre in frasi, cioè concetti
concreti, quel che sino a poco prima era solo un'idea di come il sistema software dovesse
comportarsi, poi di poter comunicare e condividere tali concetti con il team di progetto e,
naturalmente, con il committente.
Il documento di specifica dei requisiti potrà essere eventualmente analizzato da uno strumento
automatico.
È, pertanto, necessario adottare un metodo che consenta di svolgere questa attività in maniera
logica e graduale, così da focalizzare la nostra attenzione sugli aspetti più significativi (e, spesso, più
complicati da trattare).
Durante l'attività di specifica dei requisiti bisognerà assegnare a ciascun requisito un
identificativo univoco, così da poter documentarne l'origine71 più agevolmente e gestirne la
tracciabilità lungo tutto il suo ciclo di vita.
Bisognerà prevedere anche una gestione della versione di ciascun requisito, così da poter
tracciare anche tutte le modifiche effettuate su di esso.
Un requisito può essere specificato, oltre che dall'indentificativo ed dalla descrizione, anche da
un insieme di attributi che ne vanno a caratterizzare:
•
la tipologia (funzionale o non funzionale ed, eventualmente, specificare a quele classe
appartiene);
•
chi lo ha richiesto, la data di richiesta e dell'ultima modifica apportata al requisito;
•
il numero di versione, così da tener traccia dell'evoluzione subita;
•
l'importanza secondo il punto di vista del committente (ad esempio: obbligatorio,
desiderabile, opzionale);
•
la priorità di implementazione del requisito, quindi rispetto al suo rilascio;
•
lo stato che indichi, ad esempio, se il requisito sia stato approvato, implementato, verificato,
eliminato;
•
il criterio di accettazione;
•
il livello di stabilità del requisito: infatti, la specifica e lo sviluppo di un sistema possono
protrarsi per lungo tempo, durante il quale le esigenze degli stakeholder possono mutare,
71 Casi d'uso, input pervenuti dagli stakeholder, standard aziendali, regole di business, vincoli legislativi, ecc.
52
invalidando la presenza di alcuni requisiti. Per questo motivo, nell'ambito della gestione dei
requisiti, si potrebbe classificarli in duraturi72 o volatili in base al livello di stabilità che
presentano.
La creazione di una matrice di tracciabilità dei requisiti è uno dei passi fondamentali di tutta
l'attività. In essa dovranno essere riportati tutti i collegamenti tra i requisiti ed i casi d'uso da cui
discendono ed i requisiti del documento di specifica. Successivamente, si dovranno riportare tutti i
collegamenti tra i requisiti specificati e gli "artefatti" dello sviluppo, sino ad arrivare ai componenti
fisici in cui essi sono implemetati ed, infine, con le specifiche di test che li verificano.
2.6 La tracciabilità dei requisiti
Lo sviluppo di un prodotto deve seguire un percorso logico, durante il quale è fondamentale
assicurare la completezza e la consistenza di ogni passo.
Rispetto all'ingegneria dei requisiti ed, in particolare, nell'ambito loro specifica, il problema
della tracciabilità è particolarmente sentito e la sua risoluzione consentirà di capire come e dove si
collocano i requisiti una volta realizzato il sistema, dimostrare la loro effettiva implementazione,
gestire più semplicemente le evoluzioni, la manutenzione, garantire un maggior riuso.
Le tecniche di tracciabilità dei requisiti vengono adottate per garantire la congruenza tra
prodotto software ed aspettative del committente, quindi presume un lavoro congiunto e
consapevole di entrambe le parti chiamate in causa.
La tracciabilità è una proprietà dei requisiti: infatti, una volta specificati, dovranno essere
direttamente connessi alle motivazioni ed obiettivi che hanno dato origene ad esso.
Per ottenere tutti i vantaggi che derivano da essa, bisognerà fissare la tracciabilità dei requisiti
con i corrispondenti componenti del progetto, con il codice, i casi di test e, in generale, con tutti gli
artefatti derivanti dallo sviluppo del prodotto.
Tra le definizioni di tracciabilità presentate in letteratura, si distinguono i seguenti tipi:
• Tracciabilità dell'origine, in cui viene indicata la sorgente da cui ha preso vita ogni requisito.
Ad esempio, un requisito sarà collegato alla documentazione, ad un committente (cioè
all'obiettivo in cui si è tradotto il requisito) oppure ad una specifica norma, ecc.
• Tracciabilità della descrizione, in cui il requisito specificato sarà collegato alla motivazione
da cui ha avuto origine.
• Tracciabilità delle dipendenze, in cui vengono esplicitate (sotto forma di collegamenti) le
72 Per duraturo si intende un requisito relativamente stabile che rispecchia quelche aspetto fondamentale
dell'organizzazione e che, quindi, si riferisce direttamente al dominio del sistema.
Per volatile, invece, si intende un requisito che presumibilmente subirà dei cambiamenti, che seguiranno
l'evoluzione.
53
dipendenze tra requisiti;
• Tracciabilità tra sottosistemi, in cui i requisiti vengono collegati con i sottosistemi in cui
trovano la loro implementazione, dunque consentono di definire "chi deve sviluppare cosa".
Infatti, i requisiti sono suddivisi per tipologie a seconda dei sottosistemi che li governano.
• Tracciabilità del progetto, in cui il requisiti verranno collegati con i componenti specifici del
sistema che sono adoperati per implementarli;
• Tracciabilità dell'interfaccia, in cui i requisiti verranno collegati con le interfacce interne ed
esterne del sistema, attraverso le quali essi potranno esse utilizzati.
Per poter tracciare i requisiti, così da poterli individuare facilmente, bisognerà associare a
ciascuno un identificativo univoco (ad esempio, nella forma <tipo_requisito> <numero_requisito>),
in modo da utilizzare quest'ultimo come riferimento per collegare i requisiti agli aspetti relativi alla
tracciabilità.
Le informazioni sulla tracciabilità saranno disponibili su di una tabella detta, appunto, matrice
di tracciabilità, sulle cui righe e colonne sono, rispettivamente, collocati i requisiti e gli aspetti con
cui essi presentano delle relazioni. In particolare, una relazione tra il contenuto di una riga e quello
di una colonna sarà registrato in corrispondenza della loro intersezione.
Illustrazione 16: Esempio di matrice di tracciabilità
(orizzontale)
Una classificazione di tracciabilità meno stringente è la distinzione nelle due tipologie:
orizzontale e verticale.
Per tracciabilità orizzontale si intendono i collegamenti tra requisiti allo stesso livello di
astrazione e tra i quali sussiste una relazione. Ad esempio, supponiamo che nel documento di
specifica dei requisiti di sistema il requisito indicato con R1 presenti una relazione con il requisito
R2. Verrà creato un collegamento tra i due requisiti ed in più tale relazione potrebbe essere
specificata nel caso in cui R2 usi R1, R2 dettagli R1, R2 sia in conflitto con R1.
Per tracciabilità verticale si intende il collegamento tra un requisito e altre entità (siano, ad
esempio, requisiti di differente livello, moduli software, casi di test, ecc.) a cui esso fa riferimento.
54
Un esempio potrebbe essere il collegamento tra requisiti di sistema e relativi requisiti software di
alto livello (nel caso in cui si sia deciso di operare un'astrazione a più livelli dei requisiti software).
Allo stato attuale delle cose, il problema della tracciabilità, pur essendo particolarmente
sentito, non riesce a trovare uno sbocco risolutivo in parecchi contesti. Infatti, la molteplicità delle
definizioni di tracciabilità ha fatto sì che non si sia sviluppata un'idea chiara e condivisa del
concetto. Pertanto, nonostante i tool di gestione dei requisiti73 prevedano funzionalità a supporto, nei
contesti in cui vengono utilizzati, raramente si riesce a mettere a frutto i vantaggi che si potrebbero
ottenere.
È comunque possibile distinguere due fasi della tracciabilità: precedente (Pre-R equirements
Specification Traceability) e successiva alla specifica dei requisiti (Post-Requirements Specification
Traceability).
Nella prima vengono considerati i collegamenti tra un requisito con gli aspetti ad un livello
ancora alto di astrazione, mentre nella seconda ci si riferisce ai collegamenti tra lo stesso requisito e
gli aspetti a valle della specifica, cioè quelli ad un livello di dettaglio maggiore.
In figura 17 mostriamo un esempio che ci aiuterà a comprendere i concetti appena esposti.
Illustrazione 17: Tracciabilità Pre-RS e Post-RS
73 Un esempio di tool di gestione dei requisiti è IBM Rational DOORS.
55
L'approfondimento della conoscenza dei requisiti, a mano a mano che si procede, è distribuita
e messa assieme per ottenere le rappresentazioni successive, nelle quali verranno aggiunte
interazioni e sulle quali dovranno propagarsi i cambiamenti dovuti all'evoluzione dei requisiti stessi.
Si noti, inoltre, che i vantaggi ottenibili dalla tracciabilità Pre–Requirements Specification
sono strettamente dipendenti alla capacità di tracciare (in maniera bidirezionale) i requisiti con la
loro originaria formulazione. Invece, i vantaggi legati alla tracciabilità Post-Requirements
Specification
dipendono dalla capacità di tracciare (in modo bidirezionale) i requisiti con la loro specifica,
attraversando tutti gli artefatti in cui essi vengono lavorati.
2.7 Convalida dei requisiti
La convalida consiste nel dimostrare che i requisiti specificati definiscano realmente il sistema
richiesto dal cliente.
La sua importanza deriva dalla considerazione che correggere un errore od un'omissione in
una fase avanzata dello sviluppo del sistema (o, ancor peggio, dopo la sua messa in esercizio)
comporti costi molto elevati.
I requisiti documentati (nel documento dei requisiti) dovranno essere sottoposti al
committente, così che possa valutarne l'aderenza alle sue aspettative ed, eventualmente, approvarli.
Durante il processo di convalida potranno essere effettuati diversi controlli sui requisiti per
dimostrarne la validità, la consistenza, la completezza, il realismo/realizzabilità e la verificabilità
(cfr. Appendice).
Le tecniche di validazione più adoperate consistono nella revisione dei requisiti, nella
prototipizzazione e nella generazione dei casi di test.
Tra esse, la revisione dei requisiti è la più diffusa, poichè consente di validare anche i requisiti
non funzionali.
Alla base di essa vi è l'idea di riunire un gruppo di persone che dovranno leggere ed analizzare
il docmento dei requisiti, per individuare eventuali errori od incongruenze che verranno discusse al
56
fine di risolverle.
Il modello di revisione dei requisiti prende vita dalle considerazioni degli studiosi Gilb e
Graham74 e, successivamente ampliata da Kotonya e Sommerville, consta delle seguenti attività:
1. Plan review: viene nominato il team, il luogo, il giorno in cui verrà operata la revisione;
2. Distribuite documents: il documento dei requisiti (ed eventuale altra documentazione) viene
fornita al team di revisione;
3. Prepare for review: lettura individuale del documento, così da trovare conflitti e/o incongruenze.
In tal modo, ogni soggetto potrà operare senza subire l'influenza di un altro;
4. Hold review meeting: discussione di tutti i problemi riscontrati e decisione delle contromisure da
adottare;
5. Follow-up actions: verifica delle contromisure decise da parte del coordinatore del team;
6. Revise document: ulteriore revisione delle sezioni evidenziate.
I problemi riscontrabili all'interno del documento possono venir fuori dalla mancanza di
chiarezza nei requisiti: il requisito può essere espresso in maniera poco chiara, oppure si è omessa
qualche informazione comunicata durante la fase di elicitazione;
Nel caso in cui il documento dei requisiti presenti informazioni mancanti, esse potranno essere
reperite dagli utenti interessati. Va da sè che, nel caso di conflitti tra requisiti, sia necessario
negoziare con i clienti una possibile soluzione alternativa.
La revisione dei requisiti, alla quale dovrebbero essere coinvolti tutti gli interessati al prodotto
(committente e produttore), potrà essere svolta in maniera formale od informale
I requisiti dovrebbero essere revisionati regolarmente durante tutta la fase di definizione,
poichè servono ad affrontare problemi od errori di specifica nella fase iniziale del processo.
Una delle caratteristiche che dovrebbero mostrare i requisiti proposti
è la verificabilità,
74 Gilb e Graham affermano che il gruppo di revisonatori dovrebbe essere selezionato così da riflettere i diversi punti di
vista, quali il test, l'utente finale e la gestione della qualità. Inoltre, ogni organizzatore dovrebbe sviluppare le proprie
check-list, basate su standard e prassi interne, da aggiornare regolarmente quando vengono scoperti nuovi tipi di
difetti [4].
57
pertanto bisogna scrivere un insieme di casi di test 75, attraverso i quali dimostrare che il sistema
consegnato soddisferà ogni requisito specificato.
Una volta rilevate, le incongruenze potranno essere risolte mediante tecniche di negoziazione.
2.8 La gestione dei requisiti
Nel corso del processo software, gli stakeholder e produttore acquisiscono una maggiore
consapevolezza del problema e ciò, inevitabilmente, influenzerà i requisiti.
Ad esempio, non di rado capita di accorgersi che alcuni aspetti del dominio non siano stati
affrontati o, magari, non trattati in maniera adeguta, per cui nasce l'esigenza di rivedere il documento
dei requisiti sulla base delle nuove conoscenze acquisite.
Illustrazione 18: Mutabilità dei requisiti nel tempo
Tipicamente, i requisiti su cui si avverte l'impatto di questa "evoluzione" sono:
•
i requisiti di compatibilità: dipendono da altri sistemi o processi organizzativi;
•
i requisiti duplicati: requisiti che rappresentano il medesimo "bisogno";
•
i requisiti emergenti: sono frutto dell'ampliamento della conoscenza del problema. Questa
categoria di requisiti è, probabilmente, quella più interessante, poichè comporta
nell'ampliamento delle funzionalità del sistema.
•
i requisiti impliciti: specifici del dominio e, per questo motivo, non formalizzati
adeguatamente;
•
i requisiti instabili: cambiano con lo sviluppo del sistema.
L'evoluzione, sfociata in una modifica, piuttosto che in una cancellazione o nella creazione di
nuovi requisiti, dovrà essere gestita opportunamente.
75 Ed infatti, la specifica dei casi di test, condotta a fronte dei casi d'uso (correlati ai requisiti funzionali), consente di
rilevare omissioni, ambiguità nel documento dei requisiti.
58
Il primo passo da compiere in tal senso è la pianificazione delle attività da svolgere, che dovrà
iniziare durante il processo di elicitazione dei requisiti.
Questo stadio consta di alcune fasi:
•
l'identificazione dei requisiti, che consiste nell'associare a ciascun requisito in identificativo
univoco, in modo che si possa più agevolmente tenerne traccia;
•
creazione di un processo di gestione delle modifiche;
•
definizione di politiche di tracciabilità, in cui verranno determinati i tipi di dipendenze tra
requisiti che devono essere tracciate, verranno stabilite le relazioni tra requisiti e casi d'uso e
tra questi ultimi e gli artefatti dello sviluppo;
In particolare, il sistema di tracciabilità delle modifiche dovrà consentire di seguire ciascuna
proposta nei diversi stadi di avanzamento: dall'elicitazione, all'analisi, alla valutazione dell'impatto
organizzativo, temporale, economico, all'approvazione di quest'ultimo.
•
Individuazione degli strumenti CASE76 da adottare.
La gestione dei requisiti consiste in un insieme di attività volte alla comprensione ed al
controllo dei cambiamenti ai requisiti di sistema.
Bisognerà, innanzitutto, definire un processo formale di gestione delle modifiche proposte,
come la creazione di nuovi requisiti, la modifica di requisiti già esistenti, la cancellazione di requisiti
non più necessari.
Ciascuna proposta dovrà essere analizzata e valutata, solo dopo essere stata approvata, si
deciderà quando metterla in atto sul requisito di sistema al quale si riferisce.
Pertanto, nel processo di gestione dei requisiti, ogni requisito dovrà essere seguito
individualmente, ovvero, si dovrà tener traccia della sua storia e delle modifiche che ha subito
(gestione delle versioni).
Nei progetti di grandi dimensioni, con un cospicuo numero di requisiti, si rende necessario
definire il Change Control Board, che rappresenta un canale ufficiale di controllo delle modifiche ai
requisiti. E infatti, esso è rappresentato da un gruppo formalmente costituito dai ruoli preposti ad
analizzare, valutare, approvare o rifiutare le modifiche proposte.
Il Change Control Board, nel suo complesso, avrà il compito di determinare l'impatto che una
modifica proposta possa avere sul sistema e, di conseguenza, stabilire se sia opportuno attuare la
modifica.
Sarà, inoltre, importante stabilire la baseline dei requisiti, che servirà a misurare lo stato di
avanzamento del progetto. E infatti, come se fosse una istantanea, mostra l'insieme dei requisiti che
76 Computer Aided Software Engineering: strumenti che supportano lo sviluppo del software attraverso interfacce
grafiche e visuali, librerie di funzionalità.
59
rappresentano la base dell'accordo iniziale con il committente e sui quali si misurerà l'impatto delle
modifiche. All'interno della baseline, ciascun requisito avrà un proprio stadio di avanzamento che
potrà essere identificato con i termini "proposto", "approvato", "implementato" oppure "verificato";
di conseguenza, in ogni istante si potrà ottenere il numero dei requisiti che si trovano in uno
specifico stato.
L'impatto che una modifica proposta su di un requisito rispetto alle funzionalità sel sistema, sui
clienti e stakeholder, sulla potenziale destabilizzazione del sistema in seguito alla modifica, potrà
essere stimato servendoci delle matrici di tracciabilità e della conoscenza acquisita dei requisiti di
sistema. Il risultato di questa analisi fornirà il carico di lavoro necessario ed il costo legato
all'attuazione della modifica stessa. Naturalmente, maggiori saranno le modifiche da apportare al
documento dei requisiti e, se necessario al progetto del sistema ed alla sua implementazione,
maggiori saranno i costi ed il lavoro da svolgere. Una volta completata l'analisi di impatto, si dovrà
decidere se procedere o meno con la modifica.
È importante considerare che le modifiche, a causa degli impatti che potrebbero avere, devono
essere apportare seguendo un approccio top-down, cioè seguendo la tracciabilità tra i requisiti ed i
prodotti dello sviluppo. Ciò consentirà di procedere in maniera sistematica e coerente.
Illustrazione 19: Evoluzione controllata dei requisiti
La necessità di modificare un requisito potrebbe nascere da mutamenti del punto di vista del
committente, piuttosto che dalla presenza di errori o anomalie. Sarebbe opportuno, adoperare un
60
sistema che tracci ciascuna proposta di modifica e anomalia presentata con il corrispondente
requisito, così da avere sempre un'idea chiara della motivazione che ha spinto ad operare su di esso.
Apportare le modifiche al contentuto del documento dei requisiti potrebbe diventare una
attività critica, soprattutto considerando quanto spesso e su quanti requisiti potrebbe essere svolta.
Per questo motivo, è necessario organizzare il documento dei requisiti in modo che ogni
sezione sia più possibile modulare e non presenti troppo riferimenti esterni, così da poterla
modificare senza incidere (o minimizzare l'impatto) sulle altre sezioni del documento.
61
Capitolo 3
Sistemi emdebbed e metodologie di sviluppo
Un dispositivo embedded ha una natura invisibile agli occhi dell'utente, poichè è incapsulato
all'interno di un sistema progettato per una specifica applicazione e supportato da una piattaforma
hardware e software ad hoc.
La loro presenza massiva sul mercato, in grande varietà77 è indice dell'impegno sempre più
concreto delle organizzazioni verso gli specifici obiettivi del consumatore e la naturale spinta verso
l'innovazione tecnologica.
In contrapposizione ad un sistema general purpose, che ammette tipicamente una forte
alterabilità da parte dell'utente, un sistema embedded limita normalmente le possibilità di ingerenza
alla sola modifica della configurazione.
Spesso, la specifica d'uso di un sistema embedded influisce anche sulle specifiche progettuali
dell'hardware.
La scelta di realizzare un sistema embedded, piuttosto che adattare un insieme di componenti
hardware e software commerciali, ricade nella classica problematica del Make or Buy.
I sistemi embedded vedono la loro collocazione soprattutto in alcuni importanti settori
applicativi, il cui utilizzo assorbe circa la metà del costo complessivo.
Illustrazione 20: Incidenza percentuale dei sistemi emebedded sul costo complessivo dei
prodotti
Un sistema dedicato è assimilabile ad un generico sistema di calcolo, poichè la sua archiettura
77 Si pensi ad automobili, lavatrici, navigatori satellitari, carte di credito, ecc.
62
è costituita da una sezione di elaborazione, di comunicazione e di memorizzazione.
L'unità di elaborazione rende il sistema capace di elaborare i segnali provenienti dal mondo
esterno; quella di comunicazione consente il trasferimento dei segnali (cioè l'informazione) da e
verso il mondo esterno ed all'interno del sistema embedded stesso. L'unità di memoria fornisce al
sistema la capacità di custodire nel tempo l'informazione.
Naturalmente, per ogni applicazione realizzata da un sistema embedded dovranno essere
soddisfatte specifiche esigenze per la capacità di elaborazione, comunicazione e memorizzazione.
Si pensi ad una funzionalità ed a come essa possa essere ottimizzata in maniera differente a
seconda dell'applicazione a cui è destinata.
Dunque, ciò che rende un sistema embedded diverso rispetto ad altri è l'insieme dei requisiti
operativi, che ne fanno un caso peculiare, per il quale è necessario definire una particolare
metodologia di progetto.
Oltre ad essi, un sistema embedded è vincolato anche da fattori di varia natura: vincoli non
direttamente tecnologici, come il costo del prodotto ed il tempo di realizzazione.
Ci si renderà facilmente conto di quanto un numero così elevato di vincoli e requisiti
dipendano dalla necessità di adottare architetture miste hardware e software, al fine di trovare il
miglior compromesso tra prestazioni, costo e tempo di sviluppo e, nel contempo, il ricorso a
metodologie di progetto ben strutturate.
Sappiamo che un normale elaboratore è realizzato con lo scopo principale di renderlo versatile,
in maniera che possa adattarsi alla enorme varietà di ambiti applicativi cui è destinato.
Tale caratteristica sarà ottenuta dotando le architetture hardware di risorse sovrabbondanti
rispetto alle singole applicazioni, ma in linea con i vincoli di costo.
Pertanto, i prodotti general purpose seguono standard e architetture di riferimento.
Al contrario, ad un sistema dedicato a una specifica applicazione (oppure ad una classe
specifica di applicazioni) non viene certamente richiesto il requisito di versatilità, poichè è una
macchina dedicata allo svolgimento di una classe molto ristretta di compiti. Nonostante ciò, grazie
alla specificità dell'applicazione cui è rivolto, il sistema embedded potrà essere progettato in modo
da ottimizzare78 determinati vincoli di costo e di prestazioni.
Questa caratteristica rende arduo standardizzare l'architettura di un sistema dedicato, giacché,
anche a parità di requisiti funzionali, i vincoli relativi alla specifica applicazione portano a scelte
progettuali radicalmente diverse.
Si noti, infatti, che vincoli temporali troppo stringenti alla realizzazione del sistema fanno sì
78 Approfondita la conoscenza sulla particolare applicazione, si potrà dimensionare la capacità di calcolo scegliendo il
microprocessore ed, eventualmente, adoperando dispositivi hardware aggiuntivi per ridurre la potenza di elaborazione
63
che si protenda verso soluzioni prevalentemente software, così come limiti sulla dimensione e sui
costi possono far protendere verso lo sviluppo di hardware dedicato.
3.1 Caratteristiche dei sistemi embedded
Alcuni fattori sono determinanti per un sistema embedded e, per questo motivo, ne
rappresentano i principali vincoli e requisiti in termini commerciali, di hardware e software:
• Peso e dimensioni: caratteristica determinante, soprattutto per i dispositivi mobili, o che non
verranno collocati in una postazione fissa;
• Volume: i volumi di produzione previsti per il sistema rappresentano un fattore rilevante, che
dovrà essere considerato in fase di progetto;
• Costo: è un parametro fondamentale e di impatto per le scelte progettuali (strettamente
connesso ai volumi di produzione);
• Consumo energetico: questo problema dovrebbe essere affrontato in fase di progetto, in
particolar modo per quei sistemi che vengono alimentati da batterie;
• Dimensione del codice: per ragioni di costo e per ridurre l'area occupata, il software dei
sistemi embedded risiede in un supporto di memoria permanente ed integrato sullo stesso chip del
microprocessore. Questa caratteristica inciderà sulla dimensione del codice che, pertanto, dovrà
essere quanto più contenuta possibile;
• Prestazioni: nel caso dei sistemi embedded quest'obiettivo è strettamente dipendente
dall'applicazione. Ma tipicamente, i vincoli che devono essere soddisfatti sono:
- il tempo di reazione ad un evento;
- il tempo di gestione dell'evento, eseguendo il codice ad esso associato.
Questi vincoli prestazionali dovranno trovare riscontro in una soluzione architetturale, nella
quale bisognerà bilanciare anche il costo, adoperando soluzioni miste hardware/software che
renderanno più complesso il processo di progettazione e sviluppo;
•
Tempo reale: progettare il sistema in modo che esso possa operare entro parametri temporali
ben definiti;
•
Affidabilità: sarà possibile quantificare l'affidabilità del sistema (eventualmente fissando una
soglia minima) solo dopo aver effettuato un'attenta e scrupolosa analisi dei potenziali rischi;
•
Manutenibilità: probabilità che il sistema possa essere riparato o sostituito entro un certo
intervallo di tempo;
64
•
Disponibilità: probabilità che il sistema sia funzionante (dipende essenzialmente
dall’affidabilità e dalla manutenibilità);
•
Safety: misura la possibilità che, a fronte di un guasto, il sistema non provochi danni a cose o
persone con cui interagisce. A seconda dell'amibito in cui viene applicata, si definiscono
diversi livelli di safety79;
•
Sicurezza: capacità di resistenza del sistema contro gli utilizzi non autorizzati o non
preventivati in fase di progetto;
•
Time-to-market e flessibilità: nella progettazione di un sistema embedded bisogna valutare
quando porre in prodotto sul mercato. Per questo motivo, per il progetto sarà necessario
opzionare le metodologie e le tecnologie che consentano di giungere al prodotto entro breve
tempo, così da poter cogliere al massimo tutte le opportunità di mercato;
•
Interfacce di comunicazione: tipicamente, il costo di vendita di un dispositivo embedded è
basso, pertanto, la scelta di interfacce di comunicazione diventa critica quando il loro costo
incide in maniera significativa sul prezzo finale del prodotto.
•
Interfacce utente: in alcuni casi, l'interfaccia utente dei sistemi embedded è costituita da
pulsanti e LED, altre volte, invece, viene adoperata l'interfaccia utente di un sistema
ospitante80.
Quando si vuole realizzare un sistema embedded bisogna scontrarsi con tre concetti
fondamentali: l'architettura, le applicazioni e la metodologia di sviluppo.
Infatti, se è vero che nei sistemi informatici general purpose i tre aspetti citati possono essere
sviscerati in maniera relativamente indipendente l'uno dall'altro, nei sistemi embedded essi sono
strettamente interdipendenti.
Ricordiamo che un sistema siffatto dovrà essere sviluppato per realizzare una specifica
applicazione, la cui definizione determinerà un insieme di vincoli, requisiti funzionali e non
funzionali del sistema.
Ad esempio, requisiti funzionali espressi per un sistema embedded potrebbero essere la
capacità di elaborazione o di memorizzazione, le prestazioni (prestazione media e nel worst case,
throughput, ecc.), il consumo di energia e di potenza81,ecc.
Così come, requisiti non funzionali del sistema potrebbero essere limiti di budget (costi di
fabbricazione, di progetto, di manutenzione dell'hardware e del software), limiti di tempo relativi
alla fase di progettazione ed il numero di pezzi da produrre.
79 Esistono diversi standard e metodi per la valutazione della safety quali ad esempio il Safety Integrity Level o SIL.
80 Si pensi ad un sistema embedded interno di un autoveicolo.
81 Durata della batteria e dissipazione del calore
65
3.2 Vincoli dei sistemi embedded
Per la sua natura, un sistema embedded è caratterizzato da aspetti che, sotto un certo punto di
vista, lo rendono unico. Questa considerazione ci spinge a pensare che vi siano alcuni punti cruciali
che non possono essere trascurati prima di intraprenderne lo sviluppo.
Abbiamo, infatti, detto che il mondo embedded ha rappresentato e rappresenta tutt'oggi un
grosso stimolo all'innovazione tecnologica, concetto che non potrebbe esistere senza quello della
creatività.
È quest'ultima che spinge, da un canto alla scoperta di nuove soluzioni e, dall'alto, a trovare
tecniche che consentano di adattare le vecchie soluzioni ai nuovi contesti. Del resto, una importante
ed auspicabile caratteristica di un sistema embedded è certamente la ripetibilità, che, nel caso di
famiglia di prodotto, consente di capitalizzare gli sforzi profusi per qualcosa che si è già sviluppato.
In tal modo, infatti, si eviterebbe di partire daccapo ogni volta che si debba iniziare un nuovo
progetto analogo.
Oltre agli aspetti appena discussi, lo sviluppo di un sistema embedded dovrebbe tener conto
dei vincoli posti sulla durata della fase di progetto, nonché ai costi ad esso correlati (di
progettazione, fabbricazione e manutenzione) e previsti.
Abbiamo, quindi, definito alcuni vincoli dell'attività:
•
Creatività (non è un vincolo);
•
Ripetibilità;
•
Rapidità;
•
Prevedibilità,
i quali non potranno essere soddisfatti senza la definizione di una metodologia di sviluppo adeguata.
I dispositivi embedded sono sistemi complessi, al cui sviluppo partecipano più team e per i
quali l'adozione di una metodologia standardizzata rappresenta una necessità.
Si noti che, per metodologia di sviluppo, non si intende solo un'astrazione o, comunque, una
guida teorica da seguire; piuttosto, essa deve essere definita in termini di strumenti e risorse
disponibili.
3.3 I requisiti di un sistema embedded
La discussione a monte ci guida verso la definizione dei requisiti di progetto che vengono,
tipicamente, richiesti per un sistema embedded. Essi sono classificabili in:
•
Requisiti funzionali;
66
•
Requisiti temporali;
•
Requisiti di affidabilità;
•
Consumo;
•
Prestazioni;
•
Costo,
i quali, spesso, mostrano conflittualità tra loro.
3.3.1 I requisiti funzionali
I requisiti funzionali relativi ad un sistema embedded contengono la specifica della parte
elaborativa del sistema. Pertanto, essi definiscono:
•
quali siano i dati di ingresso e da dove provengano (ad esempio il comando inviato attraverso
un tasto pigiato da un operatore);
•
quali siano i dati di uscita e la loro destinazione (ad esempio un segnale di pericolo
riscontrabile attraverso l'accensione di un LED su di un banco di manovra);
•
quali dati in uscita debbano essere prodotti dal sistema in funzione di quali segnali di
ingresso.
3.3.2 Requisiti temporali
Non di rado, le specifiche tecniche dei sistemi embedded fanno riferimento a vincoli sui tempi
di risposta agli eventi esterni e che possono dar luogo ad una progettazione hardware dedicata.
Tra i requisiti temporali distinguiamo:
•
Deadline: una richiesta molto restrittiva sul massimo tempo di risposta ad un evento.
Si consideri, come esempio, un sistema di controllo dei freni di un veicolo che non potrà
mai ammettere un ritardo imprevedibile fra il comando di frenatura e l'attuazione dello
stesso.
Si distinguono vincoli che rendono un sistema:
− soft real-time, la cui violazione ne comporta un degrado delle prestazioni;
− hard real-time, la cui violazione comporta effetti catastrofici sul sistema e, in alcuni casi,
sull'ambiente circostante.
Nel caso in cui le speciche funzionali non contengano alcun vincolo temporale, invece, si ha
un sistema senza caratterizzazione real time.
67
•
Average: rappresenta un requisito piuttosto generico, in cui viene specificato un ritardo tipico
tra lo "stimolo" e "l'effetto" che ne consegue. Dunque, si tratterà di dimensionare il tempo
medio di risposta ad un evento non eccezionale;
•
Burst: è un requisito rappresentato da una richiesta che non ha alcun impatto sul tempo di
risposta, ma si riferisce alla capacità che dovrà mostrare il sistema nel non perdere eventi
(eventualmente adoperando strumenti hardware).
3.3.3 Requisiti di affidabilità
Per soddisfare i requisiti indicati come di affidabilità, un sistema embedded dovrà essere:
•
Affidabile, cioè dovrà presentare un MTTF82 sufficientemente alto;
•
Sicuro, cioè dovrà essere in grado di gestire casi eccezionali e/o critici. Si noti che, in alcuni
contesti di applicazione dei sistemi embedded (settore quello avionico, militare, ecc.) si
richiede essi la conformità a particolari standard di sicurezza.
•
Riparabile, cioè dovrà mostrare un MTTR83 sufficientemente basso;
•
Disponibile, calcolabile come D = MTTF/(MTTF + MTTR)
3.3.4 Consumo
Il consumo è uno dei requisiti più importanti richiesti ad un sistema embedded. E infatti, esso
ha un impatto diretto sul costo complessivo del sistema e sulla complessità derivata nell'hardware.
Questo problema è particolarmente sentito per i sistemi alimentati mediante batteria, che è
necessario progettare in modo da ridurre il consumo, così da assicurare il maggior tempo di vita
possibile.
3.3.5 Prestazioni
I requisiti prestazionali hanno un impatto su diversi aspetti legati ad un sistema embedded.
Se da un canto, però, migliori sono le prestazioni di un sistema, tanto più saranno influenzati
positivamente gli aspetti connessi ai requisiti temporali ed all'usabilità, d'altro canto, ciò comporterà
un peggioramento negli aspetti collegati al consumo ed ai costi.
Dunque, sarebbe necessario giungere ad un giusto compromesso tra le prestazioni e, in
82 MTTF è l'acronimo di Mean Time To Failure ed indica il tempo medio intercorso tra due errori consecutivi.
83 MTTR è l'acronimo di Mean Time to Repair ed indica il tempo mediamente necessario per ripristinare la funzionalità
del componente, valutato dall'istante in cui si verifica il guasto [18].
68
definitiva, il costo del dispositivo.
3.3.6 Costo
Il costo finale è un aspetto fondamentale, in particolare, per i sistemi prodotti in larga scala.
Esso è fortemente influenzato alle scelte progettuali dell'architettura, dall'hardware utilizzato ,
dagli aspetti legati al software, nonchè dalle licenze hardware e softwarre e dal numero di pezzi da
produrre.
3.4 Lo sviluppo dei sistemi embedded
Il processo di sviluppo di un sistema consta di un certo numero di fasi, per molte delle quali
non sono previsti strumenti di sintesi, la qual cosa rende necesssario effettuare un gran numero di
analisi e simulazioni della specifica applicazione embedded.
Questa considerazione ci porta, però, a scontrarci con un'ulteriore difficoltà: infatti, a causa dei
vincoli posti sulla durata della fase di progetto e sui costi legati al suo sviluppo, non sarà possibile
simulare accuratamente tutto il sistema.
In più, per progettare architetture eterogenee sono necessari strumenti sofisticati e, di
conseguenza, molto costosi; inoltre, tipicamente, le metodologie adoperate per il software sono
differenti rispetto a quelle utilizzate per l'hardware.
Basti pensare al metodo di sviluppo hardware a sintesi digitale, nel quale si ravvisano tecniche
sofisticate84 del tutto assenti nelle tecniche di sviluppo software. Relativamente a questo caso, le
differenze tra il caso hardware e software è giustificato dal fatto che, nel progetto dell'hardware, le
metriche di valutazione del prodotto sono facilmente quantificabili ed oggettive. Inoltre,
tipicamente, ogni metrica rappresenta un vincolo progettuale molto stringente che deve essere
ottimizzato. Ancora, i cicli di sviluppo dell'hardware sono in genere più brevi di quelli del software.
Tutte queste considerazioni suggeriscono di adottare una strategia di sviluppo ibrida, in parte
ricavata dal mondo software, in parte da quello hardware.
3.4.1 Il modello di sviluppo a cascata
Il modello di sviluppo a cascata (Royce, 1970), consta di sei fasi principali:
•
Studio di fattibilità;
•
Analisi e specifica dei requisiti;
84 Esempi di tecniche di sviluppo hardware assenti in quelle software sono, ad esempio: gli algoritmi per la stima deòòe
metriche (come consumo di energia, area occupata, ecc.), Algoritmi predittivi per valutare i modelli che operano su
definizioni incomplete del progetto, ecc.
69
•
Progetto:
- progetto architetturale, in cui si definisce la struttura generale del sistema,
- progetto in dettaglio, in cui si definiscono i singoli moduli;
•
Codifica, in cui le parti vengono implementate ed integrate con l'hardware;
•
Collaudo;
•
Manutenzione.
Si può notare che le fasi di sviluppo sono organizzate in una rigida gerarchia, secondo la quale
per progettare un livello sarà necessario definire il livello immediatamente superiore [19]. Viene da
sè che, in un modello siffatto, sarebbe molto costoso apportare modifiche al un livello
gerarchicamente superiore, mentre è in corso la definizione di un livello inferiore, poichè
comporterebbe la riesecuzione della fase successiva.
Vi sono alcuni problemi che dovranno essere affrontati nella fase di progetto.
Innanzitutto, poichè un sistema embedded è costituito sia da componenti hardware che da
Illustrazione 21: Fasi dello sviluppo software
secondo il modello a cascata
70
componenti software, per ogni modulo sarà necessario stabilire quali funzionalità debbano essere
implementate via hardware e quali via software.
Il partizionamento hardware/software è un problema complesso di ottimizzazione, in cui si
deve tener conto di diversi fattori (costi, competitività del prodotto, prestazioni, hardware
proprietario) che, spesso, sono in conflitto tra loro. Proprio la conflittualità tra essi può ostacolare il
raggiungimento di una soluzione completamente soddisfacente. Piuttosto, si raggiungerà un prodotto
frutto di un compromesso necessario per il soddisfacimento delle esigenze del cliente.
Illustrazione 22: Metodologia di sviluppo per sistemi embedded
Dunque, dalla fase di elicitazione ed analisi dei requisiti si dovrà determinare un opportuno e
necessario partizionamento hardware/software, dopo del quale bisognerà definire l'architettura
71
generale del sistema embedded e, naturalmente, l'interfacciamento tra le due logiche.
A valle di ciò, sarà necessario determinare le specifiche dell'hardware e del software.
Il vantaggio di questa metodologia risiede, quindi, nella possibilità di realizzare componenti
hardware e software separatamente e contemporaneamente.
Illustrazione 23: Partizionamento HW/SW
Naturalmente, il processo di partizionamento diventa maggiormente preciso con l'aumentare
della conoscenza del sistema.
Inoltre, bisognerà capire quali moduli hardware o software debbano essere realizzati ex novo e
quali, invece, possano essere riusabili oppure acquistabili all'esterno.
Un' altra attività molto delicata (e costosa in termini di tempo) sarà quella dell'integrazione85
hardware/software.
85 Il processo di integrazione consiste nella verifica del corretto funzionamento delle specifiche e nell'eventuale analisi
delle risposte sistema a fronte di sollecitazioni non previste. Essa richiede tool specifici per la piattaforma che si
adopera e che, spesso, deve essere realizzata ad hoc.
72
Illustrazione 24: Costo necessario per risolvere bug durante il CVS
Si noti che spesso i sistemi embedded vengono sviluppati definendo, o comunque utilizzando,
una piattaforma di riferimento. Si tratta di un dispositivo, o un'architettura di base, facilmente
modificabile al fine di apportare cambiamenti a funzionalità esistenti o per realizzarne di nuove.
Questa strategia diviene particolarmente utile qualora il sistema dedicato debba realizzare delle
funzioni definite e regolate dagli standard.
Illustrazione 25: Sviluppo di sistemi embedded basati su piattaforma
73
Questo approccio allo sviluppo consta di due fasi: la prima, nella quale viene definita la
piattaforma (funzionalità di base, prestazioni e riconfigurabilità) e la seconda, in cui la piattaforma
definita viene utilizzata per progettare uno specifico prodotto, basato su di essa.
3.4.2 Un approccio di tipo evolutivo
Nei modelli evolutivi ci si pone l'obiettivo di superare i limiti del modello a cascata, al fine di
ottenere una maggiore flessibilità [19]. Essi vengono adoperati, prevalentemente, per le fasi di
progettazione e realizzazione del software.
Appartiene a tale categoria il modello a spirale (Bohem 1988), nel quale lo sviluppo è
interpretato come un processo incrementale, costituito da piccoli passi consecutivi.
Esso combina la natura iterativa della prototipazione e quella controllata e sistematica del
modello lineare-sequenziale.
Relativamente allo sviluppo software, tale metodologia prevede che ogni ciclo sia costituito da
tutte le fasi (che potremmo sintetizzare in requisiti, architettura e codifica) e che ciascuno di essi dia
luogo ad una versione più dettagliata86 del prodotto87, poichè ogni ciclo incamera la conoscenza e
l'esperienza maturate nei cicli precedenti. La versione ottenuta al termine di ciascun ciclo può essere
un progetto, un prototipo, oppure un prodotto software.
Pertanto, il primo ciclo corrisponderà un raffinamento della conoscenza che porterà alle
specifiche, mentre i successivi condurranno via via a prototipi sempre più completi.
Illustrazione 26: Metodologia di
sviluppo software a spirale
La metodologia a spirale consta di alcune fasi che si ripetono ciclicamente:
•
comunicazione con il cliente;
86 Ogni versione successiva introduce correzioni, miglioramenti e nuove caratteristiche.
87 Si noti che il punto di partenza potrà essere anche un prototipo cartaceo.
74
•
pianificazione;
•
analisi dei rischi;
•
strutturazione;
•
costruzione e rilascio;
•
valutazione da parte del cliente.
Si noti, però che le attività da svolgere non sono fissate, bensì variano a seconda della
complessità del progetto.
Naturalmente, al contrario del rigido modello a cascata, quello a spirale consentirà di apportare
modifiche e raffinamenti in ogni fase, con costi notevolmente ridotti.
Questo approccio, però risulta particolarmente rischioso nelle circostanze in cui il processo
debba essere fortemente controllato; infatti, nel modello a spirale risulterebbe particolarmente
costoso (dunque antieconomico) produrre tutta la documentazione a corredo di ciascuna attività
svolta.
3.4.3 Modello a V
Laddove l'affidabilità, la sicurezza, la qualità rappresentano requisiti imprescindibili, così
come accade nei sistemi embedded, il modello di sviluppo tipicamente utilizzato è quello a cascata.
Nonostante i limiti mostrati88, esso garantisce l'esecuzione di un insieme ben strutturato di
attività89. Del resto, esso consente di realizzare progetti i cui prodotti (cioè gli output delle
attività svolte) vengono costruiti, almeno teoricamente, in maniera sequenziale. E infatti, l'ordine
con cui vengono eseguite le attività consentono, in qualche modo, di abbassare i costi ed i tempi di
sviluppo.
Il modello a cascata si basa sui due seguenti presupposti:
•
tutti i requisiti utente sono chiari e la tecnologia è nota agli sviluppatori ed al committente;
•
il committente accetta che nell'ultima fase temporale del progetto venga messo in esercizio
tutto l'output prodotto.
Potrebbbe, però, accadere che il committente accetti che i risultati siano consegnati nella fase
finale del progetto, ma che non riesca ad esprimere in modo completo i requisiti utente, oppure che
la tecnologia adottata non sia conosciuta, piuttosto che instabile.
Il modello a V nasce dal modello a cascata, per far fronte a situazioni come quella appena
88 Il modello a cascata diviene rischioso laddove si voglia sviluppare un sistema di cui non si hanno sufficienti
conoscenze e competenze pregresse rispetto al dominio applicativo e di business.
89 Analisi, analisi del rischio, pianificazione, tracciabilità dei requisiti, assicurazione della qualità, versioning, ecc.
75
descritta.
Come mostrato in figura 28, il modello a V è caratterizzato:
•
da interazioni anche non locali tra le varie fasi;
•
dalla presenza di ricicli, non solo alla fase precedente;
•
dalla presenza di una fase di revisione critica dell'intero progetto.
Quest'ultima caratteristica rappresenta un'attività di basilare importanza affinchè si inneschi un
processo di apprendimento che veda coinvolti il committente e gli sviluppatori, i quali svilupperanno
la conoscenza e coscienza adeguata per la gestione anche di progetti futuri.
Illustrazione 27: Modello a V
Tipicamente, il modello a V è caratterizzato da 9 fasi di sviluppo "simmetriche" nella misura in
cui da una fase si possa riciclare sia quella precedente che quella che si trova alla stessa altezza nello
schema.
In ciascuna fase del processo bisognerà redigere un documento formale, l'output, che dovrà
essere approvato dall'organo responsabile dell'intero progetto.
Va da sè che, in un modello siffatto, le modifiche dovute, ad esempio, a ripensamenti da parte
del committente, hanno un impatto prevedibile90.
90 Così come sono prevedibili i tempi ed i costi del progetto (questa caratteristica è del modello a cascata).
76
3.4.3.1 Le fasi del modello a V
1) Preanalisi/studio di fattibilità:
L'obiettivo di questa fase è stabilire l'opportunità economica del progetto, in termini di costi e
benefici. Pertanto, consisterà anche nell'esaminare le alternative di realizzazione possibili e nella
scelta di una soluzione tra queste. Le decisioni prese a questo punto del progetto non saranno
definitive, poichè i requisiti utente, così come la tecnologia, non sono ancora completamente noti.
Nel corso dello studio di fattibilità, così come nelle tre successive fasi, è opportuno prendere
decisioni che siano quanto più possibile indipendenti l'una dall'altra. Questo modo di operare
renderà più agevole apportare una eventuale modifica.
2) Elicitazione ed analisi dei requisiti utente:
I presupposti su cui di fondano queste due attività sono relativamente instabili, poichè a questo
punto del progetto è improbabile che il committente sia in grado di esprimere completamente i
propri obiettivi.
Sulla scorta di questa considerazione, è fondamentale che il documento formale redatto alla
fine dell'attività sia "modulare". In pratica, esso dovrà essere sintetico (nella giusta misura) e dovrà
risultare leggibile per i committenti e gli utenti che, pur non avendo ancora chiare le esigenze e gli
obiettivi, potranno approvarne i contenuti.
3) System design:
In questa fase viene redatto il documento contenente la descrizione dettagliata
dell'architettura hardware e software dell'intero sistema da realizzare e quella del sistema di
sviluppo. Tale documento dovrà essere modulare, in particolare rispetto alle componenti
tecnologiche meno sperimentate, quindi meno conosciute.
4) Program design:
Sulla scorta delle funzionalità descritte in fase di elicitazione ed analisi e sulle specifiche
tecnologiche definite in fase di System design, verranno documentati dettagliatamente tutti i moduli
software91 da implementare. Essi verranno riportati nel documento formale, che rappresenta l'output
di tale fase.
5) Programmazione/codifica:
In questa fase, vengono prodotti i programmi e la documentazione necessaria per la loro
manutenzione; mentre, a differenza di ciò che accade nel modello a cascata, ancora non vengono
prodotti i manuali d'uso per l'utente.
6) Program test (simmetrica alla fase di Programmazione/Codifica):
In questa fase vengono prodotti e popolati dei data base di prova, allo scopo di verificare le
91 Transazioni, programmi, procedure, ecc.
77
funzionalità e le prestazioni di ogni modulo realizzato. La documentazione prodotta in questa sede
contiene le prove eseguite e, naturalmente, il loro esito.
È proprio in corrispondenza di questa fase che il committente inizierà a rendersi conto delle
funzionalità reali92 offerte dal sistema; pertanto, potrà capitare - anche con una certa frequenza - di
dover intervenire al livello di programmazione/codifica, ma anche rispetto all'associazione nei
moduli delle varie funzionalità (fase di program design).
A questo punto, per ciascun modulo accettato, sarà redatto il documento utente.
7) System test (fase simmetrica a System Design):
Una volta terminato il test di tutti i programmi, i realizzatori, con l'assistenza degli utenti di
riferimento, eseguiranno un test sulle prestazioni globali del sistema. Esso dovrà verificare che le
prestazioni complessive siano accettabili e che le macro funzioni93 (come la regolamentazione degli
accessi, la sicurezza, ecc.) siano realizzate correttamente.
Riguardo le parti non accettate, si tornerà alla fase di System design e verranno apportate le
opportune modifiche e/o corrrezioni.
Al temine della fase verrà prodotta la documentazione necessaria per l'installazione e la
gestione del sistema.
8) Accettazione da parte dell'utente (simmetrica riespetto alla fase di Elicitazione ed Analisi):
Questa fase non è esplicitamente presente nel modello a cascata, poichè si ritiene che le fasi di
elicitazione ed analisi dei requisiti e quella di test siano sufficienti ad assicurare l'aderenza del
prodotto alle esigenze rappresentate.
Nel modello a V è, invece, necessario esplicitare la presenza di tale controllo finale, così da
garantire che tutti i requisiti (impliciti ed espliciti) siano soddisfatti. Qualora ciò non accadesse, sarà
necessario tornare alla fase di elicitazione ed analisi dei requisiti.
Durante questa attività verrà controllata tutta la documentazione disponibile.
9) Messa in esercizio e review del progetto:
In quest'ultima fase verrà completata l'installazione dell'hardware, del software e verranno
generati e popolati i data base di gestione. Naturalmente, in questa fase bisognerà prevedere anche
l'addestramento degli utenti finali del prodotto.
La messa in esercizio è un'attività lunga, che può anche terminare con la cancellazione
dell'intero progetto, qualora non sia realmente possibile adoperare i suoi prodotti. In quest'ultimo
caso,attraverso un'attenta e documentata review del progetto, tutto il lavoro svolto costituirà una
base più solida di conoscenza e competenza. Dunque, potrebbe essere necessario tornare alla fase
92 La fase di definizione dei requisiti evidenzia l'incertezza dei committenti ed utenti, che nella fase corrente vengono
posti dinnanzi a qualcosa di concreto.
93 Tra le macro funzioni, rivestono un ruolo molto importante quelle di sistema, come la sicurezza.
78
dello studio di fattibilità.
Il principale punto di forza del modello a V è la gestione dei ricicli, che diviene più efficiente
quando ci si aspetta di dover controllare maggiormente quelli relativi alla parte bassa.
Infatti, in tal caso, con l'avanzamento del progetto, le stime dei costi e dei tempi (fattori critici
nello sviluppo di un sistema embedded) diventano sempre più attendibili.
Naturalmente, una adeguata gestione presume che durante lo studio di fattibilità vi sia
un'attenta analisi dei rischi che serve a garantire la controllabilià dei ricicli nel modello.
Come accade nel modello a cascata, anche in quello a V le risorse specialistiche impiegate in
ciascuna fase vengono rilasciate al termine di essa, ma a differenza del primo, tali risorse potranno
essere ancora necessarie per lo svolgimento della fase ad essa simmetrica.
L'applicazione più valida del modello a V riguarda il caso in cui un'azienda vuole procedere
con la prima informatizzazione di un dato settore, per il quale non è stata maturata un'esperienza
sufficiente derivante da progetti conclusi con successo.
79
Capitolo 4
Le metodologie agili
L'idea del cambiamento come una necessità del business, ha spinto gli studiosi a cercare
nuove metodologie di sviluppo software. Frutto di queste attività è, tra gli alti, l'approccio Agile.
In effetti, ci si può riferire ad esso come una disciplina in contrapposizione o in complemento
alle metodologie tradizionali94, definite "heavyweight". Ma, l'utilizzo dell'una o delle altre dipende,
fondamentalmente, dai risultati che si vogliano ottenere.
Alla base delle metodologie agili vi è l'idea di raggiungere l'obiettivo per passi, focalizzandosi
su di un piccolo e ben definito risultato per volta, costruendo con un processo iterativo l'intero
sistema.
I metodi "pesanti", come quello a cascata, semplificano il controllo dell'andamento del
progetto mediante la scomposizione e la specificazione del ciclo di vita in fasi successive e ben
definite, in cui l'output di ogni fase (milestone) rappresenta l'input della successiva.
Naturalmente, questa caratteristica, se da un canto rappresenta il maggior punto di forza
dell'approccio tradizionale, d'altro canto diviene una criticità in quei progetti in cui i requisiti mutano
velocemente e/o non siano completamente elicitabili nella prima fase di sviluppo.
Illustrazione 29: Fasi del waterfall
model
Illustrazione 28: Fasi dei modelli
iterativi
Per questo motivo, sono nati i modelli iterativi, in cui le stesse fasi del waterfall model sono
eseguite su porzioni del sistema incrementalmente, consentendo di apportare modifiche
iterativamente e correzioni, tornando dalla fase di testing a quella di pianificazione.
Le discipline agili, sottoclasse dei modelli evolutivi, nascono verso la fine degli anni '8095, con
l'idea di risolvere problemi ricorrenti correlati alla conduzione di progetti software. Esse non
94 "Pesanti" come il modello a cascata e quello iterativo.
95 A partire dagli anni '80, sulla scorta delle innovazioni metodologiche introdotte in diversi settori (come il sistema di
propulsione Toyota), alcuni autori hanno proposto processi software adattativi e leggeri.
80
presentano caratteristiche "predittive" rispetto all'evoluzione del sistema software, ma propongono
valori e pratiche da adottare, al fine di "adattarsi" all'evoluzione dei requisiti utente, prima che del
sistema software [20].
Un'importante constatazione che ha spinto verso questo approccio riguarda la natura mutevole
nel tempo dei requisiti di un progetto. Pertanto, nell'ottica della pianificazione delle attività, i
requisiti iniziali potrebbero risultare un punto di partenza inadeguato.
L'adozione di un approccio è strettamente vincolato alla natura dei requisiti utente: del resto,
sebbene averne cognizione definitiva già dal principio sia un aspetto desiderabile in qualunque
progetto software, ciò avviene raramente. Inoltre, anche se accadesse, la fase di progettazione
potrebbe ugualmente presentare qualche difficoltà.
Sulla scorta di queste considerazioni, nelle metodologie agili i vincoli principali dei progetti
diventano i tempi, i costi e la possibilità di favorire la gestione del cambiamento dei requisiti.
Naturalmente, per poter operare in tal modo, è richiesta la suddivisione in singoli componenti
indipendenti delle funzionalità, al fine di poterne valutare i tempi, i costi e la possibilità di
completarli procedendo per piccoli incrementi progressivi. In tal modo, viene agevolata anche la
suddivisione dei compiti e delle responsabilità ai componenti del team di sviluppo.
In definitiva, i Metodi Agili [21] sono un insieme di tecniche di sviluppo software che si
focalizzano sullo sviluppo ed il rilascio incrementale (ed in tempi brevi) di porzioni del sistema, che
siano usabili.
4.1 Il processo Agile
A differenza delle metodologie "pesanti", quelle agili sono caratterizzate da un processo
iterativo scomposto in fase di progettazione, di sviluppo e test96 di breve durata.
Tipicamente, i Metodi Agili si basano su di una disciplina rigorosa che dà vita ad un processo
ben definito; si noti, però, che quest'ultimo è di tipo adattativo: si adatta, cioè, alle esigenze del
committente, che possono mutare durante lo sviluppo. Quest'ultimo di focalizza su gruppi di
funzionalità ed è guidato dalla necessità di rilasciare prodotti di progetto usabili.
Dunque, gli artefatti possono considerarsi "leggeri", cioè manca la "pesante" documentazione.
Il lavoro di progettazione, anzichè essere concentrato nella sola parte iniziale, è continuo e
distribuito lungo tutte le fasi del processo. Pertanto, anche le parti già realizzate sono soggette a
modifiche, al fine di migliorare l'architettura del software.
96 Testing: la verifica automatica del corretto funzionamento del sistema è uno degli aspetti più rilevanti delle
discipline agili. Essa si applica al codice, ai dati, ai modelli. Laddove non sia possibile un test automatico, la
verifica sarà eseguita manualmente da personale di pari esperienza.
81
Illustrazione 30: Fasi del processo di sviluppo Agile
Secondo Highsmith e Cockburn (2001):
“what is new about agile methods is not the practices they use, but their recognition of people as the
primary drivers of project success, coupled with an intense focus on effectiveness and
maneuverability”.
In questo contesto, si suppone che il progredire del tempo non faccia aumentare i costi del
cambiamento, bensì essi si stabilizzano ad un valore modesto.
Esistono diverse Metodolie agili tra cui:
•
Extreme Programming (XP) [22];
•
Dynamic Systems Development Method (DSDM) [23];
•
SCRUM [24];
•
Feature Driven Development (FDD) [25];
•
Crystal Family [26];
•
Adaptive Software Development (ASD)[27];
•
Agile Modeling [28].
82
Tutte queste aderiscono ai principi elencati nel cosiddetto Agile Manifesto
4.2 Il Manifesto Agile
L’“Agile Movement” [29]è nato ufficialmente nel 2001 quando un gruppo di sviluppatori e
consulenti ha redatto l' “Agile Software Development Manifesto”, [30].
Questo documento enfatizza non solo la necessità di implementare velocemente i cambiamenti
di requisiti durante lo sviluppo, ma anche la cultura della responsabilità personale, il rispetto e la
collaborazione tra gli individui.
I valori fondamentali sono ravvisati nei seguenti quattro punti (cfr. Appendice):
•
Le persone e le interazioni prima dei processi e degli strumenti. Ciò nasce dall'idea che un
soggetto, solo se opportunamente stimolato, possa produrre un sistema di migliore qualità ed
in tempi contenuti. Pertanto, l'importanza viene spostata sui singoli, così da stimolarne la
creatività, e sulla comunicazione tra di essi, così da promuovere la condivisone di
conoscenza.
•
L'obiettivo è realizzare e rilasciare, ad ogni passo, parte di progetto che sia usabile. Il codice
deve essere semplice in modo da poter essere compreso facilmente riducendo la necessità di
una documentazione esaustiva;
•
La negoziazione contrattuale è meno importante della collaborazione con il cliente, in modo
che sia quest'ultimo a "trainare" lo sviluppo del progetto.
La relazione e la collaborazione tra gli sviluppatori e il cliente è da preferirsi rispetto a
contratti stringenti. Lo sviluppo agile si focalizza sul produrre valore per il cliente già nelle prime
fasi del progetto, in modo da ridurre i rischi di una cattiva comprensione dei requisiti ed il non
soddisfacimento delle esigenze del cliente.
•
Risposta ai cambiamenti dei requisiti e dell'ambiente circostante, piuttosto che l' aderenza
alla pianificazione, che risulta difficilmente realizzabile. Le brevissime iterazioni richiedono
una pianificazione continua, questo significa che il team di sviluppo ed il cliente possono
apportare modifiche in ogni momento per soddisfare nuove esigenze.
4.3 Alcune metodologie agili
Quello agile rappresenta un vero e proprio movimento, divenuto noto grazie al progetto XP
(Extreme Programming), sviluppato da Kent Beck97 per Daimler Chrysle, con la collaborazione di
Ward Cunningham. Nella XP si inseriscono diverse pratiche, tra le quali il refactoring del codice,
97 Kent Beck è un esperto informatico, pioniere dell'XP e dell'uso di template nel software. Ha ideato i file CRC, il
framework per il testing xUnit, ecc.
83
formalizzato da Martin Fowler [31].
Essa rappresenta, principalmente, una metodologia di gestione del progetto, fondandosi sui
seguenti valori fondamentali: la comunicazione98, la semplicità99, il feedback100, il coraggio101, il pair
programming102, il testing103, il refactoring104, standard e proprietà collettiva105, i rilasci piccoli e
frequenti106, l' integrazione frequente e seriale107.
Sulla scorta della XP nasce SCRUM, un metodo agile per la gestione di progetti software, in
cui viene ribadito il concetto di ciclo di sviluppo costituito da un grande numero di iterazioni di
breve durata, caratterizzato da brevi meeting e sprint produttivi108
In particolare, tale disciplina di gestione del processo funge da contenitore di pratiche di
ingengeria del software già esistenti.
SCRUM è basato su di un approccio iterativo ed incrementale, studiato per quei sistemi i cui
requisiti mutano velocemente; la sua adozione consente di migliorare la comunicazione tra le
persone coinvolte e massimizzarne la cooperazione.
98 In XP c’è una forte comunicazione tra tutti gli attori coinvolti: gli sviluppatori, il management ed il cliente.
99 Il risultato deve essere semplice e risolvere il solo ambito del problema che è stato posto: non deve cercare di
anticipare i problemi futuri ma concentrarsi sulla soluzione del problema contingente. Lo sviluppatore deve pensare
in piccolo, concentrando lo sforzo in un ambito ristretto.
100Il sistema è costantemente verificato, in modo da assicurarne la consistenza in ogni momento. Questo avviene
tramite la creazione di test di unità che possono essere eseguiti dalla macchina stessa.
101Se si rende necessario modificare quello che è stato fatto in precedenza, in prima persona o da un altro sviluppatore
del team, è necessario procedere senza timore cambiando strada per rimanere vicini all’obiettivo. Questi valori sono
applicabili ai diversi aspetti dello sviluppo software: dalla gestione (management), alla progettazione, allo sviluppo,
fino alla documentazione.
102Extreme Programming prevede che per ogni postazione di lavoro siano presenti due persone. Lo scopo del secondo
sviluppatore è quello di verificare che il primo sviluppatore scriva il codice in modo corretto eventualmente per
sollevare potenziali problemi o proporre vie alternative di sviluppo.
103Prima di scrivere il codice dell’applicazione, viene scritto quello di test. Vengono identificati pochi ma sostanziali
test che mettano in luce eventuali malfunzionamenti del codice e se ne codifica l’implementazione. Una volta scritto
il test, si passa allo sviluppo del codice vero e proprio.Si noti che, quando si presenta un bug viene creato subito un
test per evidenziarlo.
104Il sistema è soggetto a continua riscrittura, volta a lasciare il codice nel più semplice stato possibile così da
consentire l’implementazione delle funzionalità richieste. Nessuna funzionalità viene aggiunta prima che sia
effettivamente necessaria.
105La codifica avviene secondo standard definiti, per promuovere la proprietà collettiva del codice. Tutti gli sviluppatori
sono responsabili dell’intero sistema e possono in qualsiasi momento intervenire per eseguire gli eventualmente
necessari refactoring. Gli sviluppatori dovrebbero inoltre cambiare spesso collega e parte del progetto su cui
lavorano, per essere aggiornati sul funzionamento delle altre parti del sistema ed eventualmente per acquisire skill
differenti. Lo sviluppo avviene da parte della collettività, senza specializzazioni verticali.
106I rilasci del software sono il risultato di iterazioni molto brevi, dove poche e piccole funzionalità vengono
implementate nel sistema e subito rilasciate al cliente per il test di accettazione.
107L’integrazione delle modifiche nel sistema viene fatta frequentemente, in modo da limitare i conflitti che il nuovo
codice (ed il codice di test) potrebbe dare. Inoltre, questa procedura avviene in modo strettamente sequenziale: solo
uno sviluppatore alla volta integra le sue modifiche con il sistema, testa e rilascia il codice. Questo, assieme alla
programmazione collettiva, consente di risolvere in modo semplice le tipiche problematiche di integrazione su una
stessa base di codice del lavoro di diverse persone.
108 SCRUM prevede meeting di dieci minuti al giorno e sprint produttivi di un mese. All’interno di questa iterazione,
sono presenti sotto-iterazioni di 24 ore, scandite da un meeting di inizio giornata, per far emergere eventuali problemi
da gestire e per sincronizzare il team su quanto fatto nel giorno precedente e su quanto si intende fare nel giorno
successivo. Alla fine dello sprint, il team di sviluppo fornisce la nuova funzionalità dimostrabile al cliente.
84
È bene notare, che nel passaggio tra XP e SCRUM hanno preso vita un certo numero di
metodologie mirate alla modellazione e documentazione dei sistemi software con enfasi
sull'obiettivo109, altri che adottano i concetti agili nello sviluppo dei database110, altri ancora che
pongono l'enfasi sulle funzionalità richieste dal cliente111.
4.4 Metodologie tradizionali vs Metodologie agili
Nel contesto attuale, la gestione della qualità ha assunto un carattere più complesso,
concentrandosi sulla cura della soddisfazione del cliente, da cui deriva una particolare attenzione
alla riduzione dei difetti nel prodotto.
Del resto, anche nel project management vi è stato un cambio di rotta, nella misura in cui,
passando per il controllo di tempi e costi, si è consolidato l'obiettivo di massimizzare il valore di
business per il cliente. Pertanto, un project manager dovrebbe conoscere ed applicare processi di
gestione dei livelli di qualità, mirati a garantire i risultati del progetto.
Queste considerazioni spingono verso l'idea che nell'attuale realtà aziendale è necessario
mettere in atto sia processi di project management tradizionali, sia i principi delle metodologie agili.
Non vi è, infatti, alcun motivo per contrapporre il controllo all'agilità, piuttosto che la
prevedibilità alla creatività. In definitiva, sarebbe necessario estrapolare i concetti migliori delle due
discipline, così da pervenire ad un approccio più flessibile. Ciò richiede una conoscenza di entrambe
le metodologie, in maniera tale da non imporre la soluzione, bensì arrivare ad essa attraverso la
comprensione delle caratteristiche dell'ambiente in cui applicarla.
In effetti, che si tratti di tradizionali o agili, le metodologie di sviluppo sono applicate per
rispondere in modo efficiente alle esigenze del mercato e dei clienti finali; dunque, è necessario
conoscere i diversi approcci, così da valutare quale applicare al caso specifico.
Sulla scorta di quanto detto, prima di decidere quale metodologia applicare, il Project Manager
dovrebbe chiedersi quale possa essere l'impatto di quella Agile sulle metodologie di project
management esistenti; quale sia il punto di incontro tra l'approccio adattativo e quello basato sulla
pianificazione; quale dei due sia più adeguato al dominio del cliente.
Per poter meglio comprendere i concetti appena esposti, mostiamo le principali differenze tra
l'approccio agile e le metodologie basate sulla pianificazione preventiva112.
Tabella 4: Metodologia a cascata vs Agile (SCRUM)
109Agile Modeling.
110Agile Data.
111Feature Driven Programming.
112Si parla di metodologie Plan-Driven o Waterfall.
85
Metodologia a cascata
Definizione dei requisiti
Agile (esempio SCRUM)
Requisiti dettagliati, definiti prima
Definizone di alto livello del
dell'avvio del Design e dello Sviluppo
prodotto;
Requisiti di dettaglio definiti
gradualmente, in base
all'avanzamento del Design
Pianificazione
Forte enfasi sulla pianificazione preventiva Pianificazione a finestra mobile;
Rinvio delle decisioni finché
possibile
Controllo del contenuto
Approccio al Project
Il controllo del contenuto è essenziale per
Il contenuto può cambiare ed
controllare i costi ed i tempi
aumentare, in modo da soddisfare le
(schedulazione)
esigenze del cliente
Enfasi sul controllo di costi e tempi
Enfasi sulla flessibilità ed
Management
adattabilità, così da soddisfare le
esigenze di business
Come mostrato, l'approccio a cascata si fonda sull'idea di acquisire ed analizzare tutti i
requisiti del progetto prima di avviare la fase di disegno dell'applicazione; al contrario, quello Agile
è basato sulla pianificazione per fasi successive (sprint), rinviando le decisioni quanto più
possibile113.
Ancora, nel primo dei due metodi vi è una stima dei tempi e dei costi iniziale, che diventano
vincoli di progetto, ai quali è sottoposto anche "il contenuto" (che, per questo, dovrà essere
controllato).
Quindi, sarebbe necessario eseguire un controllo sui tempi e sui costi nella giusta misura114
[32].
L'approccio adattativo, invece, risulta più flessibile, nella misura in cui i requisiti possano
essere modificati, così da soddisfare tutte le necessità di business.
Queste diversità mettono in luce, da un canto il controllo esasperato dei tempi e dei costi,
dall'altro la spasmodica ricerca della soddisfazione del cliente: aspetti che potrebbero coesistere,
evitando l'estremizzazione.
Naturalmente, pur avendo una buona conoscenza delle due metodologie, bisogna che essa sia
scevra da percezioni errate, poichè, nella realtà, la scelta del metodo da applicare dipende dal livello
di controllo desiderato e dal livello di flessibilità che si vuole dare al processo.
113Dato che lo sviluppo del software è sempre associato con qualche incertezza, i risultati migliori dovrebbero essere
raggiunti con un approccio basato sulle opzioni, rinviando le decisioni il più possibile fino a che non può essere
effettuata sulla base di fatti e non su previsioni ed ipotesi incerte [33].
114Si consideri che molti progetti non raggiungono il risultato atteso per rispettare i limiti di budget e la schedulazione
86
Tabella 5: Luoghi comuni sugli approcci a cascata e Agile
Waterfall
Agile
Troppa carta
Nessun processo
Molte checklist
Caotico, disordinato
Processi sofisticati
Non idoneo per progetti complessi
Guidano i processi e non le persone
Poco professionale, poichè informale
Eccessiva attenzione alla schedulazione
Eccessiva attenzione alle richieste di modifica
e poca schedulazione
Un'idea errata è quella che vede l'approccio tradizionale poco orientato alle persone, rispetto a
quello Agile: in realtà, un approccio più formale fornisce uno stimolo solo se il team di sviluppo è in
grado di svolgere in maniera responsabile il proprio lavoro. Pertanto, la fiducia è strettamente
connessa al controllo.
Entrambi i metodi si pongono l'obiettivo di gestire i rischi del progetto e rimuovere le
incertezze, cosa che necessita di una pianificazione.
Dunque, sarebbe erroneo pensare che l'approccio tradizionale sia caratterizzato da un'eccessiva
pianificazione preventiva, mentre quello agile non preveda alcun piano. Quest'ultima, infatti, adotta
una pianificazione "a finestra mobile115".
In definitiva, i potenziali benefici legati all'approccio agile sono:
• Maggiore attenzione ai risultati di business, poichè l'utente è più coinvolto nelle attività;
• Maggiore produttività e costi ridotti, grazie alla cooperazione massiva tra utente ed esperto;
• Maggiore efficienza organizzativa e team più motivato;
• Minore time to market, poichè l'approccio iterativo velocizza lo sviluppo;
• Qualità (potenzialmente) più alta, poichè il test è parte integrante dello sviluppo.
D'altro canto, non esiste un modo standard di avviare lo sviluppo agile e, in alcuni casi,
possono verificarsi situazioni in cui è necessario ricorrere ad un approccio più formale: quello
tradizionale.
Infatti, l'adozione del primo metodo deve tener conto delle difficoltà correlate alla creazione di
un ambiente realmente collaborativo116, alla necessità di un forte coinvolgimento del management
dell'organizzazione117, ai vincoli posti dal business, ecc.
Del resto, l'adozione di un approccio tradizionale, con l'enfasi posta sui controlli, può dar
luogo a ritardi nel time to market.
Nella realtà dei fatti, l'adozione dell'approccio a cascata resta valido quando, in un ambiente
115 Pianificazione detta anche "just-in-time".
116Non è sempre possibile richiedere la massima disponibilità da parte del cliente, ad esempio.
117 Collaborazione dello Sponsor, adeguata formazione dei partecipanti, cambiamento culturale.
87
prevedibile, l'attenzione debba essere concentrata sul controllo dei costi e schedulazione.
Altresì, laddove la spinta principale è data dalla soddisfazione dell'utente, un approccio del
genere pone alcune limitazioni al successo del prodotto.
È bene notare, infatti, che esistono punti di vista contrastanti rispetto all'adozione dei metodi
agili come soluzione a qualsiasi tipo di problema di sviluppo. Infatti, pur presentando indubbi
vantaggi se applicati in contesti specifici, in altri la loro applicazione risulta inefficace e/o difficile,
se non impossibile.
Si ritiene che i Metodi Agili non siano applicabili in contesti quali[34]:
•
Ambienti distribuiti118;
•
Produzione di componenti riusabili;
•
Sviluppo eseguito da gruppi numerosi di persone;
•
Software Safety-Critical;
•
Sviluppo di sistemi grandi e complessi
Tipicamente, tale approccio viene adoperato nella produzione di software volto alla
risoluzione di una specifica esigenza. Infatti, è bene notare che i contenuti tempi di sviluppo possono
rappresentare un ostacolo per l'implementazione di soluzioni generiche, quindi riusabili.
Del resto, uno dei capisaldi dello sviluppo Agile è:
“there is no need to design for change because any change can be effectively handled by refactoring
the code” [35].
Gli approcci agili sono focalizzati sullo sviluppo a breve termine, che rappresenta l'attuale
commessa, piuttosto che sui benefici che si potrebbero ottenere nei progetti futuri, che rappresentano
le commesse di clienti con i quali si dovrà cooperare. Dunque, l'obiettivo della loro applicazione
concerne l'ottimizzazione del progetto corrente, quindi concreto, piuttosto che quella di un eventuale
progetto futuro.
Inoltre, nei sistemi di grandi dimensioni e complessi, gli aspetti legati all'architettura sono di
fondamentale importanza, pertanto, il costo di un eventuale cambiamento può essere anche molto
alto. In questi casi, prevenire alcune modifiche nel progetto potrebbe costituire un notevole
vantaggio in termini economici.
Si pensi, ad esempio, ai sistemi legacy, le cui funzionalità risultano fortemente accoppiate e,
per i quali, un approccio incrementale potrebbe non risultare idoneo. Infatti, a causa delle
dimensioni e della complessità di tali sistemi, il refactoring del codice potrebbe divenire
particolarmente costoso e soggetto ad errori.
118Sono in atto alcuni studi che vanno verso questa direzione.
88
Quanto detto, fa nascere l'idea che, probabilmente, bisognerebbe trovare il giusto trade-off tra
l'agilità ed il controllo, così da soddisfare le esigenze legate ad un determinato contesto.
Naturalmente, a volte è necessario giungere ad un compromesso che possa dar luogo a modifiche
nell'ambiente per adeguarlo alla metodologia da adottare ed a modifiche nella metodologia da
adottare per adeguarla all'ambiente.
89
Capitolo 5
La piattaforma Metropoolitana Leggera Automatica di AnsaldoBreda:
un caso di studio
L'Iniziativa Software Finmeccanica, avviata nell'aprile del 2006, vede oggi il coinvolgimento
del CINI (Consorzio Interuniversitario Nazionale per l'Informatica), del Consorzio SESM e di
alcune aziende del gruppo Finmeccanica, tra le quali, dall'autunno del 2010, anche l' AnsaldoBreda.
In particolare, l'attività è coadiuvata dalle Unità di Ricerca CINI delle Università di Firenze,
Genova, Napoli "Federico II", Roma "La Sapienza".
L'obiettivo del progetto è far incontrare il mondo accademico con quello aziendale, così da
proporre ed avviare soluzioni innovative, frutto di una ricerca mirata, che possa costituire un
plusvalore per le aziende interessate.
Naturalmente, ciò prevede una stretta interazione tra gli esperti industriali, ai quali è richiesto
di esplicitare i Piani Tecnologici Aziendali, ed il personale specializzato, che dovrà proporre e
formare risorse qualificate da inserire nelle varie realtà industriali.
Questo capitolo è frutto di un'attività sostenuta dall'Unità di Ricerca coordinata dal Prof. Ing.
Stefano Russo, coadiuvato dall'Ing. Roberto Pietrantuono, e svolta presso la sede napoletana
dell'azienda AnsaldoBreda.
In particolare, l'ambito della ricerca del quale ci si è occupati riguarda l'esplorazione delle
metodologie e strumenti per l'ingegneria dei requisiti applicati alla piattaforma MLA (Metropolitana
Leggera Automatica).
5.1 MLA
La Commissione Europea, mediante le norme UNI 8379 e l'UITP (Associazione
Internazionale del Trasporto Pubblico)119 , ha definito la metropolitana (Rail Rapid Transit) come un
119I trattati dell’Unione Europea considerano la politica comune dei trasporti come uno degli elementi fondamentali del
mercato unico europeo. La Commissione europea ha spesso sottolineato i vantaggi competitivi della ferrovia rispetto
alle altre modalità di trasporto terrestre o aereo, soprattutto in materia di consumo d’energia, d’impatto sull’
ambiente e di sicurezza. Per la Commissione la rivitalizzazione delle ferrovie e una tariffazione più equilibrata delle
infrastrutture dovrebbero determinare un trasferimento notevole di traffico dalla strada verso la ferrovia.
Il settore ferroviario soffre sempre per la grande varietà e complessità delle specifiche tecniche e delle
modalità
di gestione delle differenti reti ferroviarie nazionali, cose che limitano la sua attrazione e producono dei
maggiori costi di costruzione e di gestione per le infrastrutture, i veicoli e gli equipaggiamenti.
La Commissione cerca dunque di attuare progressivamente una legislazione europea che favorisca l’emergere di un
mercato ferroviario unico nell’insieme dell’Unione e contribuisca al suo sviluppo, e ciò privilegiando due concetti:
quello dell’apertura del mercato e quello dell’interoperabilità.
La norma UNI 8379 fornisce inoltre dei parametri identificativi di massima delle metropolitane:
•
frequenza media per direzione: 4 minuti
90
"sistema di trasporto rapido di massa, di alta capacità e frequenza, costituito da veicoli automotori
o mossi da veicoli automotori circolanti su rotaia, ovvero con altra guida vincolante e
completamente svincolata da qualsiasi altro tipo di traffico, con regime di circolazione regolata da
segnali ".
Una prima caratterizzazione dell'infrastruttura metropolitana vede la contrapposizione di due
modelli: la metropolitana leggera e quella pesante, che differiscono per: portata, frequenza delle
corse e tipologia di rotabile adoperato.
In questa sede ci occuperemo della categoria leggera (Light Rail Transit), definita dall' UNI
8379 come:
" un sistema di trasporto rapido di massa che mantiene le caratteristiche della metropolitana, ad
eccezione della portata oraria, che è prevista minore, e dei veicoli che, qualora opportunamente
attrezzati, possono essere utilizzati su tratti di linea che, avendo caratteristiche tranviarie, non
rientrano nella categoria delle metropolitane leggere ",
aggiungendo a questa la definizione fornita dalla International Light Rail Commission120:
"la metropolitana leggera è una forma di trasporto su rotaia
che può essere sviluppata per fasi da un tram moderno ad un sistema di trasporto rapido
circolante in sede propria o sotto terra. Ciascuno stadio di sviluppo può essere completo di per sè,
ma deve rendere possibile gli sviluppi per passare al successivo ".
Dunque, la metropolitana leggera si presenta come un sistema in grado di offrire un servizio
intermedio tra quello tranviario e quello del metrò, da un canto fornendo i vantaggi tipici dei sistemi
su rotaia (elevate capacità, alta produttività, comfort, affidabilità) e dall'altro introducendo alcune
problematiche sostanzialmente connaturate ai riflessi ambientali derivanti da viadotti, rampe di
accesso alle gallerie o elementi-barriera, e dai fenomeni d'interferenza con le altre modalità di
trasporto in sede promiscua.
•
capacità di ogni convoglio: 1200 persone
•
distanza media stazioni/fermate: 600–1000 m
•
velocità commerciale: 25/30 km/h
•
lunghezza massima del convoglio: 150 m
•
portata potenziale media: 18000 pax/h dir
120Light Rail Commition è una commissione nata con lo scopo di promuovere l'interesse dei mezzi di trasporto
pubblico MLA attraverso la pubblicazione di documenti e relazioni riguardanti le esperienze a livello internazionali
connessi alla metropolitana leggera.
91
Illustrazione 31: Piattaforma MLA
5.1.1 Generalità sui componenti della piattaforma
La descrizione dei componenti costituenti la MLA esula dagli scopi di questo lavoro di tesi,
per il quale ci limiteremo a descrivere brevemente i sottostistemi prodotti dalla AnsaldoBreda per la
suddetta piattaforma.
Ciascun veicolo presenta un sistema di monitoraggio e controllo (TCMS), una o più unità di
controllo trazione (TCU) e di diagnostica (IDU).
Il Train Control and Monitoring System, rappresenta l'unità preposta al controllo ed alla
gestione del veicolo. Questa esplica le sue funzioni per mezzo di due sottounità121, una centrale
(Central Control Unit) e l'altra locale (Local Control Unit).
La gestione delle varie unità del veicolo avviene attraverso il bus MVB122 ed il bus RS485123.
121 Ciascuna sottounità può essere settata come Master del bus MVB e del bus RS485.
122Come avviene per la gestione del sistema freno, ad esempio.
123La trasmissione via RS485 è basata su di un protocollo seriale asincrono, in cui ogni informazione, a seconda del
tipo di messaggio scambiato, sarà trasmessa in un frame con un particolare formato.
92
Per mezzo di uno scambio di dati124 con sistemi quali la ATC125 , l'OBS126 e l'IDU, ecc.
Illustrazione 32: Architettura del TCMS
La Traction Control Unit è articolata in quattro casse e cinque carrelli127, quattro dei quali
motorizzati ed uno portante128.
124I dati consistoni in comandi ed informazioni di diagnostica collezionati in dataset.
125 Il treno è equipaggiato con un sistema di sicurezza e operatività del veicolo, noto come ATC.
Esso include:
•
ATO (Automatic Train Operation): è la funzione che sostituisce il macchinista.
Esso assicura che il treno si fermi correttamente in stazione, apra le porte, aspetti che i passeggeri siano saliti e scesi
dal veicolo, che venga ripresa la corsa. Esso non può modificare alcune funzioni, come il cambiamento degli scambi.
•
ATP (Automatic Train Protection): sistema per il controllo dei treni, volto ad assicurarne la sicurezza
in viaggio. Esso interviene qualora una predeterminata velocità/distanza di sicurezza venga superata e può
essere
definito come: “monitoraggio continuo della velocità con o senza segnalazione nella cabina di guida”;
•
ATS (Automati Train Supervision): raccoglie le informazioni di diagnostica del veicolo e dirige le
attività per la risoluzione dei problemi riscontrati.
Le funzioni ATP offrono una protezione a prova di errore contro collisioni, velocità eccessiva e altre condizioni
pericolose. Le funzioni ATO soddisferanno le caratteristiche operative base del treno entro i limiti di sicurezza
imposti dal sistema ATP. Le funzioni ATS forniranno informazioni sullo stato del sistema, controlleranno le
operazioni del sistema e implementeranno il controllo automatico di varie funzioni del sistema [36]
126 Onboard System è il sistema di comunicazione di bordo che consente: la comunicazione tra l'operatore (magari il
conducente) ed i passeggeri in situazioni di emergenza, la diffusione di messaggi in viva voce ai passeggeri, può
offrire un sistema di videosorveglianza, ecc.
127 È un elemento indipendente del veicolo, che si monta sulla parte inferiore della cassa, e comprende un sistema di
sospensioni per assicurare il comfort e la sicurezza di marcia Può essere fisso o imperniato su pattini, ralle o sistemi a
bilanciere, e può montare un numero variabile di assi e ruote.
128 I carrelli si differenziano in 'portanti' e 'motori', a seconda che possano o meno sviluppare sforzi di trazione.
Il carrello portante è costituito da due organi di sospensioni: primaria e secondaria. L'organo primario è
realizzato con molle ad elica ed il movimento fra gli assi e il telaio ha per vincoli delle guide verticali. Quello
secondario è costituito da una trave detta 'oscillante' sospesa al telaio del carrello e appoggiata su molle: su tale asse
93
Ogni veicolo prevede due possibili configurazioni: con singola129 e doppia unità di trazione130
Esso dispone di un certo numero di moduli inverter, attraverso il quali ciascun carrello verrà
controllato ed alimentato.
La TCU, assieme al Brake Control Unit (BCU), interagendo con il TCMS, realizza la
frenatura del veicolo131.
Il sistema diagnostico, Integrated Diagnostic Unit, è l'unità diagnostica di bordo, preposta al
monitoraggio dell'intero sistema. Oltre a consentire la verifica del corretto funzionamento delle
tecnologie presenti a bordo, il suo compito è comunicare al TCMS il verificarsi di situazioni di
avaria, così da avviare le operazioni necessarie (riducendo il tempo di fermo del treno).
In particolare, le centraline di controllo instaurano una comunicazione con il TCMS attraverso
un particolare bus e comandi I/O.
5.2 Il ciclo di sviluppo
La normativa di riferimento per lo sviluppo software in ambito ferroviario è la CELENEC
EN 50128132, pertanto, in AnsaldoBreda, tutte le attività del processo sono strutturate in maniera tale
da garantire il rispetto del modello di
ciclo di vita a V.
Illustrazione 33: Modello a V adoperato
dall'AnsaldoBreda
viene poggiata la cassa e la rotazione relativa fra cassa e trave oscillante è resa possibile attraverso una rolla. I
carrelli motore presentano soluzioni innovative dovute alla presenza di motori di trazione e relative trasmissioni e
sospensioni
129La singola trazione prevede che i due motori in una coppia di rotabili (che solitamente sono disposti in serie) , invece
di essere posti sulla stessa vettura, sono montati uno per ciascuna vettura.
130 Consiste nell'impiego di due locomotive per trainare il treno: essa viene adoperata solo nei casi relativi al recupero
in linea dei veicoli in avaria.
131 Una caratteristica particolare della frenatura della MLA è l'applicazione della logica Blending.
132 La normativa EN 50128 specifica le procedure ed i requisiti tecnici per lo sviluppo del software nelle applicazioni
ferroviarie.
94
5.2.1 Planning
La pianificazione del progetto software rappresenta la prima fase del processo di sviluppo
adottato dall'AnsaldoBreda. Dopo la fase di raccolta di tutte le informazioni necessarie133, essa
consiste nel caratterizzare i modelli standard dei documenti134 da produrre, rispetto alla particolare
commessa. Questi verranno sottoposti ad aggiornamento in concomitanza con l'avanzamento del
progetto.
Illustrazione 34: Planning e Project Review
133 L'avvio della fase di pianificazione presuppone l'esistenza di alcuni documenti di pianificazione: di assicurazione
della qualità, di gestione della configurazione, di verifica e validazione, test e di sviluppo del progetto.
134 Software Verification & Validation Plan (SVVP), Software Configuration Management Plan (SCMP), Software Test
Plan (STP), Software Development Plan (SDP).
95
5.2.2 Requirements Specification
Per ciascuna nuova commessa, il processo di sviluppo parte dal capitolato tecnico, dal quale un
sistemista estrapola i requisiti funzionali del Sistema/Veicolo. Tale ruolo è coperto da un
rappresentante di un ufficio di AnsaldoBreda (della sede di Napoli o di Pistoia), oppure da un
incaricato di una azienda partner di AnsaldoBreda per la particolare commessa.
È importante notare che alcuni dei requisiti funzionali Sistema/Veicolo vengono implementati
(via hardware e via software) in sottosistemi prodotti dalla stessa AnsaldoBreda, è questo il caso del
TCMS, IDU e TCU.
Pertanto, la specifica dei requisiti software relativi a questi ultimi verrà effettuata sulla scorta
dei requisiti funzionali di sistema e confluirà nei documenti di specifica dei requisiti software (SRS)
e di specifica dei casi di test eseguiti sul software (SRTS).
La specifica dei requisiti termina con l'ispezione dei due docuementi SRS ed STRS, effettuata
nella fase di Requirements Review.
Illustrazione 35: Requirements Specification
96
Illustrazione 36: Requirements Review
5.2.3 Architecture and Design
A partire dall'SRS, viene prodotto un documento di descrizione di alto livello dell'architettura
ed inizia la progettazione del software. La fase termina con una Design Review, un'ispezione in cui
si verifica l'adeguatezza della progettazione rispetto ai requisiti software specificati.
97
Illustrazione 37: Archietecture and Design
5.2.4 Module Design and Implementation
I moduli software individuati nella fase precedente di progettazione "di massima" vengono
progettati ad un livello di dettaglio maggiore. Verrà, quindi, prodotto il documento di Software
Module Description, in cui saranno descritti i componenti del modulo135, le interfacce, le dipendenze
tra essi.
È bene notare, però, che la redazione della documentazione della progettazione di dettaglio è
prescritta solo quando essa si riferisce a software il cui SIL è maggiore di 0 (questo caso si presenta
solo raramente nei progetti sviluppati da AnsaldoBreda).
Solo in tal caso la progettazione di dettaglio si conclude obbligatoriamente con una detailed
design review. Durante questa attività si verifica l'adeguatezza della decomposizione in moduli, dei
casi di test ed, inoltre, vengono valutati gli aspetti relativi al riuso dei moduli.
Il passo successivo consiste nell'implementazione di ciascuno dei componenti software
135 La decomposizione in moduli segue il principio di decomposizione funzionale, così da dominare la complessità del
modulo (in termini di macro-funzionalità.
98
individuati; il codice viene generato automaticamente attaverso Matlab/Simulink136 .
Illustrazione 38: Module Design and Implementation
136 Matlab è un linguaggio di programmazione per applicazioni scientifiche e numeriche. Simulink è un ambiente
grafico di simulazione di sistemi complessi.
99
Illustrazione 39: Detailed Design Review
5.2.5 Analisi Statica
L'analisi statica viene eseguita per verificare che lo standard di codifica aziendale sia stato
applicato correttamente al codice sorgente. I risultati sono riportati nel documento Static Analysis
Report (SAR), che viene redatto solo per i moduli software con SIL>0.
100
Illustrazione 40: Analisi Statica
5.2.6 Module Testing
Dopo la fase di implementazione dei moduli software, vengono eseguiti i test (funzionali) sui
componenti sviluppati. L'attività eseguita con il tool Cunit (cfr. Appendice), mentre la valutazione
della copertura dei requisiti viene effettuata tramite review.
Mentre lo svolgimento dei test è obbligatorio per tutti i moduli, la produzione della
documentazione – contenente gli esiti – è prescritta solo nei casi in cui il SIL sia maggiore di 0.
101
Illustrazione 41: Module Testing
5.2.7 Integration and Validation Testing
Dal test di modulo di passa all'integrazione dei moduli software ed al relativo test, Validation
Testing, che si riferisce alla verifica della conformità con la specifica dei requisiti funzionali e con
gli aspetti relativi alla sicurezza. In pratica, i test eseguiti in questa fase sono quelli definiti nel
documento STRS. È bene notare che non sono prescritti test di integrazione, né test per i requisiti
non funzionali137.
Bisognerà effettuare test di regressione nel caso di modifiche apportate; in particolare, il
progettista avrà il compito di selezionare il set di test (obbligatori o facoltativi) che dovranno essere
ripetuti, affinchè la nuova versione del software sia validata.
L'analisi di impatto è eseguita manualmente ed è a carico del progettista.
137 Ciò potrebbe dipendere dalla mancanza di una classificazione dei requisiti in base alla tipologia di appartenenza.
102
Illustrazione 42: Integration and Validation Testing
5.2.8 Release
A valle della fase di test, il progettista dovrà rilasciare il software; questa operazione consiste:
• nell'archiviazione del software e dei relativi documenti138;
• produzione o aggiornamento del Software Version Description Document, atto a contenere
la descrizione del software, oppure delle modifiche apportate alla precedente versione;
• produzione del documento Software Configuration Description.
Il rilascio è seguito dalla Configuration Review, in cui vengono ispezionati i documenti di
configurazione, verificandone la correttezza. L'output di questa fase è il Software Configuration
138 Supportata dal tool di gestione delle versioni Subversion.
103
Verification Report.
Illustrazione 43: Release
5.2.9 Gestione della configurazione del software
Al fine di poter distribuire ed installare il prodotto software, esso viene archiviato in un
repository ufficiale (Subversion).
In particolare, la gestione139 della configurazione viene supportata dall'utilizzo dei seguenti
strumenti (cfr. Appendice):
•
Subversion per il versioning;
•
LuntBuild per la verifica periodia della corretta generazione degli eseguibili;
•
Jira, un issue tracker, per la gestione delle modifiche e per la rilevazione di anomalie.
139 Vengono gestiti codice sorgente, script di comandi, file di configurazione, docuementazione.
104
Illustrazione 44: Configuration Review
5.3 Analisi del processo di sviluppo
Sulla scorta delle problematiche esposte, la prima attività svolta ha riguardato l'analisi del
processo di sviluppo del software in AnsaldoBreda, condotta attraverso lo studio della
documentazione relativa. Questa ha indicato gli strumenti140, i modelli standard dei documenti
prodotti nella varie fasi dello sviluppo, gli standard adottati141.
L'insieme delle informazioni reperite è stato ulteriormente dettagliato dai colloqui svolti con
alcuni responsabili della divisione software di AnsaldoBreda.
Il primo aspetto sul quale si è concentrata l'attenzione del gruppo di studio è stato quello
relativo all'organizzazione aziendale che, in seguito ad un recente cambiamento, ha indicato come
ruoli principali, per lo sviluppo del software, le figure del Lead Software Engineer, Software
140Gli strumenti a supporto della progettazione sono Jira, Confluence, Subversion, Doxygen, Cunit, Luntbuild, Salomè
TMF, Understand, per la cui descrizione si rimanda alla relativa sezione in Appendice.
141 Gli standard adottati vengono riportati nella relativa sezione in Appendice.
105
Engineer e del Test Engineer.
In particolare: il primo mantiene una visione di alto livello dell'intero progetto e svolge attività
di coordinamento; il secondo si occupa, invece, di aspetti maggiormente legati allo sviluppo del
software, quindi di livello più basso; il terzo è responsabile della fase di test.
Un'importante considerazione riguarda l'aspetto della comunicazione tra le persone coinvolte:
infatti, se da un canto la dimensione ridotta dell'azienda potrebbe favorire un buon livello di dialogo,
di fatto ciò non sembra accadere.
Si è riscontrato che, rispetto alle diverse fasi del ciclo di sviluppo, viene fornita una certa
libertà di scelta ai singoli. Ciò, se in linea di principio, rappresenta uno stimolo all'ideazione di
nuove soluzioni, nella realtà genera un certo disallineamento tra i vari gruppi di lavoro.
In tale contesto può capitare, infatti, che un gruppo si trovi a lavorare seguendo una linea
sconosciuta ad un altro, penalizzando la giusta condivisione della conoscenza.
Dunque, un primo passo verso il miglioramento del processo aziendale è, certamente,
l'osservanza obbligatoria, da parte di tutte le figure coinvolte in un progetto, delle convenzioni
aziendali e dell'utilizzo condiviso di strumenti e metodi.
Un'ulteriore situazione ravvisata riguarda l'assegnazione dei compiti e delle responsabilità, che
sembra, talvolta non essere soddisfacente.
Infatti, non caita di rado che una stessa persona ricopre più di un ruolo: il progettista, ad
esempio, è spesso anche il revisore del proprio lavoro, quindi nella fase di revisone potrebbe non
cogliere errori o inesattezze da esso stesso commessi, inficiando così la qualità del prodotto finale.
Ancora, le informazioni reperite per la realizzazione di un progetto non hanno mostrato
l'esistenza di una procedura rigorosa, sia per l'assegnazione delle risorse da impiegare, sia per la
stima preventiva dei costi. Tale attività è, infatti, a carico del capoufficio, sulla base dell'esperienza
acquisita, e successivamente valutata da uno specifico ente aziendale.
A partire dalle criticità, si è, quindi, ritenuto opportuno avanzare la proposta di una revisione
del ciclo di sviluppo, con l'obiettivo di favorire la tracciabilità dei requisiti ed il riuso.
5.4 Problematiche connesse alla piattaforma MLA
La piattaforma MLA rappresenta un prodotto nuovo e particolarmente apprezzato dal mercato
mondiale che, naturalmente, richiede sempre più il rispetto di alcuni standard e l'adozione di
particolari criteri e strumenti di sviluppo.
Ciò ha fatto nascere una nuova consapevolezza che ha spronato l'azienda a rivedere l'intero
ciclo di sviluppo del prodotto, così da scorgerne le criticità e gli aspetti migliorabili.
È facile immaginare che la commessa di una MLA sia rappresentata, in termini concreti, da un
106
capitolato di gara, nel quale sono riportati gli obiettivi/necessità del cliente, le restrizioni e norme di
riferimento con le quali il prodotto dovrà essere in linea. D'altro canto, una parte non trascurabile dei
requisiti effettivamente implementati prende vita da esigenze, conoscenze e pratiche consolidate in
ambito aziendale o, poichè diversi componenti adoperati nella piattaforma MLA sono acquistati
dall'esterno, da vincoli dettati dai produttori di COTS142.
Infatti, nonostante il cliente mostri conoscenze tecniche – a volte anche molto specifiche – del
contesto applicativo, naturalmente, esso non ha la capacità, o comunque la competenza, per
prescrivere l'utilizzo di un particolare componente.
Nonostante il capitolato di gara rappresenti un vincolo alla "personalizzazione" del prodotto,
non dobbiamo dimenticare che la piattaforma MLA appartiene ad una famiglia di prodotti, nella
fattispecie, di rotabili ferroviari. Pertanto, essa presenta elementi riusabili, poichè comuni a più
realizzazioni.
Si tenga conto, però, che rendere un prodotto siffatto aderente alle aspettative di qualunque
cliente comporta un costo, talvolta, abbastanza elevato. Pertanto, dovrebbe essere attuata una
progettazione mirata al riuso143, così da poter minimizzare i costi derivanti dalla "personalizzazione"
della piattaforma.
I componenti realizzati da AnsaldoBreda per la piattaforma MLA appartengono alla categoria
dei sistemi di controllo ed, in contesti come quello in esame, talvolta non è agevole classificare i
relativi requisiti in funzionale, di performance o di safety, poichè il confine tra le tre tipologie è
labile.
Pertanto, nell'ambito della ristrutturazione dei requisiti software, si è ritenuto opportuno
classificare ciascun requisito in base alla tipologia.
Una problematica segnalata da AnsaldoBreda, riguarda la difficoltà di far corrispondere i
requisiti standard della piattaforma ai requisiti espressi in ciascun capitolato.
Pertanto si è adoperato un criterio di tracciabilità dei requisiti, grazie al quale è più agevole
capire come e dove essi siano collocati – una volta realizzato il sistema - , per dimostrare la loro
effettiva implementazione, per gestirne in modo adeguato l'evoluzione, la manutenzione e per
migliorare il riuso.
Nell'ambito del ciclo di sviluppo di questo prodotto, il ruolo di stakeholder è coperto da:
•
il cliente finale, rappresentato dall'amministrazione territoriale che commissiona il progetto;
142COTS, Commercial, Off-The-Shelf, di riferisce a componenti integrati già prodotti e commercializzati; vengono
molto adoperati nel progetto di sistemi embedded. Esistono componenti COTS hardware e software.
143Una progettazione orientata al riuso prevede lo sviluppo di componenti riusabili ed il supporto alla scelta ed
integrazione di componenti COTS.
107
•
Ansaldo STS144, partner di AnsaldoBreda, che rappresenta il main contractor rispetto ai
clienti. In particolare, i suoi sistemisti definiscono i requisiti dell'intero sistema di trasporto e,
nel caso di prodotti ai quali è associato un SIL145 > 0 (cfr. Appendice), conducono analisi di
safety.
•
I fornitori di componenti COTS. Si noti che costruire grandi sistemi integrando COTS è una
strategia abbastanza comune ed efficiente, soprattutto per quei sistemi che presentano
funzionalità di base grosso modo comuni. Tipicamente, il loro utilizzo rende più veloce il
processo, riducendo i costi di sviluppo e test.
La varietà di "punti di vista" introduce un'ulteriore problematica aziendale, relativa alla
gestione dei requisiti, che nasce già dalla difficoltà di comprensione e raccolta degli stessi.
Pertanto, l'obiettivo da perseguire riguarda lo sviluppo di metodologie e strumenti
dell'ingegneria del software per il miglioramento del processo di sviluppo della piattaforma MLA,
con particolare enfasi su:
•
la classificazione dei requisiti;
•
la strutturazione dei requisiti;
•
la tracciabilità dei requisiti;
•
la gestione dei requisiti;
•
la progettazione mirata alla riusabilità.
Nel prosieguo di questo capitolo mostreremo le attività svolte in Azienda, relative al primo dei
due obiettivi succitati.
5.5 MetroRiyadh: un caso di studio
In accordo con i responsabili della divisione software dell'Azienda, il gruppo di lavoro si è
concentrato su di un particolare progetto, attualmente in fase di test, del quale si è fatto un caso di
studio: MetroRiyadh.
L'obiettivo dell'attività ha riguardato la revisione delle prime fasi del ciclo di sviluppo del
software, connesse all'Ingegneria dei Requisiti. In particolare, la sperimentazione è stata svolta:
1) analizzando la documentazione esistente (documenti di specifica dei requisiti funzionali di
sistema, documenti di specifica dei requisiti software);
2) ristrutturando i requisiti software, a partire da quelli di sistema;
3) esplicitando le relazioni tra i requisiti e realizzandone la tracciabilità a tutti i livelli.
144STS sta per Sistemi.
145 SIL, acronimo di Security Integrity Level, indica la "classe" di probabilità del danno provocato a cose e/o persone
coinvolte nell'interazione con il sistema. I livelli di SIL possono essere valutati in base alla norma EN IEC 62061.
108
Il lavoro è stato condotto sul sistema TCMS, rappresentante la logica di veicolo.
Si noti, però, che il progetto MetroRiyadh rappresenta un caso unico rispetto al modo in cui
sono stati descritti i requisiti di sistema e, di conseguenza, i requisiti software. Infatti, esso è frutto di
un esplicito accordo tra il sistemista ed il progettista del software del TCMS, nel:
•
descrivere i requisiti di sistema a livello di dettaglio molto basso;
Illustrazione 45: Esempio di requisito funzionale di sistema di MetroRiyadh
•
ricavare i relativi requisiti software come "copia" dei requisiti di sistema di provenienza.
Illustrazione 46: Esempio di requisito software
5.5.1 Studio della documentazione esistente
Documenti analizzati:
 Manuale del Processo di Sviluppo del Software
109
Relativamente al Progetto MetroRiyadh:
 Software documentation plan
 Software documentation list
 System Performance Requirements (sistema FRENO)
 System Performance Requirements (sistema FRENO)
 Functional Requirement Specification (sistema FRENO, sistema PROPULSIONE, sistema
HV, sistema LV)
 Software Requirement Specification (sistema FRENO, sistema PROPULSIONE, sistema
HV, sistema LV)
 Dataset
 MetroRiyadh Interface Description
 MLA Riyadh TCMS
 Test requirement specification
 Test requirement report
 Modello matlab della specifica SRS di riferimento
 Matrice di tracciabilità dei requisiti
L'analisi preliminare svolta sulla documentazione disponibile ha evidenziato un aspetto critico,
relativo alla descrizione dei requisiti software, connessa in parte alla scelta di far derivare detti
requisiti direttamente da quelli di sistema, ed in parte legata alla complessità del sistema in esame.
Innanzitutto, i requisiti del documento di specifica dei requisiti funzionali di sistema
descrivono "come" siano implementate le funzionalità, piuttosto che il "cosa". Pertanto, il
documento descrive il dominio della soluzione, invece del dominio del problema.
5.5.2 Specifica
Attraverso l'analisi preliminare dei documenti di specifica dei requisiti software, relativi al
progetto MetroRiyadh, si è potuta riscontrare:
•
la mancanza di un linguaggio naturale strutturato, i requisiti sono invece descritti con l'uso
del linguaggio naturale;
•
la mancanza di una strutturazione definita per specificare i requisiti, che, al contrario è
affidata all'arbitrio del progettista. Questo aspetto non favorisce il riuso;
•
la mancanza di una separazione dei requisiti in livelli di astrazione;
•
la mancanza di una classificazione basata sulla priorità dei requisiti;
110
•
la mancanca di una classificazione dei requisiti, in base alle tipologie note (di interfaccia,
funzionali, di performance, di safety).
5.5.3 Verifica e validazione dei requisiti
Lo strumento adoperato in azienda per verificare e validare i requisiti è la review, che consiste
nell'ispezionare il documento di specifica, al fine di riscontrarne la qualità.
Tipicamente, le figure coinvolte in una requirements review sono l'ispettore e colui che si è
occupato di scrivere la specifica dei requisiti.
Si è riscontrato però che, almeno nel caso di Riyadh, i due ruoli sono stati coperti dalla stessa
persona.
Ricordiamo che la fase di convalida richiede l'interazione con chi ha commissionato il prodotto,
cosa non prevista nel caso oggetto di studio146.
5.5.4 Tracciabilità e gestione dei cambiamenti
Notevole importanza è stata rivolta al processo di tracciabilità previsto in AnsaldoBreda,
mostrato attraverso matrici in cui sono stati collegati i requisiti software al relativo codice e casi di
test.
In effetti, la matrice contiene indicazioni di tracciabilità solo di alcuni requisiti software ed,
inoltre, non mostra le relazioni tra essi.
Probabilmente, ciò dipende dal modo in cui i requisiti sono descritti.
Infatti, la loro caratterizzazione147 – al momento non applicata – consentirebbe la creazione di
un database dei requisiti, in cui identificare facilmente quelli riusabili.
Utilizzare un adeguato criterio di tracciabilità è fondamentale per due motivi:
•
per migliorare il riuso dei requisiti;
•
per l'analisi d'impatto, che è una delle principali attività della gestione dell'evoluzione dei
requisiti.
In AnsaldoBreda, la gestione dei cambiamenti è affidata alle review di progetto ed a strumenti
di gestione delle issue.
Pertanto, è stato manifestato un notevole interesse a nuove proposte provenienti dal gruppo di
lavoro, mettendo a disposizione lo strumento di gestione dei requisiti IBM Rational DOORS.
146 Le figure che interagiscono appartengono tutte alla stessa Azienda e, solo in alcuni casi vi sono incontri con
referenti dell'Ansaldo STS (main contractor verso il cliente).
147 Un requisito dovrebbe essere caratterizzato da una strutturazione, dalla tipologia, dalle relazioni mostrate con altri
requisiti.
111
5.6 Interventi
A fronte dell'analisi svolta, il gruppo di lavoro all'Iniziativa Software ha proposto alcuni
interventi al ciclo di sviluppo del software AnsaldoBreda.
In questa sede ci occuperemo di descrivere quelli relativi alla fase di gestione dei requisiti, che
rappresenta il primo passo dell'intera attività.
5.6.1 I requisiti software
I requisiti software sono derivati, nel caso della MLA, dall' organizzazione architetturale della
piattaforma e dai requisiti di sistema. Questi ultimi, in particolare, prendono vita dalle
esigenze/obiettivi dell'utente, presentati nel capitolato tecnico.
L'architettura di sistema è costituita da un insieme di sottosistemi; pertanto:
•
i requisiti di sottosistema derivano da quelli di sistema;
•
i requisiti software derivano dai requisiti di sottosistema.
Data la complessità del prodotto, si è ritenuto opportuno strutturare i requisiti per livelli di
astrazione. E infatti, a valle della deduzione delle aspettative dell'utente, si ottengono:
•
i requisiti utente;
•
i requisiti di sistema;
•
i requisiti di sottosistema;
•
i requisiti software di alto livello del sottosistema;
•
i requisiti software di basso livello del sottosistema.
5.6.2 I livelli di astrazione
La strutturazione dei requisiti in livelli di astrazione consente di approcciare il problema della
specifica in modo da favorire l'estendibilità ed il riuso.
In primo luogo, per mettere in atto la strategia, bisogna identificare gli aspetti più "generici",
ad esempio quelli che nell'ambito di una famiglia di prodotti sono ritenuti comuni e che
costituiranno i requisiti di alto livello. Successivamente, tali aspetti potranno essere dettagliati, così
da caratterizzare il comportamento del singolo prodotto e dare vita ai requisiti di basso livello.
La specifica in livelli di astrazione consentirà di raggiungere l'obiettivo per passi successivi:
- anticipando l'eventuale feedback dell'utente;
- facilitando le verifiche di correttezza;
112
- predisponendo l'estendibilità ed il riuso.
A supporto di questa idea viene la norma DO – 178B "Software Considerations in Airbone
System And Equipment Certification", che costituisce le linee guida per la certificazione del software
safety-critical in ambito avionico.
Lo standard offre spunti per il trattamento dei componenti commerciali OTS, per lo sviluppo
volto al riuso di componenti software, per la gestione del rischio connesso all'utilizzo degli strumenti
di sviluppo.
Per poter definire la sicurezza di un sistema Safety Critical è necessario classificare le
conseguenze legate alle failure condition148. In campo aeronautico, sono fissate cinque classi149 di
"avaria", ciascuna delle quali inficia in una certa misura le funzionalità dell'aeromobile.
Poichè l'obiettivo è quello di classificare l' avaria in base alla gravità dell'evento, ciascuna
classe sarà associata ad un livello di criticità150 esplicitato sull'insieme delle funzioni
(hardware/software) coinvolte.
Allo stesso modo, per prevenire errori di progettazione che possano inficiare il funzionamento
in sicurezza del sistema, per ogni livello di criticità sarà definito un profilo di "obiettivi di design
assurance".
La normativa di progetto DO-178B definisce il requisito come un elemento di una specifica
con caratteristiche di:
• identificabilità: i requisiti devono essere numerabili e numerati;
• verificabilità: i requisiti devono essere
- espressi in forma positiva;
- coerenti tra loro;
- concepiti con la strategia di test che li verifichi.
In essa viene definito il "requisito derivato", cioè un requisito aggiuntivo, posto dal processo di
design, che può non essere direttamente tracciabile da un requisito di livello superiore [38].
Tipicamente, i derived (low-level) requirements specificano gli aspetti relativi alle proprietà
del sottosistema.
148 Ci si rende facilmente conto di quanto questa idea sia connessa al campo di applicazione.
149 Le 5 classi di avaria sono:
•
Catastrophic;
•
Hazardous/severe- major;
•
Major;
•
Monor;
•
No Effect.
150 I livelli vanno da A ad E.
113
Nel caso della piattaforma MLA la classificazione in alto e basso livello (High Level e Low
Level) riguarda i requisiti software di ciascun sottosistema.
Da ciò, si evince che esistono più livelli di specifica dei requisiti, ciascuno caratterizzato da un
livello di dettaglio incrementale.
Illustrazione 47: Processo di definizione dei requisiti
La suddivisione in livelli di astrazione richiede, passo dopo passo, una descrizione ad un
maggior dettaglio, quindi una conoscenza sempre più approfondita del dominio applicativo.
La tecnica esposta richiede competenze specifiche in ciascuna fase di sviluppo; pertanto è
richiesta una suddivisione di compiti e responsabilità tra le persone coinvolte nel progetto che, allo
stato, l'azienda non opera.
5.6.3 I requisiti di interfaccia
I requisiti di interfaccia (cfr. Cap. 1 § Requisiti di interfaccia) specificano in che modo debbano
essere realizzate le interazioni tra il sistema ed il mondo esterno151, dettandone le regole.
È facile immaginare, infatti, che dato un particolare sottosistema, nei relativi requisiti
funzionali vi siano riferimenti al mezzo (requisiti interfaccia) che consentirà la comunicazione con
altri sottosistemi.
Pertanto, sarà necessario:
•
scrivere nel requisito funzionale solo il riferimento al/ai requisito/i di interfaccia
necessario/i all'interazione;
151 Sappiamo che il sottosistema interagisce con altri sottosistemi e, naturalmente con l'hardware sottostante.
114
•
tracciare la/le relazione/i tra i requisiti (funzionale e di interfaccia).
Mostriamo ora alcuni esempi che faciliteranno la comprensione di quanto appena esposto.
ID: REQ_BRAKE_05
Descrizione: TCMS will provide the above information to TCU and BCU on MVB (dataset 500)
[…]
Il requisito non dettaglia il modo in cui viene realizzato l’interfacciamento, ma rimanda al
corrispondente requisito di interfaccia. Esso presenta un riferimento al dataset 500
115
Illustrazione 48: Esempio di requisito di interfaccia di comunicazione: Dataset 500
116
5.6.4 La scrittura dei requisiti
La scrittura dei requisiti è un'attività volta al raggiungimento di un documento dei requisiti con
le seguenti proprietà (cfr. Appendice):
•
correttezza: il requisito descrive ciò che ha realmente richiesto il committente;
•
non ambiguità: il requisito si presta ad una sola interpretazione;
•
completezza: (misura relativa ad un insieme di requisiti) l'insieme dei requisiti è completo,
dunque, descrive tutti le richieste del committente152;
•
consistenza: ciascun requisito non deve essere in conflitto con altri;
•
classificabilità: ciascun requisito deve essere classificato in base all'importanza che ha per il
committente153 ed in base al livello di stabilità;
•
verificabilità: possibilità di verificare la corrispondenza del prodotto con il requisito;
•
modificabilità: possibilità di operare modifiche su di un requisito in modo semplice e
coerente, senza impattare eccessivamente gli altri requisiti;
•
tracciabilità: l'origine di ogni requisito dovrà essere chiara, inoltre, dovrà essere possibile
definire una corrispondenza tra il requisito in esame e gli altri requisiti, nonchè con i prodotti
dello sviluppo.
5.6.4.1 Linee guida per la scrittura dei requisiti
•
Scrivere frasi e paragrafi brevi: un requisito dovrebbe essere espresso in poche righe (4, 5 al
massimo);
•
Si consiglia di utilizzare la forma attiva del verbo;
•
Scrivere frasi complete complete dal punto di vista ortografico, grammaticale (soggetto,
verbo, completamento oggetto, ecc.), e della punteggiatura;
•
Adoperare i termini coerentemente con quanto definito nel glossario;
•
Accertarsi che il significato dei termini adoperati siano noti e condivisi;
•
E’ preferibile utilizzare la formula: “il sistema (o l’utente) deve” (la forma SHALL, o MUST,
in inglese), a valle della quale esprimere un risultato osservabile (si può utilizzare la forma
SHOULD per requisiti opzionali).
•
I requisiti dovranno essere espressi con frasi che esprimano un risultato osservabile (ad
152Le richiste dell'utente riguardano funzionalità, performance, vincoli di progetto, i dati, le interfacce, ecc.
153La classificazione di un requisito in base all'importanza pone l'accento sul livello di soddisfazione del cliente in
relazione alla sua implementazione.
117
esempio: "Il sistema deve visualizzare l'elenco dei container presenti in magazzino");
•
Evitare termini che possano aumentare l'ambiguità, come "facile", "accettabile", "robusto",
"efficiente", ecc., che esprimono qualità non oggettive e non misurabili;
Se vi fosse necessità di adoperarli, accertarsi dell'accezione che il cliente dà al termine
specifico;
•
Evitare termini come: "massimizzare", "migliorare", altrimenti sarebbe opportuno
quantificarli e rapportarli ad un parametro fisso;
•
Evitare di scrivere lunghi paragrafi in cui siano presentati più requisiti;
•
Se in prima battura, i requisiti sono espressi in maniera ambigua ed ad un alto livello di
astrazione, proseguendo l'esplorazione del sistema, essi diventano più specifici e concreti.
Pertanto, è necessario scomporre un requisito di alto livello e ambiguo in più requisiti di livello più
basso e meno ambigui.
•
Per poter scrivere i requisiti ad un adeguato livello di granularità bisogna specificarli in
maniera tale che siano verificabili individualmente, ovvero sottoponibili a test.
Si noti che:
- se è sufficiente un esiguo numero di casi di test per verificare che un requisito è implementato
correttamente, presumibilmente il esso è scritto al giusto livello di dettaglio.
- se i casi di test sono numerosi e diversificati, allora sarà opportuno scindere il requisito in più
requisiti.
•
Evitare di specificare i dettagli di progettazione.
•
Tracciare le relazioni tra i requisiti.
5.6.4.1.1 Strutturazione del requisito software
L'analisi dei documenti di specifica ha mostrato, innanzitutto, la necessità di proporre uno schema
di strutturazione dei requisiti154 software, secondo il quale ciascun requisito è descritto dai seguenti
campi:
•
ID: identificativo associato al requisito;
•
Nome: nome del requisito o della funzione che descrive;
•
Input: input della funzione offerta;
•
Precondizioni: condizioni che devono essere verificate affinchè la funzione descritta nel
requisito possa essere svolta;
•
Descrizione: descrizione della funzione (non in termini di "come" viene espletata);
•
Output atteso: output della funzione, che dovrà essere osservabile;
154 Come vedremo in seguito, tale strutturazione interesserà i requisiti software di alto e basso livello.
118
•
Postcondizioni: condizioni che devono verificarsi dopo l'esecuzione della funzione descritta
nel requisito;
•
Stato (opzionale):articolato sulla base del ciclo di vita dei requisiti. N.B. Al momento non è
implementato questo attributo. stato di avanzamento del requisito durante il ciclo di
sviluppo. Esso potrà assumere i valori155 [cfr. § Gestione dei requisiti, Capitolo II]:
- proposto (con eventuale indicazione chi ha proposto il requisito);
- concordato;
- implementato;
- verificato;
- eliminato;
•
Tipologia: indica la tipologia del requisito (cfr. Capitolo 1), la quale può essere classificata
come segue:
- Funzionale: descrive la funzionalità o il servizio che il sistema deve fornire per soddisfare i
bisogni del cliente; esso esprime cosa il sistema deve fare. Non comprende indicazioni su
proprietà di performance da soddisfare, che vanno espresse in un ulteriore requisito, non
funzionale, di performance;
- Non-funzionale di performance: definisce proprietà e vincoli che il sistema deve soddisfare
su fattori relativi alle prestazioni attese/richieste (in termini di vincoli temporali e/o di
memoria). Non descrive una nuova funzionalità, ma può far riferimento ad una funzionalità
già espressa da un altro requisito funzionale
- Di interfaccia: descrive le modalità con cui il sistema interagisce con l’esterno (altri
sottosistemi, o con l’utente). Tali requisiti andranno nel documento dei requisiti di
.
5.6.4.1.2 Osservazioni
Secondo il glosssario IEEE, un requisito
"è una condizione/ una capacità che deve essere soddisfatta/posseduta [..] da un sistema [..] per
adempiere ad un contratto".
Pertanto, esso, attravero i suoi campi, dovrà esprimere la singola (una ed una sola) funzionalità
offerta.
Naturalmente, ciascun requisito software sarà in relazione con almeno un altro requisito: quello
di sistema, pertanto bisognerà tracciare tali collegamenti.
Una adeguata strutturazione dei requisiti produce importanti risultati in termini di una più
155 Oltre a quelli indicati, lo stato di un requisito potrà ricadere nelle categorie: "Obsoleto", "Sospeso", "Bozza",
"Finale".
119
rapida individuazione e risoluzione dei problemi connessi alla definizione dei requisiti stessi. E
infatti, è noto che, nelle prime fasi del processo di sviluppo, sia abbastanza comune interpretare in
maniera non corretta e/o incompleta un requisito.
Un altro aspetto rilevante riguarda il trattamento di quei requisiti "volatili", per cui un
approccio strutturato risulta più idoneo.
5.6.4.1.3 Software High Level Requirements
Illustrazione 49: Esempio di requisito di sistema
Sulla scorta delle linee guida fornite, per il sottosistema Propulsion si ricaverà il seguente requisito
software di alto livello, in cui trascuriamo i dettagli legati allo specifico progetto (dataset 500):
SR_PROP_1H
Nome: Control signal from TCMS
Input: Control signals
Precondizioni:
Descrizione: In each mode, TCMS shall provide to TCU the control signal
Output atteso: Control signal sent to TCU
Postcondizioni:
Tipologia: Functional
Si noti che, trattandosi di una specifica ad un alto livello di astrazione, i requisiti non
dovranno far riferimento agli aspetti vincolati alle scelte implementative ed alle tecniche di
verifica156. Infatti, essi dovranno rappresentare le caratteristiche comuni a prodotti della stessa
famiglia, dunque candidati al riuso. Per meglio comprendere questo aspetto, mostriamo l'esempio di
un requisito software del sistema freno del progetto MetroRiyadh:
156 Eccetto che per alcuni casi.
120
Illustrazione 50: Esempio di "sovra-specifica" nel requisito software
L'insieme delle informazioni relative ai segnali scambiati, così come la prescrizione
dell'utilizzo di particolari dataset, non dovrebbe essere indicato a questo punto del ciclo di sviluppo.
Nella fase di specifica, infatti, non bisognerebbe far riferimento al dominio della soluzione, tanto
meno vincolare le scelte da operare.
Inoltre, non bisognerebbe cadere neanche nell'errore opposto: descrivere un requisito in modo
troppo generico. Esso potrebbe esprimere funzionalità del sistema già note che non ne giustificano
l'esistenza. Ancor peggio, potrebbe accadere che questo esprima in maniera troppo implicita delle
funzionalità, dando luogo ad un requisito inutilizzabile.
La difficoltà di descrivere un requisito ad un giusto livello di dettaglio può essere mitigata
affidandosi da un canto al buon senso, dall'altro a metodi a supporto.
Prima di intraprendere la scrittura, bisognerebbe chiedersi se il requisito, così come sarà espresso,
sia o meno riusabile.
Inoltre, (cfr. § Scrittura dei requisiti) per poter scrivere i requisiti ad un adeguato livello di
granularità bisogna specificarli in maniera tale che siano verificabili individualmente, ovvero
sottoponibili a test.
Un metodo per capire se il requisito sia stato scritto al giusto livello di dettaglio è quello di
121
valutare il numero di casi di test necessari per verificare la correttezza della sua implementazione:
− un esiguo numero di casi di test ne indica, presumibilmente, l'idoneità;
− un cospicuo e diversificato numero di casi di test indicherà la necessità di scindere il
requisito in più requisiti.
Un secondo metodo consiste nel provare a confrontare i livelli di dettaglio del requisito
"sorgente" (utente/sistema) e del requisito software derivato. La comparabilità tra i due livelli indica
che il requisito software sia stato espresso ad un livello di dettaglio troppo alto. Infatti, tipicamente
un requisito utente esprime in maniera "grossolana" un servizio, il quale sarà scomponibile in un
insieme di funzionalità, ciascuna delle quali attribuibile ad un singolo requisito.
Dopo la scrittura sarà necessario tracciare i collegamenti (cfr. Tracciabilità):
•
orizzontali: collegando l'HLR al/ai requisito/o HLR con cui è in relazione (ad esempio di
dipendenza). Questa informazione sarà molto utile per valutare la consistenza del requisito
di alto livello e per l'analisi di impatto;
•
verticale: collegando l'HLR al/ai requisiti di sistema da cui deriva. Si noti che, in base alla
definizione di requisito derivato data dalla normativa DO-178B, potrebbero esservi casi in
cui non sia possibile tracciare verticalmente il requisito, perchè manca la corrispondenza.
La fase che segue la specifica dei requisiti di alto livello è quella di progettazione software, che
consentirà di pervenire all'archiettura del software ad ai requisiti di basso livello.
5.6.4.1.4 Low Level Software Requirements
La specifica dei requisiti software strutturata in livelli di astrazione ci conduce, a partire da
quelli di alto livello, ai Low Level Requirements157 (LLR).
A volte capita che un LLR derivi da più requisiti di alto livello.
I requisiti software di basso livello esprimono le informazioni omesse nei rispettivi HLR, cioè
quelle caratteristiche che specificano in che modo debba essere realizzata una data funzionalità in un
particolare progetto.
È proprio la specificità rispetto al caso in esame che rende questa classe di requisiti utili per
potervi derivare direttamente il codice sorgente.
Abbiamo già accennato all'utilità derivante dall'uso dei livelli di astrazione per anticipare il
feedback da parte dell'utente. In effetti, anche la scrittura degli LLR può fornire informazioni utili
rispetto al potenziale riuso dei relativi HLR.
Per meglio comprendere i concetti appena esposti, mostriamo un requisito relativo
all'interazione tra il TCMS ed al sistema freno:
157 Ricordiamo che da un HLR possono derivare requisiti descritti a più livelli, sempre più bassi.
122
Req_4: EB status detection, and information sending to ATC
Descrizione: TCMS can detect the status of EB Relay Bus loop by means of double breaks digital
inputs (EBRB+/-) and will provide on MVB the status of EBRB to ATC (Dataset 201 EB applied).
TCMS can detect the cause of EB application by means of the following digital inputs:
• Sts_MushRoomA/B (on A or B EDC, active low)
• Sts_ObstacleA/B (Obstacle detector on A-Side, active low)
• Sts_ DerlRxSensA/B (derailment sensor right side activated on A-Car, active low)
• Sts_ DerlLxSensA/B (derailment sensor right side activated on A-Car, active low)
Dal requisito di sistema estraiamo due requisiti software di alto livello:
ID: HLR_ Req_1
Nome: Cause of EB application_H
Input : Cause of EB application
Precondizioni : EB Application
Descrizione : TCMS can detect the cause of EB application by means of the digital inputs
Output atteso : Cause of EB application
Postcondizioni :
Tipologia : Functional
Criteri di verifica :
ID: HLR_ Req_2
Nome: EB application cause sent to ATC _H
Input : Information about EB application cause
Precondizioni : EB application
Descrizione : TCMS will provide the information about EB application cause on MVB to ATC even
if this information is directly available to ATC (by means of EB loop status). This information will
also be recorded by DBU. In case of EB request TCMS will provide (via MVB) the relative
information
Output atteso : Information about EB application cause on MVB to ATC and recorded by DBU
Postcondizioni :
123
Tipologia : Functional
Criteri di verifica :
ai quali seguiranno I rispettivi requisiti di basso livello:
ID: LLR_ Req_1
Nome: Cause of EB application_L
Input : Cause of EB application
Precondizioni : EB Application
Descrizione : TCMS can detect the cause of EB application by means of the following digital
inputs:
 Sts_MushRoomA/B (on A or B EDC, active low)
 Sts_ObstacleA/B (Obstacle detector on A-Side, active low)
 Sts_ DerlRxSensA/B (derailment sensor right side activated on A-Car, active low)
 Sts_ DerlLxSensA/B (derailment sensor right side activated on A-Car, active low)
Output atteso : Cause of EB application
Postcondizioni :
Tipologia : Functional/Safety
Criteri di verifica :
ID: LLR_ Req_2
Nome: EB application cause sent to ATC _L
Input : Information about EB application cause
Precondizioni : EB application
Descrizione : TCMS will provide the information about EB application cause on MVB to ATC
(dataset 201/202) even if this information is directly available to ATC (by means of EB loop status).
This information will also be recorded by DBU. In case of EB request TCMS will provide (via
MVB dataset 500) this information: Security Braking -> 1.
Output atteso : Information about EB application cause on MVB to ATC and recorded by DBU
Postcondizioni :
Tipologia : Functional/Safety
Criteri di verifica :
Durante la fase di specifica di ciascun requisito di basso livello bisognerà, naturalmente,
124
tracciare i collegamenti tra quest'ultimo ed il/i requisiti di alto livello con cui sussiste una "relazione
di derivazione".
Per questa classe di requisiti valgono tutte le considerazioni fatte per gli HLR, ma non è posto
alcuna restrizione alla lunghezza158 della descrizione, poichè dovranno rappresentare informazioni
più dettagliate.
Si noti che, in base alla definizione di requisito derivato data dalla normativa DO-178B,
potrebbero esservi casi in cui non sia possibile tracciare un LLR con uno o più HLR, poichè manca
la corrispondenza.
5.6.4.1.5 Casi d'uso, scenari di interazione e gerarchie di requisiti
Un requisito di alto livello rappresenta una funzionalità richiesta al sistema, che sarà espressa
come un flusso di azioni da eseguire. È necessario, però, valutare i casi d'uso in cui il flusso normale
subisca delle deviazioni, dando luogo a flussi alternativi. Abbiamo già discusso questa evenienza
(cfr. § Scenari di interazione e casi d'uso), indicando come "padre" il caso d'uso che identifica la
funzionalità base, mentre come "figli" quelli che esprimono le possibili variazioni (scenari) della
stessa funzionalità.
Questa relazione di "parentela" si tradurrà in una classificazione gerarchica dei requisiti.
Un requisito deve essere numerato e numerabile all'interno di un documento SRS, pertanto, la
gerarchia sarà esplicitata assegnando al "requisito padre" un identificativo numerico che rispecchierà
la relazione con i "figli".
È bene notare che possono esservi casi in cui il flusso normale di eventi segua una piccola
variazione, tale per cui non si ritenga necessario derivare un ulteriore requisito che rappresenti
questa situazione.
Quanto detto è, normalmente, applicabile ai requisiti a tutti i livelli di astrazione.
Il flusso normale di eventi descrive le azioni intraprese a seguito di un "esito positivo" ed
indica una (post)condizione che, come mostrato, sarà comune ad entrambi i requisiti derivati. Infatti,
i controlli eseguiti dal TCMS termineranno, dando luogo ai due possibili esiti "checks KO" e
"checks OK".
Inoltre, i due requisiti figli esprimeranno ciascuno un flusso alternativo, specificando in quali
situazioni possa verificarsi e descrivendo l'azione a seguito intrapresa.
Rispetto ai requisiti software di basso livello, vi sono alcune considerazioni che vale la pena
approfondire.
Come è noto, essi dettagliano gli HLR che potranno essere strutturati gerarchicamente: in tal
158È consigliabile scrivere i requisiti di alto livello in poche righe (4-5) (cfr. § Scrittura dei requisiti).
125
caso, i LLR dovranno particolareggiare159 lo scenario descritto dai requisiti figli di alto livello.
Si noti che, al momento della specifica di un requisito di basso livello, si potrà ancora
manipolare il relativo requisito HL, scorporandolo in "padre – figlio", qualora se ne avvertisse la
necessità.
Al contrario, se non vi fosse la possibilità di scorporare il requisito HL di partenza, per non
sconfinare nel dominio della soluzione160, l'operazione potrà ancora essere svolta nel corrispondente
requisito di basso livello. Naturalmente, in tal caso si perverebbe ad un requisito "padre" di basso
livello, al quale seguiranno nella scala gerarchica i requisiti "figli" di basso livello.
Quanto detto può essere riscontato nell'esempio che segue, riferito all'interazione tra il TCMS
ed il sistema di propulsione, in cui con "nome_requisito_H" sono stati indicati i requisiti del
documento di specifica di alto livello, mentre con "nome_requisito_L", quelli relativi al documento
di specifica di basso livello.
5.6.4.1.6 Interazioni con altri sottosistemi
Un aspetto importante che bisogna tener presente durante la scrittura dei requisiti riguarda il
livello di dettaglio con cui devono essere espresse le interazioni tra il sistema a cui si riferisce il
requisito che si sta descrivendo e gli altri sottosistemi.
Supponiamo di dover specificare un requisito relativo ad un sistema A, in cui le azioni
descritte riguardino l'interazione tra A ed un secondo sistema B.
Ad esempio, supponiamo che A possa fornire una certa funzionalità a condizione che:
−B intraprenda particolari azioni, di sua sola pertinenza;
−B fornisca ad A informazioni sull'esito delle azioni intraprese.
In tal caso, le azioni di B dovranno essere solo menzionate nella descrizione del requisito di A,
così da specificare la sua responsabilità nel flusso di eventi.
Piuttosto, tutti gli aspetti tralasciati in questa sede saranno ripresi e dettagliati nella fase di
specifica del sistema B.
Anche in questo caso sarà necessario tracciare la relazione tra il requisito di A ed il requisito
di B (sia nel caso di HLR che di LLR).
5.6.4.1.7 La tracciabilità
La tracciabilità fissa la relazione tra i prodotti del processo di sviluppo, ciò comporta che
159 Ad esempio, nei LLR dovranno essere specificati anche i segnali scambiati tra le unità interagenti.
160 Ad esempio, se scorporare il requisito in caso d'uso e scenari alternativi possa comportare la descrizione del
"come" , invece del "cosa".
126
ciascun ingresso di una fase dovrà essere posta in relazione con una specifica uscita di questa stessa
fase.
È questo un concetto tanto importante quanto critico, che deve essere affrontato fissando in
maniera chiara quali siano i soggetti coinvolti in questa operazione.
Rifacendoci all'approccio strutturato in livelli di astrazione, nell'ambito di questa fase del ciclo
di sviluppo, contemporaneamente alla scrittura dei requisiti, sarà necessario:
• Tracciare ciascuno requisito funzionale di sistema con i requisiti di interfaccia menzionati;
• Tracciare ciascun requisito software di alto livello con il/i corrispondente/i requisiti di
sistema da cui deriva;
• Tracciare ciascun requisito software di alto livello con il/i requisiti di altri sottosistemi dei
quali cita le azioni;
• Tracciare ciascun requisito software di basso livello con il/i requisito/i software di alto livello
da cui deriva;
• Tracciare ciascun requisito software di alto livello con il/i requisiti di altri sottosistemi dei
quali cita le azioni.
Inoltre, in relazione al contesto in esame, distinguiamo la tracciabilità:
• Orizzontale: i collegamenti tra requisiti allo stesso livello di astrazione tra i quali sussiste
una relazione.
• Verticale: collegamenti tra requisito "derivato" e requisito "sorgente" (ad esempio tra un
requisito software di alto livello ed il requisito di sistema da cui deriva).
127
Esempi
Esempio 1
Requisito originario:
REQ_BRAKE_61
As above described when the train will depart, the following action will be provided (see document
[2.11] for more details ):
 ATO release the Propulsion Cut Out (set High) and
commands on MVB (dataset 707/708) Coasting and
SHR_ATO_01
SLR_ATO_01
Propulsion Reset, the effort request is set to 0%.
 TCMS will command the Coasting (dataset 500)
and set to 0 Service Brake bit. TCMS set high
SHR_TCMS_01
SLR_TCMS_01
the braking Train Line
(Cmd_Braking =1) -> service brake set OFF. BCU will send back the status of service and holding
brake bits.
 ATO set traction bit =1 on MVB and Coasting and
Propulsion Reset bit = 0 and set the effort request to
SHR_ATO_02
SLR_ATO_02
50%.
 TCMS will replay the traction effort requested by
ATO on MVB to BCU and TCU.
SHR_TCMS_02
SLR_TCMS_02
If both TCU are active (no fault present), the TCMS
will set high the stopping brake command (wired and
low on MVB) at the same time when it requests traction
effort. If one TCU is not able to provide effort, the
TCMS will provide set high (wired and low on MVB)
SHR_TCMS_03
SHR_TCMS_03_scen1
SHR_TCMS_03_scen2
SLR_TCMS_03_scen1
SLR_TCMS_03_scen2
the stopping brake when the total train traction effort
applied will reach the 10% of the maximum ( 14 kN).
128
The minimum threshold applied effort value can be tuned
during integration test with ATC system
 The BCU will release the brake cylinders and set 0 on
MVB the Stopping Brake status. The BCU will use the
SHR_BCU_01
SLR_BCU_01
wired or MVB stopping brake command to release the brakes.
 The train will start to move
PASSAGGIO AI REQUISITI SOFTWARE DI ALTO E BASSO LIVELLO
Frase originaria: ATO release the Propulsion Cut Out (set High) and commands on MVB (dataset
707/708) Coasting and Propulsion Reset, the effort request is set to 0%.
ID: SHR_ATO_01
LINK a REQ_BRAKE_61
Nome: Traction release by ATO
Input:
Precondizioni: The train is departing
Descrizione: ATO shall release the Propulsion Cut Out and shall command Coasting and Propulsion
Reset. ATO shall set the effort request to 0%
Output: Coasting and Propulsion Reset
Postcondizioni: The effort request is set to 0%
Tipologia: Functional
ID: SLR_ATO_01
Link a SHR_ATO_01 (HLR)
Nome: Traction release by ATO
Input:
Precondizioni: The train is departing
Descrizione: ATO shall release the Propulsion Cut Out (set High) and shall command Coasting and
Propulsion Reset on MVB (dataset 707/708). ATO shall set the effort request to 0%
Output: Coasting and Propulsion Reset on MVB through dataset 707/708
Postcondizioni: The effort request is set to 0%
129
Tipologia: Functional
Frase originaria: TCMS will command the Coasting (dataset 500) and set to 0 Service Brake bit.
TCMS set high the braking Train Line (Cmd_Braking =1) -> service brake set OFF. BCU will send
back the status of service and holding brake bits.
ID: SHR_TCMS_01
LINK a REQ_BRAKE_61
Nome: Traction release by TCMS
Input: Coasting and Propulsion Reset commands on MVB by ATC
Precondizioni:
Descrizione: TCMS shall command the Coasting, shall release the Service Brake , and shall set the
braking Train Line to high (service brake set to OFF)
Output: Coasting commanded, Service Brake released and Braking Train Line set to off.
BCU shall send back the status of service and holding brake (Link a SHR_BCU_01)
Postcondizioni:
Tipologia: Functional
ID: SLR_TCMS_01
Link a SHR_TCMS_01 (HLR)
Nome: Traction release by TCMS
Input: Coasting and Propulsion Reset commands on MVB by ATC through dataset 707/708
Precondizioni: SLR_ATO_1 satisfied
TCMS shall command the Coasting (dataset 500), shall set the Service Brake bit to 0, and shall set
the braking Train Line to high (service brake set to OFF)
Output: Coasting ->1 on MVB, Service Brake ->0, Train Line ->1.
BCU shall send back the status of service and holding brake (Link a SHR_BCU_01)
Postcondizioni:
Tipologia: Functional
Frase originaria: ATO set traction bit =1 on MVB and Coasting and Propulsion Reset bit = 0 and
set the effort request to 50%.
ID: SHR_ATO_02
130
LINK a REQ_BRAKE_61
Nome: Traction command by ATO
Input:
Precondizioni: SHR_TCMS_01 satisfied
Descrizione: ATO shall anable the Traction and disable Coasting and Propulsion and set the effort
request to a value greater than 0%.
Output: Effort Request to TCMS
Postcondizioni: Traction enabled and Coasting/Propulsion disabled.
Tipologia: Functional
ID: SLR_ATO_02
Link a SHR_ATO_02 (HLR)
Nome: Traction command by ATO
Input:
Precondizioni:
Descrizione: ATO shall set traction bit =1 on MVB and Coasting and Propulsion Reset bit = 0 and
set the effort request to 50%.
Output: Effort Request = 50% to TCMS
Postcondizioni: Traction bit =1, Coasting and Propulsion Reset bit=0
Tipologia: Functional
Frase originaria: TCMS will replay the traction effort requested by ATO on MVB to BCU and TCU.
ID: SHR_TCMS_02
LINK a REQ_BRAKE_61
Nome: Traction effort by TCMS
Input: Traction effort by ATO
Precondizioni:
Descrizione: TCMS shall replay the traction effort requested by ATO to BCU and TCU.
Output: Traction effort to BCU and TCU
Postcondizioni:
Tipologia:Functional
ID: SLR_TCMS_02
131
Link a SHR_TCMS_02 (HLR)
Nome: Traction effort by TCMS
Input: Traction effort =50% by ATO
Precondizioni:
Descrizione: TCMS shall replay the traction effort requested by ATO on MVB through dataset 500
to BCU and TCU.
Output: Traction effort = 50% on MVB through dataset 500 to BCU and TCU
Postcondizioni:
Tipologia:Functional
Frase originaria: TCU will replay on dataset 401, 402 (ED_Actual) the applied effort.
ID: SHR_TCU_01
LINK a REQ_BRAKE_61
Nome: Applied effort by TCU
Input: Traction effort by TCMS
Precondizioni:
Descrizione: TCU shall replay the applied effort to the TCMS
Output: Applied effort replayed to the TCMS
Postcondizioni:
Tipologia:Functional
ID: SLR_TCU_01
Link a SHR_TCU_01
Nome: Applied effort by TCU
Input: Traction effort =50% on MVB by TCMS
Precondizioni:
Descrizione: TCU shall replay on dataset 401, 402 (ED_Actual) the applied effort.
Output: Applied effort via MVB on dataset 401, 402 (ED_Actual)
Postcondizioni:
Tipologia: Functional
Frase originaria: If both TCU are active (no fault present), the TCMS will set high the stopping
brake command (wired and low on MVB) at the same time when it requests traction effort. If one
132
TCU is not able to provide effort, the TCMS will provide set high (wired and low on MVB)the
stopping brake when the total train traction effort applied will reach the 10% of the maximum ( 14
kN). The minimum threshold applied effort value can be tuned during integration test with ATC
system
ID: SHR_TCMS_03
Link a REQ_BRAKE_61
Nome: Set Stopping Brake command
Input: TCUs conditions
Precondizioni:
Descrizione: The TCMS shall enable the Stopping Brake
Output:
Postcondizioni: Stopping Brake enabled
Tipologia:Functional
ID: SHR_TCMS_03_scenario1
Nome: TCUs are active
Input:
Precondizioni: TCUs are active (no fault condition)
Descrizione:The TCMS shall set the stopping brake command to high at the same time when it
requests traction effort.
Output:
Postcondizioni: Stopping Brake enabled
Tipologia:Functional
ID: SHR_TCMS_03_scenario2
Nome: One TCU is not active
Input:
Precondizioni: One TCU is not able to provide effort
Descrizione: The TCMS shall enable the Stopping Brake when the total train traction effort applied
will reach the fixed value of the maximum. The minimum threshold applied effort value can be
tuned during integration test with ATC system
Output: Stopping Brake enabled
133
Postcondizioni:
Tipologia:Functional
ID: SLR_TCMS_03_scenario1
Link a SHR_TCMS_03_scenario1 e REQ_BRAKE_61
Nome: TCUs are active
Input:
Precondizioni: TCUs are active (no fault condition)
Descrizione:The TCMS shall set the stopping brake command to high (wired and low on MVB) at
the same time when it requests traction effort.
Output:
Postcondizioni: Stopping Brake ->1
Tipologia:Functional
ID:SHR_TCMS_03_scenario2
Link a SHR_TCMS_03_scenario2 e REQ_BRAKE_61
Nome: One TCU is not active
Input:
Precondizioni:One TCU is not able to provide effort
Descrizione: The TCMS shall set the stopping brake to high (wired and low on MVB) when the total
train traction effort applied will reach the 10% of the maximum (14 kN). The minimum threshold
applied effort value can be tuned during integration test with ATC system
Output: Stopping Brake ->1
Postcondizioni:
Tipologia:Functional
Frase orginiaria: The BCU will release the brake cylinders and set 0 on MVB the Stopping Brake
status. The BCU will use the wired or MVB stopping brake command to release the brakes. The
train will start to move
ID: SHR_BCU_01
LINK a REQ_BRAKE_61
Nome: Train departure
Input: Stopping Brake command by TCMS
134
Precondizioni:
Descrizione: The BCU shall release the brake cylinders and shall release the Stopping Brake.
The BCU shall release the brake.
Output: Stopping Brake released
Postcondizioni:Brakes released
Tipologia:Functional
ID: SLR_BCU_01
Link a SHR_BCU_01
Nome: Train departure
Input: Stopping Brake ->1 by TCMS
Precondizioni:
Descrizione: The BCU shall release the brake cylinders and set 0 on MVB the Stopping Brake
status. The BCU shall use the wired or MVB stopping brake command to release the brakes.
Output: Stopping Brake ->0 on MVB
Postcondizioni: Brakes released
Tipologia:Functional
Esempio 2
Requisito originario:
REQ_BRAKE_13a
In case of wheel sliding in traction or braking, the TCU
SRH_TCMS_01
SRL_TCMS_01
or BCU (dataset 5x2) will inform about this condition
the TCMS.
BCU can also directly demand senders activation
directly on MVB (dataset 5x3).
SRH_BCU_01
SRL_BCU_01
In both cases TCMS will command the sanders in agreement
135
with train direction (Cmd_SandA/B->1) if the sliding is
detected for more than 500ms in agreement with train
direction or until the sand request is active.
SRH_TCMS_01
SRL_TCMS_01
The sander activation will last until the above condition
are active and will stop when the vehicle will reach the
standstill condition (V <1km/h).
The vehicle is equipped with sensors to monitor the sanding level of sanders (Sts_SandLev1/2 for
each wheel side).
Passaggio ai requisiti software di alto e basso livello:
Frase originaria: In case of wheel sliding in traction or braking, the TCU or BCU (dataset 5x2)
will inform about this condition the TCMS.
BCU can also directly demand senders activation directly on MVB (dataset 5x3).
ID: SHR_BCU_01
REQ_BRAKE_13a
Nome: Wheel sliding in braking
Input:
Precondizioni:Wheel sliding in braking
Descrizione: The BCU shall inform about this condition the TCMS. BCU could also directly
demand senders activation.
Output atteso:Wheel sliding information or sanders activation request sent to TCMS
Postcondizioni:
Tipologia:Functional/Safety
ID: SLR_BCU_01
Link a SHR_BCU_01 (HLR)
Nome: Wheel sliding in braking
Input:
Precondizioni:Wheel sliding in braking
136
Descrizione:The BCU (dataset 5x2) shall inform about wheel sliding condition the TCMS on MVB
(dataset 502).
BCU can also directly demand senders activation directly on MVB (dataset 5x3).
Output atteso:Wheel sliding information sent to TCMS on MVB (dataset 5x2) or sanders activation
request sent to TCMS on MVB through dataset 5x3
Postcondizioni:
Tipologia: Functional/Safety
frase originaria: In both cases TCMS shall command the sanders in agreement with train direction
if the sliding is detected for more than a fixed value in ms or until the sand request is active.
The sanders activation shall last until the above condition are active and shall stop when the vehicle
shall reach the standstill condition.
ID: SHR_TCMS_01
Link a REQ_BRAKE_13a (FRS)
Nome: Wheel sliding in traction or braking
Input: Wheel sliding information by TCU or BCU or sanders activation request by BCU
Precondizioni:
Descrizione: TCMS shall command the sanders in agreement with train direction if the sliding is
detected for more than fixed value in ms in agreement with train direction or until the sand request is
active.
The sander activation shall last until the above condition are active and shall stop when the vehicle
will reach the standstill condition.
Output atteso:Sanders activation commanded
Postcondizioni:
Tipologia:Functional/Safety
ID: SLR_TCMS_01
Link a SHR_TCMS_01 (HLR)
Nome: Wheel sliding in traction or braking
Input: Wheel sliding information by TCU or BCU on MVB through dataset 5x2 or sanders
activation request by BCU on MVB through dataset 5x3.
Precondizioni:
137
Descrizione: TCMS shall command the sanders in agreement with train direction (Cmd_SandA/B>1) if the sliding is detected for more than 500ms in agreement with train direction or until the sand
request is active.
The sander activation shall last until the above condition are active and shall stop when the vehicle
will reach the standstill condition (V <1km/h).
Output atteso:Sanders activation commanded.
Postcondizioni:
Tipologia: Functional/Safety
Esempio 3
Requisito originario:
REQ_PROP_06
During the train service TCMS will provide enable
to run signal high also at each train station departure.
If this signal is low, the ATC will not allow train
SRH_TCMS_01
SRL_TCMS_01
ID: SRH_ATC_01
departure from stations.
PASSAGGIO AI REQUISITI SOFTWARE DI ALTO E BASSO LIVELLO
frase originaria: During the train service TCMS will provide enable to run signal high also at each
train station departure.
ID: SHR_TCMS_01
LINK a REQ_PROP_06
Nome: Enable to run signal
Input:
Precondizioni: Train in service and at each train station departure
Descrizione: TCMS will provide enable to run to ATC.
Output atteso: Enable to run sent to ATC
Postcondizioni:
138
Tipologia:Functional
ID: SLR_TCMS_01
Link a SHR_TCMS_01 (HLR)
Nome: Enable to run signal
Input:
Precondizioni: Train in service
Descrizione: During the train service TCMS shall provide enable to run signal high also at each train
station departure to ATC on MVB through dataset 202 (active high).
Output atteso:Enable to run signal high sent to ATC on MVB through dataset 202 (active high).
Postcondizioni:
Tipologia:Functional
frase originaria: If this signal is low, the ATC will not allow train departure from stations.
ID: SHR_ATC_01
Link a REQ_PROP_06
Nome: Enable to run signal
Input: Enable to run by TCMS
Precondizioni:
Descrizione: The ATC shall command or shouldn't command the train departure from stations((Link
a SHR_TCMS_01).
Output atteso: Train departure commanded
Postcondizioni:
Tipologia: Functional
ID: SLR_ATC_01
Link a SHR_ATC_01
Nome: Enable to run signal
Input: Enable to run signal by TCMS on MVB through dataset 202 (active high)
Precondizioni:
Descrizione: If this enable to run signal is low, the ATC shouldn't allow train departure from
stations.
139
Output atteso:Train departure commanded
Postcondizioni:
Tipologia:Functional
Esempio 4
Requisito originario:
REQ_PROP_10
In this case of TCU fault, the failed TCU will provide
diagnostic
SRH_TCU_1
SRL_TCU_1
information to TCMS on MVB (dataset 41X, X=1,2,
Autoexlusion bit) and wired (TCU KO, PropA/B_flt active low).
The TCMS will provide a diagnostic indication on
EDC (Lmp_MajFlt->1).
SRH_TCMS_01
SRL_TCMS_01
TCMS will also provide diagnostic information
TCU_X Major Fault to ATC (dataset 201).
In this case it shall be provide a passenger
disembark procedure at the next station.
TCU will also provide a life signal on MVB (dataset 43X).
SRH_TCU_02
SRL_TCU_02
TCU will detect the HSCB status: if this one is not correctly
closed, TCU won’t allow the propulsion.
So if TCU is OK, after received the ATC readiness signal
the TCMS will command the HSCB1 and HSCB2 to close
SRH_TCMS_02
SRL_TCMS_02
(Cmd_HSCB1/2->1) (see document [2.8] for more details
about TCMS closing commands.
PASSAGGIO AI REQUISITI SOFTWARE DI ALTO E BASSO LIVELLO
140
frase originaria: In this case of TCU fault, the failed TCU will provide diagnostic information to
TCMS on MVB (dataset 41X, X=1,2,Autoexlusion bit ) and wired (TCU KO, PropA/B_flt active
low).
ID: SHR_TCU_01
Link a REQ_PROP_10
Nome: TCU fault
Input:
Precondizioni:TCU fault
Descrizione: The failed TCU shall provide diagnostic information to TCMS
Output atteso:Diagnostic information to TCMS and wired
Postcondizioni:
Tipologia:Functional/Safety
ID: SLR_TCU_01
Link a SHR_TCU_01
Nome: TCU fault
Input:
Precondizioni:TCU fault
Descrizione: The failed TCU will provide diagnostic information to TCMS on MVB (dataset 41X,
X=1,2,Autoexlusion bit ) and wired (TCU KO, PropA/B_flt active low).
Output atteso:Diagnostic information sent to TCMS on MVB (dataset 41X, X=1, 2, Autoexlusion
bit ) and wired (TCU KO, PropA/B_flt active low).
Postcondizioni:
Tipologia:Functional/Safety
frase originaria: The TCMS will provide a diagnostic indication on EDC (Lmp_MajFlt->1).
ID: SHR_TCMS_01
Link a REQ_PROP_10
141
Nome: Diagnostic information about TCU fault
Input: Diagnostic information sent by TCU
Precondizioni:
Descrizione: The TCMS shall provide a diagnostic indication on EDC.
Output atteso: Diagnostic indication on EDC
Postcondizioni:
Tipologia:Functional/Safety
ID: SLR_TCMS_01
Link a SHR_TCMS_01
Nome: Diagnostic information about TCU fault
Input: Diagnostic information sent by TCU on MVB (dataset 41X, X=1, 2, Autoexlusion bit ) and
wired (TCU KO, PropA/B_flt active low).
Precondizioni:
Descrizione: The TCMS will provide a diagnostic indication on EDC (Lmp_MajFlt->1).
Output atteso:Diagnostic indication on EDC (Lmp_MajFlt->1)
Postcondizioni:
Tipologia:Functional/Safety
frase originaria: TCMS will also provide diagnostic information TCU_X Major Fault to ATC
(dataset 201).
In this case it shall be provide a passenger disembark procedure at the next station.
ID: SHR_TCMS_02
LINK a REQ_PROP_10
Nome: Diagnostic information
Input:Diagnostic Information sent by TCU
Precondizioni:
Descrizione: TCMS shall also provide diagnostic information to ATC.
In this case it shall be command passenger disembark at the next station.
Output atteso:Diagnostic information sent to ATC. Passenger disembark commanded
142
Postcondizioni:
Tipologia:Functional/Safety
ID: SLR_TCMS_02
Link a SHL_TCMS_02
Nome: Diagnostic information
Input: Diagnostic informationsent on MVB (dataset 41X, X=1, 2, Autoexlusion bit ) and wired
(TCU KO, PropA/B_flt active low)
Precondizioni:
Descrizione: TCMS will also provide diagnostic information TCU_X Major Fault to ATC (dataset
201). In this case it shall be provide a passenger disembark procedure at the next station.
Output atteso:Diagnostic information TCU_X Major Fault to ATC on MVB through dataset 201.
Passenger disembark procedure provided.
Postcondizioni:
Tipologia: Functional/Safety
frase originaria: TCU will also provide a life signal on MVB (dataset 43X).
TCU will detect the HSCB status: if this one is not correctly closed, TCU won’t allow the
propulsion.
ID: SHR_TCU_02
Link a REQ_PROP_10
Nome: HSCB status
Input: HSCB status
Precondizioni:
Descrizione: TCU shall detect the HSCB status
Output atteso: HSCB status detected
Postcondizioni:
Tipologia:Functional
ID: SLR_TCU_02
Link a SHR_TCU_02
Nome: HSCB status
143
Input: HSCB status
Precondizioni:
Descrizione: TCU shall also provide a life signal on MVB (dataset 43X).
TCU shall detect the HSCB status
Output atteso:HSCB status detected
Postcondizioni:
Tipologia: Functional
144
5.7 IBM Rational DOORS: un tool per la Requirements Management
IBM Rational DOORS è uno dei più diffusi tool di Requirements Management.
Grazie alle funzionalità offerte e ad un’interfaccia web intuitiva, lo strumento consente ad un
team di progetto di gestire e controllare requisiti complessi, per questo talvolta multi-livello,
superando processi di revisione cartacei.
Attraverso l’interazione con il Database del Server, DOORS consente ad un gruppo eterogeneo
di utenti di poter lavorare sullo stesso progetto, condividendone i risultati.
In questa sezione mostreremo in che modo adoperare il tool, in linea con le prescrizioni
relative alla scrittura dei requisiti, con la loro scomposizione in livelli diversi di astrazione, con i
criteri di tracciabilità orizzontale e verticale.
Si è cercato di favorire l'utilizzo del tool DOORS, evidenziando in che misura una adeguata
gestione dei requisiti possa comportare risultati tesi verso un maggior riuso e manutenibilità.
Pertanto, è stata ideata una struttura di progetto, il Project Template, attualmete disponibile
all’interno del DOORS Database (DOORS AnsaldoBreda), atto a contenere tutta la documentazione
relativa ad un progetto.
Infatti, esso presenta un insieme strutturato di sottocartelle, ciascuna relativa ad una sezione
specifica del progetto ed alla quale le diverse figure coinvolte potranno accedere facilmente.
Dunque, a partire dal capitolato tecnico, si è mostrato in che modo ottenere documenti di
specifica dei requisiti di sistema, di specifica dei requisiti software di alto e basso livello, collegando
in maniera opportuna gli oggetti per ottenere informazioni sulla tracciabilità, analisi di impatto.
Creata una struttura di progetto, costituita da sei sezioni, ciascuna della quali atta a contenere
una determinata tipologia di documenti, si è proceduto all'applicazione dei concetti illustrati nei
precedenti paragrafi.
5.7.1 La struttura del progetto
Il progetto è strutturato come un insieme di sezioni:
145
Illustrazione 51: DOORS: Il Project Template
00 – Norme Vigenti
Contiene le normative vigenti a cui fare riferimento.
01- Links
Contiene i moduli per realizzare i collegamenti tra requisiti, a diversi livelli, dai requisiti di sistema
ai requisiti software, sino alla loro mappatura ai moduli ed ai casi di test. In particolare sono presenti
i seguenti moduli: FRS_Links, SRS_Links, Moduli_Links, Test_Links.
02 – Contractual Documents
Sezione contenente i documenti contrattuali del progetto, ovvero il capitolato tecnico, e le relative
appendici, nonché una cartella con gli standard ed i documenti di riferimento.
03 – System Requirements
Sezione contenente i requisiti per ogni sottosistema. Essa contiene le informazioni attualmente
presenti negli FRS (prefisso EC), come Riepilogo Revisioni, Definizioni ed Acronimi, Standard di
riferimento, System Architecture Description, Hardware Interface Description e requisiti non
funzionali. I documenti presenti sono: System Requirements Specification, System Requirements
Specification Test, System Functional Description, Links.
04 – Software Requirements
Sezione contente i requisiti software per ogni sottosistema. Essa contiene i documenti di Software
Requirements Specification, High Level Requirements, Low Level Requirements, Interface
Requirements, Software Requirements Test Specification, Software Design Description, Software
Modules, Software Test, Software Requiremetns Traceability Matrix.
05 – Project Management
146
Sezione contenente la documentazione necessaria alla gestione del progetto: Link, Attributi (di
modulo e di oggetto) e Template.
Ricordiamo che i concetti relativi alla gestione dei requisiti, discussi nella prima parte di questo
capitolo, sono stati applicati al sottosistema TCMS del progetto MetroRiyadh. Il lavoro è stato
svolto valutando le interazioni con: il sistema di propulsione, il sistema freno, il sistema High
Voltage, il sistema Low Voltage.
5.7.2 Dal capitolato ai requisiti di sistema/veicolo
Il punto di partenza del lavoro è stato l'insieme della documentazione dei requisiti funzionali
di sistema (FRS – Functional Requirements Specification).
Ciascuno di essi è stato importato in un documento DOORS, nominato FRS_nome_sistema,
collocato nella sezione System Requirements del Project Template. In particolare, ad un documento
siffatto è associato l'attributo "Descrizione", che conterrà, per ciascun requisito, la relativa
descrizione.
Un'importante osservazione riguarda la caratteristica del tool di associare automaticamente un
identificativo161 (l'attributo ID) a ciascun oggetto del documento. Ciò consentirà di pervenire, senza
alcuno sforzo, a requisiti numerati e numerabili.
Illustrazione 52: Il campo descrizione di un documento FRS
Pertanto, il primo passo compiuto ha riguardato l'individuazione delle voci del capitolato
tecnico di MetroRiyadh162, dalle quali sono stati identificati alcuni requisiti di sistema. Non ci
riferiamo a questi ultimi come requisiti funzionali, poichè alcuni di essi non presentano tale
caratteristica.
161 Al momento della creazione del documento, per l'identificativo potrà essere selezionato il prefisso, al quale seguirà
un valore numerico. Si potrà, naturalmente, decidere da quale valore associare, all'interno del documento, il primo
oggetto.
162 Trattandosi di un esempio, la corrispondenza è stata trovata solo per un piccolo numero di voci.
147
Si noti che, come abbiamo già discusso, un certo numero di requisiti di sistema derivano da
scelte progettuali prettamente aziendali, dettate dall'esperienza del dominio applicativo maturata.
Pertanto:
•
sono state tracciate le corrispondenza tra gli oggetti del capitolato ed i requisiti di sistema.
Illustrazione 53: Tracciabilità FRS_CapitolatoTecnico
5.7.3 Dai requisiti di sistema/veicolo agli HLR
Seguendo le linee guida sulla stesura dei requisiti163
•
è stato generato il documento dei requisiti di alto livello, inserito nella sezione Software
Requirements della struttura del progetto;
•
sono stati inseriti i campi necessari alla strutturazione;
•
sono stati inseriti i requisiti di alto livello, numerati automaticamente dal tool;
•
sono stati tracciati i collegamenti orizzontali con i requisiti dello stesso livello,
specializzando il link con l'attributo "DIPENDE DA";
•
sono stati tracciati i collegamenti con il/i requisito/i relativo/i dei sistemi "interagenti" (cfr. §
Interazione tra sottosistemi);
•
sono stati tracciati i collegamenti verticali con i requisiti di sistema da cui derivano,
163 Il documento è stato prodotto dall'Ing. Roberto Pietrantuono.
148
ricavando la corrispondente matrice di tracciabilità.
Illustrazione 54: Estratto di una matrice di tracciabilità (riferimento verticale)
5.7.4 Dal requisito HL al requisito LL
Come prescritto nelle linee guida:
•
è stato creato un documento dei requisiti di basso livello, inserito nella sezione Software
Requirements;
•
sono stati creati i campi necessari alla ristrutturazione;
•
a partire dai requisiti di alto livello, sono stati specificati i requisiti di basso livello;
•
sono stati tracciati i collegamenti tra i requisiti LL ed i corrispondenti requisiti HL, ricavando
la matrice di tracciabilità.
Illus
trazione 55: Matrice di tracciabilità HLR - LLR
5.7.5 Dai LLR ai Moduli Software
I moduli software, così come i documenti relativi ai test effettuati, sono collocati in
Subversion. Pertanto, per facilitare la creazione di link tra i requisiti software di basso livello e le
rispettive implementazioni, è stato necessario:
•
creare un documento DOORS collocato nella sezione Software Requirements;
149
•
nominare ogni oggetto con l'indirizzo web destinazione, in cui fosse reperibile il modulo
software.
Infatti, sfruttando la funzionalità del tool di creare link esterni, il modulo non perde il
significato di "oggetto", che rappresenta l'unica entità con cui abbia senso creare
collegamenti in DOORS.
Dopodichè, si sono tracciati i collegamenti tra i requisiti software di basso livello ed i relativi
moduli software che li implementano, ottenendo la matrice di tracciabilità.
Illustrazione 56: Esempio di tracciabilità tra LH e Moduli software
5.7.6 Moduli Software e Test
La sezione relativa ai test di modulo è disponibile in Subversion ed è costituita da File Test e
dai relativi Report. Pertanto:
•
è stato creato un documento per ciascuna tipologia di file in Software Requirements;
•
come per i moduli software, si è pensato di nominare ogni oggetto con l'indirizzo web
destinazione, in cui fosse reperibile il file test ed i Report ;
•
Dopodichè, si sono tracciati i collegamenti tra i moduli software ed i relativi moduli File Test
che li verificano, ottenendo la relativa matrice di tracciabilità;
•
Ciascun Report è stato linkato al corrispondente File Test.
150
Illustrazione 57: Esempio di tracciabilità tra Modulo Software e File Test
151
Conclusioni
Quanto mostrato in questo capitolo rappresenta il risultato della prima fase dell'Inizativa Software
Finmeccanica svolta in AnsaldoBreda. Peraltro, nonostante le proposte siano state accettate, non
risultano, allo stato, ancora validate dall'azienda. Di conseguenza, alcuni interventi potrebbero essere
ancora rivisti per incontrare le esigenze aziendali.
Per il momento, l'attività si conclude con la redazione di due documenti (le linee guida per la
scrittura dei requisiti ed un manuale sulle modalità operative del tool DOORS) e con l'intento da
parte dell'azienda di attuare gli interventi proposti nel prossimo progetto. In particolare, gli sforzi si
concentreranno su di un sottosistema scelto dai sistemisti AnsaldoBreda.
Come è stato già detto, gli interventi nel progetto MetroRiyadh sono stati operati a scopo
esercitativo e dimostrativo, poichè, da un canto vi era la necessità del gruppo di lavoro di
approfondire la conoscenza del dominio, dall'altro la necessità dell'azienda di comprendere,
attraverso degli esempi, gli interventi proposti.
Con il proseguimento dell'attività, nasceranno ulteriori esigenze ed opportunità che dovranno essere
colte dall'azienda, al fine di migliorare il processo di sviluppo e, di conseguenza, il prodotto.
152
Appendice
Scenari
Gli scenari si differenziano in base al punto di vista considerato, pertanto, distinguiamo:
•
As-is scenario: la descrizione del sistema proviene dall'utente e riguarda una situazione
corrente.
Un esempio potrebbe essere lo scenario relativo al sistema (attuale) per l'emissione di biglietti
ferroviari.
•
Visonary scenario: la definizione proviene dal cliente164, poichè è utilizzato per descrivere le
prospettive future di un sistema già esistente. Infatti, di solito vienedescritto nel greenfield
engineering o nel reengineering.
Un esempio potrebbe essere lo scenario relativo al (nuovo) sistema per l'emissione di biglietti
ferroviari.
•
Evaluation scenario: descrive i compiti che gli utenti dovrebbero svolgere utilizzando il
sistema, poichè è proprio sulla base di questi che verrà valutato il sistema.
Un esempio potrebbe essere lo scenario emettere un biglietto, oppure prenotare un treno.
•
Training scenario: descrivono passo dopo passo, come un utente possa interagire con il
sistema. In effetti, rappresentano un tutorial per introdurre nuovi utenti al sistema.
Un esempio potrebbe essere lo scenario che descrive come prenotare un treno.
Suggerimenti per la scrittura dei casi d'uso
1) I nomi dei casi d’uso dovrebbero includere verbi;
2) I nomi di Attori dovrebbe essere sostantivi;
3) I confini del sistema dovrebbero essere chiari: chiara distinzione delle azioni svolte
dall’attore e delle azioni svolte dal sistema;
4) Le relazioni causali tra passi successivi dovrebbero essere chiari;
5) Un caso d’uso dovrebbe descrivere una transazione utente completa;
6) Le eccezioni dovrebbero essere descritte separatamente;
7) Un caso d’uso non dovrebbe descrivere un interfaccia del sistema (meglio usare prototipi
mock-up);
8) Un caso d’uso non dovrebbe superare due o tre pagine
164I Visionary scenario spesso non possono essere definiti dagli utenti e dagli sviluppatori.
153
Misure di qualità per la valutazione della specifia dei requisiti
software (Standard IEEE 830)
•
correttezza: il requisito descrive ciò che ha richiesto il committente;
•
non ambiguità: il requisito si presta ad una sola interpretazione;
•
completezza (misura relativa ad un insieme di requisiti): l'insieme dei requisiti è completo,
dunque, descrive tutti le richieste del committente165;
•
consistenza: ciascun requisito non deve essere in conflitto con altri;
•
classificazione: ciascun requisito deve essere classificato in base all'importanza che ha per il
committente166 ed in base al livello di stabilità;
•
verificabilità: possibilità di verificare la corrispondenza del prodotto con il requisito;
•
modificabilità: possibilità di operare modifiche su di un requisito in modo semplice e
coerente, senza impattare eccessivamente gli altri requisiri;
•
tracciabilità: l'origine di ogni requisito dovrà essere chiara, inoltre, dovrà essere possibile
definire una corrispondenza tra il requisito in esame e gli altri requisiti, nonchè con i prodotti
dello sviluppo.
I dodici principi del software agile
Elnchiamo di seguito i principi del Manifesto Agile [30]:
1.
"Welcome changing requirements, even late in development. Agile processes harness change
for the customer's competitive advantage"
Bisogna concentrare l'attenzione sulla qualità del software, intesa come capacità di soddisfare le
aspettative del cliente, così da renderlo parte integrante del processo di sviluppo.
2. "Welcome changing requirements, even late in development. Agile processes harness change
for the customer's competitive advantage"
Il progetto ed il codice sono impostati per ottenere un buon grado di adattabilità alle modifiche,
piuttosto che rispecchiare la pianificazione del soddisfacimento di tutte le specifiche.
165Le richiste dell'utente riguardano funzionalità, performance, vincoli di progetto, i dati, le interfacce, ecc.
166La classificazione di un requisito in base all'importanza pone l'accento sul livello di soddisfazione del cliente in
relazione alla sua implementazione.
154
3. "Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale"
Il processo di sviluppo deve avere una natura incrementale ed iterativa, con un tempo basso di
iterazione. Inoltre, il deliverable principale di ciascuna iterazione deve essere un programma
funzionante, col quale l'utente potrà interagire. Le fasi del processo sono eseguite in tempi molto più
brevi rispetto alle metodologie tradizionali; infatti, ci si concentrerà sulla risoluzione di pochi
problemi, piccoli e ben definiti.
Il team di sviluppo è in grado di produrre versioni del software in tempi ridotti, quindi i rilasci
saranno più frequenti.
4. "Business people and developers must work together daily throughout the project"
Non bisogna dividere in compartimenti stagni il lavoro del team di sviluppo e quello di chi gestisce
altri aspetti del progetto, come il project management o la parte commerciale.
5. "Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done"
Il compito di un manager è quello di arginare, o rimuovere, le cause che possano ostacolare lo
svolgimento del lavoro. In pratica, egli deve ricoprire il ruolo di "facilitatore" che guida con
autorevolezza il team.
6. "The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation"
È necessario rimuovere le barriere che possano ostacolare la comunicazione tra i membri del team
di sviluppo.
7.
"Working software is the primary measure of progress"
A differenza dei metodi tradizionali, i cui artefatti documentali rivestono un ruolo molto
significativo nella misura dell'avanzamento del progetto, quello agile conferisce alla
documentazione un valore che deriva dalla sua utilità alla comprensione del software.
8. "Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely"
Non bisogna sovraccaricare il lavoro di ciascun componente del team, infatti ciò, a lungo
155
termine, pregiudica non solo la qualità del prodotto, ma anche il livello di produttività di ciascun
individuo.
9. "Continuous attention to technical excellence and good design enhances agility"
Di fondamentale importanza è il modo in cui viene progettato il software, che deve consentire di
apportare modifiche facilmente.
10. "Simplicity--the art of maximizing the amount of work not done--is essential"
La semplicità della progettazione è una delle caratteristiche alle quali viene data più importanza.
11. "The best architectures, requirements, and designs emerge from self-organizing teams"
L'organizzazione del team deve essere informale e flessibile, piuttosto che organizzata in una rigida
gerarchia. Il successo conseguibile è basato sull'idea di sfruttare al meglio le abilità, le competenze
specifiche di ogni suo membro. In quest'ottica, il singolo non è facilmente intercambiabile, bensì è
parte imprescindibile dall'insieme.
12. "At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly".
È dalla reale esperienza del team che nascono le proposte di miglioramenti, aggiornamenti e
modifiche al processo di sviluppo.
SIL – Safety Integrity Level
Il concetto di Livello di Integrità della Sicurezza (Safety Integrity Level) nasce in ambito industriale
dalla necessità di migliorare l'affidabilità, la tolleranza ai guasti e la standardizzazione delle
performance dei sistemi di sicurezza.
Il raggiungimento di tali obiettivi richiede l'adozione di opportune misure di protezione per:
•
Eliminare o ridurre ad un livello accettabile la probabilità di un evento pericoloso;
•
Ridurre le conseguenze dell'evento, in termini di danni a persone, ambientali ed economici.
Sulla scorta di queste considerazioni nasce la norma EN IEC 61508 del 1999 "Sicurezza funzionale
dei sistemi elettrici, elettronici ed elettronici programmabili per applicazioni di sicurezza", recepita
in Italia come CEI EN 61508, nasce la norma di sicurezza IEC 61508 la quale fornisce un approccio
sistematico e metodico per analizzare i rischi 167 associati al processo, allo scopo di realizzare una
strategia di riduzione del rischio.
167 I rischi associati al processo intermini di conseguenze e probabilità.
156
Lo standard IEC 61508 introduce il metodo SIL ed è suddiviso in sette sezioni:
1) Parte 1: Requisiti Generali
2) Parte 2: Requisiti per Dispositivi Elettrici, Elettronici, Elettronici Programmabili
3) Parte 3: Requisiti Software
4) Parte 4: Definizoni ed Abbreviazioni
5) Parte 5: Esempi di metodi per la determinazione dei livelli di integrità di sicurezza
6) Parte 6: Linee guida per lìapplicazione delle sezioni 2 e 3
7) Parte 7: Panoramica sulle tecniche e misure
Esso interessa in particolar modo i produttori e fornitori dei componenti dei sistemi di sicurezza
strumentale(SIS).
Al concetto di SIS è legato quello di Funzione di Sicurezza Strumentale (SIF – Safety Instrumented
Function), cioè la funzione di sicurezza (di protezione o di controllo) attuata da un SIS. Per ciascuna
SIF è calcolata la probabilità di mancata o errata risposta – su domanda di intervento – in particolari
condizioni, entro un tempo prestabilito.
Si noti che il SIL è ralativo all singola funzione di sicurezza non all'intero impianto o ai singoli
componenti che lo costituiscono.
La norma EN IEC 61508 definisce quattro livelli ai quali è associato un margine di sicurezza via via
crescente: SIL1, SIL2, SIL3, SIL4.
Tabella 6: Livelli di SIL nella norma EN IEC 61508
SIL
Probabilità media di fallimento
su domanda
per anno (bassa domanda)168
SIL4
≥ 10-5 e <10-4
SIL3
≥ 10-4 e <10-3
SIL2
≥ 10-3 e <10-2
SIL1
≥ 10-2 e <10-1
Strumenti di supporto alla progettazione in AnsaldoBreda
Issue Tracker utilizzato per gestire le attività relative ai progetti sviluppati in
AnsaldoBreda, assegnare task a singoli di un team di progetto, tracciare le
anomalie, qualora riscontrate, sino alla risoluzione.
168 Indica la probabilità di non riuscire ad eseguire la funzione di protezione richiesta.
157
Piattaforma non strutturata che consente la costruzione, con il contributo degli
utenti, una repository dinamica della conoscenza aziendala. Viene adoperata
per oganizzare la documentazione dei progetti sviluppati in AnsaldoBreda in
pagine accessibili per mezzo di un browswr http. Lo scopo dell'utilizzo dello strumento è la
condivisione delle informazioni tra i componenti del team di progetto.
Sistema di controllo versione169, adoperato in AndaldoBreda per gestire le
configurazioni del software e la configurazioni dei documenti ad esso relativi.
Sistema opensource per praticare la continuous integration. Viene adoperato
in AnsaldoBreda per la creazione degli eseguibili e delle directory di
installazione degli applicativi automatica su di un server di rete e per la creazione automatica dei
report relativo alle modifiche apportate al codice tra due release consecutive.
Tool di gestione dei test, viene adoperato in AnsaldoBreda per: progettare ed
eseguire test cases, automatici e manuali; generare automaticamente report
dii test; per creare lo storico delle prove eseguite e misurare la test coverage170.
Norme adottate in AnsaldoBreda
CEI EN 50126
Il riferimento principale in tema di valutazione della sicurezza in campo ferroviario è dato dalla Norma
Europea EN 50126 – Applicazioni ferroviarie - Specificazione e Dimostrazione di Affidabilità,
Disponibilità, Manutenibilità e Sicurezza (RAMS) con particolare considerazione ai concetti di
Categorie Qualitative di Rischio e di Matrice dei Rischi (combinazione delle valutazioni su
frequenza e conseguenze connesse con i diversi rischi) [39].
CEI EN 50128
Normativa che specifica le procedure ed i requisiti tecnici per lo sviluppo del software in
applicazioni ferroviarie
169 Il controllo versione è la gestione di versioni multiple di un insieme di informazioni
170 La test coverage indica la parte di codice coperta da test.
158
CEI EN 50129
Normativa che specifica le procedure ed i requisiti tecnici per lo sviluppo di sistemi elettronici per il
segnalamento ferroviario.
Le normative CEI EN 50128 e 50129 forniscono dettagli rispetto ai criteri da applicare ai processi
di:
•
Formazione del presonale;
•
Gestione della sicurezza;
•
Gestione della qualità;
•
Specifica dei requisiti di sistema;
•
Definizione dell'architettura di sistema;
•
Definizione delle caratteristiche progettuali;
•
Progettazione;
•
Valutazione degli effetti dei guasti;
•
Verifica e validazione.
159
Bibliografia
[1] Alan Mark Davis, A. M. Davis, 1993, Software Requirements: Objects, Functions and States,
Prentice Hall
[2] FURPS http://www.federica.unina.it/smfn/ingegneria-del-software-smfn/ingegneria-requisiti/13/
[3] Ian Sommerville, I. Sommerville, 2007, Software Engineering 8th edition, Addison Wesley
[4] Ian Sommerville, I. Sommerville, 2001, Software Engineering, 6th edition, Addison Wesley
[5] N. E. Fenton and S. L. Pfleeger, 1997,Software Metrics, a rigorous approach, second edition,
PWS publishing company, 1997.
[6] ISO 9000 http://it.wikipedia.org/wiki/Norme_della_serie_ISO_9000
[7] P. Zave, 1997, "Classification of Research Efforts in Requirements Engineering", ACM
Computing Surveys 29
[9] ISO/IEC 9126 Software engineering – Product quality
[10] A.Davis, The Art of Requirements Triage, IEEE Computer 36
[11] A. van Lamsweerde, 2000, "Requirements Engineering in the Year 00: A Research Perspective"
in Proceedings of the International Conference of Software Engineering ICSE’00, Limerick
[12] E.Hull, K.Jackson, J Dick, 2011, Requirements Engineering, Springer
[13] J.C.S.P, Leite,1996, "Viewpoints on Viewpoints", in ACM Joint Proceedings of the
SIGSOFT'96 Workshops
[14] Viewpoints http://home.dei.polimi.it/ghezzi/_PRIVATE/Colazzo_i-star_final.pdf
[15] M. Carrol, 1995, Scenario-based Design, Wiley
[16] Jacobson, "Object- Oriented software Engineering. A Use Case Driven Approach"
[17] Chirone, Tornincasa, Disegno Tecnico Industriale, Edizione il Capitello
[18] N.D'Addea, G.Perotti, 2005, Manuale di manutenzione industriale, Tecniche Nuove
[19] Roger S. Pressman, 2008, Ingegneria del software, McGraw Hill
[20] Martin Fowler , The New Methodology,
http://www.martinfowler.com/articles/newMethodology.htm
[21]Kent Beck, 2000, EXtreme Programming Explained: Embrace Change, Addison Wesley
Longman Publishing Co.
[22] Kent Beck, 1999, Extreme Programming Explained
[23] J. Stapleton, 1997, DSDM Dynamic systems development method, Harlow, England: AddisonWesley
[24] K.Schwaber, M. Beedle, 2002, Agile Software Development with SCRUM, Prentice Hall
[25] Palmer, J. Felsing, 2002, A Pratical Guide to Feature-Driven Development
160
[26] Cockburn, 2001, Agile Software Development
[27] Highsmith, 2000, Adaptative Software Development: A Collaborative Approach to Managing
Complex System, Dorse House Publishing
[28] Ambler, 2002, Agile Modeling
[29] Agile Alliance http://agilealliance.org
[30] Manifesto del movimento Agile http://agilemanifesto.org/
[31] M. Fowler, 1999, Refactoring : Improving the Design of Existing Code, Addison-Wesley
[32] C. G. Cobb, 2011, Making Sense of Agile Management, Balancing Control and Agility, John
Wiley & Sons Ltd.
[33] Lean Software Development http://it.wikipedia.org/wiki/Lean_software_development
[34] D. Turk, R. France and B. Rumpe, 2002," Limitations of agile software processes", Proceedings
of 3rd International Conference on eXtreme Programming and Agile Processes in Software
Engineering, May 2002, ACM, USA, pp:1-4,
[35] M. Fowler, K. Beck, J. Brant, W. Opdyke, D. Roberts, Fowler et al., 1999, Refactoring:
Improving the Design of Existing Code, Addison Wesley
[36] AnsaldoSTS
http://www.ansaldosts.com/AnsaldoSTS/IT/Business/MassTransit/CBTC_based/args/detail/details~
projects~project_detail_0000048.shtml/type/web_project/index.sdo
[37] Linee guida per la scrittura dei requisiti
http://www.tecnetdati.com/azienda/risorse/tutorial/gestione-dei-requisiti.html#linguida
[38] RB/EUROCAE ED-12B Software Considerations in Airborne Systems and Equipment
Certification http://www.turma-aguia.com/davi/avionics/TheAvionicsHandbook_Cap_27.pdf
[39] Osservazioni sulla normativa EN 50126 http://www.mit.gov.it/mit/mop_all.php?p_id=05324
161
162