02-ModelloWaterfallEFasi

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 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 [S2001]
Requirements
definition
System and
software design
Implementation
and unit testing
Integr ation and
system testing
Operation and
maintenance
Slide 5
Modello Waterfall [GJM91]
Feasibility study
Requirements analysis and specification
Design and specification
Coding and module testing
Integration and sytem testing
Delivery
Maintenance
Slide 6
Modello Waterfall [AC96]
Slide 7
Requirements engineering process
Feasibility
study
Requirements
elicitation and
analysis
Consistenti
Completi
Realistici
Requir ements
specification
Feasibility
report
Requirements
validation
System
models
(specification)
* User and system
requirements
Requirements
document
requirements = ‘requirements definition’ in Sommerville 5th edition
* User
System requirements = ‘requirements specification’ in Sommerville 5th edition
Software specification = Requirements Engineering [S2001, 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
High level design
Low level design
Decomposi zion e logi ca
Decomposi zion e fisi ca in moduli
(programming units )
Relazioni fra moduli
Sint assi e semanti ca delle int erfacce fra
moduli
(USES, IS_COMPOSED_OF, INHERITS_FROM)
Relazioni fra moduli
Principali st ruttu re dati e algo ritmi di
ciascun modulo
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 [S2001]
Requirements
specification
Design activities
Architectural
design
Abstract
specification
Interface
design
Component
design
Data
structure
design
Algorithm
design
Sy stem
architecture
Software
specification
Interface
specification
Component
specification
Data
structure
specification
Algorithm
specification
Ripartizione
in sottosistemi
Identif. dei servizi
offerti da ogni sottosistema
(Software Architecture)
High Level
Design products
(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
•

Module 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
Requir ements
specification
System
specification
System
integration
test plan
Acceptance
test plan
Service
System
design
Acceptance
test
Detailed
design
Sub-system
integration
test plan
System
integration test
Module and
unit code
and tess
Sub-system
integration test
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 [S95]
Activity
Requirements analysis
Requirements definition
System specification
Architectural design
Interface des ign
Detailed des ign
Coding
Unit tes ting
Module tes ting
Integration tes ting
System tes ting
Acceptance testing
Output documents
Feas ibility study, Outline requirements
Requirements document
Functional s pecification, Acceptance tes t plan
Draft user manual
Architectural specification, System tes t plan
Interface specification, Integration tes t plan
Des ign specification, Unit tes t plan
Program code
Unit tes t report
Module tes t report
Integration tes t report, Final us er manual
System tes t report
Final system plus documentation
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, 2nd edition, Vol. 1, 1987. In [TMcG93]
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-PSS05-0, Issue 2, Feb. 91 - In [TMcG93]
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