Struttura. Risorse informatiche. Materiali di consumo. Personale di supporto. Personale tecnico. uffici, energia elettrica,

Transcript

1 STIME DEI COSTI

2 Fonti di costi Struttura uffici, energia elettrica, Risorse informatiche hardware e software di sviluppo Materiali di consumo carta, dischetti, Personale di supporto segreteria, amministrazione, Personale tecnico programmatori, tecnici, manager,...

3 Fattori che influenzano produttività Numero di istruzioni da codificare Capacità, motivazioni, coordinamento del personale Complessità dell applicazione Stabilità dei requisiti Prestazioni o qualità richieste Strumenti di sviluppo usati Nelson-Jones Law (L32) A multitude of factor influence developer productivity

4 Tecniche disponibili Stime Umane Legge di Parkinson sul lavoro Price to win Esperti Per analogia Stime Automatizzate Machine Learning Algoritmiche

5 Legge di Parkinson Non è specifica del software Il costo dipende dalle risorse disponibili Work expands to fill the available volume Esempio di applicazione: This flight control software must fit on a 65,536 word machine; therefore its size will be roughly 65,000 words. It must be done in 18 months, and there are 10 people available to work on it, so the job will take roughly 180 man-months

6 Price to win Il costo e quanto il cliente e disposto a spendere (sia soldi che tempo) Molto usato VANTAGGIO: spesso si ottiene il lavoro SVANTAGGIO: nessuna garanzia sul lavoro NOT TOO BAD SE: Possibile ricontrattazione dei requisiti a posteriore Possibile sviluppo incrementale

7 Esperti esterni Non è una tecnica, ma una prassi comune Si delega la responsabilità ad altri perché sono più bravi perché hanno maggiore conoscenza del dominio perché così non si tolgono persone interne da attività più importanti perché si impegnano a darci un risultato entro una certa scadenza Come fanno gli esperti a fare le stime?

8 Stima dei costi Stima per analogia si cerca di confrontarlo con un progetto precedente di cui la quantità di lavoro necessaria (mesi-uomo) e i tempi di sviluppo (mesi) sono noti coefficienti per gli scostamenti più grande del maggiore esperienza riuso... è un metodo top-down si prende il progetto nel suo insieme e successivamente si suddivide la spesa grande soggettività del confronto

9 Le stime dei costi DeMarco-Glass Law (L34) Most cost estimates tend to be low

10 Stima dei costi Basata su dimensione codice Si scompone funzionalmente il progetto e si identificano i componenti da sviluppare di questi (meno complessi del problema originale) si effettua una stima della dimensione bottom-up si ricompone la spesa totale a partire dalla base maggiore è la scomposizione maggiore è il dettaglio in cui si scende minore è la difficoltà di stima dei singoli componenti

11 Stima dei costi Basata sulla quantità di lavoro si scompone il progetto secondo una logica operativa (per fasi) e funzionale (componenti) quindi si stima il tempo necessario per svolgere le singole fasi per il determinato componente ancora bottom-up

12 Alcuni dati storici da raccogliere Produttività LineeCodice / MeseUomo Qualità Errori / LineeCodice Costo Unitario CostoTotale / LineeCodice

13 Automatizzate Machine learning Neural Networks Fuzzy Logic Case-Based Reasoning Analogy Rule-Based Regression Trees Hybrid System

14 Stime Algoritmiche Boehm COCOMO (COnstructive COst MOdel) COCOMO 2 Putnam Software LIfe Cycle Management (SLIM)

15 Modello COCOMO è un modello algoritmico ( 80) L identificazione fattori costi presentata deriva da questo modello Assume un modello a cascata a 4 fasi Pianificazione e analisi requisiti Progetto Sviluppo Integrazione e testing Parte dalla misurazione di casi reali e estrazione di formule da essi

16 Tipo applicazione e Modelli Le formule presentano coefficienti dipendenti da tipo applicazione Semplici Intermedie (o Moderate) Complesse (Integrate) Esistono tre modelli di formule Base dipende solo dalla stima delle linee di codice Intermedio 15 fattori correttivi legati a caratteristiche del progetto Possibilità di effettuare stima singoli componenti Avanzato

17 COCOMO Modello Base Mesi-uomo = a LOC b Mesi-Sviluppo = c Mesi-uomo d Bohem s Third Law (L33) Development effort is a non linear function of product size 4 parametri nei diversi tipi di applicazioni a b c d

18 COCOMO Intermedio 15 Fattori correttivi (ci) Legati al prodotto Legati alle macchine affidabilità richiesta 0.65 efficienza richiesta 0.66 dimensione database 0.22 memoria richiesta 0.56 complessità 0.95 variabilità ambiente sviluppo 0.43 tempi di risposta 0.28

19 Fattori correttivi Legati al personale Legati al progetto esperienza analisi 0.69 tecniche di programmazione avanzate 0.42 esperienza di dominio 0.47 strumenti avanzati 0.41 esperienza sviluppo 0.72 tempi di sviluppo stretti 0.13 conoscenza ambiente 0.31 conoscenza linguaggio 0.19

20 Formule intermedie Mesi-uomo = a LOC b x Π c j Mesi-Sviluppo = c Mesi-uomo d a e b non sono più quelli di prima LOC dovrebbe essere calcolato a partire da componenti e non solo stima totale

21 COCOMO 2 Raffina COCOMO tenendo conto di nuovi modi di sviluppare il software Prototipizzazione Riuso COTS Ha diverse formule a seconda del momento della stima Prime fasi e prototipizzazione Fase di progettazione Fase successiva alla definizione della architettura

22 Dimensionamento Staff Attenzione all uso della metrica mesi-uomo se ho uno sforzo di 10 mesi uomo, mettendo 300 persone non finisco in un giorno!! Qual è allora il numero ottimale di persone da assegnare ad un lavoro? COCOMO dando M (mesi-uomo) e T (mesi sviluppo) N = M/T magari divisi per fase

23 The mythical man/month Fred Brooks

24 Pianificare: caso semplice?

25 Stime condivise Mike Cohn - Agile Estimating and Planning Nei metodi agili la responsabilità della stima passa dai manager (imposizione) a team sviluppatori (autodeterminazione) deve essere perciò stima collettiva Wideband Delphi ( Planning Poker ( Team Estimation Game ( #NoEstimate (

26 Problemi nelle stime condivise Perdita di tempo troppa comunicazione Anchoring effect ( ) dipendenza dai primi pezzi di informazione che si ottengono

27 Stime Agili I PLANNING POKER Vengono presentate brevemente le carte Il team può fare domande, richiedere chiarimenti e discutere per chiarire assunzioni e rischi Ogni componente sceglie una carta del poker rappresentante la propria stima unità di misura? Le carte vengono girate contemporaneamente Chi ha espresso le stime più basse e più alte ha un minuto per spiegare le sue motivazioni e cercare di convincere li altri. Si ripete la votazione

28 Stime Agili II PRIMA FASE: VALUTAZIONE COMPARATIVA Fate una pila con le user storie (beh non sono tante) e mettete la prima carta al centro del tavola Il primo developer prende carta dalla pila, la rilegge (ad alta voce) e la posiziona a sinistra (più semplice) a destra (più complicata) sotto (equivalente). Il prossimo developer può: * prendere una carta dalla pila e posizionarla O * spostare una carta precedentemente posizionata (commentando la motivazione della sua azione) O * se non ci sono carte nella pila e non vuole spostare esistenti, passare Si ripete il passo precedente fino a quando a) non ci sono più carte sulla pila E b) nessun developer vuole spostare una carta

29 Stime Agili II SECONDA FASE: QUANTIFICARE DISTANZE scegliete una scala di valori (Fibonacci, potenze di 2,...) Partite dal valore 2 (potrebbe esserci nella prossima iterazione qualcosa di ancora più semplice) e domandatevi se la colonna seguente è il doppio più complicata, meno del doppio, o alla fin fine assimilabile collocate le etichette numerate sulle colonne opportune

30 Stime Agili II TERZA FASE: SCALA ASSOLUTA Stimate il tempo in secondi di una della carte più semplice (valore 2) Calcolate con le proporzioni tutti gli altri Necessario?

31 Velocity capacità (osservata) di completare lavori da parte del team Sostituisce la necessità di rimappare unità ideali in tempi assoluti Permette di compensare tendenze sbagliate di stime all interno del team NON deve essere usato come metro di valutazione tra team, o nel tempo

32 #NoEstimate Perché? Funziona?