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

Presentazione sul tema: "Typical steps in project planning and scheduling To identify the tasks, their durations and their relations (pre-requisite, causal, etc.) To evaluate consistency."— Transcript della presentazione:

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

2 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) Sviluppo e messa in esercizio ma né esercizio né manutenzione 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

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

4 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

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

6 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

7 Identificare i Task: aspetti pratici TaskComunicazioniModellazioneCostruzioneDeployment c1 c2 c3 Attività generiche di un modello di processo TaskAnalisi dei requisiti ProgettazioneImplementazioneTest/ Integrazione c1 c2 c3 specifico generico

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

9 Identificare i Task: decomposizione del processo TaskComunicazioniModellazioneCostruzioneDeployment 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 Tasks generici – eventualmente consigliati da una metodologia

10 Identificare i Task: decomposizione del processo TaskComunicazioniModellazioneCostruzioneDeployment 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 Tasks generici – eventualmente consigliati da una metodologia

11 Identificare i Task: decomposizione del processo TaskComunicazioniModellazione 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 Aggiunta di un milestone

12 Identificare i Task: decomposizione di attività ombrello TaskComunicazioniModellazioneQA 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 Tasks generici provenienti da attività ombrello (piani specifici)

13 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

14 Identificare i Task: decomposizione suggerita da modelli TaskComunicazioniModellazione 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 XT1T2 Elaborare il diagramma dei Casi d’Uso T1X T2X X X X XT1T2 X X X evoluzione del piano Tasks specifici – consigliati sul diagramma dei casi d’uso

15 Identificare i Task: decomposizione suggerita da modelli Tasks: Descrivere il diagramma di contesto Costruire 2 livelli di decomposizione del DFD Convalidare il DFD completo Raffinare Pagare

16 Identificare i Task: decomposizione suggerita da pratiche (o metodologie) Tasks: Definire la qualità attesa Costruire una prima versione dell’architettura Valutare la qualità dell’architettura & modificare

17 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

18 Descrivere in dettaglio il singolo Task Process framework (struttura del processo) Umbrella Activities (attività ombrello) Framework activities (attività strutturali) Framework activities (attività strutturali) work tasks (compiti) work products (prodotti) milestones & deliverables (pietre miliari e “deliverables”) quality assurance checkpoints (punti di valutazione della qualità) progetto

19 T Inputs: 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

20 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

21 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

22 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

23 root Get Viaggio, Opzioni di Costo, Opzioni di Prenotazione, Rete, Tariffe, Prenotazioni, Dati CC Prenotare&Pagare Put Costo, Viaggio, Posti, Riepilogo, Prenotazioni, Biglietti Cohesion : Communication Coupling: Cohesion: Procedural Coupling: Control (with GetPut), Control (with Prenotare&Pagare) Cohesion: Procedural Coupling: Control (with GetPut), Control (with Prenotare&Pagare) Get All Tables Put All Tables PrenotarePagare Abstraction Refinement Cohesion : Functional Coupling: Data (with Get and Put) Esempio entity name action_on_entity

24 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”

25 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

26 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

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

28 WBS Tasks indipendenti dal progetto Tasks dipendenti dal progetto

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

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

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

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

33

34 Monitoraggio e Controllo, Ri-Pianificazione e Ri-Programmazione ComunicazioniModellazioneCostruzioneDeployement c0 c1 c2 c3 c4 c5 c6 ri-pianificazione e ri-programmazione c7 (new task)