PrimaParte 4

Ingegneria del Software
(Ing.Informatica Nuovo Ord.)

Canale M-Z / A.A. 2005-06
Marco Cadoli
Universit di Roma La Sapienza
Dipartimento di Informatica e Sistemistica
www.dis.uniroma1.it/~cadoli
PRIMA PARTE
Il processo di produzione del SW

Sezione IV: Project Management
Versione definitiva
Ing. del SW: Prima parte Sez IV
Marco Cadoli, Universit La Sapienza, nov 2005
PRIMA PARTE
Il processo di produzione del software
I.
II.
III.
IV.
Introduzione, ciclo di vita del SW

Qualit, standard
Test del SW
Project Management
IV. Project management

IV.1. Concetti fondamentali
IV.2. Pianificazione temporale e controllo
IV.3. Gestione delle configurazioni SW
IV.1. Concetti fondamentali

Limportanza del project management
Le quattro P del project management
Persone
Problema
Processo
Progetto
Limportanza di un
Project Management efficace
Lobiettivo di ogni progetto la realizzazione di un
prodotto nel rispetto di vincoli di:
tempi
costi
qualit
Limportanza di un
Project Management efficace (2)
Rischi conseguenti ad un Project Management
inadeguato:
Utili attesi trasformati in perdite (costi eccessivi,
ritardi, penali, immagine)
Ritardata presenza sul mercato
Ritardo sui progetti di R&S con scarsa utilizzazione da
parte delle linee produttive
Scarsi e inefficaci controlli e valutazioni dei progetti
causano lidentificazione di eventuali errori e problemi
troppo tardi rispetto alla possibilit di recupero
Ostacoli al PM
Attivit spesso ostacolata dai Manager e dai tecnici con
cultura organizzativa gerarchica tradizionale e scarsa
cultura di moderne tecniche di gestione
Costi aggiuntivi (5-7 %)
Richiede una comprensione dettagliata del problema
Le quattro P del project management

1.
Persone
2.
motivate / esperte
SEI PM-CMM (People Management Capability Maturity Model)
assunzione / selezione
addestramento / cultura di gruppo
stipendio / carriera
Problema
prima della pianificazione occorre identificare chiaramente:

gli obiettivi
le soluzioni possibili
i vincoli al contorno
ottenendo informazioni di tipo quantitativo
Le quattro P del project management (2)

3. Processo
utilizzando uno dei modelli per il ciclo di vita del software

occorre:
individuare attivit, scadenze, prodotti ed iterazioni,
non trascurare le attivit trasversali, quali, ad esempio, il
controllo qualit, le misure e la gestione delle versioni
4. Progetto
Molti progetti (~20%) non vengono mai terminati

Moltissimi (~40%) subiscono lievitazione dei costi ed
allungamento dei tempi
Persone coinvolte nel progetto

z
z
z
Dirigenti (senior manager)

Capi progetto (project/technical manager)
Tecnici (practitioners)
Elemento del gruppo (team member)
Capogruppo (team leader)
z
z
Cliente (customer)
Utente finale (end user)
La figura del capogruppo cruciale
motivare
organizzare
risolvere i problemi
gestire il personale
10
Il gruppo di sviluppo
Scenario:
Ci sono n persone che lavorano per k anni ad un progetto, assegnate ad m
attivit differenti.
Alcune possibilit di organizzazione:
1. Le attivit sono distinte: poca interazione, no gruppi
2. Nascono informalmente gruppi e capigruppo; nasce la necessit
di coordinamento fra gruppi
3. Le persone vengono divise formalmente in t gruppi, dove ogni
gruppo responsabile di una o pi attivit. Coordinamento:
capigruppo e capoprogetto
La possibilit 3 la migliore.
11
Struttura del gruppo

Possibili strutture interne di un gruppo
DD democratica decentralizzata
assenza di capogruppo fisso (solo temporaneo)
consenso collegiale
comunicazione orizzontale
CD controllata decentralizzata
capogruppo fisso
occasionali responsabili di sottoattivit
risoluzione di problemi per sottogruppi
comunicazione orizzontale e verticale
CA controllata accentrata
comunicazione verticale
la prima struttura formalizzata (1972)
12
Fattori per la scelta della struttura

Fattori che influenzano la scelta della struttura del gruppo
Difficolt del problema
Dimensione del problema (LOC, FP, )
Modularit del problema
Qualit richieste al sistema
Durata temporale del gruppo
Rigidit della data di consegna
13
Scelta della struttura del gruppo

DD
D IF F IC O L T
a lta
b a ssa
D IM . P R O B L E M A
g ra n d e
p ic c o la
M O D U L A R IT
a lta
b a ssa
Q U A L IT
a lta
b a ssa
V IT A G R U P P O
b re v e
lu n g a
SC A D EN ZA
stre tta
la sc a
CD
CA
x
x
x
x
x
x
14
Coordinamento del gruppo

Formale, impersonale
tool per il controllo del progetto (CSCW, )

documentazione (ad es., diagrammi, codice)
prodotti intermedi
scadenze controllate con tabelle dei tempi
Formale, interpersonale
assicurazione qualit
revisioni periodiche
Informale
riunioni
diffusione risultati/scelte
e-mail, forum, videoconferenze
15
Il problema
Scenario tipico: occorre una stima quantitativa il pi presto
possibile ma:
unanalisi dettagliata non ancora disponibile
le specifiche possono cambiare durante il progetto
occorre determinare, almeno, la portata (scope) del progetto
Portata:
Contesto: rapporto del software da sviluppare con il resto del
sistema
Obiettivi informativi: dati di ingresso e di uscita maneggiati
dallutente
Funzionalit e prestazioni: funzionalit da sviluppare e
prestazioni particolari da raggiungere
16
Il problema (2)
Sono molto importanti le informazioni quantitative
numero di utenti
massimo tempo di risposta
spazio richiesto
costi da non superare
Al pi presto, decomporre il problema in un insieme di

compiti (utilizzando, ad es., tecniche di analisi dei requisiti)
17
Il processo
1. Scelta di un modello
A prototipo/spirale, ... In ogni caso induce una sequenza di
attivit
2. Istanziare il problema nel modello scelto
a) Creare una matrice di compiti ed attivit
b) Per ogni cella stimare limpegno necessario
customer
planning
communication
compiti
c1
c2
c3
...
risk
analysis
...
18
Stima dellimpegno
Fattori che rendono difficile effettuare una stima attendibile:
complessit del progetto (assoluta e relativa alle esperienze
precedenti)
dimensione del progetto
mancanza di esperienze (e misure) pregresse
informazioni inattendibili o non ufficiali
19
Linee guida per ottenere una stima

Acquisire le informazioni principali (scope) e decomporle in
funzioni principali
prestazioni e vincoli sono essenziali ai fini di una corretta
valutazione
Individuare le risorse necessarie
Persone (capacit + numero)
Componenti riusabili (spesso trascurati)
componenti disponibili (prodotti internamente o da
acquistare)!
componenti simili da modificare (su cui si ha esperienza)!
componenti simili da modificare (su cui non si ha
esperienza)?
HW e SW da utilizzare per lo sviluppo del progetto
20
Stima del costo e dellimpegno

Metodi per la stima del tempo uomo necessario
LOC
FP
Analisi del processo di produzione del software
Modelli empirici COCOMO / equazione del software [Putnam & Myers 92]
Equazione del SW (statistiche su 4000 progetti)
E=(LOC*B0.333/P)3* (1/t4)
E = impegno (mesi uomo / anni uomo)
t = durata del progetto (mesi / anni)
B = fattore di competenza (0.16...0.39 ) (5 KLOC ... 70 KLOC)
P = parametro di produttivit (2000 ... 28.000 ) - Spesso calcolato su dati storici
complessit dellapplicazione
esperienza dei programmatori
linguaggio di programmazione
altro...
21
Il progetto
Monitoraggio del progetto (quanto manca ?)

regola del 90-90
Motivi:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Incomprensione esigenze clienti

Portata mal definita
Gestione inappropriata modifiche
Cambiamento tecnologie
Funzionalit mal definite
Date consegna irrealistiche
Ostilit clienti
Perdita risorse finanziarie
Incompetenza team
Management non mette in pratica lezioni apprese
22
Approccio vincente
Lavorare duramente allinizio, costruendo i team giusti

Mantenere alta lattenzione, non lasciare che le persone se ne vadano
Verificare i progressi
Evitare i rischi (ad es., utilizzare componenti disponibili sul mercato,
allocare pi tempo alle fasi rischiose)
Condurre analisi post-mortem, per il futuro; chiedere le opinioni
altrui, trascriverle
23
Domande chiave
Why. Perch si sviluppa il progetto?

What. Cosa verr eseguito, ed entro quando?
Who. Chi il responsabile di una funzione?
Where. Dove sono le responsabilit?
How. In quale modo verr eseguito il lavoro?
How much. Quante risorse sono necessarie?
24
IV.2. Pianificazione temporale
Fattori causanti ritardi

Persone & tempo
Scelta del grado di rigore
Scelta e raffinamento attivit principali
Rete di attivit
25
Fattori che rendono probabile

finire in ritardo
scadenza imposta dallalto
cambiamento delle specifiche che non si riflette in un cambiamento
della programmazione
mancata valutazione dei rischi
errato calcolo dellimpegno necessario
difficolt (sia tecniche sia umane) impreviste
comunicazione insufficiente/errata fra il personale
incapacit di accorgersi del ritardo del progetto e mancanza di
adeguate azioni correttive
26
Principi di pianificazione temporale

Pianificazione temporale = scheduling
Ripartizione: definire compiti ed attivit
Interdipendenza: comprendere le relazioni fra attivit
Assegnazione della durata, della data di inizio e di fine di ogni
attivit. Esistono unit appropriate (anno/uomo, mese/uomo)
Validazione: essere sicuri che le risorse siano disponibili
Responsabilit definite: assegnare persone ai compiti
Risultati definiti: ogni attivit ha un output
Punti di controllo (milestones) definiti: revisioni per la qualit
27
Persone e tempo
La relazione intercorrente tra persone e tempo non lineare
coordinamento
comunicazione
Esempio:
ogni programmatore pu produrre 5000 LOC/anno lavorando da
solo
se due programmatori devono interagire fra loro, la loro
produttivit complessiva diminuisce di 250 LOC/anno ( 9.750)
qual la produttivit di un team di quattro programmatori che
devono tutti interagire fra di loro?
Risposta: ci sono sei canali di comunicazione (3 + 2 + 1), quindi si
perdono 250*6=1500 LOC/anno. La produttivit del team di
18.500 LOC/anno (7,5% in meno)
28
Persone e tempo (2)

Anche le formule empiriche (equazione del SW) confermano che
allungando il tempo di sviluppo il carico di lavoro complessivo
diminuisce
E=(LOC*B0.333/P)3* (1/t4)
Il prodotto E*t4 costante
Esempio:
1. t = 1,3 anni;
E = 12 anni/uomo
2. t = 1,75 anni;
E = 3,7 anni/uomo
29
Persone e tempo (3)
Distribuzione del carico di lavoro (regola 40 - 20 - 40)

40 % analisi
20 % codifica
40 % test
In realt la regola solo indicativa (vedi tabelle COCOMO per i vari
tipi di progetto)
30
Programmi, progetti e compiti

Programma: iniziativa a lungo termine, che pu comprendere
pi di un progetto
Progetto: sforzo complesso, durata limitata (< 3 anni) che
comprende compiti interrelati eseguiti da diverse
organizzazioni con obiettivi, schedulazioni e budget ben
definiti
Compito (task): sforzo a breve termine (3 6 mesi) eseguito
da unorganizzazione, che insieme ad altri compiti costituisce
un progetto
Work package: insieme di task correlati tra di loro
31
Scelta del grado di rigore

Tipi di progetto
Innovativo/di ricerca
Sviluppo di nuova applicazione
Miglioramento di una applicazione
Manutenzione di una applicazione
Ristrutturazione (reengineering) di una applicazione
esistente (legacy)
32
Scelta del grado di rigore (2)

Grado di rigore
Informale:
insieme minimo di compiti, poca documentazione
Strutturato:
tutte le attivit portanti ed ausiliarie
Rigoroso:
inoltre, ricca documentazione
Reazione veloce (intervento rapido):
solo in emergenza; solo compiti essenziali (dopo la
consegna, si compila la documentazione completa)
33

Criteri per la scelta (adaptation criteria)
dimensione del progetto

numero potenziale di utenti
criticit della applicazione
vita dellapplicazione
stabilit dei requisiti
facilit di comunicazione con il committente
maturit della tecnologia utilizzata
vincoli sulle prestazioni
altro...
34

A ciascun criterio si assegna un valore 1..5
Eventuale revisione del valore, tramite un peso (compreso
fra 0.8 e 1.2)
Inclusione o meno del criterio pesato a seconda del tipo di
progetto (moltiplicatore: 0 o 1)
Calcolo della media (TSS = task set selector)
< 1.2 informale
1 ... 3.0 strutturato
> 2.4 rigoroso
35

dim.
progetto
num.
utenti
criticita'
applic.
vita
appl.
stabilita'
requisiti
facilita'
comunic.
...
grado peso
(1..5)
1.2
app.
nuova
ricerca app.
0
1
migl. manut. reengin totale

app. app.
.
1
1
1
1.1
1.1
0.9
1.2
0.9
...
...
...
...
...
...
...
36
Scelta delle attivit principali
Individuare la portata del progetto (project scoping)

Pianificazione preliminare
Valutazione del rischio tecnologico
Prova dellidea
Implementazione
Reazione del cliente
37
Piano di progetto
Project plan
Breve documento che
descrive la portata (scope) del progetto
definisce i rischi
definisce il costo e la pianificazione
fornisce un quadro di riferimento globale
evidenzia come la qualit del prodotto viene garantita
38
Modello a spirale e tipi di progetto

1)Definizione
del progetto
(com. utente)
2) Planning
3) Risk analysis
ricerca
nuova app.
miglioramento
manutenzione
reengineering
4) Ingegnerizzazione
6) valutazione
da parte del cliente
5) Realizzazione
39
Raffinamento delle attivit principali

Esempio: Individuare la portata del progetto (project scoping)
1.1 identificare i bisogni dellutente, i benefici e i clienti potenziali
1.2 definire le attivit di input/output che controllano lapplicazione
1.2.1 Revisione formale della descrizione dei bisogni
1.2.2 produrre una lista degli input/output visibili allutente
1.2.3 revisione formale degli input/output con lutente
1.3 definire le funzionalit ed il comportamento per ogni funzione principale
1.3.1 revisione formale degli input/output e degli oggetti visibili allutente prodotti
dallattivit 1.2
1.3.2 produrre un modello del comportamento delle funzioni
1.2.3 revisione formale del comportamento con lutente
1.4 individuare gli elementi tecnologici coinvolti nel progetto

1.5 ricercare componenti SW esistenti
1.6 definire la fattibilit tecnica
1.7 stimare rapidamente la dimensione del progetto
40
Esempio di
Project Breakdown Structure
(PBS)
Fonte: Russel D. Archibald Project Management

Ed. Franco Angeli
41
Rete di attivit
Costruire un grafo che evidenzi:
la sequenza delle attivit
le possibili parallelizzazioni
I.3a
I.1
I.2
I.3b
I.4
I.3c
La notazione pi usata sono i diagrammi PERT (Program Evaluation
and Review Technique) ideati negli anni 50 dalla Lockheed per gestire
il progetto Polaris.
42
Rete di attivit (2)

Un nodo rappresenta una attivit con il relativo tempo previsto
(eventualmente una terna di valori: pessimo, verosimile ed ottimo)
Un arco rappresenta una dipendenza tra le attivit
possibile individuare:
Il cammino critico (catena di attivit che determina la durata del
progetto) CPM
Il maggior anticipo possibile nelliniziare unattivit
Il maggior ritardo possibile per unattivit che non ritarda il
completamento di un progetto
Esistono molti strumenti sw per il calcolo automatico di tali informazioni

43
Diagrammi temporali
Dopo aver decomposto il progetto in task prefissati utile
costruire un diagramma temporale delle attivit detto
GANTT (da Henry Gantt: ingegnere meccanico ed esperto di
management, 1861-1919)
m1
fine analisi
analisi
m2
fine codifica
d1
studio
fattibilit
codifica1
d2
codifica2
d3
codifica3
d4
d5
int. e test
0
6m
12m
18
44
Diagrammi temporali (2)

Le barre orizzontali indicano la durata dei compiti
Le barre orizzontali si possono sovrapporre: indica potenziale
parallelismo
Il GANTT riporta anche le milestone
Un GANTT va integrato con un PERT per avere tutte le
informazioni relative alle interdipendenze tra task
Molti strumenti CASE per il project management prevedono
luso di PERT e di GANTT a vari livelli di sofisticazione
45
Controllo della pianificazione

Controllo della pianificazione = project tracking
Pert e GANTT possono essere usati per monitorare lavanzamento
del progetto
meeting periodici con i gruppi di lavoro per verificare lo stato di
avanzamento
valutazione delle revisioni formali condotte
verifica delleffettivo raggiungimento delle milestone
inizio effettivo delle attivit rispetto allinizio previsto
meeting informali per individuare i possibili problemi
46
Riassunto dei principi base per la

pianificazione
Scegliere un modello per il ciclo di vita del SW
Dividere il progetto in macro attivit usando sia la decomposizione del
problema che del processo Insieme di work package (WP) strutturati
in attivit
Definire i prodotti di ogni attivit (deliverable)
Strutturare le attivit da svolgere in singoli componenti (WBS, Work
Breakdown Structure, o PBS, Project Breakdown Structure)
Individuare le interdipendenze tra le attivit (trasversali ai WP)
Definire un calendario di progetto (Phase Activity Definition)
Definire limpegno del personale (Personnel Plan)
Individuare le responsabilit!!
47
Riassunto dei principi base per la

pianificazione (2)
Controllare che la pianificazione non richieda mai un impegno
complessivo superiore a quello massimo disponibile!
Definizione del metodo di monitoraggio del progetto
Controllo dellutilizzo del personale
Controllo globale delle spese
Evidenziazione del rapporto tra i costi e raggiungimento degli
obiettivi
Controllo globale del progetto
48
IV.3. Gestione delle configurazioni
Concetti fondamentali
Esempio
Processo di gestione delle configurazioni
CVS
49
Concetti fondamentali
In qualsiasi punto del ciclo di vita ci si trovi, il sistema

cambier, ed il desiderio di cambiarlo persister per tutto il
ciclo di vita.
Gestione delle configurazioni: principi e tecniche per

individuare, organizzare, controllare le modifiche al software in
corso di realizzazione:
1. Riconoscere il cambiamento
2. Controllarlo
3. Garantire la corretta implementazione
4. Avvertire gli interessati
50
Concetti fondamentali (2)
Gestione delle configurazioni SW = Software configuration

management
Gestione delle configurazioni:
Inizia con il progetto
Termina quando il prodotto SW non pi operativo
Manutenzione:
Inizia quando il prodotto SW viene rilasciato al cliente e
messo in esercizio
51
Tipi di cambiamenti
Cambiamenti:
nelle strategie aziendali o nelle condizioni di mercato
nei requisiti tecnici
nei requisiti utente
Si riflettono in cambiamenti:
nella pianificazione del progetto

nei modelli concettuali
nel codice
nei test
nella struttura delle basi di dati
nella documentazione
52
Esempio (1)
Lapplicazione da progettare riguarda le informazioni
sulle contravvenzioni elevate in un comune.
Di ogni vigile interessa il nome, il cognome ed il
numero di matricola
Di ogni contravvenzione interessa
Di ogni veicolo interessa
Il comune vuole effettuare dei controlli sul lavoro del
proprio personale:
dato un vigile, si vuole sapere se ha elevato una
contravvenzione per pi di una volta ad uno stesso
veicolo;

53
Esempio (2)
Progettazione/Test
1. Schema concettuale (diagrammi UML delle classi e
degli use case, specifiche)
2. Interfacce dei moduli SW
3. Codice Java
4. Casi di test
54
Esempio (3)
Schema concettuale
+-----------+
+-----------------+
+------------------+
| Veicolo
| relativa
| Contravvenzione |
| Vigile
|
|===========|-------------|=================| effettua |==================|
| targa:str |1..1
0..*| verbale : intero|------------| nome:stringa
|
+-----------+
| luogo : stringa |0..*
1..1| cognome:stringa |
^
+-----------------+
| matricola:stringa|
/ \ {disj, compl}
+------------------+
/___\
+-------------------+
|
|
+-----------+
+-------------+
| Autoveic |
| Motociclo
|
|===========|
|=============|
| pot: int |
| telaio: str |
+-----------+
+-------------+
55
Codice Java
Esempio (4)
// File Vigile.java
public class Vigile {
private final String nome, cognome, matricola;
private InsiemeSS contravvenzioni;
public Vigile(String n, String c, String m) {
...
}
// File ControlloPersonale.java
public class ControlloPersonale {
public static boolean tartassatore(Vigile vig) {
...
}
56
Esempio (5)
Casi di Test (ad es., black box)
Progettazione classi di equivalenza per la funzione
Java tartassatore:
Criterio del numero di valori, analisi dei valori estremi:
a) Vigile che non ha mai multato veicoli
b) Vigile che ha multato uno stesso veicolo al pi una volta
c) Vigile che ha multato uno stesso veicolo due volte
- Altri criteri (ad es., altri a scatola nera o scatola

bianca)
Progettazione casi di test
a)
b)
c)
57
Cambiamento (1)
Lapplicazione da progettare riguarda le informazioni
sulle contravvenzioni elevate in un comune.
Di ogni vigile interessa il nome, il cognome ed il
numero di matricola, la data di nascita
Di ogni contravvenzione interessa
Di ogni veicolo interessa
Il comune vuole effettuare dei controlli sul lavoro del
proprio personale:
dato un vigile, si vuole sapere se ha elevato una
contravvenzione per pi di (una volta) due volte ad
uno stesso veicolo;
58
Cambiamento (2)
Il cambiamento nei requisiti si riflette in:
1. Cambiamento dello schema concettuale:
1. Il diagramma UML delle classi non pi appropriato
2. La specifica dello use case non pi appropriata
Cambiamento delle interfacce dei moduli SW:

La API della classe Java Vigile non pi appropriata
59
Cambiamento (3)
Il cambiamento nei requisiti si riflette anche in:
3. Cambiamento del codice Java
1. Vanno aggiunti costruttori e getter nella classe Java Vigile
2. Va riprogettato lalgoritmo del tartassatore;
3. Va ri-implementata la funzione Java
boolean tartassatore(Vigile)
4. Cambiamento dei casi di test

1. Vanno riprogettate le classi di equivalenza
2. Vanno riprogettati i casi di test
3. Vanno rieseguiti i casi di test
60
Necessit di procedure formali

Un elemento della configurazione SW (SCI, software
configuration item), ovvero:
una specifica
un modulo SW
un insieme di casi di test

che
sia stato revisionato ed accettato,
serva da fondamento per un ulteriore sviluppo,
pu essere modificato solamente attraverso procedure formali di
controllo del cambiamento
61
Archivio di un progetto
Detto anche project repository
Contiene tutti gli SCI, tipicamente in tutte le versioni
Pu contenere anche prodotti SW per lo sviluppo
(compilatori, strumenti CASE) nella versione
autorizzata per il progetto
Tipicamente, si lavora su copie degli SCI contenuti
nellarchivio
Sono previsti precisi protocolli per linserimento
nellarchivio
62
Processo di gestione delle configurazioni

Identificazione (delle molte versioni esistenti)
Controllo della versione e dei cambiamenti
(modifiche prima e dopo il rilascio al cliente)
Responsabilit dellapprovazione delle modifiche e
della definizione delle priorit
Assicurazione che le modifiche siano state eseguite
correttamente
Notifica agli interessati dellesecuzione delle
modifiche
63
Individuazione degli SCI

Deve esistere uno schema concettuale degli SCI
{disjoint,complete}
Test
Specifica
Progettazione
implementazione
Modulo SW
collaudo
64
Individuazione degli SCI (2)

Ogni SCI deve avere un nome, che comprende la versione
Deve essere gestito un grafo delle trasformazioni degli SCI
V 1.0
V 1.1
V 1.1.1
V 1.3
V 1.4
V 2.0
V 2.1
V 1.2
V 1.1.2
65
Controllo delle versioni

Tre coordinate indipendenti:
Componente (pu essere presente o no)
Versione (ne nasce una nuova quando una o pi
componenti subiscono cambiamenti rilevanti
Variante (coesiste con altre)
66
Controllo del cambiamento
Si rileva necessit di un cambiamento

Arriva una richiesta di cambiamento dallutente
Valutazione da parte dello sviluppatore
Viene scritto un ordine di cambiamento (ECO- Engineering
change order)
Lautorit del controllo dei cambiamenti (CCA) decide
Se la richiesta non accolta, lutente viene informato
Se la richiesta accolta, si mette la richiesta in coda
Vengono assegnate persone allo SCI
Si estrae lo SCI dallarchivio di progetto (check-out)
Controllo degli accessi
Si effettua il cambiamento
(continua )
67
Controllo del cambiamento (2)

Si revisiona il cambiamento (ad es., tramite ispezione)
Se si tratta di codice, si riprogettano quando necessario i casi di
test (ad es., mediante il metodo delle basi scatola bianca)
Si effettuano i test
Si inserisce la nuova versione dello SCI nellarchivio (check-in)
Sincronizzazione
Si propone linclusione dello SCI nella release successiva
Si costruisce la nuova versione
Si revisiona il cambiamento (ad es., tramite test di sistema)
Il cambiamento diventa effettivo nella nuova versione
68
Controllo del cambiamento (3)

Necessit di
Controllo degli accessi
Diritti di lettura/scrittura
Sincronizzazione
Meccanismi di locking/unlocking
Impediscono modifiche
non autorizzate,
potenzialmente distruttive
inutili
69
Esame della configurazione

La modifica specificata nellECO stata effettuata?
stata svolta una revisione tecnica formale?
Gli standard (ad esempio per quanto riguarda il test)
sono stati applicati?
La modifica stata evidenziata nello SCI (autore, data,
)?
Gli interessati sono stati avvertiti?
Sono stati aggiornati tutti gli SCI correlati?
70
CVS: concurrent version system

Sistema di controllo delle versioni, disponibile su varie
piattaforme (UNIX, Linux, Windows, Macintosh, )
Open source (www.cvshome.org,
www.tortoisecvs.org, )
Fornisce accesso controllato ai file
Mantiene la storia dei cambiamenti
Un direttorio pubblico, posto su un server, contiene tutti i
file di un progetto strutturato in vari sottodirettori (ad es.,
per sorgenti, documentazione, casi di test, ) in tutte le
versioni
71
CVS (2)
sempre possibile sapere chi ha effettuato un
cambiamento, quando lo ha effettuato e perch
possibile ritornare ad una versione precedente (undo
o rollback). Ci utile nel caso di errori)
Ogni cliente accede al direttorio pubblico tramite un
protocollo stabilito (ad es., telnet, ssh, ) localmente,
o tramite Internet, a seconda della configurazione del
server
72
Comandi principali di CVS

Principali comandi a disposizione di un progettista
(che lavora su un client CVS):
checkout: scaricamento dal server in un direttorio
nel proprio spazio di lavoro (ad es., cartella
Windows sul proprio PC):
di tutto un progetto, o
di una sua parte,
possibile scaricare una versione qualsiasi fra
quelle presenti nel server
73
Comandi principali di CVS (2)

commit: (check-in) aggiornamento del
server (di un progetto o di una sua parte).
Viene creata sul sever una nuova versione, a

partire dai file presenti sul proprio spazio di
lavoro.
possibile registrare in forma testuale i
cambiamenti apportati e le relative motivazioni
74
Comandi principali di CVS (3)

update: verifica della consistenza (di un progetto o di una sua
parte) fra la versione locale e quella del server.
utile per sapere se si verificata una situazione di questo tipo:
client1> cvs checkout MyProject/MyFile.java
client2> cvs checkout MyProject/MyFile.java
client2> modifica di MyProject/MyFile.java
client2> cvs commit MyProject/MyFile.java
A questo punto client1 non ha pi una versione di
MyProject/MyFile.java coerente con quella del server.
client1> cvs update MyProject/MyFile.java
informa se la versione locale e quella del server differiscono
75
Gestione dei conflitti in CVS

Se, a valle della sequenza di eventi precedenti, avvengono anche i
seguenti eventi
client1> modifica di MyProject/MyFile.java
client1> cvs commit MyProject/MyFile.java
La versione sul server di MyProject/MyFile.java verr
aggiornata:
fondendo (merge) i cambiamenti, se effettuati su linee diverse del
file
evidenziando le inconsistenze, se i cambiamenti sono sulla stessa
linea del file. In tal caso il progettista deve risolvere autonomamente
i conflitti
76
Direttorio
di servizio
Un esempio di GUI per CVS
File non
modificato
dallultimo
commit
File
modificato
dallultimo
commit
File non
presente sul
server
File aggiunto
temporaneamente (solo add
senza commit ) al server
77

PrimaParte 4

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

PrimaParte 4

Caricato da

Copyright:

Formati disponibili

Ingegneria del Software

(Ing.Informatica Nuovo Ord.)

Il processo di produzione del SW

Marco Cadoli, Universit La Sapienza, nov 2005

Introduzione, ciclo di vita del SW

Ing. del SW: Prima parte Sez IV

Marco Cadoli, Universit La Sapienza, nov 2005

IV. Project management

Ing. del SW: Prima parte Sez IV

Marco Cadoli, Universit La Sapienza, nov 2005

IV.1. Concetti fondamentali

Ing. del SW: Prima parte Sez IV

Marco Cadoli, Universit La Sapienza, nov 2005

Ing. del SW: Prima parte Sez IV

Marco Cadoli, Universit La Sapienza, nov 2005

Marco Cadoli, Universit La Sapienza, nov 2005

Ing. del SW: Prima parte Sez IV

Marco Cadoli, Universit La Sapienza, nov 2005

Le quattro P del project management

prima della pianificazione occorre identificare chiaramente:

Ing. del SW: Prima parte Sez IV

Marco Cadoli, Universit La Sapienza, nov 2005

Le quattro P del project management (2)

utilizzando uno dei modelli per il ciclo di vita del software

Molti progetti (~20%) non vengono mai terminati

Ing. del SW: Prima parte Sez IV

Marco Cadoli, Universit La Sapienza, nov 2005

Persone coinvolte nel progetto

Dirigenti (senior manager)

La figura del capogruppo cruciale

Ing. del SW: Prima parte Sez IV

Marco Cadoli, Universit La Sapienza, nov 2005

Marco Cadoli, Universit La Sapienza, nov 2005

Struttura del gruppo

Ing. del SW: Prima parte Sez IV

Marco Cadoli, Universit La Sapienza, nov 2005

Fattori per la scelta della struttura

Ing. del SW: Prima parte Sez IV

Marco Cadoli, Universit La Sapienza, nov 2005

Scelta della struttura del gruppo

Marco Cadoli, Universit La Sapienza, nov 2005

Coordinamento del gruppo

tool per il controllo del progetto (CSCW, )

Ing. del SW: Prima parte Sez IV

Marco Cadoli, Universit La Sapienza, nov 2005

Marco Cadoli, Universit La Sapienza, nov 2005

Al pi presto, decomporre il problema in un insieme di

Ing. del SW: Prima parte Sez IV

Marco Cadoli, Universit La Sapienza, nov 2005

Ing. del SW: Prima parte Sez IV

Marco Cadoli, Universit La Sapienza, nov 2005

Ing. del SW: Prima parte Sez IV

Marco Cadoli, Universit La Sapienza, nov 2005

Linee guida per ottenere una stima

Marco Cadoli, Universit La Sapienza, nov 2005

Stima del costo e dellimpegno

Equazione del SW (statistiche su 4000 progetti)

Marco Cadoli, Universit La Sapienza, nov 2005

Monitoraggio del progetto (quanto manca ?)

Incomprensione esigenze clienti

Ing. del SW: Prima parte Sez IV

Marco Cadoli, Universit La Sapienza, nov 2005

Lavorare duramente allinizio, costruendo i team giusti