Software Measurement methodologies

This section describes the most relevant Software Measurement method-ologies. First, it presents the methodology proposed by Grady and Caswell [1987], which was extracted from the first and most extensive implementation of a company-wide software metrics program in Hewlett-Packard. Then, it ex-pounds the methodologies of Goodman [1993] and McAndrews [1993], which are based on other software measurement methodologies.

These methodologies have similar elements and are used to implement soft-ware metric programs in companies. They regard the measurement activity as an activity mainly performed by a single company, and coincide in the fact that such activity is a continuous process.

Grady and Caswell [1987] describe the implementation of a software met-rics program in Hewlett-Packard. They propose the following steps to define and implement metrics in an organization:

To define company/project objectives for the program. The objectives you define will frame the methods you use, the costs you are willing to incur, the urgency of the program, and the level of support you have from your managers.

To assign responsibilities. The organizational location of responsibilities for software metrics and the specific people you recruit to implement your objectives is a signal to the rest of the organization that indicates the importance of the software metrics program.

To do research. Examining data external to the organization in order to get ideas for conducting experiments and set expectations for the results.

To define initial metrics to be collected. You can start with a simple set.

To sell the initial collection of these metrics. The success of a metrics program depends on the accuracy of the data collected, and this accuracy relies on the commitment of the personnel involved and the time required to collect them.

To get tools for automatic data collection and analysis. Such type of tools helps simplify the task of collection, reduce the time expenditure, ensure accuracy and consistency, and reduce psychological barriers to collection.

To establish a training class in software metrics. Training classes help ensure that the objectives for data collection are framed in the context of the company/project objectives. Training is also necessary to achieve the widespread usage of metrics.

To publicize success stories and encourage the exchange of ideas. Making public success stories provides feedback to the people taking measure-ments that confirms that their work is valuable. It also helps spread these successes to other parts of the organization.

To create a metrics database. A database of collected measurements is necessary to evaluate overall organizational trends and effectiveness. Such database also provides valuable feedback concerning whether the metric definitions used are adequate.

To establish a mechanism for changing the standard in an orderly way.

As the organization now understands its development process better, the process and the metrics collected will evolve and mature. For that, there must be a mechanism in place that basically repeats the previous steps.

Grady and Caswell also state that a software metrics program must not have a strategy into itself. Collecting software metrics must not be an isolated goal but a part of an overall strategy for improvement.

Goodman [1993] sets up a framework for developing and implementing software metrics programs within organizations. He defines a generic model tailored to each specific environment. The stages proposed for the model are the following:

Initialisation stage. This stage is caused by some trigger, and driven by an initiator. In this stage the initial scope of the program is defined.

Requirements definition. This stage involves finding out what the various parts of the organization want from a software metrics program. Such stage is concerned with requirements gathering and specification.

Component design. This stage encompasses both the choice of specific metrics and the design of the infrastructure that will support the use of those metrics.

Component build. This stage involves building the components of the software metrics program regarding the requirements and design obtained in the previous stages.

Implementation. This stage involves implementing the components that form the measurement initiative into the organization.

McAndrews [1993] proposes a method for establishing a measurement pro-cess as part of an organization’s overall software propro-cess. The phases proposed for the process are the following:

To identify scope. The measurement process is originated by the need for measurement. It is important to understand this need and the audiences of the process before designing such a process. This phase helps establish the purpose of measurement by identifying the objectives that such mea-surement is to support, the issues involved to meet these objectives, and the measures that provide insight into these issues. The tasks that this phase comprises are related to the identification of

• The needs for measurement.

• The organization’s objectives to be addressed by each measurement need.

• The methods to be used to achieve the objectives.

• The issues that need to be managed, controlled, or observed.

• The precise, quantifiable, and unambiguous measurement goals in which each measurement issue is translated into.

• A list of questions for each goal that, when answered, will determine if the goal is being achieved.

• A list of questions for each goal that, when answered, will determine if the goal is being achieved.

To define procedures. Once measures have been identified, operational definitions and procedures of the measurement process should be con-structed and documented. In this phase, the measures and counting pro-cedures must be defined; in addition, forms or propro-cedures to record the measures must be constructed along with a database or spreadsheet to store the information, measurement report formats, and mechanisms to provide feedback; then analysis methods must be defined, and potential relationships among the measures must be identified.

To collect data. Here data are collected, recorded, and stored, using the operational definition of the measurement procedures. Then, data are validated and the procedures are reviewed for adequacy.

To analyse data. This phase consists in analysing the data required for preparing the reports, presenting the reports to the audience, and review-ing procedures for accuracy and adequacy.

To evolve the process. This phase is used to improve the process and ensure a structured way of incorporating issues and concerns during this process.

This phase also assesses the adequacy of the measurement process itself.

As can be observed, the previous methodologies contain some similar tasks.

Table 2.4 identifies the set of common tasks that these methodologies treat;

these common tasks have been grouped into phases according to the phases used in the methodologies. Table 2.5 shows a comparison of the tasks dealt with in each of these methodologies.

Phase Task

Plan Identify the needs for measurement Define organization objectives Assign responsibilities

Research external products Define Define metrics to collect

Define data collection methods

Table 2.4: Common tasks in Software Measurement methodologies.