Typical steps in project planning and scheduling

• To identify the tasks and their durations• 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

Identificare i Task (planning)• Livelli decisionali del planning e dello

scheduling (che fissano il livello di dettaglio del task network)

• Le informazioni usate per identificare i tasks: 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 per il Planning (e Scheduling)

• Strategico:– Obiettivo: previsione (tempi, costi) (per la valutazione

delle alternative) ed allocazione delle risorse – Quando: generalmente parte della fattibilità

• Operativo: – Obiettivo: alternative di pianificazione (cioè piani di

progetto con tasks diversi), – Quando: pianificazione di dettaglio dei tempi (definizione

degli adempimenti), generalmente svolto dopo una fase preliminare di Ingegneria dei Requisiti ovvero nella Ingegneria della Progettazione, Codifica, Testing e Deployement

Processo e Progetto• Un progetto è una concretizzazione di un processo con

l’obiettivo di sviluppare un prodotto software: ad esempio, lo sviluppo di un software ovvero di un sistema per il controllo dei nastri trasportatori dell’Azienda ABC

• 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: aspetti praticiTask Comunicazioni Modellazione Costruzione Deployment

c1

c2

c3

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 suggerita dai casi d’uso

Tasks:

Raffinare i casi d’uso Partire, Fermare, Chiudere Porte e Aprire Porte su Passaggio

Raffinare i casi d’uso Richiedere Ascensore e Richiedere Piano

Identificare i Task: decomposizione suggerita da un DFD

viaggicliente

Costo+codiceviaggio

Prenotazioni+ntreno

prenotazioni

Codiceviaggio+opzionicosto+opzioniprenotazioni

parametriricerca

DataFlow1

orario

Ricercare

ValutareDisponibilità&Costo

soluzioniviaggio

ValutareCosto

Costoconprenotazione+soluzioniviaggio

Codiceviaggio+opzionicosto

tariffeTariffe+opzionicosto

Richiestacosto+soluzioneviaggio

Tariffe+opzioniprenotazione+opzionicosto

clientePagareCC

Costo+codiceviaggio

Dati CC

conferma

rispostanegativa

SocietàCCrichiesta

risposta

BigliettiVerificaBiglietti

biglietti

Prenotazioni

biglietti

cliente

Target Softwareparametriricerca

viaggi

Codiceviaggio+opzionicosto+opzioniprenotazioni

Costo+codiceviaggio

orario

DataFlow1

prenotazioniPrenotazioni+ntreno

VerificaBiglietti

controllore

Dati biglietto+ntreno

Nbiglietto+risposta

biglietti

Tasks:

Raffinare Target Software

Raffinare Verifica Biglietti

Convalidare il DFD completo

Identificare i Task: decomposizione suggerita dall’architettura

Tasks:

Progetto interfaccia

Progetto applicazione

Progetto componenti del core

Tasks:

Progetto del modulo E

Progetto del modulo D

Progetto del modulo A

Identificare i Tasks: 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

In seguito è 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 1d28/11/200628/11/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 1d28/11/200628/11/2006Validazione del modello analitico

Evoluzione di un piano IIIngegneria della

progettazione

E’ possibile fare un piano basandosi sui moduli/package

dell’architettura

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 Combinare i Task: uno spazio multidimensionale, piani

diversi ed integratiDescribe plans for the various dimensions

Task networks and plans dependencies

Product quality

Risk management

Iteration

Task deliverables and work products & Milestones

Process management

Process Activity

Decomposition

Monitoring, Ri-Pianificazione e Ri-Scheduling

Comunicazioni Modellazione Costruzione Deployement

c0

c1

c2

c3

c4

c5

c6

ri-pianificazione e

ri-programmazionec7 (new task)