Are Function Points Still Relevant?

Let's start with a quick overview of Function Point Analysis:

Function Point Analysis is a technique for measuring the functionality that is meaningful to a user, independent of technology.  It was invented by Allan Albrecht of IBM in 1979. Several standards exist in the industry, but the International Function Point Users Group (IFPUG) is the most widely used.  IFPUG produces the Function Point Counting Practices Manual, used by Certified Function Point Specialists (CFPS) to conduct function point counts.  IFPUG is one of the ISO standards for software sizing (ISO/IEC 28926:2009). 

Function Point Analysis considers five major components of an application or project: External Inputs, External Outputs, External Inquiries, Internal Logical Files and External Interface Files. The analyst evaluates the functional complexity of each component and assigns an unadjusted function point value. The analyst can also analyze the application against 14 general system characteristics to further refine the sizing and determine a final adjusted function point count.

Function Point Analysis

“The effective use of function points centers around three primary functions: estimation, benchmarking and identifying service-level measures.” [i] 

More and more organizations are adopting some form of Agile framework for application development and enhancement.  The most recent VisionOne State of Agile Survey reveals that 94% of organizations practice Agile.[ii]   Hot technologies such as big data, analytics, cloud computing, portlets and APIs are becoming ever more popular in the industry.

Let’s explore each of the three primary functions of function points and their relevance in today’s Agile dominated IT world and with new technologies.

Estimation:

Whether it is a move from traditional waterfall to Agile or from mainstream technologies to new innovations, project teams still have a responsibility to the business to deliver on time and within budget.  Estimates of the overall project spend and duration are critical for financial and business planning.

Parametric estimation is the use of statistical models, along with parameters that describe a project to derive cost and duration estimates.  These models use historical data to make predictions.  The key parameters necessary to describe a project are size, complexity and team experience.   Many other parameters can be used to further calibrate the estimate and increase its accuracy, including whether the project is using an Agile framework.  Several tools can be used to perform parametric estimation, including SEER, SLIM and COCOMO. 

Project size can be described in several ways, with software lines of code (SLOC) and function points being the most common.  SLOC has some inherent problems, one being that inefficient coding produces more lines of code, another being the fact that determining the SLOC size of a project before it is coded is itself an estimate.  That’s where function point analysis provides real value as a sizing tool.  Even in software developed using the latest innovations in technology, the five components of function point analysis still exist so function point counting remains a valuable tool for measuring software size.  Because a function point count can be done based on a requirements document or user stories, and the expected variance in function point counts between two certified function point analysts is between 5% and 10%, an accurate and consistent measure of the project size can be derived.  And because function point analysis is based on the users view and independent of technology it works just as well as technology evolves.

The function point size, along with the other parameters described above are then used by the parametric estimation tool to provide a range of cost and duration estimates for the entire project within a cone of uncertainty.  This information can be used for financial budgeting and business planning.  

Projects in an Agile framework can create estimates for the individual user stories with techniques like planning poker, t-shirt size or relative mass valuation.  These estimates are used for sprint planning and are refined through the backlog grooming process.  As the team measures and refines its velocity the estimates are further updated.   Ultimately all of these estimates should converge on the overall projected estimate created using parametric estimation.

Regardless of the technologies used for development, in this way estimates of the overall project through parametric estimation and Agile estimation techniques can coexist and complement each other in support of the business’s need for financial and business planning.

Benchmarking:

Whatever technology or development framework is being used, constant improvement is essential to an organizations ability to survive and thrive in a competitive environment.  Baselining an organization’s performance relative to productivity, quality and timeliness is the starting point for benchmarking and the first step toward an IT organization’s delivery improvement. 

Function points are a common currency for metrics equations.  They provide a consistent measure of the functionality delivered, allowing benchmark comparison of performance over time, of one technology against another, internally across various departments or vendors, and externally against the industry in which a company competes.  Benchmarking is also used in outsourcing governance models as a way to ensure a vendor is providing value with respect to contractual commitments and competitors in the marketplace.

A large amount of function point based industry benchmark data is available from many suppliers.  Some of the suppliers include: The Gartner Group, Rubin Systems Inc. META Group, Software Productivity Research, International Software Benchmarking Standards Group (ISBSG) and DCG Software Value. 

To execute a benchmark, data is collected for the target projects, including function point size, effort and duration.  The data is analyzed and functional metrics are created and baselined for the target projects.  Quantitative comparison of these baselines is done against suitable industry benchmarks.  Qualitative assessment is done to further analyze the target projects and determine contributing factors to performance differences with the benchmark.

Regardless of the development framework or technology used, function points is the basis for baselining and benchmarking an organization to determine their performance relative to the industry and allowing for improvements to move toward best-in-class performance.

Service-Level Measures:

Service-level metrics are most commonly used in outsourcing governance to measure the performance of the outsourcer to ensure contract compliance.  With IT’s increased alignment with the business, service-level metrics are increasingly used internally as well.  Delivery framework and technology don’t change the need for this kind of oversight. 

Outsourcing is typically done at the individual project or application level, for application maintenance, or the entire ADM environment.  Let’s examine each of these outsourcing models and how function point based service-level metrics can be used to monitor them.

Individual project or application:

In the case of individual project or application outsourcing service-level definition is based on the provider’s responsibility, the standards required by the customer and how success is defined.  Function point analysis has a role in all three of these areas. 

Definition of the outsourcer’s responsibilities helps identify the hand-off points.  Function point sizing at requirements hand-off provides an initial baseline of the project size for all metrics to be built upon.  As requirements change throughout the project the baseline can be updated through change control. 

The standards and development practices lead to establishment of compliance measures and targets for the outsourcer to meet.  Function point sizing can be used here as the basis of measures like productivity.

Success can be measured with function point based measures of delivery rate, duration and quality against contractual requirements or internal standards.

Application maintenance:

Measurement of maintenance in an outsourcing includes customer expectations, response time, defect repair, portfolio size, application expertise and others.  Let’s explore those that involve function point analysis.

Customer expectations can be thought of as the size of the portfolio being maintained, as well as the cost of maintaining it.  The portfolio size can be measured with function points to establish the maintenance baseline and its growth over time can be monitored. 

Support efficiency can be measured as the size of the support staff needed to maintain the maintenance baseline.  This can also be measured over time to show trends.

Entire ADM environment:

The measurement needs for ADM outsourcing are different from those of the previous two scenarios.  A multi-year outsourcing requires more complex measures to ensure the services provided by the outsourcer meet contractual commitments.  To do this more complex metrics dashboards are often built to allow a wide range of measurements to be analyzed. 

To build a metrics dashboard that provides the level of monitoring required, many factors must be considered including contractual requirements, end customer expectations and organizational standards and goals. 

The table below describes metrics derived from performance considerations and business drivers. [iii]

Function Points

Many of these metrics are based on functional size so function point analysis can be used to build the measurements.

For outsourcing and internal IT, effective measurement is critical to monitor performance and improvements and should be linked to the organizations goals and objectives.  Metrics based on functional size are key to a service-level measurement program without regard to the delivery framework or technology used.

Conclusion:

We have seen above that function point analysis is versatile and adaptable with changing technology and processes.  All technologies still have the five basis components of function point analysis and organizations are still asking “when it will be done?”, “how much will it cost?” and “what will I get?”.  It is for these reasons that function point analysis remains relevant in today’s IT world.

References

  1. Garmus, D. Herron, D., Function Point Analysis, Measurement Practices for Successful Projects, Addison-Wesley, 2001
  2. IFPUG Metrics View, February 2016, International Function Point Users Group
  3. 9th Annual State of Agile Survey, VersionOne Inc., 2015
Written by Default at 05:00

Avoid the Expert Effect When Consulting

The “expert effect,” roughly, is the inability of someone who has achieved mastery of a subject to relate that concept to a non-expert. This is especially important to be aware of with consulting. As a Certified Function Point Specialist (CFPS), I spend a great deal of time working with Subject Matter Experts (SME) discussing function point counts for various software projects.

A lot of these discussions focus on the SME explaining how a particular piece of software functions. Of course, he or she knows everything about the software – I don’t, but I need to be as informed as possible in order to appropriately size it. Essentially there is a gap in my knowledge and I am dependent on the SME to fill it – which is not always easy (“Why can’t you understand what I’m talking about?!” is a commonly unexpressed, but felt, sentiment).

Keeping the expert effect in mind, there are a few things you can do to make it easier to collaborate with an a SME.

In discussions with a SME, always be mindful of the effort it took to become an expert. Every word of what seems like a “simple” explanation or question is back-loaded with hours, days, years of contextualized study and experience. Keep that in mind and be patient when relating concepts. Do not expect the SME to “get it” in the ‘”right” context (i.e. your context) immediately when sharing a concept or asking them a question. Losing patience is disrespectful to not only the SME, but also to your own efforts in becoming an expert!

Be aware that a SME can also have the tendency to be overconfident in the simplicity of an explanation. This is the other side of that coin. Sometimes when the consultant (me!) searches for clarity on a concept or asks for more detail, the SME will get annoyed because they feel it has already been explained simply. Find a polite way to point out that the reason for more questions is that there is still a knowledge gap to bridge for your own unique perspective. Of course, if it were so simple to know their system, they would not be the expert!

Working with an expert is obviously valuable – he or she knows the topic at hand to the fullest extent. But, distilling that knowledge into digestible pieces can be an exasperating challenge. Understanding that challenge is the first step to opening the door to communication – and a more efficient engagement.


Karl Jentzsch
Senior Analyst

 

Written by Karl Jentzsch at 05:00

The Mathematical Value of Function Points

"Anything you need to quantify can be measured in some way this is superior to not measuring it
all." – Gilb’s Law(1).

To assess the value of function points (any variety), it is important to step back and address
two questions.  The first is “What are function points (in a macro sense)” and secondly “Why do we measure?”

Function points are a measure of the functional size of software. What are IFPUG Function
Points? IFPUG Function Points (there are several non-IFPUG variants) are a measure of the functionality delivered by the project or application. The measure is generated by counting features and functions of the project or application based on a set of rules. In this case, the rules for counting IFPUG Function Points are documented in the IFPUG Counting Practices Manual. Using the published rules, the measure of IFPUG Function Points is a consistent and repeatable proxy for size. Consistency and repeatability increase the usefulness of estimating and measurement. An analogy for the function point size of a project is the number of square feet of a house when building or renovating. Knowing the number of square feet provides one view of the house, but not the other attributes, such as the number of bedrooms. A project function point count is a measure of the function size a project while an application count is a measure of the functional size of the application. 

The question of why do we measure is more esoteric. The stated reasons for measuring often
include:

  • To measure performance,
  • To ensure our processes are efficient,
  • To provide input for managing,
  • To estimate,
  • To pass a CMMI appraisal,
  • To control specific behaviour, and
  • To predict the future.

Douglas Hubbard (2) summarizes the myriad reasons for measuring into three basic categories.  
1. Measure to satisfy a curiosity.
2. Measure to collect data that has external economic value (selling of data).
3.Measure in order to make a decision.

The final reason, to make a decision, is the crux of why measurement has value in most organizations. The decision is the driver to the value of counting function points. The requirements for making a decision are uncertainty (lack of complete knowledge), risk (a consequence of making the wrong decision) and a decision maker (someone to make the decision).  

The attribute of uncertainty is the direct reflection that there exists more than one possible outcome for a decision. Represent the measurement of uncertainty as a set of probabilities assigned to the possible outcomes. For example, there are two possibilities for the weather tomorrow, precipitation or no precipitation. The measurement of uncertainty might be expressed as a 60% chance of rain (from the statement we can infer a 40% chance of no rain). Define risk as the uncertainty that a loss or some other “bad thing” will occur.  In this case, the risk might be that we intend to go picnic if it does not rain and must spend $30 for food the day before that will perish if we can't go on the picnic.  
Measurement of risk is the quantification of the set of possibilities that combines the probability of occurrence with the quantified impact of an outcome.  We would express the risk as a 60% chance of rain tomorrow with a potential loss of $30 for the picnic lunch that won't be eaten. In simplest terms, we measure so we can reduce the risk of a negative outcome. In our picnic example, a measure would have value if it allows us to reduce the chance that we spend $30 for a picnic on a rainy day.

A simple framework hybridized from Hubbard’s How to Measure Anything or determining the value of counting function points to support decision making is:

  • Define the decision.
  • Determine what you already know (it may be sufficient).
  • Determine if knowing functional size will reduce uncertainty.
  • Compute the value of knowing functional size (or other additional information).
  • Count the function points if they have economic value.
  • Make the decision!

The Process and an Example:

1. Define the decision.

Function points provide useful information when making some types of decisions. Knowing the size of the software delivered or maintained would address the following questions:

  • How much effort will be required to deliver a set of functionality?
  • Given a potential staffing level, is a date or budget possible?
  • Given a required level of support, is staffing sufficient?

Summarizing the myriad uses of function points into four primary areas is useful for understanding where knowing size reduces uncertainty.

a) Estimation: Size is a partial predictor of effort or duration. Estimating projects is an important use of software size. Mathematically, the effort is a function of size, behaviour, and technical complexity. All parametric estimation tools, home-grown or commercial, require project size as one of the primary inputs. The simple parametric model that equates effort to size, behavior and complexity are an example of how knowing size reduces uncertainty.
b)Denominator: Size is a descriptor that is generally used to add interpretive information
to other attributes or as a tool to normalize other attributes. When used to normalize other measures or attributes, size is usually used as a denominator. Effort per function point is an example of using function points as the denominator. Using size as a denominator helps organizations make performance comparisons between projects of differing sizes. For example, if two projects discovered ten defects after implementation, which had better quality? The size of the delivered functionality would have to be factored into the discussion of quality.  
c) Reporting: Collect the measures needed to paint a picture of project performance,
progress or success. Leverage measurement data for Organizational report cards and performance comparisons. Use functional metrics as a denominator to synchronize many disparate measures to allow comparison and reporting.
d) Control: Understanding performance allows project managers, team leaders, and project team members to understand where they are in an overall project or piece of work and, therefore, take action to change the trajectory of the work. Knowledge allows the organization to control the flow of work in order to influence the delivery of functionality and value in a predictable and controlled manner.

2. Determine what you already know (it may be enough).

Based on the decision needs, the organization may have sufficient information to reduce
uncertainty and make the decision. For example, if a table update is made every month, takes 10 hours to build and test, then no additional information is needed to predict how much effort is needed to make the change next month. However, when asked to predict a release of a fixed but un-sized backlog, collect more data.

3. Determine if knowing functional size will reduce uncertainty.

Not all software development decisions will be improved by counting function points (at
least in their purest form). Function point counting for work that is technical in nature (hardware and platform related), non-functional in nature (changing the color of a screen) or an effort to correct defects rarely provides significant economic value.

4. Compute the value of knowing the functional size (or other additional information).

One approach to determining whether measurement will provide economic value is to calculate the expected opportunity loss. As a simple example assume a high profile $10M project, estimated to have a 50% chance of being on a budget (or below) and a 50% probability of being 20% over budget.  
In table form:

Mathematical Value of Function Points

The expected opportunity loss is $1M (50% * 2M, very similar to the concept of Weighted Shortest Job First used in SAFe®). In this simple example, if we had perfect information we could make a decision to avoid a $2M over budget scenario.  The expected value of perfect information is $2M. If counting function points and modeling the estimate improves the probability of meeting the budget to 75% then the expected opportunity loss is $500K (a 50% reduction).

5. Count the function points if there is economic value.

Assuming that the cost of the function point count and the estimate is less than the improvement in the opportunity loss, there is value to counting function points.  The same basic thought process is valid to determine whether to make any measure.

6. Make the decision!

Using the reduction of uncertainty make the decision. For example, if the function point count and estimate based on that count reduce our uncertainty that we can meet the estimate by 50% we would be more apt to decide to do the project and to worry less about the potential ramifications to our career. 

Conclusion

While the scenario used to illustrate the process is simple, the basic process can be used to evaluate the value of any measurement process. The difference in the expected gain and the expected value or the percentage not spent on measurement is the value of the function point count. Modeling techniques
such as Monte Carlo Analysis and calibrated estimates are useful to address more robust scenarios in addition to the use of historical data. Counting function points reduces the amount of uncertainty so that we can make better decisions. If this simple statement is true, we can measure the economic value of counting function points.

Sources

1. Demarco, Tom and Lister, Tim. Peopleware: Productive Projects and Teams (3rd Edition). 2013.
2. Hubbard, Douglas. How to Measure Anything. (Third Edition). 2014. Wiley. 

Download

The report can downloaded here.

Written by Default at 05:00

Software Vendor Savings

Tony MannoDo you engage with software vendors to do your development? If so, then you know the drill. You provide your vendors with detailed requirements and they come back with a price for the project. But how do you really know whether you’re paying a fair price, and what’s your basis for negotiation?

If you could quantify the unit value created by the project, and know the fair market rate for those units, then you would know what you should pay for the project. You would be in a strong position to negotiate a fair price with your vendor.

Function Point Analysis can provide that information. It is a technique for measuring the functionality that is meaningful to a user, independent of technology. Function Point Analysis is governed by IFPUG, which produces the Function Point Counting Practices Manual. This manual is used by all IFPUG-certified Function Point Analysts to conduct function point counts. IFPUG is an ISO standard for software measurement.

Industry standard rates for the development of function points are available. Armed with the function point count for the project, along with the market rate, you’re ready for a win-win negotiation with your vendor.

Additional Resources:

Looking for more information? Check out these publications:

  1. An introduction to Function Point Analysis, including what it is and who would benefit from it. Download.
  2. DCG’s Function Point Analysis services. Download.
  3. DCG’s Software Vendor Savings offering. Learn more.

 If you need more information on how to use Function Point Analysis for evaluation and negotiation of vendor pricing, or if you have general questions about function points, don’t hesitate to reach out! I’m always up for a discussion!

 

Anthony Manno, III
Vice President, Outsourced Services

t.manno@softwarevalue.com

 

Written by Tony Manno at 05:00

Function Point Q&A

DCG Software Value is a long-time provider of software sizing services. We firmly believe that accurately sizing software is a critical aspect of managing and controlling successful software project delivery. Several sizing methodologies are available, but most often we employ the use of IFPUG function points (from the International Function Point Users Group), which measures functional requirements. This technique is known as Function Point Analysis.

Although this technique is widely and effectively used, we often get a number of questions about it. This blog post attempts to answer some of the most common questions we receive, but if you have others, please leave a comment below and we’ll address it!

What is Function Point Analysis?

Function Point Analysis is a technique for measuring the functionality that is meaningful to a user, independent of technology. Function Point Analysis is governed by IFPUG, which produces the Function Point Counting Practices Manual. This manual is used by all IFPUG-certified Function Point Analysts to conduct function point counts. IFPUG is an ISO standard for software measurement.

Function Point Analysis considers five major components of an application or project: External Inputs, External Outputs, External Inquiries, Internal Logical Files and External Interface Files. The analyst evaluates the complexity of each component and assigns an unadjusted function point value. The analyst then analyzes the application against 14 general system characteristics to further refine the sizing and determine a final adjusted function point count.

Function Point Analysis

When Can Function Point Analysis Be Used?

  • Function Point Analysis can be used at the beginning of projects to derive cost and duration estimates using well defined, industry-proven models and software.
  • Function Point Analysis can be used at the end of the project. Metrics such as productivity, defect density and time-to-market can be created using function point counts. These metrics allow measurement for internal improvement initiatives, contract compliance and comparison to industry benchmarks.                

Can Function Point Analysis Be Used When Evaluating Commercial Off the Shelf (COTS) Software?

Function Point Analysis can be used with COTS software projects in several important ways. These include the following:

  1. Functional requirements analysis: Like for any project, once the functional requirements have been defined, a function point count can be done to quantify the size of the application or project. This sizing can then be used for selection of the COTS package or for build-or-buy decisions.
  2. COTS function analysis: A function point count can be done on a prospective COTS package and used for comparison to functional requirements during the evaluation and selection process.
  3. Gap analysis: Comparison of the functionality provided by the COTS package to the requirements yields the gaps that must be filled with custom applications or additional COTS software.
  4. Project estimation: Using function point counts as input to industry-leading estimation applications and models provides accurate estimates for COTS configuration, customization, custom development and testing. This includes estimates for development of COTS extensions and external interfaces. 

Additional Resources:

Looking for more on function points? Check out these publications:

  1. An introduction to Function Point Analysis, including what it is and who would benefit from it. Download.
  2. DCG’s Function Point Analysis services. Download.

If you need more information on enhancement productivity improvement opportunities, or you have questions about function points, don’t hesitate to reach out! I’m always up for a discussion!


Anthony Manno, III
Vice President, Outsourced Services

t.manno@softwarevalue.com

Written by Tony Manno at 05:00

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

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