Corso di Ingegneria del Software a.a. 2009/2010 Mario Vacca mario.vacca1@istruzione.it
Le fasi - Manutenzione e Gestione Figura: (waterfall model)
Le fasi - Manutenzione e Gestione Manutenzione del software: riparazione di difetti presenti nel prodotto consegnato al cliente l aggiornamento del codice (nuove versioni)
Le fasi - Manutenzione e Gestione Tipi di manutenzione: correttiva Individua e corregge errori. adattativa Gestisce i cambiamenti di ambiente operativo hardware e software (porting) e quelli di di leggi o procedure, linguistici e culturali (e.g. date). perfettiva Gestisce aggiunte e miglioramenti.
Le fasi - Manutenzione e Gestione Riparazione riprogettazione modificare e ricostruire il software rattoppo (patch) del codice sorgente. Problemi: il codice non corrisponde più al progetto; ilcodice si complica con incremento della difficoltà di correggere ulteriori errori; problemi di documentazione. Reengineering o reverse engineering
Le fasi - Manutenzione e Gestione In che modo il modello a cascata affronta il cambiamento? Progettare per il cambiamento (design for change) prevede che si debba tener conto fin dalle fasi iniziali che sarà necessario modificare il software prodotto.
Figura: I ruoli nel modello a cascata
Riepilogo Il modello è costituuito da fasi Le fasi sono costituite da attività Le attività sono realizzate da ruoli e producono semilavorati
Riepilogo Il modello presuppone che ciascuna fase sia conclusa prima dell inizio della fase successiva. Il flusso dei semilavorati è, pertanto, unidirezionale (e.g catena di montaggio): i risultati di una fase sono il punto di partenza della fase successiva, mentre non possono influenzare una fase precedente. QUINDI in ogni fase si opera sul prodotto nella sua interezza: la fase di analisi produce le specifiche di tutto il sistema quella di progetto produce il progetto di tutto il sistema. quella di codifica produce il codice complessivo.
Riepilogo Il modello presuppone che ciascuna fase sia conclusa prima dell inizio della fase successiva. Il flusso dei semilavorati è, pertanto, unidirezionale (e.g catena di montaggio): i risultati di una fase sono il punto di partenza della fase successiva, mentre non possono influenzare una fase precedente. QUINDI in ogni fase si opera sul prodotto nella sua interezza: la fase di analisi produce le specifiche di tutto il sistema quella di progetto produce il progetto di tutto il sistema. quella di codifica produce il codice complessivo.
Riepilogo Quindi questo modello è adatto a progetti in cui i requisiti iniziali sono chiari fin dall inizio e lo sviluppo del prodotto è prevedibile. Cosa accade in caso di imprevisti (e.g. scoperta di errori od omissioni nel progetto o nelle specifiche, oppure l introduzione di nuovi requisiti)? Bisogna ripetere le fasi precedenti e la rielaborazione dei semilavorati prodotti fino a quel punto oppure rattoppare (prassi non prevista dalla teoria).
Attività omblrello documentazione la maggior parte dei deliverable è costituita da documentazione. Documentazione usata internamente al processo di sviluppo: rapporti periodici sull avanzamento dei lavori, linee guida per gli sviluppatori, verbali delle riunioni. controllo di qualità gestione pianificazione del processo di sviluppo allocazione delle risorse umane l organizzazione dei flussi di informazione fra i gruppi di lavoro e al loro interno.
Conclusioni Figura: (waterfall model)
Vantaggi È concettualmente semplice; consente di dividere il problema in fasi distinte che possono essere compiute indipendentemente È facile pianificare le attività da svolgere, i prodotti intermedi da realizzare, le risorse da allocare sulle attività e le scadenze per le attività. È più facile il controllo in corso d opera del progetto, in quanto gli obiettivi di verifica e i momenti della verifica (le milestone) sono ben definiti. Diversi tools lo supportano (per produrre documentazione, per organizzare e distribuire il lavoro, per controllare gli stati di avanzamento delle attività). Esistono standard per definire contenuti e forme della documentazione da produrre durante il lavoro. Facile da amministrare in progetti basati su contratto.
Svantaggi 1/2 Assume che i requisiti possano essere specificati e congelati tutti all inizio è difficile per il cliente dichiarare subito tutti i requisiti in modo esplicito. ha difficoltà a gestire la naturale situazione di un progetto di sviluppo software per cui i requisiti si chiariscono veramente solo durante il lavori. Il cliente deve avere pazienza, una versione funzionante del sistema non potrà essere disponibile se non nelle ultime fasi del ciclo di vita (e scoprire un difetto solo alla fine può avere conseguenze disastrose, in termini di costo di correzione). L hardware e le altre tecnologie sono decise troppo presto Approccio big bang : delivery tutto o niente; troppo rischioso Orientato alla documentazione: richiede la produzione di documenti alla fine di ogni fase
Svantaggi 2/2 Il waterfall è un modello ideale, va approssimato nella pratica. Infatti: i progetti reali raramente seguono il flusso rigidamente sequenziale proposto dal modello, spesso è necessario iterare fasi e/o attività; il lavoro degli sviluppatori è quindi talvolta inutilmente ritardato dall attesa del completamento della fase precedente (se ci sono molti problemi, il tempo di attesa complessiva può superare il tempo di lavoro!). ogni fase ha propri modelli specifici di rappresentazione del prodotto che si sta sviluppando e ciò crea difficoltà di comunicazione tra le diverse fasi, rallentando le attività;
Le assunzioni I requisiti non hanno implicazioni ad alto rischio, dovute al costo, performance, sicurezza, impatto. La natura dei requisiti non cambierà molto, sia durante lo sviluppo che l evoluzione. I requisiti sono molto stabili e gli sviluppatori conoscono bene i problemi da risolvere. I requisiti sono compatibili con le aspettative di tutti, utenti, sviluppatori, mautentori, investitori, ecc. L architettura del sistema è nota (data per certa) C è abbastanza tempo per procedere sequenzialmente
Il modello a V I fondamenti If we rely on testing alone, defects created first are detected last Figura: Il modello a V
Il modello a V I fondamenti Il modello a V è una evoluzione del modello Waterfall In ogni fase è posto l accento sulle verifiche e validazioni da effettuare: ogni strato del modello produce degli output tipici, che devono essere sottoposti a una attenta verifica di qualità, al fine di poterli validare. Altro aspetto su cui viene posta l attenzione è la tracciabilità tra ciò che viene realizzato (ogni elemento del disegno tecnico del software) e requisiti utente. Assicura che non vengano realizzati componenti inutili a soddisfare le esigenze del cliente.
Il modello a V Le caratteristiche - Fase discendente 1. Specifica requisiti utente (raccolta ed analisi) Gli utenti devono rivedere attentamente il documento della specifica dei requisiti che deve servire come guida per i progettisti. Gli user acceptance tests sono progettati in questa fase. 2. Disegno del sistema Specifica delle funzionalità del software Vengono decise le possibilità di implementazioni. Viene prodotto lo user requirement document e il documento per il system testing. 3. Disegno dell architettura Il disegno dell integration testing è prodotto in questa fase. 4. Disegno dei moduli Il disegno dell unit test è fatto in questa fase. 5. Codifica del software
Il modello a V Le caratteristiche - Fase ascendente Unit Testing È realizzato dagli sviluppatori seguendo unit test e coinvolge il codice per verificarne correttezza, efficienza. Integration Testing Seguendo il documento di integration testing, i moduli sono testati insieme per verificare il funzionamento delle interfacce. System testing Serve a confrontare le specifiche del sistema con il sistema effettivamente realizzato. Testa l intero sistema. User Acceptance Testing Questa fase ha lo scopo di verificare se il sistema soddisfa i requisiti speicificati nella fase di analisi dei requisiti.
Bibliografia 1. Concetti di base Sommario 2. Modelli del ciclo vita del software 2.1 Modello a cascata 2.2 Modelli incrementali 2.3 Modelli evolutivi 2.4 Modelli agili 3. Comparazione dei modelli 4. Bibliografia
Bibliografia Bibliografia Riferimenti bibliografici - Generali 1. R. Pressman Ingegneria del software Mc Graw Hill Italia, 5a edizione, 2007, capitoli 3, par. 3.1 e 3.2. 2. P. Jalote A Concise Introduction to Software Engineering Springer, 2008, capitolo 2.
Bibliografia Bibliografia Riferimenti bibliografici - Specifici 1. W. Royce, Managing the Development of Large Software Systems, Proceedings of IEEE WESCON, p 1ñ9, 1970.