top - download
⟦cdffb0916⟧ Wang Wps File
Length: 13886 (0x363e)
Types: Wang Wps File
Notes: CPS Conf. Man. Plan
Names: »0267A «
Derivation
└─⟦e91c96c30⟧ Bits:30006069 8" Wang WCS floppy, CR 0025A
└─ ⟦this⟧ »0267A «
WangText
…02…CPS/PLN/0011
…02…KFL/801029…02……02…#
CAMPS CONFIGURATION MANAGEMENT PLAN
…02…KFL/801021…02…CAMPS
1̲ ̲ ̲S̲C̲O̲P̲E̲ ̲A̲N̲D̲ ̲P̲U̲R̲P̲O̲S̲E̲
1.1 S̲C̲O̲P̲E̲
The CAMPS configuration Management Plan describes the
rules and procedures which apply to Configuration Management
within the CAMPS programme of Christian Rovsing A/S,
Systems Division.
1.2 P̲U̲R̲P̲O̲S̲E̲
To define Configuration Management and prescribe uniform
policies and guidance for implementation of CAMPS.
Configuration Management identifies, controls, accounts
for, and audits the functional and physical characteristics
of systems, equipments, documentation, and other designated
material items developed and produced within the CAMPS
progammme.
1.3 O̲B̲J̲E̲C̲T̲I̲V̲E̲S̲
a) To assist management in achieving, at the lowest
total life cycle cost, the required performance,
realistic schedule, operational efficiency, logistic
support and readiness of configuration items.
b) To allow the maximum degree of design and development
latitude, yet introduce at the appropriate time
the degree and depth of configuration control necessary
for production and logistic support.
c) To attain maximum efficiency in the management
of engineering changes with respect to their necessity,
cost, timing, and implementation.
d) To attain the optimum degree of uniformity in policy,
procedures, data, forms and reports for configuration
management at all interfaces pertinent to the CAMPS
programme.
e) To establish configuration/data management as a
fundamental responsibility of CR in the aquisition
and logistic support of Configuration Items (CIs)
in order that:
1) Specifications, engineering drawings and related
technical data are adequate for configuration
needs and meet overall programme requirements.
2) Verified configuration technical documentation
is available when needed.
3) Configuration item standardization and compatibility
are maintained.
4) Total performance, costs, and schedule impact
of Engineering Change Proposals (ECPs), deviations
and waivers are known at the time of their
approval.
5) ECPs are processed in a timely manner and evaluated
promptly to establish target schedules.
6) The configuration of CIs is known and pertinent
physical and functional interfaces between
systems, equipments and computer programs are
documented and controlled.
7) Interfaces and interface documents are controlled
and documented.
2̲ ̲ ̲ ̲O̲R̲G̲A̲N̲I̲Z̲A̲T̲I̲O̲N̲
2.1 R̲E̲P̲O̲R̲T̲I̲N̲G̲
Configuration Management is a line function within
the CAMPS programme. The configuration manager reports
to the Deputy Programme Manager (DPM).
2.2 C̲O̲O̲R̲D̲I̲N̲A̲T̲I̲O̲N̲ ̲W̲I̲T̲H̲ ̲Q̲A̲
Although CM is a part of the CAMPS programme, close
cooperation with the Quality Assurance Department of
Systems Division is carried out where applicable.
3̲ ̲ ̲C̲O̲N̲F̲I̲G̲U̲R̲A̲T̲I̲O̲N̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
Throughout the life cycle of the CAMPS programme four
major configuration management functions will be taking
place. They are:
a) Configuration Identification
b) Configuration Control
c) Configuration Status Accounting
d) Data Management
3.1 C̲O̲N̲F̲I̲G̲U̲R̲A̲T̲I̲O̲N̲ ̲I̲D̲E̲N̲T̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
3.1.1 D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
Configuration Identification is the specification and
inventory of all configuration items (hardware, software,
spare parts, test equipment, support equipment, training
equipment, etc) and data items (documentation, management
data, engineering drawings, computer product listings,
etc.) which have been recognized as requiring special
attention throughout the programme life cycle. An agreed
upon list (CDRL) is part of the contract with each
configuration item listed being subject to the baseline
concept.
3.1.2 B̲a̲s̲e̲l̲i̲n̲i̲n̲g̲
The baseline concept is a management tool which requires
that selected items of hardware, software, and documentation
are defined, documented, and approved at designated
points throughout the programme life cycle; specifically
at those points in the cycle where it is necessary
to define a formal departure point for control af future
development or control of future changes in performance,
design, production and related technical requirements.
3.1.2.1 R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
The first baseline in the life cycle of the CAMPS programme
is the Requirements Baseline. The purpose of the requirements
baseline is to ensure that a firm understanding is
reached between the contractor and the
purchaser on what is required of the system and how
the contractor intends to satisfy those requirements.
The contractor is required to perform an analysis of
all hardware and software in the system, determining
which end user functions that the hardware and software
items serve. This analysis leads to a refined System
Specifications and supports Development Specifications
via a System Design Review (SDR) leads to establishment
of the Requirements Baseline. Changes, waivers, and/or
deviations from this baseline require CCB approval.
3.1.2.2 P̲r̲o̲d̲u̲c̲t̲ ̲B̲a̲s̲e̲l̲i̲n̲e̲
Establishment of the Requirements Baseline leads into
the Development Phase of the programme life cycle.
At this point the system technical requirements have
been stated and reviewed (System Specification and
SRR) during the Conceptual Phase; the Validation Phase
has just been completed and the required functional
characteristics and tests required to demonstrate achievement
of those characteristics have been stated and reviewed
(Development Specification and SDR). The programme
is now ready to be fully developed. A third set of
specifications shall be prepared by the contractor.
These are the Product Specifications and state functional
requirements and physical characteristics as necessary
to procure either items requiring "form, fit, and function"
interchangeability or identical items with specification
tolerances. Preparation of the Product Specifications
is closely monitored by SHAPE using a series of two
reviews and one audit. (These are the Preliminary Design
Review (PDR); the Critical Design Review (CDR); and
the Functional Configuration Audit (FCA). A completed
and approved FCA constitutes acceptance of the Product
Specifications, establishes the Product Baseline and
provides "as-built" documentation for the system.
3.1.3 C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
3.1.3.1 D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
Configuration Control is the systematic evaluation,
coordination, approval or disapproval, and implementation
of all changes to the configuration identification.
Configuration control shall be exercised on the basis
of the configuration identification appropriate to
the stage of the CI's …86…1 …02… …02… …02… …02…
life cycle. All affected activities, such as engineering,
logistic support, maintenance, procurement and operations
will participate in evaluating proposed changes in
the configuration of the CI as applicable throughout
its life cycle. The configuration of the CI will be
identified by the use of the established appropriate
baselines for the CI. All changes to these baselines
will be recorded and controlled by the Configuration
Management.
3.1.3.2 E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲ ̲C̲h̲a̲n̲g̲e̲s̲
a) Engineering changes, waivers or deviations affecting
the configuration of a CI will be limited to those
which are necessary or offer significant benefit.
Generally, the degree of benefit is directly related
to the promptness with which actions are processed.
Necessary or beneficial changes are required to:
1) correct deficiencies,
2) satisfy change in operational or logistic support
requirements,
3) prevent or allow desired slippage in an approved
schedule,
4) meet unexpected conditions.
b) Changes in the configuration of any CI after any
of the baselines have been established will be
classified as either Class I or Class II. Class
I changes are those proposed changes that affect
"form, fit, or function". Class II changes have
no effect on performance, interchangeability, cost,
maintainability, reliability, or delivery schedules.
CCB approval prior to implementation of a Class
II change is not required. However, such changes
are subject to post facto classification review
by the CCB. Examples of Class II engineering changes
are: a change in a plan or in documentation only
(e.g., correction of errors, addition of clarifying
notes or views), and a change in hardware (e.g.,
substitution of an alternative material if a specific
material is not required). Class I ECPs are used
when the change affects technical requirements
to include (but not limited …86…1 …02… …02… …02…
…02…
to) performance outside stated tolerances; reliability.
maintainability, or survivability outside stated
tolerances; weight, balance, moment of inertia;
interface characteristics.
c) Class I ECPs will be submitted in accordance with
the procedures contained in the Configuration Management
Procedures.
d) Class I ECPs must indicate a single letter code
justifying the change as necessary or beneficial.
If one or more of these codes is applicable, the
one which is most descriptive or significant shall
be assigned. Justification codes are:
1) Correction of deficiency - Code D
2) Safety - Code S
3) Interface - Code B
4) Compatibility - Code B
5) Operational or Logistics support - Code O
6) Value Engineering - Code V
7) Production stoppage - Code P
e) Class I ECP priorities. Three priorities are assigned
to Class I ECPs. They are:
1) E̲m̲e̲r̲g̲e̲n̲c̲y̲ - used to effect a change in operational
characteristics which, if not accomplished
without delay, may seriously compromise the
programme or to correct a hazardous condition
which may result in fatal or serious injury
to personnel or in extensive damage or distribution
to the equipment.
2) U̲r̲g̲e̲n̲t̲ - Used to effect a change in operational
characteristics which, if not accomplished
expeditiously, may seriously compromise the
programme effectiveness of the equipment; (or)
to correct a potentially hazardous condition
which could result in injury to personnel or
damage to the equipment; to meet significant
contractual requirements (e.g. when lead time
will necessitate slipping approved production,
activations, or construction schedules); or
to effect interface change.
3) R̲o̲u̲t̲i̲n̲e̲ - Used to effect a change when emergency
or urgent is not applicable.
f) Engineering change proposals are prepared in accordance
with the instructions provided requiring a complete
analysis of the impact if the proposed engineering
change were not implemented. It requires that the
package submitted with an engineering change proposal
contain a description of all known interface effects
and information concerning changes required in
the baselines. It further requires the submission
of supporting data outlining the impact upon integrated
logistic support as well as overall estimated cost
impact.
g) To provide for proper change evaluation, processing,
approval/disapproval and implementation, a Configuration
Control Board (CCB) will be established. The CCB
will be only official agency to act on all proposed
changes. CR appoints the chairman of CCB, and CR
CAMPS Configuration Manager serves as secretary
of the board.
3.1.4 C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲S̲t̲a̲t̲u̲s̲ ̲A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲
a) The status accounting function provides traceability
of configuration baselines and changes thereto
and acts as a management tool for accomplishing
all related tasks resulting from such changes.
Status accounting data and reports may exist in
any one of several formats and in a variety of
volume levels; structure and mechanization of the
function are dictated by the programme's needs
and volume, formats, change activity, and any special
constraints that have been imposed.
b) Configuration management records/reports will assure
that:
1) There will be a configuration record documenting
all approved changes to all designated CIs.
2) Configuration status accounting reporting of
a configuration item mission, design, series
or type, and model will be initiated at the
time the configuration baseline is approved.
The configuration management shall assure that
configuration status accounting is maintained
…86…1 …02… …02… …02… …02…
until the last unit of the configuration type,
model, series is delivered, and shall assure
that status accounting continues to reflect
the latest configuration of any of the delivered
items.
3) The accomplishment of updating/retrofit changes
will be reported in order to maintain status
on all configuration items in the custody of
contractor, unless otherwise directed by the
contract.
3.1.5 D̲a̲t̲a̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
a) Throughout the life cycle of the programme certain
data requirements will be recognized. These requirements
may be recorded as pictorial delineations in media
such as drawings or photographs; text in specifications
or related performance or design type documents;
in machine forms such as punched cards, magnetic
tape, computer memory printouts; or it may be retained
in computer memory. Examples of recorded information
include engineering drawings and associated lists,
specifications, standards, progress and/or test
reports, technical reports, manuals or other information.
b) Data requirements must be recognized early in order
to ensure data adequacy.
c) Contract Data Requirements List (CRDL).
The data requirements is included as a part of
the contract as the Contract Data Requirements
List (CDRL) and will become the sole list of data
requirements which the contractor will be obligated
to deliver under the contract.
