Ensuring software quality & reliability with configuration & change management

Kim H. Pries and Jon M. Quigley

April 29, 2009

Kim H. Pries and Jon M. QuigleyApril 29, 2009

Configuration management is a fundamental product development process. In fact, we would say "you don't know what you are doing if you don't know what you have;" that is, you don't have much of an organization if you don't know what your product is or the resources that are available.

We know from experience in various companies that an optimally running configuration management program will reduce erroneous fault reports and will also stream line test times. Manufacturing firms with good configuration management systems bring their part numbers and product releases under control.

In general, the enterprise is completely dependent on robust configuration management, whether the product is software, firmware, or hardware. Sending the customer the incorrect version of a product is a quick way to become a "de-sourced" supplier.

The Purpose of Configuration Management
Configuration management systems help to deliver coordinated software and hardware. They do this by easily identifying features and functional content within a particular software and hardware availability.

Not only that, but we can have straightforward traceability of function and feature growth over specification revisions as well as over content--hardware and software--delivery. Throughout the process (Figure 1, below), we can always clearly identify changes, execute pre-release containment, and identify compatible components within a system.

Figure 1. Configuration Management Process

Configuration management and planning
In order to deliver robust software or hardware, it is necessary that we plan and coordinate the software and the hardware deliveries of functionality.

In short, functionality, deliveries, testing, and production follow a master plan (Figure 2, below) rather than ad hoc pandemonium. With appropriate planning we will always know the following items:

* Features and feature revision level
* For example, engine electronic control unit, cruise control rev 1.0 within a particular software revision
* Software revision level
* Hardware revision level
* Subassembly revision level in the case where we have firmware 'burned' onto a chip
* Systems integration (phased feature release)

Figure 2. A configuration management mast plan for hardware and software

IEEE standard 1220 favors the master plan approach to system engineering, providing an alternative to standard project management practices.

Configuration management areas
Configuration management can be applied to specifications (documentation), models, simulation, hardware, software, the combination of hardware and software, and to system integration.

That truth is that configuration management can be applied the just about anything. In a manufacturing facility, we might see the following approach to Configuration Management, namely:

* Product baseline
* Product change management
* Number of product changes
* Time spent on product changes
* Cost impact of changes
* Product configuration (CMP)
* Test configurations (test coverage)
* Configuration audit

The items in the list apply to both software and hardware for the most part.

< Previous
Page 1 of 3
Next >

Loading comments...