From the white paper:
Configuration management (CM) is an essential part of quality assurance and of professional software development in general. It involves version control of the various deliverables and documents that determine the application (or system) to be built. By so doing, it ensures that these items are visible, traceable, and formally controlled throughout their evolution (Sprague, 1991, cited in Keyes, 1993).
The documents you should control under CM include all the work products associated with a project, such as (ibid.):
contracts, memos, letters;
project plans and schedules;
system and software requirements;
architecture and design documents, including use cases, object models, dynamic models, functional models;
source, object, and executable code, including commercial off-the-shelf (COTS) software;
all data files, including flat files and databases;
scripts, configuration files, build files, installation files;
test plans and reports;
systems and network options;
supporting documents, such as technical reports, educational and training documents, user manuals, presentations, and business reports.
Most projects will have a significant subset of these items. By tracking and controlling these deliverables, a baseline that defines what is being built and delivered can be established and managed. This baseline management provides a version-controlled set of documents and files bound together and accessible as a whole.
Failure to implement even a simple CM system has many negative consequences. Perhaps the two more critical are:
the constant threat of drift or inconsistency in specification, architecture, and design due to the lack of a version-controlled baseline;
the inability to capture a snapshot of all files and components required to repeatedly build a specific version of the application (or system) in question from some previous point in time.
Both consequences have serious implications for quality assurance and can undermine other QA efforts and activities.