Definizione(i) di Ingegneria del Software (IEEE) Strategie sistematiche, a partire da richieste formulate del committente, per lo sviluppo, esercizio e.

Presentazione sul tema: "Definizione(i) di Ingegneria del Software (IEEE) Strategie sistematiche, a partire da richieste formulate del committente, per lo sviluppo, esercizio e."— Transcript della presentazione:

1 Definizione(i) di Ingegneria del Software (IEEE) Strategie sistematiche, a partire da richieste formulate del committente, per lo sviluppo, esercizio e manutenzione del software Studio di tali strategie Ridurre (annullare) i difetti nel software anche evitando le incomprensioni; Garantire la più lunga sopravvivenza del software una volta sviluppato; Mediare tra tempi, costi e risorse;

2 Problema generale Rispondere in modo adeguato ad una richiesta del committente (cliente) dettata generalmente dalle sue necessità (rispondenti a necessità organizzative ovvero analisi di mercato) Le richieste del committente possono essere: –Altamente rischiose con eventuale perdita di vite umane in caso di errori (tipo di software: safety-critical); –Debolmente rischiose con eventuale perdita di denaro in caso di errori (tipo di software: mission-critical e business- critical). Le richieste del committente possono essere: –Più o meno standard, cioè è noto cosa si deve fare e come; –Più o meno innovative, cioè è non noto cosa si deve fare o non è noto come farlo.

3 Domanda 1 Come si fa a sapere se quello che è richiesto si può fare, con quali tempi, costi risorse? Ovvero, “sono capace a farlo?”

4 Domanda 2 Come trattare il software pre-esistente (software legacy o COTS – Commercial On The Shelves)?

5 Domanda 3 Supponendo che si possa fare, cosa dovrebbe essere fatto esattamente (per rispondere cioè alla richiesta del committente), tenendo conto del rischio dovuto all’ambiente circostante e all’impatto degli eventuali errori (fallimenti) del software in funzione?

6 Domanda 4 Supponendo che si sappia cosa deve essere fatto, come dovrebbe essere fatto ed eventualmente quali potrebbero essere le alternative per farlo (meglio, se possibile ovvero se richiesto)? Una volta scelta l’alternativa, come si fa a realizzarlo?

7 Domanda 5 Una volta che è stato fatto, o che si è iniziato a farlo, come è possibile mantenerlo in funzione, il più a lungo possibile, ovvero continuare nello sviluppo, anche se –La richiesta del committente, da cui era stato costruito il software, si modifica? –Si scoprono eventuali errori concettuali nel software?

8 Domanda 6 Come è possibile migliorare rispetto alla capacità attuale di sviluppare del software?

9 Una distinzione preliminare Ciò che si deve sviluppare è, principalmente, il software (cioè ciò comunemente si chiama il codice) In realtà, per rispondere alle varie domande, si parla più correttamente di prodotto software in cui il codice è solo una parte Come per qualunque prodotto si distingue tra i requisiti del prodotto e il prodotto stesso

10 Alcune risposte D1 richiede ciò che si chiama anche uno studio di fattibilità il quale contiene una descrizione di massima di come s’intende procedere, quanto costa, quante risorse ci vogliono e in quali tempi D2 richiede la comprensione del software pre-esistente (in azienda o sul mercato) e delle possibilità di riuso (di un qualche tipo) D1 e D3 richiedono di capire, in funzione del rischio, quale sia il modo di procedere incluso quale il modello di processo da adottare D4 richiede la comprensione, sufficientemente profonda, di cosa deve essere fatto attraverso l’uso della specifica dei requisiti D4 richiede un modo sistematico di passare dalla specifica dei requisiti alla specifica del software e alla sua implementazione. D5 richiede un modo sistematico per riconoscere i legami tra il software realizzato ed i requisiti specificati D6 richiede tracciatura esplicita di come il software si è sviluppato nel passato e come si sviluppa nel presente, insieme ad elevate capacità di analisi storica e in presenza di modelli generali per la qualità del processo Modello del Processo (chiamato anche ciclo di vita)

11 Domanda preliminare Come fa il committente a sapere quale richiesta fare? L’Ingegneria del Software è talvolta vista in un ambito più ampio noto come Ingegneria dei Sistemi

12 Glossario della Ingegneria dei Software Una prima difficoltà è la indisponibilità parziale di un unico glossario di termini Lo SWEBOK (ovviamente in Inglese) rappresenta tale sforzo e verrà utilizzato lungo il corso (e, se necessario, facendo esplicite comparazioni con i termini usati nel testo di riferimento) Lo SWEBOK è anche un utile indice per tutti gli aspetti della ingegneria del software Lo SWEBOK è disponibile a: www.swebok.org

13 Aree della Ingegneria del Software che coprono le domande

14