Post on 02-May-2015
Typical steps in project planning and scheduling
• 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)
plan
ning
sceh
duli
ng
• Communication (Comunicazioni)• Planning (Pianificazione)• Modeling (Modellazione)
– Analysis of requirements (Analisi dei requisiti)– Design (Progettazione)
• Construction (Costruzione)– Code generation (Generazione del codice)– Testing (Collaudo)
• Deployment (Dispiegamento)
Svi
lupp
o e
mes
sa in
ese
rciz
io m
a né
es
erci
zio
né m
anut
enzi
one
Lo studio di fattibilità può essere o meno parte di tali attività
Cos’è e dove si colloca il Planning per Pressman?
In realtà la pianificazione e la programmazione è
più simile ad un’attività ombrello, continuamente svolta
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 praticiTask Comunicazioni Modellazione Costruzione Deployment
c1
c2
c3
Attività generiche di un modello di processo
Task Analisi dei requisiti
Progettazione Implementazione Test/ Integrazione
c1
c2
c3specifico
generico
Identificare i Task: decomposizione del processo
Task Comunicazioni Modellazione Costruzione Deployment
c0
c1
c2
c3
c4
c5
c6
Talvolta, i Task sono riaggregati in Work-Package
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
deco
mpo
sizi
one
WBS (Work Breakdown Structure)
Identificare i Task: decomposizione del processo
Task Comunicazioni Modellazione Costruzione Deployment
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
Elaborare il diagramma dei Casi d’Uso
Scrivere il documento dei requisiti
X
Descrivere i casi di test di accettazione
X
X
X
X
X
Tas
ks g
ener
ici –
eve
ntua
lmen
te
cons
iglia
ti da
una
met
odol
ogia
Identificare i Task: decomposizione del processo
Task Comunicazioni Modellazione Costruzione Deployment
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
Tas
ks g
ener
ici –
eve
ntua
lmen
te
cons
iglia
ti da
una
met
odol
ogia
Identificare i Task: decomposizione del processo
Task Comunicazioni Modellazione
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
Agg
iunt
a di
un
mile
ston
e
Identificare i Task: decomposizione di attività ombrello
Task Comunicazioni Modellazione QA
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
X
X
X
Tas
ks g
ener
ici p
rove
nien
ti da
at
tività
om
brel
lo (
pian
i spe
cifi
ci)
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 modelliTask Comunicazioni Modellazione
Condurre la prima riunione
X
Tracciare un Diagramma dei Casi d’Uso
X
Pianificare le riunioni necessarie per la descrizione degli scenari
X
Descrivere gli scenari di tutti i casi d’uso del diagramma
X
Convalidare prima versione Casi d’Uso
X T1 T2
Elaborare il diagramma dei Casi d’Uso
T1 X
T2 X
X
X
X
X T1 T2
X
X
X
evol
uzio
ne
del p
iano
Tas
ks s
peci
fic i
–
cons
iglia
ti s u
l dia
gram
ma
dei c
asi d
’us o
Identificare i Task: decomposizione suggerita da modelli
cliente
Target Softwareparametriricerca
viaggi
Codiceviaggio+opzionicosto+opzioniprenotazioni
Costo+codiceviaggio
orario
DataFlow1
prenotazioniPrenotazioni+ntreno
VerificaBiglietti
controllore
Dati biglietto+ntreno
Nbiglietto+risposta
biglietti
Tasks:
Descrivere il diagramma di contesto
Costruire 2 livelli di decomposizione del DFD
Convalidare il DFD completo
Raffinare Pagare
Cliente/Utente
Ricercare
Partenza+Destinazione+[OraP]
Viaggi
Pagare
Orarioorario
Viaggio+OpzioniCosto
Costo
Tariffetariffe
PrenotareViaggio+OpzioniPrenotazione
Viaggio+PostiTemporaneamentePrenotati
Prenotazioniprenotazioni
Società CCSoftware
Autorizzazione
DataFlow1
DataFlow2
prenotazione
Verificare
PasseggeroN°Biglietto
Controllore
Risultato
Biglietti
Biglietto
Risposta Stato
DupCliente/Utente
Dati CC
Riepilogo
RichiedoAltriViaggi
prenotazioni
ViaggioPrenotato
Rete
rete
Anche la funzione Prenotare potrebbe creare il biglietto se, nelcaso di pagamento differito (ad esempio eseguito in stazione con
contanti), la sola prenotazione non obbligasse all’acquisto delbiglietto; questa scelta obbligherebbe a rivedere il flusso di
creazione del biglietto indicato dalla funzione Pagare.Biglietto
N°biglietto
Non svolto a lezione ma spunto di riflessione: invece di indicareche la funzione Prenotare crea il biglietto, si può decomporre
ulteriormente la funzione Pagare in cui far apparire una funzioneCreareBiglietto che è comunque immediatamente applicata, dopo
eventuale prenotazione, anche nel caso di pagamento differito
Identificare i Task: decomposizione suggerita da pratiche (o metodologie)
Cliente/Utente
Ricercare
Partenza+Destinazione+[OraP]
Viaggi
Pagare
Orarioorario
Viaggio+OpzioniCosto
Costo
Tariffetariffe
PrenotareViaggio+OpzioniPrenotazione
Viaggio+PostiTemporaneamentePrenotati
Prenotazioniprenotazioni
Società CCSoftware
Autorizzazione
DataFlow1
DataFlow2
prenotazione
Verificare
PasseggeroN°Biglietto
Controllore
Risultato
Biglietti
Biglietto
Risposta Stato
DupCliente/Utente
Dati CC
Riepilogo
RichiedoAltriViaggi
prenotazioni
ViaggioPrenotato
Rete
rete
Anche la funzione Prenotare potrebbe creare il biglietto se, nelcaso di pagamento differito (ad esempio eseguito in stazione con
contanti), la sola prenotazione non obbligasse all’acquisto delbiglietto; questa scelta obbligherebbe a rivedere il flusso di
creazione del biglietto indicato dalla funzione Pagare.Biglietto
N°biglietto
Non svolto a lezione ma spunto di riflessione: invece di indicareche la funzione Prenotare crea il biglietto, si può decomporre
ulteriormente la funzione Pagare in cui far apparire una funzioneCreareBiglietto che è comunque immediatamente applicata, dopo
eventuale prenotazione, anche nel caso di pagamento differito
Tasks:
Definire la qualità attesa
Costruire una prima versione dell’architettura
Valutare la qualità dell’architettura & modificare
Identificare i Task: decomposizione suggerita da modelli
Tasks:
Progetto interfaccia
Progetto applicazione
Progetto componenti del core
Tasks:
Progetto Package A:
Progetto dettagliato modulo e
Progetto dettagliato modulo d
Progetto dettagliato modulo a
….
A
Descrivere in dettaglio il singolo Task
Process framework (struttura del processo)Process framework (struttura del processo)Umbrella Activities (attività ombrello)Umbrella Activities (attività ombrello)
Framework activities (attività strutturali)Framework activities (attività strutturali)work tasks work tasks (compiti)(compiti)work products work products (prodotti)(prodotti)milestones & deliverables milestones & deliverables (pietre miliari e “deliverables”)(pietre miliari e “deliverables”)quality assurance checkpoints quality assurance checkpoints (punti di valutazione della qualità)(punti di valutazione della qualità)pr
oget
to
TInputs:
Work Products & Deliverables
Outputs:
Work Products & Deliverables
Strumenti: Applicativi; Pratiche; Notazioni etc.
Descrivere in dettaglio il singolo Task
Obiettivi:…
Responsabile:…
Tipologia e quantità 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
root
Get Viaggio, Opzioni di Costo, Opzioni di Prenotazione, Rete, Tariffe,
Prenotazioni, Dati CC
Prenotare&PagarePut Costo, Viaggio, Posti, Riepilogo,
Prenotazioni, Biglietti
Cohesion : CommunicationCoupling:
Cohesion: Procedural
Coupling: Control (with GetPut), Control (with Prenotare&Pagare)
Cohesion: Procedural
Coupling: Control (with GetPut), Control (with Prenotare&Pagare)
Get All TablesPut All Tables
Prenotare Pagare
Abstraction
Refinement
Cohesion : FunctionalCoupling: Data (with Get and Put)
Esempio
entity name
action_on_entity
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
Non è ancora noto qual è l’architettura
Non è ancora possibile fare un piano basandosi
sui moduli/package dell’architettura
Ingegneria della progettazione
Il primo passo potrebbe essere quello di definizione
dell’architettura
E’ possibile fare un piano basandosi sui moduli/package
dell’architettura
Evoluzione di un piano IIngegneria dei requisiti
Non è ancora possibile fare un piano basandosi
sui moduli/package dell’architettura
Ingegneria della progettazione
E’ possibile fare un piano basandosi sui moduli/package
dell’architettura
ID Task Name Start Finish DurationNov 2006 Dec 2006
28 29 30 1 2 3 4 5 6 7 8 9 10 11
1 3d30/11/200628/11/2006Piano delle interviste
2 9d08/12/200628/11/2006Interviste
3 3d05/12/200601/12/2006Tracciatura dei Casi d’Uso
4 4d08/12/200605/12/2006Modello analitico (Casi d’uso e classi)
6 19d04/01/200711/12/2006Ingegneria della progettazione
5 1d11/12/200611/12/2006Validazione del modello analitico
ID Task Name Start Finish DurationNov 2006 Dec 2006
28 29 30 1 2 3 4 5 6 7 8 9 10 11
1 3d30/11/200628/11/2006Piano delle interviste
2 9d08/12/200628/11/2006Interviste
3 3d05/12/200601/12/2006Tracciatura dei Casi d’Uso
4 4d08/12/200605/12/2006Modello analitico (Casi d’uso e classi)
9 12d04/01/200720/12/2006Progetto modulo A
6 5d15/12/200611/12/2006Definire l’architettura
7 10d29/12/200618/12/2006Progetto Modulo B
8 7d26/12/200618/12/2006Progetto Modulo C
5 1d11/12/200611/12/2006Validazione del modello analitico
Evoluzione di un piano IIIngegneria della
progettazione
E’ possibile fare un piano basandosi sui moduli/package
dell’architettura
specifico
meno specifico
WBSProgetto
Ingegneria dei Requisiti Ingegneria dellaProgettazione
Piano delle interviste IntervisteTracciatura dei casi
d’suoModello analitico (Casi
d’Uso e classi)Validazione
Progetto
Ingegneria dei Requisiti Ingegneria dellaProgettazione
Piano delle interviste Definire l’architetturaIntervisteTracciatura dei casi
d’suoModello analitico (Casi
d’Uso e classi)Validazione
Progettare Modulo A Progetto Modulo B Progetto Modulo C
Progetto Componenti
Tasks indipendenti dal progetto
Tasks dipendenti dal progetto
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 integratiDescribe plans for the various dimensions
Task networks and plans dependencies
Product quality
Risk management
Task deliverables, work products & Milestones Process
Activites
Requirements Elicitation
Architecture definition
Building analysis model
Monitoraggio e Controllo, Ri-Pianificazione e Ri-Programmazione
Comunicazioni Modellazione Costruzione Deployement
c0
c1
c2
c3
c4
c5
c6
ri-pianificazione e
ri-programmazionec7 (new task)