forked from ggiuffre/sweki
-
Notifications
You must be signed in to change notification settings - Fork 3
/
03_ciclovita.html
102 lines (88 loc) · 9.81 KB
/
03_ciclovita.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="it" lang="it">
<head>
<title>Ciclo di vita - sweki</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="author" content="FIUP" />
<meta name="keywords" content="sweki, ingegneria, software, ciclo, vita" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" type="text/css" href="main.css" />
<link rel="prev" href="02_processi.html" />
<link rel="next" href="04_gestproj.html" />
</head>
<body>
<div id="header">
<h1>
<a class="prev" title="prev" href="02_processi.html"><</a>
<a href="index.html"><acronym title="SoftWare Engineering wiKI">sweki</acronym></a>
<a class="next" title="next" href="04_gestproj.html">></a>
</h1>
<h2>la wiki di Ingegneria del Software</h2>
</div>
<div id="content">
<h1>Ciclo di vita del software</h1>
<h2>Definizione</h2>
<p>Caratteristico di un prodotto di <abbr title="Ingegneria del Software">IS</abbr> è il suo ciclo di vita, cioè l'insieme degli <strong>stati</strong> che il prodotto assume dal concepimento al ritiro<sup class="footnote"><a id="txt1" href="#ftn1">[1]</a></sup>. Senza di esso non esisterebbe la figura dell'ingegnere del software. Conviene vedere il ciclo di vita come una macchina a stati, in cui gli stati sono il grado di maturazione del prodotto e gli archi rappresentano attività (raggruppate in processi) che servono a far avanzare il prodotto nel suo grado di maturazione. La durata temporale entro uno stato del ciclo di vita e un altro è detta <strong>fase</strong>. Misura del successo di un prodotto è un ciclo di vita lungo, speso per lo più in manutenzione, magari con un buon <span xml:lang="en">feedback</span> da parte degli utenti. Distinguiamo tre tipi di manutenzione:</p>
<ul>
<li>correttiva <code>:(</code> per correggere difetti;</li>
<li>di adattamento <code>:|</code> per adattare il sistema a variazioni di requisiti;</li>
<li>evolutiva <code>;)</code> per aggiungere funzionalità al sistema.</li>
</ul>
<p>Esempio di manutenzione evolutiva è Firefox.</p>
<h2>Modelli di ciclo di vita</h2>
<p>I processi software, di per sé, non seguono un ordinamento; le relazioni temporali e logiche tra essi sono fornite da un <strong>modello</strong> di ciclo di vita. Esistono diversi possibili cicli di vita, che si distinguono non per numero o significato degli stati, bensì per le transizioni tra essi e le loro regole di attivazione. Alcuni modelli di ciclo di vita sono:</p>
<ul>
<li>sequenziale — tipo catena di montaggio;</li>
<li>incrementale — realizzazione in più passi, con numero crescente di funzionalità;</li>
<li>evolutivo — con ripetute iterazioni interne;</li>
<li>a spirale — contesto allargato e modello astratto;</li>
<li>agile — dinamico, a cicli iterativi e incrementali.</li>
</ul>
<p>È bene tenere a mente che i vari modelli, per quanto differiscano tra loro in questo o in quel dettaglio, si possono dividere in due grandi famiglie: quelli sequenziali e quelli iterativi; i modelli incrementale, evolutivo, a spirale e agile sono tutti esempi di modelli iterativi. In pratica, possiamo dire che un approccio sequenziale scompone un progetto per <strong>attività</strong>, mentre un approccio iterativo lo scompone per <strong>funzionalità</strong>.</p>
<p>In genere un modello del ciclo di vita di un <em>prodotto</em><sup class="footnote"><a id="txt2" href="#ftn2">[2]</a></sup> include un modello del ciclo di vita dello <em>sviluppo</em><sup class="footnote"><a id="txt3" href="#ftn3">[3]</a></sup> (più eventuali altri processi che riguardano fornitura, manutenzione, evoluzione...). Attenzione: il ciclo di vita dello sviluppo non deve per forza seguire lo stesso modello del ciclo di vita dell'intero prodotto!</p>
<p>Tra le qualità che contraddistinguono l'<abbr title="Ingegneria del Software">IS</abbr> — sistematicità, disciplina, quantificabilità — i modelli di ciclo di vita nascono con l'obiettivo di perseguire la <strong>quantificabilità</strong>, che è la più difficile da soddisfare.</p>
<h2>Il modello sequenziale</h2>
<p>Nel 1970, grazie a Winston Royce, venne ideato il modello sequenziale (o a cascata), ispirato alle catene di montaggio. Questo è una successione di <strong>fasi</strong> rigidamente sequenziali. Il modello originale prevede che non si possa mai essere in due stati diversi allo stesso tempo e che non si possa tornare ad uno stato precedente. Il passaggio da una fase alla successiva è basato sulla documentazione: ogni fase produce documenti che la concretizzano e devono essere approvati per il passaggio alla fase successiva. Nello specifico, ogni fase viene definita in termini di:</p>
<ul>
<li>attività previste;</li>
<li>prodotti attesi in ingresso;</li>
<li>prodotti attesi in uscita;</li>
<li>ruoli coinvolti;</li>
<li>scadenze di consegna.</li>
</ul>
<p>Questo modello ha il pregio di individuare fasi distinte e ordinate nelle quali decomporre il progetto. Suo difetto principale è l'eccessiva <strong>rigidità</strong>. Tuttavia questo approccio può funzionare se il cliente è consapevole (e abbastanza sicuro) di ciò che vuole, pur tenendo conto che il modello genera software vero e proprio molto tardi nel ciclo di vita.</p>
<p>Allora, si pensò di correggere il modello creando un "ibrido", introducendo dei prototipi "usa e getta" oppure la possibilità di tornare ad uno stato precedente. Tuttavia risalire la cascata fa risalire il progetto nel tempo e genera iterazioni, non incrementi.</p>
<h2>Il modello incrementale</h2>
<p>Per superare le difficoltà del modello sequenziale ibrido, nacque il modello incrementale: qui i cicli non sono più iterazioni ma <strong>incrementi</strong>; ogni incremento attraversa tutte le fasi del modello sequenziale, dall'analisi alla verifica (anche se, nella variante <em xml:lang="en">Staged Delivery</em>, l'analisi e la progettazione si affrontano all'inizio e non vengono più ripetute). Il modello prevede rilasci multipli e successivi; ciascuno realizza un incremento di funzionalità, approssimando sempre meglio la soluzione. Un grande vantaggio è che le funzionalità più importanti vengono affrontante all'inizio; così facendo, queste vengono verificate più volte (dato che ogni ciclo prevede la verifica del software). Ogni incremento ha il vantaggio di ridurre il rischio di fallimento.</p>
<p>Questo modello è meno idealista ma più "gentile" del sequenziale, nel senso che sa adattarsi ai cambiamenti. Difatti, mentre il modello sequenziale segue un approccio <strong>predittivo</strong> (cioè basato su piani che devono essere rispettati), il modello incrementale segue un approccio <strong>adattativo</strong>, dove la realtà è considerata inerentemente imprevedibile. Sarebbe preferibile un approccio predittivo, che permette di stimare con precisione una data di consegna e un preventivo; tuttavia l'approccio adattativo può essere conveniente in uno scenario in cui i requisiti cambiano in corso d'opera.</p>
<h2>Il modello evolutivo</h2><!-- DA AMPLIARE -->
<p>Il modello evolutivo, che è incrementale, prevede che gli incrementi successivi siano versioni (prototipi) usabili dal cliente. Più versioni posso essere mantenute in parallelo e ogni fase ammette iterazioni multiple.</p>
<h2>Il modello a spirale</h2>
<p>Nel 1988 Barry Boehm propose il modello a spirale, che introduce il concetto di "rischio di progetto" (cercando di contenere tali rischi). Lo sviluppo procede a cicli inizialmente rapidi ma via via sempre più lenti; difatti i cicli esterni della spirale sono così lenti che possono aderire, ognuno, ad un diverso modello di ciclo di vita. Ad ogni ciclo si analizzano i rischi e si compiono simulazioni. Misura del successo di un progetto è il diametro della spirale. Questo modello viene usato solo da chi intraprende progetti sperimentali, che nessuno ha mai realizzato, e richiede forte interazione tra committente e fornitore. Un ciclo si articola generalmente in quattro momenti:</p>
<ol>
<li>definizione degli obiettivi;</li>
<li>analisi dei rischi;</li>
<li>sviluppo e validazione;</li>
<li>pianificazione della successiva iterazione.</li>
</ol>
<h2>Il modello a componenti</h2>
<p>Più pragmatico è il modello a componenti, che prevede l'integrazione di componenti già implementati. L'idea nasce dal fatto che molto di quel che ci serve fare è già stato fatto e molto di quel che faremo ci potrà servire ancora. Difatti, l'<abbr title="Ingegneria del Software">IS</abbr> è un insieme di <em xml:lang="en">best practices</em> che assembla componenti già esistenti, più che crearle ex novo.</p>
<h2>I metodi agili</h2>
<p>I metodi agili nascono alla fine degli anni '90 come reazione all'eccessiva rigidità dei modelli allora in vigore. Si basano su quattro princìpi:</p>
<ul>
<li><span xml:lang="en">individuals and interactions over processes and tools;</span></li>
<li><span xml:lang="en">working software over comprehensive documentation;</span></li>
<li><span xml:lang="en">customer collaboration over contract negotiation;</span></li>
<li><span xml:lang="en">responding to change over following a plan.</span></li>
</ul>
</div>
<div id="footnotes">
<ol>
<li id="ftn1">Per ritiro s'intende il momento in cui il prodotto cessa di essere seguito dai creatori.</li>
<li id="ftn2"><abbr xml:lang="en" title="Software Product Life Cycle">SPLC</abbr>, <span xml:lang="en">Software Product Life Cycle</span>.</li>
<li id="ftn3"><abbr xml:lang="en" title="Software Development Life Cycle">SDLC</abbr>, <span xml:lang="en">Software Development Life Cycle</span>.</li>
</ol>
</div>
</body>
</html>