Estimating Size

We need to obtain the size, or an estimate of the size, of a proposed piece of software in order to provide estimates of the effort and timescale of a software project. The size of a software artefact is also useful in forward planning for maintenance and support effort requirements.

Clearly it is best to actually measure the size of software using one of the functional size measurement techniques. However at the stage when an estimate of effort and duration is normally required the software will not have been fully defined. We must therefore employ methods which allow us to estimate the size of the software and then use this estimate as an input to our effort estimation.

Preparation

Estimation of the size of a software artefact before it is specified in detail will always be an imprecise exercise. The first step is to gather as much information regarding the software to be built as possible, the more that is known or can be inferred the more precise we can be.

Estimates of Size

Several estimating approaches can be used and these largely depend upon the documentation available. So if for example the number of logical data groups likely to be required is known, then this can be used to generate an input. This is based upon the known average contribution of such data groups to functional size (in the region of 20% of total FP size is contributed by data groups).

If however documentation is available showing the number of business Use Cases then a heuristic based upon the number of functional processes likely for each use case can be employed.

Other techniques based upon information concerning the number and type of screens to be developed, the entity relationship model, and so on can also be utilised.

All of these techniques are greatly assisted if there is an analyst or designer who has good domain experience as it can be use to assist the estimator in arriving at a realistic estimate of size.

Many estimates of size have been provided on the basis of the user's statement of their requirements.

Such estimates, as with all estimates, must be expressed as a range between the smallest expected size and the largest expected size.

Measuring Size of Requirements

Once all, or most, of the requirements have been established then it is possible to start measuring their size. This is still an estimate since it is based on the requirements not a detailed design or piece of software. The size is measured utilising one of the same functional sizing techniques that would be employed for measuring a design or the actual software.

These techniques conform to the ISO Standard for the Functional Size Measurement of Software ISO/IEC 14143:1998 and each has approval as an ISO/IEC standard.

COSMIC FFP (Full Function Points) – ISO/IEC 19761
Used in a wider range of problem domains, such as real-time or infrastructure development, as well as the business/MIS domain. The method caters for software system types; avionics, telecoms, production systems and so on. It has has been specifically designed to fit with the complex multi-layered architectures and approaches to modern software development. COSMIC FFP demonstrates an advance in generality, simplicity and accuracy.

MkII FPA– ISO/IEC 20968
A method designed to address the structured approaches in software design. The MKII method is equally useful in the area of object oriented design, fitting well with the use case notation. It is the preferred method of the UK government as it is easily applied to large systems.

IFPUG FPA – ISO/IEC 20926
The original method of sizing, it is currently at version 4. This method is still the most widely used and works well in the business/MIS domain. It is applicable to object oriented developments.