-
Notifications
You must be signed in to change notification settings - Fork 5
/
05_adminproj.html
101 lines (89 loc) · 8.53 KB
/
05_adminproj.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
<?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>Amministrazione di progetto - 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, amministrazione, 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="04_gestproj.html" />
<link rel="next" href="06_ingreqq.html" />
</head>
<body>
<div id="header">
<h1>
<a class="prev" title="prev" href="04_gestproj.html"><</a>
<a href="index.html"><acronym title="SoftWare Engineering wiKI">sweki</acronym></a>
<a class="next" title="next" href="06_ingreqq.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>Amministrazione di progetto</h1>
<h2>Amministratore di progetto</h2>
<p>Scopo dell'amministrare un progetto è quello di evitare conflitti che si manifestano quando ci sono sovrapposizioni di ruoli e di responsabilità. L'amministratore di un progetto<sup class="footnote"><a id="txt1" href="#ftn1">[1]</a></sup> non dirige (non compie scelte gestionali) ma deve far sì che l'<strong>infrastruttura</strong> di lavoro sia operante; attua le scelte tecnologiche concordate con i responsabili aziendali e di progetto e si assicura che vengano seguite dai membri del progetto.</p>
<h2>Documentazione di progetto</h2>
<p>Uno dei compiti dell'amministratore di progetto è quello di gestire la documentazione. I documenti devono essere chiaramente identificati, corretti nei contenuti, verificati, approvati, aggiornati (specificandone la data) e dotati di versione. La loro diffusione dev'essere controllata: i destinatari devono essere chiaramente identificati e ogni documento ha una sua lista di distribuzione (oppure è pubblico). La documentazione raccoglie <strong>tutto ciò che documenta le attività</strong> e si divide nelle seguenti due categorie.</p>
<ul>
<li>Documentazione di sviluppo:
<ul>
<li>documentazione fornita dal cliente;</li>
<li>diagrammi di progettazione;</li>
<li>codice;</li>
<li>piani di qualifica e risultati delle prove;</li>
<li>documentazione di accompagnamento del progetto.</li>
</ul>
</li>
<li>Documentazione di gestione del progetto:
<ul>
<li>documenti contrattuali;</li>
<li>piani e consuntivi delle attività;</li>
<li>piani di qualità.</li>
</ul>
</li>
</ul>
<p>Ogni documento contiene un "diario delle modifiche", in cui vengono riportate tutte le modifiche rispetto alla versione precedente del documento. Lo stile del diario delle modifiche dev'essere molto sintetico e, a questo scopo, è bene che si avvalga di riferimenti numerici all'interno del testo (numero della sezione modificata, ad esempio).</p>
<h2>Ambiente di lavoro</h2>
<p>L'amministratore di progetto si occupa dell'ambiente di lavoro, cioè l'insieme di persone, di ruoli, di procedure e l'infrastruttura<sup class="footnote"><a id="txt2" href="#ftn2">[2]</a></sup> la cui qualità determina la produttività del progetto. L'ambiente di lavoro dev'essere:</p>
<ul>
<li>completo (offre tutto il necessario per svolgere le attività previste);</li>
<li>ordinato (è facile trovare ciò che vi si cerca);</li>
<li>aggiornato (il materiale obsoleto non deve causare intralcio).</li>
</ul>
<h2>Configurazione e versionamento di un prodotto</h2>
<p>Oltre all'aspetto temporale (cioè il ciclo di vita), ogni prodotto ha anche un aspetto più "spaziale", in quanto si compone di parti. Quali esse sono e il modo in cui stanno assieme è detto "configurazione". E ogni sistema composto di parti va gestito con:</p>
<ul>
<li>controllo di configurazione;</li>
<li>controllo di versione (versione non del prodotto ma di ogni <em>parte</em> della configurazione del prodotto).</li>
</ul>
<p>Data la complessità di un prodotto <span xml:lang="en">software</span>, la gestione della configurazione va automatizzata con strumenti adatti. Ogni parte della configurazione (<span xml:lang="en">configuration item</span>, <abbr title="Configuration Item">CI</abbr>) dev'essere univocamente identificato (oltre ad avere nome, data, autore, registro delle modifiche e stato corrente). Due concetti centrali della gestione di configurazione sono i seguenti.</p>
<ul>
<li>Quello di <strong><em xml:lang="en">baseline</em></strong> indica un punto d'arrivo tecnico dal quale non si retrocede; la <em xml:lang="en">baseline</em> è fatta di elementi della configurazione e, poiché ogni parte è versionata, possiamo conoscere la differenza tra una <em xml:lang="en">baseline</em> e l'altra. Una <em xml:lang="en">baseline</em> è qualcosa di stabile — non usa e getta! — e sta in un <span xml:lang="en">repository</span><sup class="footnote"><a id="txt3" href="#ftn3">[3]</a></sup>; serve da base per gli avanzamenti futuri e può essere cambiata solo tramite procedure di controllo di cambiamento.</li>
<li>Il concetto di <strong xml:lang="en">milestone</strong> indica un punto nel tempo associato ad un valore strategico. Ogni <span xml:lang="en">milestone</span> di calendario è associata a uno specifico insieme di <em xml:lang="en">baseline</em>. Ogni <span xml:lang="en">milestone</span> dev'essere: specifica, raggiungibile, misurabile (per quantità d'impegno necessario), traducibile in compiti assegnabili e dimostrabile agli <em xml:lang="en">stakeholder</em><sup class="footnote"><a id="txt4" href="#ftn4">[4]</a></sup>.</li>
</ul>
<p>Anche il controllo di versione fa affidamento sul <span xml:lang="en">repository</span>, per permettere di lavorare su vecchi e nuovi <abbr title="Configuration Item">CI</abbr> senza rischio di sovrascritture accidentali, di condividere il lavorato nello spazio comune e di poter verificare la bontà di ogni modifica di <em xml:lang="en">baseline</em>. Ogni versione è una istanza di prodotto funzionalmente distinta dalle altre. Invece, si dice "variante" una istanza di prodotto funzionalmente identica ad altre ma diversa per caratteristiche non funzionali. Infine, si dice "rilascio" (<em xml:lang="en">release</em>) una istanza di prodotto resa disponibile a utenti esterni.</p>
<h2>Modifiche</h2>
<p>Anche nel corso del suo sviluppo, un progetto non è esente da richieste di modifiche (dagli utenti, dagli sviluppatori o semplicemente per competizione). Le richieste di modifica vanno sottoposte a un rigoroso processo di analisi, decisione, realizzazione e verifica; di ogni richiesta va tenuta traccia.</p>
<h2>Norme di progetto</h2>
<p>Un progetto necessita di linee guida per le attività di sviluppo. Le norme — che vanno accertate dagli amministratori — comprendono:</p>
<ul>
<li>organizzazione e uso delle risorse di sviluppo;</li>
<li>convenzioni sull'uso degli strumenti di sviluppo;</li>
<li>organizzazione della comunicazione e della cooperazione;</li>
<li>norme di codifica;</li>
<li>gestione dei cambiamenti.</li>
</ul>
<p>Le norme di progetto descrivono come dovrà essere il <strong><em xml:lang="en">way of working</em></strong>. Individuiamo due categorie di norme: regole (sottoposte a verifica) e raccomandazioni (suggerimenti, senza verifica). Tra le norme di progetto, particolare rilevanza hanno le norme di codifica; queste hanno l'obiettivo di far sì che il codice sorgente sia leggibile (anche a distanza di tempo) e costituiscono una misura preventiva che garantisce verificabilità, manutenibilità e portabilità.</p>
</div>
<div id="footnotes">
<ol>
<li id="ftn1"><span xml:lang="en">Project administrator</span>, da non confondere con il <span xml:lang="en">project manager</span>: il primo è sottoposto al secondo.</li>
<li id="ftn2">Tutte le risorse <span xml:lang="en">hardware</span> e <span xml:lang="en">software</span> del progetto.</li>
<li id="ftn3">Base di dati centralizzata nella quale risiedono (individualmente) tutti i <abbr title="Configuration Item">CI</abbr> di ogni <em xml:lang="en">baseline</em> nella loro storia completa.</li>
<li id="ftn4">Uno <span xml:lang="en">stakeholder</span> è una persona a vario titolo coinvolta nel ciclo di vita di un <span xml:lang="en">software</span>, che ha influenza sul prodotto o sul processo.</li>
</ol>
</div>
</body>
</html>