forked from ggiuffre/sweki
-
Notifications
You must be signed in to change notification settings - Fork 3
/
12_qualifica.html
99 lines (87 loc) · 8.64 KB
/
12_qualifica.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
<?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>Verifica e validazione: introduzione - 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, verifica, validazione, qualifica" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" type="text/css" href="main.css" />
<link rel="prev" href="11_qualprocesso.html" />
<link rel="next" href="13_anstatica.html" />
</head>
<body>
<div id="header">
<h1>
<a class="prev" title="prev" href="11_qualprocesso.html"><</a>
<a href="index.html"><acronym title="SoftWare Engineering wiKI">sweki</acronym></a>
<a class="next" title="next" href="13_anstatica.html">></a>
</h1>
<h2>la wiki di Ingegneria del Software</h2>
</div>
<div id="content">
<h1>Verifica e validazione: introduzione</h1>
<h2>Definizione</h2>
<p>Verifica e validazione sono due processi strettamente correlati. A questa coppia di processi si dà spesso il nome di "<strong>qualifica</strong>" o "V&V". Il loro obiettivo è assicurare la qualità del prodotto durante il suo ciclo di vita.</p>
<p>Questi due processi rispondono a due domande separate:</p>
<ul>
<li>Verifica: <q>Did I build the system right?</q></li>
<li>Validazione: <q>Did I build the right system?</q></li>
</ul>
<p>La <strong>verifica</strong> attiene alla coerenza, completezza e correttezza del prodotto. È un processo che si applica ad ogni "segmento" temporale di un progetto (ad ogni prodotto intermedio) per accertare che le attività svolte in tale segmento non abbiano introdotto errori nel prodotto.</p>
<p>La <strong>validazione</strong>, invece, non si applica ad un particolare segmento temporale ma è una conferma finale, una <em xml:lang="en">self-fulfilling prophecy</em> che accerta la conformità di un prodotto alle attese; essa fornisce una prova oggettiva di come le specifiche del prodotto siano conformi al suo scopo e alle esigenze degli utenti. La validazione, a differenza della verifica, coinvolge sempre il committente.</p>
<h2>Forme di verifica</h2>
<p>La verifica è un processo analitico. Si può fare in due forme:</p>
<ul>
<li>analisi statica (senza eseguire il software);</li>
<li>analisi dinamica (eseguendo il software o una sua parte).</li>
</ul>
<p>L'analisi statica viene fatta prima di quella dinamica: quest'ultima necessita di (una parte di) software eseguibile, mentre l'analisi statica si può applicare già a <em>frammenti</em> di prodotto.</p>
<h2>Test</h2>
<p>L'analisi dinamica viene effettuata tramite prove (<em><strong>test</strong></em>). Un test, per essere utile, dev'essere facilmente ripetibile; per questo, bisogna sempre:</p>
<ul>
<li>tener conto dell'ambiente (non solo dell'input);</li>
<li>specificare le pre-condizioni e i comportamenti attesi;</li>
<li>descrivere le procedure per eseguire il test e per analizzarne i risultati.</li>
</ul>
<p>Per fare ciò, servono tre strumenti:</p>
<ul>
<li>Un <strong>logger</strong>, che scriva l'esito della prova in un file.</li>
<li>Un <strong>driver</strong>, cioè un "pilota" che guidi l'esecuzione del test. Ogni test di unità dev'essere chiamato da qualcuno: costui è il driver.</li>
<li>Uno <strong>stub</strong>, cioè un "calco" che sostituisca del codice non ancora scritto: una componente passiva fittizia che simula una parte del sistema<sup class="footnote"><a id="txt1" href="#ftn1">[1]</a></sup>.</li>
</ul>
<p>Lo stub è quindi il duale del driver: mentre il primo simula le dipendenze della procedura testata (quelle che ne accrescono il <em>fan-out</em>, per capirci), il secondo simula un chiamante di tale procedura (che contribuisce al <em>fan-in</em>).</p>
<h2>Tipi di test</h2>
<p>Distinguiamo quattro tipi di test, a seconda del livello a cui vengono eseguiti nell'architettura:</p>
<ul>
<li>collaudo o test di accettazione (stabilito durante l'analisi del capitolato d'appalto);</li>
<li>test di sistema (stabiliti durante l'analisi dei requisiti);</li>
<li>test di integrazione (stabiliti durante la progettazione logica);</li>
<li>test di unità (stabiliti durante la progettazione di dettaglio).</li>
</ul>
<p>Nell'architettura di un software, l'unità è la più piccola quantità di software che conviene verificare da sola. Un <strong>test di unità</strong> è un'attività di analisi dinamica che verifica la correttezza del codice. Può essere responsabilità del programmatore che ha implementato l'unità<sup class="footnote"><a id="txt2" href="#ftn2">[2]</a></sup>, di un verificatore indipendente oppure (meglio!) di un automa. Questi test vengono svolti con un alto grado di parallelismo (rispecchiando lo stesso parallelismo che caratterizza il lavoro dei programmatori).</p>
<p>I <strong>test di integrazione</strong> servono per verificare il sistema in modo <em>incrementale</em>. Questi test stanno a livello di componente e integrano il funzionamento di più unità.</p>
<p>Il <strong>test di sistema</strong> serve ad accertare la copertura dei requisiti. È un'attività interna all'organizzazione, mentre il <strong>collaudo</strong> è la corrispondente attività esterna (supervisionata dal committente). Al collaudo segue il rilascio del prodotto e la fine della commessa (con eventuale manutenzione).</p>
<p>Infine, esistono anche i <strong>test di regressione</strong>: a seguito di un test andato male e di una relativa correzione, i test di regressione sono l'insieme di test necessari ad accertare he la correzione non causi errori nelle parti del sistema che dipendono da essa. La regressione può essere complicata e dev'essere studiata <em xml:lang="la">ad hoc</em>.</p>
<h2>Forme di analisi statica</h2>
<p>L'analisi statica si applica ad ogni prodotto intermedio (non solo software) per tutti i processi attivi nel progetto. Distinguiamo due tecniche principali per fare analisi statica:</p>
<ul>
<li>Metodi di lettura (<em xml:lang="en">desk check</em>), svolti da un umano che controlla coerenza, completezza e correttezza; impiegati solo per prodotti semplici.</li>
<li>Metodi formali, svolti da macchine.</li>
</ul>
<p>Tra i metodi di lettura, due importanti sono <em xml:lang="en">inspection</em> (cerco cose specifiche) e <em xml:lang="en">walkthrough</em> (attraversamento a pettine: non so cosa cerco ma cerco ovunque), che si completano a vicenda.</p>
<p><strong><em xml:lang="en">Inspection</em></strong> consiste nell'eseguire una lettura mirata, alla ricerca di errori noti. Si basa sull'individuazione di errori presupposti e fa <em xml:lang="en">profiling</em> del prodotto in esame. Si suddivide nelle seguenti attività: pianificazione; definizione di una <em>lista di controllo</em><sup class="footnote"><a id="txt3" href="#ftn3">[3]</a></sup>; lettura; correzione dei difetti. È una tecnica molto più rapida del <em xml:lang="en">walkthrough</em>. In termini statistici, <em xml:lang="en">inspection</em> può generare falsi negativi.</p>
<p><strong><em xml:lang="en">Walkthrough</em></strong>, invece, consiste nell'eseguire una lettura critica del prodotto in esame. È una lettura "a largo spettro", senza l'assunzione di presupposti. Si articola nelle seguenti attività: pianificazione; lettura; discussione; correzione dei difetti. Rispetto all'<em xml:lang="en">inspection</em>, richiede più attenzione. In termini statistici, <em xml:lang="en">walkthrough</em> può generare falsi positivi.</p>
<h2><em xml:lang="en">Quality assurance</em></h2>
<p>Analisi statica e analisi dinamica sono parte dell'attività di <em xml:lang="en">quality assurance</em> (cioè garanzia di qualità). Questa attività è un controllo che non viene fatto dopo ma <em>prima</em> di fare, per assicurare la qualità tempestivamente; viene svolta sui processi con i quali si sviluppa il prodotto (non sul prodotto stesso) ma si basa su un modello di qualità di prodotto (ad esempio <abbr title="International Organitazion for Standardization">ISO</abbr>/<abbr title="International Electrotechnical Commission">IEC</abbr> 9126).</p>
</div>
<div id="footnotes">
<ol>
<li id="ftn1">La parte di sistema simulata dallo stub <strong>non</strong> è oggetto del test in esecuzione.</li>
<li id="ftn2">Per le unità più semplici.</li>
<li id="ftn3">La lista di controllo (o <em xml:lang="en">checklist</em>) evolve nel tempo, in quanto viene continuamente migliorata.</li>
</ol>
</div>
</body>
</html>