3. PROJECT MANAGEMENT
 Gli obiettivi di questa lezione sono:
 Introdurre caratteristiche e problematiche della
direzione di progetto software (project
management)
 Discutere la pianificazione di un progetto e la
temporizzazione (scheduling)
 Presentare rappresentazioni grafiche della
pianificazione di un progetto
Software project management
 Sono le attività necessarie per assicurare che
un prodotto software sia sviluppato


rispettando le scadenze fissate
rispondendo a determinati standard
 Interazione di aspetti economici e tecnici
 Un progetto diretto bene qualche volta
fallisce, uno diretto male fallisce sicuramente
 L’importanza dell’esperienza
Che cos’è un progetto…
 Un progetto è un insieme ben definito di attività
che
 ha un inizio
 ha una fine
 realizza un obiettivo
 è realizzato da un’equipe di persone
 utilizza un certo insieme di risorse
 non è riconducibile a “routine”
Problemi
 Il prodotto software è “intangibile”: per
valutare i progressi ci si deve basare sulla
documentazione
 L’ingegneria del software non è ancora
riconosciuta come disciplina “solida”al pari
dell’ingegneria meccanica, elettrica,
 Non ci sono standard per il processo di
produzione software
 Ogni progetto ha una storia a sé (problemi di
scheduling)
I giocatori in campo...
 Business managers
 definiscono i termini economici del progetto
 Project managers
 pianificano, motivano, organizzano e controllano
lo sviluppo
 Practitioners
 hanno le competenze tecniche per realizzare il
sistema
 Customers
 specificano i requisiti del software da sviluppare
 End users
 interagiscono con il sistema una volta realizzato
Perché c’è bisogno di un team?
 La maggior parte dei progetti software sono
troppo impegnativi per essere realizzati da una
sola persona
The mythical man/month
 Perché non calcolare la “forza lavoro” in termini di mesi
uomo necessari?
 Persone/mese * Tempo allocato =
Numero_Persone_Necessarie
 Alcuni compiti possono essere
condivisi, altri no
Esempio: raccogliere fragole vs.
produrre un bambino
 overhead necessario per il
coordinamento e la
comunicazione
Tipologie di team (1)
 Democratico Decentralizzato
 Assenza di un leader permanente
 Consenso di gruppo sulle soluzioni e
sulla organizzazione del lavoro
 Comunicazione orizzontale

Vantaggi



Attitudine positiva a ricercare presto gli errori
Funziona bene per problemi “difficili” (ad
esempio per la ricerca)
Svantaggi


È difficile da imporre…
Non è scalabile...
Tipologie di team (2)
 Controllato Decentralizzato
 Un leader riconosciuto, che coordina il lavoro
 La risoluzione dei problemi è di gruppo, ma
l’implementazione delle soluzioni è assegnata a
sottogruppi da parte del leader
 Comunicazione orizzontale nei sottogruppi e verticale
con il leader
Tipologie di team (3)
 Controllato Centralizzato
 Il team leader decide sulle soluzioni e
sull’organizzazione
 Comunicazione verticale tra team leader e gli altri
membri
Ruoli in un team Controllato
Decentralizzato
 Project Manager
 pianifica, coordina e supervisiona le attività del team
 Technical staff
 conduce l’analisi e lo sviluppo (da 2 a 5 persone)
 Backup engineer
 supporta il project manager ed è responsabile della
validazione
 Software librarian
 mantiene e controlla la documentazione, i listati del codice, i
dati...
spazio condiviso & risultati condivisi

Un team deve prima di tutto
decidere gli strumenti che
permettono la cooperazione

La pianificazione
Chi fa cosa
Le scelte fatte
Cosa è stato fatto



Le attività del project manager
 Stesura della proposta di progetto
 Stima del costo del progetto
 Pianificazione (planning) e temporizzazione
(scheduling)
 Monitoraggio e revisioni del progetto
 Selezione e valutazione del personale
 Stesura di rapporti e presentazioni
Stimare i costi di un progetto
 Dilaziona la stima fino a quando il progetto non è in
stato avanzato di sviluppo
- modello non praticabile: la stima dev’essere fatta all’inizio
 Basa la stima su progetti simili già sviluppati
- similarità di problemi, clienti, ecc.
 Usa tecniche di decomposizione per generare stime
di costo e di risorse necessarie
- approccio “divide et impera”, calcolando il costo delle
componenti
 Usa uno o più modelli empirici
- basati su dati storici, es. COnstructive COst MOdel (Boehm,
1981)
Stime quantitative: LOC
 KLOC = Migliaia di linee di codice
 Metriche:
 $ per KLOC
 errori o difetti per KLOC
 LOC per mese/persona
 pagine di documentazione per KLOC
 errori/mese-persona
 $/pagina di documentazione
 Il codice è il prodotto tangibile del processo di
sviluppo, ed esiste già letteratura in proposito
 Dipende dal linguaggio di programmazione e penalizza
programmi scritti bene e concisi
Stime quantitative (dimensionali)
aspetti critici delle metriche dimensionali
1. Difficile stimare la dimensione in LOC
2. Non tiene conto diversa complessità e potenza
delle istruzioni (di uno stesso linguaggio o di
linguaggi diversi)
3. Difficile definire in modo preciso il criterio di
conteggio (istruzioni spezzate su più righe, più
istruzioni su una riga...)
4. Più produttività potrebbe portare a più codice
senza qualità?
Stime funzionali: FP
 Function Points (punti funzione)
 misurare le funzionalità offerte
dall’applicazione, a partire da:
 il dominio informativo
 da un giudizio sulla complessità del
software
Parametri
 Numero di input
 informazioni distinte fornite dall’utente e utilizzate dal
programma come dati di ingresso
 Numero di output
 informazioni distinte ritornate all’utente come risultato delle
proprie elaborazioni
 Numero di richieste
 numero di interrogazioni in linea che producono una risposta
immediata del sistema
 Numero di files
 file creati ed utilizzati internamente dal programma
 Numero di interfacce esterne
 files o di altri insiemi di dati scambiati con altri programmi
Function Points
Indici
Valore
Pesi
Sempl. Medio Compl. Vi
N. input
3
4
6
N. Output
4
5
7
N. Richieste
3
4
6
N. File
7
10
15
N. Int. Est.
5
7
10
FP =
S Vi x [0.65 + 0.01 x S Fi]
Fattori di influenza
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Il sistema richiede procedure di recovery e backup affidabili?
È richiesta la trasmissione di dati?
Vi sono funzionalità che richiedono elaborazioni distribuite?
Le prestazioni sono critiche?
Funzionerà in un sistema già carico?
Richieste funzionalità avanzate per input e lettura in linea dei dati?
Input dei dati mediante tramite interfacce a finestre?
Archivi principali aggiornati in tempo reale?
Informazioni complesse scambiate tra utente e programma?
Codice complesso?
Scritto per essere riusabile?
Il progetto include anche le attività di istallazione e conversione?
Programma progettato per essere istallato presso diversi utenti?
Programma progettato per facilitare uso e modifiche da parte
dell'utente?
LOC/FP
Linguaggio di programmazione
LOC/FP media
Assembler
C
Fortran
Cobol
Pascal
Ada
linguaggi orientati agli oggetti
fogli di calcolo (spreadsheets)
linguaggi grafici
320
128
105
105
90
70
30
6
4
Struttura del piano di progetto
1. Introduzione
2. Organizzazione del Progetto
3. Descrizione dei Processi Gestionali
4. Derscrizione dei Processi Tecnici
5. Pianificazione del lavoro, delle risorse umane e del
budget.
1. Introduzione
1.1 Overview del Progetto

Descrizione di massima del progetto e del prodotto.
1.2 Deliverables del Progetto

Tutti gli items che saranno consegnati, con data e luogo di
consegna
1.3 Evoluzione del Progetto

Piani per cambiamenti ipotizzabili e non
1.4 Materiale di riferimento

Lista dei documenti cui ci si riferisce nel Piano di Progetto
1.5 Definizioni e Abbreviazioni
2. Organizzazione del progetto
2.1 Modello del Processo

Relazioni tra le varie fasi del processo
2.2 Struttura Organizzativa

Gestione interna, chart dell’organizzazione
2.3 Interfacce Organizzative

Relazioni con altre entità
2.4 Responsabilità di Progetto



Principali funzioni e attività;
Di che natura sono?
Chi ne è il responsabile ?
3. Processi gestionali
3.1 Obiettivi e Priorità
3.2 Assunzioni, Dipendenze, Vincoli

Fattori esterni
3.3 Gestione dei rischi

Identificazione, Valutazione, Monitoraggio dei rischi
3.4 Meccanismi di monitoraggio e di controllo

Meccanismi di reporting, format, flussi di informazione, revisioni
3.5 Pianificazione dello staff

Skill necessari (cosa?, quanto?, quando?)
4. Processi tecnici
4.1 Metodi, Strumenti e Tecniche


Sistemi di calcolo, metodi di sviluppo, struttura del team, ecc.
Standards, linee guida, politiche.
4.2 Documentazione del Software

Piano di documentazione, che deve includere milestones, e
revisioni
4.3 Funzionalità di supporto al progetto


Pianificazione della qualità
Pianificazione della gestione delle configurazioni
5. Pianificazione del lavoro, delle
risorse umane e del budget.
5.1 Work Packages (Work breakdown structure)

Il progetto è scomposto in tasks; definizione di ciascun task
5.2 Dipendenze

Relazioni di precedenza tra funzioni, attività e task
5.3 Risorse Necessarie

Stima delle risorse necessarie, in termini di personale, di tempo di
computazione, di hardware particolare, di supporto software ecc.
5.4 Allocazione del Budget e delle Risorse

Associa ad ogni funzione, attività o task il costo relativo
5.5 Pianificazione

Deadlines e Milestones
Gestione dei rischi (punto 3.3)
 Identificazione dei rischi
 legati alla taglia del prodotto da costruire o modificare
 legati ai vincoli importi dal mercato o dal contratto
 legati alle caratteristiche del cliente
 legati alla buona definizione del processo
 legati all’ambiente di sviluppo (qualità e affidabilità degli
strumenti)
 legati alla complessità del sistema da costruire e alle novità
tecnologiche legate al sistema
 legati alla dimensione e all’esperienza del team di sviluppo
 Sviluppare una tabella: probabilità e impatto
 Strategia di gestione: evitare/monitorare/gestire
Fattori di fallimento
 Requisiti incompleti
 Mancato coinvolgimento del cliente
 Mancanza di risorse
 Aspettative non realistiche
 Mancanza di supporto esecutivo
 Cambiamenti dei requisiti
13.1%
12.4%
10.6%
9.9%
9.3%
8.7%
Fattori di successo
 Coinvolgimento del cliente
 Supporto della direzione esecutiva
 Definizione chiara dei requisiti
 Pianificazione corretta
 Aspettative realistiche
 Personale competente
15.9%
13.9%
13.0%
9.6%
8.2%
7.2%
Pianificazione del lavoro (5.2)
f1:Function
p:Project
f2:Function
a1:Activity
a2.1:Activity
t1:Task
a2:Activity
a2.2:Activity
t2:Task
t3:Task
a3:Activity
a2.3:Activity
t4:Task
Attività
f1:Function
p:Project
f2:Function
a1:Activity
a2.1:Activity
t1:Task
a2:Activity
a2.2:Activity
t2:Task
t3:Task
Unità principali di
lavoro, con date di
consegna precise
Scomponibili in una
serie di tasks
Culminano in una
milestone
Organizzazione delle attività
 In un progetto le attività devono essere organizzate
in modo da produrre risultati valutabili dal
management
 Milestones sono i punti finali di ogni singola attività di
processo
 Deliverables sono i risultati che sono forniti al
committente
 Il modello a cascata suggerisce una definizione ovvia
di “milestone”
Milestones & deliverables
ACT IVITIES
Feasibility
study
Requir ements
analysis
Prototype
development
Design
study
Requir ements
specification
Feasibility
report
Requir ements
definition
Evaluation
report
Architectural
design
Requir ements
specification
MILESTONES
Funzioni
 Attività o insiemi di attività che coprono tutta la durata del
progetto





Project management
Configuration Management
Documentation
Quality Control (Verifica e validazione)
Training
Tasks
 Unità di lavoro “atomiche”
 Hanno durata stimabile, necessitano di certe risorse,
producono risultati tangibili (documentazione, codice,
...)
 Specifica di un task: Work package
 Nome e descrizione del lavoro che deve essere fatto
 Precondizioni per poter avviare il lavoro, durata, risorse
necessarie
 Risultato del lavoro e criteri di accettabilità
 Rischi
Scheduling di progetto
 Dividi il progetto in attività e mansioni (tasks) e stima
il tempo e le risorse necessarie per completare ogni
singola mansione
 Organizza le mansioni in modo concorrente, per
ottimizzare la forza lavoro
 Minimizza la dipendenza tra le singole mansioni per
evitare ritardi dovuti all’attesa del completamento di
un’altra mansione
 Sono necessari intuito ed esperienza
Processo di scheduling del progetto
Identify
activities
Software
requirements
Identify activity
dependencies
Estimate resources
for activities
Allocate people
to activities
Create project
charts
Activity charts
and bar charts
Problemi nello scheduling
 E’ difficile stimare la difficoltà dei problemi ed
il costo di sviluppo di una soluzione
 La produttività non è proporzionale al numero
di persone che lavorano su una singola
mansione
 Aggiungere personale in un progetto in
ritardo può aumentare ancora di più il ritardo
 Imprevisti succedono sempre...
Grafo delle attività (PERT),
grafico a barre e diagramma di Gannt
 Diversi tipi di rappresentazione grafica dello




scheduling del progetto
Mostrano la suddivisione del lavoro in mansioni. Le
mansioni non devono essere troppo piccole (una
settimana o due di lavoro)
Il grafo delle attività (PERT) evidenzia le dipendenze
e il cammino critico
Il grafico a barre mostra lo scheduling come
calendario lavori
Il diagramma di Gannt esprime la temporizzazione
Network delle attività
T-2
2 days
T-3
1 days
T-5
5 days
T-1
5 days
T-7
3 days
T-4
7 days
T-6
2 days
Diagramma di PERT
 ES: earliest start time:
 il minimo giorno di inizio dell’attività, a partire dal
minimo tempo necessario per le attività che precedono
 EF: earliest finish time:
 dato ES e la durata dell’attività, il minimo giorno in cui
l’attività può terninare
 LF: latest finish time:
 qual è il giorno massimo in cui quel job deve finire
senza che si crei ritardo per i jobs che dipendono da lui
 LS: latest start time:
 dato LF e la durata del job, qual è il giorno massimo in
cui quel job deve iniziare senza provocare ritardo per i
job che dipendono da lui
Cammino critico
T-2
2 days
T-3
1 days
T-5
5 days
5
7
7
8
12
17
9
11
11
12
12
17
T-1
5 days
T-7
3 days
0
5
17
20
0
5
17
20
T-4
7 days
5
12
5
12
T-6
2 days
12
14
15 17
Mansioni: durata e dipendenze
Mansioni
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
Durata (giorni)
8
15
15
10
10
5
20
25
15
15
7
10
Dipendenze
T1
T2, T4
T1, T2
T1
T4
T3, T6
T5, T7
T9
T11
Network delle attività
15 days
14/7/94
M1
8 days
T9
T1
25/7/94
4/7/94
start
15 days
T3
5 days
4/8/94
25/8/94
T6
M4
M6
M3
7 days
20 days
15 days
T7
T2
25/7/94
10 days
M2
T4
T11
10 days
M7
T5
5/9/94
11/8/94
T10
18/7/94
M8
15 days
10 days
T12
M5
25 days
T8
Finish
19/9/94
Diagramma di Gannt
4 /7
11 /7
1 8/7
2 5/7
1 /8
8 /8
1 5/8
2 2/8
2 9/8
5 /9
1 2/9
1 9/9
St art
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T 11
M8
T12
Fini sh
Allocazione della forza lavoro
4/7
Fred
11/7
18/7
25/
1/8
8/8
15/8 22/8
29/8
5/9
T4
T8
T11
T12
Jane
T1
T3
T9
Anne
T2
T6
Jim
M ary
T7
T5
T10
12/9
19/9
Pianificazione collaborativa
Riferimenti
 Software Project Managenment Technology Report, STSC
Technical Report, 2000
http://www.stsc.hill.af.mil/index.asp
 A. Alessandroni, “La stima dei costi dei sistemi informativi
automatizzati”, AIPA, http://www.aipa.it
 B. Boehm e altri, “Cost Models for Future Software Life
Cycle Processes: CoCoMo II”, Centre for Software
Engineering, http://sunset.usc.edu/
 Standish Group, “The CHAOS Report”,
http://www.pm2go.com/sample_research/index.asp