Lezione 2 Ciclo diVita e Processi Softwareunina.stidue.net/Ingegneria del Software 2/Materiale/Slides 2009-201… · 2 Ingegneria del Software 2 – CVS e Processi Software 3 Obiettivi

1

Ingegneria del Software 2 – CVS e Processi Software 1

Lezione 2Ciclo di Vita e Processi Software


Riferimenti bibliografici

• I. Sommerville – Ingegneria del Software – 8a edizione – Cap.4

• R. Pressman- Principi di Ingegneria del Software- 4 edizione- Cap. 3

2


Obiettivi della lezione

1. Richiamare I concetti di Ciclo di Vita del Software e di Ciclo di Sviluppo Software

2. Classificare I Modelli di Processo Software fondamentali


Il Ciclo di Vita del Software (CVS)

• Standard IEEE 610.12-1990

• Software Life Cycle: The period of time that starts whena software product is conceived and ends when the product is no longer available for use. The software life cycle typicallyincludes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkoutphase, operation and maintenance phase, and sometimes, retirement phase. Note: These phases may overlap or beperformed iteratively. Contrast with Software DevelopmentCycle.

3


Ciclo di Sviluppo Software


• Software Development Cycle : (1) The period of time that begins with the decision to develop a software product and ends whenthe product is delivered. This cycle typically includes a requirements phase, design phase, implementation phase, test phase, and sometimes, installation and checkout phase. Contrastwith Software Life Cycle.

• Notes: The phases listed above may overlap or be performediteratively, depending upon the software development approach used. (2) This term is sometimes used to mean a longer period of time, either the period that ends when the software is no longer being enhanced by the developer, or the entire software life cycle


Una architettura per la definizione di CVS


• Software Life Cycle: a framework containing the processes, activities,and tasks in the development, operation and maintenance of a software product, spanning the life of the system from the definition of its requirements to the termination of its use

4


Ciclo di Vita ed i suoi Processi (St.ISO12207)

LIFE CYCLE

SUPPORTING

CONFIGURATION MANAGEMENTDOCUMENTATION

QUALITY ASSURANCE

VERIFICATIONVALIDATION

JOINT REVIEW

AUDIT

PROBLEM RESOLUTION

PRIMARY

DEVELOPMENT

OPERATION

MAINTENANCE

ACQUISITION

SUPPLY

ORGANIZATIONAL

MANAGEMENT

INFRASTRUCTURE

IMPROVEMENT

TRAINING


Processi Software: definizione

• Processo : – un insieme di attività concentrate nel tempo finalizzate

alla realizzazione di un particolare output.• Processo Software:

– Un insieme strutturato di attività necessarie per lo sviluppo di un sistema software.

– Specifica;– Progettazione (o Design);– Validazione;

– Evoluzione

5


Modelli di Processi Software

• Un processo software può essere organizzato usando i Modelli di Processo Software:– I Modelli di Processo Software (talora detti ancora

CVS) definiscono la struttura di massima di un processo software, indicando le fasi in cui si articola e i criteri di successione.

– Un Modello di processo software è unarappresentazione astratta di un processo.

– Fornisce una descrizione del processo da unaparticolare prospettiva.


Quali Modelli di Processo Software?

• Una possibile classificazione:

1. Processi basati su documentazione• Basati su linguaggi semi-formali per la specifica dei

documenti (es. UML), e richiedono trasformazioni e controlli manuali dei prodotti intermedi

2. Processi basati su Metodi Formali– Basati su linguaggi formali di specifica, con

trasformazioni e controlli automatici

3. Approcci AGILI– Uso ridotto di documentazione

6


• In questo corso approfondiremo:– (1) Processi basati su documentazione – (3) Processi basati su metodi AGILI

• Non tratteremo approcci basati su metodi formali!


Modelli di Processo dalla letteratura

• Basati su documentazione:– Waterfall– Evolutivo– Basato sul Riuso (di Componenti, Linee di Prodotto…)– Incrementale– A Spirale – Rational Unified Process (UP e RUP) …

• AGILI:– XP (eXtreme Programming) – TDD (Test Driven Development)

7


Requirementsdefinition

System andsoftware design

Implementa tionand unit testing

Integ ration andsystem testing

Oper ation and

maintenance

Il Waterfall model


• Fasi sequenziali ben definite• Sviluppo Guidato dalla documentazione

ma...

• Troppo rigido/ burocratizzato• Rilascia software solo a completamento di tutte le fasi• Richiede conoscenza immediata e stabilità dei requisiti

Il Waterfall model

8


• Basato sull’idea di produrre una versione iniziale del software, esporla agli utenti e perfezionarla attraversovarie versioni. Due modelli fondamentali:

• (A) Sviluppo Esplorativo– L’obiettivo è di lavorare col cliente per esaminare i requisiti

iniziali e farli evolvere fino al sistema finale. Dovrebbepartire da pochi requisiti ben compresi e aggiungere nuovecaratteristiche proposte dal cliente.

• (B) Prototipale (Usa e Getta)– L’obiettivo è di comprendere i requisiti del sistema. Si parte

da requisiti poco chiari e si realizzano prototipi per esplorarei requisiti e chiarirli.

Sviluppo Evolutivo


(A) Sviluppo evolutivo- Esplorativo

Concurr entacti vities

Valida tionFinal

version

DevelopmentInter media te

versions

Specifica tionInitial

version

Outlinedescription

9


(A) Sviluppo evolutivo- Esplorativo

• Vantaggi:– Rapido feedback e possibilità di far cambiare I requisiti

• Problemi– Mancanza di visibilità del processo (è anti-economico

documentare ogni versione del sistema);– I sistemi diventano spessomal strutturati (per i continui

cambiamenti);– Richiedono particolari skills (es. Uso di linguaggi di

prototipazione rapida)• Applicabilità

– A sistemi interattivi di piccole e medie dimensioni (<500.000 LOC);

– Per sviluppare alcune parti di sistemi di grandi dimensioni (per es. l’interfaccia utente);

– Per sistemi destinati a vita breve.

• Per grandi sistemi è consigliabile un approccio misto.


(B) Sviluppo Evolutivo- Prototipale

• Realizzazione di una prima implementazione (prototipo), più o meno incompleta da considerare come una ‘prova’, con lo scopo di:– accertare la Fattibilità del prodotto– validare i Requisiti

• Dopo la fase di utilizzo del prototipo si passa alla produzione della versione definitiva del Sistema Sw mediante un modello che, in generale, è di tipo waterfall.

10


Modello con Prototipo (Usa e Getta)


IS basata sul Riuso

• Sviluppo basato sul riuso sistematico, integrandoComponenti esistenti o interi sistemi COTS (Commercial-off-the-shelf)

• Fasi del Processo (CBSE)– Specifica dei requisiti;– Analisi dei componenti;– Modifica dei Requisiti (specificando i componenti disponibili);

– Progettazione con riuso;– Sviluppo e Integrazione.

• Necessita di appositi standard per la specifica dicomponenti.

11


Sviluppo basato sul Riuso

Requirementsspecification

Componentanalysis

Developmentand integ ration

System designwith reuse

Requirementsmodification

Systemvalidation


Processi di sviluppo Iterativi

• In un ambiente globale di rapidi cambiamenti, è essenziale per la competitività delle aziende che il software di cui necessitanosia sviluppato e consegnato in tempi rapidi!

• La mutevolezza ed instabilità dei requisiti impongono diadottare processi di sviluppo ciclici, in cui il software vieneconsegnato in una serie di incrementi, prodotti in vari cicli diprocesso (iterazioni) in cui si ritorna sulle fasi già condotte

• I cicli di processo possono essere applicati ad ogni genericomodello di processo.

• Due possibili approcci:– (A) Sviluppo e Consegna Incrementale;– (B) Sviluppo a Spirale.

12


(A) Sviluppo e Consegna Incrementale

• Piuttosto che consegnare il sistema tutto in una volta, lo sviluppo e la consegna sono eseguiti per incrementi,dove ogni incremento rilascia parte dellefunzionalità richieste .

– Ai requisiti Utente vengono associati livelli di priorità e quelli a priorità maggiore vengono rilasciati con I primiincrementi.

– Una volta partito lo sviluppo di un incremento, I relativirequisiti devono essere congelati, mentre I requisiti coinvoltiin incrementi successivi possono continuare ad evolvere.

– I servizi comuni possono essere implementati all’inizio del processo, o quando una funzione è richiesta da un datoincremento.


(A) Sviluppo e Consegna Incrementale

Validateincrement

Develop systemincrement

Design systemar chitectur e

Integrateincrement

Validatesystem

Define outline requirements

Assign requirements to increments

System incomplete

Finalsystem

13


Esempio di processo incrementale

Requisiti: R1, R2, R3Architettura: C1, C2, C3, C4Pianificazione: 3 iterations

Iteration1R1, requires C1, C2Develop and integrate C1, C2Deliver R1

Iteration2R2, requires C1, C3Develop C3, integrate C1, C2, C3Deliver R1 + R2

Iteration3R3, requires C3, C4Develop C4, integrate C1, C2, C3, C4Deliver R1 + R2 + R3


Vantaggi dello sviluppo incrementale

– I clienti non devono aspettare il sistema completoper la consegna, ma possono disporre al più presto dei requisiti più critici, attraverso I primi incrementi.

– I primi incrementi possono essere usati come prototipo per aiutare a definire I requisiti degliincrementi successivi.

– Si riduce il rischio di un fallimento totale del progetto.– I servizi a più alta priorità saranno anche testati più

intensamente degli altri.

14


Problemi dello sviluppo Incrementale

• Problemi– Gli incrementi devono essere relativamente piccoli

(<=20.000 LOC) ma può essere difficile predisporre i requisiti in incrementi della dimensione giusta.

– Le funzionalità comuni (richieste da più requisiti) potrebbero non essere identificate abbastanza presto, giacchè bisogna prima attendere che gli incrementi siano completati per avere ben chiari tutti i requisiti.


Un esempio: Extreme programming

• Extreme Programming

– Un esempio di approccio allo sviluppo basato susviluppo e consegna di piccolissimi incrementi difunzionalità.

– Si basa su un continuo miglioramento del codice, sulcoinvolgimento dell’utente nel processo di sviluppo, e sulla programmazione a coppie.

15


(B) Sviluppo a Spirale (di Boehm)

• Il processo è rappresentato come una spirale, piuttosto che una sequenza di attività con retro-azioni.

• Ogni giro nella spirale rappresenta una fase del processo.

• Non prevede fasi prefissate a priori (come la specifica o il design) ma i cicli sono definiti in base al caso specifico.

• C’è una esplicita gestione dei rischi che vengonovalutati e risolti durante tutto il processo.

• Metamodello perché comporta la selezione di un modello di CVS da adottare nello sviluppo.


Modello di sviluppo a spirale

Riskanalysis

Riskanal ysis

Riskanal ysis

Riskanal ysis Pr oto-

type 1

Pr ototype 2

Pr ototype 3Oper a-tionalpr oto ype

Concept ofOper ation

Simula tions , models , benchmar ks

S/Wrequir ements

Requir ementv alidation

DesignV&V

Productdesign Detailed

design

Code

Unit test

Integ ra tiontest

AcceptancetestService De velop , verify

ne xt-level pr oduct

Evalua te alterna tives,identify, resolv e risks

Deter mine objecti ves,alterna tives and

constr aints

Plan ne xt phase

Integ rationand test plan

De velopmentplan

Requir ements planLife-cycle plan

REVIEW

1. Determinazione di obiettivi, alternative e

vincoli

3. Sviluppo e Verifica del prodotto successivo

4. Pianificazione della fase

successiva

2. Valutazione di alternative,

identificazione e risoluzione dei

rischi

16


Settori del modello a spirale

• Determinazione degli obiettivi– Definizione di obiettivi , vincoli e piano di gestione della

fase.

• Valutazione e riduzione del rischio– Si analizzano I rischi della fase e si scelgono le attività

necessarie a gestire I rischi.• Sviluppo e Convalida

– Si sceglie un modello di sviluppo per il sistema tra I modelli generici.

• Pianificazione– Il progetto viene revisionato e si decide se continuare con

un nuovo giro della spirale. Si pianifica tale giro.


• Il RUP (Rational Unified Process)– Un esempio di modello di processo “ibrido”

17


Unified Process


Rational Unified Process (RUP)

• Un moderno modello di processo software derivato da UML e dal relativo processo.

• Include tutte le caratteristiche dei modelli generici(sviluppo iterativo ed incrementale)

• Individua 3 prospettive sul processo: – Una prospettiva dinamica che mostra le fasi del

modello al fluire del tempo;– Una prospettiva statica che mostra le attività

(workflow) coinvolte;– Una prospettiva pratica che suggerisce le buone

regole da seguire.

18


Prospettiva dinamica: Le fasi del RUP

Phase iteration

Inception Elaboration Construction TransitionAvvio Elaborazione Costruzione Transizione


Le fasi del RUP

• Avvio– Stabilire gli obiettivi di business (e relativi limiti, fattibilità e

giustificazioni economiche) per il sistema.

• Elaborazione– Ottenere una comprensione del dominio del problema (e

specificare i requisiti), stabilire una struttura architetturaleed il piano di progetto.

• Costruzione– Progettare, programmare e testare il sistema

incrementalmente.

• Transizione– Trasferire il sistema nel suo ambiente operativo.

19


Fasi, Iterazioni ed Incrementi

• Ogni fase può essere eseguita in modo ciclico (più iterazioni) , con risultati sviluppati in modo incrementale.

• Anche l’intero sistema delle fasi può essere ripetuto ciclicamente.


Prospettiva Statica: I Workflow

• Il RUP prevede vari workflow (6 attività principali e 3 di supporto):– Modellazione Processi di business– Requisiti– Analisi e Progettazione– Implementazione

– Test– Rilascio– Gestione della configurazione e delle modifiche– Gestione del Progetto– Ambiente

20


Workflows statici

Workflow Description

Business modelling T he business processes are modelled using business use cases .

Requirements Actors who interact with the system are identified and use cases aredeveloped to model the system requirements .

Analysis and design A design model is created and do cumented u sing architecturalmode ls, componen t models , object models and sequence models.

Implementation T he components in the system are implemented and structured intoimplementation sub- systems. Automatic code generation from designmode ls helps accelerate this process.

Test T esting is an iterative process that is carried ou t in conjunction withimplementation. System testing follows the completion of theimplementation.

Deployment A product release is created, distributed to users and installed in theirworkp lace.

Configuration andchange management

T his supporting workf low managed changes to the system (seeChapter 29).

Project management T his supporting workf low manages the system development (seeChapter 5).

Environment T his workflow is concerned with making appropriate software toolsavailable to the software development team.


Workflow e Fasi

• Il RUP non vincola l’esecuzione delle attività a specifiche fasi

• Tutti i workflow del RUP possono essere eseguiti in qualunque iterazione del processo.

• Ovviamente nelle prime iterazioni gli sforzi si concentreranno sui workflow di modellazione e dei requisiti, nelle successive sulla implementazione e sul test.

21


Distribuzione dei workflow per fasi

Incept ion Elabor at ion Const ruct ion Tr ansition Production

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support


Le sei pratiche fondamentali del RUP

• Sviluppare il software iterativamente:– Pianificare gli incrementi in base alle priorità del cliente

• Gestire i requisiti:– Documentare esplicitamente I requisiti ed I cambiamenti

effettuati• Usare architetture basate su componenti:

– Strutturare l’architettura con un approccio a componenti• Creare modelli visuali del software:

– Usare modelli grafici UML per rappresentare viste statiche e dinamiche del sistema

• Verificare la qualità del software:– Verificare l’aderenza a standard di qualità aziendali

• Controllare le modifiche al software:– Gestire I cambiamenti e le configurazioni del software

22


Configurazione del RUP

• Il RUP è un processo generico di sviluppo software:

– deve essere istanziato per ciascuna organizzazione e per ciascun progetto specifico, aggiungendo: standard, modelli di documento standard, strumenti, …

• Punti di forza:– Separazione di fasi e workflow– Le fasi sono dinamiche e vanno pianificate, i workflow sono

statici e sono attività tecniche condotte nelle varie fasi– Comprende un vasto insieme di linee guida e template per

operare con approccio OO e basato su componenti

– Definisce in modo accurato: Ruoli, Attività, Input Output delle varie attività


Costi del RUP

• Impatto organizzativo– Può portare ad una riorganizzazione completa del lavoro

• Impatto culturale– Può comportare una ridefinizione del modo di lavorare

• Costi tecnologici– L’utilizzo del processo é agevolato dall’uso di strumenti (tool)

specifici (come quelli della suite Rational)• Costi di avvio

– Adattamento del processo– Divulgazione– Inquadramento dei processi esistenti

• Spesso si rinuncia ad adottare il RUP proprio perchè essocomporta un drastico cambiamento nel modo di lavorare dellepersone, che potrebbero reagire (sul breve termine) diminuendo la loro produttività

23


Processi basati su Metodi Formali

• Uso di formalismo matematico per esprimere i requisiti– Es. Specifiche algebriche (es. per tipi di dato astratto)– Es. approccio basato su modelli di stato

• Uso di tecniche di model checking per provare la correttezza

• Trasformano automaticamente le specifiche in codice– La correttezza è preservata– La verifica è ottenuta implicitamente



24


Un esempio di specifica algebrica

Head (Create) = Undefined exception (empty list)Head (Cons (L, v)) = if L = Create then v else Head (L)Leng th (Create) = 0Leng th (Cons (L, v)) = Leng th (L) + 1Tail (Create ) = CreateTail (Cons (L, v)) = if L = Create then Create else Cons (T ail (L), v)

sor t Listimpor ts INTE GER

Defines a list where elements are added at the end and remo vedfrom the front. The oper ations are Create , which br ings an empty listinto e xistence , Cons , which creates a ne w list with an added member ,Leng th, which e valuates the list siz e , Head, which e valuates the frontelement of the list, and Tail, which creates a list b y remo ving the head fromits input list. Undefined represents an undefined value of type Elem.

Create ? ListCons (List, Elem) ? ListHead (List) ? ElemLeng th (List) ? IntegerTail (List) ? List

LIST ( Elem )



• Problemi– necessità di specifici skill (in linguaggi matematici)– Impossibilità a specificare formalmente alcune parti – Difficoltà del cliente nella convalida dei requisiti

• Applicabilità– Non adatti per sistemi di grandi dimensioni– Usati solo per parti critiche

25


Selezione di un Modello di Processo: qualche linea guida

• tolleranza del modello ai rischi che si potranno incontrare• facilità di comunicazione tra sviluppatori e utilizzatori• stabilità dei requisiti noti; probabilità di esistenza di requisiti (ancora) non

noti• importanza di rilasci ‘early’ di (parziali) funzionalità• Intrinseca complessità del problema e delle probabili soluzioni• (anticipata) conoscenza di frequenza e dimensione di richieste di

cambiamento• maturità dell’applicazione (o del dominio applicativo)• disponibilità e priorità di fondi• flessibilità dello scheduling e budget (scadenze per il ricevimento e spesa

dei fondi; possibilità di modificare gli incrementi per ottimizzare costi e minimizzare rischi)

• criticità del rispetto di scheduling e budget• adeguatezza del processo ‘istituzionale’ e tool di sviluppo dello

sviluppatore• corrispondenza tra organizzazione del management e il modello da adottare

Documents

Lezione 2 Ciclo diVita e Processi Softwareunina.stidue.net/Ingegneria del Software 2/Materiale/Slides 2009-201… · 2 Ingegneria del Software 2 – CVS e Processi Software 3 Obiettivi