Configuration identification consists of setting
and maintaining baselines which define the System or subsystem,
HWCIs and CSCIs of each individual Configuration Item at any point
in time. Depending on the system life cycle (see fig 1 on MANAGING STANDARDS home
page) phase different baselines are progressively established.
The following baselines are required for the System Development
and for subsequent phases and will constitute the necessary datum's
from which Configuration Management will operate.
These baselines comprise the System, HWCIs and CSCIs, and may be sub-divided in themselves, for convenience. All changes will be subject to the Formal Configuration Control outlined in Section 5.
The objective of baseline establishment is to define a basis for further system life cycle process activity and allow reference to, control of, and traceability between configuration items.
System program management normally employs three baselines for the validation and acquisition of systems and subsystems; namely the functional, allocated, and product baselines depending on complexity or peculiar requirements.
During the "Concept Exploration Phase",
the initial "Baseline Build Standard" (BBS) for the
system will be established.
The primary documents which will form the basis of the initial
BBS will be the System/subsystem Specification(s) and the associated
documentation (SOW, RFP, CDRL, etc.) and the physical baseline
definition which reflects the Specification and Drawing Trees
as defined in the SEMP. Together they form the functional and
physical definition of the System.
These are the principle concerns of Configuration Management,
the integrity of which it is their purpose to assure, through
proper operation of the change process.
The initial Baseline Build Standard for the System,
is defined in the System/Subsystem Specification, where functions
are specified in a descriptive manner qualified by performance
parameters.
Working from the SSS the System design/analysis will be defined
and specified in greater detail (decomposed) by subsidiary subsystem
specifications or Prime item development specifications and Interface
Control Drawing documentation, down to equipment specifications
(as defined in a SEMP). When authenticated these documents will
establish Functional baselines for the specific system or subsystem.
The establishment of the Functional baseline shall occur no later
than the Formal "System Design Review". See SEMP Section 3.9 .
The Allocated Baselines shall be used to govern the
development of selected Configuration Items; HWCIs and CSCIs that
have been allocated from system requirements established in the
Functional baseline or are part of a higher level Configuration
Item.
For HWCIs, the timing of the establishment of the Allocated Baseline
for each HWCI will be agreed before the Formal 'Critical Design
Review' (CDR) and consist of the drawings and hardware Development
Specifications.
For each CSCI, an Allocated Baseline shall be established upon
successful completion of the Formal Software Specification Review
(SSR) and will consist of the specific CSCI Software/Interface
Requirements Specification(s) and drawings.
During the Engineering and Manufacturing Development
phase an internal development configuration shall be established
to control the developing design and its implementation for each
of the Allocated HWCIs and CSCIs.
The internal developmental configuration
for HWCIs and CSCIs will be established at the engineering release
of the 'Software Design Description' prepared for each CSCI, and
relevant drawings for each HWCI prior to the formal PDR.
The development configuration shall terminate at the establishment
of the Product Baseline for both HWCIs and CSCIs.
Changes to the products entered into the developmental configuration
can for expediency be documented in the form of Problem/Change
Reports (PCR) until there incorporation.
(By their nature changes proposed by PCR will be Class II changes.)
For an example PCR see Problem/change report model text
The Product Baseline for a configuration item shall
be established at the successful completion of the Physical Configuration
Audit of each identified HWCI and CSCI. The Product Baseline shall
prescribe the necessary "build-to" or form, fit or function
requirements and the Acceptance Test Procedure for the HWCI requirements.
The relevant function or fabrication product specification shall
establish the Hardware Product Baseline for each HWCI.
After the 'source code listings' and design documentation for
the CSCI are approved at the Physical Configuration Audit for
each CSCI prescribing the necessary "as-coded" requirements.
They shall establish the Software Product Baseline for each CSCI
and contained within the 'Software Product Specification'.
The Physical Baseline is defined in terms of a listing
of drawings and of assemblies and component part numbers.
This baseline shall be the point of departure for all activities
in the subsequent phases of the project, leading to production
(manufacture) and in-service operation of the System. It will
constitute the datum line for the Production Change procedure
(sometimes referred to as Modifications (MODs).
Drawing practices and the identification of parts will be in accordance
with the contractually stated Design Standards (MIL-STD-100, DEF
STAN 05-10, etc.,).
4.2.1.5 Production release records.
Production release records shall be prepared in accordance
with the "production release procedure" to release new
or revised configuration documentation to the acquirer for approval.
Configuration documentation shall be initially released, including
the incorporation of related information into the configuration
status accounting information system by means of a 'Master record index'
(MRI).
A 'Version Compatibility Matrix' will
provide the software version to hardware modification details
which will form a part of the MRI.
The DRB is defined by the System Specification and
listed as applicable documents. This usually consists of already
prepared and approved project documents (SEMP, CMP, Documentation
Standard) and the relevant standards (military, commercial, etc.,)
identified and agreed at the formal System Requirements Review
for the project.
Changes to this baseline must be by agreement with the acquirer
using the appropriate Contract Change forms held by the acquirer.
The Target Standard is a listing of all relevant
specifications, this includes the CSCI executable object code
(software engineering release), System/subsystem specifications,
Interface Control Drawings, Software/interface Requirements Specifications,
General Assemblies (GAs) and Installation Drawings, HWCI and CSCI
Development and Product Specifications, relating to the hardware,
software and firmware and is therefore the document forming the
Development Component Baseline (DCB).
The Development Component Baseline contents will be established
at the System Requirements Review(s). see Formal Reviews .
The Target Standard will be maintained during development (under
acquirer control) in order to ensure clear and visible configuration
status of all items within the Target Standard.
Full documentary records shall be kept for the changing DCB which
will be progressively updated during the Engineering and Manufacturing
development phase. Changes will be subject to the applicable change
process which will cover Integrated Logistics Support (ILS) requirements
and interface aspects. The Design Build Standard for any prototype
will be the confirmation of achievement of the Target Standard,
as they become established during the development phase.
The Production Baseline is a purchaser agreed requirement
derived from the System Specification. Within the Production Baseline
is the Physical Baseline Build Standard (PBBS) which will be established
at an appropriate time before production go-ahead and will define
manufacturing drawing issues, Product Specifications, Software
Product Specifications, Production Acceptance Test Specifications,
etc., down to a level agreed with the purchaser.
Once established and released any subsequent changes shall be
performed by a production change process (MODs) as outlined in
this plan.
The Physical Baseline Build Standard (PBBS) will
be established in an incremental manner. Functional aspects (specifications,
etc.) will be updated through the configuration management change
process identified by this CMP.
Physical aspects will evolve and be maintained through the configuration
management status accounting within the change management process.
The point in time when the PBBS must be established (raised by
the acquirer to attain contractual status) and must be carefully
chosen.
Important aspects to be considered are:
- Production release;
- ILS activities;
- Design stability;
- Development flexibility.
They are clearly not entirely independent, and all aspects must be borne in mind. In general, it is required to wait until the system is design stable.
An authorization sheet will be provided for each
specification to enable approval signature by the responsible
persons at the SDR company and the purchaser.
Authentication by the acquirer will normally be accomplished on
the issue of the specification
Specifications shall be prepared in accordance with
the requirements specified in the Documentation Standard.
4.2.8 Engineering release and correlation of manufactured
products.
An Engineering Release system shall be established and maintained
to use the system to issue configuration documentation to the
functional activities (manufacturing, logistics, QA, acquisition,
etc.) and to authorize the use of configuration documentation
associated with the approved configuration.
Current and historical engineering release information
for all configuration documentation of all configuration items
and their component parts will be maintained.
Back to MANAGING STANDARDS 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 and under going continuous
improvement.
Please send any beneficial comments or identification of errors
using the following form to: kenr@wysywig.airtime.co.uk
