This edition first published 2018
© 2018 the IEEE Computer Society, Inc.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by law. Advice on how to obtain permission to reuse material from this title is available at http://www.wiley.com/go/permissions.

The rights of Claude Y. Laporte and Alain April to be identified as the authors of this work have been asserted in accordance with law.

Translated by Rosalia Falco.

Registered Office
John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, USA

Editorial Office
111 River Street, Hoboken, NJ 07030, USA

For details of our global editorial offices, customer services, and more information about Wiley products visit us at www.wiley.com.

Wiley also publishes its books in a variety of electronic formats and by print-on-demand. Some content that appears in standard print versions of this book may not be available in other formats.

Limit of Liability/Disclaimer of Warranty
While the publisher and authors have used their best efforts in preparing this work, they make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives, written sales materials or promotional statements for this work. The fact that an organization, website, or product is referred to in this work as a citation and/or potential source of further information does not mean that the publisher and authors endorse the information or services the organization, website, or product may provide or recommendations it may make. This work is sold with the understanding that the publisher is not engaged in rendering professional services. The advice and strategies contained herein may not be suitable for your situation. You should consult with a specialist where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

Library of Congress Cataloging-in-Publication Data

Names: Laporte, Claude Y., author. | April, Alain, author.
Title: Software quality assurance / by Claude Y. Laporte, Alain April.
Description: 1 | Hoboken, NJ : Wiley-IEEE Computer Society, Inc., 2018. |
Includes bibliographical references and index. |
Identifiers: LCCN 2017036440 (print) | LCCN 2017041869 (ebook) | ISBN
9781119312413 (pdf) | ISBN 9781119312420 (epub) | ISBN 9781118501825 (hardback)
Subjects: LCSH: Computer software--Quality control. | Computer software--Quality
control--Standards. | BISAC: TECHNOLOGY & ENGINEERING / Quality Control.
Classification: LCC QA76.76.Q35 (ebook) | LCC QA76.76.Q35 L42 2018 (print) |
DDC 005.3028/7--dc23
LC record available at https://lccn.loc.gov/2017036440

Cover image: ©naqiewei/Gettyimages
Cover design by Wiley

CONTENTS

Preface

Acknowledgments

Chapter 1 Software Quality Fundamentals

1.1 Introduction
1.2 Defining Software Quality
1.3 Software Errors, Defects, and Failures
1.4 Software Quality
1.5 Software Quality Assurance
1.6 Business Models and the Choice of Software Engineering Practices
1.7 Success Factors
1.8 Further Reading
1.9 Exercises

Chapter 2 Quality Culture

2.1 Introduction
2.2 Cost of Quality
2.3 Quality Culture
2.4 The Five Dimensions of a Software Project
2.5 The Software Engineering Code of Ethics
2.6 Success Factors
2.7 Further Reading
2.8 Exercises
Note

Chapter 3 Software Quality Requirements

3.1 Introduction
3.2 Software Quality Models
3.3 Definition of Software Quality Requirements
3.4 Requirement Traceability During the Software Life Cycle
3.5 Software Quality Requirements and the Software Quality Plan
3.6 Success Factors
3.7 Further Reading
3.8 Exercises
Note

Chapter 4 Software Engineering Standards and Models

4.1 Introduction
4.2 Standards, Cost of Quality, and Business Models
4.3 Main Standards for Quality Management
4.4 ISO/IEC/IEEE 12207 Standard
4.5 ISO/IEC/IEEE 15289 Standard for the Description of Information Elements
4.6 IEEE 730 Standard for SQA Processes
4.7 Other Quality Models, Standards, References, and Processes
4.8 Specific Standards for an Application Domain
4.9 Standards and the SQAP
4.10 Success Factors
4.11 Further Reading
4.12 Exercises

Chapter 5 Reviews

5.1 Introduction
5.2 Personal Review and Desk-Check Review
5.3 Standards and Models
5.4 Walk-Through
5.5 Inspection Review
5.6 Project Launch Reviews and Project Assessments
5.7 Agile Meetings
5.8 Measures
5.9 Selecting the Type of Review
5.10 Reviews and Business models
5.11 Software Quality Assurance Plan
5.12 Success Factors
5.13 Tools
5.14 Further Reading
5.15 Exercises

Chapter 6 Software Audits

6.1 Introduction
6.2 Types of Audits
6.3 Audit and Software Problem Resolution According to ISO/IEC/IEEE 12207
6.4 Audit According to the IEEE 1028 Standard
6.5 Audit Process and the ISO 9001 Standard
6.6 Audit According to the CMMI
6.7 Corrective Actions
6.8 Audits for Very Small Entities
6.9 Audit and the SQA Plan
6.10 Presentation of an Audit Case Study
6.11 Success Factors
6.12 Further Reading
6.13 Exercises

Chapter 7 Verification and Validation

7.1 Introduction
7.2 Benefits and Costs of V&V
7.3 V&V Standards and Process Models
7.4 V&V According to ISO/IEC/IEEE 12207
7.5 V&V According to the CMMI Model
7.6 ISO/IEC 29110 and V&V
7.7 Independent V&V
7.8 Traceability
7.9 Validation Phase of Software Development
7.10 Tests
7.11 Checklists
7.12 V&V Techniques
7.13 V&V Plan
7.14 Limitations OF V&V
7.15 V&V in the SQA Plan
7.16 Success Factors
7.17 Further Reading
7.18 Exercises

Chapter 8 Software Configuration Management

8.1 Introduction
8.2 Software Configuration Management
8.3 Benefits of Good Configuration Management
8.4 SCM Activities
8.5 Baselines
8.6 Software Repository and Its Branches
8.7 Configuration Control
8.8 Configuration Status Accounting
8.9 Software Configuration Audit
8.10 Implementing SCM in Very Small Entities with ISO/IEC 29110
8.11 SCM and the SQAP
8.12 Success Factors
8.13 Further Reading
8.14 Exercises

Chapter 9 Policies, Processes, and Procedures

9.1 Introduction
9.2 Policies
9.3 Processes
9.4 Procedures
9.5 Organizational Standards
9.6 Graphical Representation of Processes and Procedures
9.7 Process Notation of ISO/IEC 29110
9.8 Case Study
9.9 Personal Improvement Process
9.10 Policies, Processes, and Procedures in the SQA Plan
9.11 Success Factors
9.12 Further Reading
9.13 Exercises
Note

Chapter 10 Measurement

10.1 Introduction—the Importance of Measurement
10.2 Software Measurement According to ISO/IEC/IEEE 12207
10.3 Measurement According to ISO 9001
10.4 The Practical Software and Systems Measurement Method
10.5 ISO/IEC/IEEE 15939 Standard
10.6 Measurement According to the CMMI Model
10.7 Measurement in Very Small Entities
10.8 The Survey as a Measurement Tool
10.9 Implementing a Measurement Program
10.10 Practical Considerations
10.11 The Human Side of Measurement
10.12 Measurement and the IEEE 730 SQAP
10.13 Success Factors
10.14 Further Reading
10.15 Exercises

Chapter 11 Risk Management

11.1 Introduction
11.2 Risk Management According to Standards and Models
11.3 Practical Considerations for Risk Management
11.4 Risk Management Roles
11.5 Measurement and Risk Management
11.6 Human Factors and Risk Management
11.7 Success Factors
11.8 Conclusion
11.9 Further Reading
11.10 Exercises

Chapter 12 Supplier Management and Agreements

12.1 Introduction
12.2 Supplier Requirements of ISO 9001
12.3 Agreement Processes of ISO 12207
12.4 Supplier Agreement Management According to the CMMI
12.5 Managing Suppliers
12.6 Software Acquisition Life Cycle
12.7 Software Contract Types
12.8 Software Contract Reviews
12.9 Supplier and Acquirer Relationship and the Sqap
12.10 Success Factors
12.11 Further Reading
12.12 Exercises

Chapter 13 Software Quality Assurance Plan

13.1 Introduction
13.2 SQA Planning
13.3 Executing the SQAP
13.4 Conclusion
13.5 Further Reading
13.6 Exercises

Appendix 1 Software Engineering Code of Ethics and Professional Practice (Version 5.2)

Appendix 2 Incidents and Horror Stories Involving Software

Glossary – Abbreviations – Acronyms

References

Index

EULA

List of Tables

Chapter 1

Table 1.1

Chapter 2

Table 2.1
Table 2.2
Table 2.3
Table 2.4
Table 2.5

Chapter 3

Table 3.1
Table 3.2
Table 3.3

Chapter 4

Table 4.1
Table 4.2
Table 4.3
Table 4.4
Table 4.5
Table 4.6
Table 4.7
Table 4.8
Table 4.9
Table 4.10
Table 4.11

Chapter 5

Table 5.1
Table 5.2
Table 5.3
Table 5.4
Table 5.5

Chapter 6

Table 6.1
Table 6.2
Table 6.3

Chapter 7

Table 7.1
Table 7.2
Table 7.3
Table 7.4
Table 7.5
Table 7.6
Table 7.7
Table 7.8
Table 7.9
Table 7.10

Chapter 8

Table 8.1
Table 8.2
Table 8.3
Table 8.4
Table 8.5

Chapter 9

Table 9.1
Table 9.2
Table 9.3
Table 9.4
Table 9.5
Table 9.6
Table 9.7
Table 9.8
Table 9.9
Table 9.10

Chapter 10

Table 10.1
Table 10.2

Chapter 11

Table 11.1
Table 11.2
Table 11.3
Table 11.4
Table 11.5
Table 11.6
Table 11.7
Table 11.8
Table 11.9
Table 11.10
Table 11.11
Table 11.12

Chapter 12

Table 12.1

Chapter 13

Table 13.1
Table 13.2
Table 13.3
Table 13.4
Table 13.5
Table 13.6
Table 13.7

List of Illustrations

Chapter 1

Figure 1.1 Software Quality in the SWEBOK^® Guide [SWE 14].
Figure 1.2 Terminology recommended for describing software problems.
Figure 1.3 Errors, defects, and failures in the software life cycle.
Figure 1.4 Context of software requirements elicitation.
Figure 1.5 Reliability curve for hardware as a function of time.
Figure 1.6 Reliability curve of software. Source: Adapted from Pressman 2014. [PRE 14].

Chapter 2

Figure 2.1 Balance between the software quality level and the cost of quality [GAL 17].
Figure 2.2 Costs of propagating an error¹ [JON 00].
Figure 2.3 Defect injection distribution during the life cycle [SEL 07].
Figure 2.4 Data on software quality costs [HAL 96].
Figure 2.5 Software engineering culture.
Figure 2.6 Start coding… I'll go and see what the client wants!
Figure 2.7 Dilbert is threatened and must provide an estimate on the fly. DILBERT © 2007 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.
Figure 2.8 Dilbert tries to negotiate a change in his project. DILBERT © 2009 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.
Figure 2.9 Diagram of the flexibility of an in-house project.
Figure 2.10 Diagram of the flexibility of a critical software project.

Chapter 3

Figure 3.1 The three perspectives and 11 quality factors of McCall et al. (1977) [MCC 77].
Figure 3.2 Quality factors and criteria from McCall et al. (1977) [MCC 77].
Figure 3.3 Framework for measuring software quality as per the IEEE 1061 [IEE 98b].
Figure 3.4 Quality model for an ISO 25010 software product.
Figure 3.5 Context of software requirements elicitation.
Figure 3.6 Steps suggested for defining non-functional requirements.

Chapter 4

Figure 4.1 A few laws of nature used by some engineering disciplines.
Figure 4.2 The development of standards and models.
Figure 4.3 The evolution of standards SC7 [SUR 17].
Figure 4.4 Elements of a process [ISO 15].
Figure 4.5 The four life cycle process groups of ISO 12207 [ISO 17].
Figure 4.6 The links between requirements and the artifacts of a project [IEE 14].
Figure 4.7 Table of contents of a SQAP according to the IEEE 730 [IEE 14].
Figure 4.8 Structure of the staged representation of the CMMI [SEI 10a].
Figure 4.9 The staged representation of the CMMI^® for Development model.
Figure 4.10 Structure of the S^3m model [APR 08].
Figure 4.11 The main ITIL guides.
Figure 4.12 Processes of ISO 20000 service management system [ISO 11h].
Figure 4.13 Family of ISO 27000 Standards [ISO 05c].
Figure 4.14 Management and implementation processes for the software Basic profile [LAP 16a].
Figure 4.15 Activities for the software Basic profile management process [ISO 11e].
Figure 4.16 Software implementation activities for the Basic profile [ISO 11e].
Figure 4.17 DPs for the software Basic profile [LAP 08].
Figure 4.18 Processes and activities for the Basic profile for the development of systems [ISO 16f].
Figure 4.19 Independence versus SWSIL [CEN 01].

Chapter 5

Figure 5.1 Types of reviews used during the software development cycle [CEG 90] (© 1990 – ALSTOM Transport SA).
Figure 5.2 Objectives of a review.
Figure 5.3 Process of developing a document.
Figure 5.4 Review process.
Figure 5.5 Error detection during the software development life cycle [RAD 02].
Figure 5.6 Personal review process.
Figure 5.7 Desk-check review.
Figure 5.8 Desk-check review activities.
Figure 5.9 Desk-Check review form.
Figure 5.10 Peer reviews as described in the process area “Verification” of the CMMI-DEV.
Figure 5.11 The walk-through review.
Figure 5.12 The inspection process.

Chapter 6

Figure 6.1 Example of a conformity declaration form [ISO 04a]. Source: Standards Council of Canada.
Figure 6.2 Audit process activities according to IEEE 1028.
Figure 6.3 Major steps of a software audit or assessment [APR 08].
Figure 6.4 Example of a problem resolution process.
Figure 6.5 Problem report and resolution proposal form.
Figure 6.6 ISO/IEC 29110 certification approach.

Chapter 7

Figure 7.1 V&V activities in the software development life cycle.
Figure 7.2 A V software life cycle describing when system and software validations are executed.
Figure 7.3 Example of software process phases where defects are injected [SEL 07].
Figure 7.4 Percentage of the defects detected by the development process phase [SEL 07].
Figure 7.5 Relationship between IV&V, supplier, and customer [EAS 96].
Figure 7.6 Validation representation of a process using the ETVX process notation [CEG 90] (© 1990 - ALSTOM Transport SA).
Figure 7.7 Typical table of contents of a validation plan [CEG 90].
Figure 7.8 A software requirements checklist [GIL 93].

Chapter 8

Figure 8.1 CM activities according to CMMI [SEI 00].
Figure 8.2 Example of a directory structure to control configuration with the Subversion CM tool.
Figure 8.3 Example of a project life cycle where planned baselines are indicated.
Figure 8.4 Description of the specifications steps using ETVX notation.
Figure 8.5 Choosing a bad branching strategy.
Figure 8.6 The simplest branching strategy of versions by branch.
Figure 8.7 A typical strategy of development and production branches.
Figure 8.8 Impact of a change request on a software [WIE 13].
Figure 8.9 Change request change management workflow.
Figure 8.10 Example of a status report with the Commit Monitor tool [COL 10].

Chapter 9

Figure 9.1 The SWEBOK^® Guide software engineering process knowledge area [SWE 14].
Figure 9.2 Example of a quality system documentation model.
Figure 9.3 Processes documented for an expert.
Figure 9.4 Control flow graphical notation objects.
Figure 9.5 ETVX notation concept [RAD 85].
Figure 9.6 Illustration of the modified ETVX notation [LAP 97].
Figure 9.7 Template of a textual process description using the ETVX notation.
Figure 9.8 Example of a NASA process graphically represented using the ETVX notation [NAS 04].
Figure 9.9 A NASA template used to explain the ETVX notation [NAS 04].
Figure 9.10 A configuration management process graphically represented using the ETVX notation ETVX [LAP 97].
Figure 9.11 Bombardier Transport software life cycle high level representation [LAP 12].
Figure 9.12 Notation IDEF0 [IEE 98].
Figure 9.13 Three processes of the project planning phase.
Figure 9.14 Planning phase.
Figure 9.15 ETVX representation of step 120.
Figure 9.16 Integration of software engineering to the system engineering process [LAP 97].
Figure 9.17 BPMN list of event types [DEC 08].
Figure 9.18 Example of a provisioning process represented using BPMN notation.
Figure 9.19 PM process diagram of ISO/IEC 29110 [ISO 11e].
Figure 9.20 Four-stage roadmap of ISO/IEC 29110.
Figure 9.21 Effort estimation improvement (adapted from [HUM 00]).
Figure 9.22 Quality improvement (adapted from [HUM 00]).
Figure 9.23 Productivity improvement (adapted from [HUM 00]).

Chapter 10

Figure 10.1 Example of a measure used for decision making [WES 03].
Figure 10.2 Software engineering measurement as proposed by the SWEBOK [SWE 14].
Figure 10.3 Measuring process performance according to ISO 9001 [ISO 15].
Figure 10.4 The three disciplines of quantitative management [PSM 00].
Figure 10.5 Measurement process activities proposed by the PSM [PSM 00].
Figure 10.6 ISO 15939 software measurement process model [ISO 17c].
Figure 10.7 The software measurement process activities and tasks [ISO 17c].
Figure 10.8 Information measurement model [ISO 17c].
Figure 10.9 Example of a measurement construct for productivity [ISO 17c].
Figure 10.10 Examples of information included in a measurement plan [ISO 17c].
Figure 10.11 Components of a software measurement program [DES 95].

Chapter 11

Figure 11.1 Some software project internal and external risk sources.
Figure 11.2 Software projects—many surrounding contexts [CHA 99].
Figure 11.3 Typical expense curve of a project [FOR 05].
Figure 11.4 Risk management in the SWEBOK [SWE 14].
Figure 11.5 ISO 16085 recommended risk management process [ISO 06a].
Figure 11.6 Impact of variables as the project progresses [PMI 13].
Figure 11.7 Risk management activities.
Figure 11.8 A risk documentation template [WIE 98].
Figure 11.9 Grid illustrating risk exposure using three categories.
Figure 11.10 Example of three project risks.

Chapter 12

Figure 12.1 Interpretation of the CMMI-DEV for supplier agreement management [KON 00].
Figure 12.2 Example of a process map describing the RFI-RFQ stage for a software acquisition.
Figure 12.3 Graphical representation of risk sharing contract.

Chapter 13

Figure 13.1 The house of quality for software projects.
Figure 13.2 Example of a software project functional organization chart for a large organization.
Figure 13.3 Example of a workflow explaining the acceptance steps of a project.
Figure 13.4 Example of an acceptance process for a software project.

Preface

This book addresses the global challenge of the improvement of software quality. It seeks to provide an overview of software quality assurance (SQA) practices for customers, managers, auditors, suppliers, and personnel responsible for software projects, development, maintenance, and software services.

In a globally competitive environment, clients and competitors exert a great deal of pressure on organizations. Clients are increasingly demanding and require, among other things, software that is of high quality, low cost, delivered quickly, and with impeccable after-sales support. To meet the demand, quality, and deadlines, the organization must use efficient quality assurance practices for their software activities.

Ensuring software quality is not an easy task. Standards define ways to maximize performance but managers and employees are largely left to themselves to decide how to practically improve the situation. They face several problems:

– increasing pressure to deliver quality products quickly;
– increasing size and complexity of software and of systems;
– increasing requirements to meet national, international, and professional standards;
– subcontracting and outsourcing;
– distributed work teams; and
– ever changing platforms and technologies.

We will focus on the issue of SQA in industry and in public organizations. Industry and public organizations do not have access to a complete and integrated reference (i.e., one book) that can help them with assessing and improving activities specific to SQA. The SQA department must meet service standards for its customers, the technical criteria of the field, and maximize strategic and economic impacts.

The purpose of this book is to enable managers, clients, suppliers, developers, auditors, software maintainers, and SQA personnel to use this information to assess the effectiveness and completeness of their approach to SQA. Some of the issues raised here include:

– What are the processes, practices, and activities of SQA and software improvement?
– Can the current standards and models serve as a reference?
– How do we ensure that managers and their staff understand the value of SQA activities and their implementation?

To answer these questions, we drew upon over 30 years of practical experience in software engineering and SQA in different organizations such as telecom, banking, defense, and transportation. This industry experience has convinced us of the importance of supporting the presentation of concepts and theory with references and practical examples. We have illustrated the correct and effective implementation of numerous quality assurance practices with real case studies throughout the book.

In many organizations, SQA is a synonym for testing. SQA, as presented in this book, covers a large spectrum of proven practices to provide a level of confidence that quality in software development and maintenance activities is independent of the life cycle selected by an organization or a project.

In this book, we will extensively use the term “software quality assurance” and the acronym SQA. As defined in the IEEE Standard for Software Quality Assurance Processes, IEEE 730-2014, a function is a set of resources and activities that achieve a particular purpose [IEE 14]. The SQA function can be executed by a software project team member. It could also be executed by an independent party (e.g., within a quality assurance (QA) department responsible for hardware, software, and supplier quality).

Structure and Organization of this Book

The book is divided into 13 chapters that cover the basic knowledge of SQA as identified, among others, by the IEEE 730 Standard for SQA Processes of the Institute of Electrical and Electronics Engineers (IEEE), the ISO/IEC/IEEE 12207 software life cycle processes standard, the Capability Maturity Model^® Integration for Development (CMMI^®-DEV) developed by the Software Engineering Institute as well as the ISO Guide to the Software Engineering Body of Knowledge (SWEBOK^®). Numerous practical examples are used to illustrate the application of SQA practices.

Chapter 1: Software Quality Fundamentals

This chapter presents an overview of the knowledge required by SQA practitioners. From this overview, the book develops every aspect of the field and cites the important references that deepen each specific topic. We use the concept of business models to explain the significant differences in the selection of SQA practices. In this chapter, we also establish terms and their definitions as well as useful concepts that are used throughout the book.

Chapter 2: Quality Culture

This chapter introduces the concept of cost of quality, followed by practical examples. It also introduces the concept of quality culture and its influence on the SQA practices used. We also present five dimensions of a software project and how these dimensions can be used to identify the degrees of freedom a project manager has to ensure its success. In this chapter, we present an overview of software engineering ethics and the techniques to manage the expectations of managers and customers with respect to software quality.

Chapter 3: Software Quality Requirements

This chapter adds to the concepts and terminology already presented. It deals with software quality models as well as ISO standards on software quality models. These models propose classifications of software quality requirements and steps to define them. Practical examples describe how to use these models to define the quality requirements of a software project. Finally, we introduce the concept of requirements traceability and the importance of quality requirements for the SQA plan.

Chapter 4: Software Engineering Standards and Models

This chapter presents the most important international standards of ISO and models about software quality, such as the CMMI^® developed by the Software Engineering Institute. A new ISO standard for very small organizations is also presented. The SQA practitioner and specialist will find proven practices from standards and models. This chapter provides the framework that can be useful for the following major software activities: (1) development, (2) maintenance, and (3) IT services. Finally, a short discussion on the standards specific to certain domains of application is presented, followed by recommendations for a SQA plan.

Chapter 5: Reviews

This chapter presents different types of software reviews: personal review, the “desk check,” the walk-through, and the inspection. We describe the theory about reviews and then provide practical examples. It introduces reviews in an agile context. Subsequently, we describe other reviews specific to a project: the project launch review and lessons learned review. The chapter concludes with a discussion on the selection of one type of review depending on your business domain and how these techniques fit into the SQA plan.

Chapter 6: Software Audits

This chapter describes the audit process and the software problem resolution process. Sooner or later in the career of a software practitioner, audits will be conducted in a software project. Standards and models describing audits are presented followed by a practical case. The chapter concludes with a discussion of the role of audits in the SQA plan.

Chapter 7: Verification and Validation

This chapter describes the concept of software verification and validation (V&V). It describes its benefits as well as the costs of using V&V practices. Then, the standards and models that impose or describe V&V practices for a project are described. Finally, the description of the contents of a V&V plan is presented.

Chapter 8: Software Configuration Management

This chapter describes an important component of software quality: software configuration management (SCM). The chapter begins by presenting the usefulness of SCM and typical SCM activities. It presents repositories and branching techniques involved in source code management, as well as the concepts of software control, software status, and software audits. Finally, this chapter concludes with a proposal for the implementation of SCM in a small organization and ends with a discussion of the role of SCM in the SQA plan.

Chapter 9: Policies, Processes, and Procedures

This chapter explains how to develop, document, and improve policies, processes, and procedures to ensure the effectiveness and efficiency of the software organization. It explains the importance of documentation presenting a few notations, as examples, to document processes and procedures. The chapter ends by presenting the Personal Software Process (PSP) developed by the Software Engineering Institute to ensure individuals have a disciplined and structured approach to software development that enables them to significantly increase the quality of their software products.

Chapter 10: Measurement

This chapter explains the importance of measurement, standards, and models, and presents a methodology to describe the requirements for a measurement process. It presents how measurement can be used by small organizations and small projects. Then, an approach to implement a measurement program, to detect the potential pitfalls, and the potential impact of human factors, when measuring, is discussed. The chapter concludes with a discussion of the role of measurement in a SQA plan.

Chapter 11: Risk Management

This chapter presents the main models and standards that include requirements for the management of risks. It discusses the risks that may affect the quality of software and techniques to identify, prioritize, document, and mitigate them. It also presents the roles of stakeholders in the risk management process and discusses the human factors to consider in the management of software risks. The chapter concludes with a discussion on the critical role of risk in the development of a SQA plan.

Chapter 12: Supplier Management and Agreements

This chapter deals with the important topic of supplier management and agreements. It discusses the major reviews and recommendations of the CMMI^®. Subsequently, it lists the different types of software agreements and the benefits of the risk sharing agreement are illustrated using a practical example. This chapter concludes with recommendations for the content of the SQA plan when suppliers are involved.

Chapter 13: Software Quality Assurance Plan

This chapter summarizes the topics presented in the whole book by using the concepts presented in each chapter to assemble a comprehensive SQA plan that conforms to the IEEE 730 recommendation. It ends by presenting additional recommendations and practical examples.

Appendices

Appendix 1 – Software Engineering Code of Ethics and Professional Practice (Version 5.2)
Appendix 2 – Incidents and Horror Stories involving Software

Icons Used in the Book

Different icons are used throughout this book to illustrate a concept with a practical example; to focus on a definition; to present an anecdote, a tool, or checklist; or simply to provide a quote or a website. Consult the table below for the meaning of each icon.

Icon	Meaning
	Practical example: An example of the practical application of a theoretical concept
	Quote: A quote from an expert
	Definition: A definition of an important term
	Reference on the Web: An internet site to learn more about a specific topic
	Tools: Examples of tools that support the techniques presented
	Anecdote: A short story of a little known fact, or a curious point on the subject discussed
	Checklist: A list of items to check, or not to be forgotten, during the execution of a presented technique
	Tip: A tip from the authors or from another professional

Website

Supplementary material for teaching as well as for use in organizations (e.g., presentation material, solutions, project descriptions, templates, tools, articles, and links) is available on the website: www.sqabook.org.

Given that international standards are updated on a regular basis, the website will also highlight the latest developments that contribute to SQA practices.

Exercises

Each chapter contains exercises.

Notes

Many software engineering standards from ISO and IEEE have been cited in this book. These standards are updated on a regular basis, typically every five years, to reflect evolving software engineering practices. The accompanying website, www.sqabook.org, contains complementary information as well as the latest developments that impact or contribute to SQA practices described in each chapter and will evolve over time.

Since software engineering standards can be cited in an agreement between a customer and a supplier and add additional legal requirements to the agreement, we have not paraphrased the text of standards in our book, we have directly quoted the text from the standards.

Giancarlo Fortino	Xiaoou Li	Ray Perez
Dmitry Goldgof	Andreas Molisch	Linda Shafer
Don Heirman	Saeid Nahavandi	Mohammad Shahidehpour
Ekram Hossain	Jeffrey Nanzer	Zidong Wang