Cost Estimation Tips & Techniques For Software Projects

Software costs and effort estimates is an important aspect of Project Planning objectives. The estimation process can never be exact because of the variable components involved like human, technical, environmental, business and political. However systematic steps followed can ensure to provide estimates within acceptable risks.

The Software cost components comprises of hardware and software costs, travel and training costs, effort costs including overheads. Effort estimation comprises of prediction of man hours of work and number of workers required for development.

 

The common viable options are using Decomposition Techniques to generate the cost and effort estimates or to use one or more Empirical Models.

 

The Decomposition Techniques normally is a ‘Divide and Conquer’ approach. It is done in a stepwise fashion by dividing a project into major functions and related software processes. The Empirical estimation models can be used to complement the decomposition techniques.

 

There are also automated estimation tools available with graphical user interfaces. The input data for these tools will be the major characteristics of the development organization such as experience, environment and the software to be developed. The output is the cost and effort estimates. The accuracy of the costing increases with the reliability of the historical data used to seed the estimates.

 

In using the Decomposition techniques, the project planner must understand the software scope and generate estimate of its size. The accuracy of a software project estimate is dependant on the ability to estimate the size of the product and to translate this into human effort, calendar time and cost of activities. The degree to which the abilities of the team are reflected accurately, stability of the requirement and supporting environment are factors that contribute to this process.

 

The size refers to a quantifiable outcome of the software project. In a direct approach size can be measured as LOC (Lines of Code). In an indirect approach size can be represented and measured in terms of FP (Functional Points). LOC is based on assumption that there is a linear relationship between system size and volume of documentation. Function point is based on a combination of software characteristics such as external inputs and outputs, external interfaces and user interactions.

 

Sizing can be ‘Fuzzy Logic Sizing’, ‘Functional Point Sizing’ or ‘Standard Component Sizing’ or ‘Change Sizing’.

 

In fuzzy logic sizing, approximate reasoning techniques are used. The planner identifies the type of application, establishes its size approximately on a qualitative scale and refines this with access to personal experience and historical information.

 

In Standard Component Sizing the project planner estimates the number of occurrences of each standard component and uses historical data to determine the size of code per standard component.

 

In Change sizing which is normally used for enhancements to an existing project, the planner estimates the number and type of modifications and uses an effort ratio for each type of change.

 

The Decomposition technique can be of two kinds of views. They are Decomposition of the Problem leading to problem based estimation and Decomposition of the Process leading to process based estimation.

 

In Problem based estimation LOC and FP are distinct estimation techniques with a number of characteristics in common. The Project Planner starts with bounded software scope and attempts to decompose software into problem functions that can be estimated on an individual basis. LOC or FP (estimation variables) is estimated for each function.

 

Baseline productivity metrics are applied to the estimation variable chosen and cost or effort for the function is derived. These function estimates are consolidated to give an overall estimate. The LOC and FP estimation techniques differ at the level of details required for decomposition. For LOC, decomposition focuses on software functions whereas FP based estimation focuses on information domain values.

 

Process based estimation is most common technique whereby the process is decomposed into a small set of tasks and effort is estimated task wise. From project scope, software functions are obtained and series of software process activities are associated with each function. The Planner estimates the effort (eg. Person months) required for each software process activity corresponding to each software function. Average labor rates are applied to the effort estimated for each activity. Cost and effort for each function and software process are consolidated.

 

An Empirical estimation model for software uses empirically derived formulas to predict effort as a function, of values of LOC or FP which has been estimated earlier. The empirical data that supports these models are derived from a sample set of projects and must be used judiciously.

 

The Decomposition technique and Empirical estimation models are also available as part of a variety of automated estimation tools. These allow the planner to perform ‘What If ‘analysis for important project variables. They help to perform generic functions such as sizing of project deliverables, selection of project activities, predicting staffing requirements, predicting software effort, cost and schedules. One such popular empirical model is the COCOMO (COnstructive COst MOdel) model based on project experience.

 

Each estimation method differs and has its own strength and weaknesses. Estimation should be based on several methods and checked that approximately same result occurs. If not, action should be taken to get more information to make more accurate estimates