Lezione%202.%20Il%20modello%20Waterfall%20e%20le%20sue%20fasi

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 ()

2
Il modello di sviluppo Code-and-fix

• Prima
• Problemi di complessita relativamente bassa
• Programmatore unico
• Programmatore utente finale, di formazione
  scientifica
• gt 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)
• gt nuovo approccio il processo

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

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.

5
Modello Waterfall S2001
6
Modello Waterfall GJM91
Feasibility study
Requirements analysis and specification
Design and specification
Coding and module testing
Integration and sytem testing
Delivery
Maintenance
7
Modello Waterfall AC96
8
Requirements engineering process
Consistenti Completi Realistici

(specification)
User requirements requirements definition in
Sommerville 5th edition System requirements
requirements specification in Sommerville 5th
edition Software specification Requirements
Engineering S2001, p. 55

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...

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 gt 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

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)

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.

13
Diversi modi di intendere high-level/low-level
design
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)

15
The software design process S2001
Identif. dei servizi offerti da ogni sottosistema
Ripartizione in sottosistemi
(Software Design) Low Level
(Software Architecture) High Level
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

17
Coding (programming)e unitmodule 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.

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 a-testing
• Testing with customer data to check that it is
  acceptable

19
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.

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.

21
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 lapplicazione a cambi
  nellambiente in cui il sistema gira (20)
• Perfettiva - migliorare, cambiare, aggiungere
  qualita o funzioni (60)

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
• gt puntare a requirements piu affidabili

23
Waterfall model documents S95
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

25
Una cascata a V
26
Attività per fase
27
...
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

29

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
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)

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