Ingegneria del Software
Ingegneria del Software
Gestione progetti
Personale (Staff)
• Non sempre è possibile avere le persone ideali per
• La gestione di un progetto software (management)
descrive le attività necessarie affinché il prodotto software
lavorare su un progetto
sia finito in tempo e in accordo ai requisiti delle
organizzazioni di sviluppo e di acquisto
• Attività di gestione
• Pianificazione e scheduling progetto
Riferimenti
Pressman, capitoli 5.3, 19.1,
19.2.1, 19.4, 19.5, 20.3, 20.4
+Milestones +Percorso critico;
Sommerville, capitolo 4
• Costi di progetto
Vedi documento projectPlanV01
• Scrittura della proposta (proposal)
• Monitoraggio e revisioni progetto
• Selezione e valutazione personale
• Scrittura report e presentazioni
• Il budget potrebbe non consentire di usare il personale
molto costoso
• Il personale con l’esperienza appropriata potrebbe non
essere disponibile
• Una organizzazione potrebbe voler formare del personale
lavorando su un progetto
• I manager devono lavorare con questi vincoli
specialmente quando (come oggi) vi è carenza di
personale ben qualificato
Software
Win OpenWorkbench, MS Project
Linux MrProject
XPlanner
Ing. E. Tramontana - Gestione Progetti - 28-Mar-06
Ing. E. Tramontana - Gestione Progetti - 28-Mar-06
1
Ingegneria del Software
2
Ingegneria del Software
Pianificazione del progetto
Tipi di piani del progetto
• Piano della qualità
• La pianificazione (compreso il monitoring) è
probabilmente l’attività che prende più tempo
• Descrive le procedure di qualità e gli standard che dovranno essere usati
• E’ continuativa dall’inizio alla consegna del prodotto
software
• Descrive l’approccio, le risorse e lo scheduling usati per validare il sistema
• Piano di gestione configurazione
• I piani devono essere revisionati (arricchiti di
• Descrive le procedure e le strutture di gestione configurazione che
dettagli, corretti, aggiornati) quando nuove
informazioni diventano disponibili
devono essere usate
• Piano di manutenzione
• Predice i requisiti di manutenzione del sistema, i costi di manutenzione e
• Piani di tipo differente possono essere
lo sforzo richiesto
sviluppati a supporto del piano principale che si
concentra su scheduling e budget
Ing. E. Tramontana - Gestione Progetti - 28-Mar-06
• Piano di validazione
• Piano di sviluppo del personale
• Descrive come le abilità e l’esperienza del personale sarà sviluppato
3
Ing. E. Tramontana - Gestione Progetti - 28-Mar-06
4
Ingegneria del Software
Ingegneria del Software
Organizzazione attività
Milestones
• Esempio di attività e milestones nella fase di
• Le attività del progetto dovrebbero essere
organizzate per produrre risultati tangibili che i
manager possono esaminare per stabilire i progressi
raggiunti
specifica dei requisiti
• Milestones sono il punto finale di una attività del
processo software
• Deliverables sono i risultati del progetto che sono
consegnati ai clienti
• Il processo a cascata permette direttamente la
definizione di milestones
Ing. E. Tramontana - Gestione Progetti - 28-Mar-06
Ing. E. Tramontana - Gestione Progetti - 28-Mar-06
5
Ingegneria del Software
6
Ingegneria del Software
Scheduling del progetto
Problemi nella schedulazione
• Dividere il progetto in task e stimare tempo e risorse
• E’ difficile valutare la difficoltà dei problemi e quindi il costo per
lo sviluppo di una soluzione
necessarie a completare ciascun task
• La produttività non è proporzionale al numero di persone che
• Ogni task dovrebbe durare almeno 1 settimana e non
lavorano per un task
dovrebbe superare le 10 settimane
• Aggiungere persone ad un progetto in ritardo fa aumentare il ritardo, a
• Organizzare i task in modo concorrente per fare un
causa della comunicazione necessaria
uso ottimale della forza lavoro
• Qualcosa di inaspettato può capitare
• Minimizzare le dipendenze tra task per evitare ritardi
• Prevedere un piano per le emergenze
dovuti ad un task che aspetta il completamento di un
altro
• E’ possibile stimare la durata di un progetto
•
•
•
•
• Lo scheduling dipende dall’intuizione e dall’esperienza
dei manager del progetto
Ing. E. Tramontana - Gestione Progetti - 28-Mar-06
7
Ricorrendo all’esperienza (propria o altrui)
Facendo affidamento che niente vada male
Aggiungendo un 30% per i problemi che possono essere intravisti
Aggiungendo un ulteriore 20% per tener conto di ciò che non è stato
Ing. E. Tramontana - Gestione Progetti - 28-Mar-06
immaginato
8
Ingegneria del Software
Ingegneria del Software
Diagrammi
Task
• Durata e dipendenza dei task
• Uso di notazioni grafiche per illustrare lo
scheduling del progetto
Task
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
• Mostrare le divisioni in task
• I task non dovrebbero essere troppo piccoli, la loro
durata dovrebbe essere di una o due settimane
• I diagrammi delle attività mostrano le
dipendenze tra i task ed i percorsi critici
• I diagrammi a barre mostrano lo scheduling su
un calendario
Ing. E. Tramontana - Gestione Progetti - 28-Mar-06
Dependencies
T1 (M1)
T2, T4 (M2)
T1, T2 (M3)
T1 (M1)
T4 (M5)
T3, T6 (M4)
T5, T7 (M7)
T9 (M6)
T11 (M8)
Ing. E. Tramontana - Gestione Progetti - 28-Mar-06
9
Ingegneria del Software
Duration (days)
8
15
15
10
10
5
20
25
15
15
7
10
10
Ingegneria del Software
Rete delle Attività
Temporizzazione attività
• Il tempo minimo richiesto per completare il progetto è dato dal più lungo
percorso del grafo (detto percorso critico)
• Ritardi nei task che non fanno parte del percorso critico non causano ritardi
globali, a patto che il percorso critico non cambi
Ing. E. Tramontana - Gestione Progetti - 28-Mar-06
11
Ing. E. Tramontana - Gestione Progetti - 28-Mar-06
12
Ingegneria del Software
Ingegneria del Software
Allocazione del personale
Gestione del rischio
• La gestione del rischio consiste nell’identificare i rischi
e progettare piani che minimizzano gli effetti dei rischi
sul progetto
• Un rischio è la probabilità che una circostanza
negativa si verifichi
• Rischi di progetto hanno effetto sullo scheduling o sulle
risorse
• Rischi di prodotto hanno effetto sulla qualità o sulle
performance del prodotto che si sta sviluppando
• Rischi di business hanno effetto sulla organizzazione che
sviluppa o richiede il software
Ing. E. Tramontana - Gestione Progetti - 28-Mar-06
Ing. E. Tramontana - Gestione Progetti - 28-Mar-06
13
Ingegneria del Software
Ingegneria del Software
Rischi
Gestione del rischio
Tipo
Rischio
Progetto
Turnover del personale Personale esperto lascia il progetto prima che sia finito
Progetto
Cambio della gestione
Progetto
Indisponibilità hardware Hardware essenziale non è consegnato in tempo
Progetto e Cambiamento dei
prodotto
requisiti
Descrizione
Cambiamenti nell’organizzazione della gestione con
differenti priorità
• Di progetto, prodotto e di business
• Valutazione della probabilità e delle conseguenze dei rischi
identificati
Più cambiamenti di requisiti rispetto alle previsioni
• Pianificazione rischi
• Progettare un piano per evitare o minimizzare gli effetti dei
rischi
• Monitoraggio rischi
Progetto e Dimensione
prodotto
sottostimata
La dimensione del sistema è stata sottostimata
Business
La tecnologia su cui il sistema è costruito è sorpassata
da una nuova tecnologia
Ing. E. Tramontana - Gestione Progetti - 28-Mar-06
• Identificazione dei rischi
• Analisi dei rischi
Progetto e Ritardo nelle specifiche Le specifiche su interfacce essenziali non sono
prodotto
disponibili in tempo
Cambio di tecnologia
14
15
• Monitoraggio durante il progetto
Ing. E. Tramontana - Gestione Progetti - 28-Mar-06
16
