1. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 23 Estimation for Software Projects Software Engineering: A Practitioner’s Approach, 6/e Chapter 23 Estimation for Software Projects copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

2. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2 Software Project Planning The overall goal of project planning is to establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project. Why? So the end result gets done on time, with quality!

3. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3 Scope — understand the problem and the work that must be done Scope — understand the problem and the work that must be done Estimation — how much effort? how much time? Estimation — how much effort? how much time? Risk — what can go wrong? how can we avoid it? what can we do about it? Risk — what can go wrong? how can we avoid it? what can we do about it? Schedule — how do we allocate resources along the timeline? what are the milestones? Schedule — how do we allocate resources along the timeline? what are the milestones? Control strategy — how do we control quality? how do we control change? Control strategy — how do we control quality? how do we control change? The Steps

4. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4 Project Planning Task Set-I Establish project scope Establish project scope Determine feasibility Determine feasibility Analyze risks: considered in detail in Chapter 25 Analyze risks: considered in detail in Chapter 25 Define required resources Define required resources Determine require human resources Determine require human resources Define reusable software resources Define reusable software resources Identify environmental resources Identify environmental resources

5. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5 Project Planning Task Set-II Estimate cost and effort Estimate cost and effort Decompose the problem Decompose the problem Develop two or more estimates using size, function points, process tasks or use-cases Develop two or more estimates using size, function points, process tasks or use-cases Reconcile the estimates Reconcile the estimates Develop a project schedule: considered in detail in Chapter 24. Develop a project schedule: considered in detail in Chapter 24. Establish a meaningful task set Establish a meaningful task set Define a task network Define a task network Use scheduling tools to develop a timeline chart Use scheduling tools to develop a timeline chart Define schedule tracking mechanisms Define schedule tracking mechanisms

6. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6 Write it Down! SoftwareProjectPlan Project Scope EstimatesRisksSchedule Control strategy

7. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7 To Understand Scope... Understand the customers needs Understand the customers needs understand the business context understand the business context understand the project boundaries understand the project boundaries understand the customer’s motivation understand the customer’s motivation understand the likely paths for change understand the likely paths for change understand that... understand that... Even when you understand, nothing is guaranteed!

8. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8 What is Scope? Software scope describes Software scope describes the functions and features that are to be delivered to end-users the functions and features that are to be delivered to end-users the data that are input and output the data that are input and output the “content” that is presented to users as a consequence of using the software the “content” that is presented to users as a consequence of using the software the performance, constraints, interfaces, and reliability that bound the system. the performance, constraints, interfaces, and reliability that bound the system. Scope is defined using one of two techniques: Scope is defined using one of two techniques: A narrative description of software scope is developed after communication with all stakeholders. A narrative description of software scope is developed after communication with all stakeholders. A set of use-cases is developed by end-users. A set of use-cases is developed by end-users.

9. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9 Obtaining Information for Scope Preliminary meeting or interview Preliminary meeting or interview First set of questions: Focus on customer, the overall goals and benefits First set of questions: Focus on customer, the overall goals and benefits Second set of questions: Gain a better understanding of the problem and customer perception about a solution Second set of questions: Gain a better understanding of the problem and customer perception about a solution Final set of questions: Focus on the effectiveness of the meeting Final set of questions: Focus on the effectiveness of the meeting

10. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10 Resources Resources: Resources: Hardware/software tools Hardware/software tools Reusable software components Reusable software components People People Characteristics: Characteristics: Description of the resources Description of the resources A statement of availability A statement of availability Chronological time that the resource will be required Chronological time that the resource will be required Duration of time that the resource will be applied Duration of time that the resource will be applied

11. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11 Resources project people number skills location environment software tools hardware network resources reusable software OTS components new components part-experience components full-experience components

12. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12 Project Estimation Project scope must be understood Project scope must be understood Elaboration (decomposition) is necessary Elaboration (decomposition) is necessary Historical metrics are very helpful Historical metrics are very helpful At least two different techniques should be used At least two different techniques should be used Uncertainty is inherent in the process Uncertainty is inherent in the process

13. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13 Achieve Reliable Estimation Delay estimation until late in project (but it is impossible) Delay estimation until late in project (but it is impossible) Base estimates on similar projects that have already been completed Base estimates on similar projects that have already been completed Use relatively simple decomposition techniques to generate project cost and effort estimates Use relatively simple decomposition techniques to generate project cost and effort estimates Use one or more empirical models for software cost and effort estimation Use one or more empirical models for software cost and effort estimation

14. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14 Estimation Techniques Past (similar) project experience Past (similar) project experience Conventional estimation techniques Conventional estimation techniques task breakdown and effort estimates task breakdown and effort estimates size (e.g., FP) estimates size (e.g., FP) estimates Empirical models Empirical models Automated tools Automated tools

15. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15 Estimation Accuracy Predicated on … Predicated on … 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 (a function of the availability of reliable software metrics from past projects) the degree to which the project plan reflects the abilities of the software team the stability of product requirements and the environment that supports the software engineering effort.

16. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16 Functional Decomposition functionaldecomposition StatementofScope Perform a Grammatical “parse”

17. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17 Conventional Methods: LOC/FP Approach compute LOC/FP using estimates of information domain values compute LOC/FP using estimates of information domain values use historical data to build estimates for the project use historical data to build estimates for the project

18. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 18 Example: LOC Approach Average productivity for systems of this type = 620 LOC/pm. Average productivity for systems of this type = 620 LOC/pm. Burdened labor rate =$8000 per month, the cost per line of code is approximately $13. Burdened labor rate =$8000 per month, the cost per line of code is approximately $13. Based on the LOC estimate and the historical productivity data, the total estimated project cost is $431,000 and the estimated effort is 54 person-months. Based on the LOC estimate and the historical productivity data, the total estimated project cost is $431,000 and the estimated effort is 54 person-months.Function Estimated LOC User interface and control facilities (UICF) 2,300 Two-dimensional geometric analysis (2DGA) 5,300 Three-dimensional geometric analysis (3DGA) 6,800 Database management (CBM) 3,350 Computer graphics display facilities (CGDF) 4,950 Peripheral control function (PCF) 2,100 Design analysis modules (DAM) 8,400 Estimated lines of code 33,200

19. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 19 Example: FP Value Adjustment Factors FactorValue Backup and recovery 4 Data communications 2 Distributed processing 0 Performance critical 4 Existing operating environment 3 On-line data entry 4 Input transaction over multiple screens 5 Internal logical files updates online 3 Information domain values complex 5 Internal processing complex 5 Code designed for reuse 4 Conversion/installation in design 3 Multiple installations 5 Application designed for change 5 Value adjustment factor  (F i ) 52

20. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20 Example: FP Approach The estimated number of FP is derived: The estimated number of FP is derived: FP estimated = count-total * [0.65 + 0.01 *  (F i )] = 375 Organizational average productivity = 6.5 FP/pm, burdened labor rate = $8000 per month, the cost per FP is approximately $1230. Organizational average productivity = 6.5 FP/pm, burdened labor rate = $8000 per month, the cost per FP is approximately $1230. Based on the FP estimate and the historical productivity data, the total estimated project cost is $461,000 and the estimated effort is 58 person-months. Based on the FP estimate and the historical productivity data, the total estimated project cost is $461,000 and the estimated effort is 58 person-months. Information domain value Opt.LikelyPess. Est. count Weight FP count Number of external inputs 20243024497 Number of external outputs 12152216578 Number of external inquires 16222822588 Number of internal logic files 44541042 Number of external interface files 2232715 Count total 320

21. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21 Process-Based Estimation Obtained from “process framework” applicationfunctions framework activities Effort required to accomplish each framework activity for each application function

22. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22 Process-Based Estimation Example Based on an average burdened labor rate of $8,000 per month, the total estimated project cost is $368,000 and the estimated effort is 46 person-months. Activity  CCPlanning Risk analysis EngineeringConstructionreleaseCETotals Task  AnalysisDesignCodeTest Function  UICF0.502.500.405.00n/a8.40 2DGA0.754.000.602.00n/a7.35 3DGA0.504.001.003.00n/a8.50 CGDF0.503.001.001.50n/a6.00 DBM0.503.000.751.50n/a5.75 PCF0.252.000.501.50n/a4.25 DAM0.502.000.502.00n/a5.00 Totals0.250.250.253.5020.504.5016.5046.00 % effort 1%1%1%8%45%10%36% CC = customer communication, CE = customer evaluation

23. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23 Tool-Based Estimation project characteristics calibration factors LOC/FP data

24. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24 Tool-Based Estimation Sizing of project deliverables Sizing of project deliverables Selecting project activities Selecting project activities Predicting staffing level Predicting staffing level Predicting software effort Predicting software effort Predicting software cost Predicting software cost Predicting software schedules Predicting software schedules

25. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25 Empirical Estimation Models General form: effort = tuning coefficient * size exponent usually derived as person-months of effort required either a constant or a number derived based on complexity of project usually LOC but may also be function point empirically derived

26. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 26 COCOMO-II COCOMO II is actually a hierarchy of estimation models that address the following areas: COCOMO II is actually a hierarchy of estimation models that address the following areas: Application composition model. Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance, and evaluation of technology maturity are paramount. Application composition model. Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance, and evaluation of technology maturity are paramount. Early design stage model. Used once requirements have been stabilized and basic software architecture has been established. Early design stage model. Used once requirements have been stabilized and basic software architecture has been established. Post-architecture-stage model. Used during the construction of the software. Post-architecture-stage model. Used during the construction of the software.

27. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 27 The Software Equation A dynamic multivariable model E = [LOC x B 0.333 /P] 3 x (1/t 4 ) where E = effort in person-months or person-years t = project duration in months or years B = “special skills factor” P = “productivity parameter”

28. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 28 Estimation for OO Projects-I Develop estimates using effort decomposition, FP analysis, and any other method that is applicable for conventional applications. Develop estimates using effort decomposition, FP analysis, and any other method that is applicable for conventional applications. Using object-oriented analysis modeling (Chapter 8), develop use-cases and determine a count. Using object-oriented analysis modeling (Chapter 8), develop use-cases and determine a count. From the analysis model, determine the number of key classes (called analysis classes in Chapter 8). From the analysis model, determine the number of key classes (called analysis classes in Chapter 8). Categorize the type of interface for the application and develop a multiplier for support classes: Categorize the type of interface for the application and develop a multiplier for support classes: Interface typeMultiplier No GUI 2.0 Text-based user interface 2.25 GUI 2.5 Complex GUI 3.0

29. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 29 Estimation for OO Projects-II Multiply the number of key classes (step 3) by the multiplier to obtain an estimate for the number of support classes. Multiply the number of key classes (step 3) by the multiplier to obtain an estimate for the number of support classes. Multiply the total number of classes (key + support) by the average number of work-units per class. Lorenz and Kidd suggest 15 to 20 person-days per class. Multiply the total number of classes (key + support) by the average number of work-units per class. Lorenz and Kidd suggest 15 to 20 person-days per class. Cross check the class-based estimate by multiplying the average number of work-units per use-case Cross check the class-based estimate by multiplying the average number of work-units per use-case

30. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 30 Estimation for Agile Projects Each user scenario (a mini-use-case) is considered separately for estimation purposes. Each user scenario (a mini-use-case) is considered separately for estimation purposes. The scenario is decomposed into the set of software engineering tasks that will be required to develop it. The scenario is decomposed into the set of software engineering tasks that will be required to develop it. Each task is estimated separately. Note: estimation can be based on historical data, an empirical model, or “experience.” Alternatively, the ‘volume’ of the scenario can be estimated in LOC, FP or some other volume-oriented measure (e.g., use-case count). Each task is estimated separately. Note: estimation can be based on historical data, an empirical model, or “experience.” Alternatively, the ‘volume’ of the scenario can be estimated in LOC, FP or some other volume-oriented measure (e.g., use-case count). Estimates for each task are summed to create an estimate for the scenario. Alternatively, the volume estimate for the scenario is translated into effort using historical data. Estimates for each task are summed to create an estimate for the scenario. Alternatively, the volume estimate for the scenario is translated into effort using historical data. The effort estimates for all scenarios that are to be implemented for a given software increment are summed to develop the effort estimate for the increment. The effort estimates for all scenarios that are to be implemented for a given software increment are summed to develop the effort estimate for the increment.

31. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 31 Estimation Guidelines estimate using at least two techniques estimate using at least two techniques get estimates from independent sources get estimates from independent sources avoid over-optimism, assume difficulties avoid over-optimism, assume difficulties you've arrived at an estimate, sleep on it you've arrived at an estimate, sleep on it adjust for the people who'll be doing the job — they have the highest impact adjust for the people who'll be doing the job — they have the highest impact

32. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 32 Disagreement between Estimates Require a re-evaluation of information used to make the estimates Require a re-evaluation of information used to make the estimates The scope of the project is not adequately understood or has been misinterpreted by the planner The scope of the project is not adequately understood or has been misinterpreted by the planner Productivity data used for problem-based estimation techniques is not appropriate for the application, obsolete, or has been misapplied Productivity data used for problem-based estimation techniques is not appropriate for the application, obsolete, or has been misapplied

33. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 33 The Make-Buy Decision Delivery date Delivery date Acquisition cost + customization cost Acquisition cost + customization cost Outside support cost (maintenance contract) Outside support cost (maintenance contract)

34. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 34 The Make-Buy Decision system X reuse simple (0.30) difficult (0.70) minor changes (0.40) major changes (0.60) simple (0.20) complex (0.80) major changes (0.30) minor changes (0.70) $ 380,000 $ 450,000 $ 275,000 $ 310,000 $ 490,000 $ 210,000 $ 400,000 buy contract without changes (0.60) with changes (0.40) $ 350,000 $ 500,000 build

35. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 35 Computing Expected Cost (path probability) x (estimated path cost) (path probability) x (estimated path cost) i i For example, the expected cost to build is: expected cost build = 0.30 ($380K) + 0.70 ($450K) = $429 K similarly, expected cost reuse = $382 K expected cost buy = $267 K expected cost contract = $410 K

36. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 36 Outsourcing Cost saving by reducing the number of software people and the facilities (e.g., computers, infrastructure) Cost saving by reducing the number of software people and the facilities (e.g., computers, infrastructure) Loss control over the software and put the fate of its competitiveness into the hands of a third party Loss control over the software and put the fate of its competitiveness into the hands of a third party