Ingegneria del Software - Dipartimento di Ingegneria dell`Informazione

UNIVERSITA’ DI FIRENZE
Facoltà di Ingegneria
Ingegneria del Software
Ciclo di Vita
O
Ciclo a Cascata e a V
I
R
Modelli agili ISO
V
V
Standard e Normativa
O
Prof. Giacomo Bucci
(2010-11 )
R
P
Il ciclo di vita
Da ANSI / IEEE Std 729-1983
Il ciclo di vita è il periodo di tempo che:
inizia quando un prodotto software viene
concepito
termina quando il prodotto software non viene
più usato
Costituisce il contesto organizzativo per
lo sviluppo di un progetto
Detto anche processo software
Ciclo di vita
G. Bucci
2
Il ciclo di vita
Organizzato in fasi.
Grossolanamente: sviluppo e uso
La fase di uso è molto più lunga della fase di
progetto e sviluppo
durante la fase d’uso è normale apportare
modifiche
Inizio
Abbandono
Rilascio
Uso
Sviluppo
(processo software)
Leggenda metropolitana:
Il costo della fase di uso (costo maintenance) è il 70%
del totale
Ciclo di vita
G. Bucci
3
Ciclo di vita
Due classi estreme di modelli del ciclo
Modelli Prescrittivi
Modelli Agili
fasi ben codificate in successione
organizzazione e metodi
Esempio: modello cascata
privilegiano l’adattabilità
riducono la burocrazia
Esempio: Extreme programming
Code & Fix : Non è niente !!!
Ciclo di vita
G. Bucci
4
Ciclo di vita
Serve un modello che possa essere:
controllato
diviso in fasi
che consenta di identificare i semilavorati
lungo il processo di produzione
che permetta di identificare milestones
etc.
Ciclo di vita
G. Bucci
5
Schema preliminare
Requisiti
Analisi
Spazio del problema
Spec. Requisiti
Progettazione
Spec. Progetto
Realizzazione
Spazio della
soluzione
Ciclo di vita
G. Bucci
Codice corretto
6
Modello del ciclo di vita
a Cascata
W. W. Royce, Winston W., Managing the Development
of Large Software Systems, IEEE 1970
Ciclo di vita
G. Bucci
7
Modello a cascata
Capostipite di tutti i modelli di ciclo
di vita
risente dell’epoca in cui è stato
formulato
albori dell’industria del software
macchine/strumenti scadenti
E’ un po’ il modello “industria
pesante” o “piano quinquennale”
Ciclo di vita
G. Bucci
8
Modello a Cascata: Fasi e
deliverables (i principali)
SRS
Studio di
Fattibilità
Analisi
DS
Progetto
Ele
m
ent
id
Codifica
Test unit
i di
stu
r
bo
Codice e
risultati test
Integraz
Test sist.
Manutenz
Più una caterva
di altri
documenti
Ciclo di vita
G. Bucci
9
Fasi
Ogni fase
ha un obiettivo definito;
si basa sui risultati della fase precedente
Le fasi corrispondono ad attività che
transformano i loro ingressi in uscite;
presuppongono la verifica ai milestones
Ciclo di vita
G. Bucci
10
Milestone
E’ un evento predefinito
che serve a misurare il progredire dello
sviluppo
Un milestone prevede normalmente:
la consegna di prodotti (intermedi) - detti
deliverable
un esame (review) formale
(l’emissione di un documento)
Ciclo di vita
G. Bucci
11
Analisi/specifica dei requisiti
L’analisi è lo studio di un problema prima di
intraprendere qualsiasi azione (*)
L’analisi è lo studio del dominio di un
problema, che porta alla specifica di un
comportamento esternamente osservabile, a
una descrizione coerente e fattibile di ciò che
occorre realizzare
De Marco “Structured Analysis and System
Specification", Yourdon Press, 1978.
Ciclo di vita
G. Bucci
12
Analisi
Il principale deliverable prodotto è l’SRS
Fornisce una base di confronto e di accordo
contrattuale con il committente
Dovrebbe produrre anche il Manuale Utente e
il Piano di test del sistema
Analisi
SRS
Il manuale utente dice meglio di qualunque altra
cosa come si comporterà il sistema
Il piano di test dice come verranno condotti i test
del sistema
Grande approfondimento
Ciclo di vita
G. Bucci
13
Progettazione
SRS
DS
Progetto
La Specifica di Progetto (DS) contiene
l’architettura del software:
Scomposizione del sistema in sottosistemi
Identificazione dei moduli e delle relazioni
tra i moduli (struttura del sistema secondo
una conveniente rappresentazione)
Interfacce
Convenzioni di chiamata
...
Ciclo di vita
G. Bucci
14
DS
Realizzazione
Codifica
C&T
Codice e
risultati test
I singoli moduli vengono sviluppati in base
alla specifica di progetto, nel linguaggio di
programmazione scelto
Test individuali
I singoli moduli vengono provati per conto
proprio
Ciclo di vita
G. Bucci
15
Integrazione
Il fatto che i singoli moduli siano
individualmente testati non è sufficiente
a garantire il corretto funzionamento
del sistema
Spesso si scoprono incongruenze
progettuali
Normalmente è la fase più dolente
Si parla di alfa test, beta test,
COLLAUDO
Ciclo di vita
G. Bucci
16
Manutenzione
I costi per la manutenzione sono di norma superiori
ai costi di sviluppo
Si parla di un 70% del costo totale (sviluppo più
manutenzione)
Correttiva (eliminazione errori)
Adattativa (alle condizioni esterne)
Perfettiva (nuove funzionalità, eliminazione di funzionalità
inutili)
di norma oltre il 50% della manutenzione
Sui costi di manutenzione hanno grande incidenza:
la modalità di progetto e sviluppo
la qualità della documentazione
Ciclo di vita
G. Bucci
17
Documentazione
Documentazione tecnica interna
Documentazione tecnica esterna
motivazioni per le assunzioni fatte e le decisioni prese in ogni fase
risultati dei test
…
struttura del sistema
istruzioni per l’installazione
guida alla soluzione dei problemi
...
Documentazione per l’utente finale
Manuale utente
prontuario (quick reference)
guided tour
...
Ciclo di vita
G. Bucci
18
Costi modifiche (tradizionale)
Dati sperimentali
indicavano che il
costo dei
cambiamenti
cresceva
esponenzialmente
nel tempo
Ciclo di vita
G. Bucci
19
Se i costi crescono
esponenzialmente:
Bisogna pianificare bene le attività del
progetto
Scoprire un errore subito fa salvare
denaro
Modificare il modello è meglio che
modificare il codice
=>Investire sulle fasi di analisi
=>BDUF (big design up-front)
E’ proprio così ?
Ciclo di vita
G. Bucci
20
Il modello a cascata
Presume che sia possibile definire
esattamente quali sono i requisiti del sistema
Presume che i requisiti siano stabili
Ma i requisiti non sono stabili
E’ la traduzione dei processi manifatturieri:
La Fiat deve pianificare esattamente la catena di
montaggio.
Il SW può essere cambiato sempre
Ciclo di vita
G. Bucci
21
Problemi del ciclo a cascata
Tende a spostare in avanti le verifiche:
Ci si può accorgere troppo tardi di errate
concezioni o di errori
Produce disallineamento tra ciò che
viene “fatto” e ciò che era “desiderato”
Il prodotto risultante finisce per soddisfare
le esigenze degli sviluppatori, anziché
quelle dei committenti.
Ciclo di vita
G. Bucci
22
Cosa ci si aspetta
Ciclo di vita
G. Bucci
Dall’uso di
strumenti,
tecniche e
metodi attuali
23
Perché investire tanto nella fase iniziale
quando non si sa bene dove si va a
cascare?
Perché investire su cose che possono
rivelarsi del tutto inutili?
...Il tempo dirà al momento opportuno cosa
fare e cosa non fare
Ciclo di vita
G. Bucci
24
Inoltre
Il modello a cascata
Tende a irreggimentare
Non si adatta allo spirito del
programmatore (un progettista/inventore
piuttosto che un produttore)
E’ burocratico
impone la produzione di una quantità di
semilavorati che disturba il programmatore
Occorrono modelli meno rigidi
Ciclo di vita
G. Bucci
25
Prototipazione
Un modo per ridurre i problemi
Prototipo: una realizzazione parziale
di un sistema, costruita allo scopo di
permettere a committenti, utenti e
sviluppatori una miglior conoscenza del
problema e delle sue soluzioni
Usa e getta
Prototipo evolutivo
Ciclo di vita
G. Bucci
26
Prototipazione
L’uso di prototipi aiuta nella scrittura di SRS
Il committente preferisce vedere un prototipo
piuttosto che un documento scritto
Il prototipo mette in evidenza aspetti non previsti
Alcuni requisiti (p.e., i formati delle videate)
possono essere estratti direttamente dal prototipo
e portati in SRS
Il processo deve essere ordinato: successivi
rilasci di SRS e relativi prototipi, fino ad
arrivare a SRS definitivo.
Ciclo di vita
G. Bucci
27
Evoluzione tecnologica
Nel processo software:
dal metodo a cascata
ai metodi “agili”
Ciclo di vita
G. Bucci
28
Modello iterativo-evolutivo
Successivi ampliamenti e rifiniture attraverso
iterazioni multiple (feedback)
Il sistema cresce incrementalmente
Ciclo di vita
G. Bucci
29
UP Unified Process
Modello proposto da chi ha definito
UML
E’ iterativo e incrementale
Ogni iterazione è fatta di:
Requisiti, analisi, progettazione,
implementazione, test
E’ pilotato dai casi d’uso (requisiti)
Ciclo di vita
G. Bucci
30
RUP
This diagram is Copyright 1999-2005 IBM.
http://www.agilemodeling.com/essays/agileModelingRUP.htm
Ciclo di vita
G. Bucci
31
UP
Sostanzialmente ci riferiremo ad esso
W. Zuser, S. Biffl, T. Grechenig, M.
Kohle,, “Ingegneria del software con
UML e Unified process”, McGraw-Hill,
2004
Ciclo di vita
G. Bucci
32
Modelli leggeri/agili
Nati in opposizione (estrema) ai metodi
tradizionali
I metodi tradizionali sono inadeguati
specialmente quando:
i requisiti sono incerti o variabili
si richiede una rapida risposta ai
cambiamenti di mercato
Ciclo di vita
G. Bucci
33
Modelli leggeri/agili
Ogni applicazione pone problemi diversi
E’ irrealistico definire un processo
universalmente valido, senza cadere nei
generici richiami al buon senso
Occorre adattare il processo alle
specifiche esigenze del caso
Le tecnologie moderne aiutano
Ciclo di vita
G. Bucci
34
Modelli leggeri/agili
Il lavoro aggiuntivo per i semilavorati
intermedi risulta in una burocrazia
inutile, che influisce in maniera negativa
su flessibilità e efficienza.
ridurre il lavoro di supporto,
convogliando il massimo dello sforzo
sulla mera produzione dell’applicazione
Ciclo di vita
G. Bucci
35
Manifesto (2001)
http://www.agilealliance.org/
Privilegiare
gli individui e le loro interazioni
rispetto a processi e strumenti
la disponibilità di sw funzionante
rispetto a un’ampia documentazione
la collaborazione col cliente rispetto
alla negoziazione dei contratti
la pronta risposta ai cambiamenti
rispetto all’esecuzione di un piano
Ciclo di vita
G. Bucci
36
..ovvero
Dettagliate specifiche formali,
approfondite analisi e puntigliosa
documentazione sono considerate
attività troppo costose rispetto ai
benefici apportati
limitano la flessibilità del processo che deve
poter modificare i propri obiettivi in ogni
momento.
Ciclo di vita
G. Bucci
37
XP – eXtreme Programming
(l’agile estremo)
Ciclo di vita
G. Bucci
38
What is XP?
XP is a lightweight methodology for small to
medium sized teams developing software in the
face of vague or rapidly changing requirements.
-- Kent Beck.
XP is:
Humane.
Honest.
Productive.
Professional.
Fun.
Ciclo di vita
G. Bucci
39
What is XP?
XP is a discipline of software development.
There are certain things you must do.
You must write tests before code.
You must program in pairs.
You must integrate frequently.
You must be rested.
You must communicate with the customer daily.
You must follow the customer’s priorities.
You must leave the software clean and simple by
the end of the day.
You must adapt the process and practices to your
environment.
Ciclo di vita
G. Bucci
40
eXtreme Programming
Evita la produzione di semilavorati
diversi da quelli necessari alla
realizzazione delle applicazioni
Mira a fornire meccanismi che, in corso
d’opera, danno agli sviluppatori la
consapevolezza che ciò che stanno
costruendo soddisferà pienamente le
esigenze del committente/utente
Ciclo di vita
G. Bucci
41
Attività
Quattro attività fondamentali che si
ripetono per tutto il progetto:
scrittura del codice dell’applicazione
(coding);
verifica delle funzionalità (testing);
osservazione dell’ambiente inteso come
desideri del committente, opportunità
tecnologiche, sviluppi di mercato
(listening);
progetto dell’applicazione (design).
Ciclo di vita
G. Bucci
42
Criteri
I programmatori sono responsabili non
solo della codifica dell’applicazione, ma
anche della sua verifica
L’enfasi è sulla verifica:
Ciclo di vita
Prima di scrivere le istruzioni pensare a come si
testano
nessuna istruzione dovrebbe essere considerata
veramente parte dell’applicazione finché non ne
sia stato verificato l’effetto secondo le attese
G. Bucci
43
What makes XP familiar?
XP matches the behavior of successful
programmers in the wild.
Tests.
Refactoring.
Evolutionary delivery.
Incremental planning.
Low overhead.
Ciclo di vita
G. Bucci
44
Processo
La costruzione dell’applicazione procede
in maniera iterativa
cogliendo le reazioni dei committenti e
riprogettando, in maniera adeguata, le sue
funzionalità e i meccanismi adottati per
ottenerle
Ciclo di vita
G. Bucci
45
Extreme programming
Pianificazione attività (planning the game)
Brevi Iterazioni, Rilasci frequenti (Short releases)
Progetti semplici (simple design)
Integrazione continua (continous integration)
Ristrutturazione del codice (refactoring)
Verifica di ogni funzionalità (testing)
Programmazione a coppie (pair programming)
Proprietà collettiva del codice (collective ownership)
Partecipazione del committente (onsite costumer)
Uso di standard di codifica (coding standards)
Rinuncia la lavoro straordinaro (40 h/w)
Ciclo di vita
G. Bucci
46
Costi con XP
(pretesi)
Sarà vero?
Difficile!
Ciclo di vita
G. Bucci
47
Vantaggi XP
Coinvolgimento del cliente
Attività più gratificante per il programmatore
Riduzione dei costi
Maggior adeguamento al cambiamento in corso
d’opera
Ciclo di vita
G. Bucci
48
Problemi XP
C’è il rischio di cadere nel CODE & FIX
Contrario a ogni pratica ingegneristica
Conta troppo sulla qualità delle persone
Chi fa software non sempre è un genio!!!
Hacker
Cascata
XP
Agili
Adattativi
Pianificati
Pescrittivi
Ciclo di vita
G. Bucci
49
Lavoro individuale
Approfondire il modello XP
andare al sito dell’XP
www.extremeprogramming.org
Visitare il sito
http://www.agilemodeling.com/
Ciclo di vita
G. Bucci
50
Bibliografia
W. Zuser e altri, “Ingegneria del software con UML e
Unified process”, McGraw-Hill, 2004
Kent Beck “Extreme Programming Explained:
Embrace Change”, Addison-Wesley (1999)
www.extremeprogramming.org
B. Boehm, “Get Ready with Agile methods, with
Care”, IEEE Computer Genn. 2002, pp.64-69
Ciclo di vita
G. Bucci
51
Quando la sicurezza è il
requisito principale
Sostanzialmente viene seguito il criterio
del metodo a cascata: analisi e
progettazione accurate sin dall’inizio.
Analisi dei requisiti, analisi del rischio,
tracciabilità dei requisiti, pianificazione,
assicurazione della qualità, versionamento,
..
Ciclo di vita
G. Bucci
52
Sicurezza
Al termine “sicurezza” corrispondono due
termini inglesi: safety e security
Safety: the condition of being safe; freedom
from danger, risk, or injury
Security: something that gives or assures
safety
Si parla spesso di safety integrity level per
indicare la misura della garanzia che un
sistema dà di essere libero da determinati
pericoli.
Ciclo di vita
G. Bucci
53
Dove e come
Sistemi embedded, sistemi medicali,
controllo del traffico aereo, ecc..
Devono garantire affidabilità, sicurezza,
qualità, …
Di norma il processo software è
strutturato come un modello a V (un
adeguamento del modello a cascata)
Normative e standard (di prodotto e di
processo) per i vari settori (ferrovie,
avionica,..)
Ciclo di vita
G. Bucci
54
Modello a V (in generale)
Originally issued as a standard of the German
Federal Administration
The V-Modell is a process model for planning and
executing Projects. The V-Modell improves project
transparency, project management and the
probability of success by defining concrete practices
with associated results and responsible Roles
Describes the development process from a functional
point of view, defining a set of activities and products
(results) that have to be produced.
Publicly available
It has been adopted by many companies and tailored
to a variety of specific application contexts
Ciclo di vita
G. Bucci
55
Modello a V (in generale)
Ciclo di vita
G. Bucci
56
Produzione di sistemi HW/SW
Ciclo di vita
G. Bucci
57
Ciclo di vita
G. Bucci
58
defines User Requirements,
specifying both functional
requirements and non-functional
requirements.
Ciclo di vita
G. Bucci
59
identifies main system units and allocates
User Requirements to each of them.
Ciclo di vita
G. Bucci
60
examines both software and hardware resources of
each unit, decomposing them into software and
hardware components that, according to the notation
of Software Configuration Management, are referred
to as Computer Software Configuration Items
(CSCIs) and Hardware Configuration Items (HCIs).
Ciclo di vita
G. Bucci
61
V Model
In software context
Aimed at regulating the processes of
system development, maintenance and
modification in the software life cycle.
Mentioned within a variety of process
quality standards such as RTCA/DO-178B
and CENELEC 50128
Ciclo di vita
G. Bucci
62
Modello a V (solo SW)
Ciclo di vita
G. Bucci
63
Associaz. standardizzazione
ISO (International Standard Organization)
CEN/CENELEC (Comité européen de normalisation / Comité
européen de normalisation en électronique et en électrotechnique)
ECMA (European Computer Manufacturers Association)
ANSI (American National Standards Institute)
NIST (National Institute of Standards and Technology)
IEEE
UNI (Ente Nazionale Italiano di Unificazione)
DOD, FDA
..e molte altre
Ciclo di vita
G. Bucci
64
Ciclo di vita
G. Bucci
65
Cosa contiene uno standard
Scopo del documento
EN 50128: This Standard concentrates on the methods
which need to be used in order to provide software which
meets the demands for safety integrity which are placed
upon it by …
Definizione dei termini
Identificazione degli attori
Ciclo di vita
Elencazione della documentazione richiesta
Raccomandazioni
Ciclo di vita
G. Bucci
66
ESEMPIO: Normative CEI
EN 50128, 50129
EN 50128 La Normativa specifica le procedure
ed i requisiti tecnici per lo sviluppo del
software nelle applicazioni ferroviarie
EN 50129 Railway applications Communication, signalling and processing
systems - Safety related electronic systems
for signalling
Ciclo di vita
G. Bucci
67
Fail-Safe
I sistemi elettronici per il segnalamento ferroviario
sono critici per la sicurezza.
Devono conformarsi a criteri per il raggiungimento di
Safety Requirements.
Ovvero devono rispondere a seconda delle funzioni
svolte a determinati SIL (Safety Integrity Level)
software safety integrity level: A classification
number which determines the techniques and
measures that have to be applied in order to reduce
residual software faults to an appropriate level
5 livelli : da 0 a 4 (zero praticamente nessun
provvedimento)
Ciclo di vita
G. Bucci
68
EN 50128
Le normative europee CEI EN 50129 e 50128
forniscono dettagli circa i criteri da applicare per i
processi di:
Formazione del personale;
Gestione della sicurezza;
Gestione della qualità;
Specifica dei requisiti del sistema;
Definizione dell’architettura del sistema;
Definizione delle caratteristiche progettuali;
Progettazione;
Valutazione degli effetti dei guasti;
Verifica e validazione
Ciclo di vita
G. Bucci
69
Modello a V di
EN50128
Ciclo di vita
G. Bucci
70