Software Configuration Management and ISO 9001

Configuration Management and ISO 9001

Robert Bamford, William J. Deibler II, Software Systems Quality Consulting, www.ssqc.com

Configuration management is about managing change of the multiple items composing an information system. This article puts in reference the configuration management function and the ISO 9001 standard. This standard offers a wide range of advice on how to deal with this important, but often neglected, aspect of software engineering.

The software engineering practices associated with software configuration management (SCM or CM) offer a number of opportunities to address requirements found in the International Standard, ISO 9001. From a management perspective, the principles and practices of CM represent an accepted and understood foundation for implementing ISO-compliant processes in software engineering organizations. In addition, the growing number of tools for automating CM practices is chance for improving the efficiency and effectiveness of these processes.

This article begins with brief, general definitions of configuration management and of ISO 9001.

Configuration Management

While there is no single definition of CM, there are three widely disseminated views from three different sources: the Institute of Electrical and Electronics Engineers (IEEE), The International Organisation for Standardisation (ISO), and the Software Engineering Institute (SEI) at Carnegie Mellon University.

The IEEE perspective on CM

A most widely understood description of the practices associated with configuration management is found in the IEEE Standard 828-1990, Software Configuration Management Plans.

[Numbers in brackets are added]

“SCM activities are traditionally grouped into four functions: [1] configuration identification, [2] configuration control, [3] status accounting, and [4] configuration audits and reviews.”

IEEE Standard 828-1990 goes on to list specific activities associated with each of the four functions (the number of the paragraph containing the reference appears in parentheses):

• Identification:

identify, name, and describe the documented physical
and functional characteristics of the code, specifications, design, and data
elements to be controlled for the project. (Paragraph 2.3.1)


• Control:

request, evaluate, approve or disapprove, and implement
changes (Paragraph 2.3.2)


• Status accounting:

record and report the status of project
configuration items [initial approved version. status of requested changes,
implementation status of approved changes] (Paragraph 2.3.3)


• Audits and reviews:

determine to what extent the actual configuration
item reflects the required physical and functional characteristics (Paragraph
2.3.4)

This list is similar to the set of activities noted by Pressman:

“Software configuration management is an umbrella
activity … developed to (1) identify change, (2) control change, (3) ensure
that change is being properly implemented, and (4) report change to others who
may have an interest.”

The ISO perspective on CM

In the guideline document, ISO 9000-3:1991 Guidelines for
the application of ISO 9001 to the development, supply and maintenance of
software, the International Organisation for Standardisation identifies a
similar set of practices as CM:

“Configuration management provides a mechanism for
identifying, controlling and tracking the versions of each software item. In
many cases earlier versions still in use must also be maintained and controlled.

“The [CM] system should

“a) identify uniquely the versions of each software
item;

“b) identify the versions of each software item which
together constitute a specific version of a complete product;

“c) identity the build status of software products in
development or delivered and installed;

“d) control simultaneous updating of a given software
item by more than one person;

“e) provide coordination for the updating of multiple
products in one or more locations as required;

“f) identify and track all actions and changes resulting
from a change request, from initiation … to release.”

The SEI perspective on CM

Based on a review of currently available tools and an evolving understanding of the organizational role of CM, the SEI advocates a broader definition of CM in SEI-92-TR-8:

“The standard definition for CM taken from IEEE standard
729-1983 [updated as IEEE Std 610.12-1990] includes:

“Identification: identifying the structure of the
product, its components and their type, and making them unique and accessible in
some form

“Control: controlling the release of product and
changes to it throughout the life cycle …

“Status Accounting: recording and reporting the
status of components and change requests, and gathering vital statistics about
components in the product

“Audit and review: validating the completeness of a
product and maintaining consistency among the components …

“[The IEEE] definition of CM … needs to be broadened
to encompass … :

“Manufacturing: managing the construction and
building of the product

“Process management: ensuring the correct execution
of the organization’s procedures, policies, and life-cycle model

“Team work: controlling the work and interactions
between multiple developers on a product.”

ISO 9001

In 1987, the International Organisation for Standardisation
in Geneva Switzerland published ISO 9001, Quality Systems – Model for
quality assurance in design / development, production, installation, and
servicing.

ISO 9001 is the most comprehensive model in the ISO 9000
series of standards. It describes a minimum set of activities found in companies
and organizations that consistently produce products that satisfy customer
requirements. The policies, procedures, standards, records, and associated
business activities are the quality system. While ISO 9001 is written to
describe any company providing any product or service, it tends to employ
manufacturing terminology, which must be interpreted for non-manufacturing
environments, including service and software providers.

To ensure a uniform interpretation of ISO 9001 for software
engineering organizations, ISO published ISO 9000-3, Guidelines for the
Application of ISO 9001 to the development, supply and maintenance of
software.

The key issues ISO 9000-3 addresses are those:

• Product exists earlier in software (during design and development)
• Software product can be proliferated easily

Focusing on these issues mirrors the guidance in Clause 7.4
of ISO 9000-1:1994:

The process of development, supply, and maintenance of
software is different from that of most other types of industrial products in
that there is no distinct manufacturing phase. Software does not “wear
out” and, consequently, quality activities during the design phase are of
paramount importance to the final quality of the product.

Note that ISO 9000-1 and ISO 9000-3 provides guidance. ISO
9001 is the only source of the requirements against which compliance in software
engineering practices is assessed.

ISO 9001 and Configuration Management

Tracing the relationship between ISO 9001’s requirements and
CM practices begins with an examination of the guidance in ISO 9000-3.

ISO 9000-3 and configuration management

ISO 9000-3 contains two appendices, Annex A and Annex B, that
provide cross-references between ISO 9001 and ISO 9000-3. According to Annex A,
five sections of ISO 9001 correlate to ISO 9000-3, Paragraph 6.1, Configuration
Management:

• 4.4 Design control
• 4.5 Document data control
• 4.8 Product identification and traceability
• 4.12 Inspection and test status
• 4.13 Control of nonconforming product

Each of these sections of ISO 9001 contains a portion of the traditional CM process.

4.4 Design control addresses all of the steps in the software development life cycle: planning, specification, design, coding, testing

Section 4.4 requires that design inputs and outputs be documented, reviewed, verified, controlled, approved, and modified according todocumented procedures. Design inputs and outputs include plans(project life cycle definition), specifications, prototypes, requirementsdocuments, progress reports, review results, test plans, test cases/scripts, development tools, code, and test reports.

ISO 9001 4.4.9 Design changes, in conjunction with ISO 9001 4.14.2 Corrective action, and 4.13 Control ofnonconforming product, requires that each change be traceable to an appropriate source and approval.

For software product there should be a clear path between a change request spawned by a fault report or enhancement request and a change ina specific product component to correct the fault or to implement the enhancement.

An interested party should be able to pick up the path at any point and follow it forward to the released change and backward to the changerequest or to the fault report.

4.5 Document and data control addresses the identification, protection, approval, and availability of current issues of allpertinent product- and project-related documents, including designs, specifications, plans, and schedules.

Because a fundamental function of CM is making current configuration items available, the CM practices and tools can be applied to thecontrol of product- and process-related documentation and data.

4.8 Product identification and traceability requires that each version of a configuration item be identified by some appropriate means.

4.12 Inspection and Test Status requires procedures to identify what verification steps and tests have been completed and what resultshave been achieved by the product or product components at each phase in the defined development life cycle.

4.13 Control of Nonconforming Product requires procedures to ensure that untested, defective, or incorrect versions (e.g., down level) ofthe product are not inadvertently used. This paragraph of ISO 9001also requires a procedure to determine the disposition of nonconforming product at all stages.

For software, the bulk of the activity related to non-conforming product is in the correction of faults identified during allphases of development (e.g., during requirements definition, prototyping,integration testing, and beta testing) and after the product has been released (e.g., customer reported faults).

Page 2   Click here to view the complete list of archived articles