Leveling delle attività

Transcript

1 Leveling delle attività Metodi per risolvere i conflitti di allocazione delle attività Allocare in modo non-uniforme Ritardare un attività Prima le attività con slack più alto Nel caso di attività con priorità Prima le attività a più bassa priorità e con lo slack più alto Frammentare un attività Aggiungere risorse

2 Controllo della gestione di un progetto Esaminare periodicamente lo stato dei lavori allo scopo di verificare che gli obiettivi vengano raggiunti secondo i piani iniziali relativamente a scadenze temporali, e costi sostenuti; la qualità del prodotto ottenuto verifichi gli standard di produzione prefissati.

3 Piano di progetto È un documento versionato, redatto dal project manager per poter stimare realisticamente le risorse, i costi e i tempi necessari alla realizzazione del progetto. Il piano di progetto si divide in due parti, pianificazione e consuntivazione, per rendere possibile la pianificazione delle attività future e il riscontro tangibile tra le attività effettuate e quelle previste. Il piano di progetto è un documento che varia nel tempo a seconda delle situazioni e dell evolversi delle attività portate avanti dai membri. Una parte del documento, il diario delle modifiche, tiene traccia delle variazioni apportate al piano, registrando la data delle modifiche e la versione del piano. Il piano del progetto contiene la descrizione delle attività pianificate 1. Definizione degli obiettivi 2. Analisi dei rischi (piano gestione rischi, sintesi rischi individuati e strategie di prevenzione) 3. Descrizione del modello di processo di sviluppo Descrizione fasi (milestones) del processo 4. Suddivisione in sottosistemi 5. Attività di progetto (Work Breakdown Structure. Diagramma di Pert, Diagramma di Gantt) 6. Stima dei costi 7. Consuntivo attività La documentazione inerente il controllo del progetto prevede almeno (1) una tabella nella quale per ogni attività si evincano i partecipanti con i rispettivi monte ore, (2) una tabella nella quale per ogni membro del gruppo si evincano le attività a cui egli ha preso parte ed il totale numero di ore di lavoro.

4 Stima delle risorse nello sviluppo del software 1 Fare una stima delle risorse impiegate in un progetto è un processo laborioso Avere delle sorprese sui costi finali così come non riuscire a rispettare lo schedule sono spesso frutto di un processo di stima insoddisfacente Una pianificazione efficace dello sviluppo di un software dipende dall accuratezza delle stime delle risorse che a loro volta si relazionano con accurate stime della dimensione del software Sebbene le stime dei costi e dello schedule per lo sviluppo del software vengano spesso dettate dall alto, l ingegnere del software deve fare lo stesso una stima più accurata possibile, basata sulle dimensioni del software.

5 Stima delle risorse nello sviluppo del software 2 Problema di stimare il numero di mesi di lavoro e il tempo necessario per sviluppare un prodotto software Certe caratteristiche ed attributi del prodotto Le condizioni sotto cui il prodotto software deve essere sviluppato La dimensione del software (SLOC, FP)

6 Risorse per sviluppare un prodotto software Lavoro: gli sforzi di tutti coloro i quali sono impegnati nello sviluppo del prodotto i costi del lavoro vengono spesso calcolati in termini di produttività (SLOC/mese uomo, FP/mese uomo) Tempo di sviluppo del software: dall analisi dei requisiti alla consegna Mezzi di produzione: ambiente di sviluppo

7 Stime sulle risorse Le stime sulla risorsa lavoro sono dette stime dei costi Le stime sul tempo di sviluppo sono dette stime dello schedule

8 Costi di produzione del software Meeting con il cliente e discussioni Revisioni formali di sviluppo e pubblicazione della specifica dei requisiti Comunicazione con altre squadre che lavorano su altre componenti del prodotto software Manager e segretari Mantenimento di tool (compilatori, debugger,..) Supporto per il training e la documentazione del prodotto Sviluppo di casi di test e relativa documentazione Garanzia della qualità Svese di viaggio Sviluppo, revisione e pubblicazione della specifica di sistema Walk-through del codice, revisione, audit Il tempo e il denaro speso per queste attività può raggiungere l 80% del costo e dello schedule totale

9 Alcuni punti importanti sulle stime 1. Le stime di costo e schedule devono essere condotte in maniera seria e professionale 2. La dimensione del software gioca un ruolo importante nel calcolo delle stime 3. Bisogna cercare di postporre eventuali negoziazioni a quando è disponibile una buona stima 4. Il rapporto fra la stima e il valore effettivo di un attributo è una guida nell identificare eventuali aree di rischio, nel ridurre i costi ed aumentare la probabilità di successo del progetto 5. Le stime dei costi e dello schedule sono procedimenti iterativi 6. L ingegnere del software deve giocare un ruolo attivo nello sviluppo delle stime e nel mantenerle aggiornate

10 Inoltre A volte il costo del software e lo schedule vengono annunciati dalla gestione (gara d appalto) o dal cliente (quantità limitata di risorse) L ingegnere del software non è assolto dalla responsabilità di aiutare a produrre la migliore stima di tempi e costi consistente con la data La stima può essere fatta da un consulente esterno Bisogna comunque essere in grado di revisionarla e comprenderla

11 Il modello COCOMO CoCoMo (Constructive Cost Model) è un metodo di stima dei costi di sviluppo del software, basato su un modello algoritmico ideato da Bohem (versioni ) Bohem arrivò alla formulazione del suo modello studiando attentamente i dati relativi a 63 progetti software completi (piccoli 5000 SLOC, grandi oltre 1 milione SLOC) CoCoMo assume che lo sviluppo software si svolga secondo il ciclo di vita a cascata

12 Il modello COCOMO L equazione generale usata per computare la componente del numero di mesi uomo è LM = a * (KSLOC) b Tempo di sviluppo: DT = c * (LM) d

13 Il modello COCOMO E importante calcolare le dimensioni del prodotto software nella maniera migliore possibile Nel computo fare la giusta distinzione fra codice nuovo, riutilizzato, tenendo in considerazione anche i commenti

14 Il modello COCOMO Comprende tre diversi livelli di stima Di base: utilizzato per stime approssimate, veloci e premature. La sua accuratezza è limitata dal non utilizzo di dati dettagliati Intermedio: fornisce una stima più accurata grazie alla considerazione di fattori riguardanti l ambiente di sviluppo del progetto software, in termini del loro effetto complessivo sui parametri del progetto Dettagliato: fornisce la miglior stima in quanto tiene conto dei fattori dell ambiente del progetto software in ogni fase del progetto Che portano ad una stima via via più aderente alla situazione effettiva

15 Il modello COCOMO di base Il modello CoCoMo di base distingue tre modalità di sviluppo del software: Organic mode: il team di sviluppo consiste di un numero piccolo di sviluppatori di esperienza che hanno familiarità con l area di applicazione e con l ambiente di sviluppo. Le dimensioni del prodotto sono da piccole a medie Semidetached mode: il team di sviluppo consiste di un misto di persone con e senza esperienza, che lavorano insieme da poco. La dimensione del prodotto può variare da media a molto grande Embedded mode: richiede la maggior quantità di risorse: il prodotto ha requisiti stringenti riguardo ad affidabilità, performance, schedule, interfacce esterne. Inoltre richiede un ambiente di sviluppo altamente controllato, revisioni frequenti. Il problema che viene risolto è di dimensioni medio grande e generalmente complesso

16 Le equazioni Organic mode: 1.05 LM = 2.4 * (KSLOC) 0.38 DT = 2.5 * (LM) Semidetached mode: 1.12 LM = 3.0 * (KSLOC) 0.35 DT = 2.5 * (LM) Embedded mode: 1.20 LM = 3.6 * (KSLOC) 0.32 DT = 2.5 * (LM)

17 Relazione fra impegno e dimensione (by G.Raiss Università la Sapienza)

18 Modello COCOMO intermedio Mantiene la stessa distinzione fra tipi di progetto Introduce 15 nuovi parametri (Cost drivers) che permettono agli attributi del prodotto, del sistema, dell ambiente di lavoro e del prodotto, di influire sul calcolo dellla stima dei costi e dello schedule Il valore di questi parametri è determinato dall analista in base alla sua esperienza, considerando lo specifico progetto e le tabelle fornite da CoCoMo Attraverso i valori assegnati ai 15 attributi cost driver, è possibile calcolare un fattore di aggiustamento che tenga conto delle caratteristiche del progetto in questione

19 Prodotto: Attributi cost driver CPLX: product ComPLeXity ( ) Quantifica l effetto della complessità globale del prodotto RELY: REquired software reliability ( ) Quantifica l effetto dell affidabilità richiesta DATA: DATA base size ( ) Quantifica l effetto della dimensione del database usato dal sistema

20 Attributi cost driver Sistema: TIME: execution TIME constraint ( ) Quantifica l effetto dei vincoli nel tempo di esecuzione STOR: main STORage constraint ( ) Quantifica l effetto relativo ai requisiti di memoria centrale richiesti dal software VIRT: VIRTual machine volatility ( ) frequenza con cui le caratteristiche del sistema target vengono modificate durante lo sviluppo TURN: computer TURNaround time ( ) Quantifica l effetto dei vincoli nei tempi di risposta

21 Attributi cost driver Personale: ACAP: Analyst CAPability ( ) Quantifica l effetto dell efficienza del personale addetto all analisi AEXP: Application EXPerience ( ) Quantifica l effetto dell esperienza del team nell applicazione software corrente PCAP: Programmer CAPability ( ) Quantifica l effetto dell efficienza del personale di programmazione VEXP: Virtual machine EXPerience ( ) Quantifica l effetto dell esperienza del personale di programmazione con la macchina virtuale host LEXP: (programming) Language EXPerience ( ) Quantifica l esperienza del personale di programmazione con il linguaggio di programmazione che viene utilizzato

22 Attributi cost driver Progetto: MODP: MODern Programming practices ( ) Quantifica l effetto dell utilizzo di tecniche di programmazione moderne TOOL: Use of software TOOLs ( ) Quantifica l effetto dell utilizzo di strumenti per lo sviluppo software avanzati SCED: SChEDule constraints ( ) Quantifica l effetto dei vincoli di tempo per la conclusione del progetto

23 Valutare attributi cost driver - esempio Per valutare l influenza sul progetto dei fattori che riguardano l esperienza del personale utilizzato (3 fattori AEXP, VEXP, LEXP), si potrebbero usare questi criteri di classificazione dell esperienza del personale: Very Low Low Nominal High 2 4 mesi di esperienza 6 8 mesi di esperienza 1 1,5 anni di esperienza 2 3 anni di esperienza

24 Le equazioni L effetto complessivo degli attributi cost driver viene computato come il prodotto dei valori di ciascuno dei 15 attributi: C = C1 * C2 * * C15 dove Ci è il valore dell i-esimo attributo cost driver

25 Le equazioni Organic mode: 1.05 LM = 3.2 * (KSLOC) * C 0.38 DT = 2.5 * (LM) Semidetached mode: 1.12 LM = 3.0 * (KSLOC) * C 0.35 DT = 2.5 * (LM) Embedded mode: 1.20 LM = 2.8 * (KSLOC) * C 0.32 DT = 2.5 * (LM)

26 Parti che il modello COCOMO non copre Lo sforzo di raccolta dei requisiti Training dell utente Installazione Mantenimento post-consegna Amministrazione della base di dati ALM = LM * 1.20 ADT = DT * 1.10

27 Il modello COCOMO dettagliato Considera che l influenza sul progetto degli stessi 15 fattori di complessità del modello intermedio vari in funzione delle fasi del processo di sviluppo del software Esempio Cost driver ACAP Rating PD DD CUT IT Very Low Low Nominal High Very high

28 Considerazioni su COCOMO Modello base errore < 20 % nel 60% dei casi Modello intermedio errore < 20% nel 68% dei casi Modello avanzato errore < 20% nel 70% dei casi Le SLOC sono poco utilizzabili nelle fasi iniziali del processo di sviluppo Non sono adeguate nel caso di linguaggi avanzati

29 COCOMO II Negli anni 90 fu introdotto un modello che si potesse adattare meglio ai nuovi processi di sviluppo (riuso, applications composition, approccio object-oriented,..) Si adatta a diversi modelli di processo La granularità della stima deve essere consistente rispetto alla granularità delle informazioni disponibili

30 Modello rudimentale Monte ore medio: 120 ore/persona Salario: Leader: 50 /ora Analista: 40 /ora Programmatore: 38 /ora