Contenuti - Gestione di progetto - Ruoli professionali - Pianificazione di progetto - Stima dei costi di progetto - Seminario: rischi di progetto Gestione di progetto - Dal processo al progetto - Da processo definito a standard aziendale - Processo istanziato secondo le esigenze del progetto - Stimare i costi e le risorse necessarie - Pianificare le attività, assegnarle alle persone - Controllare le attività e verificare i risultati Peculiarità problematiche - Il prodotto software è intangibile e straordinariamente flessibile - All’ingegneria del software non viene (ancora) riconosciuta la dignità delle altre discipline ingegneristiche - Il processo di sviluppo software non è standardizzato in modo definitivo - Una gran quantità di progetti è di tipo “one off” - Esemplari unici piuttosto che di serie Fattori di rischio - Variabilità del personale (incluso il responsabile - Disponibilità della piattaforma di sviluppo e/o di esecuzione - Variabilità dei requisiti - Ritardo nelle specifiche - Iniziali (del committente) e/o interne (del fornitore) - Variabilità delle tecnologie - Prodotti nuovi vs. obsoleti (non più manutenuti) - Competizione sul mercato Gestione dei rischi - Identificazione - Nel progetto, nel prodotto, nel business - Analisi - Probabilità di occorrenza e conseguenze possibili - Pianificazione - Come evitarne o minimizzarne gli effetti - Controllo - Attenzione continua nel corso del progetto Ruoli - Funzioni aziendali assegnate a progetto - Sviluppo --> aspetti tecnologici - Direzione --> responsabilità decisionali - Amministrazione --> gestione dei processi - Controllo --> gestione del sistema qualità - Profilo professionale - Requisiti per l’assunzione di un ruolo in un progetto - Competenze tecnologiche e metodologiche - Esperienza espresse in anni e partecipazione a progetti Analisti e progettisti - Analisti - Conoscono il dominio ed hanno cospicua esperienza professionale - Hanno grande impatto sul successo del progetto - Sono pochi. Raramente seguono il progetto fino alla conclusione - Spesso passano presto al progetto successivo - Progettisti - Hanno competenze tecniche e tecnologiche aggiornate ed esperienza professionale - Hanno grande impatto sugli aspetti tecnici e tecnologici del progetto. Spesso ne assumono responsabilità di scelta e gestione - Sono pochi. Talvolta seguono il prodotto fino alla manutenzione Programmatori e verificatori - Programmatori - Partecipano alla realizzazione e manutenzione del prodotto - Hanno competenze tecniche, visione e responsabilità circoscritte - Formano la categoria storicamente più numerosa - Partecipano anche alla manutenzione - Verificatori - Partecipano all’intero ciclo di vita - Hanno competenze tecniche, conoscenza delle norme, esperienza di progetto - Hanno capacità di giudizio e di relazione Responsabile di progetto - Rappresenta il progetto - Accentra le responsabilità di scelta e approvazione - Partecipa al progetto per tutta la sua durata - È difficilmente sostituibile - Responsabilità - Pianificazione - Gestione delle risorse umane - Controllo e coordinamento - Deve avere conoscenze e capacità tecniche - Per comprendere ed anticipare l’evoluzione del progetto Amministrazione di progetto - Controllo dell’ambiente di sviluppo - Amministrazione delle risorse e delle infrastrutture - Risoluzione di problemi legati all’ambiente e al processo - Gestione della documentazione di progetto (librarian) - Controllo di versioni e configurazioni - Funzione o ruolo? - Funzione in aziende molto strutturate, con progetti simili - Ruolo (spesso su più persone) in progetti diversificati Controllo della qualità - La funzione di più recente introduzione - Funzione e non ruolo! - Accertamento della qualità - Dei prodotti e dei processi - Sia verso il committente che verso la direzione aziendale - Dare confidenza - Definendo e manutenendo i processi aziendali (PDCA) - Verificandone la corretta applicazione Pianificazione di progetto - Definizione delle attività - Per pianificarne lo svolgimento e controllarne l’attuazione - Per avere una base su cui gestire l’allocazione delle risorse - Per stimare e controllare scadenze e costi - Strumenti per la pianificazione - Work Breakdown Structure - Diagrammi di Gantt - ("Work, Wages and Profit“, Henry L. Gantt, The Engineering Magazine, NY, 1910 ) - Programme Evaluation and Review Technique (PERT) Work Breakdown Structure - Struttura gerarchica delle attività - Ogni attività si compone di sottoattività - Non necessariamente sequenziali - Univocamente identificate Diagrammi di Gantt - Dislocazione temporale delle attività - Per rappresentare la durata - Per rappresentare sequenzialità e parallelismo - Per confrontare le stime con i progressi Diagrammi PERT - Dipendenze temporali tra attività - Per ragionare sulle scadenze di un progetto - Slack time, free slack, total slack, … - Cammino critico Allocazione delle risorse - Assegnare attività a ruoli e ruoli a persone - Problemi - Non sottostimare - Non sovrastimare - Risorse impegnate su progetti diversi - Per non correre il rischio di sottoallocare - Per far fronte alle richieste dei clienti (mai dire di no) - Cammini critici su più progetti Stima dei costi di progetto - Come pianificare? - Gli strumenti permettono di organizzare le attività - Gli strumenti permettono di evidenziare le criticità - Gli strumenti permettono di studiare scenari diversi - Ma come definire durata e costo delle attività? - Tempo/persona - Unità di misura del tempo necessario a un progetto - Come stimare il tempo/persona? Fattori di influenza - Dimensione del progetto - Esperienza del dominio - Tecnologie adottate - Ambiente di sviluppo - Qualità richiesta dei processi Tecniche di stima - Legge di Parkinson - 1951, C Northcote Parkinson, Parkinson's Law: The Pursuit of Progress : “Work expands to fill the time available” - Prezzo per vincere - Giudizio dell’esperto - Stima per analogia - Modello algoritmico dei costi Constructive Cost Model - Stima le risorse necessarie, in Mesi/Persona - Software Engineering Economics, B. Boehm, Prentice-Hall, 1981 - Utilità di prova : http://www1.jsc.nasa.gov/bu2/COCOMO.html - M/P = C * (D**S) * M - C fattore di complessità del progetto - D misura della dimensione stimata del prodotto - S esponente di complessità - M fattore derivante dalla valutazione di altri attributi - D = KDSI (Kilo Delivered Source Instructions) CoCoMo in versione base - Bassa complessità di progetto: “Simple” - È possibile avere una visione globale del prodotto - C = 2.4, S = 1.05, M = 1 [Organic] - Complessità media: “Moderate” - Il prodotto può essere compreso solo per componenti - C = 3.0, S = 1.12, M = 1 [Semi-detached] - Complessità elevata: “Embedded” - Il prodotto interagisce con componenti ed ambiente esterne/o - C = 3.6, S = 1.20, M = 1 Stime CoCoMo Raffinamenti di modello - Intermediate CoCoMo - Effort Adjustment Factors : fattori moltiplicativi - Attributi di prodotto - affidabilità, categorie, … [1) - Attributi tecnologici - piattaforma, strumenti, … [1) - Attributi del personale - esperienza, competenza, … [1) - M/P = F * C * (D**S) * M, con F = Prod(i) f_i - Detailed CoCoMo - Decomposizione del progetto - Stima “intermediate” per singole componenti - Composizione dei risultati - Modello avanzato: - http://sunset.usc.edu/research/COCOMOII Rischi di progetto - Risultati dei progetti software - Costi eccessivi, scadenze non rispettate - Prodotti insoddisfacenti - Perché? - Studio Standish Group (1995) - Analisi delle cause dei fallimenti - L’affidabilità di altri settori produttivi deriva dall’esperienza Categorie di progetti - Progetti di successo - In tempo, senza costi aggiuntivi, prodotto soddisfacente - 16.2% dei progetti (dati USA 1994) - Progetti a rischio - Fuori tempo, o con costi aggiuntivi, o con prodotto difettoso - 52.7%, con media dei costi al 189% delle stime iniziali - Fallimenti - Progetti cancellati prima della conclusione - 31.1% Fattori di successo - Coinvolgimento del cliente 15.9% - Supporto della direzione esecutiva 13.9% - Definizione chiara dei requisiti 13.0% - Pianificazione corretta 9.6% - Aspettative realistiche 8.2% - Personale competente 7.2% Fattori di fallimento - Requisiti incompleti 13.1% - Mancato coinvolgimento del cliente 12.4% - Mancanza di risorse 10.6% - Aspettative non realistiche 9.9% - Mancanza di supporto esecutivo 9.3% - Fluttuazione dei requisiti 8.7% La situazione 10 anni dopo - CHAOS Chronicles 2004 (10a edizione) - Oltre 40.000 progetti USA studiati in 10 anni - Costo complessivo dei progetti : 255 miliardi $ (era 250) - Progetti finiti con successo : 34% (era 16,2%) - Importante miglioramento nelle tecniche di gestione - Progetti falliti : 15% (era 31,1%) - Danno economico : 55 miliardi $ (era 140) - Eccesso di costo : 43% (era 180%) Riferimenti - Software Project Managenment Technology Report, STSC Technical Report, 2000, http://www.stsc.hill.af.mil/index.asp - A. Alessandroni, “La stima dei costi dei sistemi informativi automatizzati”, AIPA, http://www.aipa.it - B. Boehm e altri, “Cost Models for Future Software Life Cycle Processes: CoCoMo II”, Centre for Software Engineering, http://sunset.usc.edu/ - Standish Group, “The CHAOS Report”, http://www.pm2go.com/sample_research/index.asp