ISO 9000 for Software

This document has been excerpted from hardcopy workbook for Component 9 -- "ISO 9000 Software Development" of Essential Software Engineering, a video curriculum developed by R.S. Pressman & Associates, Inc. Much of the text was written by Dr. Michael Stovsky, an expert in ISO 90000 issues. Reproduced with permission of R.S. Pressman & Associates, Inc.

The ISO 9000 Standards

ISO 9000 is a set of standards for quality assurance systems. The standards were developed by the International Organization for Standardization (ISO). First published in 1987, the standards were revised in 1994. They provide a foundation for organizations to develop or improve their quality assurance systems.

The following excerpt, adapted from Dr. Stovsky’s white paper, What Every Executive Should Know about ISO 9000, describes the background and philosophy of the ISO system.

Background

A quality assurance system may be defined as the organizational structure, responsibilities, procedures, processes, and resources for implementing quality management. [1] Quality assurance systems are created to help organizations ensure their products and services satisfy customer expectations by meeting their specifications. These systems cover a wide variety of activities encompassing a product’s entire life cycle including planning, controlling, measuring, testing and reporting, and improving quality levels throughout the development and manufacturing process.

Quality assurance is a management function consisting of auditing and reporting activities. These quality assurance functions help management determine the effectiveness of the quality system. ISO 9000 describes quality assurance elements in generic terms that can be applied to any business regardless of the products or services offered.

Adoption of the Standards

The standards have been adopted by over 60 countries including all members of the European Community, Canada, Mexico, the United States, Australia, New Zealand, and the Pacific Rim. Countries in Latin and South America have recently shown interest in the standards.

On February 14, 1994, the U.S. Department of Defense (DoD) announced in a press release that it will accept ISO registration "in place of the current military-unique quality standards, MIL-I-45208A, Inspection System Requirements, and MIL-Q-9858A, Quality Program Requirements. Contractors seeking to do business with the DoD may continue to utilize quality standards that satisfy DoD acquisition needs whether they are modeled on military, commercial, national, or international quality standards."[2]

After adopting the standards, a country typically permits only ISO registered companies to supply goods and services to government agencies and public utilities. Telecommunications equipment and medical devices are examples of product categories that must be supplied by ISO registered companies. In turn, manufacturers of these products often require their suppliers to become registered. Private companies such as automobile and computer manufacturers frequently require their suppliers to be ISO registered as well. In the United States, General Motors, Ford, Chrysler, and several truck companies have developed QS 9000 [3], an automotive specific variant of ISO 9000. These companies have notified their suppliers that they must register to QS 9000 within the next few years.

To become registered to one of the quality assurance system models contained in ISO 9000, a company’s quality system and operations are scrutinized by third party auditors for compliance to the standard and for effective operation. Upon successful registration, a company is issued a certificate from a registration body represented by the auditors. Semi-annual surveillance audits ensure continued compliance to the standard.

The ISO Approach to Quality Assurance Systems

The ISO 9000 quality assurance models treat an enterprise as a network of interconnected processes. For a quality system to be ISO-compliant, these processes must address the areas identified in the standard and must be documented and practiced as described. Documenting a process helps an organization understand, control, and improve it. It is the opportunity to understand, control, and improve the process network that offers, perhaps, the greatest benefit to organizations that design and implement ISO-compliant quality systems.

ISO 9000 describes the elements of a quality assurance system in general terms. These elements include the organizational structure, procedures, processes, and resources needed to implement quality planning, quality control, quality assurance, and quality improvement. However, ISO 9000 does not describe how an organization should implement these quality system elements. Consequently, the challenge lies in designing and implementing a quality assurance system that meets the standard and fits the company’s products, services, and culture.

[1] ANSI/ASQC A3-1987, Quality Systems Terminology, 1987.

[2] "DoD Removes Barriers to Use of ISO 9000/Q90 Quality Standards," in On Q, ASQC’s Journal of Record, Vol. IX, No. 5, pp. 9, May 1994.

[3] Quality System Requirements QS-9000, Chrylser Corp., Ford Motor Co., General Motors Corp, August, 1994. r

 

ISO 9000-3 Guidelines

In this section, we’ll look at ISO 9000-3, Guidelines for the Application of ISO 9001 to the Development, Supply, and Maintenance of Software. This document was written to help software development organizations create quality assurance systems that are compliant with ISO 9001. We’ll introduce the quality assurance system model suggested in 9000-3. As we look more closely at 9000-3, we’ll look at the goal of each section. In addition, we’ll identify areas of concern a software development group’s quality system should address to cover 9001’s requirements.

ISO 9001 was not written with software in mind. And because of the peculiar nature of the product that we (software developers) build, a few extra words of explanation and interpretation are warranted. Hence, ISO 9000-3.

The following excerpt, adapted from Dr. Stovsky’s white paper, "The ISO 9000 Approach to Quality Systems for Software Development," explains the rationale for creating 9000-3, describes its relationship to ISO 9001, and provides an overview of the 9000-3 model.

The Software Development Challenge

ISO 9001 was designed to be a generic standard, applicable to any business. As a result, it may be difficult to interpret the twenty requirements for a specific industry. In addition, 9001 has a "manufacturing" focus. That is, it contains an unstated assumption that the primary challenge faced by companies using the standard is to minimize variation in production processes so they may produce dozens, if not hundreds or thousands, of identical (or nearly so) items.

On the other hand, research and development organizations focus on design, where product design and development represent the major activities, as opposed to product reproduction. (Of course, designing products for manufacturability may be an important aspect of product design.) While the goal of the quality assurance systems for manufacturing organizations and research and development groups are similar–minimizing variation–the challenges faced when crafting an appropriate quality assurance system differ due to the nature of activities conducted in each type of organization. Computer software development has unique characteristics within research and development and engineering disciplines, further challenging the design of ISO-complaint quality assurance systems.

These software-specific differences include the intangible nature of the software product, potential complexity of the software, potential complexity in the interaction among software subsystems and software—hardware subsystems, and a unique product life cycle. To help address the additional challenges faced by software development organizations, ISO developed 9000-3, a guidance document designed to assist software development organizations seeking to create ISO-compliant quality assurance systems.

Computer software’s ethereal nature creates challenges in project management and tracking. The inherent complexity of many software products creates design challenges as well as testing problems. It may be difficult to assess the "goodness" of a design. In addition, because of the huge number of possible execution thread permutations, testing a software product adequately may prove troublesome. Furthermore, because software products never wear out, their persistence can create configuration, maintenance, and support problems not encountered by other types of products.

The Role of ISO 9000-3

Because it is a guidance document, 9000-3 is not an auditable standard. Rather, it includes areas of concern that, when addressed by a software development organization, fulfill 9001’s requirements. As a result, auditor’s cannot issue non-conformances against the paragraphs in 9000-3. ISO 9001 remains the quality system standard–9000-3 simply represents one model for complying with the standard.

The quality assurance system model contained in 9000-3 is essentially a management model and, therefore, is technology-independent. As a result, it may be used as is regardless of the technology used in the development environment or the product hardware and software.

ISO 9000-3 provides insight into the scope of activities covered by the ISO 9001 model. It states that software is independent of the medium on which it is recorded. Consequently, 9000-3 may be applied to "hardware" development activities including firmware, gate arrays, programmed logic arrays, silicon compilers, and hardware description languages. In addition, software products include all documentation and data that are delivered to a user. So the creation of user manuals and other customer documentation is covered by 9000-3 as well. This broad definition of software conforms with the definition of the "software configuration" presented in [SEPA, 5/e, Chapter 9].

Unfortunately, the authors of 9000-3 did not organize the document so the presentation order and paragraph numbering mirrors that of 9001. Consequently, it may be difficult to relate directly paragraphs in 9000-3 to corresponding paragraphs in 9001. 9000-3 contains two annexes to help identify related clauses. However, reading both documents several times is essential to understanding how the guidance in 9000-3 relates to 9001’s requirements.

The text of 9000-3 includes complete paragraphs from 9001. These paragraphs may be identified by the typeface used–they appear in italics, followed by a reference to the paragraph in 9001 from which the text was taken.

As you read 9000-3 you’ll see references to specific documents such as quality plans, development plans, test plans, etc. These document names are used to suggest the nature of their contents–no specific documentation scheme is suggested. There is no requirement that your organization produce documents with these exact names or organization. As long as the topics contained in the suggested documents appear somewhere in your documentation scheme, your should not encounter a problem. For example, many organizations combine project plans, quality plans, and development plans into a single document.

Unfortunately, 9000-3 has not yet been updated to account for the 1994 revision of 9001. While the changes to 9001 were minimal, the 1994 standard represents the current set of quality assurance system requirements. If you’re in doubt as to the precise nature of a requirement, always check with the most up-to-date version of 9001.

ISO 9000-3 Model

ISO 9000-3 divides the elements of its quality system model into three parts: a framework, the supporting structures, and the life cycle activities. The terminology of 9000-3 is software development-oriented, rather than manufacturing-oriented. Nevertheless, all of 9001’s requirements are covered by 9000-3.

ISO 9000-3, Primary Areas of Concern

The following excerpt, adapted from Dr. Stovsky’s white paper, The ISO 9000 Approach to Quality Systems for Software Development, describes some of the primary areas of concern in 9000-3. These include configuration management, change control, development planning, quality planning, design and implementation, testing and validation, and maintenance.

Configuration Management

The purpose of configuration management is to ensure each build of a product is derived from the correct version of every source file. These requirements apply to all software products, including customer documentation and manuals. A configuration management plan should identify the activities to be carried out and the tools, techniques, and methods to be used.

The plan should determine the stage at which items will be brought under configuration control. Each software item should be identified uniquely and each item’s build status should be identified. The version of each software item required to construct each version of the product should be specified.

Change Control

Change control helps managers balance customer needs, technical capability, and additional resource requirements for modifications to the product. It helps prevent the late introduction of new requirements in the development cycle Change control also ensures all parties affected by a change are notified. Procedures should be developed to identify, document, review, and authorize any changes to items under configuration management.

It should be possible to trace approved changes and subsequent modifications to all affected items, from change initiation through release. Changes are often initiated by engineering change orders (ECOs) also known as modification requests, initiation requests, etc. A review board typically reviews the ECOs, prioritizes them, and decides whether to accept immediately, defer, or reject the requests based on previously established criteria. For detailed treatment of software configuration management, see [SEPA, 5/e, Chapter 9].

Development Planning

A development plan provides a unified view of the activities required to complete a project. It includes identification of the activities to be performed, the resources required for each activity, and the timing of and coordination of each activity. Risk analysis and contingency planning should be included as part of the development planning process.

A development plan should define the development stages to be carried out for each project, the required inputs and outputs for each phase, and the verification procedures for each phase. The development plan should include a schedule, describe the mechanisms for tracking progress, and outline organizational responsibilities and work assignments. The development plan should identify related project plans such as the quality plan, integration plan, test plan, maintenance plan, and configuration management plan.

The development plan provides the basis for tracking project progress. Completion of milestones should be recorded and progress should be compared to the development plan schedule on a regular basis. Slippages should be identified and the plan should be updated to accommodate additional resources required, including time, personnel, and equipment. If the shipping date will be changed, affected departments and customers should be notified so they may plan accordingly. For detailed treatment of software development planning, see [SEPA, 5/e, Chapter 5].

Quality Planning

The purpose of a quality plan is to determine a project’s quality goals before development starts. This information helps direct the testing and validation effort and determines whether or not a product has achieved its quality goals and, therefore, is ready to be shipped to customers. In the absence of a quality plan, products are often shipped at the schedule’s end date without regard to product quality.

A quality plan should state the project quality goals–in measurable terms, when possible. It should define the input and output criteria for each development phase and identify the test and verification activities to be carried out for each phase. The plan should also identify those who are responsible for and have authority for the quality assurance activities performed. For detailed treatment of software quality assurance and planning, see [SEPA, 5/e, Chapter 8].

Design and Implementation

The reasons for using a design and implementation methodology include use of common language to express and evaluate designs, consistent approach among projects, and elimination of haphazard development. Projects of different size and complexity may elect to use different design methods and degrees of formality.

However, ISO 9000-3 suggests that a systematic design methodology appropriate for the software product being developed should be identified and used. Design and coding rules and conventions should be identified. Reviews should be carried out to ensure the product requirements are met and the methods identified are employed appropriately. For detailed treatment of analysis, design and related activities, see [SEPA, 5/e, Parts Three and Four].

Testing and Validation

A test plan identifies the levels and types of tests to be run on a product, the resources required, the schedule, and the required inputs and expected outputs for each test case. 9000-3 recognizes that several types of testing may be necessary to adequately exercise a product, such as unit, integration, system, and acceptance testing.

?The test plan should include descriptions of test environments, tools, software, and documentation needed. The required version of each software and hardware component in the test environment should be specified. The inputs and expected results for each test case should be documented. Completion criteria for each level of testing should be described. For detailed treatment of software testing, see [SEPA, 5/e, Chapter 17, 18, and 23].

Maintenance

Because the maintenance phase of a product is likely to last much longer than the original product design and development, this phase should consist of a carefully planned set of activities. A maintenance plan should identify support organizations, activities covered under the plan, the records and reports produced, and release procedures for distributing and installing customer updates. The maintenance plan should cover problem resolution, interface modifications, and functional enhancement for the product.