MG6088 - Software Project Management - PROJECT LIFE CYCLE AND EFFORT ESTIMATION

MG6088 - Software Project Management - PROJECT LIFE CYCLE AND EFFORT ESTIMATION

Some problems with estimating:

1. Subjective nature of much of estimating
2. It may be difficult to produce evidence to support your precise target
3. Political pressures
4. Managers may wish to reduce estimated costs in order to win support for acceptance of a project proposal
5. Changing technologies
6. these bring uncertainties, especially in the early days when there is a ‘learning curve’
7. Projects differ
8. Experience on one project may not be applicable to another

Basis for successful estimating:

• Information about past projects
• Need to collect performance details about past project: how big were they? How much effort/time did they need?
• Need to be able to measure the amount of work involved
• Traditional size measurement for software is ‘lines of code’ – but this can have problems

A taxonomy of estimating methods:

• Bottom-up - activity based, analytical
• Parametric or algorithmic models  e.g. function points
• Expert opinion - just guessing?
• Analogy - case-based, comparative
• Parkinson and ‘price to win’

Parameters to be Estimated:

• Size is a fundamental  measure of work
• Based on the estimated size, two parameters are estimated:
• Effort
• Duration
• Effort is measured in person-months:
• One person-month is the effort an individual can typically put in a month.

Measure of Work:

• The project size  is a measure of the problem complexity in terms of the effort and time required to  develop the product.
• Two metrics are used to measure project size:
• Source Lines of Code (SLOC) 
• Function point (FP)
• FP is now-a-days favoured over SLOC:
• Because of the many shortcomings of SLOC.

Major Shortcomings of SLOC :

• Difficult to estimate at start of a project
• Only a code measure
• Programmer-dependent
• Does not consider code complexity