Typical steps in project planning and scheduling To identify the tasks, their durations and their relations (pre-requisite, causal, etc.) To evaluate consistency

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)



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




X


X


X


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


Task Comunicazioni Modellazione


X


X


X


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


X


X


X


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


X


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


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


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


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


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)

Documents

Typical steps in project planning and scheduling To identify the tasks, their durations and their relations (pre-requisite, causal, etc.) To evaluate consistency