Pragmatic Software Cost Estimation

1
Pragmatic Software Cost Estimation

• Mike Calvanese
• ISYS 420

2
Problems

• Lack of well-documented case studies of projects
  that use iterative development approach
• Data that does exist from projects is suspect in
  terms of consistency and comparability
• The software industry has inconsistently
  defined units of measure

3
Debates Among Developers

• Which cost estimation model to use
• Whether to measure software size in source lines
  of code or function points
• What constitutes a good estimate

4
Measurements of Software Size

• Source Lines of Code (SLOC)
• Function Points
• Ad Hoc/Subjective

5
Source Lines of Code

• Advantages
• Most people in the industry are comfortable
  with its general mass
• SLOC tends to work well in custom-built
  applications
• SLOC measurement is easy to automate and
  instrument
• SLOC are particularly useful in later stages of
  the project life-cycle

6
Source Lines of Code

• Disadvantages
• SLOC can become ambiguous due to changes in
  programming and languages
• -Language advancements
• -Automatic source code generation
• -Object orientation
• Different programmers have different styles

7
Function Points

• Advantages
• Independent of Technology
• -Works well for those on the project who are not
  technology-oriented
• Much better primitive unit for comparisons among
  projects and organizations
• Works well for cross-project or
  cross-organization comparisons
• Works well in early stages of the project
  life-cycle when actual coding is not yet in full
  production

8
Function Points

• Disadvantages
• Primitive definitions are abstract
• Measurements are not easily derived directly
  from the evolving artifacts

9
Still Very Inexact

• Conventional cost models have been described as
  within 20 of actuals, 70 of the time.
• This is scary to investors and stakeholders, as
  very seldom are variations of estimates for the
  better.

10
Attributes of a Good Software Cost Estimate

• It is conceived and supported by the project
  manager, architecture team, development team, and
  test team accountable for performing the work.
• It is accepted by all stakeholders as ambitious
  but realizable.
• It is based on a well-defined software cost model
  with a credible basis.
• It is based on a database of relevant project
  experience that includes similar processes,
  similar technologies, similar environments,
  similar quality requirements, and similar people.
• It is defined in enough detail so that its key
  risk areas are understood and the probability of
  success is objectively assessed.