Software Process and Project Metrics: A Comprehensive Overview
Software Process and Project Metrics
Within the context of software project management, there is significant concern about metrics for productivity and quality. These metrics measure the “output” (completion) of software development based on employee time and effort, and also measure the utility of the product.
Measures, Metrics, and Indicators
Although the terms measure, measurement, and metrics are often used interchangeably, it’s important to note the subtle differences between them. Since the terms “measured” and “measurement” can be used as both nouns and verbs, the definitions of these terms can be confusing.
Metric Domains in the Process and Project
Measurement is common in the world of engineering. We measure energy consumption, weight, physical dimensions, temperature, voltage, signal-to-noise ratio—the list is nearly endless. Unfortunately, measurement is much less common in the world of software engineering.
Metrics and Process Improvements in Software Processes
The only way to rationally improve any process is to measure attributes of the process, develop a set of metrics based on these attributes, and then use the metrics to provide indicators that lead to an improvement strategy.
The Failure Analysis Works the Same Way:
- All errors and defects are categorized by origin (e.g., defects in the specification, in logic, not in accordance with standards).
- Both the cost to correct each error and the default are recorded.
- The number of errors and defects in each category are counted and sorted in descending order.
- The total cost of errors and defects in each category is computed.
- The resulting data is analyzed to identify categories that produce the highest cost for the organization.
- Plans are developed to modify the process in an attempt to eliminate (or reduce the frequency of occurrences of) the kinds of errors and defects that are most expensive.
Project Metrics
Software process metrics are used for strategic purposes. Software project metrics are tactical. That is, project metrics and indicators derived from them are used by a project manager and software team to adapt the project workflow and technical activities.
Another model of software project metrics suggests that all projects should be measured in terms of:
- Tickets: The size of resources (e.g., people, environment) required to perform the work.
- Out: Measures of supplies or products created during the software engineering process.
- Results: Measures indicating the effectiveness of delivery.
Software Measurements
Measurements in the physical world can be categorized in two ways: direct measures (e.g., the length of a screw) and indirect measures (e.g., the “quality” of bolts produced, measured by counting defective items). Software metrics can be categorized in a similar way.
Size-Oriented Metrics
Size-oriented software metrics standardize quality and/or productivity measures by considering the “size” of the software produced.
Function-Oriented Metrics
Function-oriented metrics use a function to measure the functionality delivered by the application as a normalization value. Since “functionality” cannot be measured directly, it must be derived indirectly using other direct measures. Function-oriented metrics were first proposed by Albrecht, who suggested a measure based on information domain values.
The values of the information domains are defined as follows:
- Number of user inputs: Counts each user input providing different application-oriented data. Inputs should be distinguished from inquiries, which are counted separately.
- Number of user outputs: Counts each output that provides the user with application-oriented information. In this context, output refers to reports, screens, error messages, etc. Individual data elements within a report are not counted separately.
- Number of user inquiries: An inquiry is defined as an interactive input that results in the generation of some immediate software response in the form of interactive output. Each inquiry is counted separately.
- Number of files: Counts each logical master file (i.e., a logical group of data that may be part of a large database or a separate file).
- Number of external interfaces: Counts all machine-readable interfaces (e.g., data files, tape, or disk) used to transmit information to another system.
Extended Function Point Metrics
The function point measure was originally designed to apply to management information systems applications. To accommodate these applications, the scale emphasized data (the information domain values discussed above) to the exclusion of size and behavioral function. For this reason, the function point measurement was inadequate for many engineering and embedded systems (which emphasize function and control).
The Characteristics of the Three Dimensions:
- The data dimension is evaluated exactly as described in the function-oriented metrics. Data counts (internal data structures of programs, e.g., files) and external data (inputs, outputs, inquiries, and external references) are used along with complexity measures to derive a data dimension count.
- The functional dimension is measured by considering “the number of internal operations required to transform input data into output data.” For purposes of computing the 3D function points, a “transformation” is a series of process steps that are delimited by semantic judgments.
- The control dimension is measured by counting the number of transitions between states. A state represents some externally observable mode of behavior, and a transition occurs as a result of some event that changes the way the system or software behaves (i.e., changes state). For example, a wireless phone contains software that supports auto-dial functions.
Metrics for Software Quality
The primary goal of software engineering is to produce a quality system, application, or product. To achieve this goal, software engineers must implement effective methods with modern tools within the context of a mature software development process.
Quality Measurement
- Correctness: A program should operate correctly or provide little value to its users. Correctness is the degree to which the software performs its required function. The most common measure of correctness is KLDC defects, where a defect is defined as a verified lack of conformance to requirements.
- Maintainability: The software maintenance effort consumes more resources than any other software engineering activity.
- Integrity: In this age of “hackers” and “firewalls,” the integrity of software has become quite important.