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.

Presentazione sul tema: "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."— Transcript della presentazione:

1 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) planning scehduling

2 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)

3 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

4 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?

5 Identificare i Task: aspetti pratici TaskComunicazioniModellazioneCostruzioneDeployment c1 c2 c3 Modello di processo TaskAnalisi dei requisiti ProgettazioneImplementazioneTest/ Integrazione c1 c2 c3 specifico generico

6 Identificare i Task: decomposizione del processo Task ComunicazioniModellazioneCostruzioneDeployment 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 decomposizione WBS (work breakdown structure)

7 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

8 Identificare i Task: decomposizione suggerita da un DFD Tasks: Raffinare Target Software Raffinare Verifica Biglietti Convalidare il DFD completo

9 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

10 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

11 Evoluzione di un piano I Ingegneria 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

12 Evoluzione di un piano II Ingegneria della progettazione E’ possibile fare un piano basandosi sui moduli/package dell’architettura

13 WBS Tasks indipendenti dal progetto Tasks dipendenti dal progetto

14 Terminologia Progetto e processo sono termini stabili Task (compito), activity (attività), action (azione), che indicano livello successivi di decomposizione, sono termini meno stabili

15 Decomposizione, di cosa? architettura, processo, obiettivi, rilasci, spazio, etc.

16 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)

17 Identificare e Combinare i Task: uno spazio multidimensionale, piani diversi ed integrati Describe 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

18

19 Monitoring, Ri-Pianificazione e Ri-Scheduling ComunicazioniModellazioneCostruzioneDeployement c0 c1 c2 c3 c4 c5 c6 ri-pianificazione e ri-programmazione c7 (new task)