Weakness of Function Point Analysis

Function Point Analysis is seen as a very important and useful technique for requirements estimation, and for numerous other benefits (see previous post for more details). However, even such a famous method has its detractors, with a number of people / studies pointing out issues with the technique. Here are some of these issues / weaknesses / problems:

- FPA is seen as not being fully suited for object oriented work with an objection that the core of the technique, function points cannot be reasonably counted for object-oriented requirements specifications. The problems are that several constructs of object oriented specifications representation can be interpreted in various ways in the spirit of FPA, depending on the context.
- Function point counts are affected by project size; ideally Function Points should not be affected by project size since they measure each function, but this does not work out in actual practise
- Function Point Counting techniques have been found to be not easy to apply to systems with very complex internal processing or massively distributed systems
- Difficult to define logical files from physical files
- The validity of the weights that were present in the initial technique that the founder of FPA, Albrecht, set up as well as the consistency of their application has been challenged
- Different companies do calculate function points slightly different (actually depending on the process and people who do the actual Function Counts), making intercompany comparisons questionable and negating one of the core benefits of having standardised Function Counts
- There is a conflict in the usage of FPA for project size purposes, this conflict being with another standard measure of counting - The number of lines of code is the traditional way of gauging application size and is claimed to be still relevant because it measures what software developers actually do, that is, write lines of code. At best it can be used along with Function Counts.
- Doing FPA means that you are depending on converting back the available information to actually do essentially the same thing as requirements specification, and should end up with the same types of errors. This process is touted as a big error prone area.
- Function points, and many other software metrics, have been criticized as adding little value relative to the cost and complexity of the effort which are major factors in decision making
- The effort in computing function points has some base errors inherent because much of the variance in software cost estimates are not considered (such as business changes, scope changes, unplanned resource constraints or reprioritizations, etc.).
- Function points don't solve the problems of team variation, programming tool variation, type of application, etc.
- FP was originally designed to be applied to business information systems applications. So, the data dimension was emphasized and as a result, FPA was inadequate for many engineering and embedded systems.
- Another problem, this one dealing with the technical process of FPA comes up when assessing the size of a system in unadjusted function points (UFPs). The
classification of all system component types as simple, average and complex is not sufficient for all needs.
- Counting FP's is a major factor, requiring the presence of a skilled counter. Many companies get this work done by people not having the desired skill level (this happens for other tools as well, but counting correct FP's is critical to the whole system)
Inspite of these problems, FPA is a very useful tool, and probably a very good fitment for doing estimation.

Advantages / Benefits of Function Point Analysis

Function Point Analysis is seen as a significantly important took / process for doing estimation. But what exactly are the benefits that you can get via this process, and why is this something that people are willing to pay good money to learn ? Reading ahead, you will see reasons outlined (and if you are willing to share your own story of how FPA worked for you, please share via the comments).

Function Point Analysis lets you have the ability to do a reasonably accurate estimate of the most important estimation metric:
- The project cost
- The duration of the project
- The number of resources required to staff the project

In addition, there are more metrics that are required for a project, and FPA helps in understanding them much better:
- You can get a good idea of the project defect rate
- By calculating the number of Function Points (FP's), you can calculate the cost per FP
- Similar calculations will get you the FP's per hour
- If you are experimenting with using new tools, using FP's provides you an easy way to determine the productivity benefits of using new or different tools

Some of the other benefits of using Function Point Analysis are listed below:
- By measuring FP's, you can guard against increase in scope (function creep)
- Measurement of performance indicators enables benchmarking against other teams and projects
- Project Scoping: By breaking the project into several small functions, you get the advantage of being able to easily convey the scope of the application to the user
measured in function points.
- Assessing Replacement Impact: If existing applications have to be replaced by a similar application, you know the desired FP (and the size of current project).
- Assessing Replacement Cost: Once you know the replacement impact, it is easier to derive the replacement cost, since some standard figures are available for cost per FP
- Testing Resources: With the help of the FP's calculated during the project, it is easier to calculate the areas that are more complex and will require more testing effort.

In summary, Function points work well as a measurement tool in part because, they are relatively small units and can be measured easily. These measurements in turn can be used to derive a number of project related metrics.

Effort Estimation Technique: Function Point Analysis (Part 2)

In the previous post, you learned about the 5 functional components; now, in addition to these, there are 2 adjustment factors that need to be employed during Functional Point Analysis. These are:

Functional Complexity: As the name states, you need to consider the functional complexity for each unique function. Functional Complexity is determined based on the combination of data groupings and data elements of a particular function. Then, the data elements and unique groupings are counted, and based on a complexity matrix, these functions will be rated as high, medium, or low complexity (and the complexity matrix is unique for each of the 5 different types of functional components). Once this analysis is done, you get a total called as Unadjusted Function Point count.

Value Adjustment Factor: This is the second adjustment factor, and takes into account the system's operational and technical characteristics. There are a total of 14 questions / factors that need to be used for this calculation:
# Data Communication: The data and control information used in the application are sent or received over communication facilities
# Distributed data processing: Distributed data or processing functions are a characteristic of the application within the application boundary
# Performance: Application performance objectives, stated or approved by the user, in either response or throughput, influence (or will influence) the design, development, installation and support of the application.
# Heavily used configuration: How heavily used is the current hardware platform where the application will be executed?
# Transaction rate: How frequently are transactions executed daily, weekly, monthly, etc.?
# Online data entry: What percentage of the information is entered On-Line?
# End user efficiency: The on-line functions provided emphasize a design for end-user efficiency.
# Online update: The application provides on-line update for the internal logical files.
# Complex processing: Does the application have extensive logical or mathematical processing?
# Reusability: Was the application developed to meet one or many user’s needs?
# Installation ease: How difficult is conversion and installation?
# Operational ease: How effective and/or automated are start-up, back-up, and recovery procedures?
# Multiple sites: The application has been specifically designed, developed and supported to be installed at multiple sites for multiple organizations.
# Facilitate change: The application has been specifically designed, developed and supported to facilitate change.

One of the major sub-process in the FPA analysis is about counting of the Functional Points. There are several approaches used to count function points. The five major steps in the process of counting FPs are as follows:

1. Determine the type of count.
2. Identify the scope and boundary of the count.
3. Determine the unadjusted FP count.
4. Determine the Value Adjustment Factor.
5. Calculate the Adjusted FP Count.

Effort Estimation Technique: Function Point Analysis (Part 1)

The Function Point Analysis technique was developed during the late seventies by IBM, which commissioned one of its employees, Allan Albrecht to develop this technique. In the early eighties, this technique was refined, and then a new organization, International Function Point Users Group (IFPUG), was founded to take the Function Point Analysis technique forward; while keeping the core spirit behind what Albrecht had proposed.
Function Point Analysis (FPA) is a sizing measure that uses a system of sizing as per clear business significance. Function Point Analysis is a structured technique of classifying components of a system. One of the primary goals of Function Point Analysis is to evaluate a system's capabilities from a user's point of view. It is a method used to break systems down into smaller components so that they can be better understood and analyzed. The main objectives of FPA are:
1. Measure software by quantifying the functionality requested by and provided to the customer.
2. Measure software development and maintenance independently of technology used for implementation.
3. Measure software development and maintenance consistently across all projects and organizations.
FPA uses functional, logical entities such as outputs, inputs, and inquiries that tend to relate more closely to the functions (that is, business needs) performed by the software as compared to other measures, such as lines of code. FPA has become generally accepted as an effective way to
* estimate a software project's size (and in part, duration)
* establish productivity rates in function points per hour
* normalize the comparison of software modules
* evaluate support requirements
* estimate system change costs
In the world of Function Point Analysis, systems are divided into five large classes and general system characteristics. The first three classes or components are External Inputs, External Outputs and External Inquires. Now, each of these components transact against files and are hence called transactions. The next two classes, Internal Logical Files and External Interface Files are where data is stored that is combined to form logical information. The general system characteristics assess the general functionality of the system.
Details of each one of these:
1. Data Functions → Internal Logical Files: This contains logically related data that resides entirely within the application’s boundary and is maintained through external inputs.
2. Data Functions → External Interface Files: The second Data Function a system provides an end user is also related to logical groupings of data. In this case the user is not responsible for maintaining the data. The data resides in another system and is maintained by another user or system.
3. Transaction Functions → External Inputs: This is an elementary process in which data crosses the boundary from outside to inside. This data may come from a data input screen or another application. The data may be used to maintain one or more internal logical files. The data can be either control information or business information.
4. Transaction Functions → External Outputs: an elementary process in which derived data passes across the boundary from inside to outside. The data creates reports or output files sent to other applications.
5. Transaction Functions → External Inquiries: The final capability provided to users through a computerized system addresses the requirement to select and display specific data from files. To accomplish this a user inputs selection information that is used to retrieve data that meets the specific criteria. In this situation there is no manipulation of the data. It is a direct retrieval of information contained on the files.

Effort estimation techniques

A new project is being thought of (or even an extension of the current product). As an example, say you want to build a new shopping cart application for your website. In order to get started, besides knowing exactly what you want to build (the product details), you also need to start estimating how many people you will need and how long it will take. And this process of estimation is probably one of the more difficult parts of software development, something that can make or break a project. Suppose your estimation goes wrong, and you estimate too little effort for the project. In such a case, you will be forced to make compromises / overwork the people involved / deliver a low quality work. All of these are major factors that could cause the project to fail. Fortunately, there are a number of different effort estimation techniques that could be employed (this post just has brief descriptions, details for each of these will be covered in future posts):

# Function Point Analysis (FPA): A way to break down the work into units to express the amount of business function an information system provides to a user
# Parametric Estimating / Estimation Theory: Estimating the value based on measured / empirical data
# Wideband Delphi: A estimation theory that works on the basis of developing a consensus for the estimation (typically based on a series of group meetings)
# Cocomo: An algorithmic estimation model, using a regression formula derived from historical data and current project details
# Putnam Model: Taking data from the project (such as effort and size and fitting these data to a curve). This is an empirical model.
# SEER-SEM Parametric Estimation of Effort, Schedule, Cost, Risk.: System Evaluation and Estimation of Resources - Software Estimating Model. This model is based on a mixture of statistics and algorithms
# Proxy-based estimating (PROBE) (from the Personal Software Process): Proxy based estimating produces size estimates based on previous developments in similar application domains
# The Planning Game (from Extreme Programming): This is the process that depends on release planning and iteration planning (inside iteration planning, requirements are broken down into tasks and tasks are estimated by the programmers)
# Program Evaluation and Review Technique (PERT): PERT is intended for very large-scale, one-time, complex, non-routine projects, and has a great advantage of being able to incorporate uncertainty
# Analysis Effort method: This method is best suited to producing initial estimates for the length of a job based on a known time duration for preparing a specification
# TruePlanning Software Model: Parametric model that estimates the scope, cost, effort and schedule for software projects
# Work Breakdown Structure: In this technique, all the individual tasks are laid out with their estimates and description, and they can be summed to display the total effort

Doing something new in the same company

Suppose you are working for a software company that makes software products, and are getting somewhat bored of the same product that you have been working on for some time now (if you have been with the company for some time now, there are good chances that you will be working for version X.y of the same product, and would have felt that you have not being doing anything new for quite some time now). What can you realistically do ? There are several options that you should consider (some of them are possibilities depending on the company you are working for in terms of size, policies, etc).
- You could ask to move to another group. Say you are working for a particular product as a developer, you could ask to move to another product. Typically, most companies are loath to lose good guys, and would consider your request
- You could change your sub-role within the same function. Say you are the engineering manager handling a team, and feel that you have been out of touch for quite some time, then you could request that you no longer be a manager, and instead move to a non-managerial role. Good companies have an equally rewarding career path for people who want to remain in non-managerial positions
- You could change your function. At times, a person finally realizes that his role is not longer attractive enough. So you could change from being an engineer to a quality role, or a product management role, or any other such role. For moving to a new role, you need to have some background skills as well as a base in the product, and you would already have a base; so that is half the problem solved. If you are looking at such an option, then you should take care that you keep a lookout for new positions that become open.
- Start something new. This is something that is a bit more difficult. Most companies of a certain size and above have a policy of allowing employees that have new ideas to work their way through these ideas. So, they can actually get support to develop their ideas, and if the idea has market potential, they could actually lead the effort to get this idea into a new market
- Take some time off. Many companies have this policy where they would allow people to take time off, and depending on the amount of time, this could be paid or unpaid leave (without harming their career in any way)
Finally, if nothing works, and you are feeling bored / frustrated, then it is time to quit your job and work elsewhere.

A great resource: Joel on Software

For a long time now, I have been reading the content posted by Joel Spolsky on his blog. I like his writing enough to have taken an email subscription to his feed so that I get notified whenever he writes a new article. His feed typically provides the opening paragraph of the content, and then I go to the Blog to read the rest. And what is the link of the Blog, you may ask ? Well, here it is (link)
As Joel says, "This is Joel on Software, where I've been ranting about software development, management, business, and the Internet (ack) since 2000. Rest assured, however, that this isn't one of those dreaded blogs about blogging." He spent some time in various jobs including Microsoft Consulting, and then chucked it all up, and went onto found his own company called Fog Creek Software in September, 2000.
I like a lot of his articles where he talks about design, usability, and sundry other topics. The articles are not long or preachy, but are instead quick reads and, if you are in the software business, you should consider them as part of an ongoing education.
Joel has written books as well, and this is his latest one: