We take a look at the various ways to measure software size

There are four common ways of software sizing: counting lines of code , counting user stories, counting story points and counting function points.

Straight to the point: we recommend that you use COSMIC Function points in most instances.  Why? because they are valid, reliable, consistent, ungameable, quick to measure and suited to Agile work where the full requirements may not be known up front.

measuring software

Why does software sizing matter?

Developing software is labour-intensive knowledge work.  The biggest cost driver for developing software is usually the human effort to create it.   Size is the most significant factor in estimating the effort (i.e. cost) and time to build software.  So let us look at the various approaches to sizing software.

Lines of Code

Lines of code is easily and automatically done by most coding tools.  There are two main values, the gross number of lines used (LOC) and the net number of lines of functional code (SLOC).

Counting lines of code has limited merit in software project management.   Consider for example two developers who both write 50 lines of code in a day.  It could be that one of the developers writes terse, efficient code that makes good use of underlying language capability.  His 50 lines good deliver significant functionality, possibly even an entire (tiny) application, where as the other might just perform a very basic validation.  Superficially these  are as productive as each other, both writing 50 lines per day.    This is the main reason that we limit the use of SLOC for software sizing.

Function Points

There are other ways of measuring software, such as counting user stories, counting use cases, counting the number of pages of written requirements.  However these are all highly variable measures from one project to another.  The only common and consistent currency is that of Function Points.

Function Points have been around since the 1970’s.  They are a consistent, user-centric description and measure of functionality in terms of inputs and outputs and data stored.   They are counted by examining the requirements, and applying some rules/principles to determine the data that is moved, and stored.  The two most important “flavours” of function point are IFPUG FP and COSMIC Function Points (CFP).  The latter is a more universal and up to date approach.  Both are mature, independently maintained and free or inexpensive to learn.

Counting Function Points Manually

Up until now, counting function points has been a laborious manual process  You need to read the requirements and then record the function point counts on paper, or in a spreadsheet.  Accurate and consistent counts are achieved only if the count is performed by certified and experienced function point specialist.  On average a certified measurer can measure up to 2000 FP/ week,  this is the equivalent of about $2m worth of software.  SLOW, ACCURATE

Counting Function Points by Estimation

Using some rules of thumb, estimated FP counts can be achieved by looking at a number of contributory factors.  If your application is predominantly a database type application, you can count the number of database tables of data being maintained by the application.  You then multiply the number of tables by 27-30 for an IFPUG estimation.  This is just one of many useful rules of thumb and should be not be relied upon for anything but a high level size.  Counting speed: 5,000 – 50,000 FP / person week  FAST, INACCURATE

Backfiring Function Points from Lines of Code

Most software language have published averages for lines of code per function point.  For example 50 lines of Java is, on average, equivalent to one function point.   Counting the lines of code and dividing by this number is called “backfiring”.  This is useful after the code has been written.   You need to be careful with this approach especially when using large volumes of pre-written frameworks which may need to be excluded from a custom code count. Counting speed: up to 5,000 FP / person week.  FAST, INACCURATE

Automated Function Point Count from Code

It is now possible to automate function point counting from code.  The  Cast Software company have developed software that will perform a reliable Automated Function Point count based on existing application code.  It takes some effort to prepare the code so that it can be interpreted, thereafter a reliable count can be achieved. This is far superior to the backfiring approach.  It has the added benefit of providing deep insight into the application code.   FAST, CONSISTENT, ACCURATE

Automated Function Point Count from Written Requirements

ScopeMaster is the only system available for automating function point count from written requirements.   ScopeMaster interprets the English used to write the requirements or user stories.  It is not 100% accurate, but our algorithms are being continuously improved, through formal verification and through machine learning.   We are expecting to reach a consistent accuracy in excess of 85%.  Currently our results are in the 70-95% accuracy range.   Dealing with the nuances of the english language, makes it quite a challenge to reach 100% accuracy.  But the clearer the requirements the more accurate the count.  Given the same set of requirements it will always be consistent.  Combined with a manual check by a Function Point specialist we see counting rates of 10,000 – 20,000 FP / per man week.  (approximately $10- $20m of software) FAST, CONSISTENT, FAIRLY ACCURATE


If you want to determine the size of an application from the written requirements you have two main choices: count function points manually or use ScopeMaster to count them for you.  If you already have application code that you want to measure, then there are additional choices: backfire from the lines of code, estimate from technical components (e.g. based on a database table count), or look at the automation of functional sizing from CAST Software.