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.

Presentazione sul tema: "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."— Transcript della presentazione:

1 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

2 Slide 2 ESA - Incremental delivery approach (*) (*) European Space Agency Software Engineering Standards, ESA PSS-05-0, N. 2, Feb. 91. In [TMcG93] User Requirements Software Requirements Architectural Design Detailed Design and coding TRansfer to operations Operations 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

3 Slide 3 Incremental delivery [S2001] - 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

4 Slide 4 ESA - Evolutionary development approach Sequenza rapida di cicli waterfall completi Serve a chiarire e far evolvere i requisiti attraverso esperienza diretta su implementazioni intermedie

5 Slide 5 Evolutionary development [S2001]

6 Slide 6

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

8 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

9 Slide 9 Trasformazione formale

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

11 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

12 Slide 12 The Cleanroom process By correctness-preserving transformations Functional requirements in ‘box structure’ notation System usages

13 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

14 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

15 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

16 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

17 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

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

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

20 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

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

22 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

23 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

24 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

25 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

26 Slide 26 Il (meta-)modello ibrido a spirale [Boehm 88]

27 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’

28 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

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

30 Slide 30 ‘Best practices’ in S.E. processes 123456123456

31 Slide 31 1. Develop iteratively (Phases and Workflows)

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

33 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

34 Slide 34 Evolvable architecture (bought, built, new)

35 Slide 35 4. Model software visually (with UML diagrams)

36 Slide 36 5. Verify quality - test incrementally

37 Slide 37 …using test tools

38 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

39 Slide 39

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

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

42 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

43 Slide 43 Functional tool classification (Syntax-directed)

44 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