R    E   •   D    A    C   •   T    I    O    N
 
 
 
     
 
   

 

Lightweight Function Points
Notes on a Structured Approach To Software Estimation

 

       Abstract:
 
Metrics-based software estimation can provide a framework for reasoning about project cost and timing. Estimation systems improve with consistent use as organizational sophistication increases and historic metrics come into play. For a system to be consistently used it must be straightforward, trend towards accuracy, and be generally applicable. This paper outlines a simple modified function point approach suitable for web development projects which has been shown to meet these criteria.

 

 
There is nothing more fun than critical software estimation, except maybe a root canal. Software estimates are notoriously inaccurate, not rigorous, and generally fly by night. Project success is highly dependent on reasonable effort estimation. We all know the common wisdom on the ratio of success to failure in software project work: low. Given the importance of software projects to the bottom line of most companies it seems reasonable to take another crack at the problem of generating reasonable estimates. The fact that there can be no perfect system should not deter us.

This paper outlines a modified function point system, call it Lightweight Function Points (LFP), aimed at Internet projects. The system has been used in projects in several companies with good results. There is no intention here to create a new standard for function point counting. Rather the goal is to offer a concrete example of function points in action and, since this is not IFPUG compliant, to account for the approach taken.

Two quick questions should be popping up:

  • Why count function points (in any way, shape or form)?
  • Why depart from the traditional function point methods?
The answer to the first, why count function points, is simple—do or don't, dealers choice. But virtually everyone does software estimates of some sort. Probably the most common situation is for a project leader to be handed schedule and budget constraints under conditions coverable as force majeure. Next most likely is that estimates come out of a smoke filled room of one. In many cases teams get together and try to ballpark the numbers. If a company keeps detailed records of past work a reasonable estimate might come from looking at similar projects. The best known formal methods include counting lines of code (LOC), COCOMO, and counting Function Points. Each of these approaches has a many year history and competing methodological factions. And other lesser known methods undoubtedly exist.

The concept of function point counting intuitively works for many people. Compared to counting LOC that don't yet exist function points may feel more concrete—after all in some form the functional requirements do exist. COCOMO on the other hand is a statistically based model driven estimation tool that uses hundreds of data points, including estimated Delivered Source Instructions. This is a highly structured approach with similar LOC roots and a substantial history. However COCOMO is not at all intuitive and it tends towards a steep learning curve. Function points are user centric rather than code centric. This works well for people with a background in business or use case analysis. So why not go to the International Function Point User's Group, get the standard and start counting? Because IFPUG style point counting is overly complex for many small and mid sized projects and because it is doubtful that traditional function point counting will apply directly to a web development project unmodified, in any case. Instead we will look at a lightweight version of function point counting with relatively few rules, cognizance of project roles and relationships, and a focus on end user facing distributed applications.

 
WHAT IS A LIGHTWEIGHT FUNCTION POINT?

Lightweight Function Points have two main components:

  • Point definition
  • Point-based group effort structure
Added to these two items may be a risk weighting, cost numbers, etc. In practice a LFP worksheet may extend to any number of derived metrics, as shown in the example below, but the starting point is simplicity.

Points are defined as one user function affecting each layer of the application. Remember that we are focused on web applications. The typical enterprise class web application, at least in the minds of its creators, is minimally layered as:

  • Presentation
  • Application
  • Data
An example of a single function point item might be a login screen. Each layer of the application is touched. No one layer does (or requires) significantly more work than another. The unit of work per layer is modest. However, not every work item will be so neat. A message-based systems integration triggered by the login function may have no significant UI or database work attached but require sophisticated business or integration logic. Nonetheless, working on the law of averages we can accept a function point that charges us for more UI time than is needed in this case, knowing there will be a balancing point that requires less software engineering. In the end, lightweight function points are generalizations. They will fit well to one function and poorly to another. There is no exact science of estimation—but on average a stronger estimation system out performs a weaker one.

Zooming in on the application exposes new detail. Layers tend to divide, for instance presentation is probably a combination of client and server side programming. This is important because client and server side development come from different skill sets. If we get a bit closer to the project team we'll probably see designers, UI developers, software engineers and systems engineers all collaborating. Each of these roles impacts the estimates. With a nod towards reality we will add project manager and quality control roles and, frequently, a product manager or program manager (Note: these roles are not equivalents, but one is more likely in a consumer effort and the other more likely in an internal systems project). Larger projects collect more people, no surprise there. Each person increases the cost of project management by upping the cost of communication and coordination, and impacts risk (as we will define it below). And of course, each additional role impacts the schedule independently as concerns are increasingly separated.

The function point considers system layers and the relationship of roles to layers—all in the context of a unit of functionality, as shown in Figure 1, below. Defining a function point consistently is an important first step of using function points to estimate work. The definition needs to be clear about two things:

  • The scope of an average unit of work
  • The average participation of the involved groups in one unit of work
The measurement of participation is usually fractional days or hours. Add to these two items an internal cost per hour per group (Note: this is a prorated salary average plus total overhead or an external charge per hour plus any internal overhead) and you can find a number of interesting metrics, including the time per point, cost per point, project overhead, etc.

Beyond this metric baseline I suggest defining and assigning risk and a planning-to-execution ratio. Risk should be a separately tracked metric with an easily understood impact on the bottom line. There are many definitions of risk but I would suggest considering the risk of miscommunication or misunderstanding of requirements. Some projects track other risks, including new technology risk, personnel issues, design failure. And many project managers work by just buffering all estimates. While these approaches can work they may cloud real progress towards better work estimation with rules of thumb of questionable accuracy. Along with some measure of risk it may be useful to break down the definitional function point into planning and execution. Although this step may not be needed for some projects it offers a possibly useful resolution on project progress against estimates at any given point.

 

Figure 1. Lightweight Function Points cut across system layers and development groups. ...

 
USING LFP: A SMALL APPLICATION EXAMPLE

How do we get started counting LFP? As we said above, step one is to outline what a function point is. Given a modest catalog/cart eCommerce component as our example project, we will want to create an LFP Worksheet. At the top of the sheet the LFP definition will be:

 
 

FUNCTION POINT DEFINTION

   One point is the average unit of functionality. Each point represents the impact of one user action on each level of the application. The levels considered are Model (data), View (UI), Controller (application functions).

   The risk number represents time lost and/or time wasted due to miscommunication or misunderstanding. This can be thought of as a measure of complexity—simple items are less subject to misinterpretation or incomplete information.

 

Source 1. Definition of a function point, with related definitions.

 
The next step is to define the groups participating in the development work. We don't need precise definitions of role here, but an accurate list of what players will impact the deliverables is required. Besides this list we need to estimate the average effort composition of one function point. In our example document, this section will look like:

 
 

FUNCTION POINT BREAKDOWN

# Planning
     #    Product Management
     #    Project Management
     #    Software Engineering
     #    Quality Assurance
     #    Senior Management
# UI
     #    Graphic Design
     #    Web Programming
     #    Software Engineering
# Application
     #    Software Engineering
# Data Management
     #    Software Engineering
     #    Systems
# Quality Control
     #    Software Engineering
     #    Web Programming
     #    QA
     #    Project Management
     #    Senior Management
# Project Management
     #    Project Management
___________________________________________________________

#      TOTAL DAYS PER POINT

 

Source 2. Average effort composition of a function point.

 
With this information we can see the project's point costs, cost per function day, etc. We need to settle on an approach to a risk multiplier before moving on to picking apart the functions for their points. Risk multipliers, like everything else about software estimation, improve with age. The way we have defined risk it is almost completely idiosyncratic to the company. As a starting point I would suggest using a thin factor for risk and modifying it over several projects as reliability is tracked against actual progress. As long as the risk measure is isolated from the unweighted estimates experimenting with it will not interfere with accuracy. With risk in place it is up to the project manager to collect and organize requirements and solicit input from the team for the function point breakdown.

Here is our simple example LFP Worksheet. Take this example as only a rough starting point. Many more useful metrics can be incorporated (not to mention a cleaner style!) Keep in mind that software estimation is not a one time process and, with organizational discipline, ages well.

Happy counting.

   
   

 

 

    
© 1999-2002, d.kershaw. all rights reserved.
Δ