In terms of Software, what constitutes a quality control plan for ISO 9001 compliance?

Question

I am bidding on a government contract (my first) and there is a section requesting that I provide a high-level outline of a quality control plan that would ensure that the end product is ISO-9001 compliant.

I don't know much about ISO 9001 so I am certainly doing my own homework and research on this, but thought I would ask the question here in case there happens to be someone very knowledgeable in the area who could provide 5-10 broad bullet points on which I should focus.

Answer 1

I'm going to preface my answer with the fact that my expertise is in AS9100 and AS9115. AS9100 is the aerospace industry standard that incorporates additional aerospace industry requirements with ISO 9001. The revision of AS9100 that I'm familiar with is AS9100C, which corresponds to ISO9001:2008. There may be minor differences between the two.

The first thing to realize is that a document like ISO9001 or AS9100 is designed for an organization to ensure that their process accounts for things that are important to their customers. It, by itself, is not a process. It's up to an organization to determine exactly how to meet the requirements, based on the organizational environment, objectives, the product, the size of the organization, and more. The emphasis is on considering the value added to customers by process steps, obtaining an effective process and continually improving processes using objective measures, and ultimately understanding customer requirements and meeting them throughout the product life cycle.

At the highest level, the goal is to define organizational processes, how those processes interact, ensure that the processes have the resources and information needed to function, how to measure and control each process, and how to implement actions to correct or prevent problems in the process.

In AS9100, the actual requirements are found in sections 4 through 8. Looking at the outline of ISO9001 on Wikipedia, it looks like the section headers are the same - Quality Management System, Management Responsibility, Resource Management, Product Realization, and Measurement, Analysis and Improvement.

Each section and subsection is a collection of statements, usually "shall" statements. In essence, this document is a requirements specification for an organization to follow.

For example, section 7.3.4 Design and Development Review:

At suitable stages, systematic reviews of design and development shall be performed in accordance with planned arrangements (see 7.3.1)

a) to evaluate the ability of the results of design and development to meet requirements

b) to identify any problems and propose necessary actions

Participants in such reviews shall include representatives of functions concerned with the design and development stage(s) being reviewed. Records of the results of the reviews and any necessary actions shall be maintained (see 4.2.4).

What this says is that you have planned and well-defined reviews during product development. Often, this takes the form of System Requirements Review, Preliminary Design Review, Critical Design Review, and Test Readiness Review, in addition to various peer reviews that are planned and executed during development. These reviews are to ensure that the current work products (derived requirements specifications, models, design documents, source code, test code, etc) are meeting requirements.

This ties to Section 7.3.1 Design and Development Planning, which says that you plan the stages of design and development, ensure that reviews and V&V activities occur at every stage of development and are appropriate given the inputs and outputs, and that you identify who is responsible and has authority over design and development activities. It also ties to 4.2.4 Control of Records which says that you have documented procedures for identifying, storing, protecting, retrieving, retaining, and dispositioning records and maintain objective evidence of this happening.

Depending on your organization, there may be one or more documents that define the organizational process. In larger organizations, there are often several documents controlled by different people who are knowledgeable in that area. For example, the documents that define the processes for configuration management are controlled by the configuration management team, while the documents for record management are controlled by Document Control, and the engineering documents are controlled by various engineers (often engineering management). However, in a smaller organization, you may only have one or a small handful of documents.

In order to fully understand and implement ISO9001, you'll need to have a copy of the standard to read and follow. Reading it pretty much tells you everything that you'll need to achieve with your process documentation. Once your documentation is in place and you've been executing to it for long enough to begin to produce objective evidence, you can seek an audit and your organization will become compliant to ISO9001.

Answer 2

In doing my own research on the topic, I found this document published by ISO. It covers eight quality management principles:

1. Customer Focus
2. Leadership
3. Involvement of people
4. Process approach
5. System approach to management
6. Continual improvement
7. Factual approach to decision making
8. Mutually beneficial supplier relationships

The document itself goes into detail about what each tenent means with regards to quality and it's not too hard to apply that to the process of producing a piece of software.