Software Project Estimation
- 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
- 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
- The most commonly used size indicator, but obviously not the best one!
- 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
- 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
- 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
- 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
- Based on the experience of developers
- Gather experts
- Conduct group discussion
- Gather estimates
- Distribute estimates
- Repeat until consensus is reached
- Takes advantage of experience
- educates developers about the software
- reinforces team concept
- 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)
- 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.
- Data Communications
- Distributed Computing
- Performance Requirements
- Constrained Configuration
- Transaction Rate
- 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)
- 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
- 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.
- Uses a similar process to function points and feature points.
- Suits object-oriented software.
- Uses different weighting factors and tables.
 Prof. Shervin Shirmohammadi, University of Ottawa SEG4100 Course Notes, Lecture 5