340 likes | 698 Views
Chapter 23. Estimation. Software Engineering: A Practitioner’s Approach 6 th Edition Roger S. Pressman. Software Project Estimation (1). S/W is the most expensive element of virtually all computer based systems S/W cost and effort estimation will never be an exact science
E N D
Chapter 23 Estimation Software Engineering: A Practitioner’s Approach 6th Edition Roger S. Pressman
Software Project Estimation (1) • S/W is the most expensive element of virtually all computer based systems • S/W cost and effort estimation will never be an exact science • Too many variables • Human • Technical • Environmental • Political
Software Project Estimation (2) • Options for estimation • Delay estimation until late in the project • Attractive, but not practical • Base estimates on similar projects that have already been completed • Unfortunately, past experience has not always been a good indicator of future results • Use relatively simple decomposition techniques to generate project cost and effort estimates • “Divide and conquer” approach • Use one or more empirical models for software cost and effort estimation • Can be used as a cross-check for the previous option and vice versa
Decomposition Techniques • Two different points of view for the decomposition approach • Decomposition of the problem • Decomposition of the process • But first, the project planner must • Understand the scope of the s/w to be built • Generate an estimate of its “size”
Software Sizing (1) • The accuracy of a s/w project estimate is predicated on a number of things: • The degree to which the planner has properly estimated the size of the product to be built • The ability to translate the size estimate into human effort, calendar time, and dollars (required availability of past records) • The degree to which the project plan reflects the abilities of the s/w team • The stability of product requirements and the environment that supports the s/w engineering effort
Software Sizing (2) • Sizing represents the project planner’s first major challenge • Size refers to a quantifiable outcome of the s/w project (e.g. LOC and/or FP) • Four different approaches to the sizing problem [PUT92] • “Fuzzy Logic” sizing • Function point sizing • Standard component sizing • Change sizing
Problem-Based Estimation (1) • Example of baseline productivity metrics are LOC/pm or FP/pm • Making the use of single baseline productivity metric is discouraged • In general, LOC/pm or FP/pm averages should be computed by project domain • Local domain averages should be used
Problem-Based Estimation (2) • Statistical approach – three-point or expected-value estimate • S = (sopt + 4sm + spess)/6 • S = expected-value for the estimation variable (size) • sopt = optimistic value • sm = most likely value • spess = pessimistic value
An Example of LOC-Based Estimation (2) • Estimated lines of code = W = 33,200 • Let, • Average productivity = 620 LOC/pm = X • Labor rate = $8,000 per month = Y • So, • Cost per line of code = Z = Y/X = $13 (approx.) • Total estimated project cost = W*Z = $431,000 (approx.) • Estimated effort = W/X = 54 person-months (approx)
An Example of FP-Based Estimation (1) Figure 15.4: Computing function points
An Example of FP-Based Estimation (3) Value Adjustment Factors
An Example of FP-Based Estimation (4) • Now, • FPestimated = count-total [0.65 + 0.01 (Fi)] • Fi (i = 1 to 14 are value adjustment factors) • So, • FPestimated = W = 320 [0.65 + 0.01 52] = 375 (approx.) • Let, • Average Productivity = X = 6.5 FP/pm • Labor rate = Y = $8,000 per month • So, • Cost per FP = Z = Y/X = $1,230 (approx.) • Total estimated project cost = W*Z = $461,000 (approx.) • Estimated effort = W/X = 58 person-months (approx)
Empirical Estimation Models • Uses empirically derived formulas to predict effort as a function of LOC or FP • The empirical data are derived from a limited sample of projects • So, no estimation model is appropriate for all classes of s/w and in all development environments • The results obtained from such models must be used judiciously • An estimation model should be calibrated to reflect local conditions
The Structure of Estimation Models (1) • Derived using regression analysis on data collected from past s/w projects • Overall structure, E = A + B (ev)c • Here, • A, B, and C are empirically derived constants • E is effort in person-months • ev is the estimation variable (either LOC or FP) • Some form of project adjustment component is also used
The Structure of Estimation Models (2) • Example of a LOC-oriented estimation model (Bailey-Basili model) • E = 5.5 + 0.73 (KLOC)1.16 • Example of a FP-oriented estimation model (Kemerer model) • E = -37 + 0.96 FP • Estimation models must be calibrated for local needs.
Summary of S/W estimation methods S/W equation TIME LOC/usecase Usecase based LOC $/LOC E(LOC) Problem based $/FP COST FP E(FP) Process based E(Effort) Man-month $/Man-month
The COCOMO II Model (1) • COnstructive COst Model • A hierarchy of estimation models • Addresses the following areas • Application composition model • Early design stage model • Post-architecture stage model • Three different sizing options are available • Object points • Function points • Lines of source code
The COCOMO II Model (2) • The COCOMO II application composition model uses object points • Object point is computed using counts of the number of • Screens (at the user interface) • Reports • Components likely to be required to build the application
The COCOMO II Model (3) Figure 23.6: Complexity weighting for object types
The COCOMO II Model (4) Figure 23.7: Productivity rate for object points
The COCOMO II Model (5) • NOP = (object points) [(100-%reuse)/100] • NOP = New Object Points • Object Points = Weighted Total • %reuse = Percent of reuse • Estimated effort = NOP/PROD • PROD = Productivity Rate • PROD = NOP/person-month
The Software Equation [PUT92] (1) • It is a multivariate model • Has been derived from productivity data collected for over 4000 contemporary s/w projects • E = [LOC B0.333/P]3 (1/t4) • Here, • E = effort in person-months or person-years • t = project duration in months or years • B = “special skills factor” • P = “productivity parameter”
The Software Equation [PUT92] (2) • For small programs (KLOC = 5 to 15) • B = 0.16 • For programs greater than 70 KLOC • B = 0.39 • P = 2000 for development of real-time embedded s/w • P = 10,000 for telecommunication and systems s/w • P = 28,000 for business systems applications
The Software Equation [PUT92] (3) • Simplified formulas • tmin = 8.14 (LOC/P)0.43 in months for tmin > 6 months • tmin = minimum development time • E = 180 Bt3 in person-months for E 20 person-months • Here t is represented in years
The Make/Buy Decision • S/W acquisition options • s/w may be purchased (or licensed) off the shelf • “full-experience” or “partial-experience” s/w components may be acquired and then modified and integrated to meet specific needs • s/w may be custom built by an outside contractor to meet the purchaser’s specifications
Creating a Decision Tree (2) • The expected value for cost, computed along any branch of the decision tree, is • Expected cost = (path probability)i (estimated path cost)i • Where, i is the decision tree path
Outsourcing • S/W engineering activities are contracted to a third party who does the work at lower cost and, hopefully, higher quality • S/W work conducted within a company is reduced to a contract management activity • The decision to outsource can be either strategic or tactical • Has both merits and demerits
Chapter 23 • Introduction • 23.5 to 23.6.8 • 23.7 • 23.10 • Exercises • 23.1, 23.4—23.8, 23.12