Slide 1 Lezione 2. Il modello Waterfall e le sue fasi [GJM91, Sez. 7.1], [S2001, Cap. 3], [TMcG93, Cap. 2 (#) fotocopia] Modello code-and-fix Processo di sviluppo: specifica, progetto e codifica, validazione, evoluzione Le fasi del modello Waterfall. Fattibilità, requisiti, specifica, progetto, codifica, testing unitario, integrazione e test di sistema, verifica e validazione, manutenzione, evoluzione Waterfall, variante STARTS (#) Waterfall, variante ESA (#)

Slide 2 Il modello di sviluppo Code-and-fix Prima: Problemi di complessita relativamente bassa Programmatore unico Programmatore = utente finale, di formazione scientifica ==> Modello a due fasi CODE-AND-FIX Problemi: il codice diventa rapidamente illeggibile. Poi: Problemi di alta complessita (p. es. business administr.) Team di programmatori (problemi di comunicazione) Utenti finali inesperti (problemi di comunicazione) ==> nuovo approccio: il processo

Slide 3 Quattro attività fondamentali del processo software Vengono riconosciute quattro attività: Specification Design and implementation (coding) Validation Evolution Il processo di sviluppo deve essere modellato esplicitamente, per poter essere gestito e monitorato

Slide 4 Waterfall model Appare in letteratura negli anni 50 in rif. a sistema difensivo SAGE - Semi-Automated Ground Environment. Larga diffusione a partire dagli anni 70.

Slide 5 Modello Waterfall [S2001]

Slide 6 Modello Waterfall [GJM91] Requirements analysis and specification Design and specification Coding and module testing Integration and sytem testing Delivery Feasibility study Maintenance

Slide 7 Modello Waterfall [AC96]

Slide 8 Requirements engineering process (specification) User requirements = requirements definition in Sommerville 5th edition System requirements = requirements specification in Sommerville 5th edition Software specification = Requirements Engineering [S2001, p. 55] * * Consistenti Completi Realistici

Slide 9 Feasibility study Valuta i costi e i benefici della applicazione proposta. Contiene almeno: Definizione del problema Soluzioni alternative e relativi vantaggi Risorse richieste, costi, tempi per ciascuna alternativa Si conclude con una offerta al Cliente Il cliente potrebbe ritirarsi, dunque lo studio e spesso affrettato...

Slide 10 Requirements (elicitation, analysis, specification, validation) Identifica le qualita richieste per lapplicazione funzionalita, performance, facilita duso, portabilita… I requisiti esprimono il COSA ma non il COME. non devono vincolare la architettura e gli algoritmi ===> liberta di implementazione Requisiti funzionali Descrivono cosa fa il sistema, con notazioni formali, informali, o miste. Requisiti non-funzionali Su reliability, safety, performance, man-machine interface, portability, operating requirements. Requisiti sul processo di sviluppo e manutenzione Sulle procedure di controllo di qualita e di testing

Slide 11 Requirements document Il requirements document e una interfaccia fra cliente e sviluppatore Comprensibile, precisa, completa, consistente, non-ambigua Puo offrire anche Manuale duso e Piano di test. Descrizione del sistema sotto piu punti di vista, ma allo stesso livello (alto) di astrazione. Esempio: Modello dei dati (diagrammi ER) Modello delle funzioni (diagrammi data-flow) Strutture di controllo (Reti di Petri)

Slide 12 Design Definisce larchitettura del sistema, mediante decomposizione in moduli. Il design (specification) document descrive le relazioni fra moduli, e cosa fa ciascuno, non come la fa, sebbene... …la decomposizione puo essere iterata (vertical modularity) su piu livelli di astrazione. Design e implementazione (codifica) sono correlati, e vengono spesso eseguiti in ciclo.

Slide 13 Diversi modi di intendere high-level/low-level design

Slide 14 Formati e notazioni per il design specification document Companywide standards Spesso vengono adottati standard internazionali (ISO, CCITT, OMG) Esempi LOTOS (Language of Temporal Ordering Specification) ESTELLE (Ext. State Transition Language) SDL (Specification and Description Language) UML (Unified Modelling Language)

Slide 15 The software design process [S2001] (Software Architecture) High Level (Software Design) Low Level Ripartizione in sottosistemi Identif. dei servizi offerti da ogni sottosistema

Slide 16 Design methods Systematic approaches to developing a software design The design is usually documented as a set of graphical models Possible models Data-flow model Entity-relation-attribute model Object models

Slide 17 Coding (programming) e unit+module testing (debugging) Produce e testa le implementazioni dei moduli del Design Corrisponde al vecchio code-and-fix, o Programming-in-the-small: attività creativa personale (non cè processo) Company standards per: Convenzioni su nomi di variabili nei programmi Convenzioni sui commenti Vincoli su numero di linee di codice per modulo.

Slide 18 Testing Unit testing Individual components are tested Module testing Related collections of dependent components are tested Sub-system testing Modules are integrated into sub-systems and tested. The focus here should be on interface testing System testing Testing of the system as a whole. Testing of emergent properties Acceptance testing = -testing Testing with customer data to check that it is acceptable

Slide 19 Testing phases Le componenti possono venire aggiunte e testate incrementalmente. -testing: esposizione del sistema (specifico) al cliente, che è paziente. Può rivelare problemi di performance

Slide 20 Verifica & validazione Verifica: il software è corretto, cioè conforme alla specifica (system testing) Validazione: si è costruito il sistema giusto, che soddisfa le aspettative del cliente (acceptance testing) La verifica puo riguardare tutti i passi del processo di sviluppo, ed essere formale.

Slide 21 Delivery and maintenance -testing: distribuzione del sistema (generico) limitata a pochi utenti finali, poi Distribuzione illimitata. Manutenzione (60% dei costi di sviluppo) Correttiva - rimuovere errori (20%) Adattiva - adattare lapplicazione a cambi nellambiente in cui il sistema gira (20%) Perfettiva - migliorare, cambiare, aggiungere qualita o funzioni (60%)

Slide 22 Costi di manutenzione [Lientz, Swanson 80] Costi di manutenzione - survey su 400 software house: 42%cambiamenti negli user requirements 17%cambiamenti nel formato dei dati 12%emergency fixes 9%routine debugging 6%cambiamenti di hardware 5%modifiche nella documentazione 4%miglioramento della efficienza ==> puntare a requirements piu affidabili

Slide 23 Waterfall model documents [S95]

Slide 24 Waterfall, variante STARTS (87) Software Technology for Application to large Real-Time Systems - National Computing Centre, Manchester, UK Waterfall esteso: ogni attività si estende a tutte le fasi Fonti: The STARTS Guide, 2nd edition, Vol. 1, In [TMcG93]

Slide 25 Una cascata … a V

Slide 26 Attività per fase

Slide 27...

Slide 28 ESA - Software Lifecycle Model (*) UR phase: User Requirements definition SR phase: Software Requirements definition con stima dei costi al 30% di accuratezza AD phase: Architectural Design con stima dei costi al 10% di accuratezza DD phase: Detailed Design and production (code) TR phase: Transfer OM phase: Operations and Maintenance (*) ESA (European Space Agency) Software Engineering Standards, ESA-PSS- 05-0, Issue 2, Feb In [TMcG93]

Slide 29

Slide 30 ESA - Waterfall approach * Waterfall approach e la più ovvia interpretazione di ESA Soft. Lifecycle Model Le frecce inverse (tratteggiate) rappresentano possibili cicli di correzione (waterfall?) Gli altri due approcci ESA sono: - Incremental delivery - Evolutionary development

Slide 31 Software evolution Il Software is intrinsecamente flessibile, e puo cambiare, per adeguarsi a nuovi requisiti derivanti da nuove situazioni legali, economiche... Sempre piu spesso lo sviluppo di nuovi sistemi non parte da zero, ma si configura come evoluzione e/o assemblaggio di sistemi sviluppati in precedenza. COTS = Components Off The Shelf (o Commmercial…)

Slide 32 Modello Waterfall - problemi e applicabilità Rigida partizione del progetto in fasi difficile e costoso accogliere nuovi requisiti tardivamente Applicabile quando i requisiti sono ben comprensibili, e stabili