Metodologie e strumenti dell'Ingegneria dei Requisiti ... - MobiLab

More documents

Recommendations

Info

è costituita da una sezione di elaborazione, di comunicazione e di memorizzazione. L'unità di elaborazione rende il sistema capace di elaborare i segnali provenienti dal mondo esterno; quella di comunicazione consente il trasferimento dei segnali (cioè l'informazione) da e verso il mondo esterno ed all'interno del sistema embedded stesso. L'unità di memoria fornisce al sistema la capacità di custodire nel tempo l'informazione. Naturalmente, per ogni applicazione realizzata da un sistema embedded dovranno essere soddisfatte specifiche esigenze per la capacità di elaborazione, comunicazione e memorizzazione. Si pensi ad una funzionalità ed a come essa possa essere ottimizzata in maniera differente a seconda dell'applicazione a cui è destinata. Dunque, ciò che rende un sistema embedded diverso rispetto ad altri è l'insieme dei requisiti operativi, che ne fanno un caso peculiare, per il quale è necessario definire una particolare metodologia di progetto. Oltre ad essi, un sistema embedded è vincolato anche da fattori di varia natura: vincoli non direttamente tecnologici, come il costo del prodotto ed il tempo di realizzazione. Ci si renderà facilmente conto di quanto un numero così elevato di vincoli e requisiti dipendano dalla necessità di adottare architetture miste hardware e software, al fine di trovare il miglior compromesso tra prestazioni, costo e tempo di sviluppo e, nel contempo, il ricorso a metodologie di progetto ben strutturate. Sappiamo che un normale elaboratore è realizzato con lo scopo principale di renderlo versatile, in maniera che possa adattarsi alla enorme varietà di ambiti applicativi cui è destinato. Tale caratteristica sarà ottenuta dotando le architetture hardware di risorse sovrabbondanti rispetto alle singole applicazioni, ma in linea con i vincoli di costo. Pertanto, i prodotti general purpose seguono standard e architetture di riferimento. Al contrario, ad un sistema dedicato a una specifica applicazione (oppure ad una classe specifica di applicazioni) non viene certamente richiesto il requisito di versatilità, poichè è una macchina dedicata allo svolgimento di una classe molto ristretta di compiti. Nonostante ciò, grazie alla specificità dell'applicazione cui è rivolto, il sistema embedded potrà essere progettato in modo da ottimizzare 78 determinati vincoli di costo e di prestazioni. Questa caratteristica rende arduo standardizzare l'architettura di un sistema dedicato, giacché, anche a parità di requisiti funzionali, i vincoli relativi alla specifica applicazione portano a scelte progettuali radicalmente diverse. Si noti, infatti, che vincoli temporali troppo stringenti alla realizzazione del sistema fanno sì 78 Approfondita la conoscenza sulla particolare applicazione, si potrà dimensionare la capacità di calcolo scegliendo il microprocessore ed, eventualmente, adoperando dispositivi hardware aggiuntivi per ridurre la potenza di elaborazione 63
che si protenda verso soluzioni prevalentemente software, così come limiti sulla dimensione e sui costi possono far protendere verso lo sviluppo di hardware dedicato. 3.1 Caratteristiche dei sistemi embedded Alcuni fattori sono determinanti per un sistema embedded e, per questo motivo, ne rappresentano i principali vincoli e requisiti in termini commerciali, di hardware e software: • Peso e dimensioni: caratteristica determinante, soprattutto per i dispositivi mobili, o che non verranno collocati in una postazione fissa; • Volume: i volumi di produzione previsti per il sistema rappresentano un fattore rilevante, che dovrà essere considerato in fase di progetto; • Costo: è un parametro fondamentale e di impatto per le scelte progettuali (strettamente connesso ai volumi di produzione); • Consumo energetico: questo problema dovrebbe essere affrontato in fase di progetto, in particolar modo per quei sistemi che vengono alimentati da batterie; • Dimensione del codice: per ragioni di costo e per ridurre l'area occupata, il software dei sistemi embedded risiede in un supporto di memoria permanente ed integrato sullo stesso chip del microprocessore. Questa caratteristica inciderà sulla dimensione del codice che, pertanto, dovrà essere quanto più contenuta possibile; • Prestazioni: nel caso dei sistemi embedded quest'obiettivo è strettamente dipendente dall'applicazione. Ma tipicamente, i vincoli che devono essere soddisfatti sono: - il tempo di reazione ad un evento; - il tempo di gestione dell'evento, eseguendo il codice ad esso associato. Questi vincoli prestazionali dovranno trovare riscontro in una soluzione architetturale, nella quale bisognerà bilanciare anche il costo, adoperando soluzioni miste hardware/software che renderanno più complesso il processo di progettazione e sviluppo; • Tempo reale: progettare il sistema in modo che esso possa operare entro parametri temporali ben definiti; • Affidabilità: sarà possibile quantificare l'affidabilità del sistema (eventualmente fissando una soglia minima) solo dopo aver effettuato un'attenta e scrupolosa analisi dei potenziali rischi; • Manutenibilità: probabilità che il sistema possa essere riparato o sostituito entro un certo intervallo di tempo; 64
Page 1 and 2:
Facoltà di Ingegneria Corso di Stu
Page 3 and 4:
Indice generale Metodologie e strum
Page 5 and 6:
5.6.4.1.5 Casi d'uso, scenari di in
Page 8 and 9:
Introduzione Nel corso degli ultimi
Page 10 and 11:
Ciò ha fatto nascere una nuova con
Page 12 and 13:
La situazione appena descritta non
Page 14 and 15: I requisiti non funzionali sono str
Page 16 and 17: minimizzare gli errori degli utenti
Page 18 and 19: di fiducia che può essere ragionev
Page 20 and 21: difficoltà nel capire il modo in c
Page 22 and 23: In effetti, essi dovrebbero descriv
Page 24 and 25: specifica dei requisiti. Oltre a qu
Page 26 and 27: descrizione delle funzionalità che
Page 28 and 29: 1.10 La qualità del software Per q
Page 30 and 31: Illustrazione 6: Modello di qualit
Page 32 and 33: Inoltre, l'adozione di strumenti a
Page 34 and 35: dalle parti interessate, cioè clie
Page 36 and 37: Prima di procedere ad una definizio
Page 38 and 39: software. In linea con questo appro
Page 40 and 41: descrizione di massima del sistema
Page 42 and 43: pervenire al glossario di dominio 5
Page 44 and 45: Può capitare, invece, che il lavor
Page 46 and 47: stakeholder (intervista aperta). Il
Page 48 and 49: percezione concreta delle interazio
Page 50 and 51: particolare funzionalità, che potr
Page 52 and 53: Ancora, nella redazione della sezio
Page 54 and 55: invalidando la presenza di alcuni r
Page 56 and 57: Un esempio potrebbe essere il colle
Page 58 and 59: fine di risolverle. Il modello di r
Page 60 and 61: Il primo passo da compiere in tal s
Page 62 and 63: sistema che tracci ciascuna propost
Page 66 and 67: • Disponibilità: probabilità ch
Page 68 and 69: • Requisiti temporali; • Requis
Page 70 and 71: definitiva, il costo del dispositiv
Page 72 and 73: componenti software, per ogni modul
Page 74 and 75: Illustrazione 24: Costo necessario
Page 76 and 77: • pianificazione; • analisi dei
Page 78 and 79: 3.4.3.1 Le fasi del modello a V 1)
Page 80 and 81: dello studio di fattibilità. Il pr
Page 82 and 83: presentano caratteristiche "preditt
Page 84 and 85: Tutte queste aderiscono ai principi
Page 86 and 87: È bene notare, che nel passaggio t
Page 88 and 89: Tabella 5: Luoghi comuni sugli appr
Page 90 and 91: Quanto detto, fa nascere l'idea che
Page 92 and 93: "sistema di trasporto rapido di mas
Page 94 and 95: Per mezzo di uno scambio di dati 12
Page 96 and 97: 5.2.1 Planning La pianificazione de
Page 98 and 99: 5.2.3 Architecture and Design Illus
Page 100 and 101: individuati; il codice viene genera
Page 102 and 103: 5.2.6 Module Testing Illustrazione
Page 104 and 105: 5.2.8 Release Illustrazione 42: Int
Page 106 and 107: 5.3 Analisi del processo di svilupp
Page 108 and 109: capitolato di gara, nel quale sono
Page 110 and 111: Il lavoro è stato condotto sul sis
Page 112 and 113: • la mancanca di una classificazi
Page 114 and 115:
- predisponendo l'estendibilità ed
Page 116 and 117:
• tracciare la/le relazione/i tra
Page 118 and 119:
5.6.4 La scrittura dei requisiti La
Page 120 and 121:
• Postcondizioni: condizioni che
Page 122 and 123:
L'insieme delle informazioni relati
Page 124 and 125:
Req_4: EB status detection, and inf
Page 126 and 127:
tracciare i collegamenti tra quest'
Page 128 and 129:
ciascun ingresso di una fase dovrà
Page 130 and 131:
The minimum threshold applied effor
Page 132 and 133:
LINK a REQ_BRAKE_61 Nome: Traction
Page 134 and 135:
TCU is not able to provide effort,
Page 136 and 137:
Precondizioni: Descrizione: The BCU
Page 138 and 139:
Descrizione:The BCU (dataset 5x2) s
Page 140 and 141:
Tipologia:Functional ID: SLR_TCMS_0
Page 142 and 143:
frase originaria: In this case of T
Page 144 and 145:
Postcondizioni: Tipologia:Functiona
Page 146 and 147:
5.7 IBM Rational DOORS: un tool per
Page 148 and 149:
Sezione contenente la documentazion
Page 150 and 151:
icavando la corrispondente matrice
Page 152 and 153:
Illustrazione 57: Esempio di tracci
Page 154 and 155:
Appendice Scenari Gli scenari si di
Page 156 and 157:
3. "Deliver working software freque
Page 158 and 159:
Lo standard IEC 61508 introduce il
Page 160 and 161:
CEI EN 50129 Normativa che specific
Page 162 and 163:
[26] Cockburn, 2001, Agile Software
show all

Metodologie e strumenti dell'Ingegneria dei Requisiti ... - MobiLab

Create successful ePaper yourself

Delete template?

Save as template?