1 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 Software Projects Chapter 26 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.

Software Project Management 2 Software project management is the organization and management of project resources to create or evolve software within specified, budgetary, time and scoping constraints. So estimates of time, money and scope are required!!

3 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

4 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. Estimation happens in 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 project is completed on time, with required quality!

5 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 is considered in detail in Chapter 25. Define required resources Determine require human resources Define reusable software resources Identify environmental resources

6 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

7 Five Phases of Project Management Scoping the Project Adapted from Weiss, J.W., and Wysocki, R.K Phase Project Management: A Practical Planning and Implementation Guide. Reading, MA: Addison Wesley. Scoping the Project Launching the Plan Monitoring & Controlling Closing Out the Project Developing the Project Plan

8 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!

9 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.

10 Five Phases of Project Management Scoping the Project Adapted from Weiss, J.W., and Wysocki, R.K Phase Project Management: A Practical Planning and Implementation Guide. Reading, MA: Addison Wesley. Developing the Project Plan Scoping the Project Launching the Plan Monitoring & Controlling Closing Out the Project

11 Developing The Plan Construct/Analyze Project Schedule Prepare the Project Proposal Identify Project Tasks (WBS) Estimate Task Duration Estimate Resource Requirements

12 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” Functional Decomposition produces a WBS which is refined into to required granularity. Estimates for separate modules are computed and aggregated. Identify Project Tasks

Estimate task duration & resource requirements for each item in the WBS 13 Software Project System Engineering Analysis Design Testing Architectural Design Detailed Design Procedural Design Database Design User Interface Design … Algorithm Design Test Case Design Determine Work Patterns Design Interface Design Review … … Define Operational Signatures Define Pre/post Conditions

14 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

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

16 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

17 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 estimation techniques task breakdown and effort estimates size (e.g., FP) estimates Empirical models Automated tools

18 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.

19 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

20 Function-Based Metrics The function point metric (FP), first proposed by Albrecht [ALB79], can be used effectively as a means for measuring the functionality delivered by a system. Function points are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity Information domain values are defined in the following manner: number of external inputs (EIs) number of external outputs (EOs) number of external inquiries (EQs) number of internal logical files (ILFs) Number of external interface files (EIFs) FP = count-total * ( * ∑ (F i ) ) Sum of information domain values Value Adjustment Factor

21 Function Points: Information domain values

22 Function Points: Information domain values EV = (opt + 4*likely + pess)/

23 Example: Computing FP The estimated number of FP is derived: FP estimated = count-total * [ * ∑ (F i )] i.e FP estimated = 320 * [ * ∑ (F i )] i.e FP estimated = 320 * [ * ∑ (F i )] Need to compute Value Adjustment Factor 320

Computing the Value Adjustment Factor Each factor is assessed on a scale from: 0  not important to 5  absolutely essential 24 52

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, Example: Computing FP The estimated number of FP is derived: FP estimated = count-total [ S (F i )] FP estimated = 320 * [ (0.01 * 52)] = 320 * ( ) = 320 * 1.17 = 375 so FP estimated = 375 Now that we have computed the number of function points, how do we estimate the cost of developing the software?Now that we have computed the number of function points, how do we estimate the cost of developing the software? organizational average productivity = 6.5 FP/pm  duration = 375/6.5 = 58 person- months.organizational average productivity = 6.5 FP/pm  duration = 375/6.5 = 58 person- months. the cost per FP is approximately $1230 (based on burdened labor rate = $8000 per month,)  total project cost = 1230 * 375 = $461,250.the cost per FP is approximately $1230 (based on burdened labor rate = $8000 per month,)  total project cost = 1230 * 375 = $461,

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 $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.

27 Example: LOC Approach Average productivity for systems of this type = 620 LOC/pm. The cost per line of code is = 8000/620 = $13 (Based on burdened labor rate of $8000 per month). Estimated effort = 33,200 / 620 = 54 person-months. Project Cost = (13 * 33,200) OR (54 * 8000) = $431,000. Estimated LOC = (opt + 4*likely + pess)/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, Comparing LOC and FP Representative values developed by QSM See See

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, Why Opt for FP? Programming language independent Used readily countable characteristics that are determined early in the software process Does not “penalize” inventive (short) implementations that use fewer LOC that other more clumsy versions Makes it easier to measure the impact of reusable components

30 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

31 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.

32 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

33 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.

34 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

35 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 effort = tuning coefficient * size exponent LOC estimation models E = 5.2 * (KLOC) 0.91 – Watson-Felix Model E = * (KLOC) 1.16 – Bailey-basili Model FP estimation models E = FP – Albrecht and Gaffney Model E = FP – Kemerer Model E = 5.2 * (KLOC) 0.91 – Watson-Felix Model

36 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. Estimated Effort = NOP/PROD

37 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 Example Use the COCOMO II model to estimate the effort required to build software that produces 15 screens, 9 reports, and will require about 60 software components. Assume average complexity and average developer/environment maturity. Use the application composition model with object points. Assume 70% reuse. Using the weightings from Table 26.6 the unadjusted object points are object points = 15 * * * 10 = 675 If we assume 70% reuse NOP (i.e., new object points) = (object points) * [(100 - %reuse)/100] = (675) * [(100 – 70)/100] = 675 * 0.3 = Using the weightings from Table 26.7 for nominal developer experience PROD = 13 (i.e. productivity is 13) The estimated effort in person months is estimated effort = NOP/PROD = / 13 = pm

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 Software Equation A dynamic multivariable model E = [(LOC x B )/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”

39 The Software Equation Use the software equation to estimate the duration of a project where: P ( the productivity parameter ) = 3,000 B ( the special skills factor ) = 0.16 LOC = 6450 t.min = 8.14 * (LOC / P) 0.43 = = 8.14 * (6450/3000) 0.43 = 8.14 * 1.38 = months t = month / 12 months/year = 0.94 years E = 180 * B * t 3 = 180 * 0.16 * (0.94) 3 = 24 person months

40 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

41 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

42 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.

43 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

44 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) ($450K) similarly, expected cost = $382K expected cost = $267K expected cost = $410K build reuse buy contr expected cost = = $429 K

Summary 45 What’s coming next class? ______________________ Devon M. Simmonds Computer Science Department University of North Carolina Wilmington _____________________________________________________________ Qu es ti ons?