Corso di Ingegneria del Software. Modelli di produzione del software

Transcript

1 Corso di Ingegneria del Software a.a. 2009/2010 Mario Vacca

2 1. Concetti di base Sommario Modello a cascata 2.2 Modelli incrementali 2.3 Modelli evolutivi 2.4 Modelli agili 3. Comparazione dei modelli 4. Bibliografia

3 1. Concetti di base Sommario Modello a cascata 2.2 Modelli incrementali 2.3 Modelli evolutivi 2.4 Modelli agili 3. Comparazione dei modelli 4. Bibliografia

4 Generalità Lo studio del modello a cascata è importante perchè 1. è il modello più noto 2. l analisi delle varie fasi permette di descrivere delle attività che fanno parte di tutti i modelli di processo, anche se raggruppate e pianificate in modi diversi. (waterfall) prevede una successione di fasi consecutive. Ciascuna fase produce dei semilavorati (deliverable). I semilavorati sono documenti relativi al processo, oppure documentazione del prodotto e codice sorgente o compilato, che vengono ulteriormente elaborati dalle fasi successive.

5 Generalità Lo studio del modello a cascata è importante perchè 1. è il modello più noto 2. l analisi delle varie fasi permette di descrivere delle attività che fanno parte di tutti i modelli di processo, anche se raggruppate e pianificate in modi diversi. (waterfall) prevede una successione di fasi consecutive. Ciascuna fase produce dei semilavorati (deliverable). I semilavorati sono documenti relativi al processo, oppure documentazione del prodotto e codice sorgente o compilato, che vengono ulteriormente elaborati dalle fasi successive.

6 Generalità Lo studio del modello a cascata è importante perchè 1. è il modello più noto 2. l analisi delle varie fasi permette di descrivere delle attività che fanno parte di tutti i modelli di processo, anche se raggruppate e pianificate in modi diversi. (waterfall) prevede una successione di fasi consecutive. Ciascuna fase produce dei semilavorati (deliverable). I semilavorati sono documenti relativi al processo, oppure documentazione del prodotto e codice sorgente o compilato, che vengono ulteriormente elaborati dalle fasi successive.

7 Generalità Lo studio del modello a cascata è importante perchè 1. è il modello più noto 2. l analisi delle varie fasi permette di descrivere delle attività che fanno parte di tutti i modelli di processo, anche se raggruppate e pianificate in modi diversi. (waterfall) prevede una successione di fasi consecutive. Ciascuna fase produce dei semilavorati (deliverable). I semilavorati sono documenti relativi al processo, oppure documentazione del prodotto e codice sorgente o compilato, che vengono ulteriormente elaborati dalle fasi successive.

8 Caratteristiche - 1/3 Il software è sviluppato attraverso una successione lineare ordinata di fasi (stadi) di lavoro. Il numero, il contenuto e la denominazione delle fasi può variare da un organizzazione all altra, e da un progetto all altro. Specifica dei requisiti! Disegno sistema! Codifica! Testing! Messa in esercizio! Gestione e Manutenzione Ogni fase ha in input i semilavorati usciti dalla fase precedente e produce output che sono in ingresso alla fase successiva.

9 Caratteristiche - 1/3 Contemporaneamente a queste fasi, e nel corso di tutto il processo, si svolgono anche queste attività di supporto: gestione controllo di qualità documentazione

10 Caratteristiche - 2/3 Le fasi sono descritte in termini di: prodotti in ingresso alle attività e dai task che le compongono attività e compiti da svolgere prodotti in uscita dalle attività e dai task che le compongono responsabilità e ruoli riguardo le attività controlli da effettuare per validare input ed output dipendenze causali e temporali tra le attività documentazione da produrre

11 Caratteristiche - 3/3 Una fase inizia solo quando la precedente è stata completata; assenza feedback Le fasi partizionano il progetto: ogno fase serve ad uno scopo In ingresso ad ogni attività è un documento/prodotto proveniente dalla fase immediatamente precedente, che, una volta lavorato, è in input alla fase successiva.

12 Figura: (waterfall model)

13 Studio di fattibilità: caratteristiche Lo studio di fattibilità serve a stabilire se un dato prodotto può essere realizzato e se è conveniente realizzarlo. Lo studio di fattibilità deve accertare quali sono le possibili strategie per la sua realizzazione valutare la quantità di risorse necessarie stimare costi In base al risultato dello studio di fattibilità, il committente decide se firmare o no il contratto per la fornitura del software.

14 Studio di fattibilità: caratteristiche Il semilavorato prodotto dallo studio di fattibilità è un documento che dovrebbe contenere queste informazioni: o una descrizione del problema che deve essere risolto dall applicazione, in termini di obiettivi e vincoli; o un insieme di scenari possibili per la soluzione, sulla base di un analisi dello stato dell arte, cioè delle conoscenze e delle tecnologie disponibili; o le modalità di sviluppo per le alternative proposte, insieme a una stima dei costi e dei tempi richiesti.

15 Studio di fattibilità: problemi CASO 1 La rilevanza economica di questa fase può influenzare negativamente la qualità dello studio di fattibilità poichè il produttore di software, per non perdere il contratto, può sottovalutare i costi e le difficoltà della proposta, ovvero sopravvalutare le proprie capacità e risorse. Questi errori di valutazione rischiano poi di causare ritardi e inadempienze contrattuali, con perdite economiche per il fornitore o per il committente. CASO 2 A volte il committente paga lo studio di fattibilità, che in questo caso si può considerare un prodotto finito anche se il progetto iniziale cade. In questo caso lo studio di fattibilità è servito ad evitare il danno economico derivante dalla decisione di sviluppare un prodotto eccessivamente costoso o addirittura irrealizzabile.

16 Le fasi - Raccolta ed analisi dei requisiti Questa fase serve a capire e descrivere nel modo più completo e preciso possibile che cosa vuole il committente dal prodotto software.

17 Le fasi - Raccolta ed analisi dei requisiti La Raccolta ed analisi dei requisiti utente deve produrre una descrizione formale delle esigenze del cliente che il software deve soddisfare. La fonte principale dei requisiti sono i futuri utenti del software che deve essere sviluppato. Il metodo di raccolta principale sono le interviste o dei test svolti con l ausilio di prototipi. In questa fase deve essere definito un accordo (senza ambiguità) tra cliente e fornitore su cosa deve fare il software (funzionalità) sulle caratteristiche che dovrà avere su come il software dovrà essere utilizzato dall utente

18 Le fasi - Raccolta ed analisi dei requisiti La fase di analisi e specifica può essere suddivisa nelle sottofasi di definizione dei requisiti specifica dei requisiti specifica dei requisiti del software.

19 Le fasi - - Esempio 1/3 Definizione dei requisiti dell utente 1. L applicazione deve permettere la rappresentazione di file creati da altre applicazioni l elaborazione di file creati da altre applicazioni (detti file esterni)

20 Le fasi - Raccolta ed analisi dei requisiti - Esempio 2/3 Specifica dei requisiti dell utente 1.1 L applicazione deve permettere all utente di definire i tipi dei file da elaborare. 1.2 Ad ogni tipo di file corrisponde un programma ed una icona che viene usata per rappresentare il file. Se al tipo di un file non è associata alcuna icona, viene usata un icona default non associata ad alcun tipo. 1.3 L applicazione deve permettere all utente di definire l icona associata ai tipi di file esterni. 1.4 La selezione di un icona rappresentante un file esterno causa l elaborazione del file rappresentato, per mezzo del programma associato al tipo del file stesso.

21 Le fasi - Raccolta ed analisi dei requisiti - Esempio 3/3 Specifica dei requisiti del software L utente può definire i tipi dei file sia per mezzo di menù L utente può associare un programma esterno ad un tipo di file esterno sia per mezzo di finestre di dialogo L utente può associare un icona ad un tipo di file esterno per mezzo di una finestra di selezione grafica L applicazione deve comprendere una libreria di icone già pronte ed uno strumento grafico che permetta all utente di crearne di nuove La selezione di un icona rappresentante un file esterno può avvenire sia per mezzo del mouse che della tastiera.

22 Le fasi - Raccolta ed analisi dei requisiti Tipologia di requisiti da definire: Funzionali (ciò che il software deve fare, i servizi che eroga per ĺıutente). Descritti generalmente in termini di relazioni fra dati di ingresso e dati di uscita. Non funzionali (caratteristiche generali che dovrà avere il software, quali affidabilità, usabilità, prestazioni, portabilità in vari ambienti, ecc.). Tecnologici (le tecnologie da utilizzare per lo sviluppo, ad es, JAVA, UML, ecc ). Inversi (le operazioni che il software non deve compiere e che riguardano spesso la sicurezza).

23 Le fasi - Raccolta ed analisi dei requisiti Il prodotto tipico della fase di specifica dei requisiti è costituito dai seguenti documenti: Documento di Specifica dei Requisiti (DSR). È il fondamento di tutto il lavoro successivo, e, se il prodotto è sviluppato per un committente esterno, ha anche un valore legale poichè viene incluso nel contratto. Manuale Utente Descrive il comportamento del sistema dal punto di vista dell utente Piano di Test di Sistema Definisce come verranno eseguiti i test finali per convalidare il prodotto rispetto ai requisiti. Anche questo documento può avere valore legale, se firmato dal committente: il piano di test serve come piano di collaudo per l accettazione del sistema.

24 Le fasi - Raccolta ed analisi dei requisiti Il DSR della fase di specifica dei requisiti deve essere completo Deve contenere esplicitamente tutte le caratteristiche consistente Non deve contenere requisiti contraddittori. Può essere scritto usando un linguaggio formale, il linguaggio naturale o linguaggi semi-formali (naturali più diagrammi esplicativi, glossari ecc.).