Software size is the main driver for project cost estimation
By far most cost estimation models for software development, enhancement or maintenance projects use the software size as the main input parameter. Software size is widely recognized as an important cost driver for the effort and cost needed for software projects. Unlike many physical objects however, there are no universal measurement standards to measure software size. While a painter who needs to estimate the cost of painting a wall usually would measure the size of this wall in square feet or square meters as an input for his estimate, the measurement of software size is hard because of the fact that it has no real physical shape. However, there are a number of methods available in the industry that can be used to measure software size. For cost estimators that are no experts on software sizing however, it may be difficult to understand the advantages and disadvantages of the methods available and therefore they might find it difficult to select the best method for their purpose. In this blog, an overview is given of the most widely used methods for software sizing available to the industry. Also the advantages and disadvantages of these methods as well as recommendations of which methods to use for which types of software project estimates are given. In the following table the software size measurement methods are displayed that are covered in this blog.
|Software Size Measure||Measurement Scope||Size|
|SLOC||Physical software object||Technical size in SLOCs|
|IFPUG||Functional User Requirements||Functional size in FP|
|Nesma||Functional User Requirements||Functional size in FP|
|COSMIC||Functional User Requirements||Functional size in CFP|
|SNAP||Part of the non-functional user requirements||Non-functional size in SNAP points|
|Use Case Points||Usecases, technical project characteristics, environmental project characteristics||‘Effort/Size combination’ in Usecase points|
|Fast Function Points||Functional user requirements and configuration size||Gartner FFP|
|Story Points||Backlog items, functional and non-functional||'Effort/Complexity combination' in Story points|
Software project cost estimation
In software project cost estimation, the focus is usually on estimating the effort hours of the people in the team. The reason for this is that the effort hours usually drive the total costs of the project. Of course there are other costs involved, e.g. licenses, workplaces, infrastructure, et cetera, but these costs are not driven by the software size and can also be calculated in an easier way.
A (simplified) estimation model is displayed in the following figure.
The size of the software to be developed is the main input parameter for the project estimate. It is crucial for the accuracy of the estimate that the size is measured accurately. Selecting a realistic productivity rate is also a very important step. This should be done based on historical data or with the help of professional parametric tools that are based on relevant industry data. Using company data is usually preferred, as this shows the actual capabilities of the organization which may be (much) better or (much) worse than industry average. Project specific characteristics can also be important to consider, e.g. schedule pressure, team size, quality constraints, et cetera. Therefore, parametric tools are usually very useful in this step of a project estimate.
Multiplying the size by productivity, the gross effort hours are calculated. Usually some adjustments are necessary based on a risk analysis. If one needs to be 99% sure that there won’t be an overrun of the costs for instance, the effort hours will probably be adjusted to create a contingency.
Software size measurement methods classification
There is an important distinction between functional size measurement methods and other (non-functional size measurement methods or hybrid methods). Functional size measurement methods measure the functionality (‘what does the software do’) that the software offers its users and quantifies this in some way. The more functionality the user can use, this greater the size of the software. One of the main advantages of these type of methods are that the size is independent of technology used (e.g. Java, .Net, Oracle) and implementation method used (COTS, waterfall development, agile development, etc.).
Non-functional size measurement methods measure the technical artifacts of the software, usually the software code that is constructed. There are also hybrid methods available that measure functional aspects, technical aspects and sometimes also environmental aspects of the software project in order to come up with a size, e.g. Use Case Points. However, most methods either measure the functional size or the technical size of software.
Functional size measurement methods – advantages and disadvantages
In general, the main advantages of all ISO/IEC standards for functional size measurement are:
- The size measurement is carried out in an objective way. Two certified measurers should come up with the same size when measuring the same functional user requirements;
- The size measurement is repeatable and verifiable. If any assumptions were made by the measurement specialist, these should be documented as part of the size measurement;
- The size measurement is defendable. This is very important as functional size is often used in unit-priced contracts between suppliers and customers. Price per function point contracts are only possible when the functional size can be determined without a dispute;
- Some of the methods offer derived methods that enable cost estimators to fairly accurately measure the functional size quite early in the project lifecycle. For instance the Nesma indicative method can be used after the requirements analysis phase and offers a quick way to get an indication of the functional size (+50% / -30% accuracy).
- Functional size can be recognized as ‘value’ to users and customers of the software system. More functionality means more value and therefore higher costs. This for instance when compared to technical size like source lines of code (slocs) where it is unclear if more slocs mean more value to the user and/or the business.
- Because of the standardization, the most important advantage is that it becomes possible to store the data of completed projects in order to use in estimates for new projects. Just like the painter that has data of his productivity in hours per square feet for specific types of walls, organizations are able to get insight in their productivity in terms of hours per function point. This enables benchmarking, for instance against the open industry database of the International Software Benchmarking Standards Group (ISBSG).
Some of the disadvantages of using functional size measurement methods for software sizing and estimation are:
- Functional size measurement requires people with the expertise to carry out this activity. As it is such an important activity, it is really recommended to only have certified measurers do the sizing and even then have a proper review process in place. There are some initiatives to automatically measure the functional size of software but until now these are not very accurate;
- Functional size measurement takes some time and costs effort. Usually this is less than 1% of the project budget and by far most projects can be measured within 1 week of duration. Usually the benefits of doing a functional size measurement outweighs the cost many times, as it enables the stakeholders to draw up more realistic plans and avoid overruns and possible humiliation;
- Functional size measurement methods measure the functional user requirements that are specified in functional documentation. There are some requirements to this documentation in order for the measurers to be able to measure it. However, if these requirements are not met, the project is probably doomed anyway, as the programmers won’t be able to code and the testers won’t be able to test using these documents. A functional size measurement is in fact a powerful static test on the requirements, in many cases serious flaws and omissions are detected, enabling an early adjustment of the specifications and therefore preventing the costs of later detection and correcting of the defects.
In the next blog on this topic, I will give my opinion on the advantages and the disadvantages when it comes to software project cost estimation of the methods listed in the table.
About the author
Harold van Heeringen is a senior consultant software metrics / senior software cost engineer for Sogeti Nederland B.V. Apart for his work for the department Sizing, Estimating & Control of Sogeti, he is involved in Nesma (board member), the International Software Benchmarking Standards Group (ISBSG, current president) and the Common Software Metrics International Consortium (COSMIC, International Advisory Council, representing the Netherlands).