Chapter 15

Chapter 15

Product Metrics for Software

CHAPTER OVERVIEW AND COMMENTS

This chapter discusses the use of software measurement and metrics as a means of helping to assess the quality of software engineering work products. Most of the metrics discussed in this chapter are not difficult to compute. Students can be encouraged to compute several of them for them own work products. What will be difficult for students is trying to interpret their meaning, since they will not have any historic data to use in their analyses of the metrics. Discussing case studies based on commercial products may help students to understand the use of metrics in improving the quality of software engineering work products.

15.1  Software Quality

This section defines software quality as conformance to the implicit and explicit requirements associated with a product. This implies the existence of a set of standards used by the developer and customer expectations that a product will work well. Conformance to implicit requirements (e.g. ease of use and reliable performance) is what sets software engineering apart from simply writing programs that work most of the time. Several sets of software quality factors are described.

Be sure to emphasize the McCall triangle (Figure 15.1) during lecture. Although McCall’s work was done almost 30 years ago, quality factors remain the same today. What does that say about quality issues for computer software? They remain invariant even though software technology has changed radically.

Students should be reminded that these factors are used in the qualitative assessment of software quality. The main weakness of this approach, is that it is based on opinion obtained by having customers or developers score products using a questionnaire. Disagreements on qualitative ratings are hard to resolve. In the remainder of this chapter focuses on quantitative approaches to assessing software quality.

15.2  A Framework for Technical Software Metrics

General principles for selecting product measures and metrics are discussed in this section. The generic measurement process activities parallel the scientific method taught in natural science classes (formulation, collection, analysis, interpretation, feedback). A key point to get across to students is that effective measures need to be easy for developers to collect. If the measurement process is too time consuming, no data will ever be collected during the development process. Metrics should be easy to compute or developers will not take the time to compute them. The tricky part is that in addition to being easy compute, the metrics need to be perceived as being important to predicting whether product quality can be improved or not.

The GQM paradigm (Section 15.2.4) should be used whenever someone wants to develop a software metric. To help your students better understand its intent, have them use the GQM approach to create a metric for a product other than software.

15.3  Metrics for the Analysis Model

This section discusses metrics that may be useful in assessing the quality of the requirements analysis model. Students need to understand that it is important to begin assessing product quality long before the first line of code is written. Most managers want the quality effort to be rewarded in the current project, not the next one. The metrics presented in this section are presented in sufficient detail to allow students to compute them for their own projects. It may be interesting to have students compute the same metrics for their term projects before and after implementation. If similar student projects are assigned each semester, it may be worthwhile to collect historic product measures and allow future student development teams to make use of this data to interpret their own metrics.

15.4  Metrics for the Design Model

Representative design model metrics are discussed for architectural design, component-level design, and interface design. Students may benefit from seeing examples of each computed from real design work products. The computations are not too difficult and after seeing some examples students should be able to compute them for their own work products. Design is where measurement is a ‘must.’ Be sure to emphasize that a software engineer should use these metrics as he/she is doing design work.

Section 15.4.2 describes nine measurable characteristics of an OO design. The details of the data that need to be collected and the metrics that can be computed are discussed later in the chapter. Students may benefit from seeing examples of actual measures and metrics computed for each of the nine characteristics.

A variety of different class-oriented, component level, and operation-oriented metrics are discussed in Sections 15.4.3 through 15.4.7. Enough detail is presented to allow student to compute most of these metrics for their own software projects. Students would benefit from seeing how to compute and interpret these metrics for a real OO design (which requires access to some historical project information). A potential project activity might be the development of one or more "tiny tools" to automatically (or semi-automatically) compute the metrics presented in this section.

15.5  Metrics for Source Code

The only source code metrics mentioned in this section are associated with Halstead’s software science. It may be a good idea to show students how to compute them for a real program and then have them compute these for one of their own programs. Again students may benefit from seeing examples of how to use these metrics to improve a developing software product.

15.6  Metrics for Testing

This section discusses the role of metrics in assessing the quality of the tests themselves. The majority of testing metrics focus on the quality of the testing process, not on the test work products. In general, testers rely on analysis, design, and coding metrics to guide the construction and execution of test cases. The point to get across to students is that good test metrics need to either predict the number of tests required at various testing levels or focus on test coverage for particular software components.

Six new metrics  that may be useful in determining the testability of OO systems are described in Section 15.6.2. Students may benefit from seeing how the metrics may be used in measuring the testability of an actual system (in terms of threads, scenarios, and clusters). Ultimately, students will want to find some relationship between these metrics and the number of test cases that need to be generated to test a system.

15.7  Metrics for Maintenance

Students should be reminded that all the metrics discussed in this chapter can be used for both the development and maintenance of existing software. The IEEE software maturity index (SMI) is specifically designed to assist developers in assessing the stability of a product undergoing changes. An example of how to compute SMI for a real product might be helpful to students.