1 / 35

Lezione 17. Pianificazione e stima dei costi

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

salma
Download Presentation

Lezione 17. Pianificazione e stima dei costi

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Pianificazione di progetto e stime di costi • 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) • l’individuazione e allocazione di man-power alle singole attività (staffing) • 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) • La stima del costo è essenziale • per allocare un budget di progetto • per definire il prezzo da proporre al Cliente nel contratto

  3. 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... • 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. Fattori nel calcolo dei prezzi del software

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

  6. Linee di codice (LOC) • 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? • Un programmatore ‘meno produttivo’ puo’ produrre codice • piu’ affidabile, • piu’ facile da capire • piu’ facile da mantenere e modificare

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

  8. Esempio 4

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

  10. Function points (Albrecht ‘79) • 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 l’esterno, prima del progetto dettagliato • Si basa sul conteggio di alcuni elementi del programma • external inputs and outputs • userinteractions • external interfaces • files used by the system • E’ definita come somma pesata del numero di occorrenze degli elementi • i pesi proposti da Albrecht vanno da un valore 3 (per input dall’esterno) a un valore 15 (per file interni gestiti dal programma) • UFC (Unadjusted Function Count) =  i (# elem. tipo i) * peso i • Per ottenere il valore FC finale, UFCviene poi modificato in base a parametri di complessità del progetto, quali: • ilgrado di distributività, di riuso, di performance, ...

  11. Produttività: function points / P-month • Per un dato linguaggio si può definire, basandosi su dati storici, il numero medio di LOC per Function Point (AVC). • 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 • Valoritipici di AVC: • Linguaggio assembler: 200-300 LOC/FP • Linguaggio di 4a generazione 20-40 LOC/FP

  12. Object points • Object points are an alternative function-related measure to function points, when 4GLs (->) are used • 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) • Easily estimated from system specification (i.e. early) • Used in COCOMO-2 estimation model (--->)

  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 generations • 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 which • 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. • SQL; Focus, Metafont, PostScript, RPG-II, S, IDL-PV/WAVE, Gauss, Mathematica and • data-stream languages such as AVS, APE, Iris Explorer.

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

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

  16. Tecniche di stima di costi • 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, … • La scarsa affidabilità delle tecniche di stima dei costi ‘scientifiche’ puo’ indurre a stime più ‘politiche’ • con la legge di Parkinson: L’impegno (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 ridimensionanogli obiettivi (dinamicamente)

  17. 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. • Per progetti complessi, Boehm suggerisce di applicare piu’ tecniche di predizione dei costi, fino a quando i risultati convergono.

  18. Algorithmic cost modelling • Empirical method, based on the analysis of historical data (completed projects) and identification of best fitformula • Effort is estimated as a function of product, project and process attributes whose values are estimated by project managers • Effort = A ´SizeB´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. • Most models are similar but with different values for A, B and M

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

  20. 1. Basic COCOMO formula for project classes • 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 • 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 • 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 • KDSI = thousands of Delivered Source Instructions (= source lines, excl. comments) • PM = Programmer Months (‘Effort’) • TDEV = Expected duration of project (Time) )

  21. Effort estimates

  22. Esempi di stime in basic COCOMO • 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 • 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 Effort (PM) Durata (TDEV) Numero persone necessarie (N) Effort (PM) Durata (TDEV) Numero persone disponibili

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

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

  25. Intermediate COCOMO attributes (--> multipliers) • Personnel attributes • Analyst capability • Programmer capability • Programming language experience • Application experience • Product attributes • Reliability requirement • Database size • Product complexity • Computer attributes • (i.e. constraints imposed on SW by the adopted HW) • Execution time constraints • Memory space constraints • 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 • Model tuning - Each organization must identify its own attributes and associated multiplier values • A statistically significant database of detailed cost information is necessary

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

  27. Management options for previous example

  28. Costs of alternatives based on varying COCOMO params.

  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. Staffing requirements • Staff required can’t be computed by diving the effort (man months) by the required schedule • The number of people working on a project varies depending on the phase of the project • The more people work on the project, the more total effort is usually required • Very rapid build-up of people often correlates with schedule slippage

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

  32. L1. Early prototyping level • Supports prototyping projects and projects where there is extensive reuse • Based on standard estimates of developer productivity in object points/month • Takes CASE tool use into account • 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. L2. Early design level • Estimates can be made after the requirements have been agreed • Based on standard formula for algorithmic models • PM = A´SizeB´M + PMm • where: • M = PERS ´ RCPX ´ RUSE ´ PDIF ´ PREX ´ FCIL ´ SCED • PMm = (ASLOC´(AT/100)) / ATPROD reflects the amount of automaticallygenerated 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) • Bvaries 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. Multipliers • 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. The exponent term B • This depends on five scale factors (5 = low, 0 = high) • Their sum/100 is added to 1.01 • 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 • 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

More Related