Software Engineering 2 Chapter 26: Estimate Mehran Rezaei

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!

Project Planning Task Set-I Establish project scope Determine feasibility Analyze risks Risk analysis is considered in detail in Chapter 28. Define required resources

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.

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

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

Write it Down! Project Scope Software Estimates Project Risks Plan Schedule Control strategy Software Project Plan

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!

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

Resources

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

Estimation Techniques Past (similar) project experience Conventional estimation techniques task breakdown and effort estimates size (e.g., FP) estimates Empirical models Automated tools

Decomposition Techniques Two different points of view for the decomposition approach Decomposition of the problem Decomposition of the process

Functional Decomposition Statement of Scope functional decomposition Perform a Grammatical “parse”

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 (1) Function Estimated LOC User interface and control facilities (UICF) Two-dimensional geometric analysis (2DGA) Three-dimensional geometric analysis (3DGA) Database management (DBM) Computer graphics display facilities (CGDF) Peripheral control function (PCF) Design analysis modules (DAM) 2,300 5,300 6,800 3,350 4,950 2,100 8,400 Estimated lines of code 33,200

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) Information Domain Value Count Weighting factor Simple Average Complex External Inputs (EIS) 3 X 4 6 = 9 External Outputs (EOs) 2 5 7 8 External Inquiries (EQs) Internal Logical Files (ILFs) 1 10 15 External Interface Files (EIFs) 20 Count Total 50

An Example of FP-Based Estimation (2)

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 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)

Process-Based Estimation Obtained from “process framework” framework activities application functions Effort required to accomplish each framework activity for each application function

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.

Tool-Based Estimation project characteristics calibration factors LOC/FP data

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, the total estimated project cost is $552,000 and the estimated effort is 68 person-months.

Empirical Models: 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)

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 LOC/usecase S/W equation TIME 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) Object type Complexity weight Simple Medium Difficult Screen 1 2 3 Report 5 8 3GL component 10

Productivity rate for object points The COCOMO II Model (4) Developer’s experience/capability Very low Low Nominal High Very High Environment maturity/capability PROD 4 7 13 25 50 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

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 type Multiplier No GUI 2.0 Text-based user interface 2.25 GUI 2.5 Complex GUI 3.0

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

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.

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 (1)

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

Assignment 4, 5 Homework Assignment 4 Homework Assignment 5 26.1, 4, 5, 9, 11 due next week, Tuesday, 1390/02/11 Homework Assignment 5 25.1, 5, 6, and 9 Due on Tuesday, 1390/02/18 Reading Assignment 26.8 till 26.11, pp. 712 – 718 due next week, Tuesday, 1390/02/06