Upload
domenica-pisani
View
220
Download
0
Embed Size (px)
Citation preview
Slide 1
Lezione 3.Altri modelli di processo software
• [GJM91, Sez. 7.1], [S2001, Cap. 3, Sez. 19.4], [TMcG93, Cap. 2], [BRJ99, App. C (°)]
• Incremental delivery
• Modello evolutivo
• Modello formale-trasformazionale» Esempio: Cleanroom (anche incrementale)
• Reuse
• Extreme programming
• Modelli ibridi e metamodello a spirale
• Modello Unified (UML) (°)
• Visibilità nei vari modelli
• Supporto CASE
Slide 2
ESA - Incremental delivery approach (*)
(*) European Space Agency Software Engineering Standards, ESA PSS-05-0, N. 2, Feb. 91. In [TMcG93]
User RequirementsSoftware RequirementsArchitectural DesignDetailed Design and codingTRansfer to operationsOperations and Maintenance
- Assume UR e SR stabili, come Waterfall, ma- Affronta UR incrementalmente (priorità temporali)- Development team ridotto ==> sequenzializz. di deliverables- ‘Spalma’ il budget nel tempo
Slide 3
Incremental delivery [S2001]
Valida teincrement
Develop systemincrement
Design systemarchitecture
Integrateincrement
Valida tesystem
Define outline requirements
Assign requirements to increments
System incomplete
Finalsystem
- Consegna alcune funzionalità molto presto- ...e queste aiutano nella definizione di ulteriori requisiti- Diminuisce il rischio di fallimento completo del progetto- Le funzionalità prioritarie sono testate ripetutamente
Slide 4
ESA - Evolutionary development approach
Sequenza rapidadi cicli waterfall completi
Serve a chiarire e far evolvere i requisiti attraverso esperienza diretta su implementazioni intermedie
Slide 5
Evolutionary development [S2001]
ValidationFinal
version
DevelopmentIntermediate
versions
SpecificationInitial
version
Outlinedescription
Concurrentactivities
Slide 6
Slide 7
Due forme di evolutionary development
Exploratory prototyping • Forma ‘costruttiva’ - mira ad assistere il Cliente nel
raffinamento dei requisiti (chiari) iniziali.
• Si parte con i requisiti piu’ chiari…
Throw-away prototyping • Forma ‘distruttiva’ - serve allo sviluppatore per capire cosa il
Cliente NON vuole
• Si parte dai requisiti piu’ oscuri...
Slide 8
Evolutionary development - problemi e applicabilità
Problemi• La visibilità del processo è debole
• Non promuove buone architetture
• Puo’ richiedere personale specializzato (p.es. su linguaggi di prototipazione rapida).
Applicabilità• Sistemi interattivi piccoli (fino 100.000 linee) o medi (500.000)
• Parti (p. es. interfaccia utente) di sistemi complessi
• Short-lifetime systems
Slide 9
Trasformazione formale
R2Formalspecification R3 Executable
program
P2 P3 P4
T1 T2 T3 T4
Proofs of transformation correctness
Formal transformations
R1
P1
Slide 10
Esempi di metodi basati su trasf. formale
Cleanroom software development (H. Mills,IBM) LOTOS equivalence-preserving transformations
(Esprit LotoSphere Project) B Method (J.-R. Abrial -->Wordsworth ‘96)
Slide 11
Nome ‘cleanroom’ derivato da un processo di produzione di semiconduttori.
Mira e evitare gli errori a priori, anziché rimuoverli a posteriori
Si basa su:• Incremental development
• Formal specification by state-transition model
• ‘Rigorous’, semi-formal static verification using correctness arguments
• Statistical testing to determine program reliability.
Esempio: Cleanroom software development
Slide 12
The Cleanroom process
Constructstructuredprogram
Definesoftware
increments
Formallyverifycode
Integrateincrement
Formallyspecifysystem
Developoperational
profileDesign
statisticaltests
Testintegrated
system
Error rework
By correctness-preserving transformations
Functional requirements in‘box structure’ notation
System usages
Slide 13
Cleanroom process characteristics
Formal specification using a state transition model called box structure notation
Incremental development Structured programming - limited control and
abstraction constructs are used• for facilitating verification of consistency between steps
Static verification using rigorous inspections• in place of unit testing
Statistical testing of the system• after each increment integration
Slide 14
box structure notation ha tre livelli
Black box: funzione da sequenze di inputs -->outputs. Raffinata in
State box: una funzione di transizione (input, stato)--> (output, stato). Raffinata in
Clear box: una state box definita usando i costrutti di structured programming: assignment, sequence, if-then-else, while-do
Slide 15
Formal specification and inspections
The state based model is a system specification and the inspection process checks the program against this model• even though the use of correctness-preserving transformations
should in principle make inspections unnecessary...
Programming approach is defined so that the correspondence between the model and the system is clear
Mathematical arguments (not proofs) are used to increase confidence in the inspection process
Slide 16
Specification team. • Responsible for developing and maintaining the customer-
oriented and developer-oriented system specification
Development team. • Responsible for developing and verifying the software. The
software is NOT executed or even compiled during this process
Certification team. • Responsible for developing a set of statistical tests to exercise
the software after development. Reliability growth models used to determine when reliability is acceptable (MTTF: mean time to failure)
Cleanroom process teams
Slide 17
Results in IBM have been very impressive with few discovered faults in delivered systems
Independent assessment shows that the process is no more expensive than other approaches
Not clear how this approach can be transferred to an environment with less skilled or less highly motivated engineers
Cleanroom process evaluation
Slide 18
LOTOS equivalence-preserving transformation
Basato sulla specifica in LOTOS di struttura e comportamento del sistema,
Sequenza di (due, tre, quattro…) descrizioni sempre piu’ dettagliate del sistema, utilizzando diversi stili di specifica: Constraint-Oriented, Resource-Oriented, e State-Oriented, da cui è facilmente derivabile il codice.
Verifica formale di equivalenza osservazionale fra due descrizioni successive
(vedi lezioni su Verifica e Validazione)
Slide 19
B-method
B is a generic term given to a method of software development, the B-Method, its process and notation, and and its supporting toolset, the B-Toolkit. B derives from Z, and has similarities with Z and VDM. Axiomatic semantics based on Dijkstra’s weakest-precondition calculus.
The B-Method uses a simple `pseudo' programming language, AMN (The Abstract Machine Notation), to model requirements, interfaces, implementations and intermediate designs.
Step-wise development is used. A complete implementation (in C) is thus constructed from layers of specification/implementation pairs.
Specification/implementation pairs at the lowest levels are drawn from an extensive library of pre-implemented re-usable components.
Slide 20
Una abstract machine incapsula variabili di stato I valori delle variabili devono sempre soddisfare
l’invariante della macchina, espresso da un predicato Il comportamento della macchina è espresso da
• inizializzazione delle variabili
• lista di operazioni che possono accedere e modificare lo stato
Ogni specifica espressa come abstract machine viene validata mediante un insieme di proof obligations generabili automaticamente
• l’inizializzazione deve soddisfare l’invariante
• ogni operazione deve preservare l’invariante
Slide 21
inizializzazione e operazioni sono espresse mediante ‘sostituzioni generalizzate’,
simili a istruzioni di assegnamento ma dotate di semantica formale ben definita. Macchine astratte complesse sono ottenute componendo macchine piu’ semplici
attraverso relazioni di • include
• use
• see
• import
• extend
Tools commerciali di supporto:
• Atelier B, di Stéria Méditerranée, Aix-en-Provence, Francia » http://www.atelierb.societe.com
• B Tool, di B-Core Limited, Oxford, UK » http://www.b-core.com
Applicato con successo a sistemi di controllo ferroviario (Metro Parigi)
Slide 22
Trasformazione formale - problemi e applicabilità
Problemi• Non pratico per sistemi di dimensioni medio-grandi
• Richiede training, o personale già specializzato
• Non adatto alla specifica dell’interfaccia utente
Applicabilità• Sistemi critici con requisity di safety o security.
• Parti piccole o critiche di sistemi complessi
Slide 23
Reuse-oriented development
Il sistema è ottenuto per integrazione di componenti esistenti, eventualmente comperate da terze parti (COTS =Commercial-off-the-shelf)
Fasi• Component analysis• Requirements modification• System design with reuse• Development and integration
Tecnica recente, in forte crescita, poco consolidata e formalizzata
Slide 24
Nuovo approccio per team medio-piccoli che sviluppano sw dai requisiti vaghi o rapidamente mutevoli
Sviluppo e rilascio di incrementi molto piccoli di funzionalità Si basa su
• pair programming: codice scritto da due programmatori sulla stessa macchina
• collective ownership: chiunque nel team puo’ migliorare il codice in ogni parte, in ogni momento
• on-site customer: coinvolgimento full-time di un utente nel team di sviluppo
• testing: gli sviluppatori scrivono continuamente unit test, i cui fallimenti originano nuovo codice
• stories: la funzionalità del sistema è caratterizzata mediante brevi storie (simili a UML use-cases)
• ‘egoless’ programming: decisioni di management prese dal gruppo
Extreme programming
Slide 25
Modelli ibridi
Usare diversi modelli per diverse parti dello stesso sistema (complesso)• Evolutionary/Prototyping per parti con requisiti poco stabili o
oscuri
• Waterfall per parti con requisiti stabili e chiari
• Formal development per parti safety-critical
Slide 26
Il (meta-)modello ibrido a spirale [Boehm 88]
Riskanalysis
Riskanalysis
Riskanalysis
Riskanalysis Proto-
type 1
Prototype 2Prototype 3
Opera-tionalprotoype
Concept ofOperation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
design
CodeUnit test
IntegrationtestAcceptance
testService Develop, verifynext-level product
Evaluate alternativesidentify, resolve risks
Determine objectivesalternatives and
constraints
Plan next phase
Integrationand test plan
Developmentplan
Requirements planLife-cycle plan
REVIEW
Slide 27
I quattro settori della spirale
Stabilire gli obiettivi• Identifica obiettivi specifici per una fase (un giro)
Valutare e ridurre i rischi • I principali rischi sono identificati, analizzati, e viene raccolta
informazione su come minimizzarli
Sviluppo e validazione• Viene scelto un modello di sviluppo e validazione dei risultati
Pianificazione• Review del progetto e piani per il nuovo ‘giro’
Slide 28
Modello a Spirale - vantaggi e problemi
+ Attento al ri-uso + Attento alla eliminazione precoce di rischi
- Non applicabile quando il contratto prescrive un dato modello e identifica precisi deliverables
- Richiede esperti in valutazione dei rischi - E’ molto astratto, e va istanziato
Slide 29
Modello Rational Unified (UML)
Root causes of Software Development Problems• Insufficient requirements management
• Ambiguous and imprecise communications
• Fragile architectures
• Overwhelming complexity
• Undetected inconsistencies among requirements, designs and implementations
• Insufficient testing
• Subjective project status assessment
• Delayed risk reduction due to waterfall development
• Uncontrolled change propagation• Insufficient automation (source: RatiOnal)
Slide 30
‘Best practices’ in S.E. processes
123456
Slide 31
1. Develop iteratively (Phases and Workflows)
Slide 32
2. Manage requirements
Requirements can be related to many other project documents.
They can be prioritized, filtered, traced• Each iteraction handles a requirements subset
Requirements error detection by prototyping the user interface.
Requirements repository tool, with traceability information and links to external documents.
Slide 33
3. Use component architectures
Architecture is part of Design • but stops at the major abstractions (components), those that have
crucial effect on system quality, performance, evolvability.
Good architecture • ===> good team sizing and supervision• ===> good control over iterative, incremental system
development • ===> guidance in build vs. buy decision• ===> re-use and evolution
Slide 34
Evolvable architecture (bought, built, new)
Slide 35
4. Model software visually (with UML diagrams)
Slide 36
5. Verify quality - test incrementally
Slide 37
…using test tools
Slide 38
Visibilità nel processo di sviluppo
Il software è poco tangibile ma i manager richiedono documenti per poter controllare il progresso
Un modello ha alta visibilità quando prevede la produzione documentazione accurata delle varie fasi e dei risultati intermedi.
Ma:• Timing of progress deliverables may not match the time needed to
complete an activity
• The need to produce documents constraints process iteration
• The rime taken to review and approve documents is significant
Slide 39
Process Model Process Visibility
Waterfall Model Good; each activity produces some deliverable
Evolutionary development Poor: uneconomic to produce documents during rapid iteration
Spiral Model Good; each segment in each spiral loop must produce paper…
Formal transformations Good (but difficult to read…)
Reuse-oriented development Moderate; may be ‘artificial’ to produce documents about reused components
Slide 40
La scelta del modello dipende da
tipo di sistema e di utente finale rapporti fra Cliente e Sviluppatore politiche aziendali del Cliente o dello Sviluppatore Es. 1 - Sistema per utenti non esperti: va sviluppata documentazione
didattico-illustrativa, e mantenuta allineata agli altri artefatti.
Es. 2 - Lo studio di fattibilita’ cambia se la SW House sviluppa:
• Software specifico per cliente esterno, o
• Software specifico per altro ramo della stessa Compagnia, o
• Software generico da lanciare sul mercato.
Slide 41
Automated process support: CASE
Computer-aided software engineering (CASE) is software to support software development and evolution processes
Activity automation• Graphical editors for system model development
• Data dictionary to manage design entities
• Graphical UI builder for user interface construction
• Debuggers to support program fault finding
• Automated code generators: code (skeletons) from designs
• Automated translators from old (versions of a) programming language to new version or language.
Slide 42
Case technology
Case technology has led to significant improvements (40%, Huff’92) in the software process -- but not the predicted order of magnitude improvements
Reasons for limited effectiveness• Creative work is not readily automatable
• Software engineering effort largely spent in team interactions. CASE technology does not really help here
Slide 43
Functional tool classification
(Syntax-directed)
Slide 44
PERT - Project Evaluation and Review Technique
• U.S. Dept. Of Defense ha usato PERT (‘50) nel progettare il sottomarino Polaris
• Presenta un progetto (sia per pianificazione che per gestione) come insieme parzialmente ordinato di attività, ciascuno con una durata.
• Cammino critico dal nodo START al nodo END: quello di maggior durata