3. SOFTWARE MANAGEMENT Software project management
annuncio pubblicitario
3. SOFTWARE MANAGEMENT ¾ ¾ ¾ A.Cortesi Introdurre caratteristiche e problematiche della direzione di progetto software (software management) Discutere la pianificazione di un progetto e la temporizzazione (scheduling) Presentare rappresentazioni grafiche della pianificazione di un progetto Ingegneria del Software Slide 1 Software project management ¾ ¾ ¾ ¾ A.Cortesi Sono le attività necessarie per assicurare che un prodotto software sia sviluppato rispettando le scadenze fissate e risponda a determinati standard Interazione di aspetti economici e tecnici Un progetto diretto bene qualche volta fallisce, uno diretto male fallisce sicuramente L’importanza dell’esperienza Ingegneria del Software Slide 2 Che cos’è un progetto… Un progetto è un insieme ben definito di attività che 9 ha un inizio 9 ha una fine 9 realizza un obiettivo 9 è realizzato da un’equipe di persone 9 utilizza un certo insieme di risorse 9 non è riconducibile a “routine” ¾ A.Cortesi Ingegneria del Software Slide 3 Problemi ¾ ¾ ¾ ¾ A.Cortesi Il prodotto software è “intangibile”: per valutare i progressi ci si deve basare sulla documentazione L’ingegneria del software non è ancora riconosciuta come disciplina “solida”al pari dell’ingegneria meccanica, elettrica, Non ci sono standard per il processo di produzione software Ogni progetto ha una storia a sé (problemi di scheduling) Ingegneria del Software Slide 4 I giocatori in campo... ¾ Senior managers 9 ¾ Project managers 9 ¾ specificano i requisiti del software da sviluppare End users 9 A.Cortesi hanno le competenze tecniche per realizzare il sistema Customers 9 ¾ pianificano, motivano, organizzano e controllano lo sviluppo Practitioners 9 ¾ definiscono i termini economici del progetto interagiscono con il sistema una volta realizzato Ingegneria del Software Slide 5 Perché c’è bisogno di un team? ¾ A.Cortesi La maggior parte dei progetti software sono troppo impegnativi per essere realizzati da una sola persona Ingegneria del Software Slide 6 The mythical man/month ¾ Perché non calcolare la “forza lavoro” in termini di mesi uomo necessari? 9 ¾ Persone/mese * Tempo allocato = Numero_Persone_Necessarie Questa equazione non può essere utilizzata perché: 9 9 Alcuni compiti possono essere condivisi, altri no Esempio: raccogliere fragole vs. produrre un bambino overhead necessario per il coordinamento e la comunicazione A.Cortesi Ingegneria del Software Slide 7 Tipologie di team (1) ¾ Democratico Decentralizzato 9 9 9 ¾ Vantaggi 9 9 ¾ Attitudine positiva a ricercare presto gli errori Funziona bene per problemi “difficili” (ad esempio per la ricerca) Svantaggi 9 9 A.Cortesi Assenza di un leader permanente Consenso di gruppo sulle soluzioni e sulla organizzazione del lavoro Comunicazione orizzontale È difficile da imporre… Non è scalabile... Ingegneria del Software Slide 8 Tipologie di team (2) Controllato Decentralizzato ¾ 9 9 9 Un leader riconosciuto, che coordina il lavoro La risoluzione dei problemi è di gruppo, ma l’implementazione delle soluzioni è assegnata a sottogruppi da parte del leader Comunicazione orizzontale nei sottogruppi e verticale con il leader A.Cortesi Ingegneria del Software Slide 9 Tipologie di team (3) ¾ Controllato Centralizzato 9 9 A.Cortesi Il team leader decide sulle soluzioni e sull’organizzazione Counicazione verticale tra team leader e gli altri membri Ingegneria del Software Slide 10 Ruoli in un team Controllato Decentralizzato ¾ Project Manager 9 ¾ Technical staff 9 ¾ supporta il project manager ed è responsabile della validazione Software librarian 9 A.Cortesi conduce l’analisi e lo sviluppo (da 2 a 5 persone) Backup engineer 9 ¾ pianifica, coordina e supervisiona le attività del team mantiene e controlla la documentazione, i listati del codice, i dati... Ingegneria del Software Slide 11 spazio condiviso & risultati condivisi ¾ ¾ ¾ ¾ ¾ A.Cortesi Un team deve prima di tutto decidere gli strumenti che permettono la cooperazione La pianificazione Chi fa cosa Le scelte fatte Cosa è stato fatto Ingegneria del Software Slide 12 Le attività del project manager ¾ ¾ ¾ ¾ ¾ ¾ A.Cortesi Stesura della proposta di progetto Stima del costo del progetto Pianificazione (planning) e temporizzazione (scheduling) Monitoraggio e revisioni del progetto Selezione e valutazione del personale Stesura di rapporti e presentazioni Ingegneria del Software Slide 13 Stimare i costi di un progetto ¾ Dilaziona la stima fino a quando il progetto non è in stato avanzato di sviluppo - modello non praticabile: la stima dev’essere fatta all’inizio ¾ Basa la stima su progetti simili già sviluppati - similarità di problemi, clienti, ecc. ¾ Usa tecniche di decomposizione per generare stime di costo e di risorse necessarie - approccio “divide et impera”, calcolando il costo delle componenti ¾ A.Cortesi Usa uno o più modelli empirici - basati su dati storici, es. COnstructive COst MOdel (Boehm, 1981) Ingegneria del Software Slide 14 Stime quantitative: LOC ¾ ¾ KLOC = Migliaia di linee di codice Metriche: 9 9 9 9 9 9 ¾ ¾ $ per KLOC errori o difetti per KLOC LOC per mese/persona pagine di documentazione per KLOC errori/mese-persona $/pagina di documentazione Il codice è il prodotto tangibile del processo di sviluppo, ed esiste già letteratura in proposito Dipende dal linguaggio di programmazione e penalizza programmi scritti bene e concisi A.Cortesi Ingegneria del Software Slide 15 Stime quantitative: FP ¾ Function Points: la funzionalità offerta dall’applicazione, a partire dal dominio informativo e da un giudizio sulla complessità del software ¾ Parametri ¾ FP = totale * [0.65 + 0.01 * Σ Fi] numero di user inputs numero di user output numero di richieste numero di files numero di interfacce esterne Fattori di Peso Fi 3 4 3 7 5 4 5 4 10 7 6 7 6 15 10 dove gli Fi sono fattori di aggiustamento A.Cortesi Ingegneria del Software Slide 16 LOC/FP A.Cortesi Linguaggio di programmazione LOC/FP media Assembler C Fortran Cobol Pascal Ada linguaggi orientati agli oggetti fogli di calcolo (spreadsheets) linguaggi grafici 320 128 105 105 90 70 30 6 4 Ingegneria del Software Slide 17 Struttura del piano di progetto 1. Introduzione 2. Organizatione del Progetto 3. Processi Gestionali 4. Processi Tecnici 5. Pianificazione del lavoro, delle risorse umane e del budget. A.Cortesi Ingegneria del Software Slide 18 1. Introduzione 1.1 Overview del Progetto 9 Descrizione di massima del progetto e del prodotto. 1.2 Deliverables del Progetto 9 Tutti gli items che saranno consegnati, con data e luogo di consegna 1.3 Evoluzione del SPMP 9 Piani per cambiamenti ipotizzabili e non 1.4 Materiale di riferimento 9 Lista dei documenti cui ci si riferisce nel SPMP 1.5 Definizioni e Abbreviazioni A.Cortesi Ingegneria del Software Slide 19 2. Organizzazione del progetto 2.1 Modello del Processo 9 Relazioni tra le varie fasi del processo 2.2 Struttura Organizzativa 9 Gestione interna, chart dell’organizzazione 2.3 Interfacce Organizzative 9 Relazioni con altre entità 2.4 Responsabilità di Progetto 9 9 9 A.Cortesi Principali funzioni e attività; Di che natura sono? Chi ne è il responsabile ? Ingegneria del Software Slide 20 3. Processi gestionali 3.1 Obiettivi e Priorità 3.2 Assunzioni, Dipendenze, Vincoli 9 Fattori esterni 3.3 Gestione dei rischi 9 Identificazione, Valutazione, Monitoraggio dei rischi 3.4 Meccanismi di monitoraggio e di controllo 9 Meccanismi di reporting, format, flussi di informazione, revisioni 3.5 Pianificazione dello staff 9 A.Cortesi Skill necessari (cosa?, quanto?, quando?) Ingegneria del Software Slide 21 4. Processi tecnici 4.1 Metodi, Strumenti e Tecniche 9 9 Sistemi di calcolo, metodi di sviluppo, struttura del team, ecc. Standards, linee guida, politiche. 4.2 Documentazione del Software 9 Piano di documentazione, che deve includere milestones, e revisioni 4.3 Funzionalità di supporto al progetto 9 9 A.Cortesi Pianificazione della qualità Pianificazione della gestione delle configurazioni Ingegneria del Software Slide 22 5. Pianificazione del lavoro, delle risorse umane e del budget. 5.1 Work Packages (Work breakdown structure) 9 Il progetto è scomposto in tasks; definizione di ciascun task 5.2 Dipendenze 9 Relazioni di precedenza tra funzioni, attività e task 5.3 Risorse Necessarie 9 Stima delle risorse necessarie, in termini di personale, di tempo di computazione, di hardware particolare, di supporto software ecc. 5.4 Allocazione del Budget e delle Risorse 9 Associa ad ogni funzione, attività o task il costo relativo 5.5 Pianificazione 9 Deadlines e Milestones A.Cortesi Ingegneria del Software Slide 23 Analisi dei rischi ¾ Identificazione dei rischi 9 9 9 9 9 9 9 ¾ ¾ A.Cortesi legati alla taglia del prodotto da costruire o modificare legati ai vincoli importi dal mercato o dal contratto legati alle caratteristiche del cliente legati alla buona definizione del processo legati all’ambiente di sviluppo (qualità e affidabilità degli strumenti) legati alla complessità del sistema da costruire e alle novità tecnologiche legate al sistema legati alla dimensione e all’esperienza del team di sviluppo Sviluppare una tabella: probabilità e impatto Strategia di gestione: evitare/monitorare/gestire Ingegneria del Software Slide 24 Pianificazione del lavoro f1:Function p:Project f2:Function a1:Activity a2:Activity a2.1:Activity t1:Task A.Cortesi a3:Activity a2.2:Activity t2:Task a2.3:Activity t3:Task t4:Task Ingegneria del Software Slide 25 Attività f1:Function p:Project f2:Function a1:Activity a2.1:Activity t1:Task A.Cortesi a2:Activity Unità principali di lavoro, con date di consegna precise a2.2:Activity Scomponibili in una serie di tasks t2:Task t3:Task Ingegneria del Software Culminano in una milestone Slide 26 Organizzazione delle attività ¾ ¾ ¾ ¾ A.Cortesi In un progetto le attività devono essere organizzate in modo da produrre risultati valutabili dal management Milestones sono i punti finali di ogni singola attività di processo Deliverables sono i risultati che sono forniti al committente Il modello a cascata suggerisce una definizione ovvia di “milestone” Ingegneria del Software Slide 27 Milestones & deliverables ACT IVITIES Feasibility study Requir ements analysis Prototype development Design study Requir ements specification Feasibility report Requir ements definition Evaluation report Architectural design Requir ements specification MILESTONES A.Cortesi Ingegneria del Software Slide 28 Funzioni ¾ Actività o insiemi di attività che coprono tutta la durata del progetto 9 9 9 9 9 A.Cortesi Project management Configuration Management Documentation Quality Control (Verification and validation) Training Ingegneria del Software Slide 29 Tasks ¾ Unità di lavoro “atomiche” 9 ¾ Specifica di un task: Work package 9 9 9 9 A.Cortesi Hanno durata stimabile, necessitano di certe risorse, producono risultati tangibili (documentazione, codice, ...) Nome e descrizione del lavoro che deve essere fatto Precondizioni per poter avviare il lavoro, durata, risorse necessarie Risultato del lavoro e criteri di accettabilità Rischi Ingegneria del Software Slide 30 Scheduling di progetto ¾ ¾ ¾ ¾ A.Cortesi Dividi il progetto in attività e mansioni (tasks) e stima il tempo e le risorse necessarie per completare ogni singola mansione Organizza le mansioni in modo concorrente, per ottimizzare la forza lavoro Minimizza la dipendenza tra le singole mansioni per evitare ritardi dovuti all’attesa del completamento di un’altra mansione Sono necessari intuito ed esperienza Ingegneria del Software Slide 31 Problemi nello scheduling ¾ ¾ ¾ ¾ A.Cortesi E’ difficile stimare la difficoltà dei problemi ed il costo di sviluppo di una soluzione La produttività non è proporzionale al numero di persone che lavorano su una singola mansione Aggiungere personale in un progetto in ritardo può aumentare ancora di più il ritardo Imprevisti succedono sempre... Ingegneria del Software Slide 32 Grafico a barre, grafo delle attività e diagramma di Gannt ¾ ¾ ¾ ¾ ¾ Diversi tipi di rappresentazione grafica dello scheduling del progetto Mostrano la suddivisione del lavoro in mansioni. Le mansioni non devono essere troppo piccole (una settimana o due di lavoro) Il grafo delle attività evidenzia le dipendenze e il cammino critico Il grafico a barre mostra lo scheduling come calendario lavori Il diagramma di Gannt per la temporizzazione A.Cortesi Ingegneria del Software Slide 33 Mansioni: durata e dipendenze Mansioni T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 A.Cortesi Durata (giorni) 8 15 15 10 10 5 20 25 15 15 7 10 Ingegneria del Software Dipendenze T1 T2, T4 T1, T2 T1 T4 T3, T6 T5, T7 T9 T11 Slide 34 Network delle attività 1 5 d ay s 1 4/ 7/ 94 M1 8 day s T9 T1 2 5/ 7/ 94 4/ 7/ 94 5 d ays 4/ 8/ 94 2 5/ 8/ 94 T6 M4 M6 M3 s tart 1 5 d ay s T3 7 day s 2 0 d ay s 1 5 d ay s T1 1 T7 T2 2 5/ 7/ 94 1 0 d ay s M2 T4 5/ 9/ 94 1 1/ 8/ 94 1 0 d ay s M7 T5 M8 1 5 d ay s T1 0 1 8/ 7/ 94 10 days T1 2 M5 2 5 d ay s T8 A.Cortesi Fi ni sh 1 9/ 9/ 94 Ingegneria del Software Slide 35 Temporizzazione delle attività 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 Start T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T10 M6 T1 1 M8 T12 Finish A.Cortesi Ingegneria del Software Slide 36 Allocazione della forza lavoro 4/7 Fred 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 T4 T8 T11 T12 Jane T1 T3 T9 Anne T2 T6 Jim Mary A.Cortesi T10 T7 T5 Ingegneria del Software Slide 37 Pianificazione collaborativa A.Cortesi Ingegneria del Software Slide 38 A.Cortesi Ingegneria del Software Slide 39 Sommario parte introduttiva ¾ ¾ ¾ A.Cortesi Prodotto software & processo software 9 9 Modelli di processo: a cascata, evolutivi, a spirale Visibilità del processo di sviluppo software 9 9 9 9 9 ambiente acquisizione di sistemi Processo di sviluppo di un sistema Modello di architettura di un sistema Affidabilità di un sistema 9 9 Pianificazione di progetto Organizzazione e scheduling Progettazione di sistemi Project Management Ingegneria del Software Slide 40
