Software Cost Estimation
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.
- social and insurance costs.
- Effort costs must take overheads into account:
- Costs of building, heating, lighting.
- Costs of networking and communications.
- Costs of shared facilities (library, staff restaurant).
Pricing Factors
The cost is how much the company spends on making the software product. The price is what the customer pays.
- Market Opportunity - A low price may be quoted when moving into a new segment. This may bring the opportunity of more profit later.
- Cost Estimate Uncertainty - The price may be increased if the cost is unknown.
- Contractual Terms - If the source code is withheld then the price could be less.
- Requirements Volatility - If the requirements are likely to be changed an organisation may lower its price to win the contract. High prices may then be charged for changes to the requirements.
- Financial Health - Developers in financial difficult may lower their price to gain a contract. It is better to make a small profit than go out of business.
Programmer Productivity
These are ways of measuring how much work a particular programmer has completed:
- Size-Related Measures:
- Lines of code delivered:
- This isn’t the best measure, just write loads of code that does nothing.
- Object code instructions.
- Lines of code delivered:
- Function-Related Measures:
- Based on an estimate of the functionality of the delivered software.
- Function-points - A weight is associated with each point:
- External inputs and outputs.
- User interactions.
- External interfaces.
- Files used by the system.
- Object Points:
- Number of screens.
- Number of reports.
- Number of modules developed.
Multiply each raw count by the weight and sum the results. {:.info}
Factors Affecting Productivity
- Application Domain Experience
- Development Process Quality
- Project Size
- Due to increased communication.
- Technology Support
- Working Environment
Estimation Techniques
You should ideally use multiple of the following to find the cost of the system:
- If they don’t return approximately the same result, there is insufficient information available.
- Pricing to win is sometimes the only applicable method.
Algorithmic Cost Modelling
This is a formulaic approach based on historical cost information. This is generally based on the size of the software.
\[\text{Effort}=A\times\text{Size}^B\times M\]Where:
- $A$ - Organisation-dependant constant.
- $B$ - Reflects the disproportionate effort for large projects.
- $M$ - A multiplier reflecting product, process and people attributes.
Expert Judgement
One or more experts in both software development and the application domain use their experience to predict software costs. The process iterates until some consensus is reached.
- Advantages:
- Relatively cheap estimation method.
- Can be accurate if experts have direct experience of similar systems.
- Disadvantages:
- Very inaccurate if there are no experts.
Estimation by Analogy
The cost of a project is computed by comparing the project to a similar project in the same application domain.
- Advantages:
- Accurate if project data is available.
- Disadvantages:
- Impossible if no comparable project has been tackled.
- Needs a systematically maintained cost database.
Parkinson’s Law
The project costs whatever resources are available:
Work expands to fill the time available. The cost is determined by available resources rather than by objective statements.
- Advantages:
- No overspend.
- Disadvantages:
- System is usually unfinished.
Parkinson’s Law Example
The project should be delivered in 12 months and there are 5 people therefore:
\[\text{Effort}=60p/m\]Pricing to Win
The project costs whatever the customer has to spend.
- Advantages:
- You get the contract.
- Disadvantages:
- The probability that the customer gets the system they want is small.
- Costs do not accurately reflect the work required.
Top-Down or Bottom-Up Estimation
Any of the previous approaches can be completed as top-down or bottom-up.
- Top-Down - Start at the system level and assess the overall system functionality and how this is deliver through sub-systems.
- Bottom-Up - Start at the component level and estimate the effort required for each component. Add these effort to reach a final estimate.
Estimation Accuracy
The size of a software system can only be know accurately when it is finished:
- As the development process progresses the size estimate becomes more accurate.