forked from ggiuffre/sweki
-
Notifications
You must be signed in to change notification settings - Fork 3
/
02_processi.html
102 lines (90 loc) · 7.47 KB
/
02_processi.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>Processi software - 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, processi" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="stylesheet" type="text/css" href="main.css" />
<link rel="prev" href="01_intro.html" />
<link rel="next" href="03_ciclovita.html" />
</head>
<body>
<div id="header">
<h1>
<a class="prev" title="prev" href="01_intro.html"><</a>
<a href="index.html"><acronym title="SoftWare Engineering wiKI">sweki</acronym></a>
<a class="next" title="next" href="03_ciclovita.html">></a>
</h1>
<h2>la wiki di Ingegneria del Software</h2>
</div>
<div id="content">
<h1>Processi software</h1>
<h2>Definizione</h2>
<p>In ingegneria, secondo l'<abbr title="International Organitazion for Standardization">ISO</abbr>, un <strong>processo</strong> è un insieme di attività correlate e coese che trasformano ingressi in uscite, consumando risorse nel farlo. In particolare, un processo software (d'ora in avanti solo "processo") porta ad un <em>prodotto</em> software.</p>
<h2>Anatomia</h2>
<p>Ogni processo si divide in più <strong>attività</strong>. Ogni attività si divide in <strong>compiti</strong>. Ogni compito si può svolgere usando qualche tecnica, cioè una sorta di ricetta applicata agli strumenti disponibili. Per strumento s'intende un insieme di concetti e di metodi, con delle tecnologie di supporto.</p>
<h2>Processi software, aziende e progetti</h2>
<p>Distinguiamo le seguenti tre categorie principali di processi:</p>
<ul>
<li>standard di processo — riferimento di base generico usato come stile comune per lo svolgimento delle funzioni aziendali, pensato per una collettività di casi afferenti ad un certo dominio applicativo (quindi una sorta di <span xml:lang="en">template</span>);</li> <!-- "processo standard" o std di processo? forse da process standard, in inglese -->
<li>processo definito — specializzazione dello standard di processo necessaria per adattarlo ad esigenze specifiche di progetto;</li>
<li>processo di progetto — istanza di un processo definito che utilizza risorse aziendali per raggiungere obbiettivi prefissati (il processo viene calato nella realtà aziendale).</li>
</ul>
<p>L'organizzazione aziendale si struttura verticalmente in settori (orientati alla specializzazione) e orizzontalmente in processi (che abbracciano più settori specializzati).</p>
<p>Esiste il processo perfetto? Esiste l'insieme ideale di processi? No: nessun progetto è identico a un altro, quindi i processi vanno selezionati e adattati in modo critico, in base al progetto e/o all'organizzazione a cui servono. Selezionare, adattare, applicare e migliorare (evolvere) i processi è compito degli amministratori di progetto.</p>
<p>I processi software, di per sé, non seguono un ordinamento. Le relazioni temporali tra essi sono fornite da un modello di ciclo di vita.</p>
<h2><abbr title="International Organitazion for Standardization">ISO</abbr>/<abbr title="International Electrotechnical Commission">IEC</abbr> 12207</h2>
<p>Lo standard <abbr title="International Organitazion for Standardization">ISO</abbr>/<abbr title="International Electrotechnical Commission">IEC</abbr> 12207 è il più noto standard di processo. Esso divide i processi in tre famiglie.</p>
<ul>
<li><strong>Processi primari</strong>:
<ul>
<li>acquisizione (gestione dei propri sotto-fornitori<sup class="footnote"><a id="txt1" href="#ftn1">[1]</a></sup>, cioè di chi ci fornisce una componente del nostro prodotto);</li>
<li>fornitura (gestione dei rapporti con il cliente — controparte dell'acquisizione);</li>
<li>sviluppo — affrontato con approccio costruttivo, non correttivo; svolto anche tramite appalto esterno; <em>non</em> solo programmazione (che tra l'altro va affiancata dal <span xml:lang="en">testing</span>)!</li>
<li>gestione operativa (installazione ed erogazione dei prodotti);</li>
<li>manutenzione (correzione, adattamento, evoluzione).</li>
</ul>
</li>
<li><strong>Processi di supporto</strong> (delle specie di "sottoprocedure"):
<ul>
<li>documentazione;</li>
<li>gestione delle versioni e della configurazione;</li>
<li>accertamento della qualità;</li>
<li>qualifica: verifica e validazione ("V&V"), due processi distinti ma collegati;</li>
<li>revisioni congiunte con il cliente;</li>
<li>verifiche ispettive esterne;</li>
<li>risoluzione dei problemi.</li>
</ul>
</li>
<li><strong>Processi organizzativi</strong> (l'"ambiente" del sistema):
<ul>
<li>gestione dei processi;</li>
<li>gestione delle infrastrutture;</li>
<li>miglioramento del processo;</li>
<li>formazione del personale.</li>
</ul>
</li>
</ul>
<p>Un ingegnere del software sa fare qualsiasi processo tra i suddetti.</p>
<h2>Organizzazione di processo</h2>
<p>Per essere disciplinati si ha bisogno di una forma di standardizzazione, per "tenere alta" la qualità di un lavoro ripetitivo che rischia continuamente di degradare. Ecco perché un buon processo si auto-migliora, in modo continuo, secondo lo <strong>schema <abbr title="Plan, Do, Check, Act">PDCA</abbr></strong> (ciclo di Deming):</p>
<ol>
<li><span xml:lang="en">Plan</span>: individuare obiettivi di miglioramento.</li>
<li><span xml:lang="en">Do</span>: eseguire ciò che si è pianificato.</li>
<li><span xml:lang="en">Check</span>: verificare se ha funzionato. Non è tanto un'ispezione quanto, piuttosto, un'analisi<sup class="footnote"><a id="txt2" href="#ftn2">[2]</a></sup>; si studiano i risultati della fase precedente (<span xml:lang="en">do</span>) e li si cofrontano con gli obiettivi individuati nella prima fase (<span xml:lang="en">plan</span>).</li>
<li><span xml:lang="en">Act</span>: agire per correggersi. Se la fase precedente (<span xml:lang="en">check</span>) ha dimostrato che il piano (<span xml:lang="en">plan</span>) implementato (<span xml:lang="en">do</span>) è migliore rispetto agli standard precedenti, allora questo piano diventa il nuovo standard — la nuova <em xml:lang="en">baseline</em>. Altrimenti, il vecchio standard in uso rimarrà la <em xml:lang="en">baseline</em>.</li>
</ol>
<h2>Efficienza ed efficacia di un processo</h2>
<p>Un buon esempio di valutazione dell'efficienza e dell'efficacia è la misurazione di questi due aspetti a livello di processo. Efficienza di un processo, attività o compito è il rapporto tra le <strong>risorse</strong> realmente consumate e quelle che si era previsto venissero consumate; efficacia di un processo, attività o compito è il rapporto tra i <strong>prodotti</strong> realmente ottenuti a partire dal processo e i prodotti che si volevano ottenere.</p>
</div>
<div id="footnotes">
<ol>
<li id="ftn1">Gli acquirenti di software non sono solo utenti "laici" ma anche (e soprattutto) altre case di software: il maggior acquirente di software è Google!</li>
<li id="ftn2">Deming preferiva infatti la sigla <abbr title="Plan, Do Study, Act">PDSA</abbr>: <span xml:lang="en">Plan, Do <em>Study</em>, Act</span>.</li>
</ol>
</div>
</body>
</html>