1. 1 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Chapter 26 Estimation for Software Projects Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use.

2. 2 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 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. 3 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Project Planning Task Set-I Establish project scope Determine feasibility Analyze risks Risk analysis. Define required resources Determine require human resources Define reusable software resources Identify environmental resources

4. 4 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Project Planning Task Set-II Estimate cost and effort Decompose the problem Develop two or more estimates using size, function points, process tasks or use-cases Reconcile the estimates Develop a project schedule Scheduling is considered in detail in Chapter 27. Establish a meaningful task set Define a task network Use scheduling tools to develop a timeline chart Define schedule tracking mechanisms

5. 5 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Estimation Estimation of resources, cost, and schedule for a software engineering effort requires experience access to good historical information (metrics) the courage to commit to quantitative predictions when qualitative information is all that exists Estimation carries inherent risk and this risk leads to uncertainty

6. 6 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Write it Down! SoftwareProjectPlan Project Scope EstimatesRisksSchedule Control strategy

7. 7 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. To Understand Scope... Understand the customers needs understand the business context understand the project boundaries understand the customer’s motivation understand the likely paths for change understand that... Even when you understand, nothing is guaranteed!

8. 8 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. What is Scope? Software scope describes the functions and features that are to be delivered to end-users the data that are input and output the “content” that is presented to users as a consequence of using the software the performance, constraints, interfaces, and reliability that bound the system. Scope is defined using one of two techniques: A narrative description of software scope is developed after communication with all stakeholders. A set of use-cases is developed by end-users.

9. 9 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Resources

10. 10 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Categories of Resources People - Number required - Skills required - Geographical location Development Environment - Software tools - Computer hardware - Network resources Reusable Software Components - Off-the-shelf components - Full-experience components - Partial-experience components - New components The Project

11. 11 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Project Estimation Project scope must be understood Elaboration (decomposition) is necessary Historical metrics are very helpful At least two different techniques should be used Uncertainty is inherent in the process

12. 12 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Estimation Techniques Past (similar) project experience Conventional or Decomposition techniques These take a "divide and conquer" approach Cost and effort estimation are performed in a stepwise fashion by breaking down a project into major functions and related software engineering activities Empirical estimation models Offer a potentially valuable estimation approach if the historical data used to seed the estimate is good Automated tools

13. 13 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Functional Decomposition functionaldecomposition StatementofScope Perform a Grammatical “parse”

14. Decomposition Techniques Before an estimate can be made and decomposition techniques applied, the planner must Understand the scope of the software to be built Generate an estimate of the software’s size Then one of two approaches are used Problem-based estimation Based on either source lines of code or function point estimates Process-based estimation Based on the effort required to accomplish each task 14 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

15. Software Sizing 15 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

16. 16 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Estimation Accuracy 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.

17. 17 Approaches to Software Sizing Function point sizing Develop estimates of the information domain characteristics (Ch. 15 – Product Metrics for Software) Standard component sizing Estimate the number of occurrences of each standard component Use historical project data to determine the delivered LOC size per standard component Change sizing Used when changes are being made to existing software Estimate the number and type of modifications that must be accomplished Types of modifications include reuse, adding code, changing code, and deleting code An effort ratio is then used to estimate each type of change and the size of the change The results of these estimates are used to compute an optimistic (low), a most likely, and a pessimistic (high) value for software size

18. 18 Problem-Based Estimation 1) Start with a bounded statement of scope 2) Decompose the software into problem functions that can each be estimated individually 3) Compute an LOC or FP value for each function 4) Derive cost or effort estimates by applying the LOC or FP values to your baseline productivity metrics (e.g., LOC/person-month or FP/person-month) 5) Combine function estimates to produce an overall estimate for the entire project (More on next slide)

19. 19 Problem-Based Estimation In general, the LOC/pm and FP/pm metrics should be computed by project domain Important factors are team size, application area, and complexity LOC and FP estimation differ in the level of detail required for decomposition with each value For LOC, decomposition of functions is essential and should go into considerable detail (the more detail, the more accurate the estimate) For FP, decomposition occurs for the five information domain characteristics and the 14 adjustment factors External inputs, external outputs, external inquiries, internal logical files, external interface files pm = person month

20. 20 Problem-Based Estimation For both approaches, the planner uses lessons learned to estimate an optimistic, most likely, and pessimistic size value for each function or count (for each information domain value) Then the expected size value S is computed as follows: S = (S opt + 4S m + S pess )/6 Historical LOC or FP data is then compared to S in order to cross- check it

21. 21 Process-Based Estimation 1) Identify the set of functions that the software needs to perform as obtained from the project scope 2) Identify the series of framework activities that need to be performed for each function 3) Estimate the effort (in person months) that will be required to accomplish each software process activity for each function (More on next slide)

22. 22 Process-Based Estimation 4) Apply average labor rates (i.e., cost/unit effort) to the effort estimated for each process activity 5) Compute the total cost and effort for each function and each framework activity (See table in Pressman, p. 655) 6) Compare the resulting values to those obtained by way of the LOC and FP estimates If both sets of estimates agree, then your numbers are highly reliable Otherwise, conduct further investigation and analysis concerning the function and activity breakdown This is the most commonly used of the two estimation techniques (problem and process)

23. 23 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Conventional Methods: LOC/FP Approach compute LOC/FP using estimates of information domain values use historical data to build estimates for the project

24. 24 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Example: LOC Approach 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. Based on the LOC estimate and the historical productivity data, the total estimated project cost is 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.

25. 25 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Example: LOC Approach For example, the range of LOC estimates for the 3D geometric analysis function is optimistic, 4600 LOC; most likely, 6900 LOC; and pessimistic, 8600 LOC. the expected value for the 3D geometric analysis function is 6800 LOC by applying this S = (S opt + 4S m + S pess )/6 = (4600+4X6900+8600) = 40,800/6 = 6800 LOC Productivity = size/effort = KilosLOC/person month Quality = errors/size = errors/KLOC Cost = $/KLOC Documentation = pages/KLOC Effort will be given

26. 26 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Example: LOC Approach Average productivity for systems of this type = 620 LOC/pm. Burdened labor rate =$8000 per month, The cost per line of code is approximately = = $12.90 ≈ $13 Based on the LOC estimate and the historical productivity data, The total estimated project cost is = (33200 X 13) = $431,000 The estimated effort is = = 54 person-months.

27. 27 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Example: FP Approach The estimated number of FP is derived: FP estimated = count-total 3 [0.65 + 0.01 3 S (F i )] FP estimated = 375 organizational average productivity = 6.5 FP/pm. burdened labor rate = $8000 per month, approximately $1230/FP. Based on the FP estimate and the historical productivity data, Based on the FP estimate and the historical productivity data, total estimated project cost is $461,000 and estimated effort is 58 person-months.

28. 28 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Process-Based Estimation Obtained from “process framework” application functions framework activities Effort required to accomplish each framework activity for each application function

29. 29 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Process-Based Estimation Example Based on an average burdened labor rate of $8,000 per month, 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.

30. 30 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Tool-Based Estimation project characteristics calibration factors LOC/FP data

31. 31 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Estimation with Use-Cases Using 620 LOC/pm as the average productivity for systems of this type and a burdened labor rate of $8000 per month, the cost per line of code is approximately $13. Based on the use- case estimate and the historical productivity data, Using 620 LOC/pm as the average productivity for systems of this type and a burdened labor rate of $8000 per month, the cost per line of code is approximately $13. Based on the use- case estimate and the historical productivity data, the total estimated project cost is $552,000 and the estimated effort is 68 person-months.

32. 32 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 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

33. 33 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. COCOMO-II 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. 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.

34. 34 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 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”

35. 35 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Estimation for OO Projects-I Develop estimates using effort decomposition, FP analysis, and any other method that is applicable for conventional applications. Using object-oriented requirements modeling (Chapter 6), develop use-cases and determine a count. From the analysis model, determine the number of key classes (called analysis classes in Chapter 6). 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

36. 36 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 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 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

37. 37 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Estimation for Agile Projects 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. 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. 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.

38. 38 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. The Make-Buy Decision

39. 39 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Computing Expected Cost (path probability) (estimated path cost) (path probability) x (estimated path cost) ii For example, the expected cost to build is: expected cost = 0.30 ($380K) + 0.70 ($450K) similarly, expected cost = $382K expected cost = $267K expected cost = $410K build reuse buy contr expected cost = = $429 K