Ciclo di vita del software

(1)

L , P at te rns , a nd J ava ri ent ed S oft w are E ngi ne eri ng

Ciclo di vita

del software

(2)

Problemi inerenti lo sviluppo software

I requisiti cambiano continuamente

Il cliente potrebbe non conoscere tutti i requisiti in anticipo.

I cambiamenti frequenti sono difficili da gestire Pianificare le attività e stimare i costi è difficile.

Ci sono più sistemi che devono interagire

I nuovi sistemi spesso devono essere compatibili con quelli precedenti (i.e., “sistemi legacy”).

(3)

Ciclo di vita del software

(4)

Ciclo di vita del software

Il termine ”ciclo di vita” si basa sulla metafora della vita di una persona.

(5)

Ciclo di vita del software

Concepimento

(6)

Ciclo di vita del software

Concepimento Infanzia

(7)

Ciclo di vita del software

Concepimento Infanzia Età

Adulta

(8)

Ciclo di vita del software

Concepimento Infanzia Età

Adulta Pensione

(9)

Ciclo di vita del software

Concepimento

Pre-Sviluppo

Infanzia Età

Adulta Pensione

(10)

Ciclo di vita del software

Concepimento

Sviluppo Pre-Sviluppo

Infanzia Età

Adulta Pensione

(11)

Ciclo di vita del software

Post-Sviluppo

Concepimento

Sviluppo Pre-Sviluppo

Infanzia Età

Adulta Pensione

(12)

Ciclo di vita del software

Post-Sviluppo

Concepimento

Sviluppo Pre-Sviluppo

Infanzia Età

Adulta Pensione

(13)

Ciclo di vita del software

Post-Sviluppo

Concepimento

Sviluppo Pre-Sviluppo

Infanzia Età

Adulta Pensione

Infanzia

(14)

Identificare le attività di sviluppo software

Quale è il problema?

Quale è la soluzione?

Quali sono i migliori meccanismi per implementare la soluzione?

Come dovrebbe essere costruita la soluzione?

Il problema è risolto?

Il cliente riesce ad usare la soluzione?

Come gestiamo i cambiamenti durante lo sviluppo del software?

Dobbiamo apportare dei miglioramenti?

(15)

Analisi dei requisiti

Progettazione del sistema

Quale è il problema?

Quale è la soluzione?

Progettazione dettagliata Quali sono i migliori meccanismi  per implementare la soluzione?

Implementazione Come dovrebbe essere

costruita la soluzione?

Collaudo

Il problema è risolto?

Attività di sviluppo software

(16)

Collaudo

Consegna Il cliente riesce ad usare la soluzione?

Manutenzione Dobbiamo apportare dei miglioramenti?

Dominio Applicativo

Attività di sviluppo software

(17)

Collaudo

Dominio Applicativo

Dominio

della Soluzione

Attività di sviluppo software

(18)

Definizioni

Ciclo di sviluppo software

• Un insieme di attività e le relazioni tra loro per supportare lo sviluppo di un sistema software

Metodologia di sviluppo software

• Un insieme di tecniche per costruire modelli applicati al ciclo di sviluppo software

Attività relative alla definizione

del problema

Attività relative allo sviluppo

del sistema

Attività relative alla messa in opera

del sistema

Attività relative alla creazione

del mercato

Attività relative all’aggiornamento

del sistema

(19)

Visioni del ciclo di sviluppo del software

Documento

di post-mortem analysis Documento di

specifica del sistema Documento di

analisi del mercato

Sviluppo software

Finora abbiamo visto lo sviluppo software come una serie di attività di sviluppo.

Sistema eseguibile

(20)

Combinazione di attività e deliverables

Documento di analisi del mercato Definizione del

problema

Sviluppo del sistema

Messa in opera del sistema

Attività Deliverable

consuma

produce consuma produce consuma

produce

Documento di

specifica del sistema

Sistema eseguibile

Documento

di post-mortem analysis

(21)

IEEE Std 1074: uno standard per le attività del ciclo di sviluppo software

IEEE Std 1074

Gestione del

Progetto Pre-Sviluppo Sviluppo Post-Sviluppo Cross-Sviluppo

> Project Initiation

> Project Monitoring & Control

> Software Quality Management

> Concept Exploration

> System Allocation

> Requirements

> Design

> Implementation

> Installation

> Operation &

Support

> Maintenance

> Retirement

> V & V

> Configuration Management

> Documentation

> Training

(22)

Maturità del processo

Un processo di sviluppo software è maturo se

• le attività di sviluppo sono ben definite e

• il management ha qualche tipo di controllo sulla qualità, il budget ed la pianificazione del progetto

La maturità del processo è definita con

• un insieme di livelli di maturità

• le misure associate (i.e., metriche) per gestire il processo

Si assume che una crescente maturità riduca il rischio di fallimento del progetto.

La maturità del processo può essere misurata con il Capability Maturity Model.

(23)

Livelli del CMM

1. Iniziale. Chiamato anche ad-hoc o caotico.

2. Ripetibile. Il processo dipende dai membri del progetto.

3. Definito. Il processo prevede sanzioni da parte del management.

4. Gestito. Le attività sono misurate e viene fornito del feedback per l’allocazione delle risorse.

5. Ottimizzato. Il processo cambia in base al feedback ricevuto.

(24)

Cosa misura il CMM?

Il vero indicatore della maturità del processo è la predicibilità delle performance del progetto (e.g., qualità, costi, pianificazione).

•Livello 1: casuale, performance non pronosticabili

•Livello 2: performance ripetibili da progetto a progetto

•Livello 3: performance migliori dopo ogni progetto

•Livello 4: sostanziale miglioramento di una misura di performance

•Livello 5: sostanziali miglioramenti di tutte le misure di performance

(25)

Aree chiave del processo

Per raggiungere un certo livello di maturità, un’organizzazione deve dimostrare che soddisfa tutte le aree chiave di processo per quel livello.

• Il livello 1 non prevede nessuna area chiave di processo.

• Il livello 2 prevede l’adozione di pratiche di base per la gestione di progetti software.

• Il livello 3 prevede un’infrastruttura capace di gestire almeno un modello di ciclo di sviluppo del software.

• Il livello 4 prevede analisi quantitative del processo e dei deliverable.

• Il livello 5 tiene traccia di cambiamenti alla tecnologia ed al processo.

(26)

Vantaggi e Svantaggi del CMM

Vantaggi

• Maggiore controllo dei progetti

• Predicibilità del progetto e della pianificazione

• Valutazione oggettiva di cambiamenti relative a tecniche, strumenti e metodologie

• Predicibilità degli effetti di un cambiamento sui costi o la pianificazione

Svantaggi

• Le attività devono essere monitorate con attenzione (effetto ”Grande Fratello”)

• Costi aggiuntivi per ottenere, immagazzinare ed analizzare le informazioni richieste

(27)

Requirements Process

System

Allocation Process Concept

Exploration Process

Design Process

Implementation Process

Verification

& Validation Process

Il modello a cascata del

ciclo di vita del software

(28)

Esempio di Modello a Cascata:

DOD Standard 2167A

Attività di sviluppo software

• Analisi dei requisiti del sistema

• Progettazione preliminare e progettazione in dettaglio

• Implementazione e testing di unità

• Integrazione delle componenti e testing

• Integrazione del sistema e testing

L’esecuzione di queste attività è richiesta dal Dipartimento di Difesa Americano per tutti i software contractors negli anni ’80 e ’90.

(29)

Diagramma delle attività

del modello MIL DOD-STD-2167A

Preliminary Design Review

Critical Design Review (CDR)

System

Requirements Review

System Design Review

System

Requirements Analysis

Software

System Design

Preliminary Design

Detailed Design

(30)

Dal modello a cascata al modello a V

System Design Requirements

Analysis Requirements

Engineering

Object Design

Integration Testing

Unit Testing Implemen-

tation

(31)

Dal modello a cascata al modello a V

Engineering

Object Design

Implemen- tation

System Testing

Unit Testing

Integration Testing

Acceptance

(32)

Dal modello a cascata al modello a V

Engineering

Object Design

Implemen- tation

System Testing

Unit Testing

Integration Testing

Acceptance

(33)

Diagramma delle attività del modello a V

System

Preliminary Design

Detailed Design Software

Requirements Elicitation

Operation

Client

Acceptance

UnitTest

System Integration

& Test

Component Integration

& Test

(34)

Diagramma delle attività del modello a V

System

Implementation Preliminary

Design

Detailed Design Software

Requirements Elicitation

Operation

Client

Acceptance

UnitTest

System Integration

& Test

Component Integration

& Test

(35)

Proprietà dei modelli a cascata

I manager amano i modelli a cascata

• Milestone definite

• Nessun bisogno di guardare il passato (modello lineare)

• Viene eseguita un’attività alla volta

• È facile controllare i progressi durante lo sviluppo (e.g., 90% implementato, 20% testato).

Lo sviluppo software non è però lineare

• Durante la fase di design, possono essere identificati problemi nei requisiti

• Durante la fase di implementazione, possono essere identificati problemi nel design ed nei requisiti

• Durante la fase di testing, possono essere identificati errori nell’implementazione, nel design e nei requisiti

(36)

Il modello a spirale proposto da Boehm è costituito da iterazioni (round), ognuna composta dalle seguenti attività:

1. Determinare obiettivi e vincoli 2. Valutare le alternative

3. Identificare i rischi

4. Risolvere i rischi assegnando priorità

5. Sviluppare prototipi per i rischi identificati partendo dal più grande 6. Utilizzare un modello a cascata per sviluppare ogni prototipo

a. Se un rischio è stato risolto con successo, valutare i risultati dell’iterazione e progettare il successivo b. Se un rischio non può essere risolto, terminare il progetto immediatamente

Alternativa: Permettere più iterazioni

Modello a Spirale

(37)

Modello a Spirale di Boehm

(38)

Round 1 ^, Definizione delle Operazioni ^, Quadrante IV:

Determinare Obiettivi, Alternative e Vincoli

Inizio Progetto

(39)

Analisi dei Rischi

Round 1 ^, Definizione delle Operazioni ^, Quadrante I:

Valutare Alternative, Identificare e Risolvere Rischi

(40)

Analisi dei sistema

Round 1 ^, Definizione delle Operazioni ^, Quadrante II:

Sviluppo e Verifica

(41)

Round 1 ^, Definizione delle Operazioni ^, Quadrante III:

Preparazione per la Prossima Attività

(42)

Inizio del Round 2

Round 2 ^, Definizione delle Operazioni ^, Quadrante IV:

Determinare Obiettivi, Alternative e Vincoli

(43)

Limitazioni dei Modelli a Cascata e Spirale

Nessuno di questi modelli gestisce bene cambiamenti frequenti

• Il modello a cascata summe che una volta terminate una fase, tutti i problemi coperti in quella fase siano chiusi e non possano essere riaperti.

• Il modello a spirale può gestire il cambiamento tra le fasi, ma non il cambiamento all’interno di una fase.

Nonostante questo:

“The only constant is change”

(44)

Alternativa: Sviluppo basato sui Problemi

Un sistema viene descritto come un insieme di problemi (issue)

• I problemi possono essere chiusi o aperti

• I problemi chiusi hanno una soluzione

• I problemi chiusi possono essere riaperti (iterazione)

L’insieme dei problemi chiusi è la base del modello.

I1:Open

I2:Closed I3:Closed

A.I1:Open

A.I2:Open

SD.I1:Closed

SD.I2:Closed

SD.I3:Closed

(45)

Modello a Cascata: Fase di Analisi

I1:Open

I2:Open I3:Open

A.I1:Open

A.I2:Open

SD.I1:Open

SD.I2:Open

SD.I3:Open

Analysis Analisi

(46)

Modello a Cascata: Fase di Design

I1:Closed

I2:Closed I3:Closed

A.I1:Open

A.I2:Open

SD.I1:Open

SD.I2:Open

SD.I3:Open

Analysis

Design

Analisi

(47)

Modello a Cascata: Fase Implementativa

I1:Closed

I2:Closed I3:Closed

A.I1:Closed

A.I2:Closed

SD.I1:Open

SD.I2:Open

SD.I3:Open

Analisi

(48)

Modello a Cascata: Progetto Concluso

I1:Closed

I2:Closed I3:Closed

A.I1:Closed

A.I2:Closed

SD.I1:Closed

SD.I2:Closed

SD.I3:Closed

Implementazione Design

Analisi

(49)

Modello basato sui Problemi:

Fase di Analisi

I1:Open

I2:Open I3:Open

D.I1:Open

Imp.I1:Open

Analisi:80%

(50)

I1:Closed

I2:Closed I3:Open

SD.I1:Open

SD.I2:Open

Imp.I1:Open

Imp.I2:Open

Imp.I3:Open

Analisi: 40%

Design: 60%

Implementazio ne: 0%

Modello basato sui Problemi:

Fase di Design

(51)

I1:Open

I2:Closed I3:Closed

A.I1:Open

A.I2:Closed

SD.I1:Open

SD.I2:Closed

SD.I3:Open

Analisi: 10%

Modello basato sui Problemi:

Fase Implementativa

(52)

I1:Closed

I2:Closed I3: Pending

A.I1:Closed

A.I2:Closed

SD.I1:Closed

SD.I2: Unresolved

SD.I3:Closed

Modello basato sui Problemi:

Prototipo Completato

(53)

Frequenza del Cambiamento e Scelta del Modello di Ciclo di Vita da Adottare

PT = Tempo del Progetto

MTBC = Tempo Medio tra i Cambiamenti Il cambiamento è raro (MTBC » PT)

• Modello Lineare (Cascata, Modello a V)

• I problemi aperti sono risolti prima di iniziare una nuova fase.

Il cambiamento occorre a volte (MTBC ≈ PT)

• Modello Iterativo (Modello a Spirale)

• Il cambiamento all’interno di una fase può portare a iterare una fase precedente o cancellare il progetto.

Il cambiamento è frequente (MTBC « PT)

• Modello basato sui Problemi (Scrum o Kanban)

• Le fasi non finiscono mai, ma avvengono in parallelo.