Configuration control covers the evaluation of all
Change Requests and Change Proposals and their subsequent approval
and disapproval.
The following outlines the method to avoid the possibility of
a change being implemented without due consideration of its effect
on the baselines, including logistics impact, costs, schedules,
performance, or interface with any associate companies, etc.
Each participating company shall appoint a "Configuration Controller" who will be responsible for configuration management for the company specific project/program configuration responsibilities.
The authority required to make a decision on a change varies with the magnitude and nature of the change concerned and involves one of several levels within the organization of the parties (acquirer and developer) to the project. This decision making process is an integral part of the overall management of the 'Project Management System' program and will be defined in the 'System Engineering Management Plan.
To enable the process to operate correctly it is necessary to establish specific procedures for dealing with changes, having the purpose of:
and involving the use of formally constituted 'Configuration Control Boards' (CCB) at the participating companies as illustrated in figure.
Changes to baselines, affecting costs, schedules,
performance and logistics outside the agreed participating companies
liabilities, will be presented to the acquirer or his agent for
a decision.
The acquirers agent will refer all appropriate cases to the purchaser.
In order to control the impact of changes on operating and support issues the following will be taken into account:
If the change has an effect this will be indicated
in the change documentation and a supplementary evaluation sheet
will be attached giving details of assessment.
The following aspects shall in particular be treated:
An important part of change control is the interface between two partner companies working on the same project. To control the interface, the originating company will complete a Change Request (CR) form, and an interface sheet.
If agreement cannot be reached between affected parties, for any reason, the CRs will be submitted to the company Interface configuration control board where agreement should be sought on the presence of the acquirer or his representative. Failing agreement at this level, the acquirer will discuss the change ait the next acquirer change board and communicate the decision to all concerned.
In some cases it may be necessary to obtain higher agreement. Where changes affect interfaces as defined in the system ICD, these will be coordinated with the appropriate Design Authority and the submitted to the acquirer.
The Configuration Management organization within the acquirer will be responsible for:
All changes will be submitted on an agreed change
format.
Change categorization falls into two classes "Class
I" and "Class II".
Class I changes will always be subject to the formal change process,
i.e., Change Request/ Change Proposal.
Class II changes will be subject to the SCMP and HWMP change procedure
"Problem/Change Report" with access being provided to
the customer.
The originator of an Engineering Change to a CI will classify
the changes as Class I or Class II. Classification disagreements
shall be referred to the customer for final decision. Assuming
that its purpose and necessity have been established, each Change
Proposal will be assigned the appropriate classification by the
Originator in accordance with the following definitions.
A computer software change will be classified Class I when one or more of the factors listed below is affected:
A computer software change will be classified Class
II when it does not fall within the definition of a Class I change
as defined previously.
Examples of a Class II change are:
All changes to the established Functional, Allocated, or Product Baselines are Class I change. Note a Class I change is not correcting minor deficiencies Slight changes to documentation or other changes of a minor nature are Class II changes.
Requirements for defining a computer software change as Class I (aye) or Class II (aye, aye) as presented in 5.3.1 and 5.3.2.
Initially Class I change processing shall be performed in one or two steps. One step change processing is the simultaneous submission of the formal CP and the CP with change pages for the appropriate specification(s) by the developer to acquirer Configuration Control Board (CCB). Two step change processing consists of the following steps:
One step change processing shall apply to changes in the System/subsystem specification(s) when approved change to a development specification (allocated baseline) impacts on the System/subsystem specification. One step change processing shall be used for changes in the allocated baseline(s) when changes are of a minor nature to accomplish expansions or refinements, such as the elimination of TBDs.
Two step processing shall be used for proposed major changes to the allocated baselines, such as the addition or deletion of significant capabilities, which may entail extensive systems engineering analysis and result in changes to many pages of the specification. However, two step processing shall always apply to the Product Specification. Modification of the components shall be accomplished between steps one and two of the process by furnishing computer-generated change pages for the CR package to the Product Specification.
Upon approval of the formal CP and the CR(s) by the acquirer CCB, for two step change processing the developer/supplier shall complete the change process for the current modification by preparing the following items for distribution:
Class II changes usually do not require approval by the acquirer prior to implementation. Class II changes will be documented using the first page of the Change Proposal form, or using a 'Problem/Change Report' (PCR).
A Class II 'Change Proposal' or a PCR may address
both development and interface requirements specifications or
a Product Specification, but never the requirements and Product
simultaneously.
A Class II CP or a PCR may be used to maintain any document if
directed by the acquirer.
Class II changes may be reported to the acquirer if requested by including a PCR as part of the next Class I CP package for the same CI. Class II changes shall be included in CRs issued to incorporate Class I changes. The CR shall indicate the classification of each change specified therein.
Instructions for the preparation of the configuration control documents are:
Preliminary CPs shall be provided to the acquirer for all proposed Class I changes to a CSCI. Upon approval and implementation of a change, using the two step process, the informal CP will be submitted to the acquirer CCB.
The Change Proposal shall be prepared to the format and content defined in the CP - Model text.
The CR shall be used to document all requested Class I and Class II changes to the Functional Baseline, Allocated Baseline, or Product Baselines for the identified system and subsystem(s). The CR or PCR shall be used to propose, transmit and record deficiency changes (Class II) to software specifications and design documents held under formal/informal configuration control.
The CR shall be prepared to the format and content defined in the CR - Model text.
The PCR shall be used to report a Problem and proposed Change (Class II only) to an Allocated Baseline or Product Baseline and to document changes to software items which have been entered into a specific CI internal Developmental Configuration, the format, content and instructions for a problem/change report will be identified in the CMP.
Note: a PCR can be known as a variety of change documentation
in different companies they must however contain the minimum basic
information defined.
The PCR shall be prepared to the format and content defined in
the PCR - Model text.
A 'System Allocation Description' if identified in the CDRL to identify the aggregation of configuration items which are the basis for system design and integration. The 'System Allocation Description' shall be maintained until completion of all system testing required to complete the design and development program.
For an example text see System Allocation Description model text .
An SVD shall be prepared to accompany the formal release of each engineering version of a CSCI and to accompany the release of each change (that is, changes that occur between CSCI versions) to the purchaser. This document will record the items delivered and additional pertinent data relating to status and usage of the CSCI change. The SVD shall be prepared to the format and content defined in the SVD - Model text.
A 'Version compatibility matrix' (VCM) shall be prepared to show compatible combinations of software versions and hardware modification states, and will be part of the Master Record Index (MRI). The VCM shall be prepared to the format and content defined in the VCM - Model text.
A 'Change status report' shall be prepared to detail the status of all proposed changes to CSCIs and HWCIs for which the relevant System Design supplier (Design Authority) is responsible. The purpose of the report is to provide, on a periodic basis, the current status of all officially proposed 'Change Proposals' for the specific CSCIs and HWCIs.
The 'Change Status Report' shall be prepared to the format and content defined in Change status report example text .
An index to a master set of drawings, specifications, and other pertinent documentation which defines a system of hardware and software for the purpose of:
The 'Master Record Index' shall be prepared to the format and content defined in Master Record Index report example text .
For implementation of urgent (or emergency) changes
in support of system testing, reliability, maintainability, and
maintainability demonstration, manufacture, without having delay
caused by the normal change procedure, urgent methods within supplier
companies shall be established and applied.
These change must still be subjected to the Qualification procedures
and adequate supporting evidence for the change will be necessary
in each case.
An Urgent priority will be assigned to an engineering change proposed
for any of the following reasons:
Where a drawing or specification is correct and manufacturing
error(s) occur, a form for 'Deviations and Waivers' is completed
by manufacturing to enable the item to be accepted or for some
form of repair to be embodied, in order that the component is
not scrapped just because it does not exactly conform to the drawing
or standards.
Deviations and waivers should not be used to avoid processes required
by the life cycle. If non applicable documents and evaluations
are required these must be tailored and agreed prior to contract
let.
Note: Deviations and waivers will supersede Concessions and Production Permits used by some countries.
Prior to the manufacture of an item, if it is considered necessary to temporarily depart from mandatory requirements of a specification or drawings, a request from the developer/supplier may be authorized by the acquirer. Items shall not be delivered incorporating a known departure from documentation unless a request for deviation has been approved.
Supplies or services which do not conform in all respects to the contractual requirements shall normally be rejected. An item which through error during manufacture does not conform to the specified configuration documentation shall not be delivered to the acquirer unless a waiver has been processed and granted.
For implementation of urgent changes to developer/supplier
components (equipment, CSCIs, HWCIs) a ' On-site Equipment Change
Procedure' will enable rapid incorporation and/or retrofit.
Back to Home page
Back to CMP page
Back to Top of this page
For Home page MANAGING STANDARDS
kenr@wysywig.airtime.co.uk
Originated on the 17th of July 1995
Please send any beneficial comments or identification of errors
using the following form to: kenr@wysywig.airtime.co.uk
Note: Class I changes are generally identified as 'Modifications'
in the UK; Class II as 'Amendments'.
Waivers are sometimes known as 'Concessions'.
Deviations are sometimes known as 'Production Permits'.