This document discusses project estimation and the Constructive Cost Model (COCOMO) for estimating software development costs and schedules. It explains that inaccurate estimates often lead to cost overruns and project failures. Several estimation methods are described like expert judgment, analogy models, and algorithmic models. The COCOMO model uses variables like project size, mode (organic, semidetached, embedded), and effort adjustment factors to estimate effort (in person-months), development time, and staffing needs. The basic, intermediate, and detailed COCOMO models are explained along with the equations used for effort and schedule estimates. Factors that impact productivity like application experience, process quality, and technology are also summarized.

1. 3. Project Estimation
Kasun Ranga Wijeweera
(krw19870829@gmail.com)

2. Why We Need Estimation?
• Large software systems usually take 200-
300% cost overruns and a 100% schedule slip
• 15% of large projects fail without delivering
anything
• Failures occur basically due to poor
management and inaccurate estimations of
development cost and development schedule
• Developers have to pay the price in schedule
slips

3. Estimation Problems
• Software cost prediction
• Software schedule prediction
• Software risk control
• Progress tracking
• Project management

4. Software Cost
• Hardware and software
• Travel and training
• Effort: (dominant factor)
– Salaries of engineers
– Social and insurance
• Other
– Building, heating, lighting
– Networking and communications
– Shared facilities (E.g. library, restaurant)

5. Cost and Price
• The relationship between the software
development cost and charged price from the
customer is not simple
• Price is influenced by
– Organization
– Economy
– Politics
– Business considerations

6. Pricing Factors
• Market opportunity
– Accepting low profit on one project may give the
opportunity of more profit later
– Gaining experience
– Wish of moving into a new segment in market
• Cost estimate uncertainty
– Unsure cost estimate can lead expecting higher
than normal profit

7. Pricing Factors…
• Contractual terms
– Customer allows developers to retain the
ownership of the source code and reuse it in other
projects
• Requirements volatility
– Requirements are likely to change
– Price can be lowered to win the contract
– Higher prices can be charged later for changing
requirements

8. Pricing Factors…
• Financial health
– Developers may be in financial difficulty
– Price can be lowered to win the contract
– Better to make smaller profit than normal profit
than to go out of business
– Break even may also be a solution

9. Estimation Models
• Expert judgment
• Analogy
• Parkinson’s law
• Price to win

10. Expert Judgment
• Experts in both software development and
application domain use their experience
• Advantages
– Relatively cheap
– Accurate if they have knowledge in similar
systems
• Disadvantages
– If there are no experts!

11. Analogy
• The project is compared to a similar project in
the same application domain
• Advantages
– Accurate if project data is available and
people/tools are the same
• Disadvantages
– Impossible without a similar project available
– Systematically maintained cost database is
necessary

12. Parkinson’s Law
• Whatever the resources available is the cost of
the project
• Advantages
– No need to overspend
• Disadvantages
– System is usually unfinished

13. Cost Pricing to Win
• Whatever the customer is able to spend is the
cost of the project
• Advantages
– Can get the contract
• Disadvantages
– Customer satisfaction of the product is less
– Cost does not reflect the work required

14. Algorithmic Cost Modeling
• A mathematical function is used to estimate
the cost
– Inputs: Project, Process, Product
– Decided by project managers
• Historical data are studied to derive the
function
• Commonly used product attribute is LOC
(code size)

15. Software Productivity
• The rate at which individual software
engineers involve in development process is
known as software productivity
• Although quality assurance is a factor in
productivity assessment, the productivity is not
quality oriented
• The useful functionality produced per time unit
should be measured

16. Productivity Measures
• Size related measures:
– Lines of delivered source code
– Object code instructions
– Etc
• Function related measures:
– Functionality of the delivered software
– E.g. Function points

17. Lines of Code
• What programs should be considered as part of
the system?
• Assumption of the model:
– The relationship between system size and volume
of documentation is linear
• Key thing to remember:
– Uncertainty is more important than the initial line
– Seek justifiable bounds

18. Productivity Comparison
• Low level language verses high level language
• Verbose code verses compact code

19. Function Points
• Program characteristics are considered
– External inputs and outputs
– User interactions
– External interfaces
– Files used by the system
• Corresponding weights are assigned to each
characteristic

20. FPs and LOC
• FPs can be used to estimate LOC
– LOC = AVC * (Number of FPs)
– AVC is a factor which depends on the
programming language
• Assembly language: AVC = 200 to 300
• 4 GL language: AVC = 2 to 40
• FPs are subjective and dependent on the
estimator
– FP automation is impossible

21. Productivity Estimates
• Real time embedded systems
– 40 to 60 LOC per month
• Systems programs
– 150 to 400 LOC per month
• Commercial applications
– 200 to 900 LOC per month

22. Productivity Factors
• Application domain experience
• Process quality
• Product size
• Technology support
• Working environment

23. Changing Technologies
• Previous estimating experience does not carry
over to new systems due to changes in
technology
– Use of web services
– Use of CASE tools and program generators
– Development for and with reuse
– Using scripting languages

24. COCOMO
• Constructive Cost Model (COCOMO)
• Estimates are derived as functions of variables
• Data of past projects must be available
• First published by Dr. Barry Boehm in 1981
• Derived through statistical regression of data
from 63 past projects

25. Example
Size 2000
SLOC
8000
SLOC
32000
SLOC
128000
SLOC
MM 5 21 91 392
Schedule
Months
5 8 14 24
Staff 1.1 2.7 6.5 16
SLOC/
MM
400 376 352 327

26. Basic Effort Equation
• (Effort) = A * (Size) ^ (Exponent)
• (Effort) = (EAF) * A * (Size) ^ (Exponent)
• Estimates the man-months (MM) of effort for
software development project
– 1 MM = 152 hours of development
• Size is the source lines of code (SLOC)

27. Modes and Models of COCOMO
• Three modes
– Organic mode
– Semidetached mode
– Embedded mode
• Three models
– Basic model
– Intermediate model
– Detailed model

28. Modes of COCOMO
• Organic mode
– Similar to an earlier project
– Familiar and stable environment
– E.g. Accounting system
• Semidetached mode
– Between Organic and Embedded modes
• Embedded mode
– New project involving new inventions
– E.g. Real-time systems

29. Models of COCOMO
• Basic model
– Roughly estimates project cost, performance and
schedule
• Intermediate model
– EAF (Effort Adjustment Factor) is used from 15
cost drivers
• Detailed model
– Different Effort Multipliers are used for each phase
of project

30. Effort Equation : Basic
• (Effort) = A * (Size) ^ (Exponent)
• A is a constant which depends on the mode of
development
– Organic: 2.4, Semidetached: 3.0, Embedded: 3.6
• (Exponent) is also a constant which depends
on the mode of development
– Organic: 1.05, Semidetached: 1.12, Embedded:
1.20
• Size should be in KSLOC (1000 SLOC)

31. Schedule Equation : Basic
• Minimum time to develop (MTDEV)
• (MTDEV) = 2.5 * (Effort) ^ (Exponent)
• Exponent is a constant which depends on the
mode
– Organic: 0.38, Semidetached: 0.35, Embedded:
0.32
• 2.5 is constant for all modes
• MTDEV is independent from the number of
people assigned

32. Effort Equation : Intermediate
• (Effort) = (EAF) * A * (Size) ^ (Exponent)
• A is a constant which depends on the mode of
development
– Organic: 3.2, Semidetached: 3.0, Embedded: 2.8
• (Exponent) is also a constant which depends
on the mode of development
– Organic: 1.05, Semidetached: 1.12, Embedded:
1.20
• Size should be in KSLOC (1000 SLOC)

33. EAF (Effort Adjustment Factor)
• EAF = Product of effort multipliers

34. Schedule Equation : Intermediate
• Minimum time to develop (MTDEV)
• (MTDEV) = 2.5 * (Effort) ^ (Exponent)
• Exponent is a constant which depends on the
mode
– Organic: 0.38, Semidetached: 0.35, Embedded:
0.32
• 2.5 is constant for all modes
• MTDEV is independent from the number of
people assigned

35. Tool Demonstration
http://sunset.usc.edu/research/COCOMOII/expert_co
como/expert_cocomo2000.html

36. Thank you!