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
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
Software project management
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”
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)
Problemi
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 noEsempio: 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
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
Le attività del project manager
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 LOC2. 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
FP = Vi x [0.65 + 0.01 x Fi]
Indici Valore 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
Pesi
Fattori di influenza1. Il sistema richiede procedure di recovery e backup affidabili?2. È richiesta la trasmissione di dati?3. Vi sono funzionalità che richiedono elaborazioni distribuite?4. Le prestazioni sono critiche?5. Funzionerà in un sistema già carico?6. Richieste funzionalità avanzate per input e lettura in linea dei dati?7. Input dei dati mediante tramite interfacce a finestre?8. Archivi principali aggiornati in tempo reale?9. Informazioni complesse scambiate tra utente e programma?10. Codice complesso?11. Scritto per essere riusabile?12. Il progetto include anche le attività di istallazione e conversione?13. Programma progettato per essere istallato presso diversi utenti?14. Programma progettato per facilitare uso e modifiche da parte
dell'utente?
LOC/FP
Linguaggio di programmazione LOC/FP media
Assembler 320C 128Fortran 105Cobol 105Pascal 90Ada 70linguaggi orientati agli oggetti 30fogli di calcolo (spreadsheets) 6linguaggi grafici 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 13.1% Mancato coinvolgimento del cliente 12.4% Mancanza di risorse 10.6% Aspettative non realistiche 9.9% Mancanza di supporto esecutivo 9.3% Cambiamenti dei requisiti 8.7%
Fattori di successo
Coinvolgimento del cliente 15.9% Supporto della direzione esecutiva 13.9% Definizione chiara dei requisiti 13.0% Pianificazione corretta 9.6% Aspettative realistiche 8.2% Personale competente 7.2%
Pianificazione del lavoro (5.2)
p:Project
f1:Function
f2:Function
a1:Activity a2:Activity a3:Activity
a2.1:Activity a2.2:Activity a2.3:Activity
t1:Task t2:Task t3:Task t4:Task
Unità principali di lavoro, con date di consegna precise
Culminano in una milestone
Scomponibili in una serie di tasks
p:Project
f1:Function
f2:Function
a1:Activity a2:Activity
a2.1:Activity a2.2:Activity
t1:Task t2:Task t3:Task
Attività
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
Evaluationreport
Prototypedevelopment
Requirementsdefinition
Requirementsanalysis
Feasibilityreport
Feasibilitystudy
Architecturaldesign
Designstudy
Requirementsspecification
Requirementsspecification
ACTIVITIES
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
Estimate resourcesfor activities
Identify activitydependencies
Identifyactivities
Allocate peopleto activities
Create projectcharts
Softwarerequirements
Activity chartsand 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-15 days
T-22 days
T-31 days
T-47 days
T-62 days
T-55 days
T-73 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-15 days
T-22 days
T-31 days
T-47 days
T-62 days
T-55 days
T-73 days
0 5
5
5
0 5
9
17
17 20
20
8 12
1412
7 7
12
11 11
5
12
12
12
15
17
17
17
Mansioni: durata e dipendenzeMansioni Durata (giorni) Dipendenze
T1 8T2 15T3 15 T1T4 10T5 10 T2, T4T6 5 T1, T2T7 20 T1T8 25 T4T9 15 T3, T6T10 15 T5, T7T11 7 T9T12 10 T11
Network delle attività
start
T2
M3T6
Finish
T10
M7T5
T7
M2T4
M5
T8
4/7/94
8 days
14/7/94 15 days
4/8/94
15 days
25/8/94
7 days
5/9/94
10 days
19/9/94
15 days
11/8/94
25 days
10 days
20 days
5 days25/7/94
15 days
25/7/94
18/7/94
10 days
T1
M1 T3T9
M6
T11
M8
T12
M4
Diagramma di Gannt4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T1T2
M1
T7T3
M5T8
M3
M2T6
T5M4
T9
M7T10
M6
T11M8
T12
Start
Finish
Allocazione della forza lavoro4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T8 T11
T12
T1
T3
T9
T2
T6 T10
T7
T5
Fred
Jane
Anne
Mary
Jim
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