About Us


  Process Models

  SE Resources


  Contact us

Breaking News!

A new blog ... visit OnCenter, Roger Pressman's running commentary on the world at large

A new edition ... the 6th edition of Software Engineering is available now

A first novel ... Roger Pressman's first novel is a technothriller -- The Aymara Bridge

A new training curriculum! RSP&A has partnered with QAI to develop a comprehensive Internet-based software engineering curriculum.

A redesigned Web site ... we've done a major redesign and added many new features

Reference Library
Process and Project Metrics

This page provides access to a variety of downloadable papers that address process and project metrics issues. The following topics are considered:

Process Metrics
SPC Metrics Program


A System for Measuring Function Points [PDF]
Evelina Lamma, Paolo Mello and Fabrizio Riguzzi

This paper presents a system for measuring the Function Point software metric from specifications expressed in the form of an Entity Relationship (ER) diagram and a Data Flow Diagram (DFD). As a first step towards the implementation of the system, the informal Function Point counting rules have been translated into rigorous rules expressing properties of the ERDFD. Prolog was chosen for the implementation because of its declarativity and maintainability. Thanks to its relational representation, it was possible to directly represent the input ER-DFD with Prolog facts.

Software Measurement Process - Part #1 - An Introduction [PDF]
Peter Baxter

This article introduces ISO/IEC 15939 software measurement process. Measurement- related actions are listed. The four measurement activities: establish capability, plan measurement, perform the measurement process, and evaluate measurement are illustrated.

Software Metrics [PDF]
Everald E. Mills

This paper discusses commonly used software metrics. This paper also reviews the metrics by constructing models of the software development process.

Software Metrics and Risk [PDF]
Norman Fenton and Martin Neil

Most software metrics activities are carried out for the purposes of risk analysis of some form or another. Yet traditional metrics approaches, such as regression-based models for cost estimation and defects prediction, provide little support for managers wishing to use measurement to analyze and minimize risk. Significant improvements can be achieved by using causal models that require no new metrics. The new approach, using Bayesian nets, provides true decision-support and risk analysis potential.

Software Metrics Capability Evaluation Guide [DOC]
Faye Budlong and Judi Peterson

This guide covers the following: it defines a metrics capability evaluation method that deals specifically with defining a customer's metrics capability, it presents metrics capability questionnaires that help gather metrics capability data, it outlines a metrics capability evaluation report that provides the basis for developing a metrics customer project plan, it provides a metrics customer profile form used to determine the initial information required to prepare for a metrics capability evaluation, and it provides a customer organization information form that helps guide the STSC in gathering cultural information about the organization that will help with developing and implementing the metrics customer project plan.

Back to the top

Process Metrics

A Metrics - Based Study of Software Evolution - Some Results from FEAST/1 [PDF]
M.M. Lehman and J.F. Ramil

This slide presentation on the Feedback Evolution, and Software Technology (FEAST/1) includes the following topics: the FEAST hypothesis, FEAST results, metrics of software evolution-some desired features, implications for the control of software evolution, and metrics in software evolution management.

Beyond the Personal Software Process: Metrics Collection and Analysis for the Differently Disciplined [PDF]
Philip M. Johnson, Hongbing Kou, Joy Agustin, Christopher Chan, Carleton Moore, Jitender Miglani, Shenyan Zhen and William E.J. Doane

Pedagogies such as the Personal Software Process (PSP) shift metrics definition, collection, and analysis from the organizational level to the individual level. The authors research suggests that this "PSP adoption problem" may be due to two problems: the high overhead of PSP-style metrics collection and analysis, and the requirement that PSP users "context switch" between product development and process recording. This paper overviews the authors initial PSP experiences, their first attempt to solve the PSP adoption problem with the LEAP system, and their current approach called Hackystat.

On Building an Effective Measurement System for OO Software Process, Product and Resource Tracking [PDF]
Sita Ramakrishnan, Tim Menzies, M. Hasslinger, P. Bok, H. Mccarthy, B. Devakadadcham and D. Moulder

This paper reports on an ongoing object oriented software measurement experiment which has been set up to monitor and evaluate team-based projects building OO software. The process, called the Software Assessment Through Ongoing Profile Sheets (SATOPS) which relies on manual form entries for recording measurement data in a project management framework is being automated using JAVA. The automated tracking of software process and resource activities will improve the metrics data collection and analysis phase.

Process - Oriented Metrics for Software Architecture Adaptability [PDF]
Lawrence Chung and Nary Subramanian

This paper proposes a framework, POMSAA (Process- Oriented Metrics for Software Architecture Adaptability), which aims to provide numeric scores representing the adaptability of a software architecture as well as the intuitions behind these scores. In this framework, the intuitions behind the architectural adaptability scores are traced back to the "whys" of the architecture, namely, the requirements for which the architecture exists in the first place. POMSAA achieves the needed tracing by adopting the NFR Framework, which is a process-oriented qualitative framework for representing and reasoning about non-functional requirements (NFRs). In this paper the authors show how POMSAA can be used to calculate adaptability metrics for an architecture of a software system, how it helps detect weaknesses and strategic strengths in the architecture, how it helps to understand the reasons for the weaknesses/strengths and how to make improvements (that will help improve the metrics), and how to recalculate the metrics for the new architecture fast and intuitively.

Software Process Improvement: Management Commitment, Measures, and Motivation [PDF]
J.W.E. Greene

This paper on the software process improvement (SPI) begins with an introduction about SPI. Other topics include: measures for process improvement, background to the measures, management measures, the software control office, the development control office, the purchasing control office, meeting the key process areas, U.S. control office experience, and measures and motivation.

Using Process Metrics to Enhance Software Fault Prediction Models [PDF]
Greg Kaszycki

This paper discusses EMERALD which is a software risk assessment tool developed to be used internally at Nortel Networks, but is now commercially available. Process data significance levels were measured to determine the accuracy of the model.

Back to the top

SPC Metrics Program

Creating a Metrics Program
Software Productivity Center Inc.

The Software Productivity Center's 8-step metrics program. All 8 steps and other links can be found on the Software Productivity Center's Metrics Page.

Creating a Metrics Program
Step 1: Document the Software Process [PDF]

Software Productivity Center Inc.

A software development process is simply the procedures that are followed to transform specified requirements into a software product. The objective of this step is to document these procedures so they can be applied consistently across projects. Procedures for documenting the process, actions required for step 1, and an example are given.

Creating a Metrics Program
Step 2: State the Goals [PDF]

Software Productivity Center Inc.

Step 2 is to state the goals of the metrics program. The goals will ultimately determine which data to measure. A table that lists some of the goals that commonly drive metrics programs, actions required for step 2, and an example are given.

Creating a Metrics Program
Step 3: Define Metrics Required to Reach Goals [PDF]

Software Productivity Center Inc.

Step 3 is to choose which software metrics will help achieve the goals of the metric program. This section analyzes each of the eight goals outlined in Step 2. The goals will be converted into a set of metrics by applying the Basili GQM (Goals/Questions/Metrics) model. Actions required for step 3, and an example are given.

Creating a Metrics Program
Step 4: Identify Data to Collect [PDF]

Software Productivity Center Inc.

Step 4 is to identify the data that needs to be collected for each metric selected in the preceding step. In this step, each of the metrics is expanded into a set of raw data to collect. Actions required for step 4, and an example are given.

Creating a Metrics Program
Step 5: Define Data Collection Procedures [PDF]

Software Productivity Center Inc.

Step 5 is to decide where to find the raw data identified in Step 4, and how to collect it. Actions required for step 5 are given.

Creating a Metrics Program
Step 6: Assemble a Metrics Toolset [PDF]

Software Productivity Center Inc.

Step 6 is to identify and configure tools which are necessary to support the metrics program. Each tool is described and an example is given. Actions required for step 6, and an example are given.

Creating a Metrics Program
Step 7: Create a Metrics Database [PDF]

Software Productivity Center Inc.

Step 7 is to define and create the metrics database for the storage and retrieval of the software measurement data. Actions required for step 7 are given.

Creating a Metrics Program
Step 8: Define the Feedback Mechanism [PDF]

Software Productivity Center Inc.

Step 8 is to outline the procedures necessary to enable good internal communication about the metrics data, the program goals, and the changes to the development process. Actions required for step 8, and an example are given.

Back to the top