Ingegneria del Software. MINR a.a Prof. Giuseppe Santucci Project management. Project management

Transcript

1 Ingegneria del Software MINR a.a Prof. Giuseppe Santucci 04 - Project management 04Prman.1 Project management I. Concetti fondamentali II. Pianificazione temporale e controllo III. Gestione delle configurazioni SW 04Prman.2

2 I. Concetti fondamentali L importanza del project management Le quattro P del project management Persone Problema Processo Progetto 04Prman.3 L importanza di un Project Management efficace L obbiettivo di ogni progetto è la realizzazione di un prodotto nel rispetto di vincoli di: tempi costi qualità 04Prman.4

3 L importanza di un Project Management efficace (2) Rischi conseguenti ad un Project Management inadeguato: Utili attesi trasformati in perdite (costi eccessivi, ritardi, penali, immagine) Ritardata presenza sul mercato Ritardo sui progetti di R&S con scarsa utilizzazione da parte delle linee produttive Scarsi e inefficaci controlli e valutazioni dei progetti causano l identificazione di eventuali errori e problemi troppo tardi rispetto alla possibilità di recupero 04Prman.5 Ostacoli al PM Attività spesso ostacolata dai dirigenti e dai tecnici con cultura organizzativa gerarchica tradizionale e scarsa cultura di moderne tecniche di gestione Costi aggiuntivi (5-7 %) Richiede una comprensione dettagliata del problema 04Prman.6

4 Le quattro P del project management 1. Persone motivate / esperte SEI PM-CMM (People Management Capability Maturity Model) assunzione / selezione addestramento / cultura di gruppo stipendio / carriera 2. Problema prima della pianificazione occorre identificare chiaramente: gli obbiettivi le soluzioni possibili i vincolialcontorno ottenendo informazioni di tipo quantitativo 04Prman.7 Le quattro P del project management (2) 3. Processo utilizzando uno dei modelli per il ciclo di vita del software occorre: individuare attività, scadenze, prodotti ed iterazioni, non trascurare le attività trasversali, quali, ad esempio, il controllo qualità, le misure e la gestione delle versioni 4. Progetto Molti progetti (~20%) non vengono mai terminati Moltissimi (~40%) subiscono levitazione dei costi ed allungamento dei tempi 04Prman.8

5 Persone coinvolte nel progetto Dirigenti (senior manager) Capi progetto (project/technical manager) Tecnici (practitioners) Elemento del gruppo (team member) Capogruppo (team leader) Cliente (customer) Utente finale (end user) La figura del capogruppo è cruciale motivare organizzare risolvere i problemi gestire il personale 04Prman.9 Il gruppo di sviluppo Scenario: Ci sono n persone che lavorano per k anni ad un progetto, assegnate ad m attività differenti. Alcune possibilità di organizzazione: 1. Le attività sono distinte: poca interazione, no gruppi 2. Nascono infomalmente gruppi e capigruppo; nasce la necessità di coordinamento fra gruppi 3. Le persone vengono divise formalmente in t gruppi, dove ogni gruppo è responsabile di una o più attività. Coordinamento: capigruppo e capoprogetto La possibilità 3 è la migliore. 04Prman.10

6 Struttura del gruppo Possibili strutture interne di un gruppo DD democratica decentralizzata assenza di capogruppo fisso (solo temporaneo) consenso collegiale comunicazione orizzontale CD controllata decentralizzata capogruppo fisso occasionali responsabili di sottoattività risoluzione di problemi per sottogruppi comunicazione orizzontale e verticale CC controllata centralizzata comunicazione verticale la prima struttura formalizzata (1972) 04Prman.11 Fattori per la scelta della struttura Fattori che influenzano la scelta della struttura del gruppo Difficoltà del problema Dimensione del problema (LOC, FP, ) Modularità del problema Qualità richieste al sistema Durata temporale del gruppo Rigidità della data di consegna 04Prman.12

7 Scelta della struttura del gruppo 04Prman.13 Formale, impersonale tool per il controllo del progetto documentazione (ad es., diagrammi, codice) prodotti intermedi scadenze controllate con tabelle dei tempi Formale, interpersonale assicurazione qualità revisioni periodiche Informale Coordinamento del gruppo riunioni diffusione risultati/scelte , forum, videoconferenze 04Prman.14

8 Scenario tipico: occorre una stima quantitativa il più presto possibile ma: un analisi dettagliata non è ancora disponibile le specifiche possono cambiare durante il progetto occorre determinare, almeno, la portata (scope) del progetto Portata: Il Problema Contesto: rapporto del software da sviluppare con il resto del sistema Obiettivi informativi: dati di ingresso e di uscita maneggiati dall utente Funzionalità e prestazioni: funzionalità da sviluppare e prestazioni particolari da raggiungere 04Prman.15 Sono molto importanti le informazioni quantitative numero di utenti massimo tempo di risposta spazio richiesto costi da non superare Il problema (2) Al più presto, decomporre il problema in un insieme di compiti (utilizzando, ad es., tecniche di analisi dei requisiti) 04Prman.16

9 Il Processo 1. Scelta di un modello A prototipo/spirale,... In ogni caso induce una sequenza di attività 2. Istanziare il problema nel modello scelto a) Creare una matrice di compiti ed attività b) Per ogni cella stimare l impegno necessario compiti 04Prman.17 Stima dell impegno Fattori che rendono difficile effettuare una stima attendibile: complessità del progetto (assoluta e relativa alle esperienze precedenti) dimensione del progetto mancanza di esperienze (e misure) pregresse informazioni inattendibili o non ufficiali 04Prman.18

10 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 (capacità + 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 utilizzare per lo sviluppo del progetto 04Prman.19 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 /P) 3 * (1/t 4 ) E =impegno (mesi uomo / anni uomo) t =durata del progetto (mesi / anni) B = fattore di competenza ( ) (5 KLOC KLOC) P = parametro di produttività ( ) - Spesso calcolato su dati storici complessità dell applicazione esperienza dei programmatori linguaggio di programmazione altro... 04Prman.20

11 Monitoraggio del progetto (quanto manca?) regola del Motivi: 1. Incomprensione esigenze clienti 2. Portata mal definita 3. Gestione inappropriata modifiche 4. Cambiamento tecnologie 5. Funzionalità mal definite 6. Date consegna irrealistiche 7. Ostilità dei clienti 8. Perdita risorse finanziarie 9. Incompetenza team Pianificazione! Il Progetto 04Prman.21 II. Pianificazione temporale Fattori che causano ritardi Persone & tempo Scelta e raffinamento attività principali Rete di attività 04Prman.22

12 Fattori che rendono probabile finire in ritardo scadenza imposta dall alto cambiamento delle specifiche che non si riflette in un cambiamento della programmazione mancata valutazione dei rischi errato calcolo dell impegno necessario difficoltà (sia tecniche sia umane) impreviste comunicazione insufficiente/errata fra il personale incapacità di accorgersi del ritardo del progetto e mancanza di adeguate azioni correttive 04Prman.23 Principi di pianificazione temporale Pianificazione temporale = scheduling Ripartizione: definire compiti ed attività Interdipendenza: comprendere le relazioni fra attività Assegnazione della durata, della data di inizio e di fine di ogni attività. Esistono unità appropriate (anno/uomo, mese/uomo) Validazione: essere sicuri che le risorse siano disponibili Responsabilità definite: assegnare persone ai compiti Risultati definiti: ogni attività ha un output Punti di controllo (milestone) definiti: revisioni per la qualità 04Prman.24

13 Persone e tempo La relazione intercorrente tra persone e tempo non è lineare coordinamento comunicazione Esempio: ogni programmatore può produrre 5000 LOC/anno lavorando da solo se due programmatori devono interagire fra loro, la loro produttività complessiva diminuisce di 250 LOC/anno ( 9.750) (2,5% in meno) qual è la produttività di un team di quattro programmatori che devono tutti interagire fra di loro? Risposta: ci sono sei canali di comunicazione (4*3)/2, quindi si perdono 250*6=1500 LOC/anno. La produttività del team è di LOC/anno (7,5% in meno) 04Prman.25 Persone e tempo (2) Anche le formule empiriche (equazione del SW) confermano che allungando il tempo di sviluppo il carico di lavoro complessivo diminuisce Il prodotto E*t 4 è costante E=(LOC*B /P) 3 * (1/t 4 ) Esempio: 1. t = 1,3 anni; E = 12 anni/uomo ----> 12/1,3 = 9.2 persone 2. t = 1,75 anni; E = 3,7 anni/uomo ----> 3.7/1.75 = 2.1 persone 04Prman.26

14 Persone e tempo (3) Distribuzione del carico di lavoro (regola ) 40 % analisi 20%codifica 40% test In realtà la regola è solo indicativa (vedi tabelle COCOMO per i vari tipi di progetto) 04Prman.27 Piano di progetto Project plan 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 qualità del prodotto viene garantita 04Prman.28

15 Programmi, progetti e compiti Programma: iniziativa a lungo termine, che può comprendere più di un progetto Progetto: sforzo complesso, durata limitata (< 3 anni) che comprende compiti interrelati eseguiti da diverse organizzazioni con obiettivi, schedulazioni e budget ben definiti Compito (task): sforzo a breve termine (3 6 mesi) eseguito da un organizzazione, che insieme ad altri compiti costituisce un progetto Work package: insieme di task correlati tra di loro 04Prman.29 Raffinamento delle attività principali Esempio: Individuare la portata del progetto (project scoping) 1.1 identificare i bisogni dell utente, i benefici e i clienti potenziali 1.2 definire le attività di input/output che controllano l applicazione Revisione formale della descrizione dei bisogni produrre una lista degli input/output visibili all utente revisione formale degli input/output con l utente 1.3 definire le funzionalità ed il comportamento per ogni funzione principale revisione formale degli input/output e degli oggetti visibili all utente prodotti dall attività produrre un modello del comportamento delle funzioni 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 fattibilità tecnica 1.7 stimare rapidamente la dimensione del progetto 04Prman.30

16 Costruire un grafo che evidenzi: la sequenza delle attività con le relative durate le possibili parallelizzazioni I.1 I.2 Rete di attività I.3a 3 I.3b 6 I.3c La notazione più usata sono i diagrammi PERT (Program Evaluation and Review Technique) ideati negli anni 50 dalla Lockheed per gestire il progetto Polaris. 6 I.4 04Prman.31 Rete di attività (2) Un nodo rappresenta una attività con il relativo tempo previsto (eventualmente una terna di valori: pessimo, verosimile ed ottimo) Un arco rappresenta una dipendenza tra le attività È possibile individuare: Il cammino critico (catena di attività che determina la durata del progetto) CPM Il maggior anticipo possibile nell iniziare un attività Il maggior ritardo possibile per un attività che non ritarda il completamento di un progetto Esistono molti strumenti sw per il calcolo automatico di tali informazioni 04Prman.32

17 Diagrammi temporali Dopo aver decomposto il progetto in task prefissati è utile costruire un diagramma temporale delle attività detto GANTT (da Henry Gantt: ) m1 fine analisi m2 fine codifica analisi studio fattibilità d1 cod. a d2 cod. b d3 codifica c d4 int. e test d5 0 6m 12m 18m 04Prman.33 Diagrammi temporali (2) Le barre orizzontali indicano la durata dei compiti Le barre orizzontali si possono sovrapporre: indica potenziale parallelismo Il GANTT riporta anche le milestone Un GANTT va integrato con un PERT per avere tutte le informazioni relative alle interdipendenze tra task Molti strumenti CASE per il project management prevedono l uso di PERT e di GANTT a vari livelli di sofisticazione 04Prman.34

18 Controllo della pianificazione Controllo della pianificazione = project tracking Pert e GANTT possono 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 verifica dell effettivo raggiungimento delle milestone inizio effettivo delle attività rispetto all inizio previsto meeting informali per individuare i possibili problemi 04Prman.35 Riassunto dei principi base per la pianificazione Scegliere un modello per il ciclo di vita del SW Dividere il progetto in macro attività usando sia la decomposizione del problema che del processo -> Insieme di work package (WP) strutturati in attività Definire i prodotti di ogni attività (deliverable) Strutturare le attività da svolgere in singoli componenti (WBS, Work Breakdown Structure, o PBS, Project Breakdown Structure) Individuare le interdipendenze tra le attività (trasversali ai WP) Definire un calendario di progetto (Phase Activity Definition) Definire l impegno del personale (Personnel Plan) Individuare le responsabilità!! 04Prman.36

19 Riassunto dei principi base per la pianificazione (2) Controllare che la pianificazione non richieda mai un impegno complessivo superiore a quello massimo disponibile! Definizione del metodo di monitoraggio del progetto Controllo dell utilizzo del personale Controllo globale delle spese Evidenziazione del rapporto tra i costi e raggiungimento degli obiettivi Controllo globale del progetto 04Prman.37 III. Gestione delle configurazioni Concetti fondamentali Esempio Processo di gestione delle configurazioni 04Prman.38

20 Concetti fondamentali In qualsiasi punto del ciclo di vita ci si trovi, il sistema cambierà, ed il desiderio di cambiarlo persisterà per tutto il ciclo di vita. Gestione delle configurazioni: principi e tecniche per individuare, organizzare, controllare le modifiche al software in corso di realizzazione: 1. Riconoscere il cambiamento 2. Controllarlo 3. Garantire corretta implementazione 4. Avvertire gli interessati 04Prman.39 Concetti fondamentali (2) Gestione delle configurazioni SW = Software configuration management Gestione delle configurazioni: Inizia con il progetto Termina quando il prodotto SW non è più operativo Manutenzione: Inizia quando il prodotto SW viene rilasciato al cliente e messo in esercizio 04Prman.40

21 Cambiamenti: Tipi di cambiamenti nelle strategie aziendali o nelle condizioni di mercato nei requisiti tecnici nei requisiti utente Si riflettono in cambiamenti: nella pianificazione del progetto nei modelli concettuali nel codice nei test nella struttura delle basi di dati nella documentazione 04Prman.41 Esempio (1) L applicazione da progettare riguarda le informazioni sulle contravvenzioni elevate in un comune. Di ogni vigile interessa il nome, il cognome ed il numero di matricola Di ogni contravvenzione interessa Di ogni veicolo interessa Il comune vuole effettuare dei controlli sul lavoro del proprio personale: dato un vigile, si vuole sapere se ha elevato una contravvenzione per più di una volta ad uno stesso veicolo; 04Prman.42

22 Esempio (2) Progettazione/Test 1. Schema concettuale (diagrammi UML delle classi e degli use case, specifiche) 2. Interfacce dei moduli SW 3. Codice Java 4. Casi di test 04Prman.43 Schema concettuale Esempio (3) 04Prman.44

23 Codice Java Esempio (4) // File Vigile.java public class Vigile { private final String nome, cognome, matricola; private InsiemeSS contravvenzioni; public Vigile(String n, String c, String m) {... } // File ControlloPersonale.java public class ControlloPersonale { public static boolean tartassatore(vigile vig) {... } 04Prman.45 Esempio (5) Casi di Test (ad es., black box) Progettazione classi di equivalenza per la funzione Java tartassatore : Criterio del numero di valori, analisi dei valori estremi : a) Vigile che non ha mai multato veicoli b) Vigile che ha multato uno stesso veicolo al più una volta c) Vigile che ha multato uno stesso veicolo due volte - Altri criteri (es. scatola bianca) Progettazione casi di test a) b) c) 04Prman.46

24 Cambiamento (1) L applicazione da progettare riguarda le informazioni sulle contravvenzioni elevate in un comune. Di ogni vigile interessa il nome, il cognome ed il numero di matricola, la data di nascita Di ogni contravvenzione interessa Di ogni veicolo interessa Il comune vuole effettuare dei controlli sul lavoro del proprio personale: dato un vigile, si vuole sapere se ha elevato una contravvenzione per più di (una volta) due volte ad uno stesso veicolo; 04Prman.47 Cambiamento (2) Il cambiamento nei requisiti si riflette in: 1. Cambiamento dello schema concettuale: 1. Il diagramma UML delle classi non è più appropriato 2. La specifica dello use case non è più appropriata Cambiamento delle interfacce dei moduli SW: La API della classe Java Vigile non è più appropriata 04Prman.48

25 Cambiamento (3) Il cambiamento nei requisiti si riflette anche in: 3. Cambiamento del codice Java 1. Vanno aggiunti costruttori e getter nella classe Java Vigile 2. Va riprogettato l algoritmo del tartassatore ; 3. Va ri-implementata la funzione Java boolean tartassatore(vigile) 4. Cambiamento dei casi di test 1. Vanno riprogettate le classi di equivalenza 2. Vanno riprogettati i casi di test 3. Vanno rieseguiti i casi di test 04Prman.49 Necessità di procedure formali Un elemento della configurazione SW (SCI, software configuration item), ovvero: una specifica un modulo SW un insieme di casi di test che sia stato revisionato ed accettato, serva da fondamento per un ulteriore sviluppo, può essere modificato solamente attraverso procedure formali di controllo del cambiamento 04Prman.50

26 Archivio di un progetto Detto anche project repository Contiene tutti gli SCI, tipicamente in tutte le versioni Può contenere anche prodotti SW per lo sviluppo (compilatori, strumenti CASE) nella versione autorizzata per il progetto Tipicamente, si lavora su copie degli SCI contenuti nell archivio Sono previsti precisi protocolli per l inserimento nell archivio 04Prman.51 Processo di gestione delle configurazioni Identificazione (delle molte versioni esistenti) Controllo della versione e dei cambiamenti (modifiche prima e dopo il rilascio al cliente) Responsabilità dell approvazione delle modifiche e della definizione delle priorità Assicurazione che le modifiche siano state eseguite correttamente Notifica agli interessati dell esecuzione delle modifiche 04Prman.52

27 Individuazione degli SCI Deve esistere uno schema concettuale degli SCI {disjoint,complete} Specifica Test Progettazione implementazione Modulo SW collaudo 04Prman.53 Individuazione degli SCI (2) Ogni SCI deve avere un nome, che comprende la versione Deve essere gestito un grafo delle trasformazioni degli SCI V 1.3 V 1.4 V 1.0 V 1.1 V 1.2 V 2.0 V 2.1 V V Prman.54

28 Controllo delle versioni Tre coordinate indipendenti: Componente (può essere presente o no) Versione (ne nasce una nuova quando uno o più componenti subiscono cambiamenti rilevanti) Variante (coesiste con altre) 04Prman.55 Controllo del cambiamento Si rileva necessità di un cambiamento Arriva una richiesta di cambiamento dall utente Valutazione da parte dello sviluppatore Viene scritto un ordine di cambiamento (ECO- Engineering change order) L autorità del controllo dei cambiamenti (CCA) decide Se la richiesta non è accolta, l utente viene informato Se la richiesta è accolta, si mette la richiesta in coda Vengono assegnate persone allo SCI Si estrae lo SCI dall archivio di progetto (check-out) Controllo degli accessi Si effettua il cambiamento (continua ) 04Prman.56

29 Controllo del cambiamento (2) Si revisiona il cambiamento (ad es., tramite ispezione) Se si tratta di codice, si riprogettano i casi di test (ad es., mediante il metodo delle basi scatola bianca) Si effettuano i test Si inserisce la nuova versione dello SCI nell archivio (check-in) Sincronizzazione Si propone l inclusione dello SCI nella release successiva Si costruisce la nuova versione Si revisiona il cambiamento (ad es., tramite test di sistema) Il cambiamento diventa effettivo nella nuova versione 04Prman.57 Controllo del cambiamento (3) Necessità di Controllo degli accessi Diritti di lettura/scrittura Sincronizzazione Meccanismi di locking/unlocking Impediscono modifiche non autorizzate, potenzialmente distruttive inutili 04Prman.58

30 Esame della configurazione La modifica specificata nell ECO è stata effettuata? È stata svolta una revisione tecnica formale? Gli standard (ad esempio per quanto riguarda il test) sono stati applicati? La modifica è stata evidenziata nello SCI (autore, data, )? Gli interessati sono stati avvertiti? Sono stati aggiornati tutti gli SCI correlati? 04Prman.59 CVS - Concurrent Versions System Free client sw Comandi checkout (importa una directory dal server) add (aggiunge un modulo locale al server) commit (propaga le modifiche locali al server) Può fallire! update (importa le mdifiche presenti sul server) Può fallire! 04Prman.60

31 Direttorio di servizio Un esempio di GUI per CVS File non modificato dall ultimo commit File modificato dall ultimo commit File non presente sul server File aggiunto temporaneamente (senza commit ) al server 04Prman.61