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