forked from ggiuffre/sweki
-
Notifications
You must be signed in to change notification settings - Fork 3
/
04_gestproj.html
105 lines (92 loc) · 8.84 KB
/
04_gestproj.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
<?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>Gestione di progetto - 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, gestione, 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="03_ciclovita.html" />
<link rel="next" href="05_adminproj.html" />
</head>
<body>
<div id="header">
<h1>
<a class="prev" title="prev" href="03_ciclovita.html"><</a>
<a href="index.html"><acronym title="SoftWare Engineering wiKI">sweki</acronym></a>
<a class="next" title="next" href="05_adminproj.html">></a>
</h1>
<h2>la wiki di Ingegneria del Software</h2>
</div>
<div id="content">
<h1>Gestione di progetto</h1>
<h2>Progetto</h2>
<p>Un progetto è un insieme di <strong>compiti</strong> da svolgere a fronte di un <span xml:lang="en">assignement</span>. Alcune <strong>attività</strong> (intese come insiemi di compiti) possono essere svolte individualmente ma il progetto è sempre collaborativo. Tutti i compiti sono pianificati dall'inizio alla fine, secondo specifici obiettivi e vincoli; i vincoli sono dati dal tempo disponibile, le risorse utilizzabili e i risultati attesi.</p>
<h2>Responsabile di progetto</h2>
<p>La gestione di un progetto è compito del <strong>responsabile di progetto</strong><sup class="footnote"><a id="txt1" href="#ftn1">[1]</a></sup> e consiste di:</p>
<ul>
<li>istanziare processi nel progetto;</li>
<li>stimare i costi e le risorse necessarie;</li>
<li>pianificare le attività e assegnarle alle persone;</li>
<li>controllare le attività e verificare i risultati.</li>
</ul>
<h2>Ruoli</h2>
<p>Ogni persona, in un progetto, ha un ruolo (o funzione, in azienda<sup class="footnote"><a id="txt2" href="#ftn2">[2]</a></sup>). Il ruolo può essere di quattro tipi:</p>
<ul>
<li>sviluppo (responsabilità tecnica e realizzativa);</li>
<li>direzione (responsabilità decisionale);</li>
<li>amministrazione (gestione dei processi);</li>
<li>qualità (gestione della qualità).</li>
</ul>
<p>Allocare le risorse per un progetto significa assegnare attività a ruoli e ruoli a persone.</p>
<h2>Profilo professionale</h2>
<p>Ogni persona ha un profilo professionale, cioè un insieme di competenze (tecnologiche e metodologiche) e un'esperienza (espressa in anni e partecipazione a progetti) che fanno da requisiti per l'assunzione di un ruolo in un progetto. Esistono vari profili professionali.</p>
<ul>
<li><strong>Analista</strong> — a partire dal bisogno del cliente, individua il problema (di cui conosce il dominio) da fornire al progettista; solitamente non segue il progetto fino alla fine. In un certo senso, l'analista è la giuntura che collega gli utenti agli sviluppatori.</li>
<li><strong>Progettista</strong> — ha competenze tecniche e tecnologiche<sup class="footnote"><a id="txt3" href="#ftn3">[3]</a></sup> aggiornate e ha vasta esperienza professionale; a partire dalle specifiche del problema fornitogli, sviluppa una soluzione e rimane finché la soluzione non è stata implementata; spesso si assume la responsabilità di gestione del progetto.</li>
<li><strong>Programmatore</strong> — implementa (una parte de) la soluzione del progettista; sta a lungo nel progetto poiché può essere coinvolto nella manutenzione. Ha competenze specifiche; visione e responsabilità circoscritte.</li>
<li><strong>Verificatore</strong> — verifica il lavoro prodotto dai programmatori.</li>
<li><strong>Responsabile di progetto</strong> — pianifica il progetto, assegna le persone ai ruoli giusti e rappresenta il progetto presso il fornitore e il committente.</li>
<li><strong>Amministratore di progetto</strong> — ruolo "orizzontale": deve controllare che ad ogni istante della vita del progetto le risorse (umane, materiali, economiche e strutturali) siano presenti e operanti; inoltre, gestisce la documentazione e controlla il versionamento e la configurazione.</li>
<li><strong>Controllore della qualità</strong> — funzione aziendale (e non ruolo di progetto) che accerta la qualità dei prodotti.</li>
</ul>
<h2>Pianificazione di progetto</h2>
<p>Il ruolo più importante del responsabile di progetto è quello di pianificare. La pianificazione è l'identificazione del da farsi e di come farlo. È bene notare come lo stato di avanzamento di un prodotto sia rilevante solo se dà informazioni sulla pianificazione. Tre strumenti notevoli per la pianificazione di un progetto sono:</p>
<ul>
<li>I diagrammi <abbr title="Work Breakdown Structure">WBS</abbr> (<span xml:lang="en">Work Breakdown Structure</span>) decompongono, in modo gerarchico, le attività in sottoattività; pur essendo fortemente coese, le sottoattività non sono necessariamente sequenziali.</li>
<li>I diagrammi di Gantt sono ideali per rappresentare la durata, la sequenzialità e il parallelismo; si possono confrontare facilmente le stime con i progressi effettivi. Tuttavia, non sono particolarmente adatti per rappresentare le dipendenze tra attività.</li>
<li>I diagrammi <acronym title="Project Evaluation and Review Technique">PERT</acronym> (<span xml:lang="en">Project Evaluation and Review Technique</span>) unificano le due tecniche precedenti e sono ideali per rappresentare le dipendenze temporali (e le criticità<sup class="footnote"><a id="txt4" href="#ftn4">[4]</a></sup>) tra attività e, quindi, per ragionare sulle scadenze del progetto. Un tale diagramma è un grafo orientato dove gli archi rappresentano le attività, mentre i nodi sono degli eventi. Ogni evento ha una data minima a partire da cui può accadere e una data massima oltre la quale esso ritarda gli eventi successivi; la differenza tra questi due tempi è detta <em xml:lang="en">slack time</em><sup class="footnote"><a id="txt5" href="#ftn5">[5]</a></sup>.</li>
</ul>
<p>Il primo passo da fare nel gestire un progetto dovrebbe essere la selezione di un modello di ciclo di vita per lo sviluppo del prodotto.</p>
<h2>Stima dei costi di progetto</h2>
<p>Un'altro compito importante del responsabile di progetto è quello di stimarne i costi. In particolare, il responsabile deve stimare il tempo/persona<sup class="footnote"><a id="txt6" href="#ftn6">[6]</a></sup>, unità di misura delle risorse umane. In questo, utile <em xml:lang="la">caveat</em> è la legge di Parkinson, una critica alla regolamentazione fine a se stessa: <q xml:lang="en">Work expands to fill the time available</q>. Uno strumento per la stima del tempo/persona è <acronym title="Constructive Cost Model">CoCoMo</acronym> (<span xml:lang="en">Constructive Cost Model</span>), una funzione matematica che produce in uscita un valore in tempo/persona e prende in ingresso alcuni parametri relativi al progetto; tale funzione matematica è <var>x = C ⋅ D<sup>S</sup> ⋅ M</var>, dove <var>x</var> è misurato in mesi-persona e i parametri sono:</p>
<ul>
<li>fattore di complessità del progetto <var>C</var>;</li>
<li>misura in <abbr title="Kilo Delivered Source Instructions">KDSI</abbr><sup class="footnote"><a id="txt7" href="#ftn7">[7]</a></sup> della dimensione stimata del prodotto software <var>D</var>;</li>
<li>fattore di complessità <var>S</var>;</li>
<li>moltiplicatori di costo <var>M</var>.</li>
</ul>
<h2>Rischi di progetto</h2>
<p>I risultati di un progetto software possono portare costi eccessivi, non rispettare le scadenze o risultare insoddisfacenti. Un buon metodo per gestire i rischi è il seguente:</p>
<ol>
<li>identificazione dei rischi;</li>
<li>analisi dei rischi (per ordinarli secondo una priorità);</li>
<li>pianificazione di come evitare i rischi;</li>
<li>monitoraggio dei rischi e, eventualmente, ritorno al punto 2 per aggiornare le strategie.</li>
</ol>
</div>
<div id="footnotes">
<ol>
<li id="ftn1"><em>Project manager</em>.</li>
<li id="ftn2">Funzione aziendale, in organizzazioni molto strutturate, con progetti simili; ruolo di progetto, in strutture con ambiti eterogenei.</li>
<li id="ftn3">Mentre <em>tecnica</em> è il modo con cui si usa uno strumento, <em>tecnologia</em> è lo strumento sul quale si opera.</li>
<li id="ftn4">Distanze troppo brevi tra attività dipendenti</li>
<li id="ftn5">Lo <span xml:lang="en">slack time</span> è quindi la quantità di tempo di cui un evento può essere procrastinato senza influenzare l'andamento del progetto.</li>
<li id="ftn6">Generalmente mesi/persona, o anche settimane/persona.</li>
<li id="ftn7"><span xml:lang="en">Kilo Delivered Source Instructions</span>.</li>
</ol>
</div>
</body>
</html>