IEEE/EIA (1997b) “IEEE/EIA Std 12207.1-1997 – IEEE/EIA Guide – Industry Project Implementation of International Standard ISO/IEC 12207:1995 – Software Life

20 6. IEEE/EIA (1997b) “IEEE/EIA Std 12207.1-1997 – IEEE/EIA Guide – Industry Project Implementation of International Standard ISO/IEC 12207:1995 – Software Life

Cycle Processes – Implementation Considerations”, in IEEE Software Engineering Standards Collection, The Institute of Electrical and Electronics Engineers, New York.

progres

7. ISO (1997) ISO 9000-3:1997(E), Quality Management and Quality Assurance Standards – Part 3: Guidelines for the Application of ISO 9001:1994 to the Development, Supply, Installation and Maintenance of Computer Software, 2nd

s edn, International Organization for Standardization (ISO), Geneva, paragraph 4.16.

8. contro ISO/IEC (2001) “ISO 9000-3:2001 Software and System Engineering –

Guidelines for the Application of ISO 9001:2000 to Software, Final draft”, International Organization for Standardization (ISO), Geneva, unpublished

draft, December 2001, paragraph 4.2. 9. Jones, C. (1994) Assessment and Control of Software Risks, Yourdon Press, Prentice Hall, Upper Saddle River, NJ.

Review questions

20.1 The introduction of the chapter presents three examples of situations that can cause managerial failure in the control of a software development project.

(1) What measures could management have taken to prevent each of these adverse situations? (2) Which of these adverse situations could have been detected by audits of project progress control procedures?

20.2 In April, the project progress control system identified an unexpected delay of three months in the project’s delivery date (originally planned for October), caus- ing that date to be postponed to the following January.

(1) List your proposed interventions in this situation, including the assumptions underlying each proposal. (2) Would you alter your proposals if the project were an internal project for development of a computer game software package scheduled for the pre- Christmas market?

20.3 A project progress control process has been planned to involve two levels: (1) Management of the Development Department, which regularly operates six to eight software development teams, and (2) Management of the Software Development Division, which covers three software development departments.

Consider the case of a standard one-year software development project. (1) Inform the project leader of your suggestions for the proper progress

reporting frequencies and conditions for immediate reporting to depart- mental management.

(2) Inform the departmental manager of your suggestions for the proper progress reporting frequencies and conditions for immediate reporting to

(3) What type of progress-related information would you recommend be report-

ed to divisional management?

Topic Topic for discussion

for di

20.1 The “Golden Bridge” software development project was scheduled to be com- pleted in about 12 months. Two to six team members were planned to work on

sc u

the project. Project progress control was based on a monthly report that would

ss

refer to each of the 32 activities to be performed and to the components (1) risk

ion

item management, (2) timetable, and (3) project’s human resources utilization.

The first three monthly progress reports submitted to management did not indicate any deviation from the plan. The fourth progress report presented a sub- stantial overrun in terms of human resources utilization (overtime, etc.) as well as

a one-month delay in the expected completion dates for some of the activities. (1) Can you suggest possible reasons for the relatively late detection of the devi-

ations from the plan? (2) For each of the above three components, describe the measures that could have prevented deviations and their adverse effects. (3) Suggest some interventions that management could have introduced to

compensate for the project’s failures, including the assumptions behind each intervention.

Chapter 21

Software quality metrics

Chapter outline

21.1 Objectives of quality measurement 414

21.2 Classification of software quality metrics 415

21.3 Process metrics 416

21.3.1 Software process quality metrics 416

21.3.2 Software process timetable metrics 420

21.3.3 Error removal efficiency metrics 420

21.3.4 Software process productivity metrics 420

21.4 Product metrics 420

21.4.1 HD quality metrics measures 422

21.4.2 HD productivity and effectiveness metrics 424

21.4.3 Corrective maintenance quality metrics 424

21.4.4 Software corrective maintenance productivity

and effectiveness metrics 426

21.5 Implementation of software quality metrics 427

21.5.1 Definition of new software quality metrics 428

21.5.2 Application of the metrics — managerial aspects 428

21.5.3 Statistical analysis of metrics data 430

21.5.4 Taking action in response to metrics analysis results 432

21.6 Limitations of software metrics 432 Summary

434 Selected bibliography

436 Review questions

438 Topics for discussion

440 Appendix 21A: The function point method

442 21A.1: Introduction

442 21A.2: The function point method

443 21A.3: Example – the Attend-Master software system

445 21A.4: Function point advantages and disadvantages

“You can’t control what you can’t measure” 413 Tom DeMarco (1982)

Softw

Tom DeMarco’s statement has become the motto for software quality experts trying to develop and apply quality metrics in the software industry.

are quality

Two alternative but complementary definitions (IEEE, 1990) describe quality metrics as a category of SQA tools:

(1) A quantitative measure of the degree to which an item possesses a given quality attribute.

metric

(2) A function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the soft-

ware possesses a given quality attribute. That is, the second definition refers to the process that produces quality met-

rics whereas the first refers to the outcome of the above process. It is commonly believed that quality metrics should be included in soft- ware, as in other industries, among the fundamental tools employed to assist management in three basic areas: control of software development projects and software maintenance, support of decision taking, and initia- tion of corrective actions. Statistical analysis of metrics data is expected to pinpoint (descriptively and statistically significant) changes initiated as a result of application of new development tools, changed procedures, and other interventions.

The scope of software quality metrics (hereinafter “metrics”) has expanded considerably over the past few decades. We will review some of those most pertinent software development and maintenance issues at the heart of this chapter. Metrics as a quality assurance tool has not, unfortu- nately, been applied at an adequate level in the software industry. Nor have they provided benefits at the anticipated levels. Only a small portion of soft- ware development organizations apply software quality metrics systematically, and few of these report successful use of the results of their efforts. Some of the reasons for this situation and prospects for the future are discussed in the last part of the chapter.

Experience with metrics in the field has not threatened its potential sig- nificance, attested to by the ISO 9000-3 standard (see ISO/IEC (1997) Sec.

4.20 and ISO (2001) Sec. 8). Software quality metrics are also an important part of the CMM guidelines (see Paulk et al., 1995). Several books, chapters in books, and numerous journal as well as con- ference papers have been dedicated to this subject. Some are listed in the bibliography at the end of this chapter. In addition, IEEE offers some soft- ware quality metrics criteria within its software engineering standards (IEEE 1988, 1998). A comprehensive discussion of metrics for software reuse,

414 After completing this chapter, you will be able to:

21 ■ Explain the objectives of software quality metrics. Softw

List the requirements to be fulfilled by successful software quality metrics.

Explain how software quality metrics are categorized.

Compare the KLOC and function point measures for the size of a soft-

are quality

ware system.

Describe the process of defining a new software quality metrics.

Explain the reasons for limitations characterizing some software quality metrics.

metric