1. SOFTWARE COST ESTIMATION
SEMINAR FOR
COOP EDUCATION
ITSE 1380, ITNW 1380
FALL 2005

2. Objectives To introduce cost and schedule estimation
To discuss the problems of productivity estimation
To describe several cost estimation techniques
To discuss the utility of algorithmic cost modeling and its applicability in the software process

3. Cost estimation objectives
Budget
To know what you will spend
Controls
A lever to control the project
Differential analysis
Monitor progress by comparing planned with estimated costs
Cost database
Make future estimation better
Marry costing to management
Cost estimation and planning/scheduling are closely related activities

4. Software cost components
Hardware and software costs
Travel and training costs
Effort costs (the dominant factor in most projects)
salaries of engineers involved in the project
costs of building, heating, lighting
costs of networking and communications
costs of shared facilities (e.g library, staff restaurant, etc.)
costs of pensions, health insurance, etc.

5. Costing and pricing Estimating Cost Estimating Price
Costs for developer, not buyer
We need our costs to manage and assess
Estimating Price
There is not a simple relationship between the development cost and the price charged to the customer.
Broader organisational, economic, political and business considerations influence the price charged.

6. Productivity Measures
Size-related measures
Must be based on some output from the software process
Delivered source code
Object code instructions
Function-related measures
Based on an estimate of the functionality of the delivered software.
Function-points are the best known of this type of measure

7. Lines of Codes LOC = NCLOC + CLOC LOC: lines of code
NCLOC: non-commented line of code
CLOC: commented line of code
KLOC = one thousand of line of code

8. Function points Based on a combination of program characteristics
external inputs and outputs
user interactions
external interfaces
files used by the system
A weight is associated with each of these
The function point count is computed by multiplying each raw count by the weight and summing all values

9. Function points FPs are very subjective
Function point count modified by complexity of the project
FPs can be used to estimate LOC depending on the average number of LOC per FP for a given language
FPs are very subjective
Depend on the estimator
FP cannot generally be counted automatically

10. Factors affecting productivity
Description
Application domain experience
Knowledge of the application domain is essential for effective software development. Engineers who already understand a domain are likely to be the most productive.
Process quality
The development process used can have a significant effect on productivity. This is covered in Chapter 31.
Project size
The larger a project, the more time required for team communications. Less time is available for development so individual productivity is reduced.
Technology support
Good support technology such as CASE tools, supportive configuration management systems, etc. can improve productivity.
Working environment
A quiet working environment with private work areas contributes to improved productivity.

11. Estimation techniques
Expert judgement
Estimation by analogy
Parkinson’s Law
Pricing to win
Top-down estimation
Bottom-up estimation
Algorithmic cost modelling

12. Expert judgement
One or more experts in both software development and the application domain use their experience to predict software costs. Process iterates until some consensus is reached.
Advantages: Relatively cheap estimation method. Can be accurate if experts have direct experience of similar systems
Disadvantages: May be very costly

13. Estimation by analogy
The cost of a project is computed by comparing the project to a similar project inthe same application domain
Advantages: Accurate if project data available
Disadvantages: Impossible if no comparable project has been tackled. Needs systematically maintained cost database

14. Parkinson's Law The project costs whatever resources are available
Advantages: No overspending
Disadvantages: System is usually unfinished

15. Pricing to win
The project costs whatever the customer has to spend on it
Advantages: You get the contract
Disadvantages: The probability that the customer gets the system he or she wants is small. Costs do not accurately reflect the work required

16. Top-down estimation
Approaches may be applied using a top-down approach. Start at system level andwork out how the system functionality is provided
Takes into account costs such as integration, configuration management and documentation
Can underestimate the cost of solving difficult low-level technical problems

17. Bottom-up estimation
Start at the lowest system level. The cost of each component is estimated individually.These costs are summed to give final cost estimate
Accurate method if the system has been designed in detail
May underestimate costs of system level activities such as integration and documentation

18. Estimation methods Each method has strengths and weaknesses
Estimation should be based on several methods
If these do not return approximately the same result, there is insufficient information available
Some action should be taken to find out more in order to make more accurate estimates
Pricing to win is sometimes the only applicable method

19. Algorithmic cost modelling
Cost is estimated as a mathematical function of product, project and processattributes whose values are estimated by project managers
The function is derived from a study of historical costing data
Most commonly used product attribute for cost estimation is LOC (code size)
Most models are basically similar but withdifferent attribute values

20. Examples of cost models
General form: E = A + B  SC
E: Effort cost; S: Size; A, B, C: constants
Examples:
E = 5.2 x (KLOC)0.91 Walston-Felix Model
E = x (KLOC)1.16 Bailey-Basili Model
E = 3.2 x (KLOC)1.05 COCOMO Basic Model
E = x (KLOC) Doty Model for KLOC > 9

21. Examples of cost models
Cost models using FP as a primary input include (Pressman, 1997):
E = FP
Albrecht and Gaffney Model
E = x x 10-8 FP3
Kemerer Model
E = FP
Matson, Barnett, and Mellichamp Model

22. The COCOMO model Developed at TRW, a US defense contractor
Based on a cost database of more than 60 different projects
Exists in three stages
Basic -Gives a 'ball-park' estimate based on product attributes
Intermediate -modifies basic estimate using project and process attributes
Advanced -Estimates project phases and parts separately

23. The COCOMO model Three modes:
Organic mode: relatively simple projects in which small teams work to a set of informal requirements
Semidetached mode: an intermediate project in which mixed teams must work to a set of rigid and less than rigid requirements
Embedded mode:a project that must operate within a tight set of constraints (ie. flight control software for aircraft).

24. BASIC COCOMO Formula E = a(KLOC)b TDEV = cEd Mode a b c d Organic mode
2.4
1.05
2.5
0.38
Semi-detached
3.0
1.12
0.35
Embedded
3.6
1.20
0.32

25. COCOMO examples Organic mode project, KLOC = 32
PM = 2.4 (32)1.05 = 91 person months
TDEV = 2.5 (91)0.38 = 14 months
N = 91/15 = 6.5 people

26. Intermediate COCOMO Takes basic COCOMO as starting point
Identifies personnel, product, computer and project attributes which affect cost
Multiplies basic cost by attribute multipliers which may increase or decrease costs

27. Effort Multipliers Cost Driver Description Rating Very Low Low Nominal
High
Very High
Extra High
Product
RELY
Required software reliability
0.75
0.88
1.00
1.15
1.40 -
DATA
Database size
0.94
1.08
1.16
CPLX
Product complexity
0.70
0.85
1.30
1.65
Computer
TIME
Execution time constraint
1.11
1.66
STOR
Main storage constraint
1.06
1.21
1.56
VIRT
Virtual machine volatility
0.87
TURN
Computer turnaround time
1.07
Personnel
ACAP
Analyst capability
1.46
1.19
0.86
0.71
AEXP
Applications experience
1.29
1.13
0.91
0.82
PCAP
Programmer capability
1.42
1.17
VEXP
Virtual machine experience
1.10
0.90
LEXP
Language experience
1.14
0.95
Project
MODP
Modern programming practices
1.24
TOOL
Software Tools
0.83
SCED
Development Schedule
1.23
1.04

28. Advanced COCOMO model
The Advanced COCOMO model computes effort as a function of program size and a set of cost drivers weighted according to each phase of the software lifecycle. The Advanced model applies the Intermediate model at the component level, and then a phase-based approach is used to consolidate the estimate (Fenton, 1997).
The 4 phases used in the detailed COCOMO model are: requirements planning and product design (RPD), detailed design (DD), code and unit test (CUT), and integration and test (IT). Each cost driver is broken down by phase as in the example shown in Table 6 (Boehm, 1981).

29. Analyst capability effort multiplier for Advanced COCOMO
Cost Driver
Rating
RPD DD
CUT IT
ACAP
Very Low
1.80
1.35
1.50
Low
0.85
1.20
Nominal
1.00
High
0.75
0.90
Very High
0.55
0.70

30. Model tuning
All numbers in cost model are organization specific. The parameters of the model must be modified to adapt it to local needs
A statistically significant database of detailed cost information is necessary

31. Staffing requirements
Staff required can’t be computed by dividing the development time by the requiredschedule
The number of people working on a project varies depending on the phase of the project
The more people who work on the project, the more total effort is usually required
Very rapid build-up of people often correlates with schedule slippage

32. Rayleigh curve

33. Software Equation
Putnam used some empirical observations about productivity levels to derive the software equation from the basic Rayleigh curve formula (Fenton, 1997). The software equation is expressed as:
Size =
where C is a technology factor, E is the total project effort in person years, and t is the elapsed time to delivery in years.

34. Technology Factor
The technology factor is a composite cost driver involving 14 components. It primarily reflects:
Overall process maturity and management practices
The extent to which good software engineering practices are used
The level of programming languages used
The state of the software environment
The skills and experience of the software team
The complexity of the application
The software equation includes a fourth power and therefore has strong implications for resource allocation on large projects. Relatively small extensions in delivery date can result in substantial reductions in effort (Pressman, 1997).

35. Key points
There is not a simple relationship between the price charged for a system and its development costs.
Factors affecting productivity include individual aptitude, domain experience, the development project, the project size, tool support and the working environment.
Software may be priced to gain a contract and the functionality adjusted to the price.

36. Key points
Different techniques of cost estimation should be used when estimating costs.
The COCOMO model takes project, product, personnel and hardware attributes into account when predicting effort required.
Algorithmic cost models support quantitative option analysis as they allow the costs of different options to be compared.
The time to complete a project is not proportional to the number of people working on the project.

37. Seminar Report
Select any Software Cost Estimation relating topic of your interest (may or may not presented in the seminar)
Write report having at least 2 pages
Use the form from Saigontech website
Each report must have a title
Indicate the Week # in each report
Indicate reference materials

38. Reference Software Engineering, A Practitioner’s Approach, 4nd Edition
Roger S. Pressman, PhD.
McGraw-Hill, 2002.
Software Engineering
Jan Sommerville