-
Notifications
You must be signed in to change notification settings - Fork 5
/
09_projdidattico.html
151 lines (137 loc) · 8.81 KB
/
09_projdidattico.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
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
<?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>Progetto didattico - sweki</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="author" content="Giorgio Giuffrè" />
<meta name="keywords" content="sweki, ingegneria, software, progetto" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" type="text/css" href="main.css" />
<link rel="prev" href="08_documentazione.html" />
<link rel="next" href="10_qualsoftware.html" />
</head>
<body>
<div id="header">
<h1>
<a class="prev" title="prev" href="08_documentazione.html"><</a>
<a href="index.html"><acronym title="SoftWare Engineering wiKI">sweki</acronym></a>
<a class="next" title="next" href="10_qualsoftware.html">></a>
</h1>
<h2>la <span xml:lang="en">wiki</span> di Ingegneria del <span xml:lang="en">Software</span></h2>
</div>
<div id="content">
<h1>Progetto didattico</h1>
<h2>Motivazioni</h2>
<p>Un corso di Ingegneria del <span xml:lang="en">Software</span> sarebbe incompleto senza un progetto didattico: è bene che lo studente si scontri in prima persona con un progetto di gruppo che rispecchi la logica di relazione "cliente-fornitore". Nello specifico, le principali entità del progetto didattico sono:</p>
<ul>
<li>Il cliente o <strong>committente</strong>, cioè chi ha commissionato il prodotto; generalmente è un'azienda o una <span xml:lang="en">startup</span>, che pubblica un capitolato d'appalto in cui viene spiegato qual è il prodotto da realizzare.</li>
<li>Il <strong>fornitore</strong>, cioè chi si impegna a fornire il prodotto richiesto dal committente; è un gruppo di sei o sette studenti che scelgono di rispondere ad un particolare capitolato d'appalto. Il gruppo è un'entità coesa provvista di nome, logo e <span xml:lang="en">e-mail</span> per le comunicazioni ufficiali.</li>
<li>Il docente, che nel nostro caso funge da <strong>proponente</strong>; il docente verifica e valuta<sup class="footnote"><a id="txt1" href="#ftn1">[1]</a></sup> l'andamento dei vari progetti.</li>
</ul>
<h2>Revisioni di avanzamento</h2>
<p>Il progetto si estende nell'arco di uno o due semestri. Il docente potrebbe scegliere tra due approcci: l'approccio "chiavi in mano" (i gruppi sono lasciati liberi e il docente torna il giorno della consegna del prodotto); l'approccio per revisioni (più interattivo). L'approccio adottato è il secondo, molto più didattico. Quindi la principale modalità d'interazione tra gruppi e docente sono le <strong>revisioni di avanzamento</strong>, che sono quattro:</p>
<ol>
<li>Revisione dei Requisiti (RR);</li>
<li>Revisione di Progettazione (RP);</li>
<li>Revisione di Qualifica (RQ);</li>
<li>Revisione di Accettazione (RA).</li>
</ol>
<p>È importante notare che la logica sequenziale delle revisioni di avanzamento non implica che il modello di sviluppo scelto dai gruppi debba essere anch'esso sequenziale<sup class="footnote"><a id="txt2" href="#ftn2">[2]</a></sup>!</p>
<p>Ricordiamo che <abbr title="International Organitazion for Standardization">ISO</abbr>/<abbr title="International Electrotechnical Commission">IEC</abbr> 12207 prevede due diversi tipi di processi di revisione: l'<span xml:lang="it">audit process</span> e il <span xml:lang="it">joint review process</span>. Alla prima classe appartengono le due revisioni esterne con effetto bloccante: RR e RA; alla seconda classe appartengono le due revisioni interne con valenza informativa: RP e RQ.</p>
<h2>Documentazione</h2>
<p>Tutto il progetto va documentato. In particolare, il fornitore deve documentare: le sue strategie di efficienza ed efficacia, nei documenti di strategia; le regole per attuare tali strategie, nelle Norme di Progetto. I documenti di strategia, che servono sia al fornitore sia al committente, sono:</p>
<ul>
<li>Il <strong>Piano di Progetto</strong>, che tratta delle strategie che il gruppo sceglie di adottare per essere efficiente; esso presenta l'organigramma dettagliato del fornitore, lo schema proposto per l'assegnazione e la rotazione dei ruoli di progetto, l'impegno complessivo previsto per ogni ruolo e per ogni individuo, e il conto economico preventivo di realizzazione del prodotto.</li>
<li>Il <strong>Piano di Qualifica</strong>, che tratta dell'efficacia e garantisce che le attese verranno rispettate; esso illustra la strategia complessiva di verifica e validazione proposta dal fornitore.</li>
</ul>
<p>Invece, le <strong>Norme di Progetto</strong> interessano solo il fornitore (e il docente) ma non il committente; esse servono a fissare il <span xml:lang="en">way of working</span>.</p>
<p>In generale, i principali documenti del progetto didattico sono:</p>
<ul>
<li>Documenti gestionali:
<ul>
<li>Studio di Fattibilità;</li>
<li>Norme di Progetto;</li>
<li>Piano di Progetto;</li>
<li>Piano di Qualifica.</li>
</ul>
</li>
<li>Documenti tecnici:
<ul>
<li>Analisi dei Requisiti;</li>
<li>Specifica Tecnica;</li>
<li>Definizione di Prodotto;</li>
<li>Manuale Utente.</li>
</ul>
</li>
</ul>
<p>Possiamo suddividere i documenti anche tra interni (al gruppo) ed esterni. Documenti interni sono:</p>
<ul>
<li>Studio di Fattibilità;</li>
<li>Norme di Progetto.</li>
</ul>
<p>Documenti esterni sono:</p>
<ul>
<li>Piano di Progetto;</li>
<li>Piano di Qualifica;</li>
<li>Analisi dei Requisiti;</li>
<li>Specifica Tecnica;</li>
<li>Definizione di Prodotto;</li>
<li>Manuale Utente.</li>
</ul>
<h2>Revisione dei Requisiti</h2>
<p>Questa revisione ha la funzione di concordare con il cliente una visione condivisa del prodotto atteso. Tale visione è documentata nel documento di Analisi dei Requisiti, che studia i requisiti e i casi d'uso del prodotto da realizzare. I documenti valutati sono:</p>
<ul>
<li>Studio di Fattibilità;</li>
<li>Norme di Progetto;</li>
<li>Piano di Progetto;</li>
<li>Piano di Qualifica;</li>
<li><strong>Analisi dei Requisiti</strong>.</li>
</ul>
<h2>Revisione di Progettazione</h2>
<p>Questa revisione può avvenire in una (sola) delle seguenti modalità:</p>
<ol>
<li>Revisione di Progettazione <em>minima</em>;</li>
<li>Revisione di Progettazione <em>massima</em>.</li>
</ol>
<p>La RP minima riguarda l'architettura del sistema <em>ad alto livello</em>; essa ha la funzione di accertare la realizzabilità del prodotto. I documenti valutati sono:</p>
<ul>
<li>Norme di Progetto;</li>
<li>Piano di Progetto;</li>
<li>Piano di Qualifica;</li>
<li><strong>Specifica Tecnica</strong>.</li>
</ul>
<p>La RP massima riguarda l'architettura <em>di dettaglio</em> del sistema; essa ha la funzione di accordarsi sulle caratteristiche del prodotto da realizzare. I documenti valutati sono:</p>
<ul>
<li>Norme di Progetto;</li>
<li>Piano di Progetto;</li>
<li>Piano di Qualifica;</li>
<li><strong>Definizione di Prodotto</strong>.</li>
</ul>
<h2>Revisione di Qualifica</h2>
<p>Questa revisione ha la funzione di approvare l'esito finale delle verifiche e attivare quindi la validazione. I documenti valutati sono:</p>
<ul>
<li>Norme di Progetto;</li>
<li>Piano di Progetto;</li>
<li>Piano di Qualifica;</li>
<li>Definizione di Prodotto;</li>
<li>versione preliminare del Manuale Utente.</li>
</ul>
<h2>Revisione di Accettazione</h2>
<p>Questa revisione ha la funzione di collaudare il sistema e di accertare il soddisfacimento di tutti i requisiti utente stabiliti nell'Analisi dei Requisiti. I documenti valutati sono le versioni definitive di:</p>
<ul>
<li>Piano di Progetto;</li>
<li>Piano di Qualifica;</li>
<li>Manuale Utente.</li>
</ul>
<h2>Ore di lavoro</h2>
<p>Le ore di lavoro si contano solo <em>dopo</em> la valutazione della RR; fino a quel momento, il tempo speso è tempo d'investimento non rendicontato (eventualmente registrato, ma non rendicontato). Le ore totali impiegate a progetto da ciascuna persona sono circa 25-30 ore di lavoro; a questo proposito, è bene notare come l'efficienza è proporzionale al rapporto tra ore di lavoro e ore effettive. L'impegno totale di ore rendicontabili presentate a consuntivo da ogni componente di un gruppo dovrà situarsi fra un minimo di 85 e un massimo di 105 ore produttive. Le ore rendicontabili non includono le attività di auto-formazione.</p>
</div>
<div id="footnotes">
<ol>
<li id="ftn1">Nota bene: il docente valuta i documenti e il prodotto, <em>non</em> il codice; questo può essere guardato ma non viene valutato.</li>
<li id="ftn2">Anzi, il modello di sviluppo più gettonato dai gruppi è quello incrementale, non quello sequenziale.</li>
</ol>
</div>
</body>
</html>