| Software Configuration Managementa key process area for level 2: RepeatableThe purpose of Software Configuration Management is to establish and maintain
the integrity of the products of the software project throughout the project's
software life cycle.
 
Software Configuration Management involves identifying the configuration of the
software (i.e., selected software work products and their descriptions) at
given points in time, systematically controlling changes to the configuration,
and maintaining the integrity and traceability of the configuration throughout
the software life cycle.  The work products placed under software configuration
management include the software products that are delivered to the customer
(e.g., the software requirements document and the code) and the items that are
identified with or required to create these software products (e.g., the
compiler). 
A software baseline library is established containing the software baselines as
they are developed.  Changes to baselines and the release of software products
built from the software baseline library are systematically controlled via the
change control and configuration auditing functions of software configuration
management. 
This key process area covers the practices for performing the software
configuration mangement function.  The practices identifying specific
configuration items/units are contained in the key process areas that describe
the development and maintenance of each configuration item/unit.
 GoalsGoal 1Software configuration management activities are planned.
 Goal 2Selected software work products are identified, controlled, and available.
 Goal 3Changes to identified software work products are controlled.
 Goal 4Affected groups and individuals are informed of the status and content of
software baselines.
 Commitment to performCommitment 1 -- The project follows a written organizational policy for
implementing software configuration management (SCM).This policy typically specifies that:
		Responsibility for SCM for each project is explicitly assigned.
		SCM is implemented throughout the project's life cycle.
		SCM is implemented for externally deliverable software products,
	designated internal software work products, and designated support tools used
	inside the project (e.g., compilers).
		The projects establish or have access to a repository for storing
	configuration items/units and the associated SCM records.
The contents of this repository are referred to as the "software baseline
	library" in these practices.
 
    
	The tools and procedures for accessing this repository are referred to as
	the "configuration management library system" in these practices.
 
 
 Work products that are placed under configuration management and treated as  a
	single entity are referred to as configuration items.
 
    
	Configuration items are typically decomposed into configuration components, and
	configuration components are typically decomposed into units.  In a
	hardware/software system, all of the software may be considered as a single
	configuration item, or the software may be decomposed into multiple
	configuration items.  In these practices the term "configuration items/units"
	is used to refer to the elements under configuration management. 
 
		The software baselines and SCM activities are audited on a periodic
	basis.
 Ability to performAbility 1 -- A board having the authority for managing the project's
software baselines (i.e., a software configuration control board - SCCB)
exists or is established.The SCCB:
		Authorizes the establishment of software baselines and the identification
	of configuration items/units.
		Represents the interests of the project manager and all groups who may be
	affected by changes to the software baselines.
Examples of affected groups include:
 
			hardware quality assurance,
			hardware configuration management,
			hardware engineering,
			manufacturing engineering,
			software engineering (including all subgroups, such as software design),
			system engineering,
			system test,
			software quality assurance,
			software configuration management,
			contract management, and
			documentation support.
	 
		Reviews and authorizes changes to the software baselines.
		Authorizes the creation of products from the software baseline
	library.
 Ability 2 -- A group that is responsible for coordinating and implementing
SCM for the project (i.e., the SCM group) exists.A group is the collection of departments, managers, and individuals who have
	responsibility for a set of tasks or activities.  A group could vary from a
	single individual assigned part time, to several part-time individuals assigned
	from different departments, to several individuals dedicated full time.
	Considerations when implementing a group include assigned tasks or activities,
	the size of the project, the organizational structure, and the organizational
	culture.  Some groups, such as the software quality assurance group, are
	focused on project activities, and others, such as the software engineering
	process group, are focused on organization-wide activities.
 
 The SCM group coordinates or implements:
 
		Creation and management of the project's software baseline library.
		Development, maintenance, and distribution of the SCM plans, standards,
	and procedures.
		The identification of the set of work products to be placed under
	SCM.
A work product is any artifact  from defining, maintaining, or using a software
	process.
 
 
		Management of the access to the software baseline library.
		Updates of the software baselines.
		Creation of products from the software baseline library.
		Recording of SCM actions.
		Production and distribution of SCM reports.
 Ability 3 -- Adequate resources and funding are provided for performing
the SCM activities.
		A manager is assigned specific responsibilities for SCM.
		Tools to support the SCM activities are made available.
Examples of support tools include:
 
			workstations,
			database programs, and
			configuration management tools.
	 
 Ability 4 -- Members of the SCM group are trained in the objectives,
procedures, and methods for performing their SCM activities.Examples of training include:
 
			SCM standards, procedures, and methods;  and
			SCM tools.
	 
 Ability 5 -- Members of the software engineering group and other
software-related groups are trained to perform their SCM activities.Examples of other software-related groups include:
 
			software quality assurance, and
			documentation support.
	 
 
 Examples of training include:
 
			the standards, procedures, and methods to be followed for SCM activities
		performed inside the software engineering group and other software-related
		groups; and
			the role, responsibilities, and authority of the SCM group.
	 
 Activities performedActivity 1 -- A SCM plan is prepared for each software project according
to a documented procedure.This procedure typically specifies that:
		The SCM plan is developed in the early stages of, and in parallel with,
	the overall project planning.
		The SCM plan is reviewed by the affected groups.
		The SCM plan is managed and controlled.
"Managed and controlled" implies that the version of the work product in use at
	a given time (past or present) is be known (i.e., version control), and changes
	are incorporated in a controlled manner (i.e., change control).
 
    
	If a greater degree of control than is implied by "managed and controlled" is
	desired, the work product can be placed under the full discipline of
	configuration management, as is described in this key process area. 
 
 Activity 2 -- A documented and approved SCM plan is used as the basis for
performing the SCM activities.The plan covers:
		The SCM activities to be performed, the schedule of activities, the
	assigned responsibilities, and the resources required (including staff, tools,
	and computer facilities).
		The SCM requirements and activities to be performed by the software
	engineering group and other software-related groups.
 Activity 3 -- A configuration management library system is established as
a repository for the software baselinesThis library system:
		Supports multiple control levels of SCM.
Examples of situations leading to multiple levels of control include:
 
			differences in the levels of control needed at different times in the life
		cycle (e.g., tighter control as product matures),
			differences in the levels of control needed for software-only systems vs.
		systems which include both hardware and software.
	 
		Provides for the storage and retrieval of configuration items/units.
		Provides for the sharing and transfer of configuration items/units between
	the affected groups and between control levels within the library.
		Helps in the use of product standards for configuration items/units.
		Provides for the storage and recovery of archive versions of configuration
	items/units.
		Helps to ensure correct creation of products from the software baseline
	library.
		Provides for the storage, update, and retrieval of SCM records.
		Supports production of SCM reports.
		Provides for the maintenance of the library structure and
	contents.
Examples of library maintenance functions include:
 
			backup/restoring of library files, and
			recovery from library errors.
	 
 Activity 4 -- The software work products to be placed under configuration
management are identified.
		The configuration items/units are selected based on documented
	criteria.
 Examples of software work products that may be identified as configuration
	items/units include:
 
			process-related documentation (e.g., plans, standards, or procedures)
			software requirements,
			software design,
			software code units,
			software test procedures,
			software system build for the software test activity,
			software system build for delivery to the customer or end users,
			compilers, and
			other support tools.
	 
		The configuration items/units are assigned unique identifiers.
		The characteristics of each configuration item/unit are specified.
		The software baselines to which each configuration item/unit belongs are
	specified.
		The point in its development that each configuration item/unit is placed
	under configuration management is specified.
		The person responsible for each configuration item/unit (i.e., the owner,
	from a configuration management point of view) is identified.
 Activity 5 -- Change requests and problem reports for all configuration
items/units are initiated, recorded, reviewed, approved, and tracked according
to a documented procedure.Activity 6 -- Changes to baselines are controlled according to a
documented procedure.This procedure typically specifies that:
		Reviews and/or regression tests are performed to ensure that changes have
	not caused unintended effects on the baseline.
		Only configuration items/units that are approved by the SCCB are entered
	into the software baseline library.
		Configuration items/units are checked in and out in a manner that
	maintains the correctness and integrity of the software baseline
	library.
Examples of check-in/out steps include:
 
			verifying that the revisions are authorized,
			creating a change log,
			maintaining a copy of the changes,
			updating the software baseline library, and
			archiving the replaced software baseline.
	 
 Activity 7 -- Products from the software baseline library are created and
their release is controlled according to a documented procedure.This procedure typically specifies that:
		The SCCB authorizes the creation of products from the software baseline
	library.
		Products from the software baseline library, for both internal and
	external use, are built only from configuration items/units in the software
	baseline library.
 Activity 8 -- The status of configuration items/units is recorded
according to a documented procedure.This procedure typically specifies that:
		The configuration management actions are recorded in sufficient detail so
	that the content and status of each configuration item/unit are known and
	previous versions can be recovered.
		The current status and history (i.e., changes and other actions) of each
	configuration item/unit are maintained.
 Activity 9 -- Standard reports documenting the SCM activities and the
contents of the software baseline are developed and made available to
affected groups and individuals.Examples of reports include:
 
			SCCB meeting minutes,
			change request summary and status,
			trouble report summary and status (including fixes),
			summary of changes made to the software baselines,
			revision history of configuration items/units,
			software baseline status, and
			results of software baseline audits.
	 
 Activity 10 -- Software baseline audits are conducted according to a
documented procedure.This procedure typically specifies that:
		There is adequate preparation for the audit.
		The integrity of software baselines is assessed.
		The structure and facilities of the configuration management library
	system are reviewed.
		The completeness and correctness of the software baseline library contents
	are verified.
		Compliance with applicable SCM standards and procedures is verified.
		The results of the audit are reported to the project software manager.
		Action items from the audit are tracked to closure.
 Measurement and analysisMeasurement 1 -- Measurements are made and used to determine the status of
the SCM activities.Examples of measurements include:
 
			number of change requests processed per unit time;
			completions of milestones for the SCM activities compared to the plan; and
			work completed, effort expended, and funds expended in the SCM
		activities.
	 
 Verifying implementationVerification 1 -- The SCM activities are reviewed with senior management
on a periodic basis.The primary purpose of periodic reviews by senior management is to provide
	awareness of and insight into software process activities at an appropriate
	level of abstraction and in a timely manner.  The time between reviews should
	meet the needs of the organization and may be lengthy, as long as adequate
	mechanisms for exception reporting are available.
 
 
 
 Refer to Verification 1 of the Software Project Tracking and Oversight key
	process area for practices covering the typical content of senior management
	oversight reviews.
 
 
 Verification 2 -- The SCM activities are reviewed with the project manager
on both a periodic and event-driven basis.Refer to Verification 2 of the Software Project Tracking and Oversight key
	process area for practices covering the typical content of project management
	oversight reviews.
 
 
 Verification 3 -- The SCM group periodically audits software baselines to
verify that they conform to the documentation that defines them.Verification 4 -- The software quality assurance group reviews and/or
audits the activities and work products for SCM and reports the results.Refer to the Software Quality Assurance key process area.
 
 At a minimum, the reviews and/or audits verify:
 
		Compliance with the SCM standards and procedures by:
	
			the SCM group,
			the SCCB,
			the software engineering group, and
			other software-related groups.
			Occurrence of periodic software baseline audits.
 
![[^^]](up.gif) Table of contents ![[->]](back.gif) Back one chapter |  |  |