Slide 1 Lezione 17. Pianificazione e stima dei costi [S2001, Cap. 23] [GJM91, Sez. 8.2] u Composizione dei costi u Misure di produttività (LOC, FP, OP)

Presentazione sul tema: "Slide 1 Lezione 17. Pianificazione e stima dei costi [S2001, Cap. 23] [GJM91, Sez. 8.2] u Composizione dei costi u Misure di produttività (LOC, FP, OP)"— Transcript della presentazione:

1 Slide 1 Lezione 17. Pianificazione e stima dei costi [S2001, Cap. 23] [GJM91, Sez. 8.2] u Composizione dei costi u Misure di produttività (LOC, FP, OP) u Tecniche di stima dei costi di sviluppo software u Stima algoritmica dei costi il modello COCOMO81 il modello COCOMO 2

2 Slide 2 Pianificazione di progetto e stime di costi u Nella fase di planning di un progetto vengono descritte: le attività in cui il progetto si articola le loro interdipendenze logiche e temporali (sequenziali / parallele) lindividuazione e allocazione di man-power alle singole attività (staffing) u Ma un planning dettagliato deve anche quantificare, per ogni attività, il costo, suddiviso in costi di acquisizione/manutenzione di hardware/software costi di viaggio e training costi del personale coinvolto nel lavoro (dominante) u La stima del costo è essenziale per allocare un budget di progetto per definire il prezzo da proporre al Cliente nel contratto

3 Slide 3 u I costi del personale che sviluppa il sistema comprendono: salari di ingegneri del software e programmatori overheads (per una quota relativa allo staff coinvolto): »riscaldamento, illuminazione, affitto spazi ufficio... »servizi di segreteria, ufficio personale, assicurazioni, servizi legali, biblioteca, mensa, pulizie... »collegamenti rete e telefonici… »contributi casse pensioni... u Normalmente gli overheads sono una o due volte i salari un ing. che guadagna 100 ML./anno costa 200-300 ML./anno alla sua organizzazione

4 Slide 4 Fattori nel calcolo dei prezzi del software

5 Slide 5 / u Si misura il software secondo qualche parametro, e u si divide per il tempo-programmatore consumato u (-) Le metriche basate su quantità/tempo non tengono conto del fattore qualità u Parametri considerati: misure di dimensione »linee di codice sorgente »linee di codice oggetto misure di funzionalità »function points Produttività del programmatore e impatto sui costi di progetto Stima delle linee di codice del sistema (LOC) Produttività (LOC/mese-uomo) Man-power necessario (mesi-uomo) * Costo unitario (salari+overheads) (M.lire/mese-uomo) Costo progetto (M.lire) +% Prezzo al Cliente (M.lire) Un modello altamente grossolano: / Dimensione team programmazione (# persone) Durata progetto (mesi)

6 Slide 6 Linee di codice (LOC) u Misura classica: linee di codice sorgente per mese-uomo, includendo analisi, progetto, validazione, documentazione. Ma…: Da FORTRAN a C++ il concetto di linea di codice si complica Diversi criteri di conteggio (commenti?, dichiarazioni di dati?, comandi su piu linee? macro-expansion?) I programmatori verbosi sono più produttivi? I programmatori in linguaggi a più basso livello sono più produttivi? Il programmatore che riusa software già disponibile è meno produttivo? u Un programmatore meno produttivo puo produrre codice piu affidabile, piu facile da capire piu facile da mantenere e modificare

7 Slide 7 Tempi di sviluppo con linguaggi ad alto / basso livello

8 Slide 8 Esempio 4

9 Slide 9 Valori tipici di produttività in LOC u Real-time embedded systems: 40-160 LOC/P-month (mese-programmatore) u Systems programs: 150-400 LOC/P-month u Commercial applications: 200-800 LOC/P-month u In Extreme Programming (continua evoluzione del codice) LOC è poco significativa [Beck2000]

10 Slide 10 Function points (Albrecht 79) u Metrica indipendente dal linguaggio (ma molto soggettiva…) e orientata a sistemi di data-processing. + Una prima stima è possibile appena definite le interazioni del sistema con lesterno, prima del progetto dettagliato u Si basa sul conteggio di alcuni elementi del programma external inputs and outputs user interactions external interfaces files used by the system u E definita come somma pesata del numero di occorrenze degli elementi i pesi proposti da Albrecht vanno da un valore 3 (per input dallesterno) a un valore 15 (per file interni gestiti dal programma) UFC (Unadjusted Function Count) = i (# elem. tipo i) * peso i u Per ottenere il valore FC finale, UFC viene poi modificato in base a parametri di complessità del progetto, quali: il grado di distributività, di riuso, di performance,...

11 Slide 11 u Produttività: function points / P-month u Per un dato linguaggio si può definire, basandosi su dati storici, il numero medio di LOC per Function Point (AVC). u Se si dispone di una stima dei Function Points di un nuovo sistema S, si puo stimare la dimensione del parametro LOC di S: LOC(S) = Function Points(S) * AVC u Valori tipici di AVC: Linguaggio assembler:200-300 LOC/FP Linguaggio di 4a generazione20-40 LOC/FP

12 Slide 12 Object points u Object points are an alternative function-related measure to function points, when 4GLs (->) are used u Object points do not count object classes, they are obtained by a weighted estimate of The number of separate screens displayed (weights 1, 2, 3) The number of reports produced by the system(weights 2, 5, 8) The number of 3GL modules (high level programming languages such as Java) needed to supplement the 4GL code (weight 10) u Easily estimated from system specification (i.e. early) u Used in COCOMO-2 estimation model (--->)

13 Slide 13 (4GL: fourth generation language) An "application specific" language. The term was invented by Jim Martin to refer to non-procedural high level languages built around database systems. The first three generationshigh level languagedatabase were developed fairly quickly, but it was still frustrating, slow, and error prone to program computers, leading to the first "programming crisis", in which the amount of work that might be assigned to programmers greatly exceeded the amount of programmer time available to do it. Meanwhile, a lot of experience was gathered in certain areas, and it became clear that certain applications could be generalised by adding limited programming languages to them. Thus were born report-generator languages, which were fed a description of the data format and the report to generate and turned that into a COBOL (or other language) program whichCOBOL actually contained the commands to read and process the data and place the results on the page. Some other successful 4th-generation languages are: database query languages, e.g.database query language SQLSQL; Focus, Metafont, PostScript, RPG-II, S, IDL-PV/WAVE, Gauss, Mathematica andFocusMetafontPostScriptRPG-IISIDL-PV/WAVEGaussMathematica data-stream languagedata-stream languages such as AVS, APE, Iris Explorer.AVSAPEIris Explorer

14 Slide 14 Valori tipici di produttività in Object Points u In object points, productivity has been measured between 4 and 50 object points/month depending on tool support and developer capability (Boehm 95)

15 Slide 15 Fattori che influenzano la produttività Ma, a parità di qualità del codice, un programmatore puo essere fino a 10 volte piu produttivo di un altro (Sackman 68)

16 Slide 16 Tecniche di stima di costi u Minate da molti elementi di incertezza: Requirements (in evoluzione, anche in dipendenza dal processo di sviluppo scelto) Personale (variabilità della produttività individuale) Tecnologie in parte ancora da definire, … u La scarsa affidabilità delle tecniche di stima dei costi scientifiche puo indurre a stime più politiche con la legge di Parkinson: Limpegno (effort) necessario è … quello possibile: »il cliente vuole il risultato dopo 12 mesi, »(e lo sviluppatore ha 5 persone disponibili) ==> »lo sforzo stimato è … 60 mesi-uomo… con il criterio pricing to win: »il costo stimato è … uguale alla disponibilità del Cliente... con il criterio del costo fisso: »anziché stimare i costi per un obiettivo prefissato »si fissano i costi, e si ridimensionano gli obiettivi (dinamicamente)

17 Slide 17 u Criteri empirici più seri: Valutazione iterativa da parte di un insieme di esperti (di dominio e tecnologia), fino a convergenza sulla previsione Valutazione per analogia con progetti nello stesso settore Modellazione algoritmica dei costi: »previsione dei costi secondo una formula/algoritmo che fa dipendere i costi da attributi del prodotto (tipicamente LOC), del progetto, del processo »la formula è indotta dalla osservazione di dati storici sperimentali (valori degli attributi, costi) relativi a un corpus di progetti precedenti. u Per progetti complessi, Boehm suggerisce di applicare piu tecniche di predizione dei costi, fino a quando i risultati convergono.

18 Slide 18 u Empirical method, based on the analysis of historical data (completed projects) and identification of best fit formula u Effort is estimated as a function of product, project and process attributes whose values are estimated by project managers Effort = A Size B M A is an organisation-dependent constant (local practices, type of developed SW), B reflects the disproportionate effort for large projects (between 1 and 1.5) M is a multiplier reflecting product, process and people attributes Size estimated in LOC, FP, OP. u Most models are similar but with different values for A, B and M Algorithmic cost modelling

19 Slide 19 The COCOMO model [Boehm 81] u COnstructive COst MOdel; developed at TRW, a US defense contractor - Versions in 81, 89, 95. u Provided with support tools, but independent from software vendors... u Based on a cost database of more than 60 different projects u Exists in three stages 1. Basic - Gives an order of magnitude estimate based on product attributes 2. Intermediate - modifies basic estimate using project and process attributes 3. Advanced - Estimates project phases and parts (subsystems) separately. Not discussed here

20 Slide 20 1. Basic COCOMO formula for project classes u simple small teams, familiar environment, well-understood applications, simple non-functional requirements (EASY) PM = 2.4 (KDSI) 1.05 TDEV = 2.5 (PM) 0.38 u moderate Project team may have experience mixture, system may have more significant non-functional constraints, organization may have less familiarity with application (HARDER) PM = 3 (KDSI) 1.12 TDEV = 2.5 (PM) 0.35 u embedded Hardware/software systems tight constraints, including local regulations and operational procedures; unusual for team to have deep application experience (HARD) PM = 3.6 (KDSI) 1.2 TDEV = 2.5 (PM) 0.32 u KDSI = thousands of Delivered Source Instructions (= source lines, excl. comments) u PM = Programmer Months (Effort) u TDEV = Expected duration of project (Time) )

21 Slide 21 Effort estimates

22 Slide 22 u Simple project, 32 KDSI PM = 2.4 (32) 1.05 = 91 person*month TDEV = 2.5 (91) 0.38 = 14 month N = 91/14 = 6.5 person u Embedded project, 128 KDSI PM = 3.6 (128) 1.2 = 1216 person-months TDEV = 2.5 (1216) 0.32 = 24 months N = 1216/24 = 51 persons Esempi di stime in basic COCOMO Effort (PM)Durata (TDEV) Numero persone necessarie (N) Durata (TDEV) Effort (PM) Numero persone disponibili

23 Slide 23 u Implicit productivity estimate (but it still depends on size!) Simple mode = 16 LOC/day Embedded mode = 4 LOC/day u Time required is a function of total effort, NOT team size u Not clear how to adapt model to personnel availability COCOMO assumptions

24 Slide 24 u Takes basic COCOMO as starting point u Identifies personnel, product, computer and project attributes which affect cost u Multiplies basic COCOMO cost (required effort) by attribute multipliers which may increase or decrease costs u Multipliers are assigned values in the range [0.7, 1.66] multiplier < 1 implies reduced cost 2. Intermediate COCOMO

25 Slide 25 u Personnel attributes Analyst capability Programmer capability Programming language experience Application experience u Product attributes Reliability requirement Database size Product complexity Intermediate COCOMO attributes (--> multipliers) u Computer attributes (i.e. constraints imposed on SW by the adopted HW) Execution time constraints Memory space constraints u Project attributes Modern programming practices »structured programming, when COCOMO was defined; »O-O programming today Software tools Required development schedule »Mismatch between basic COCOMO and Client schedule gives attribute > 1 u Model tuning - Each organization must identify its own attributes and associated multiplier values u A statistically significant database of detailed cost information is necessary

26 Slide 26 u Embedded software system on microcomputer hardware. u Basic COCOMO predicts a 45 person-month effort requirement u Attributes: RELY = 1.15, STOR = 1.21, TIME = 1.10, TOOL = 1.10 u Intermediate COCOMO predicts 45 * 1.15*1.21.1.10*1.10 = 76 person-months. u Total cost = 76 * $7000 = $532, 000 Example

27 Slide 27 Management options for previous example

28 Slide 28 Costs of alternatives based on varying COCOMO params.

29 Slide 29 Calibrazione dei parametri delle formule COCOMO Se il Predicted effort secondo i parametri COCOMO standard si scosta dai valori sperimentali misurati (i punti sul diagramma), i parametri vengono modificati secondo il criterio dei minimi quadrati, portando a una nuova curva di previsione ottimale

30 Slide 30 Staffing requirements u Staff required cant be computed by diving the effort (man months) by the required schedule u The number of people working on a project varies depending on the phase of the project u The more people work on the project, the more total effort is usually required u Very rapid build-up of people often correlates with schedule slippage

31 Slide 31 COCOMO 2 levels u COCOMO 2 is a 3 level model that allows increasingly detailed estimates to be prepared as development progresses u L1. Early prototyping level Estimates based on object points and a simple formula is used for effort estimation u L2. Early design level Estimates based on function points that are then translated to LOC u (L3. Post-architecture level Estimates based on lines of source code )

32 Slide 32 L1. Early prototyping level u Supports prototyping projects and projects where there is extensive reuse u Based on standard estimates of developer productivity in object points/month u Takes CASE tool use into account u Formula is simplified: PM = ( NOP (1 - %reuse/100 ) ) / PROD PM is the effort in person-months, NOP is the number of object points and PROD is the productivity (Ops/month)

33 Slide 33 L2. Early design level u Estimates can be made after the requirements have been agreed u Based on standard formula for algorithmic models PM = A Size B M + PM m where: M = PERS RCPX RUSE PDIF PREX FCIL SCED PM m = ( ASLOC (AT/100)) / ATPROD reflects the amount of automatically generated code A = 2.5 in initial calibration, Size in KSLOC, but derived from estimated Function Points, and FP to KSLOC conversion table (progr. language-dependent) B varies from 1.1 to 1.24 depending on novelty of the project, development flexibility, risk management approaches and the process maturity (overlap with M…)

34 Slide 34 Multipliers u Multipliers (values 1 to 6) reflect the capability of the developers, the non-functional requirements, the familiarity with the development platform, etc. PERS - personnel capability RCPX - product reliability and complexity RUSE - the reuse required PDIF - platform difficulty PREX - personnel experience FCIL - the team support facilities SCED - required schedule

35 Slide 35 The exponent term B u This depends on five scale factors (5 = low, 0 = high) u Their sum/100 is added to 1.01 u Example Precedenteness - new project - 4 Development flexibility - no client involvement - Very high - 1 Architecture/risk resolution - No risk analysis - Very Low - 5 Team cohesion - new team - nominal - 3 Process maturity - some control - nominal - 3 u Scale factor is therefore 1.17 Project duration: TDEV = 3 (PM) (0.33+0.2*(B-1.01)) PM is the effort computation and B is the exponent computed as discussed above (B is 1 for the early prototyping model). This computation predicts the nominal schedule for the project