Software Project Estimation

[1]

• You can’t manage something which you can’t measure
• We need some sort of measurement for:
  • size of the project
  • effort and cost
• Estimating software projects is notoriously poor.
• If performance doesn’t meet estimates then either:
  • the performance was poor; or
  • the estimate was poor

Impact on Development Process

[1]

• One of the key factors in software project management
• If “software managers and engineers are trained in and apply software estimating and planning procedures”, then you are one step closer to CMM level 2 (repeatable).

Lines of Code

[1]

• The most commonly used size indicator, but obviously not the best one!
• Issues:
  • How can lines of code be defined?
  • How can the total lines of code be known before coding?
  • How interpret lines of code? Is 250 more productive than 200?
  • What about different programming languages which have a different syntax?

Lines of Code Calculation

[1]

• Prerequisite for line of code calculations is the work breakdown structure
• Line = statement
• Line = data definition
• Line != comments
• Line != debug code
• Line != test cases
• For different languages, convert all to assembly.

Beta Distribution Measurement

[1]

• Ask developers for the following line of code values:
• Optimistic (0)
• Pessimistic (P)
• Realistic (R)

LOC = (O+P+4*R)/6

• ex: R=250, O=200, P=400
  • LOC = 266

The Blitz

[1]

• Based on historical observation of previous projects.

LOC = Processes * prgs/processes * avg. prg size

• Process = class, db table, …
• Ex: 20 classes, 1 program/class, 50 java lines of code/program
  • LOC = 20*1*50 = 1000

Wideband Delphi

[1]

• Based on the experience of developers

1. Gather experts
2. Conduct group discussion
3. Gather estimates
4. Distribute estimates
5. Repeat until consensus is reached

• Pros:
  • Takes advantage of experience
  • educates developers about the software
  • reinforces team concept

Function Points

[1]

• Uses the functionality of the software as a measure of its complexity.
• Analogy: For a given house, we can say how many square meters it has (lines of code) or we can say how many bedrooms and bathrooms it has (function points).
• A measure of the functionality of a given software.
• Works best for traditional applications; not very suitable for algorithmically intensive applications. (ex: real-time and embedded applications)

Weighting Factor

[1]

• There are tables that provide the project manager with a weighting factor for each category.
• Input can be:
  • Simple (weighting factor=4)
  • Average (weighting factor=5)
  • Complex (weighting factor=7)
• Ex: 1 to 5 data items referenced from 1 file is considered a simple function. Same action from 5 files is considered average.
• Sum of all weighted categories is the raw function points.

Environmental Factors

[1]

• Data Communications
• Distributed Computing
• Performance Requirements
• Constrained Configuration
• Transaction Rate
• Re-usability
• Ease of Operation
• And much more…

• For a given project, each factor is rated from 0 (no effect) to 5 (highly affects).
• Sum of all gives the environmental influence factor (N)

Adjustments

• Complexity Adjustment Factor (CAF)
  • Assumes a +-35% inaccuracy in early estimates; therefore:

CAF = 0.65 + 0.01*N

• Adjusted Function Points (AFP)

AFP = CAF * rawFunctionPoints

• Convert to lines of code using tables

Differences with Function Point

[1]

• Also includes number of algorithms
  • weighting factor for an algorithm is 3
• Uses average weighting factors instead of simple, average, and complex values.
• Uses 2 environmental factors: logical complexity and data complexity.
• CAF is calculated using a table.

Object Points

• Uses a similar process to function points and feature points.
• Suits object-oriented software.
• Uses different weighting factors and tables.

—

[1] Prof. Shervin Shirmohammadi, University of Ottawa SEG4100 Course Notes, Lecture 5