Function Points and the SEI Capability Maturity Model
David Lipton

When a software development organization first becomes interested in deriving the benefits of measurement, it may be confronted with a number of options and approaches which can be utilized. Two of the most widely known approaches in software measurement are Function Point Analysis and the Software Engineering Institute (SEI) Capability Maturity Model (CMM). There is often confusion on how these two approaches work together. The purpose of this article is to show how and where Function Point Analysis maps into the Software Engineering Institute (SEI) Capability Maturity Model (CMM).

The CMM is the most widely accepted model for understanding the process of software development. It has been used successfully by many organizations to appraise their software process and identify the key areas to focus improvement initiatives.

Function Point Analysis is a proven, reliable method for measuring the size of computer software. In addition to measuring the output of the software development process, Function Point Analysis is extremely useful in estimating projects' duration and costs, managing change of scope, measuring productivity, and communicating functional requirements.

This article will provide a mapping within the structure of the CMM where Function Point Analysis is the metric of choice.

The Structure of the CMM
The CMM provides a framework for understanding and improving an organization's effectiveness in developing software. It is organized into five levels of organizational maturity, where each level represents an evolutionary stage of process capability. Figure 1 shows the five levels of the CMM.

Figure 1. The 5 levels of the CMM

Each level represents a stage of organizational maturity, described in terms of its "Key Process Areas." A Key Process Area is a group of related activities considered to be important for an organization functioning at the appropriate process maturity level.

A Key Process Area's goals are met when certain activities are performed. For example, one of the goals of the Level 2 Key Process Area Software Project Planning is "Software estimates are documented for use in planning and tracking the software project." Figure 2 shows the Key Process Areas for each Level of the CMM.

Figure 2. Key Process Areas
Level 5 "Optimizing" Defect Prevention
Technology Change Management
Process Change Management
Level 4 "Managed" Quantitative Process Management
Software Quality Management
Level 3 "Defined" Organization Process Focus
Organization Process Definition
Training Program
Integrated Software Management
Software Product Engineering
Intergroup Coordination
Peer Reviews
Level 2 "Repeatable" Requirements Management
Software Project Planning
Software Project Tracking and Oversight
Software Subcontract Management
Software Quality Assurance
Software Configuration Management
Level 1 "Initial" (no Key Process Areas)

Observe that Level 1 has no key process areas. Level 1, the "Initial" level, represents absence of process. An organization is said to be functioning at Level 2 when all of the Level 2 Key Process Area goals are met. Most organizations are trying to achieve Level 2.

Level 2, the "Repeatable" level, is primarily concerned with good project management practice. It focuses on processes which apply at the project level. Level 3, on the other hand, is concerned with processes which relate to engineering activities across an organization. Level 4 looks at processes at a more granular level, providing measurement and feedback at the process level. Level 5, which has been achieved by only a handful of organizations, is concerned with continuously improving an already world class organization.

Because of the project management focus of Level 2, it is within the Key Process Areas of Level 2 that we will most readily map Function Point Analysis. Relevant goals and activities for each Key Process Area are quoted from the SEI CMM document (CMU/SEI-93-TR-25) for Level 2 practices.

Requirements Management
Goal 1

System requirements allocated to software are controlled to establish a baseline for software engineering and management use.

Activity 1

The software engineering group reviews the allocated requirements before they are incorporated into the software project.

Activity 3

Changes to the allocated requirements are reviewed and incorporated into the software project.

Function Point Analysis can be used to describe and document functional requirements. It supports this goal by analyzing the requirements in order to quantify the functional size of the project. A function point count at the requirements phase of a project can be used for estimating and to set a baseline for managing scope creep.

As requirements do change, function points can be used to communicate the size of the changes relative to the size of the project.

Software Project Planning
Goal 1

Software estimates are documented for use in planning and tracking the software project.

Activity 7

The plan for the software project is documented. Size estimates of the software work products and any changes to the software work products.

Activity 9

Estimates for the size of the software work products (or changes to the size of software work products) are derived according to a documented procedure.

Size estimates are made for all major software work products and activities. Examples of software size measurements include function points.

Activity 10

Estimates for the software project's effort and costs are derived according to a documented procedure.

This procedure typically specifies that:

Estimates for the software project's effort and costs are related to the size estimates of the software work products (or the size of the changes).
Productivity data (historical and/or current) is used for the estimates when available; sources and rationale for this data are documented.
Clearly, function points are the metric of choice for software size estimates, and for the use of size estimates in estimating project effort and cost. This is supported by numerous industry benchmarks as well as in-house history.

Software Project Tracking and Oversight
Goal 1

Actual results and performances are tracked against the software plans.

Activity 5

The size of the software work products (or size of the changes to the software work products) are tracked, and corrective actions are taken as necessary.

Activity 11

Actual measurement data and re-planning data for the software project are recorded.

In this Key Process Area, function point counts are updated through the life of the project. Typically, an initial count is performed at the requirements phase, and updated at the design phase. By recording, tracking, and analyzing the size changes through the project, an organization can improve the effectiveness and accuracy of its estimating, thereby improving control and oversight of the project.

Software Subcontract Management
Goal 4

The prime contractor tracks the software subcontractor's actual results and performance against its commitments.

Activity 1

The work to be subcontracted is defined and planned according to a documented procedure.

Function Point Analysis has been widely used in subcontract management situations to communicate size, evaluate bids, and define contract terms. This includes one time development as well as long term outsourcing arrangements. This Key Process Area invites the use of function points for estimating at the requirements phase and tracking changes through the project. A final count at project completion is used to compare what was delivered to what was planned, and is useful in helping to evaluate the performance of the contractor.

Software Configuration Management
Goal 2

Selected software work products are identified, controlled, and available.

Goal 3

Changes to identified software work products are controlled.

Activity 6

Changes to baselines are controlled according to a documented procedure.

Function Points play an important supporting role in Software Configuration Management. When requirements change, the magnitude of the changes should be quantified and expressed in function points. The function point documentation for the project can also be placed under configuration management, as a technique for describing the functional changes.


Function Point Analysis can be demonstrated to be the metric of choice for many of the activities required by the SEI CMM at Level 2. Its use in managing requirements, project plans, subcontractors and documentation can greatly benefit projects. The question for an organization considering the CMM and Function Point Analysis should not be "Which one should we use?", but rather, "How can they be used together to optimize the process improvement and increase organizational maturity?"

About the author
This article was written by David Lipton, a Senior Consultant with Q/P Management Group, Inc.

Copyright 2000-2002. Q/P Management Group, Inc. Proprietary and Confidential. All Rights Reserved