An Introduction to Functional Size and Function Points: Part 1 | DCG

Function points are a measure of the functional size provided to the user by an application. The user is any entity (either a human or another application), outside of the application being measured, that considers the function to be important. Size is determined by applying one of several rule sets, including those outlined by the International Function Point Users Group (IFPUG) or the Common Software Measurement International Consortium (COSMIC). It is important to note that these systems do not measure size in terms of the number of lines of code, but instead based on what the user can ultimately see anduse.

Sizing software helps to establish an appropriate timeline for completing the work, as well as to appropriately allocate resources, including both team members and budget. But how does this relate to the testing process? The adage, “What you can’t measure, you can’t manage,” applies here. 

As a preventative measure, it can be difficult to determine the importance of software testing or how much effort should be applied to it. Coding, by contrast, reveals its value more readily, as it provides clear-cut value by fulfilling requirements. This difference in visibility can cause testing to be less emphasized than other steps, when it should ideally be emphasized throughout the development process. What is needed is a method of making the importance and effectiveness of testing more visible and measurable. Function points can help with this, providing measures that can be applied in test planning and in measuring the effectiveness oftesting.

First Step: Estimating Testing Requirements

One of the measures that is of particular use in testing is test case coverage i, which is defined as:

Number of test cases / Total number of function points

This provides a measure of how thorough the testing process is for a given project. If the test case coverage from a similar project that was determined to have been successful (perhaps using a measure like defect density, described in the next section) is available, this can be used to give an estimate of software test cases needed on a new project. Once the number of function points is known, simply use the number of test cases that gives similar coverage. Since function points can be measured based on requirements, rather than waiting until coding, a good idea of testing needs becomes apparent early in the process. This can be especially helpful when using defect prevention techniques (done throughout development), rather than defect removal (traditionally done at the end of development).

Initially, a software development organization may not have the metrics necessary to determine exactly how much testing is necessary for a given project. This does not have to be an impediment to using software measurement to get an initial estimate. There are a number of sites that publish benchmarking statistics, such as the International Software Benchmarking Standards Group (, which can be used in creating initial plans. If industry data is not available for a similar project, then it is still possible for experienced testers to give an estimate based on the expected size of the final product. Once the project is finished, continued measurement can be used to help in test planning for future projects, as well as to determine if the project met expectations.

Measuring Quality

Another good measure used in testing, and an indicator of both testing effectiveness and software quality, is defect densityi, defined as:

Total number of defects / Total function points

Defect density can also be compared to industry data or projects previously created to determine if the software meets standards. It does so in a neutral fashion, unlike some measures, such as cost per defect, which can penalize efforts at software qualityii. Ultimately, testing should be part of the process of improving quality, and measuring its effects on defect density is one way to track changes in quality.

Maintenance and Process Improvement

Once the software development project is finished, there is still the process of maintaining it. Even during this time, software may require re-engineering at some point. The choice to re-engineer, like most business decisions, should be made at a point when it is likely to be most cost effective. Function points can be used in this decision as well. The amount of maintenance an application requires per function point can give an idea of when re-engineering should take place: the longer spent on an application that provides a given amount of benefit (measured by function points), the more likely that it needs to be re-workediii. This should be based on company standards or industry standards, as appropriate for the project.

Measures are also necessary for the continuous improvement of processes. While the data may not be available at the beginning of the measurement process, perhaps because industry data including a similar project does not exist, as data is collected and analyzed it can be used to improve future projects. This data collection is a requirement of certain testing models, such as the Testing Maturity Model integration (TMMi)iv. Level Four of the TMMi model, Measured, requires test measurement, so function points and the analysis that can be based on them are one way to fulfill that need.


Software testing can be a challenge to track in a rigorous fashion. It does not itself create easily seen benefits, but instead usually prevents issues down the line. By combining function point sizings and other information, the very real benefits of testing can be more easily seen, analyzed and compared with other projects. This makes the sizing potentially valuable, allowing testing to be planned earlier in the process, giving a measure of effectiveness and allowing maintenance planning. By making the test process measurable, function points can facilitate process improvement, such as in the TMMi model. Perhaps most importantly, function points can be used to demonstrate the importance of testing to non-testers, which often includes managers. That, by itself, may be a sufficient reason to use them.

Further Reading


i Function Point Analysis, David Garmus and David Herron, pages37-39

ii Function Points as a Universal Software Metric, CapersJones

iii. Using Function Points,

iv Test Maturity Model integration, Erik van Veenendaal and BrianWells


Written by Default at 11:56

Can Function Points Be Used to Estimate Code Complexity?

Software code can get really complex and we all agree that complex code is harder to maintain and enhance.  This leads to lower business value for the application as the inevitable changes required for the application to keep pace with a changing environment cost more and more to implement for a given function size. Can function points be used to estimate code

Consequently, I was a little surprised to see the title, “Cozying up to Complexity,” at the head of a book review by Robert W. Lucky in the January 2017 edition of the IEEE Spectrum.  Lucky reviewed the new book by Samuel Arbesman, “Overcomplicated.” Lucky identifies Arbesman’s three key drivers of increasing technological complexity: “accretion”, “interconnection”, and “edge cases”.  Accretion is the result of the continual addition of functionality on top of and connecting existing systems.  Connecting ever more systems leads to interconnection complexity.  Edge cases are the rare but possible use cases or failure modes that have to be accounted for in the initial design or incorporated when they are discovered.  Over time, these edge cases add a lot of complexity that is not apparent from majority uses of the system.  Increased software complexity can be a problem for outsourcing software development because more complex code is more difficult to maintain and more difficult to enhance.  This becomes a problem for software vendor management as costs go up due to reduced vendor productivity.

There are measurements and metrics for software complexity but Lucky reports that Arbesman’s suggested solutions for complexity including the novel idea that we should not take a physicists mathematical view to try to build a model.  Instead, we should take a biologists view: record the complexity we find (e.g. in nature) and look for patterns that might repeat elsewhere.  Arbesman does not necessarily see increased complexity as a bad thing.

If we accept that some level of complexity is a good and necessary thing to achieve the “magic” of current and future software capabilities, I wonder if there is a way to identify the point of maximum useful complexity?  Perhaps “useful complexity” could be measured in function points per line of code?  Too much complexity would be indicated by a low “useful complexity” value – trying to shoehorn too much functionality into too few lines of code.  At the other end of the spectrum – what Arbesman might refer to as his edge cases – we might see too little functionality being delivered by too many lines of code.

My train of thought was as follows:

  • A program with zero functionality (and zero function points) may have complexity but I’m going to exclude it.
  • A program with 1 function point must have some lines of code and some small complexity.
  • For a program with a reasonable number of function points, I (as a former ‘C’ programmer) could make the program more complex by reducing the number of lines of code.
  • Adding lines of code could make the program less complex and easier to maintain or enhance by spreading out the functionality (and adding explanatory comments although these don’t usually count as lines of code) up to a certain point, after which diminishing returns would apply.  The question is where is that point.
  • It must also be true that there must be a certain complexity inherent in coding a certain number of function points.  This implies a lower limit for the complexity given a fixed number of function points.
  • This suggests that, for a given number of function points, there might be a non-linear inverse relationship between complexity and lines of code.

I’d welcome people’s ideas on this topic.  Thoughts?

Written by Michael D. Harris at 10:03

Algorithms: What are They Worth and What Might They Cost You?

Every so often, I read an article that gets me thinking in a different way about software value and software risk.  Danilo Doneda of Rio de Janeiro State University and Virgilio Almeida of Harvard University recently published an article entitled, “What is Algorithm Governance?[1]

Doneda and Almeida suggest that the time may have come to apply governance to algorithms because of the growing risks of intentional or unintentional, “… manipulation, biases, censorship, social discrimination, violations of privacy and property rights and more,” through the dynamic application of a relatively static algorithm to a relatively dynamic data set.  

By way of example, we have probably all experienced the unintended consequences of the application of a reasonably well understood algorithm to new data.  We all have a basic grasp of what the Google search algorithm will do for us but some of you might have experienced embarrassment like mine when I typed in a perfectly innocent search term without thinking through the possible alternative meanings of that set of words (No, I’m not going to share).  At the other end of the spectrum from the risk of relatively harmless misunderstandings, there is a risk that algorithms can be intentionally manipulative – the VW emission control algorithm that directed different behavior when it detected a test environment is a good example. 

For those of us who deal with outsourcing software development, it is impossible to test every delivered algorithm against every possible set of data and then validate the outcomes. Algorithm Governance, Software risk management consulting by DCG Software Value

If we consider software value, from a governance perspective, it should be desirable to understand how many algorithms we own and what they are worth.  Clearly, the Google search algorithm is worth more than my company.  But, are there any algorithms in your company’s software that represent trade secrets or even simple competitive differentiators?  Which are the most valuable? How could their value be improved?  Are they software assets that should be inventoried and managed?  Are they software assets that could be sold or licensed?  If data can gather and sell data then why not algorithms?

From a software metrics perspective, it should be easy to identify and count the algorithms in a piece of software.  Indeed, function point analysis might be a starting point using its rules for counting unique transactions, each of which presumably involves one or more algorithms, though it would be necessary to identify those algorithms that are used by many unique transactions (perhaps as a measure of the value of the algorithm?).  Another possible perspective on the value of the algorithm might be on the nature of the data it processes.  Again, function points might offer a starting point here but Doneda and Almeida offer a slightly different perspective.  They mention three characteristics of the data that feeds “Big Data” algorithms, “… the 3 V’s: volume (more data are available), variety (from a wider number of sources), and velocity (at an increasing pace, even in real time).  It seems to me that these characteristics could be used to form a parametric estimate of the risk and value associated with each algorithm. 

It is interesting to me that these potential software metrics appear to scale similarly for software value and software risk.  That is, algorithms that are used more often are more valuable yet carry with them more risk.  The same applies to algorithms that are potentially exposed to more data. 

[1] Doneda, Danilo & Almeida, Virgilio A.F. “What is Algorithm Governance.” IEEE Computer Edge. December 2016.


Mike Harris, CEO

Written by Michael D. Harris at 15:07

Function Points and Agile

I participated in an interesting conversation on Function Points and Agile with members of the software development group at a federal agency recently.  We, the DCG team, were explaining how we would start the process of measuring how much value they are delivering from software development by measuring how much functionality they are delivering in function points.  For an organization with immature metrics and, perhaps, lack of user trust, this starting point takes the question of productivity off of the table to allow us to move on to end user value delivery

All of the participants in the meeting quickly recognized the value of having a standard metric, function points, to measure the size of the functionality being delivered (and with SNAP – the non-functional size too) but I could see on their faces the sort of trusting disbelief that might be associated with my pulling a rabbit out of my bag.   Some of the participants in the meeting were not familiar with function points and asked for a quick, five minute explanation.  I get asked this a lot so here it is (before I get inundated with corrections – I know - this is an over-simplification):

Imagine a software application and draw an imaginary boundary around it in your mind to include all its functionality but not the functionality of other applications that it communicates with or draws information from.  Now consider the diagram below.

Function Points and Agile

From a user perspective, looking at the application from outside the application boundary, I can interact with the application in three ways, called transaction functions: external inputs (EIs), external outputs (Eos) and external inquiries (same as input and output but with no change of data or state - EQs).  From within the application, I can access data in two places – inside the application boundary or outside the application boundary.  My interactions with these files are the two types of data functions: internal logical files (ILFs) where data is stored within the application boundary and external interface files (EIFs) where data is stored outside our application boundary. 

Most of you will be able to easily imagine that these five types of user interaction with our application can be more or less complex.  If I want to produce a function point count, the next step is to consider the first of the transactions that the user wishes to perform on the application (as defined in the requirements, user stories or whatever) and to identify how many of each of the five function types is involved in the transaction and how complex that involvement is (low, average or high).  Predetermined rules govern the weights that apply to each function type based on the complexity of the function in this transaction.  With all this information gathered, we can calculate the number of function points using the simple table shown below.

Function Point Counting Weights









__ x 3 +

__ x 4 +

__ x 6 =




__ x 4 +

__ x 5 +

__ x 7 =




__ x 3 +

__ x 4 +

__ x 6 =




__ x 7 +

__ x10 +

__ x15 =




__ x 5 +

__ x 7 +

__ x10 =









One of the participants offered a very perceptive observation, “Isn’t this a lot of work for every user story in Agile?”  It could be.  In practice though, by the time a user story is defined and understood, the software problem has been decomposed to the point where identifying the FPA functions and complexities is fairly simple.  That said, we don’t recommend this for all agile team members.  Story points work fine for most agile teams.  Where function points (and SNAP) can and must be used for Agile is where there is a need to aggregate the delivered functionality (and non-functional elements) into higher level metrics  for reporting to management.  This level of function point analysis is often better done by a separate, central team rather than the agile team members themselves.


Written by Michael D. Harris at 15:17
Categories :

Function Points in the Philippines?

David LambertI know what you are thinking – and I was thinking the same thing. Is there really a company using function points in the Philippines? Yes, there is. In fact, I recently traveled to the Philippines to train a lean development team on the use of function points as a measure for their metrics program.

I’d never been to the Philippines before, so it was an interesting experience to be in a new place, but it was also interesting to see how function points are being used around the world.

This particular team is way above the curve as far as their processes and documentation is concerned. They were looking for a standardized process to size their change requests in order to measure productivity and quality and help forecast future projects. Their intent is to start sizing those small change requests and establish some benchmarks for their applications. Once those benchmarks are in place and they have gathered some valuable data, the team intends to start using the data to help size their larger projects. The sizing for those projects will allow them to better manage staffing, cost, and quality related to those projects.

This, of course, is something we encourage and espouse as a best practice for development teams. So, it was great to see that this mentality has really taken hold in this organization, and that they truly understand the benefits of sizing.

I also learned while I was there that several larger technology companies are starting to use the Philippines as a source to locate their infrastructure and development teams. So you may not think of the Philippines when it comes to the IT domain, but the country is starting to make some strides towards closing the gap on the rest of IT world. I know for sure that one lean development team has closed the gap and function points have allowed them to standardize their process even further.

I look forward to seeing how the use of function points continues to develop in the country – and beyond. Is your organization using function points? If not, it’s time to catch up!


David Lambert
Managing Consultant

Written by David Lambert at 05:00

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!