02: Project Management
Le tre P del project management Persone motivate / esperte SEI PM-CMM (People Management Capability Maturity Model) assunzione / selezione addestramento / cultura di gruppo stipendio / carriera Problema prima della pianificazione occorre identificare chiaramente gli obbiettivi, le soluzioni possibili ed i vincoli al contorno ottenendo informazioni di tipo quantitativo Processo utilizzando uno dei modelli per il ciclo di vita del software occorre individuare attivita, scadenze, prodotti ed iterazioni, non trascurando le attivita trasversali, quali, ad esempio, il controllo qualita, le misure e la gestione delle versioni 02Prman.2
Persone coinvolte nel progetto Senior manager Project (technical) manager Practitioners Gruppo Capogruppo Customer End User La figura del capogruppo e cruciale motivare organizzare risolvere i problemi gestire il personale 02Prman.3
Il gruppo di sviluppo n persone che lavorano per k anni n persone assegnate a m attivita differenti m>n m<n (nasce il concetto di gruppo e di capogruppo) n persone divise in t gruppi, dove ogni gruppo e responsabile di una o piu attivita Struttura interna del gruppo DD decentralizzata democratica CD decentralizzata controllata CC centralizzata controllata Fattori che influenzano la scelta della struttura del gruppo difficolta, modularita e dimensione del problema "ciclo di vita del gruppo" qualita richieste al sistema e rigidita della data di consegna 02Prman.4
Scelta della struttura del gruppo DD CD CC DIFFICOLTA alta bassa DIM. PROBLEMA grande piccola MODULARITA alta bassa AFFIDABILITA alta bassa VITA GRUPPO breve lunga SCADENZA stretta lasca 02Prman.5
Coordinamento del gruppo Formale, impersonale tool per il controllo del progetto documentazione prodotti intermedi scadenze Formale, interpersonale assicurazione qualita revisioni periodiche Informale riunioni diffusione risultati/scelte e-mail, altro 02Prman.6
Il problema Occorre una stima quantitativa il piu presto possibile ma: un analisi dettagliata non e ancora disponibile le specifiche possono cambiare durante il progetto occorre determinare, almeno, la portata (scope) del progetto Scope: Contet: rapporto del software da sviluppare con il resto del sistema Information objectives: dati di ingresso e di uscita maneggiati dall utente Function and performances: funzionalita da sviluppare ed prestazioni particolari da raggiungere Informazioni quantitative! numero di utenti massimo tempo di risposta spazio richiesto costi da non superare Decomporre il problema in un insieme di compiti 02Prman.7
Il processo Scelta di un modello a prototipo/ spirale,... -> sequenza di attivita Problema & modello matrice di compiti ed attivita customer communication c1? c2 c3... planning risk analysis... per ogni cella stimare l impegno necessario Monitoraggio del progetto (quanto manca?) regola del 90-90 metriche quantitative 02Prman.8
Stima Fattori che rendono difficile effettuare una stima attendibile: complessita del progetto (assoluta e relativa alle esperienze precedenti) dimensione del progetto mancanza di esperienze (e misure) pregresse informazioni inattendibili o non ufficiali Linee guida per ottenere una stima Acquisire le informazioni principali (scope) e decomporle in funzioni principali prestazioni e vincoli sono essenziali ai fini di una corretta valutazione Individuare le risorse necessarie Persone (capacita + numero) Componenti riusabili (spesso trascurati) componenti disponibili (prodotti internamente o da acquistare)! componenti simili da modificare (su cui si ha esperienza)! componenti simili da modificare (su cui non si ha esperienza)? HW e SW da utilizzarsi per lo sviluppo del progetto 02Prman.9
Stima del costo e dell impegno Metodi per la stima del tempo uomo necessario LOC FP Analisi del processo di produzione del software Modelli empirici COCOMO / equazione del software [Putnam & Myers 92] Equazione del SW (statistiche su 4000 progetti) E=(LOC*B 0.333 /P) 3 * (1/t 4 ) t = durata del progetto (mesi / anni) E = impegno (mesi uomo / anni uomo) B = fattore di aggiustamento (0.16...0.39 ) (5 KLOC... 70 KLOC) P = produttivita (2000... 28.000 ) complessita dell applicazione esperienza dei programmatori linguaggio di programmazione altro... 02Prman.10
Make or Buy? Acquistare o sviluppare in proprio? In linea di principio conviene acquisire il SW piuttosto che svilupparlo In caso di SW economico prodotto da terzi conviene acquistarlo e sperimentarlo In caso di SW costoso e necessario analizzare le funzionalita richieste e valutare quale sia la scelta piu vantaggiosa in termini di: costi tempi rischi alberi di decisione pesati statisticamente il costo di una scelta e pari alla somma pesata dei vari cammini 02Prman.11
semplice (0.3) difficile (0.7) 380.000 ECU 450.000 ECU sviluppare piccoli cambiamenti (0.4) 275.000 ECU sistema X riutilizzare acquistare grossi cambiamenti (0.6) semplice (0.2) 310.000 ECU commissionare piccoli cambiamenti (0.7) grossi cambiamenti (0.6) difficile (0.8) 490.000 ECU 210.000 ECU senza cambiamenti (0.6) con cambiamenti (0.4) 400.000 ECU 350.000 ECU 500.000 ECU riutilizzare = 0.4*275.000+0.6[0.2*310.000+0.8*490.000]=382.000 02Prman.12
Pianificazione di un progetto Fattori che rendono probabile finire in ritardo : scadenza imposta dall alto cambiamento delle specifiche errato calcolo dell impegno necessario difficolta impreviste incapacita di accorgersi del ritardo del progetto e mancanza di adeguate azioni correttive Principi base per la pianificazione Dividere il progetto in macro attivita usando sia la decomposizione del problema che del processo Individuare le interdipendenze tra le macro attivita Controllare che la pianificazione non richieda mai un impegno complessivo superiore a quello massimo disponibile Individuare le responsabilita Definire i prodotti di ogni attivita (deliverable) Definire scadenze intermedie (milestone) 02Prman.13
Persone e tempo La relazione che corre tra persone e tempo non e lineare coordinamento comunicazione anche le formule empiriche confermano questo dato: allungando il tempo di sviluppo l impegno complessivo diminuisce Distribuzione dell impegno (regola 40-20 - 40) 40 % analisi 20 % codifica 40 % test In realta la regola e solo indicativa (vedi tabelle COCOMO per i vari tipi di progetto) 02Prman.14
Individuazione delle attivita Scelta di un modello Tipi di progetto progetto di ricerca nuova applicazione miglioramento di una applicazione mantenimento di una applicazione reengineering di una applicazione (legacy) esistente Grado di rigore Casuale Strutturato Rigoroso Reazione veloce 02Prman.15
Scelta del grado di rigore Criteri per la scelta (adaptation criteria) dimensione del progetto numero potenziale di utenti criticita della applicazione vita dell applicazione stabilita dei requisiti facilita di comunicazione con il committente maturita della tecnologia utilizzata vincoli sulle prestazioni altro... A ciascun criterio si assegna un valore 1..5 (informale... reazione veloce) Eventuale revisione del peso del criterio Inclusione o meno del criterio pesato a seconda del tipo di progetto Calcolo della media <1.2 casuale 1... 3.0 strutturato >2.4 rigoroso 02Prman.16
grado peso app. nuova migl. mant. reengin. prodotto (1..5) ricerca app. app. app. dim. 1.2 1 1 1 1 1 progetto num. 1.1 1 1 1 1 1 utenti criticita 1.1 1 1 1 1 1 applic. vita 0.9 1 1 1 0 0 appl. stabilita 1.2 1 1 1 1 1 requisiti facilita 0.9 1 1 1 1 1 comunic......................... 02Prman.17
1)Definizione del progetto (com. utente) ricerca nuova app. miglioramento manutenzione reengineering Modello a spirale e tipi di progetto 2) Planning 3) Risk analysis 4) Ingegnerizzazione 6) valutazione da parte del cliente 5) Realizzazione 02Prman.18
Raffinamento delle attivita principali Individuare la portata del progetto (concept scoping) 1.1 identificare i bisogni dell utente, benefici ed utenti potenziali 1.2 definire le attivita di input/output che controllano l applicazione 1.2.1 Revisione formale della descriizone dei bisogni 1.2.2 produrre una lista degli input/output visibili all utente 1.2.3 revisione formale degli input/output con l utente 1.3 definire le funzionalita ed il comportamento per ogni funzione principale 1.3.1 revisione formale degli input/output e degli oggetti visibili all utente prodotti dall attivita 1.2 1.3.2 produrre un modello del comportamento delle funzioni 1.2.3 revisione formale del comportamento con l utente 1.4 individuare gli elementi tecnologici coinvolti nel progetto 1.5 ricercare componenti SW esistenti 1.6 definire la fattibilita tecnica 1.7 stimare rapidamente la dimensione del progetto 1.8 definire la portata del progetto 02Prman.19
Rete di attivita Costruire un grafo che evidenzi la sequenza delle attivita evidenziando le possibili parallelizzazioni I.3a I.1 I.2 I.3b I.4 I.3c La notazione piu usata sono i diagrammi PERT (Program Evaluation and Review) ideati ne 50 dalla Lockheed per gestire il progetto Polaris. Un nodo rappresenta una attivita con il relativo tempo previsto (eventualmente una terna di valori : pessimo, verosimile ed ottimo) Un arco rappresenta una dipendenza tra le attivita E possibile individuare il cammino critico 02Prman.20
Diagrammi temporali Dopo aver decomposto il progetto in task prefissati e utili costruire un diagramma temporale delle attivita detto GANTT m1 fine analisi m2 fine codifica analisi studio fattibilita d1 codifica1 codifica2 d2 d3 codifica3 d4 int. e test d5 0 6m 12m 18 Un GANTT va integrato con un PERT per avere tutte le informazioni relative alle interdipendenze tra task Molti CASE tool per il project management prevedono l uso di PERT e di GANTT a vari livelli di sofisticazione 02Prman.21
Controllo della pianificazione Pert e GANTT possone essere usati per monitorare l avanzamento del progetto meeting periodici con i gruppi di lavoro per verificare lo stato di avanzamento valutazione delle revisioni formali condotte corretto raggiungimento dei milestone inizio effettivo attivita vs inizio previsto meeting informali per individuare possibili problemi Individuazione e risoluzione dei problemi Strategia time-bo rilascio incrementale del prodotto terminare sempre le attivita al loro scadere periodico Piano di progetto - breve documento che descrive la portata (scope) del progetto definisce i rischi definisce il costo e la pianificazione fornisce un quadro di riferimento globale evidenzia come la qualita del prodotto viene garantita 02Prman.22