#1 This section should describe the organisation of configuration management, and the associated responsibilities. It should define the roles to be carried out
#1 This section should:
identify the organisational roles that influence the software configuration management function (e.g. project managers, configuration librarian, programmers, quality assurance personnel and review boards);
describe the relationships between the organisational roles;
describe the interface with the user organisation.
#2 Relationships between the organisational roles may be shown by means of an organigram. This section may reference the Project Management Plan (PMP).
Configuration Management responsibilities
#1 This section should identify the:
software configuration management functions that each organisational role is responsible for (e.g. identification, storage, change control, status accounting), in the review, audit and approval processes;
#1 This section should define the procedures for the configuration management of external hardware and software interfaces. In particular it should identify the:
external organisations responsible for the systems or subsystems with which the software interfaces;
points of contact in the external organisations for jointly managing the interface;
groups responsible for the configuration management of each interface.
#1 This section should establish the key events in the implementation of the CMP, for example the:
readiness of the configuration management system for use;
establishment of the Software Review Board (SRB);
establishment of baselines;
release of products.
#2 The scheduling of the software configuration management resources should also be shown (e.g. availability of software librarian, software configuration management tools and SRB). This section may cross-reference the PMP.
Applicable policies, directives and procedures
#1 This section should:
identify all applicable software configuration management policies, directives or procedures to be implemented as part of this plan (corporate software configuration management documents may be referenced here, with notes describing the parts of the documents that apply);
describe any software configuration management polices, directives or procedures specific to this project, for example:
i project-specific interpretations of corporate software configuration management documents;
ii level of authority required for each level of control;
iii level of review, testing or assurance required for promotion.
#2 This section should describe the conventions for identifying the items (e.g. software, hardware, documentation etc.) and then define the baselines used to control their evolution.
#3 This section should:
define project naming conventions;
define or reference labelling conventions.
#4 For each baseline, this section should give the:
identifier of the baseline;
contents, i.e. the:
i software itself (e.g. requirement and design documents, modules, executables, verification plans);
ii tools for making derived items in the baseline (e.g. compiler, linker and build procedures);
iii test software (e.g. data, harnesses and stubs);
review and approval events, and the acceptance criteria, associated with establishing each baseline;
participation required of developers and users in establishing baselines.
#5 If appropriate, the description of each baseline should:
distinguish software being developed from software being reused or purchased;
define the hardware environment needed for each configuration;
#6 These sections should detail the control processes by which configured items are to be stored, retrieved and reused.
Code (and document) control
#7 This section should describe the library handling procedures (for software and documents).
#8 Separate types of source code library may be set up, e.g.:
development (or dynamic);
master (or controlled);
archive (or static).
Ideally the same set of procedures should be used for each type of library.
#9 This section should describe the procedure for handling the hardware on which the software resides, such as:
#10 Whatever media is used, the procedure described should include the controls for:
storing the media (e.g. fire-proof safes, redundant off-site locations);
recycling the media (e.g. always use new magnetic tapes when archiving).
#11 This section should define the procedures for processing changes to baselines described in Section 3.2 of this CMP.
Levels of authority
#12 This section should define the level of authority required to authorise changes to a baseline (e.g. software librarian, project manager).
#13 If the procedure for processing change proposals to software (including software development and support tools) is already written in the Change Control procedure then make a reference here to the specific section of that document.
#14 Identify and give details of only those parts of the procedure that are different and specific to this particular project.