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

Software sizing is most useful before the code is written and it is an indicator of the amount of business functionality: counting user stories, counting story points and the leading function point analysis methods: COSMIC function points and traditional (IFPUG) function points.  After it has been written, some also examine the number of lines of code.

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.

Counting Story Points

Story points are an arbitrary proxy for size measurement that should only ever be used within a team.  They are not a valid measure nor metric for determining progress against team.  Remember that story points can change over time, and are an inconsistent opinion of the duration likely for some activity to take.  They are highly game-able by those providing the count.   The popularity of story points is a somewhat bizarre behaviour of the majority of the software industry – their popularity is not merited.  On the other hand, COSMIC Function Points and IFPUG Function Points are both formal, consistent ISO standards for measuring size.

A user story can vary in size dramatically.  One story can be delivered in minutes another can require an entire team to work for a month.  Counting stories of different size is an indication of progress but is not a valid measure of progress.

ISO standard Functional Sizing – aka Function Point Analysis

The only consistent way of measuring software size that exists as of 2021 is functional sizing.  There are two leading flavours:   IFPUG Function Points (1st Generation) and  COSMIC Function Points (CFP) Points (2nd Generation).

Both Function Point standards have been around for many years (IFPUG:1974,  COSMIC:1998)  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 types that are moved and stored.  Both standards are mature, independently maintained and free or inexpensive to learn.  We recommend the 2nd Generation COSMIC Sizing methodology.  The units of the COSMIC sizing methodology are the COSMIC Function Point (CFP)

COSMIC Function Points

Some of the key benefits of the COSMIC Function Points standard are:

  1. COSMIC Sizing is based on principles of software design.  As a standard, no tuning is needed when applied to different types of software (custom coding, middleware, web apps, multi-layered software, system software, embedded systems or data warehouse projects).
  2. COSMIC gives us a definition of a single function point,  each movement of a data group Entry, Exit, Read, Write counts as 1 CFP.
  3. CFP can be accurately measured from incomplete requirements which makes them suited to Agile and various forms of scaled Agile work.
  4. CFP are faster and easier to learn than IFPUG Function Points.  (1/3 of the number pages for the entire methodology syllabus)
  5. COSMIC FP can be determined automatically to a higher degree of precision than IFPUG via automated requirements analysis.

IFPUG Function Points

Having said that COSMIC function points are preferrable over traditional IFPUG function points, the latter benefits from larger volumes of published and available benchmark data.  IFPUG function points were designed in the 1970’s when software design was less layered and segregated that it is nowadays.   The standards remains largely unchanged from it’s initial concept.

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

 Conclusion

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.