Archived from
http://ourworld.compuserve.com/homepages/softcomp/fpfaq.htm, which
is sadly no longer available.
Frequently Asked Questions (and Answers) Regarding Function Point Analysis
Updated June 25, 1997
Copyright 1996-1997 by Software Composition Technologies, Inc.What are function points and why count them?
When can you count function points?
Who can count function points?
How do you count function points?
What do you do with the function point counts?
This document contains information regarding function point analysis. It is a compendium of questions that are often raised on-line or in a business environment, including the classroom. Variations on these questions often occur on the CompuServe CASE forum and the USENET comp.software-eng newsgroup. However, because there is no function point newsgroup, this FAQ is not the official FAQ to any newsgroup. The following questions relate to the way the FAQ is maintained:
This document will be updated on a quarterly basis. It may be updated sooner when people submit a lot of questions or answers. People who wish to be placed on a mailing list to be notified when updates occur should contact the editor.
For this first edition, all of the material originated with the editor. It is hoped that users of the document will begin to submit additional questions, and answers if possible. Elaboration on existing answers is also sought. Please do not submit copyrighted material unless you are the copyright owner and you are also giving permission for its inclusion. Like any publication, the editor may refuse to include any material that he feels is not of general interest or may edit material for style or space considerations.
The editor is Ray Boehm. He has been involved with function point analysis for about eight years and has been an IFPUG Certified Function Point Specialist (CFPS) for the past three. Ray spent the past most of that time working for a major systems integrator where he used function point analysis to monitor productivity and to estimate project effort. Currently, he is the Principal Consultant at Software Composition Technologies, a firm involved in function point training and consulting.
The preferred electronic mail address is rayboehm@cnj.digex.net.
Snail mail to:
Ray Boehm
Software Composition Technologies, Inc.
19 Homer Place
Metuchen, NJ 08840
USA
FAX: (732) 906-5728
Voice: (732) 906-3671
Absolutely not! As a CFPS, the editor "will not engage in any conduct or commit any act which is a discredit to the reputation or integrity of the CFPS Program, IFPUG, or the information system community." However, there is occasionally room for disagreement with mainstream IFPUG thinking. In these cases, the views are those of the editor or the individual credited with the opinion.
As would be expected, there are a number of minor changes and corrections throughout the document. In particular, thanks go to Sharon Hill for pointing out that my contact information was wrong in one place. (Talk about stealth marketing!) However, the major changes are enumerated below:
In the late seventies, IBM felt the need to develop a language independent approach to estimating software development effort. It tasked one of its employees, Allan Albrecht, with developing this approach. The result was the function point technique.
In the early eighties, the function point technique was refined and a counting manual was produced by IBM's GUIDE organization. The International Function Point Users Group (IFPUG) was founded in the late eighties. This organization produced its own Counting Practices Manual. In 1994, IFPUG produced Release 4.0 of its Counting Practices Manual. While the GUIDE publication and each release of the IFPUG publications contained refinements to the technique originally presented by Albrecht, they always claimed to be consistent with his original thinking. In truth, it is still very close considering the nearly two decades that have elapsed since Albrecht's original publication!
During the eighties and nineties, several people have suggested function point counting techniques intended to substantially extend or completely replace the work done by Albrecht. Some of these will be briefly discussed in this FAQ. However, unless otherwise specified, information in this FAQ is intended to be consistent with IFPUG Release 4.0.
Function points are a measure of the size of computer applications and the projects that build them. The size is measured from a functional, or user, point of view. It is independent of the computer language, development methodology, technology or capability of the project team used to develop the application. The fact that Albrecht originally used it to predict effort is simply a consequence of the fact that size is usually the primary driver of development effort. The function points measured size.
It is important to stress what function points do NOT measure. Function points are not a perfect measure of effort to develop an application or of its business value, although the size in function points is typically an important factor in measuring each. This is often illustrated with an analogy to the building trades. A three thousand square foot house is usually less expensive to build one that is six thousand square feet. However, many attributes like marble bathrooms and tile floors might actually make the smaller house more expensive. Other factors, like location and number of bedrooms, might also make the smaller house more valuable as a residence.
Bill Hufschmidt, a seasoned function point practitioner, always stresses that the first three letters in function points are FUN. People who enjoy function point counting and can justify it on that basis should do so. The following are more hard nosed reasons:
There are a number of frequently asked questions that are related to the more general question of "What are function points?" These questions and answers follow:
Yes. When the function point technique was originally developed, it was not applied to systems with Graphical User Interfaces (GUIs). There were no systems with GUIs! Even as late as three years ago, there was a certain amount of disagreement between function point practitioners regarding how to count these systems.
Two years ago, IFPUG completed Release 4.0 of their Function Point Counting Practices Manual. It contains the official rules for, and extensive examples of, counting GUI based systems. Subsequently, IFPUG produced a case study that contained the count of an entire GUI-based system.
Unfortunately, you can still find practitioners who are not familiar with the new rules and have not updated their course material to reflect current technology. Do not tolerate this! Just like any other professional you rely on, your function point specialist(s) should have knowledge that is up to date.
Yes. In the simplest case, the user may be unaware of whether she is using a program running on a central computer or a set of programs running on various computers across a network. In fact, in the wonderful world of client/server, your application can abend (reach an abnormal end) because of a failure on a computer that you did not even know existed! This presents a strong argument that client-server systems can be counted just like any other ones. Unfortunately, client/server does introduce some complications into the counting process.
Accounting for the development of a technical infrastructure is often a challenge. The technical infrastructure can be composed of database managers, middleware, APIs and other components that are used by the developers. Installing this infrastructure is often a completely separate project. Are there function points associated with this project? If so, is the count performed as if the application developers are the users of the infrastructure? Of course, it is possible that some of the business users of the enterprise will interact directly with this infrastructure when doing end-user application development. Will this change the answers to any of the preceding questions?
Even when confining our attention to the application programs, identifying the boundaries in client/server systems development projects can often be tricky. In the simple case, where an application is developed partially on a client and partially on a server, the boundary includes them both. However, many projects call for the development of server applications that will interact with other pre-existing clients and servers in addition to a client program that is being developed as part of the project. In this case, multiple boundaries may need to be considered.
Yes. You probably see the pattern here! The short answer is that they can be used to measure these applications and their size is the same as if object oriented development had not been used. This is because the function point count for an application is independent of the technology used to develop the application. However, the use of object orientation does tend to impact the function point count of the project that builds the application.
In the simplest case of software development, an application is built from scratch by a single project. In this case, the application and project function point counts are the same. For example, building a 1000 function point system would be a 1000 function point project. Object orientation is quickly making this simple approach to application building a thing of the past!
At a minimum, using object oriented development techniques allows the developer to use pre-built Windows editing controls and the like. When object orientation is fully embraced, developers can incorporate major chunks of functionality into their applications. For example, OLE Automation allows an application to completely harness the power of Microsoft Project version 4.0. Counting in these situations requires good engineering judgment and experience.
One school of thought has been simply to incorporate all of the functionality into the application and project counts. This makes sense for minor functionality that would not be separately recognized by the user anyway, like editing controls. However it is often a problem for more function rich components. If the user realizes that much of the functionality that is being provided has actually come from a purchased application, will he be willing to give the developer "credit" for all of that functionality? If the developer claims all of the functionality of both the custom written portions and the acquired portions of the project, will the function point technique still be usable for estimating?
It should be stressed that these considerations have been around longer than object oriented development. However, years ago these were the exceptional cases. Now, they are becoming the norm. The function point community still needs to codify its approach to handling these situations.
The International Function Point Users Group (IFPUG) has just published a case study showing the count for an application that was developed using object oriented techniques. It is Case Study number 3.
The number of lines of code is the traditional way of gauging application size. Some people claim it is still relevant because it measures what software developers actually do, that is, write lines of code. They will use lines of code either instead of or in addition to function points. Other practitioners say lines of code are irrelevant. Capers Jones has declared "the use of lines of code metrics for productivity and quality studies to be regarded as professional malpractice starting in 1995."
At best, counting lines of code measures software from the developers' point of view. Since function points are based on screens, reports and other external objects, this measure takes the users' view. In these days of outsourcing and other confusion regarding the role of IT in an organization, understanding the users' view is of critical importance!
Related to these different views is the phenomenon that you get what you measure. When the number of lines of code is your primary measure of productivity, you often get it by having developers use less powerful languages and ignore opportunities for reuse. When the number of function points is your primary measure of productivity, you tend to get increased production of functionality by the developers. Of course, it is the users' responsibility to evaluate whether this functionality is delivering increased business value.
There are other technical problems with the lines of code measure. IBM encouraged the development of function points because it was starting to see a heterogeneous development environment where BAL, COBOL and PL/I where being used. Now almost every shop is using a mixture of languages. Furthermore, most modern development projects use a host of languages. How do you compare a project that delivers a 100,000 line mixture of C++, SQL and Visual Basic to one that delivers 100,000 lines of COBOL?
In addition, there is no standard definition of what a line of code is. Do blank lines count? Do comments count? Are data declarations included? What happens if a statement extends over several lines? Organizations, like the Software Engineering Institute, have published some guidelines in an attempt to standardize counting, but no one organization has played the same role for lines of code that IFPUG has for function points.
For some time, function point practitioners recognized that some classes of applications did not profit from function point analysis as much as they hoped. These application classes included real-time process control, mathematical optimization and various embedded systems. In 1986, Software Productivity Research (SPR) developed feature points.
This technique considers the number of algorithms used in the application and slightly modifies some of the weights of the traditional function point constituents. It was designed in such a way that typical business applications, an area where function points have been applied successfully, would have the same size whether calculated with function points or feature points. The problem classes of applications mentioned above will typically have higher scores when measured feature points than with function points. This compensates for the fact that productivity usually appears to be lower for these applications. Of course, feature points are still considered to be experimental.
Feature points do not enjoy the same level of acceptance as function points do. There is no standards organization, like IFPUG, that concerns itself with its use. However one requirement of a standard is that it be available for people to study and use. Capers Jones has documented the technique in his Applied Software Measurement book. SPR makes a description of the technique available on its Web page in an article called "What Are Function Points?" It describes both function and feature points, and discusses how to choose the appropriate one to use for any given application.
Nolan, Norton & Co., part of KPMG Management Consulting, hired Charles Symons in 1984 to advise clients on methods to improve their systems development performance. In the course of doing this he claims to have discovered weaknesses in Albrecht's approach to function point analysis and developed the Mk II approach to overcome them. By 1987 it became a licensed product and is actively marketed.
Symons claims that the Albrecht approach suffers from the following weaknesses:
The principal conceptual difference between the two methods is the calculation of Information Processing Size, which corresponds to the Albrecht Unadjusted Function Points. Symons decomposes the application being counted into a collection of logical transactions. Each transaction consists of an input, a process and an output. For each transaction, Unadjusted Function Points (UFP) become a function of the number of input data element-types, entity-types referenced and output data element-types. The UFPs for the entire system are then summed.
Detractors of Symons' work say that Mk II is simply a way overstate the value of the monolithic systems that Nolan, Norton & Co.'s clients were building at the time. They consider it a political concession that will undermine the competitiveness of those clients in the long run. More moderate critics believe that Symons identified some function point issues that practitioners were already addressing. However, he chose to deal with them in a manner that would lead to a proprietary Nolan, Norton & Co. product, instead of strengthening the original Albrecht work.
Grant Rule supplied information on the current state of Mk II. He reported that the technique has been in the public domain since 1991. The design authority is the United Kingdom Function Point Users Group, 147 Knowsley Road, Norwich, Norfolk, NR3_4PT, United Kingdom; telephone/fax: +44-1603-219-263.
He went on to state that Mk II is widely used in the UK, and increasingly in places like India, Singapore, Hong Kong and Europe. Roughly 50% of the UFPUG membership use MK II. Users include many governmental organizations, finance, insurance, retail and manufacturing.
Between 1989 and 1992, the Boeing Company considered the use of function points to measure productivity. An internal Boeing Company document was published in the proceedings of the Pacific Northwest Software Quality Conference in 1992. It defined a technique called 3D function points.
The new technique was designed to address two classic problems associated with the Albrecht approach. First, the approach is considered difficult to use. Second, it does not properly measure scientific and real-time systems.
The three dimensions in 3D function points are data, function and control. The data dimension is similar to Albrecht's function points. The function dimension adds transformations, which are similar to the algorithms. The control dimension adds transitions, which enumerate changes in application state. It has been claimed 3D function points scale downward to the class level when used in conjunction with object oriented development.
It is debatable whether 3D function points are any easier to count than traditional function points. It is also debatable whether the technique addresses scientific work any better than feature points do. It is a fact that 3D function points are not widely used at this time.
Like voting, you should count early and often! The sooner you can quantify what a project is delivering, the sooner it is under control. Traditionally, many practitioners believed that function point counting could not occur until product design (or external design, another name for the same thing) was complete. IFPUG members have long realized the importance of being able to count function points earlier in the development life cycle. Under IFPUG 4.0, there are rules and guidelines that make it possible to count function points once the requirements have been finalized. Many practitioners use heuristics that allow them to estimate function point size even earlier in the life cycle. The paragraphs below discuss the function point estimating and counting that can occur at various points in the life cycle. Since everyone uses different live cycles, the stages will be described in terms of the project's progress on related deliverables.
If the life cycle begins with something like a feasibility study, it is usually impossible to count function points at this time. However, the number of function points can be estimated using the same techniques currently being used to estimate lines of code or effort. If a similar project was 2,000 function points, the best guess at this time is that this project is also 2,000 function points.
During requirements gathering the estimate of size in function points can be refined continuously. For many projects, a logical data model is developed. People's definitions of a logical data model vary, but at some point, this model is not attributed, nor is it in third normal form. However, at this point the analyst can start to identify which entities will need processes to add, change, delete and display them. If the equivalent of a Yourdon context diagram has been produced, then the interactions with users and external systems specified. At this point, a good estimate of function point size can be made assuming that the transactions identified are all of average complexity. Even at this point of the life cycle, it is usually possible to predict the Value Adjustment Factors with fair accuracy.
Once the business requirements have been completed it is possible to accurately count the function points for the application. At this point, the logical data model should be fully attributed. All of the system interactions, including screens and reports, should be identified and the data items associated with them specified. There is no need for the screens or reports to be formatted at this time.
As was already stated, following external design or product design it is possible to get an accurate function point count. Of course, you should have gotten an accurate count at the completion of requirements. This is the time to start considering requirements' volatility and its impact on the project. The simplest type of requirements' volatility is scope creep. If, at the end of requirements, you measured the project as 1,000 function points, and then, after product design, it measures 1,500 function points, you have at least a 50% scope creep.
Other forms of requirements' volatility can be more insidious. For example, you might measure 1,000 function points at the end of requirements and 1,000 function points at the end of project design. Unfortunately, most of these later function points are for functions that are completely different from the ones identified in the requirements. Some people refer to this as breakage. Whatever it is called, it needs to be tracked. The farther into the life cycle this occurs, the more expensive each such change becomes. However, since the function point size did not change, the impact of these changes is often ignored. These changes need to be tracked as enhancement function points. In this way their impact can be properly considered when the project needs to be re-estimated.
In theory, there should be no changes in function point count between the end of product design and the end of acceptance testing. Of course, in theory, there is no difference between theory and practice; in practice, there is a big difference! It is during this time of implementation and testing that changes become progressively more expensive to make. Very often, users and project managers horse-trade change requests, features, costs and schedules throughout this time. Function points can be used to quantify these negotiations. However, they must be used properly. It is not wise to exchange a 100 function point enhancement for a 100 function point reduction in functionality. The work already expended on the 100 function points to be dropped must also be considered. Again, using enhancement function points can make this process easier on all participants.
It makes sense to update the function point count at the end of the project. The project should be reviewed with the idea of making future project estimates more accurate. Application size is also a factor that determines the required level of support. The user community needs to decide whether the business value associated with an application is worth the effort that will be required to support it.
Anyone can count function points! All it takes is a one day class and a little on-the-job training by an experience counter and a person is on their way. Given this, should the counters be technical people or users (customers, clients or whatever the current politically correct term is for people that use these systems)? Is there any advantage to having a senior (more expensive) person count? Should everyone in the organization count function points or should it be a small group? Do you need a single function point guru? The answer is that there is no answer. Any of these scenarios can succeed, and all of them have failed in one organization or another. Some of the lessons learned from the successes and failures are presented below:
Technical people have long been the main function point counters. This made sense. Technical people often used the technique when called upon to generate estimates. Some more forward thinking technical managers used it to monitor the productivity of their departments. Truly forward thinking technologists used function points to allocate functionality when developing an application architecture or to make retain/retire/redesign decisions regarding the applications in their company's application portfolio. Technical people should continue to be function point counters!
Unfortunately, technical people have one major blind spot regarding function point counting. They know that function point counts should correlate to effort for the entire project. Therefore, they attempt to make each detail of the count correspond to the effort that they remember was, or predict will be, associated with that detail. For example, they remember that the help system took weeks to develop and will be uncomfortable with the fact that IFPUG 4.0 only allows eight function points (three for the low complexity EQ and five for the low complexity EIF) for the entire application's help capability. (16 if both field and screen level help exist.) Technical people should apply the counting rules correctly, and interested users must be ready to force them to when necessary.
The early GUIDE counting manual mentions that senior level users can also be trained to count function points. There is no doubt about that. Function point counting is much like accounting. An accountant must apply a body of rules, for example, from the Financial Accounting Standards Board (FASB), to measure the financial well being of their firms. These rules have some theoretical underpinnings, but are often the result of compromise and politicking by special interests. This sounds a lot like applying IFPUG rules to applications.
Why would users want to count function points? Developing complex systems has become a core competency of virtually every business. At the same time, certain outsourcing agreements have often placed system development in the hands of people who do not have a stake in the well being of the firm. Users must be ready to negotiate with these developers to insure that they are getting the required degree of functionality in their systems. This is an arrangement that can work well. The only problem is that the comparatively somber traditional function point counters are often intimidated by the relatively wild accounting types that they are now meeting.
Since anyone can be trained to count function points, the natural question is whether to assign a senior person to do it. The answer is usually yes. First, a senior person usually knows the questions to ask in order to make sure that major chunks of functionality do not go uncounted. In addition, other information usually becomes apparent during the counting exercise that a less experienced person may overlook. After counting, a senior technical person will often walk away with a good idea of whether the project is really proceeding as planned. A senior level user will recognize not only that the current number of function points is being developed, but will also know if the right functions are among them.
There are three possible ways to assign function point counting responsibility: to everyone, to a small group or to a single person. All project personnel should be familiar with function points so that they understand how they are being applied, but most of them will not be able to count them accurately. They count them too infrequently. They do a count, work on development for six months or more, and then are expected to count again. They have forgotten the rules by then. Constant retraining is the only way to get accurate counts from everyone, and this is often not cost effective.
For a large organization, a small group involved with function point counting and other estimating activity is ideal. The group should be counting frequently enough to stay current with the rules. By being independent of the projects, they will be able to provide less biased feedback regarding the projects. As a group, they will be able to look to one another for assistance with difficult counting situations and thus keep their counts consistent.
There are strong advantages and disadvantages associated with tasking a single person to be the function point guru for the organization. If the workload is light, allocating one person has the same advantage as allocating a group in a larger organization. However, the function point guru needs someone to bounce off different interpretations of counting rules. Membership in and attendance at IFPUG conferences should be considered mandatory in this situation. A relationship with one of the industry consultants is probably a must. In fact, regardless of how counting is handled in an organization, a relationship with one of these consultants can add considerable value by exposing people to different industry views.
Outsourcing of function point counting has all of the advantages associated with other forms of outsourcing. These include access to expertise and the freeing of resources. In addition, there are special attributes of the function point counting role that make outsourcing attractive. These involve issues of credibility, consistency and independence.
Loss of expertise and cost are two of the traditional disadvantages of outsourcing. Without proper planning, the result can be more insidious in this case. The ability to count function points may not be critical to an organization, but the ability to understand the counts is.
Release 4.0 of the IFPUG Function Point Counting Practices Manual is about 200 pages long. Many people feel that it does not adequately explain the function point counting process. Obviously, the six page magazine articles or summaries in more general textbooks do not accomplish this either. Some of these summaries do the disservice of making people believe they are ready to use the technique long before they can actually use it properly. This FAQ will not do that. At this time, no summary of rules or counting methods will be presented. The counting process will be presented so that people will understand what a count entails. To actually perform a count, or even get insight into the nature of function points and function point counting, requires training.
The first step is to get classroom training. There is only one modern textbook that attempts to addresses function point counting, and reviews of that book have been somewhat mixed. The most recent IFPUG Counting Practices Manual is an excellent reference, but does an inadequate job of explaining the basics. Many consultants offer a one day course that will get people headed in the right direction. IFPUG conferences usually run twice a year on a Wednesday through Friday. One day training courses are usually available on the Monday and Tuesday of that week. Having people attend the class and conference can be a very worthwhile training experience.
Simply attending the class will give managers and project personnel sufficient insight into function points in order to do their jobs. However, for the people who will actually be performing counts, classroom training is not enough. They must go through an application count with an experienced counter to actually get the feeling of how it is done. They also need an experienced counter to consult with when new counting situations present themselves and they feel the need for a consultation.
There are a number of frequently asked questions that are related to the more general question of "How do you count function points?" These questions and answers follow:
When IFPUG started to release Counting Practice Manuals, they introduced the idea of a second way to count function points. The first way was the traditional Albrecht approach based on the analysis of transactions. The second way was to be based on a data modeling approach. IFPUG always indicated that this approach would be specified in later releases of their manuals.
IFPUG has always recognized there are two key requirements to keeping the function point measure effective. The first is that function points had to be measurable early in the development life cycle. It is not possible to Postpone the count until after external design. The second requirement was to make function points something that could be measured automatically. At the very least, it was hoped that an ICASE tool might be able to display the function point count for systems being specified in it.
IFPUG kept its promise of delivering method two with release 4.0 of its Counting Practices Manual, kind of. Instead of being strictly driven by a data model, it called for the identification of elementary processes. These elementary processes are really only logical transactions. Of course, this presentation does drive home the point that function point counting is possible prior to external design. Unfortunately, IFPUG added to the general confusion by merging this method with the traditional method one and removing any references to the two methods.
The current IFPUG manual is organized in such a way that chapters two through eight correspond to the steps necessary to perform a function point count. The following steps will give an equivalent count, but stress some practical considerations. Deviations from the IFPUG presentation are explained.
Plan the Count. This step includes two IFPUG steps: determine the type of count, and identify counting boundary. It also includes critical logistics around the identification and assignment of a system expert.
Currently, IFPUG identifies three types of counts: development project counts, enhancement project counts and application counts. They are related. The development project count also yields the first application count for an application. In any event, identifying the type of count you are being asked to perform is usually not too complicated.
This is something most people do not want to discuss. IBM expects someone to be able to count 100 function points per hour. Most function point consultants feel that this is much too low. Some consultants claim to count as many as 4,000 per day. However, the 100 function points per day counting rate may be right if it includes the preparation and possible presentation of a complete project review.
There are usually some tasks in a count that take a fixed amount of time, independent of the size of the count. For this reason, some consultants feel that most applications can be counted in one day. Some use the same logic and indicate that an application can be completed in one half day.
Capers Jones has done a good deal of research regarding the expressive power of computer languages. He sometimes refers to this as language level. In particular, he has produced tables that indicate how many statements of code it takes to implement a function point. Obviously, this figure varies by computer language.
It should be noted that there is a minor religious war regarding the difference between number of code statements and number of lines of code. Jones' tables are based on number of statements. This was done minimize the impact of different coding styles. For example, some programmers write several statements on one line, while others will break a statement into several lines. Unfortunately, using statements raises the following problems:
These reasons have made it attractive for many practitioners to ignore the difference between statements and lines of code. That is the position taken in the remainder of this document. Given some of the other problems inherent in both backfiring and estimating, this may be the smallest source of error.
In any event, by applying the Jones' tables, it should be possible to guess how many function points are implemented based on the number of lines of code. For example, if you had an application consisting of 91,000 line COBOL program, these tables would lead you to believe that you had a 1,000 function point system. This is the backfiring technique. Many people use it to get a rough size measure for a portfolio of applications.
Backfiring is not without its problems. First, for many there is a wide range of implementation styles that can change the lines of code to function points ratio significantly. Second, this approach makes a product design that is implemented with excessive amounts of code look like a functionally rich product. Third, it will hide situations where the extent of the application's product design exceeded the user's requirements.
As was explained in a previous question, IFPUG identifies three types of counts: development project counts, enhancement project counts and application counts. The first and last are basically the same. A development project of 1,000 function will result in an application that has an application count of 1,000 function points. However, subjecting that application to an enhancement project of 500 function point may result in an application that is sized at anywhere from 500 to 1,500 function points.
New, changed and deleted functionality is all added together when counting for enhancement projects. There are just as many enhancement function points involved in deleting an application as there were development function points involved in building it! All this means that enhancement function points must be considered on a different scale than development or application function points.
It may be because of the above stated that the enhancement counting process is often under-explained in many function point courses. This is a mistake! Building systems in multiple releases is fast becoming the rule, rather than the exception. Software development approaches such as application composition, component-based development and most object oriented development approaches do not develop applications from scratch. They begin with a collection of components, or objects, and evolve them into an application. Enhancement project counting may be the best way to measure these undertakings.
It makes sense that some type of software support should be possible and available to count function points. The answer to this question will concentrate more on types of software than specific pieces of software. The specific packages are listed under What Resources Are Available.
IFPUG recognizes the existence of three types of software to support the counting process. In this discussion, the same breakdown will be used. Each type will be discussed in turn.
This software simply provides an automated repository for counting information and the ability to perform calculations. Type 1 software does for function point counting what Quicken does for personal financial management. It should make it easy for the counter to capture information and calculate results, just like Quicken provides a repository for financial information and has preprogrammed reports that are of use to Quicken users.
Type 1 software must be used by a qualified function point counter. It does nothing to apply the rules of counting function points to the problem at hand. Again this is just like Quicken. Quicken allows you to split your mortgage payment into principle, interest and escrow portions, but it does not perform the breakup for the user.
While IFPUG recognizes three types of software, certification criteria exists only for type 1 software. There is at least one program that has been certified as a type 1 program. Many consulting firms have programs of this type.
This software does everything that the type 1 software does. In addition, it helps the counter to properly interpret function point counting rules and to perform the count. Computer Associates did market, and perhaps still markets, a program that claimed to be of this type called FPExpert. How close this product came to being of type 2 is open to debate.
The best way to visualize what a type 2 program might look like is to consider another Intuit program. Their tax programs, either Mac-In-Tax or TurboTax, provide a good example. The software has an interview mode which asks tax related questions. Based on the responses, the tax forms are filled out.
The function point counting world needs programs like this. Many project personnel only count function points once a year or so. Even if they have been exposed to function point analysis, they need to be walked through the count. Even more experienced counters might benefit from the increased consistency that software like this would encourage.
This software does a completely automatic count. It is driven by either the specifications from a CASE tool or from the source code of a system. It is where IFPUG wants counting to go. Unfortunately, there are major theoretical and practical problems with this type of software.
Some of the CASE tool vendors are including function point counts in their software. The ADW package is an example. Unfortunately, the accuracy of these packages have been a big problem. The problem stems from the fact that function points are not a byproduct of normal software development. For example, most case tools require a logical data model to be developed. There is usually a tendency, if not a requirement, to prepare this data model in third normal form. CASE tools then treat each of the relational tables as an ILF. Unfortunately, this inflates the count. Many of these tables combine to form an a single ILF with several RETs.
The situation is even worse with source code analysis. Note that this is not backfiring. With type 3 function point software, the program is automatically expected for inputs, outputs, files. Unfortunately, it is impossible for a program to distinguish between transactions that are required to meet business needs versus those that are there for technological reasons. The former count should count as functional transactions, while the latter should not. Viasoft attempted to bring this type of tool to market, but many users are reporting up to a 400% error in the counts.
This question should be asked and answered long before the first function point is counted. Here are a few of the traditional answers:
The two productivity metrics that get the most attention are function points implemented per staff month and function points implemented per calendar month. When measuring software maintenance activities, enhancement function points can be substituted into these same metrics. The number of function points supported per staff member is also commonly tracked.
Function points implemented per staff month indicates the amount of effort that goes into system development. A 500 function point application developed by 10 people in 10 months had a productivity rate of 5 function points per staff month. There are often questions regarding what people to count. If users participate in the building process, then does their time count? When calculated for an entire IS department, do executive and administrative personnel count?
Function points implemented per calendar month indicates the speed with which systems can be developed. This quantity can not be increased endlessly simply by adding staff. Software development suffers from the law of diminishing returns. Eventually adding staff will have no positive impact on schedule. Organizations that can organize large development teams for rapid system delivery have accomplished something. In the example above, 50 function points were developed per calendar month.
As was stated earlier, enhancement function points implemented per staff and calendar month can be calculated in maintenance environments. This is not usually done. Most maintenance managers are more concerned with ensuring proper staffing to support their application portfolios. Therefore, the size of the application portfolio in function points divided by the number of full time equivalents performing maintenance is often calculated. Here, the traditional problem occurs. Who is counted as being part of the maintenance staff? Many organizations also track the total number of enhancement function points completed in a year. Sometimes this number is divided by the size of the maintenance staff to yield enhancement function points delivered per staff year.
There are basically two methods to transform function point counts into development estimates. The first is to assume a certain level of productivity in function points per person and calendar month. The second is to convert the function point count into an equivalent number of lines of code and use a macro estimating model like COCOMO. This latter method allows a variety of other factors, in addition to function points, to be considered in the estimate. Some of these factors are considered in the next question.
Capers Jones has done work that is applicable to both approaches. His book Applied Software Measurement gives average productivity rates for commercial, MIS and military applications. The International Function Point Users Group and some of its international affiliates are beginning to collect benchmark information of this type.
In the same book, Jones gives tables that indicate how many statements of code are necessary to implement a function point in several different languages. As was discussed under "What is Backfiring?," many practitioners make the assumption that statements and lines of code are roughly equivalent. Then, the result can be entered into any macro model, including one of the public domain COCOMO implementations. A commercial product, Before You Leap, provides this in a single integrated product. More information regarding software packages can be found under What resources are available?
Even proponents of the first approach will usually admit that a large database of similar projects is necessary for its use. Simply categorizing a project as commercial, MIS or military is not sufficient. Even among commercial projects, there can be large variations in productivity because of various project attributes. These include project size, development tools and other factors. A truly similar project must be found in order to get productivity rates that can be used with confidence.
There are areas of debate regarding the second approach. One is whether to base the derived line count on the unadjusted function point count or use the count after it has been adjusted by the Value Adjustment Factor. In his preliminary work on COCOMO2, Barry Boehm is definite in his belief that better results have been generated using the unadjusted counts. However, other practitioners have been using adjusted ones.
These same approaches are valid for estimating maintenance activities. However, there are two major reasons why these estimates can be even more difficult to arrive at. First, maintenance activities tend to be smaller is size. It is always dangerous to use a model to predict small projects. The timing is very dependent upon the individual or small team doing the work. Supermen (and superwomen) exist in the software development community. However, no one seems to be able to find and coordinate the activities of 30 super people.
The second challenge in estimating maintenance is the nature of enhancement function points. This was discussed in the answer to the "What are enhancement function points?" question. Adding an additional 100 function points of functionality or deleting 100 function points result in an enhancement count of 100 function points. However, the effort estimate would be quite a bit different. This must be considered when using this technique.
The effort and schedule required to develop or enhance a software product are influenced by a number of factors in addition to product size. Many of these factors are discussed by Barry Boehm in conjunction with his new COCOMO2 model. They can be summarized into the following four categories:
Benchmarking became popular as part of Total Quality Management (TQM). Employees of one company would visit other companies and compare various processes in those companies with the same process in their own. Some people felt that these interactions gave them valuable insights that helped them to optimize their business processes. Others felt that they were expensive field trips that distracted people from the business of solving their own problems.
Most companies are involved in software development. This became a natural process to benchmark. Furthermore, techniques like function point analyses allow people to attempt to do quantitative comparisons between companies.
The advantages of these comparisons are obvious. IS departments can get an advanced look at the impact of moving to new technologies. They can pinpoint problems in their own processes.
Unfortunately, there are difficulties. Despite volumes of generally accepted accounting practices, comparing the financial statements of two companies can be tricky. Comparing the productivity rates of two IS departments is worse. There are just too many different approaches to counting reuse when measuring size, and too many different possibilities when considering which staff to allocate to a project.
Of course, there are several organizations that are involved in IS benchmarking. Most of them make some use of function points. The best known organizations are:
All of a company's software applications can be thought of as their application portfolio. A business has three possible courses of action for each of these applications. They can retain, retire, replace or redesign the application.
While the function point size of an application is a factor in this decision, there are usually several other factors to be considered. Several consulting firms claim to have methodologies to help with planning at this level, but there is no universal agreement on how these decisions should be made. Some notes on each course of action follow:
A similar set of comments could be made about projects. All of the ongoing projects could be thought of as comprising a portfolio. As each project started it was authorized through some mechanism in the company. However, over time, business priorities, technologies and the company's understanding of the projects all change. At any point, the projects in the portfolio have to be reexamined to make sure that their continued funding still makes sense.
Many of these programs begin when a CEO, CFO or CIO decides that he or she wants to have a metrics program. Then the question becomes what is the best way to implement the program? Otherwise, you may have to make the case for a metrics program yourself. Justifying these programs is never easy. The following two books might help you start:
Both books are published by Prentice Hall as part of their Yourdon Press Computing Series. Both books are written by well-known measurement consultants with products and organizations they are attempting to market.
Once the program is justified, it has to be designed and implemented. In the case of the metrics program, that means selecting what will be measured, who will be collecting and analyzing the information, how findings will be presented, and a host of other questions.
All of the function point consultants that are listed under resources claim to be able to help implement these programs. Most of them of them can be helpful in the process. The ultimate success of a metrics program rests with the organization itself. Howard Rubin has often said that the life expectancy of a metrics program is 18 months. Even programs that claim long histories have often experienced periods where the influence of those programs has ebbed.
There is one other resource that should be considered for those hearty souls who are undertaking the implementation of a metrics program. The Quality Assurance Institute has a couple of courses that address this undertaking. They can be reached at (407) 363-1111.
People want to use function points to measure the productivity of new development, the amount of support necessary for existing application portfolios and the productivity of enhancement projects. However, there are some large issues that every organization must address. These are beyond the scope of IFPUG counting practices.
IFPUG has a documented procedure to measure new development function points. However, that procedure leaves a number of critical questions unanswered. The way these questions are answered can have tremendous impact on the way productivity is measured. Some of these questions follow:
Support size is used to predict the number of maintenance programmers that an organization will need to employ. Capers Jones has said that the maintenance assignment scope should be between 500 and 1500 (or more) function points. Many people look for a similar magic number. However, the following factors make this support load hard to predict:
IFPUG has a procedure for counting enhancement function points. However, it is not particularly easy to apply. There is also a question of how useful it is for measuring productivity. Some of the problems follow:
Capers Jones has referred to function points as the fastest growing software measure of recent years. Therefore, one would expect a good deal of resources to be available. There are. Unfortunately, function point analysis will never be as pervasive as C++ programming. There will always be a more limited supply of resources, and there may be gaps in the resources available. For example, there is not yet a function point counting text book that everyone agrees is exhaustive.
The list that follows will present key function point resources. Some of the above questions, like the one on benchmarking, mentioned firms that were active in the benchmarking area and may have only had a limited interest in function points. These firms are not repeated below.
One of the strengths and weaknesses of this list is its limited size. It is a strength because the list is restricted to resources that have demonstrated some staying power in the field of function point analysis. Unfortunately, the weakness is that it will probably slight some practitioners who are truly deserving of consideration. A geographical weakness is that it concentrates on North America.
The following questions deal with specific types of resources:
According to its brochure, the International Function Point Users "is a membership governed, non-profit organization committed to promoting and supporting function point analysis and other software measurement techniques." It appears to have been organized in 1986, when a group of American companies decided that they wanted to pursue the use of function point analysis without being associated with IBM or its GUIDE association. They must have gotten someone from Canada involved so that they could call themselves international. In any case, their membership is still primarily North American.
Quoting from their brochure again, "IFPUG maintains the Function Point Counting Practices Manual, which is the recognized industry standard on FP analysis." There is no disputing this. Early releases of the document were reviewed by Alan Albrecht and found to be consistent with his ideas regarding function points. The latest release has been reviewed by four large European and the Australian users groups.
IFPUG claims to have over 1000 members. The current regular membership appears to consist mostly of Fortune 1000 companies who are at least interested enough in function points to pay the $500 per year dues for each physical location using function points. Many of these companies also send delegates to the IFPUG conferences. The IFPUG also has several associate members who are concerned with providing function point consulting, training and other related products.
This year, IFPUG has instituted an individual membership. It is appropriate for both individuals and small companies. It cost $150 per year. This is about the amount of money that many people currently spend on their ACM or IEEE memberships. However, IFPUG currently produces much less journal type material than these other organizations. It is possible that the dues structure will undergo further refinements in the not too distant future.
Among the services of IFPUG are the conferences that they hold twice per year. The conference itself is on Wednesday through Friday. Monday and Tuesday are used for optional tutorial sessions, including the introductory course. One of the best ways to learn about function points is to attend the tutorial and stay for the conference.
The IFPUG has had a questionable track record with on-line access to their information. However, their web page is at http://www.ifpug.org/ifpug. It is worth trying to see if it is available. Otherwise, their contact information is
International Function Point Users Group
Blendonview Office Park
5008-28 Pine Creek Drive
Westerville, Ohio 43081-4899 USA
Voice: (614) 895-7130
FAX: (614) 895-3466
Both the internet and CompuServe serve as sources of on-line function point information. Many of the function point trainers and consultants maintain web pages. There URL�s are listed in the next section. References to other worthwhile resources follow:
Many management consultants and systems integrators will offer some type of function point related services. However, the following firms make function point analysis a significant part of their practice and have established a presence in the function point community:
There are many general purpose software products, like Microsoft Excel, that can be useful to the function point practitioner. These are not discussed here. Likewise, every producer of estimating and project management software is willing to sell their product to function point users, but there products are not listed here. The products that follow are primarily function point applications that have enjoyed some level of usage in the function point community:
The following books and periodicals should be of interest to function point practitioners: