9.1 THINGS TO REMEMBER

---

9.1 THINGS TO REMEMBER

Software Metrics is a large, multidimensional subject. It covers management information, cost estimation and the use of metrics based techniques to improve quality, control complexity and to assist with system management. It is, and in fact must be, applicable to both new, green field developments and to enhancement or maintenance projects including application support. It has links to project control, configuration management and customer relations.

If you consider any standard software development life cycle, you can add an additional, parallel stream to show the relationship to software metrics as shown in Figure 9.1. Notice how information flows to and from the project management process across the interfaces with the development process:

Figure 9.1: Relationships Between a Standard Lifecycle, Software Metrics and Project Management

Notice also that information is communicated between the project management process and the Software Metrics initiative as well as between the Software Metrics initiative and the development process directly. There is also an interface between the customer or system user domain and the measurement program.

The next point to consider is that to attempt to introduce the use of Software Metrics in any kind of ad-hoc way simply will not work. It must be handled as a project in its own right with each of the usual project stages, i.e.:

• Requirements Definition

• Component Design

• Component Build

• Implementation.

One very useful concept that was highlighted by a QA Forum working party report of which I had the pleasure of being party to some years ago, "Implementing a Software Metrics Programme," Irvine (1) , was that of multiple sub-projects within such programs. This simply states that the Requirements Definition stage may identify a number of requirements that the organization wishes the metrics program to address. After these requirements have been identified it is possible to establish a separate sub-project that takes each of these requirements through the design, build and implementation stages. This makes the management of the SMP much easier and allows an organization to concentrate on those areas where it sees a quick return while still directing some effort towards satisfying those requirements that may provide a significant pay-back in the mid to long term.

This idea can be further developed by introducing the idea of "phasing." There are a number of ways that this can be done. I have said that Software Metrics is a big subject area. Normally, there is another element of "bigness" that will affect the program, namely the size of the organization that seeks to apply metrics. Most software engineering organizations or departments consist of a number of project or product teams. Often this number is large. To target all of these at once can make the management of the Software Metrics Program a nightmare.

Phasing can help with this size problem in two ways. First, the software metrics topic itself can be partitioned and these partitions addressed by different phases of the metrics program. Second, the implementation process itself can be phased so that only a manageable number of project teams or work areas are targeted within a particular time slice.

Figure 9.2 illustrates the first type of phasing and shows effort ramping up at different times against different topic areas.

Figure 9.2: Potential Phases of a Software Metrics Program (Not to scale)

The actual partitioning can be considered right at the start of requirements specification, provided an organization is very clear about its business objectives and what areas will give the best short term pay-back. For most organizations, however, the detailed phasing is best left until the end of the Requirements Definition stage.

To summarize, Software Metrics covers many areas and will impinge on the total development process. It can also affect every member of the software development organization. Software Metrics is also a technical subject. Because of this, the introduction of Software Metrics should be treated as a project in its own right. Finally, different types of phasing can help manage the implementation of metrication.

---