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

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

1 (Una) Definizione 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, anche considerando i tempi, costi e risorse disponibili (in particolare il personale)? 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 in cui il software dovrà operare 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 anche considerando eventualmente quali potrebbero essere le alternative per farlo? 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 (anche 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 (i) codice (i) è (sono) solo una parte Come per qualunque prodotto si distingue tra i requisiti del prodotto e il prodotto

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 e quali risorse sono necessarie 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 comprendendo quale sia il modello di processo da adottare D3 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 D4 e D5 richiedono un modo sistematico per riconoscere/stabilire 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 talvolta ciclo di vita del software)

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 (che fornisce una visione precisa dell’impatto del Software nel Sistema in cui dovrà operare) Tuttavia, talvolta, l’Ingegneria dei Sistemi e l’Ingegneria del Software sono usate congiuntamente in modo da fornire al committente un Sistema (di cui solo parte è Software) che risponde correttamente ad una sua richiesta

12 Glossario della Ingegneria dei Software Una difficoltà sempre presente è 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