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]Requirements

definition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance

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

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

(specification)

User requirements = ‘requirements definition’ in Sommerville 5th editionSystem requirements = ‘requirements specification’ in Sommerville 5th editionSoftware specification = Requirements Engineering [S2001, p. 55]

*

*

ConsistentiCompletiRealistici

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 l’applicazione• funzionalita’, performance, facilita’ d’uso, 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 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 12

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 13

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

High level design Low level design

Decomposizione logica Decomposizione fisica in moduli(programming units)

Relazioni fra moduli(USES, IS_COMPOSED_OF, INHERITS_FROM)

Sintassi e semantica delle interfacce fra

moduli

Relazioni fra moduli Principali strutture dati e algoritmi di

ciascun modulo

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]

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products

(Software Architecture)High Level

(Software Design)Low Level

Ripartizionein sottosistemi

Identif. dei serviziofferti 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

Requirementsspecification

Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand tess

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

ServiceAcceptance

testSystem

integration testSub-system

integration test

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 l’applicazione a cambi nell’ambiente 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]

Activity Output documentsRequirements analysis Feasibility study, Outline requirementsRequirements definition Requirements documentSystem specification Functional specification, Acceptance test plan

Draft user manualArchitectural design Architectural specification, System test planInterface design Interface specification, Integration test planDetailed design Design specification, Unit test planCoding Program codeUnit testing Unit test reportModule testing Module test reportIntegration testing Integration test report, Final user manualSystem testing System test reportAcceptance testing Final system plus documentation

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, 1987. 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. 91 - In [TMcG93]

Slide 29

Slide 30

ESA - Waterfall approach

* Waterfall approache’ la più ovvia interpretazione diESA 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