5 FAH-5 H-530

(CT:ITS-4;   06-21-2012)
(Office of Origin:  IRM/BMP/GRP/GP)
(Updated only to revise Office of Origin)

5 FAH-5 H-531  GENERAL

(TL:ITS-1;   02-13-2002)

CM is often equated to change control.  Indeed, change control is a critical component of CM, but it is only one of many.  Following is a brief look at the components of CM and how they connect to supporting a project manager’s ability to manage and control the project.


(TL:ITS-1;   02-13-2002)

a. Configuration identification (CI) is the current approved or conditionally approved technical documentation for a configuration item as set forth in requirement and design documents such as specifications, drawings, or associated lists and other documents referenced therein.  The purpose of CI is to incrementally establish and maintain a definitive basis for control and status accounting for configuration items throughout its life cycle.

b. CI contains a selection of items and the documents that will comprise baselines for the system and for the configuration item involved, as well as the numbers to be affixed to the items and documents.  Examples of configuration items to be placed under configuration control are:

(1)  Documentation (e.g., requirements, specifications, and user guides);

(2)  Source Code (e.g., PBLs and modules);

(3)  Executable and/or run-time code;

(4)  Database scripts;

(5)  Test database; and

(6)  COTS patches and/or updates.

c.  The following criteria can be used to identify configuration items:

(1)  The item is a manageable entity;

(2)  The item is critical to the project’s mission, cost, or scheduled objective;

(3)  The item has specific requirements for performance control;

(4)  The item is expected to undergo a high degree of change after it becomes operational;

(5)  The item will require maintenance, training, and logistics support; and

(6)  The item has been designated by project management to be placed under CM control.


(TL:ITS-1;   02-13-2002)

a. Configuration control is the systematic evaluation, coordination, approval or disapproval, and implementation of all approved changes in the configuration of a configurated item after formal establishment of its identification. Configuration control covers the evaluation of all change requests and change proposals and their subsequent approval and disapproval.

b. The questions to ask for configuration control to be effective are:

(1)  What is to be controlled?

(2)  Who is the configuration change control authority?

(3)  How are the products to be controlled?

c.  In CI, the first question is answered when the required baselines and the components necessary to make up each of the baselines are identified by the project manager.  The configuration change control authority is the project manager and local board during initial development and the IT CCB thereafter. CM implements physical and electronic controlled libraries for storage of identified controlled items.


(TL:ITS-1;   02-13-2002)

a. Configuration status accounting is the recording and reporting of the information that is needed to change a configuration effectively, including a  listing of the approved configuration identification, the status of proposed changes to the configuration, and the implementation status of approved changes. Configuration management status accounting and the configuration index are the recording activity of configuration management.

b. Status accounting is matter of knowing the current inventory and the use of components under the configuration control.  This will include tracking the configuration over time and then being able to identify configurations of a certain release at any given point in time.  Changes to documentation are controlled and managed also.  CM must be able to produce any versions of configurations and identify any changes or pending changes to each configuration of an application.

c.  CM provides various metric and configuration accounting reports to project management, development, test, and QA personnel during the life cycle of each task.


(TL:ITS-1;   02-13-2002)

a. A configuration audit is the process of verifying that all required configuration items have been produced, and that the current version agrees with the specified requirements.  The audit also verifies that the technical documentation is complete and accurate.  It describes the configuration items, and ensures that all change requests have been resolved.

b. Identification, version control, and change control help the developer to maintain order in what would otherwise be a chaotic and fluid situation. Audits ensure integrity of the product, from beginning to end.  They also identify if there is a traceability of a product change to the authorization for the change, and that only authorized changes were implemented in the controlled product.

c.  A configuration audit is a QA activity that helps to ensure that quality is maintained as changes are made.


(TL:ITS-1;   02-13-2002)

a. The definition of interfaces is one of the most important CM planning and tracking activities.  There must be agreement of each group or organization’s responsibility at each interface.  Any proposed changes to the product or baseline configuration items can be considered and evaluated by all affected groups.

b. There are two basic types of interfaces that must be considered:

(1)  Organizational interfaces; and

(2)  Technical interfaces.

      Organizational interfaces are those in which configuration management controls the transfer of configuration items from vendor to customer, project to project, and co-developer to co-developer.  CM ensures that the correct configuration items are sent to the correct people.  Organizational interfaces also include life-cycle phase interfaces.  Phase interfaces become critical when control of the product is being transitioned between different groups.  Technical interfaces are descriptions that should be placed under configuration management control like any other configuration item.  Technical interfaces include system, user, software, hardware, and communications interfaces.


(TL:ITS-1;   02-13-2002)

a. If a portion of a development project is to be subcontracted to another organization, the responsibility for the CM generally belongs to the contracting organization, and, specifically, the project manager of the project that requires this outside support.  The subcontractor is normally only responsible for the portion of the work that his or her organization is tasked to perform.  The integration of the subcontracted work is normally the responsibility of the organization that subcontracted portions of the work.

b. An effective CM system generally increases the opportunity to have portions of the product subcontracted out and then integrated back into a whole that satisfies the customer’s technical and quality requirements.  CM must be applied to a subcontractor to ensure that the subcontractor is able to maintain the integrity of the subsystem for which it has contracted.  This also includes placing necessary life-cycle products under configuration control to ensure consistency with the main development effort and maintaining a subcontractor’s library that will release the agreed-upon configuration items or subsystems to the contracting organization.


(TL:ITS-1;   02-13-2002)

a. Standards refer to the repeatable method of performing an action or creating a product. In addition, the Department has established various standards from cabling to email products that must be considered when making IT decisions.  QA and development and/or maintenance managers work together to develop standards for coding, displaying reports, and other development and maintenance practices.  The QA team will produce the standards for reviews, audits, testing, and all practices as they apply to the QA functions and responsibilities.

b. Standards relating to CM functions are created by configuration management and approved by quality assurance.  The CM standards include:

(1)  Naming conventions;

(2)  Directory structure conventions;

(3)  Release numbering conventions;

(4)  Labeling;

(5)  CM forms; and

(6)  Change control process.


(TL:ITS-1;   02-13-2002)

a. The CM library should contain the items that are important to a project, including software, source code, user documentation, system documentation, test data, support software, specifications, and project plans.  The CM library typically stores the configuration items and prevents unauthorized changes to the base-lined items.  The CM library system should:

(1)  Support multiple control levels of CM;

(2)  Provide for the storage and retrieval of configuration items;

(3)  Provide for sharing and transfer of configuration items among affected groups and among group control levels within the library;

(4)  Provide for the storage and recovery of archive versions of configuration items;

(5)  Provide service functions, such as checking status, verifying the presence of all built items, and integrating changes into a new baseline;

(6)  Ensure the correct creation of products from the baseline library;

(7)  Provide for the storage, update, and retrieval of CM records;

(8)  Support the production of CM reports; and

(9)  Support the tracing of requirements, forward and backwards, throughout the life cycle.

b. A library provides safe and secure storage for configuration items (key project components) so they cannot be changed without authorization. Acceptance of items (new or revised) into the library is strictly controlled to ensure that everyone accessing items in the library can have complete confidence in their integrity.  A number of libraries may be established to hold different types of items or provide different levels of control.