To better understand the relationship between the Capability Maturity Model^® Integration^SM (CMMI^SM) and Function Point Analysis (FPA), it is necessary to review the CMMI project. Readers already familiar with the CMMI can skip forward to the next section, "What are Function Points?"

The CMMI project began in 1998 as a collaborative effort of industry, government, and the Software Engineering Institute (SEI) to merge various SEI models [1]:

• Software Capability Maturity Model^® (SW-CMM).
• Systems Engineering Capability Maturity Model (SE-CMM) (Systems Engineering published by Enterprise Process Improvement Collaboration: EPIC).
• The Systems Engineering Capability Appraisal Model (SECAM) (Published by International Council on Systems Engineering: INCOSE).
• Systems Engineering Capability Model (SECM) is the collaborative model of the SE-CMM and SECAM (EIA/IS-731).

The current CMMI is similar to its predecessor models in a number of ways. For example, the CMMI V1.02 Integration Systems/Software Engineering model has retained the five maturity levels of the SW-CMM and a set of corresponding process areas (formerly known as key process areas or KPAs) in the SW-CMM.

Organizations appraised at Level 1 are characterized as simply "performing" software processes and do so in a manner that is often ad hoc or chaotic. The competence and heroics of the individuals doing the work drive how the activities are performed at this level. This first level in the CMMI model is the most common for development organizations embarking on process improvement initiatives. Processes defined at Level 1 are fundamental to software development.

(Formerly called Repeatable in the SW-CMM) A Level 2 organization is more rigorous in both how it performs software processes and in the processes it performs.

At level 2, processes are managed: That is, they are planned, performed, monitored, and controlled for individual projects and groups, or they are standalone processes to achieve a given purpose. At level 2, managing the process achieves both the specific goals for the process area, as well as meets other goals such as cost, schedule, and quality.

A Level 3 organization actually defines its processes and tailors them based on the organization's set of standard processes. Deviations beyond those allowed by the tailoring guidelines are documented, justified, reviewed, and approved.

(Formerly called Managed in the SW-CMM) At Level 4, processes are controlled using statistical and other quantitative techniques. Quantitative objectives for product quality, service quality, and process performance are established and used as criteria in managing processes. Product quality, service quality, and process performance are understood in statistical terms and are managed throughout the life of processes.

At Level 5, processes are continually improved based on an understanding of the common causes of variation inherent in processes. The CMMI SE/SW model identifies a consolidated set of process areas across the five levels. These will be discussed in further detail in the sections that follow.

Function points (FP) are a technically independent measure that quantifies the size of functional user requirements of software. The function point counting method used to calculate the number of function points is known as the International Function Point Users Group (IFPUG) function point method [2]. In its Counting Practices Manual release 4.1, IFPUG identifies the following objectives for function point counting:

• To measure the functionality the user requests and receives.
• To measure independently of implementation technology.
• To provide a normalization factor for software measurement.

IFPUG provides the following standard definitions in their FP Counting Practices Manual release 4.1 (1999):

"Function point (FP). A measure, which represents the functional size of application software."

"Function point analysis. A standard method for measuring software development and maintenance from the customer's point of view."

The question remains "Where is the link between measurements, the CMMI's process maturity, and FP?" The SEI's CMMI SE/SW Model 1.02 presents a standard set of software processes to be satisfied before an organization can be appraised at a particular capability maturity level. Measurement, if used appropriately, can be a facilitator that can enable companies to move ahead and complete many of these process areas.

Measurement should encourage process repeatability: It is exactly the place where process maturity and FP coalesce to bring productive and positive bottom line results. The FPA counting process mirrors structured peer review to solidify "and" quantify the functional user requirements. As such, there are processes in the CMMI that could be supported by the process of documenting the logical functions counted with FPs, while other areas can be supported by the FP measure itself. In the latter case, the numbers and ratios based on the FP measure can be the most significant factor in achieving the process area. (See "Applying Function Point Analysis to Requirements Completeness" by Carol Dekkers and Mauricio Aguiar in Feb. 2001 CrossTalk.)

While a picture can paint a thousand words, examples also provide illumination better than words. For example, in CMMI Level 2: Managed, the following Level 2 process areas (PAs) could be supported through FP based measurement:
1. Requirements Management PA:

• Measurements can be made to assess the status of requirements -- are they reviewed or accepted or rejected?
• The amount of change activity can be captured -- compare and quantify the FP size of change requests.

• Estimates for size of software work products (using FP) or changes must be derived according to documented procedure.

In 1998, Ken Dymond stated in his article Using and Implementing the CMM, "Many Level 1 companies fail to reach Level 2 ... Lack of measurement to aid project planning, tracking and oversight, and requirements management. One of the most often missed measures is that of the size of various tasks/products to be performed/produced."

For the past three years, authors and leading experts have recognized the importance of software sizing in the CMM models. FP "size" addresses and quantifies software size objectively from a logical (user) point of view, independent of implementation, and is a valid sizing measure to use in conjunction with the CMMI.

As an organization evolves to higher CMMI levels, its usage of FP-based measurements generally also evolves. This does not refer to the evolution of the function point methodology per se, but rather to how the organization leverages their FP counting process and makes use of their FP data and resultant measurements.

As briefly described in the previous section, FP can be used in almost all process areas of the CMMI, either as a part of a FP-based measurement, or the FPA process itself can be used to enhance the process area.

It is important to determine what FPbased measurements are appropriate for the current level (and capability) of your organization, as well as goals. As a case in point, trying to implement Level 4 types of software measurement based on FP may be impossible, or at least frustrating, to do in an organization appraised as Level 1.

A good method for determining what measurements make sense for your organization at its current maturity is the Goal-Question-Metric (GQM)-approach. GQM provides that the goals of your organization and your measurement program be outlined first, before determining which questions need to be answered (to meet the goals), and which measures will answer the questions.

This is similar to determining requirements before building software -- GQM sets up the requirements (goals) first, before setting the measurement details (the questions and metrics). Briefly, without getting into the depths of GQM, it is sufficient to say that goals must be
SMART:

S - Strategic

M - Measurable

A - Achievable

R - Realistic

T - Targeted
(Note-These may be different than other uses of the SMART acronym.)

Ensuring that you have SMART goals before you decide on the questions and metrics to reach those goals will assist you to align your measurements with your own organizational capability (realistic, achievable).

This section illustrates what measurements and measurement processes can be used effectively at each level of the CMMI. If the FP process supports the process area, a "+" is indicated. Otherwise, it is the FP measure that supports the process area.

A maturity Level 1 is typically ad hoc and chaotic. For example, sample system measurements for Level 1 are "size of applications in FP." Sample software project measurements for Level 1 are "size of projects in FP."

These Level 2 PA support the inclusion of FP-based measurement:

• Requirements Management -- Use FP to quantify the size of the functional requirements.
• Project Planning -- Use FP to estimate effort and cost.
• Project Monitoring and Control -- Use FP to keep track of scope changes, percent complete, etc.
• Supplier Agreement Management -- Use FP to define size of requirements (application/project being outsourced) and for monitoring supplier's progress, evaluating alternatives for outsourcing, and writing service level agreements.
• Measurement and Analysis -- Collecting FP data, reporting data to managers/project managers, and understanding how FP can/cannot be used.
• Process and Product Quality Assurance -- Use FP to track defects.
• Configuration Management -- Use FP to track changes to requirements and to measure impact to project size.

• Portfolio Size and Growth Trends -- Percent increase/change of FPs from one date to another.
• Age of Applications -- Percent of applications or percent of FPs older than five years, etc.
• Application Support Rates for Individual Applications -- Number of FP per resource.
• FP by Language, Platform -- Percent of FP Mainframe Cobol, etc.
• Application Churning -- Number of change requests and FP size.

• Delivery Rates/Duration Delivery Rates -- FP/hour or FP/month.
• Productivity -- Hours per FP.
• Stability Ratio, Scope Creep/Requirements Volatility -- Percent FP added, changed, deleted.
• Project Cost per FP -- Dollars per FP.
• Defect Ratio -- Defects per FP.
• Testing Proficiency Ratios -- Percent defects found pre-delivery/total defects (up to one month post-delivery) per FP.

These Level 3 PAs support the inclusion of FP-based measurement:

• Requirements Development -- FP analysis process serves as a design walk-through of requirements.
• Technical Solution -- Review FPA for design issues and for documenting interfaces and project documentation.
• Product Integration -- Use FP to measure interface with other applications.
• Verification -- Update FPs based on verification process.
• Validation -- Track defect data and use FP as denominator.
• Organizational Process Focus+ -- Include FPA as a standard organizational process.
• Organizational Process Definition+ -- Include FP as part of the organizational measurement repository.
• Organizational Training -- n/a.
• Integrated Project Management -- n/a.
• Risk Management+ -- Using FP to measure the size of the application will enable assessing risk changes when the size changes.
• Decision Analysis and Resolution+ -- Using FP to assist in decision-making, i.e., impact of scope changes on schedule, extend schedule, increase resources, renegotiate scope, etc.

• Application Support Rates for Organization -- FPs per month.
• Support Activity Trends -- Number of FPs per person over time.
• Application Maintenance Load per Person -- FPs per person.
• Application Maintenance Cost per FP -- Dollars per FP.
• Mean Time to Repair -- Using FP to normalize based on application size.

• Delivery Rates by Type of Project (development, enhancement, maintenance, language, platform, etc.) -- Hours per FP.
• Duration Delivery Rates by Type of Project (elapsed duration) -- FPs per month or hours per FP.
• Trending of Delivery Rates -- FPs per month or hours per FP over time.
• Testing Proficiency Ratios for Organization -- Percent defects found pre-delivery/total defects (up to 1 month post-delivery) per FP.
• Scope Creep/Requirements Volatility -- Comparisons between projects, percent of change measured with FPs.
• Defect Density -- Defects per FP.

These Level 4 PAs support the inclusion of FP-based measurement:

• Organizational Process Performance -- Use FP as one of the measures for establishing performance baselines for processes.
• Quantitative Project Management -- Use FP as the common denominator for selecting measures and statistical control of products and quality.

• Enterprise Productivity Rates -- Total FP/ total information systems work effort.
• Enterprise Quality Rates -- Defects per FP compiled for the enterprise.
• Enterprise Cost Per FP -- Dollars per FP compiled for the enterprise.
• Mean Time to Failure -- Elapsed time/number of failures, normalized by FP.
• Mean Time to Repair -- Elapsed time/number of failures, normalized by FP.

• Enterprise Project Delivery Rates -- Hours per FP compiled for all projects.
• Enterprise Quality Rates -- Defects per FP compiled for all projects.
• Enterprise Cost Per FP -- Dollars per FP compiled for all projects.
• Statistical Process Control of Project Delivery Rates Trend Analysis of Projects -- Using FP to normalize.

These Level 5 PAs support the inclusion of FP-based measurement:

• Causal Analysis and Resolution -- Analyzing defect data using FP as the common denominator enables comparisons between projects; allows evaluating impact of changes by using FP as the common denominator.
• Organizational Innovation and Deployment -- Use FP as a measure for establishing process improvement objectives.

• Repair Cost Ratio.
• Defect Density -- Defects/FP.
• Cumulative Defects.
• Defect Distribution by Severity.
• Defects by Cause.
• Mean Time Between Defects.
• Application Support Rate Trends After Process Improvements.

• Defect Detection Ratio (by phase found). Also known as inspection effectiveness.
• Defect Removal Efficiency.
• Defect Distribution by Severity.
• Defects by Cause.
• Delivery Rate Trends After Process Improvements.
• Statistical Process Control of Defect Data.
• Cost of Defect Removal by Inspection Phase.
• SPC of Process Information.
• Post Release Defect Stability (by month).
• Software Quality -- Post-Release Defect Density.

In order to fully exploit and leverage the FPA benefits (the process of measuring "and" the measure) in a CMMI or process improvement environment, it is critical that you know what level your organization is. Understanding the capability maturity level of your organization will greatly assist you and your organization in establishing SMART goals, and applying appropriate FP-based measurements based on GQM priorities.

1. Software Engineering Institute, www.sei.cmu.edu/sema/welcome.html, www.sei.cmu.edu/cmmi.html for CMMI, and www.sei.cmu.edu/activities/cmm/acronyms.html for acronyms.
2. International Function Point Users Group, www.ifpug.org.
3. Quality Plus Technologies, Inc., www.qualityplustech.com. Free articles on function points, software measurement, cultural issues, secrets of highly successful measurement programs, use cases, etc.
4. Software Technology Support Center. CrossTalk, July 2000, www.stsc.hill.af.mil/crosstalk/2000/07/.

1. The word "user" in the context of function point analysis refers to any person, thing, outside department, or other application that specifies the requirements for the software, or that has requirements to interact with the software. For a concise and non-technical discussion of a variety of terms with specific, non-traditional information technology meanings in function points, refer to Demystifying Function Points -- Clarifying Common Terminology by Carol Dekkers, March 2001 available from Quality Plus Technologies, Inc. at www.qualityplustech.com.

Carol Dekkers, certified management consultant and certified function point specialist, is president of Quality Plus Technologies and is a recognized expert in the area of functional size measurement (Function Point Analysis). She represents the United States to the International Organization for Standardization as a project editor of their functional domain standard. The American Society for Quality (ASQ) honored Dekkers in 2000 as one of the 21 New Voices of Quality for the 21st century. Dekkers is the vice chair of the Project Management Institute's Metrics Specific Interest Group, the past-president of the International Function Point Users Group, and a regional counselor for the ASQ Software Division. Dekkers is a frequent presenter at industry conferences, an author, and a weekly talk-radio host.

8430 Egret Lane
Seminole, FL 33776
Phone: (727)393-6048
Fax: (727)393-8732
E-mail: dekkers@qualityplustech.com

Barbara Emmons is a certified function point specialist with Quality Plus Technologies, Inc. She is a member of the International Function Point Users Group and currently serves on the Management Reporting Committee. She has more than 15 years of experience in information technology, over half of that in quality assurance or software measurement roles. In addition to consulting with companies to achieve software measurement and process improvement success, Emmons saw the successful integration of function points and the Capability Maturity Model^® as the lead analyst at a prominent state government agency.

8430 Egret Lane
Seminole, FL 33776
Phone: (360)402-0163
E-mail: beemmons@qualityplustech.com

© Copyright 2001 Barbara Emmons and Carol Dekkers, Quality Plus Technologies, Inc. All rights reserved.