Measuring Software Size
We are going to have a look at the various ways of measuring software size
There are three common ways of measuring software size: counting lines of code , counting user stories, and counting function points.
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 dismiss line counting as an metric of very limited merit.
User Stories and Other artefacts
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. The latter is a more universal and evolved concept. However there is more data published on IFPUG function points than Cosmic.
Counting Function Points Manually
Read the requirements and then recording the function point counts on paper, or in a spreadsheet is the most common way. Accurate and consistent counts are achieved if 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 IFPUG FP 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. Rates unknown, but expected to be high. 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 count the size of an application from the written requirements you have two main choices: count manually or try out ScopeMaster. If you already have application code that you want to measure, then there are additional choices, backfire from the lines of code, estimate (e.g. based on a database table count), or look at the automation by CAST Software.