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