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 MeasureMeasurement ScopeSize
SLOCPhysical software objectTechnical size in SLOCs
IFPUGFunctional User RequirementsFunctional size in FP
NesmaFunctional User RequirementsFunctional size in FP
COSMICFunctional User RequirementsFunctional size in CFP
SNAPPart of the non-functional user requirementsNon-functional size in SNAP points
Use Case PointsUsecases, technical project characteristics, environmental project characteristics‘Effort/Size combination’ in Usecase points
Fast Function PointsFunctional user requirements and configuration sizeGartner FFP
Story PointsBacklog 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.


Nesma simplified estimating model

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.

The functional size of software projects can be used in the most widely used parametric  estimation tools and models, e.g. QSM SLIM, Galorath SEER, Price Systems Trueplanning  and COCOMO II.

Next blog

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).

A blog post represents the personal opinion of the author
and may not necessarily coincide with official Nesma policies.
Share this post on:


Leave a Comment
  1. dmbeckett says:

    While I agree with everything stated, I would like to address a couple of items that merit consideration. One of the factors that has the most dramatic impact on a project’s cost (and quality) is schedule. The relationship between cost and schedule is non-linear. Simply stated, one unit of schedule reduction is purchased at a cost of many units of effort. Consequently, when estimating it is important to explore the impact of various schedules since they will affect the cost. In “The Mythical Manmonth” Brooks stated that the lack of sufficient schedule caused more software project failures than all of the other causes combined. My own experience as a software estimator serves only to confirm this.

    While I am a supporter and practitioner or functional sizing, what matters when estimating a software project is how long it will take to deliver, how much it will cost, what is the best staffing profile, and how reliable will the end product be. Non-functional requirements have a role in determining these and they are not all fixed costs that can be added on to a model based on functional requirements. For example, in an ERP implementation a significant portion of the work will be in configuring the product. There is nothing functional about configuration, but any estimation model that ignores it will produce inaccurate results.

    When estimating we want to take into account all of the size factors that will impact the cost and schedule. Some of these are functional size, others are not.

    Best regards,

    Don Beckett, CFPS

  2. Kalyana Chakravarthy says:

    Dear Team,
    I have a few queries w.r.t to Estimation.

    1. While developing RICEW components, what’s the most suited method for estimation.
    2. while implementing Oracle R12 from ; e.g Financial modules, how do we estimate?
    Are there any case studies?
    Thanks in advance !!!

Leave a Reply