Configuration Management and ISO 9001 - Part 3

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

Summary - ISO 9001 and configuration management

As described in the preceding paragraphs, of the 20 sections of ISO 9001 that define a supplier's capability to meet customer requirements, CM practices directly impact the following. Check marks in the following table indicate clauses of ISO 9001 that are addressed by CM practices.

Section of ISO 9001
4.1	Management responsibility	x
4.2	Quality system	x
4.3	Contract review
4.4	Design control	x
4.5	Document and data control	x
4.6	Purchasing	x
4.7	Control of customer-supplied product	x
4.8	Product identification and traceability	x
4.9	Process control	x
4.10	Inspection and testing
4.11	Control of inspection, measuring and test equipment
4.12	Inspection and test status	x
4.13	Control of nonconforming product	x
4.14	Corrective and preventive action	x
4.15	Handling, storage, packaging, preservation and delivery	x
4.16	Control of quality records	x
4.17	Internal quality audits
4.18	Training
4.19	Servicing	x
4.20	Statistical techniques	x

In terms of improved efficiency, major opportunities exist in ensuring that the CM, project management, customer technical support, build management, and problem reporting and tracking systems are as tightly coupled as possible.

Beyond CM - Product Attributes and Tool Selection

Nothing in ISO 9001 requires that a specific tool or technology be employed. ISO's sole concern is that the implemented systems be effective in delivering the promised product or service. Tools that automate CM practices may improve the effectiveness and will improve the efficiency of systems that require significant manual intervention.

From an ISO implementation perspective, automation represents an opportunity to:

• Reduce process and project documentation
• Reduce requirements for training
• Ensure that required steps are completed
• Record progress and activity

The tool selection process should ensure that the selected tools support the current or planned software engineering practices. While some minor changes to engineering practices may be required (especially if standard tools with minimum customization are selected), the tools cannot be the basis for formulating engineering practices.

Considerations in tool selection

While a number of factors determine the appropriateness of a particular tool, the following is an initial list of information that is required to evaluate a tool for suitability.

• Product
• Number of products
• Shared/common components
• Application complexity
• Number of platforms supported; number of platforms on which development is performed
• Maintenance of multiple versions (multiple platforms, application variants)
• Project
• Size of project
• Need to maintain, control, adapt, extend, etc. - project or product
• Risks associated with the product, project, and related commitments
• Process
• Code structure and techniques
• Concurrent development
• Paradigm (configuration items, developers' requirements for access, managers' requirements for control and information)
• Stability and flexibility
• People
• Organization size and experience
• Capacity of the organization to adapt
• Existing tools that will be retained
• In the engineering organization
• In organizations that interface with engineering
• Integration with other tools under consideration
• Project management
• Build management
• Customer technical support
• Problem reporting and tracking

Based on Feiler's characterization of current CM tools, certain aspects of tool functionality and process automation emerge as key differentiators among the competing models and tools.

• Merging and propagation of changes (to support multiple versions, concurrent development, shared/common components)
• Among parallel versions
• Between branches and mainstream or shared core
• Restoration of previous versions
• Identification and control of changes
• Identification and control of product and product components
• Automated build management

With this information, the ability of a tool to support a particular organization and its development practices can be evaluated objectively and any requirements for immediate or future customization can be defined.

Bibliography and Recommended Reading

[Ba1] Wayne A. Babich, Software Configuration Management, Addison Wesley Publishing Company, Reading MA, 1986

[Bb1] R.C. Bamford and W.J. Deibler, Comparing, contrasting ISO 9001 and the SEI capability maturity model, IEEE Computer, October 1993, Vol 26, No. 10, IEEE Computer Society, page 68

[Bb2] R.C. Bamford and W.J. Deibler, A Detailed Comparison of the SEI Software Maturity Levels and Technology Stages to the Requirements for ISO 9001 Registration, Software Systems Quality Consulting, San Jose, Calif., 1993.

[Bb3] R.C. Bamford and W.J. Deibler, MKS RCS Version 6.2 and ISO 9001, Software Systems Quality Consulting, San Jose, Calif., 1993.

[Bb4] R.C. Bamford and W.J. Deibler, ISO Implementation as a Managed Process - A Software Perspective, Software Systems Quality Consulting, San Jose, Calif., 1993.

[Da1] Susan A. Dart, The Past, Present, and Future of Configuration Management, CMU/SEI-92-TR-8, Software Engineering Institute, Carnegie Mellon University, Pittsburgh PA, July 1992 (available by anonymous ftp from ftp.sei.cmu.edu)

[Fe1] Peter H. Feiler, Configuration Management Models in Commercial Environments, CMU/SEI-91 -TR-7, Software Engineering Institute, Carnegie Mellon University, Pittsburgh PA, March 1991 (available by anonymous ftp from ftp.sei.cmu.edu)

[Hu1] Watts S. Humphrey, Managing the Software Process, Addison Wesley Publishing Company, New York, August 1990 (Reprinted with corrections)

[Ie1] IEEE Std 828-1990, IEEE Standard for Software Configuration Management Plans, IEEE, 345 E. 47th St., New York, NY (from the Spring 1991 Software Engineering Standards Collection, April 5, 1991)

[Ie2] IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology, , IEEE, 345 E. 47th St., New York, NY (from the Spring 1991 Software Engineering Standards Collection, April 5, 1991)

[In1] ISO 9001:1987 Model for design/development, production, installation and servicing, International Organisation for Standardisation, Geneva, Switzerland, 1987

[In2] ISO 9000-3:1991 Guidelines for the application of ISO 9001 to the development, supply and maintenance of software, International Organisation for Standardisation, Geneva, Switzerland, 1991

[In3] ISO 9000-1:1994 Quality management and quality assurance standards - Guidelines for selection and use, International Organisation for Standardisation, Geneva, Switzerland, 1994

[In4] ISO 9004-1:1994 Quality management and quality system elements - Guidelines, International Organisation for Standardisation, Geneva, Switzerland, 1991

[Pa1] Mark C. Paulk et al., Capability Maturity Model for Software, Version 1.1, CMU/SEI-93-TR-24, Software Engineering Institute, Carnegie Mellon University, Pittsburgh PA 15213, February 1993

[Pa2] Mark C. Paulk et al., Key Practices of the Capability Maturity Model, Version 1.1, CMU/SEI-93-TR-25, Software Engineering Institute, Carnegie Mellon University, Pittsburgh PA 15213, March 1993

[Pr1] Roger S. Pressman, A Manager's Guide to Software Engineering, McGraw-Hill, Inc., New York, 1993

[Wh1] David Whitgift, Methods and Tools for Software Configuration Management, John Wiley & Sons, New York, 1992

---

Related Software Process Articles in Methods & Tools

• Don't Write Another Process
• Assessing Readiness for (Software) Process Improvement
• Process Improvement - Is it a Lottery?
• Mature Scrum at Systematic

---

Page 2   

---

Click here to view the complete list of archived articles

This article was originally published in the Summer 1999 issue of Methods & Tools