1. Software Engineering 2 Chapter 26: Estimate
Mehran Rezaei

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. Project Planning Task Set-I
Establish project scope
Determine feasibility
Analyze risks
Risk analysis is considered in detail in Chapter 28.
Define required resources

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

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

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

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

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

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

11. Resources

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

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

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

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

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

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

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

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

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

21. An Example of FP-Based Estimation (2)

22. An Example of FP-Based Estimation (3)
Value Adjustment Factors

23. An Example of FP-Based Estimation (4)
Now,
FPestimated = count-total  [   (Fi)]
Fi (i = 1 to 14 are value adjustment factors)
So,
FPestimated = W = 320  [  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)

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

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

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

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

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

29. The Structure of Estimation Models (2)
Example of a LOC-oriented estimation model (Bailey-Basili model)
E =  (KLOC)1.16
Example of a FP-oriented estimation model (Kemerer model)
E = FP
Estimation models must be calibrated for local needs.

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

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

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

33. The COCOMO II Model (3) Object type Complexity weight Simple Medium
Difficult
Screen 1 2 3
Report 5 8
3GL component 10

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

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

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

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

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

39. 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
Text-based user interface
GUI
Complex GUI

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

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

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

43. Creating a Decision Tree (1)

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

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

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