Lezione 2 Il modello Waterfall e le sue

Lezione 2. Il modello Waterfall e le sue fasi • [GJM 91, Sez. 7. 1], [S 2001, Cap. 3], [TMc. G 93, 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 1

Il ‘modello’ di sviluppo Code-and-fix Prima: • • • ==> Modello a due fasi ‘CODE-AND-FIX’ • Problemi: il codice diventa rapidamente illeggibile. Poi: • • • Problemi di complessita’ relativamente bassa Programmatore unico Programmatore = utente finale, di formazione scientifica 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 2

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 3

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 4

Modello Waterfall [S 2001] Slide 5

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

Modello Waterfall [AC 96] Slide 7

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

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 9

Requirements (elicitation, analysis, specification, validation) Identifica le qualita’ richieste per l’applicazione • I requisiti esprimono il COSA ma non il COME. • Descrivono cosa fa il sistema, con notazioni formali, informali, o miste. Requisiti non-funzionali • non devono vincolare la architettura e gli algoritmi ===> liberta’ di implementazione Requisiti funzionali • funzionalita’, performance, facilita’ d’uso, portabilita’… 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 10

Requirements document Il requirements document e’ una interfaccia fra cliente e sviluppatore • • Comprensibile, precisa, completa, consistente, non-ambigua Puo’ offrire anche Manuale d’uso 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 11

Design Definisce l’architettura 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 12

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

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 14

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

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 16

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 17

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

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

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 20

Delivery and maintenance b-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 l’applicazione a cambi nell’ambiente in cui il sistema ‘gira’ (20%) Perfettiva - migliorare, cambiare, aggiungere qualita’ o funzioni (60%) Slide 21

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

Waterfall model documents [S 95] Slide 23

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, 2 nd edition, Vol. 1, 1987. In [TMc. G 93] Slide 24

Una cascata … a ‘V’ Slide 25

Attività per fase Slide 26

. . . Slide 27

ESA - Software Lifecycle Model (*) UR phase: User Requirements definition SR phase: Software Requirements definition • AD phase: Architectural Design • con stima dei costi al 30% di accuratezza 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. 91 - In [TMc. G 93] Slide 28

Slide 29

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 30

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 31

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 Slide 32