Of linos of codc

If the denominator is inflated , then the quality may appear artificially high. The coding phase of most projects typically consumes only an insignificant 7% of total effort to a maximum of only about 20% of total effort. It is, of course, the quality of code that is important, not the volume.

These issues led the thinkers of the software revolution to cast about for another way to measure. Enter function points.

Function Points as a Unit of Size

The function point (FP) method is based on the idea that software size is better measured in terms of the number and complexity of the functions that it performs than on the number of lines of code that represent it. The first work to be published about function points was written in the late 1970s by A.J. Albrecht of IBM, for transaction-oriented systems. Capers Jones, of Software Productivity Research, Inc, expanded Albrecht's ideas into a large and widely recognized body of knowledge. In 1986, a nonprofit group, the International Function Point User Group (IFPUG), was formed to disseminate information about the metric. In 1987, the British government adopted a modified function point for the standard software productivity metric. 1994 saw the publication of Release 4.0 of the IFPUG Standard Function Point Counting Practices Manual and Release 1.0 of the IFPUG Standard Guidelines to Software Measurement.

Function points measure categories of end-user business functions. They are determined in a more methodological way than are LOC counts. A really straightforward analogy is that of a physical house to software: The number of square feet is to the house as LOC is to software; the number of bedrooms and bathrooms is to the house as function points are to software. The former looks only at size; the latter looks at size and function.

Function points are intended to do the following:

• Measure categories of end-user business functions;

® Address the problem of attempting to estimate LOC too early in the life cycle;

® Determine the number and complexity of outputs, inputs, database inquiries, files or data structures, and external interfaces associated with the software system.

A quick overview of the function point process is:

1. Count the functions in each category (categories are: outputs, inputs, inquiries, data structures, and interfaces).

2. Establish the complexity of each—simple, medium, complex.

3. Establish weights for each complexity.

4. Multiply each function by its weight and then sum up to get total function points.

5. Convert function points to LOC using the formula:

LOC = Points x ADJ x Conversion factor where ADJ is an adjustment for the general characteristics of the application.

The conversion factor, based on historical experience for the application and programming language, represents the average number of lines of code to implement a simple function. Why do this last step? Because most automated tools that estimate effort, cost, and schedule require LOC as input. Now we'll describe the FP process in more detail.

Guidelines for Counting Function Points

Figure 10-4 shows the basic steps in counting function points; each will be described later. Each step has an output that is used in the next step. Table 10-2 shows the input, transformation, and output of each step in FP counting. This worksheet is left blank, as a template for your future use.

Figure 10-4. Basic Steps in Function Point Analysis

Figure 10-4. Basic Steps in Function Point Analysis

Step 1. Count Number of Functions in Each Category

General Guidelines for Counting

® Count only software requirements functions.

® Count logical representations. When any input, output, and so on requires different processing logic, each one of those logical representations is a unique function point.

The first rough cut at estimating the size of the system to be developed entails examination of the major system components. How much output is produced? How much input is necessary to produce the output? How much data is stored?

Count the number of items: outputs, inputs, inquiries, and files. The preliminary architecture provides the basis for this counting activity. Some people can begin with architecture in the form of textual requirements, but having an architecture in graphical form is very helpful. The weighting factors applied to all of these visibly external aspects of software are a set of empirical constants derived from trial and error.

Table 10-2. Function Point Analysis Worksheet

Step 1. Count Number of Functions in Each Category Step 2. Apply Complexity Weighting Factors

Simple

Average

Complex

Function Points

Number of Outputs

x 4

x 5

x 7

Number of Inputs

x 3

x 4

x 6

Number of Inquiry Outputs

x 4

x 5

x 7

Number of Inquiry Inputs

x 3

x 4

x 6

Number of Files

x 7

x 10

x 15

Number of Interfaces

x 5

x 7

x 10

Total (FP):

Step 3. Apply Environmental Factors

Environmental Factor

Rating (0,1,2, 3, 4, 5)

Data Communications

Distributed Computing

Performance Requirements

Constrained Configuration

Transaction Rate

Online Inquiry and/or Entry

End-User Efficiency

Online Update

Complex Processing

Reusability

Ease of Conversion/Install

Ease of Operation

Used at Multiple Sites

Potential for Function Change

Total (N):

Step 1. Count Number of Functions in Each Category Step 2. Apply Complexity Weighting Factors

Simple

Average

Complex

Function Points

Step 4. Calculate Complexity Adjustment Factor (CAF)

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment