The developer shall perform software configuration management in accordance
with the following requirements.
Note: If a system or CSCI is developed in multiple builds, the software
products of each build may be refinements of, or additions to, software
products of previous builds. Software configuration management in each build
should be understood to take place in the context of the software products and
controls in place at the start of the build.
5.14.1 Configuration identification. The developer
shall participate in selecting CSCIs, as performed under system architectural
design in 5.4.2
,
shall identify the entities to be placed under configuration control, and
shall assign a project-unique identifier to each CSCI and each additional
entity to be placed under configuration control. These entities shall include
the software products to be developed or used under the contract and the
elements of the software development environment. The identification scheme
shall be at the level at which entities will actually be controlled, for
example, computer files, electronic media, documents, software units,
configuration items. The identification scheme shall include the version/
revision/release status of each entity.
5.14.2 Configuration control. The developer shall establish and implement
procedures designating the levels of control each identified entity must pass
through (for example, author control, project-level control, acquirer
control); the persons or groups with authority to authorize changes and to
make changes at each level (for example, the programmer/analyst, the software
lead, the project manager, the acquirer); and the steps to be followed to
request authorization for changes, process change requests, track changes,
distribute changes, and maintain past versions. Changes that affect an entity
already under acquirer control shall be proposed to the acquirer in accordance
with contractually established forms and procedures, if any.
Note: A number of requirements in this standard refer to "project-level or
higher configuration control. "If "project-level" is not a level of control
selected for the project, the software development plan should state how these
requirements map to the selected levels.
5.14.3 Configuration status accounting. The developer shall prepare and
maintain records of the configuration status of all entities that have been
placed under project-level or higher configuration control. These records
shall be maintained for the life of the contract. They shall include, as
applicable, the current version/revision/release of each entity, a record of
changes to the entity since being placed under project-level or higher
configuration control, and the status of problem/change reports affecting the
entity.
5.14.4 Configuration audits. The developer shall support acquirer-conducted
configuration audits as specified in the contract.
Note: These configuration audits may be called Functional Configuration
Audits and Physical Configuration Audits.
5.14.5 Packaging, storage, handling, and delivery. The developer shall
establish and implement procedures for the packaging, storage, handling, and
delivery of deliverable software products. The developer shall maintain master
copies of delivered software products for the duration of the
contract.