Transcript Project management

Typical steps in
project planning and scheduling
scehduling
planning
• To identify the tasks, their durations and their
relations (pre-requisite, causal, etc.)
• To evaluate consistency of the task net
• To evaluate the critical path on the tasks net
• Using the critical path, to revise the tasks net
•To evaluate/assign (h-)resources required by tasks
•To move tasks, try to find out at least one consistent
assignment of h-resources to tasks
•To assign costs to tasks and (verify the feasibility)
Sviluppo e messa in esercizio ma né
esercizio né manutenzione
Cos’è e dove si colloca il Planning
per Pressman?
• Communication (Comunicazioni)
• Planning (Pianificazione)
In realtà
• Modeling (Modellazione)
– Analysis of requirements
(Analisi dei requisiti)è
la pianificazione
e la programmazione
– Design (Progettazione)
più
simile
ad
un’attività
ombrello,
• Construction (Costruzione)
continuamente
svolta
– Code
generation (Generazione
del codice)
– Testing (Collaudo)
• Deployment (Dispiegamento)
Lo studio di fattibilità può essere o
meno parte di tali attività
Identificare i Task
• Livelli decisionali della pianificazione e della
programmazione (che fissano il livello di
dettaglio del task chart – o task network -)
• Le informazioni usate per identificare i
task: il processo, l’architettura preliminare, il
modello
di
progetto
(in
particolare
l’architettura), il modello analitico, gli
obiettivi, i rilasci, lo spazio (e le competenze),
e se nulla è disponibile, la portata (scope)
Livelli decisionali
• Strategico:
– Obiettivo: previsione (tempi, costi) (per la valutazione
delle alternative) ed allocazione delle risorse
– Quando: generalmente parte della fattibilità (cioè
quando si deve decidere se fare)
• Operativo:
– Obiettivo: alternative di pianificazione (cioè piani di
progetto con tasks diversi),
– Quando: generalmente svolto dopo una fase preliminare
di Ingegneria dei Requisiti ovvero prima di o durante
Ingegneria della Progettazione, Codifica, Testing e
Deployment
Processo e Progetto
• Un progetto è, nel nostro caso, una concretizzazione di
un processo con l’obiettivo di sviluppare un prodotto
software:
– ad esempio, il progetto per lo sviluppo di un software ovvero
di un sistema per il controllo dei nastri trasportatori
dell’Azienda ABC che segue un modello evolutivo
• Il processo è come detto più volte, l’idea sottostante, la
filosofia di come il software dovrebbe essere sviluppato:
– In un certo senso, in un’azienda, il processo raggruppa tutti
i progetti che seguono tale processo
• Il processo è importante poiché permette di rispondere a
domande quali: quanto siamo capaci a fare del software
con pochi difetti? Quanto siamo capaci a rispettare le
stime? Come possiamo calibrare le stime in funzione del
passato?
Identificare i task
• I task si ricercano all’inizio attraverso una
qualche forma di decomposizione partendo
da ciò che, globalmente, deve essere fatto
• Trovati i task, è necessario descriverli in
dettaglio
Identificare i Task: aspetti pratici
Task
Comunicazioni Modellazione
Costruzione
Deployment
c1
c2
c3
Attività generiche di un
modello di processo
generico
Task
c1
c2
specifico c3
Analisi dei
requisiti
Progettazione
Implementazione
Test/
Integrazione
Identificare i Task:
decomposizione del processo
WBS (Work Breakdown Structure)
Task
Comunicazioni
Modellazione
Costruzione
Deployment
decomposizione
c0
c1
c2
c3
c4
c5
c6
Talvolta, i Task sono
riaggregati in WorkPackage
Ogni Task ed ogni Work-Package
deve avere obiettivi precisi e ben
descritti ovvero responsabilità
precise e può essere più o meno
dipendente al progetto specifico
Identificare i Task:
decomposizione del processo
Comunicazioni
Modellazione
Condurre la prima
riunione
X
Tracciare un
Diagramma dei
Casi d’Uso
X
X
Descrivere gli
Scenari di tutti i
casi d’uso del
diagramma
X
X
Convalidare i Casi
d’Uso
X
X
X
Elaborare il
diagramma dei
Casi d’Uso
Scrivere il
documento dei
requisiti
X
Descrivere i casi
di test di
accettazione
X
Costruzione
Deployment
Tasks generici – eventualmente
consigliati da una metodologia
Task
Identificare i Task:
decomposizione del processo
Comunicazioni
Condurre la prima
riunione
X
Tracciare un
Diagramma dei
Casi d’Uso
X
Descrivere gli
Scenari di tutti i
casi d’uso del
diagramma
X
Convalidare i Casi
d’Uso
X
Identificare i casi
d’uso a maggiore
rischio
X
…
Valutare il
prototipo
X
Modellazione
Costruzione
Deployment
Tasks generici – eventualmente
consigliati da una metodologia
Task
Identificare i Task:
decomposizione del processo
Comunicazioni
Condurre la prima
riunione
X
Tracciare un
Diagramma dei
Casi d’Uso
X
Descrivere gli
Scenari di tutti i
casi d’uso del
diagramma
X
Convalidare i Casi
d’Uso
X
Milestone: il
modello dei casi
d’uso deve essere
disponibile e
convalidato
X
X
Modellazione
Aggiunta di un milestone
Task
Identificare i Task:
decomposizione di attività ombrello
Comunicazioni
Condurre la prima
riunione
X
Tracciare un
Diagramma dei
Casi d’Uso
X
Descrivere gli
Scenari di tutti i
casi d’uso del
diagramma
X
Convalidare i Casi
d’Uso
X
Verificare la
forma del rapporto
della prima
riunione
Verificare che
l’architettura è
consistente con il
modello analitico
Convalidare
l’architettura
X
Modellazione
QA
Tasks generici provenienti da
attività ombrello (piani specifici)
Task
X
X
X
Identificare i Task: decomposizione
suggerita da modelli
T1: Convalidare i casi d’uso,
Cercare, Visualizzare i Viaggi,
Estendere la Ricerca
T2 Convalidare i casi d’uso,
Prenotare, Creare Biglietto, Pagare
CC Casa
Identificare i Task: decomposizione suggerita da modelli
Task
Comunicazioni
Condurre la prima
riunione
X
Tracciare un
Diagramma dei
Casi d’Uso
X
X
Pianificare le
riunioni necessarie
per la descrizione
degli scenari
X
X
Descrivere gli
scenari di tutti i
casi d’uso del
diagramma
X
X
Convalidare prima
versione Casi
d’Uso
X
T1
T2
Modellazione
X
X
Elaborare il
diagramma dei
Casi d’Uso
T1
X
X
T2
X
X
T1
T2
Identificare i Task: decomposizione
suggerita da modelli
cliente
DataFlow1
viaggi
Società CC
Software
Autorizzazione
Costo+codiceviaggio
Orario
orario
Ricercare
Codiceviaggio+opzionicosto+opzioniprenotazioni
Prenotazioni+ntreno
prenotazioni
RichiedoAltriViaggi
Partenza+Destinazione+[OraP]
Rete
Target Software
parametriricerca
rete
DataFlow2
tariffe
Pagare
Viaggio+OpzioniCosto
ViaggioPrenotato
Tariffe
Dati CC
Viaggi
DataFlow1
biglietti
Riepilogo
Cliente/
Utente
orario
prenotazioni
DupCliente/
Utente
Viaggio+PostiTemporaneamentePrenotati
Costo
Biglietto
N°biglietto
VerificaBiglietti
Dati biglietto+ntreno
prenotazioni
Viaggio+OpzioniPrenotazione
Nbiglietto+risposta
controllore
Prenotare
Prenotazioni
prenotazione
Anche la funzione Prenotare potrebbe creare il biglietto se, nel
caso di pagamento differito (ad esempio eseguito in stazione con
contanti), la sola prenotazione non obbligasse all’acquisto del
biglietto; questa scelta obbligherebbe a rivedere il flusso di
creazione del biglietto indicato dalla funzione Pagare.
Biglietto
Biglietti
Non svolto a lezione ma spunto di riflessione: invece di indicare
che la funzione Prenotare crea il biglietto, si può decomporre
ulteriormente la funzione Pagare in cui far apparire una funzione
CreareBiglietto che è comunque immediatamente applicata, dopo
eventuale prenotazione, anche nel caso di pagamento differito
Tasks:
Risposta Stato
Controllore
Passeggero
N°Biglietto
Verificare
Descrivere il diagramma di contesto
Costruire 2 livelli di decomposizione del
DFD
Convalidare il DFD completo
Raffinare Pagare
Risultato
Identificare i Task: decomposizione
suggerita da pratiche (o metodologie)
DataFlow1
Società CC
Software
Autorizzazione
Orario
orario
Ricercare
RichiedoAltriViaggi
Partenza+Destinazione+[OraP]
Rete
rete
DataFlow2
tariffe
Pagare
Viaggio+OpzioniCosto
ViaggioPrenotato
Tariffe
Dati CC
Viaggi
Riepilogo
Cliente/
Utente
prenotazioni
DupCliente/
Utente
Viaggio+PostiTemporaneamentePrenotati
Costo
Biglietto
N°biglietto
prenotazioni
Viaggio+OpzioniPrenotazione
Prenotare
Prenotazioni
prenotazione
Anche la funzione Prenotare potrebbe creare il biglietto se, nel
caso di pagamento differito (ad esempio eseguito in stazione con
contanti), la sola prenotazione non obbligasse all’acquisto del
biglietto; questa scelta obbligherebbe a rivedere il flusso di
creazione del biglietto indicato dalla funzione Pagare.
Biglietto
Biglietti
Non svolto a lezione ma spunto di riflessione: invece di indicare
che la funzione Prenotare crea il biglietto, si può decomporre
ulteriormente la funzione Pagare in cui far apparire una funzione
CreareBiglietto che è comunque immediatamente applicata, dopo
eventuale prenotazione, anche nel caso di pagamento differito
Risposta Stato
Controllore
Passeggero
N°Biglietto
Verificare
Risultato
Tasks:
Definire la qualità attesa
Costruire una prima versione
dell’architettura
Valutare la qualità dell’architettura
& modificare
Identificare i Task: decomposizione
suggerita da modelli
A
Tasks:
Tasks:
Progetto Package A:
Progetto interfaccia
Progetto dettagliato modulo e
Progetto applicazione
Progetto dettagliato modulo d
Progetto componenti del core
Progetto dettagliato modulo a
….
progetto
Descrivere in dettaglio il singolo
Task
Process framework (struttura del processo)
Umbrella Activities (attività ombrello)
Framework activities (attività strutturali)
work tasks
(compiti)
work products
(prodotti)
milestones & deliverables
(pietre miliari e “deliverables”)
quality assurance checkpoints
(punti di valutazione della qualità)
Descrivere in dettaglio il singolo
Task
Obiettivi:…
Inputs:
Outputs:
T
Work Products
Work Products
& Deliverables
& Deliverables
Strumenti:
Responsabile:…
Applicativi;
Tipologia e quantità
Pratiche;
Notazioni etc. di risorse richieste:…
Queste informazioni non sono generalmente
descritte nel task chart
Ricerca delle relazioni (o dipendenze)
• Un task T1 deve precedere un altro task T2
se per svolgere correttamente T2 è stato
necessario completare T1 cioè se T1
produce in output ciò che T2 necessita in
input
• Un task T1 deve precedere un altro task T2
se T2 è svolto sse T1 è stato svolto
• …
Le dipendenze devono essere mantenute ridotte
in modo da parallelizzare al massimo i task
Ad esempio…
• Non posso fare un diagramma dei casi d’uso
senza aver essermi riunito con il committente
• Non posso elaborare un diagramma dei casi
d’uso senza averne fatto una prima versione
• Non posso definire un’architettura senza aver
costruito il modello analitico
• Non posso fare una valutazione di qualità
delle singole componenti se non è stata
svolta una valutazione di qualità
dell’architettura
Ma….
• Quando si arriva a task legati a componenti o
package di componenti la questione diventa
più complessa!
• Le componenti si possono indipendentemente
progettare in modo dettagliato a meno che
queste non siano troppo accoppiate
• Nel caso d’accoppiamento elevato conviene
– creare un unico task per tutte le componenti
troppo accoppiate oppure
– considerare i task in sequenza stretta
Esempio
root
Get Viaggio, Opzioni di Costo,
Opzioni di Prenotazione, Rete, Tariffe,
Prenotazioni, Dati CC
Prenotare&Pagare
Prenotare
entity name
action_on_entity
Pagare
Cohesion : Functional
Coupling: Data
(with Get and Put)
Cohesion:
Procedural
Get All Tables
Put All Tables
Coupling: Control
(with GetPut),
Control (with
Prenotare&Pagare)
Cohesion :
Communication
Coupling:
Put Costo, Viaggio, Posti, Riepilogo,
Prenotazioni, Biglietti
Refinement
Abstraction
Cohesion:
Procedural
Coupling: Control
(with GetPut),
Control (with
Prenotare&Pagare)
Esempio
Progetto dettagliato
“Get All Table; Put All Table” <
Progetto dettagliato
“Get Viaggio, Opzioni di Costo,
Opzioni di Prenotazione, Rete,
Tariffe, Prenotazioni, Dati CC”
Progetto dettagliato
“Get All Table; Put All Table”
Progetto dettagliato
“Get Viaggio, Opzioni di Costo,
Opzioni di Prenotazione, Rete, Tariffe,
Prenotazioni, Dati CC”
Identificare i Task:
un lavoro continuo
Ingegneria
dei requisiti
Ingegneria della
progettazione
Non è ancora noto
qual è l’architettura
Il primo passo potrebbe essere
quello di definizione
dell’architettura
Non è ancora possibile
fare un piano basandosi
sui moduli/package
dell’architettura
E’ possibile fare un piano
basandosi sui moduli/package
dell’architettura
Evoluzione di un piano I
Ingegneria
dei requisiti
Ingegneria della
progettazione
Non è ancora possibile
fare un piano basandosi
sui moduli/package
dell’architettura
E’ possibile fare un piano
basandosi sui moduli/package
dell’architettura
Nov 2006
ID
Task Name
Start
Finish
Dec 2006
Duration
28
1
Piano delle interviste
28/11/2006
30/11/2006
3d
2
Interviste
28/11/2006
08/12/2006
9d
3
Tracciatura dei Casi d’Uso
01/12/2006
05/12/2006
3d
4
Modello analitico (Casi d’uso e classi)
05/12/2006
08/12/2006
4d
5
Validazione del modello analitico
11/12/2006
11/12/2006
1d
6
Ingegneria della progettazione
11/12/2006
04/01/2007
19d
29
30
1
2
3
4
5
6
7
8
9
10
11
Evoluzione di un piano II
Ingegneria della
progettazione
meno
specifico
E’ possibile fare un piano
basandosi sui moduli/package
dell’architettura
specifico
Nov 2006
ID
Task Name
Start
Finish
Dec 2006
Duration
28
1
Piano delle interviste
28/11/2006
30/11/2006
3d
2
Interviste
28/11/2006
08/12/2006
9d
3
Tracciatura dei Casi d’Uso
01/12/2006
05/12/2006
3d
4
Modello analitico (Casi d’uso e classi)
05/12/2006
08/12/2006
4d
5
Validazione del modello analitico
11/12/2006
11/12/2006
1d
6
Definire l’architettura
11/12/2006
15/12/2006
5d
7
Progetto Modulo B
18/12/2006
29/12/2006
10d
8
Progetto Modulo C
18/12/2006
26/12/2006
7d
9
Progetto modulo A
20/12/2006
04/01/2007
12d
29
30
1
2
3
4
5
6
7
8
9
10
11
Progetto
WBS
Ingegneria dei Requisiti
Ingegneria della
Progettazione
Tasks indipendenti
dal progetto
Piano delle interviste
Interviste
Tracciatura dei casi
d’suo
Modello analitico (Casi
d’Uso e classi)
Validazione
Progetto
Ingegneria dei Requisiti
Piano delle interviste
Tasks dipendenti
dal progetto
Ingegneria della
Progettazione
Interviste
Tracciatura dei casi
d’suo
Modello analitico (Casi
d’Uso e classi)
Validazione
Progettare Modulo A
Definire l’architettura
Progetto Modulo B
Progetto Componenti
Progetto Modulo C
Terminologia
• Progetto e processo sono termini stabili
• Task (compito), activity (attività), action
(azione), che indicano livello successivi di
decomposizione, sono termini meno stabili
Decomposizione, di cosa?
architettura,
processo,
obiettivi, rilasci,
spazio, etc.
Vincoli nella decomposizione
• Temporali: un task dovrebbe durare non meno di una
settimana (di un giorno)
• Periodo di reporting: un task non può frangere il
periodo di reporting relativo ad uno stato di
avanzamento
• Obiettivi e responsabilità: un task deve avere un
obiettivo ben definito e un responsabile
• Consistenza: un task, se decomposto in ulteriori tasks
più semplici dovrebbe mantenere la sua durata, il
suo numero di risorse ed anche il suo costo (il costo
è in tal caso la variabile dipendente)
Identificare e Relazionare i Task:
uno spazio multidimensionale,
piani diversi ed integrati
Task deliverables, work
products & Milestones
Task networks and
plans dependencies
Describe plans for the
various dimensions
Requirements
Elicitation
Process
Activites
Building analysis
model
Product quality
Architecture
definition
Risk management
Monitoraggio e Controllo,
Ri-Pianificazione e
Ri-Programmazione
Comunicazioni
Modellazione
Costruzione
Deployement
c0
c1
c2
c3
c4
c5
c6
c7 (new task)
ri-pianificazione e
ri-programmazione