slide 1 lezione 2. il modello waterfall e le sue fasi [gjm91, sez. 7.1], [s2001, cap. 3], [tmcg93,...
Post on 01-May-2015
215 Views
Preview:
TRANSCRIPT
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
top related