MSFC-STD-3394
National Aeronautics and REVISION A
Space Administration January 31, 2005
George C. Marshall Space Flight Center
Marshall Space Flight Center, AL 35812
ED03
STANDARD FOR
CONTRACTOR CONFIGURATION MANAGEMENT
FOR MSFC PROGRAMS/PROJECTS
Approved for Public Release; Distribution is Unlimited
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 2 of 70
DOCUMENT HISTORY LOG
Status
(Baseline/
Revision/
Canceled)
Document
Revision
Effective
Date
Description
Baseline
09/30/2003 Initial Release
Revision A 01/31/2005 General: updated language utilizing “shall” for requirements
(avoiding use of must or will) per Rules Review; 2.0 Changes
reflecting new Marshall Program Requirements; 6.1 change
acknowledging variance in selection CIs for technology studies;
6.4 change providing greater detail on engineering drawing
requirements and content; 6.4.2 Added section for CAD models;
7.1 Add text specifying location of engineering release system; 8.7
New paragraph defining post-deployment software/firmware
change process; 8.7 Added information relative to MSFC form
460 in the deviation/waiver process; 9.3.5 Add paragraph
describing software status accounting; 10.2 Added requirement
for specific planning issued to be addressed during planning; 10.3
Made allowances for Government overview of FCA/PCA, added
requirement for Contractor to actually “do” the as-built/as-
designed review, and added contractor duties regarding
software/firmware, made miscellaneous changes to clarify
contractor support; 10.4 Added contractor administrative and
technical responsibilities; 11.2 New paragraph describing CM
utilization of results of Independent Verification and Validation
(IV&V); 11.3 Describes delivery of the software product; 11.4
Adds marking and labeling instructions for software/firmware;
Appendix A added specific coverage for software/firmware;
Appendix B added for software configuration management plan;
Appendix C added sample copy of MSFC form 460; Appendix D
added new write-up for Acceptance Data Package expands
delivery of ADP to require updated delivery when
hardware/software is shipped to a new location and to ; includes
separate requirements for hardware different from
software/firmware. Added guidance Appendices H - Guidance for
Processing Urgent-Emergency Software Changes and Appendix I
– Documentation Guidance for FCA/PCA.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 3 of 70
TABLE OF CONTENTS
PARAGRAPH PAGE
FOREWORD .............................................................................................................................5
1. SCOPE/PURPOSE..........................................................................................................6
1.1 Scope/Purpose.................................................................................................................6
1.2 Applicability ......................................................................................................................6
2. APPLICABLE AND REFERENCE DOCUMENTS .........................................................6
2.1 Applicable Documents .....................................................................................................6
2.2 Reference Documents .....................................................................................................7
3. ACRONYMS/DEFINITIONS ............................................................................................7
4. GENERAL REQUIREMENTS..........................................................................................7
5. CONFIGURATION MANAGEMENT PLANNING............................................................8
5.1 General ............................................................................................................................8
5.2 Contractor’s CM Plans .....................................................................................................8
6. IDENTIFICATION ............................................................................................................8
6.1 Configuration Identification...............................................................................................8
6.2 Specifications.................................................................................................................10
6.3 Interface Identification....................................................................................................11
6.4 Drawing and Models ......................................................................................................13
6.5 Identification Numbering ................................................................................................15
6.6 Lot and Serial Numbering ..............................................................................................17
7. ENGINEERING RELEASE INFORMATION..................................................................18
7.1 Engineering Release......................................................................................................18
7.2 Elements of Data Required for Hardware Items.............................................................19
7.3 Elements of Data Required for Software Items..............................................................20
7.4 Production Release Functional Capabilities...................................................................20
7.5 Release of Engineering Changes ..................................................................................21
7.6 Field Release Functional Capabilities............................................................................21
8. CONFIGURATION CONTROL......................................................................................21
8.1 General ..........................................................................................................................21
8.2 Configuration Control Boards.........................................................................................21
8.3 Changes, Deviations, and Waivers................................................................................21
8.4 Engineering Change Proposal .......................................................................................23
8.5 Record Engineering Change Proposal...........................................................................23
8.6 Field Engineering Change (FEC)...................................................................................23
8.7 Software/Firmware Field Engineering Change ..............................................................23
8.8 Deviation and Waiver Request.......................................................................................24
8.9 Modification Kit and Instructions ....................................................................................24
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 4 of 70
TABLE OF CONTENTS (Continued)
PARAGRAPH PAGE
9. CONFIGURATION ACCOUNTING................................................................................26
9.1 General ..........................................................................................................................26
9.2 Configuration Accounting Requirements........................................................................26
9.3 Configuration Accounting Records.................................................................................26
10. CONFIGURATION VERIFICATION AND AUDIT..........................................................28
10.1 General ..........................................................................................................................28
10.2 Planning .........................................................................................................................28
10.3 Contractor Support.........................................................................................................28
10.4 Objectives ......................................................................................................................29
10.5 Contractor Responsibilities ............................................................................................30
10.6 In-process Configuration Management Audits...............................................................31
10.7 “Other” Reviews .............................................................................................................31
11. SOFTWARE CONFIGURATION MANAGEMENT ........................................................32
11.1 Preparation.....................................................................................................................32
11.2 Independent Verification and Validation (IV&V).............................................................32
11.3 Delivery ..........................................................................................................................32
11.4 Software/Firmware marking and Labeling......................................................................32
LIST OF TABLES
Table Page
I Class I Change Definition...............................................................................................25
APPENDICES
Appendix Page
A Configuration Management Plan....................................................................................34
B Software Configuration Plan ..........................................................................................39
C Specification Change Notice and Instructions................................................................42
D Interface Control.............................................................................................................43
E Change Control..............................................................................................................45
F Acceptance Data Package.............................................................................................58
G Definitions, Abbreviations and Acronyms.......................................................................62
H Guidance for Processing Urgent-Emergency Software Changes..................................68
I Documentation Guidance for FCA/PCA.........................................................................70
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 5 of 70
FOREWORD
This standard defines configuration management principles for design, development,
integration, operation, and logistical support of Configuration Items and Computer Software
Configuration Items managed by MSFC throughout the acquisition life cycle. It incorporates
the industry-Government consensus standard ANSI-EIA 649 principles.
The focus of this standard is on performance requirements rather than the details of the
design solution. MSFC management of the CM process is based on insight of contractor
practice and application of ANSI-EIA 649 principles. These principles are relevant to
configuration management practices through the entire life cycle, including "technology"
programs where technology is the precursor to product development.
This standard applies only to the extent specified in contracts.
An important function of this standard is to facilitate the use of automation tools by providing
standard criteria of the CM process. The predominant media for exchange of information
has transitioned from a paper base to a digital one. Information technology concepts and
standards for data access, data transfer, and data sharing have increased the opportunity
for Government and industry to productively integrate information from distributed sources.
This leads to a true virtual enterprise that includes all the Configuration Management
information necessary for the life cycle support and maintenance of equipment and
software.
Forms cited herein are available at http://starbase.msfc.nasa.gov:8000/forms/forms.taf
Usage of these forms is not mandatory; contractor-equivalent forms may be used as long as the
content of information requested is furnished.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 6 of 70
STANDARD CONTRACTOR CONFIGURATION MANAGEMENT
REQUIREMENTS, MSFC PROGRAMS/PROJECTS
1. SCOPE/PURPOSE
1.1
Scope/Purpose. The purpose of this document is to establish requirements for
implementing Configuration Management (CM) on MSFC contracts to design, develop,
fabricate, integrate, operate, or provide logistical support to hardware, software, and firmware
items. This document also establishes requirements for MSFC contracts providing technology
or requirements that are precursors of program design.
1.2
Applicability. This document is applicable to all MSFC contractors performing design,
development, fabrication, integration, operations, or logistical products and services for MSFC
programs or projects. These standards apply to flight, flight demos, protoflight, and ground
support equipment and may be tailored by the individual programs/projects.
2. APPLICABLE AND REFERENCE DOCUMENTS
2.1
Applicable Documents. The following documents of the issue in effect on the date of
incorporation of these requirements form a part of this document to the extent specified herein.
2.1.1
Federal Documents.
Cataloging
Handbook H4/H8
MIL-STD-130
MIL-STD-961
MIL-STD-962
MPR 8040.1
NPD 2190.1
NPR 2200.2
Commercial and Government Entity (CAGE) Codes
Identification Marking of U.S. Military Property
Defense Specifications
Defense Standards and Handbooks
Configuration Management, MSFC Program/Projects (Appendix
Z, CM Audits)
NASA Export Control Program
Requirements for Documentation, Approval, and Dissemination
of NASA Scientific and Technical Information
NPR 7150.2 NASA Software Engineering Requirements
2.1.2
Industrial Standards.
ASME Y14.5 Dimensioning and Tolerancing
ASME Y14.24 Types and Applications of Engineering Drawings
ASME Y14.35 Revision of Engineering Drawings and Associated Documents
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 7 of 70
ASME Y14.41 Digital Product Definition Data Practices
ASME Y14.100 Engineering Drawing Practices
IEEE/EIA 12207 Software Life Cycle Process
IEEE 1042 Guide to Software Configuration Management
2.2 Reference Documents.
ANSI/EIA 649 National Consensus Standard for Configuration Management
OMB Circular A-130 Management of Federal Information Resources
DD Form 250 Material Inspection and Receiving Report
DD Form 1149 Requisition and Invoice/Shipping Document
MSFC Form 460 Discrepancy Record
MSFC Form 847 Deviation/Waiver Approval Request (DAR)
MSFC Form 2348 Engineering Change Proposal
MSFC Form 2490 Installation Notice Card (INC)
MSFC Form 4229 Preliminary/Interface Revision Notice (PIRN/IRN)
MSFC Form 4242 Record Engineering Change Proposal
3. ACRONYMS/DEFINITIONS
For a definition of terms and a list of abbreviations and acronyms used in this document, see
Appendix G.
4. GENERAL REQUIREMENTS
The contractor shall establish a CM program covering the appropriate life-cycle phases of the
applicable Configuration Items (CIs) and Computer Software Configuration Items (CSCIs). In
this document, CI is a broad term that includes CSCI whenever appropriate. The requirements
of this document shall be implemented and tailored as stated in the contract Statement of Work
(SOW) and consist of the following elements:
a. Configuration Identification
b. Configuration Control
c. Configuration Status Accounting
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 8 of 70
d. Configuration Verification; Configuration Verification/Validation for Software/Firmware
The contractor shall assure that all appropriate subcontractors comply with the requirements of
this CM program.
5. CONFIGURATION MANAGEMENT PLANNING
5.1
General. The contractor shall plan a CM program in accordance with the requirements
defined in this standard. The CM program shall be tailored appropriately for the particular CIs,
their scope and complexity, and the contracted phase(s) of the life cycle.
5.2
Contractor's CM Plans. The contractor shall develop a CM plan or plans that describe
the processes, methods, forms, and procedures to be used for management of the functional
and physical characteristics of the CIs. The CM plan, when approved, forms the basis for
implementation of CM requirements and shall be maintained by the contractor. The content and
format of the CM plan shall be in accordance with Appendix A as tailored by the contract. The
software CM plan shall be prepared in accordance with contract direction. The contractor shall
submit the CM plan and changes thereto in accordance with the contract Data Procurement
Document (DPD).
6. IDENTIFICATION
6.1
Configuration Identification. Configuration Identification is the basis from which the
configuration of products is defined and verified; products and documents are labeled; changes
are managed; and accountability is maintained. The contractor shall implement configuration
identification for every CI.
Note: Technology driven programs defy clear definitions of what constitutes a configuration
item. Typically government funded studies on technology issues do not result in a designed
product requiring configuration management. Prototypes that are scaled down visual models or
computer programs that are simply Computer-Off-The-Shelf (COTS) unmodified software or
even applications of common desktop programs may be better handled without formal control of
design. On the other hand, formal requirements, controlled design over a life cycle, and a formal
changes clause in the contract indicate that hardware or software requires formal configuration
management to control. The configuration management plan shall identify these items, if not
initially, then in a future revision.
Note: The term “configuration item” should not be applied to software products that are
employed in the development process of a Program/Project, and considered Computer-Off-The-
Shelf (COTS) software. Configuration item would apply to those software products that are the
result of specific design requirements generated for the Program/Project, and therefore would
be subject to formal configuration management control for the duration of the Program/Project
lifecycle. These configuration items shall be identified in the Configuration Management (CM)
Plan.
6.1.1
Configuration Identification Baselines. The contractor shall accomplish configuration
identification through formal documentation that defines the baseline being established and
provides for the control and accounting of future changes to that baseline. The design of each
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 9 of 70
CI progresses through baseline evolution from basic requirements into a final verified and built
product. The baselines are defined as the Functional Baseline, Allocated Baseline,
Development Baseline, and Product Baseline. A baseline identifies an agreed-to description of
attributes of a CI at a point in time and provides a known configuration to which changes are
addressed. Baselines are established by agreeing to (and documenting) the stated definition of
a CIs attributes. The approved "current" baseline defines the basis of the subsequent change.
a.
Functional Baseline. The Functional Baseline is the approved configuration documentation
that describes a system's or top-level CIs performance requirements (functional, interoperability,
and interface characteristics) and the verification required to demonstrate the achievement of
those specified characteristics. The Functional Baseline is controlled by the Government.
b.
Allocated Baseline – The Allocated Baseline is the approved performance-oriented
configuration documentation for a CI to be developed that describes the functional and interface
characteristics that are allocated from a higher level requirements document or a CI and the
verification required to demonstrate achievement of those specified characteristics. The
allocated baseline extends the top-level performance requirements of the functional baseline to
sufficient detail for initiating manufacturing or coding of a CI. The Allocated Baseline is
controlled by the Government.
c.
Development Baseline. The Development Baseline is the contractor's design and
associated technical documentation that defines the contractor’s evolving design solution during
development of a CI. The developmental configuration for a CI consists of contractor internally-
released technical documentation for hardware and software design that is under the
developing contractor's configuration control.
d.
Product Baseline - The Product Baseline is the approved technical documentation that
describes the configuration of a CI during the production, fielding/deployment and operational
support phases of its life cycle. It is not established until successful certification following a
Functional Configuration Audit and a Physical Configuration Audit. The product baseline
describes:
— Detailed physical or form, fit, and function characteristics of a CI
— The selected functional characteristics designated for production acceptance testing
— The production acceptance test requirements.
Once the Product Baseline is established, the Government determines how it shall be
controlled.
6.1.2
Functional and Allocated Baseline Relationships. Interface control documents are
considered part of the functional and/or allocated baselines to the extent that they are
referenced in and supplement the performance specifications that constitute the applicable
baselines. Contractor implementation of the Functional and Allocated Baseline Requirements
involves the creation and release of engineering documentation that incrementally defines the
configuration of the specific product. The function and allocated baseline represents the
contractor’s detailed design solution and is controlled by the Government. It may or may not
include a detail specification for the product. The contractor is responsible for the configuration
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 10 of 70
control of the developmental configuration and may iteratively design, release, prototype, and
test until the functional and allocated requirements are satisfied. The developmental
configuration ultimately includes the complete set of released and approved engineering design
documents, such as the engineering drawings and associated lists for hardware, software, and
interface and database design documents for software. By reference within this documentation,
it also includes test and verification documents.
6.1.3
Product Baseline Requirements. The product baseline is the approved documentation
that completely describes the functional and physical characteristics of the CI, and any required
joint and combined operation’s interoperability characteristics of a CI (including a
comprehensive summary of the other environment(s) and allied interfacing CIs or systems and
equipment). It consists of the Product Configuration Identification which defines the
configuration of a CI during production, operation, maintenance and logistic support phases of
its life cycle and which prescribes the requirements for 1) fit and function characteristics of a CI,
2) the functional characteristics selected for production acceptance testing, and 3) the
production acceptance tests.
The Product Configuration Identification includes the complete set of released and approved
engineering design documents such as engineering models, engineering drawings and
associated lists for hardware, software, interfaces, operations documentation, and database
design documents for software. (These are the configurations of the documents that were
considered the developmental configuration.) The product baseline may include the 2-D
drawings or a 3-D engineering model of a hardware product, and for software a representation
of the CSCI source code. It also includes by reference the material and process specifications
invoked by the engineering documentation.
6.2
Specifications. Each CI shall be documented in a performance specification as defined
in MIL-STD-961. At the system or program level, Systems Specifications or a System
Requirements document may be required to establish comprehensive and definitive set of
system performance requirements. These shall follow the same content requirements as exist
for CI specifications. (Exceptions shall be documented in the Configuration Management Plan.)
Note: MIL-STD-961 describes different types of specifications, including performance
specifications, detail specifications, and program-unique specifications. A program-unique
specification is prepared when there is little likelihood that the requirements will extend beyond
a single program. A program-unique specification can be prepared as a
performance
specification or a detailed specification. A performance specification defines requirements in
terms of results required and criteria for verifying compliance. A detailed specification goes
beyond describing functions and defines in detail the methodology to build the product.
Specifications are also categorized as to type-like system specification, Configuration Item (CI)
specification, material specification, software specification, or process specification.
6.2.1
Specification Requirements. The contractor shall prepare a performance specification
as a program-unique document for each identified CI in accordance with MIL-STD-961. For
software specifications and requirements, the contractor shall prepare documentation in
accordance with IEEE 12207 and IEEE 1042.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 11 of 70
6.2.2 Requirements When Submitting Specification Changes. The contractor shall provide
detailed change information when proposing changes to baselined specifications and shall
maintain traceability of changes to other baselines for each specification.
6.2.2.1
Specification Changes. When a change to a specification is proposed, the proposed
revision shall be described verbatim with a "From/To" language or graphics, if the change is less
than 25 percent of the specification. If the change is greater than 25 percent, a general
description of the changes shall identify individual sections and/or paragraphs being changed
with a brief explanation. Information regarding application of the change that is described in
Appendix C shall be apparent either by referencing an ECP or as header information describing
the change. There is no prescribed format.
Note: The editing tool of common word processors may be used as a means of submitting
from/to language.
6.2.2.2
Specification History Log. All approved changes shall be prepared as a revision and
each specification shall contain a Specification History Log in the front of each document.
(Specification change pages in lieu of a revision may be used only as an exception and with
prior authorization in the Configuration Management Plan.) The history log records all changes
(approved, disapproved, or pending) issued against the specification. The log shall also provide
a chronological listing of all changes to the specification. Appendix C shows content. There is
no prescribed format.
6.2.2.3
Distribution Restrictions. The contractor shall identify notices of availability and
limitation statements as required in accordance with public law, federal regulations, and
contractual requirements. The contractor shall assess each document and provide a
determination on distribution restrictions. Generic or general statements like “may contain
export control data” are not acceptable. Areas of limitation include: International Traffic in Arms
Regulations (ITAR) Notice; Export Administration Act (EAR) Notice; Trade Secrets or
Confidential Commercial Information; Copyright; Small Business Innovative Research (SBIR)
Data; and Publicly Available Documents. (Reference NPD 2190.1.)
6.3
Interface Identification. The contractor shall comply with the imposed interface
requirements and shall establish interface identification documentation as required by contract
provisions and systems integration considerations. These interface identifications shall become
a portion of the Functional and Allocated Baseline definitions. Interface documentation consists
of Interface Control Documents (ICDs) and/or Interface Requirements Documents (IRDs).
6.3.1
Interface Requirements Documents. The contractor shall comply with and/or develop
IRDs as required by the contract Statement of Work requirements. The IRD defines interface
requirements to be controlled between programs, projects, systems, or CIs. The specifications
for the interfacing elements shall reference and identify the current and applicable IRDs.
6.3.2
Interface Control Documents. ICDs are the design solutions to the IRDs. The contractor
shall prepare or support preparation of ICDs to identify the physical, functional, and/or
procedural parameters that are to be controlled between interfacing elements.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 12 of 70
6.3.3 Interface Change Control. Following IRD/ICD baseline establishment, any changes
affecting the IRD/ICD approved baselines shall be a Class I change. (See paragraph 8.3.3 for
definition of Class I change.)
6.3.3.1
IRD/ICD Revision. Interface document revision involves the total reissuance of the
document and shall be accomplished only to incorporate approved Interface Revision Notices
(IRNs). Revisions to IRDs/ICDs are made concurrently with IRN approval or periodically to
incorporate multiple approved IRNs. The contractor’s Configuration Management Plan shall
tailor the policy to program/projects requirements. The revised document shall be submitted for
approval in the same manner prescribed for the initial submission.
6.3.3.2
IRN Process. When a contractor desires, or is directed by MSFC to make a change to
an interface document, the proposed change shall be documented as a Preliminary Interface
Revision Notice (PIRN). All changes to interfaces are initiated with a PIRN which permits
coordination of the technical interfaces among the different organizations. The PIRN shall be
coordinated among all parties of the affected interface before it is submitted for approval. The
PIRN shall be submitted by an Engineering Change Proposal (ECP) in accordance with
implementing instructions for processing changes. (See paragraph 8 for processing ECPs.)
Changes to specifications that may be associated with the change to the interface shall also be
submitted as part of the ECP. Note that a PIRN utilizes the same format as the IRN. Until
approved, the input is designated with the word “preliminary” (PIRN). If the contractor cannot
agree to the PIRN during review and evaluation, the contractor shall submit an alternate PIRN
by ECP to MSFC for consideration and disposition. The PIRN requires approval from all parties
affected by the interface. Appendix D shows an example of the PIRN/IRN format.
Proposed interface document changes initiated by other activities and submitted for the
contractor review and evaluation shall require coordination and response in accordance with
implementing instructions for processing changes. When a change to an IRD/ICD is proposed
by another entity, the contractor shall acknowledge receipt and release of the change into its
baseline. If the change is to be incorporated without affecting the cost, schedule, or other
principal articles of the contract, the contractor shall agree to acceptance of the change with a
“Record” ECP (RECP). (See paragraph 8.5.)
When not designated as interface document custodian, the contractor shall review proposed
IRDs/ICDs from other interfacing contractors and/or agencies. Upon receipt of proposed
IRDs/ICDs, the contractor shall assess impact, coordinate as necessary, and take one of the
following actions:
a. Submit an RECP.
b. If the interface document is not a contractual requirement, but is compatible with the
contractor's detailed design, submit an ECP with specification changes incorporating the
IRD/ICD in the development specification CI documentation.
c. If the interface document is incompatible with the contractor’s detailed design, submit an
ECP identifying required changes in accordance with implementing instructions for
processing changes, including specification changes as required.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 13 of 70
6.3.4 Contractor Developed and Maintained Interface Documents. When designated as an
interface document custodian, the contractor shall be responsible for initial preparation of
Interface Requirements Documents/Interface Control Drawings (IRDs/ICDs). IRDs shall comply
with the format for Interface Standards as defined in MIL-STD-962 and shall specify basic
performance requirements that are defined for visibility and control. ICDs shall comply with the
requirements for interface control drawings/documents specified in industry standard
ASME Y14.24 (drawings) or MIL-STD-962 (documents). ICDs shall record quantified design
interfaces between participating contractors and/or Government agencies.
The contractor shall be responsible for technical coordination with other parties involved with the
interface. The contractor shall provide periodic status of this coordination activity and shall
advise MSFC of any design, operational, or procedural differences, including recommended
resolution, between interfacing parties.
The proposed initial interface document baseline shall be submitted by an Engineering Change
Proposal (ECP). MSFC approval of the ECP provides authority for release and distribution of
the interface documents.
6.3.5
Interface Designation on Associated Documentation/Drawings.
Documentation/drawings affecting any interface require interface control management
coordination and action. The following statement shall be entered on the first sheet of the
document/drawing immediately above the title block:
"This drawing/document contains information controlled by an IRD/ICD. No changes shall be
made to information controlled by an IRD/ICD prior to interface control management
authorization."
6.4
Drawing and Models
6.4.1
Drawings. A drawing discloses by means of graphical or textual presentation or a
combination of both the physical and functional definition of a product. The drawing along with
associated lists and notes define the detailed design, the attributes of which are verified through
testing. Drawings reflect the end-product and provide information for manufacturing, testing,
quality, training, and operations. Released drawings reflect the status of design at an exact point
in time. Drawings provide data regarding sources of supply when a part is built by an outside
vendor.
6.4.1.1 Each drawing shall be designated with a drawing number and each drawing shall
reflect the next higher assembly until a top assembly is defined. The sum of all drawings
represents the complete design of the product.
6.4.1.2 The contractor shall prepare drawings in accordance with ASME Y14.100.
Part I drawings shall define the following:
a. Reflect the end-product at its current level of design maturing
b. Provide the engineering data for logistics support products
c. Provide the necessary data to permit manufacture and/or acquisition of items identical to
the original item
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 14 of 70
d. Document directly or by reference the following
(1) Details of unique processes (i.e. not published or generally available to industry)
when essential to design and manufacture
(2) Performance ratings
(3) Critical manufacturing processes and assembly sequences, and rigging procedures
(4) Diagrams
(5) Mechanical and electrical connections
(6) Physical character tics, including form and finish
(7) Details of material identification, including heat treatment and protective coating
(8) Inspection, test, and evaluation criteria
(9) Equipment calibration requirements
(10) Quality assurance requirements
(11) Hardware marking requirements
(12) Requirements for reliability, maintainability, environmental conditions, shock and
vibration testing and other operation or functional tests
Part II Cable interconnect diagrams (CIDs) electrical system schematics, wiring lists, and fluid
system schematics shall include the following:
a. Cable interconnect diagrams shall show graphically the arrangement of external electrical
cabling which interconnects electrical assemblies and/or equipment. The CID shall show all
cable runs and terminations; each cable shall be identified by reference designation number.
The connector short sign shall be identified.
b. Electrical system schematics shall illustrate and describe circuit items with symbols placed
such that a circuit may be traced from item to item in the sequence of its function. The
placement and arrangement of these circuits shall follow a logical sequence of presentation
to provide a clear description of distribution.
c. Schematics and/or wiring list for components, including interconnection cable harnesses
shall be provided.
d. The grounding schematics shall show the details of all grounds and power returns from
source to loads. All connections shall be shown in overall grounding documentation. The
schematics shall also show details of all electrical ground support equipment
interconnections to facility and show all safety grounds.
e. The fluid system schematics shall illustrate and describe all components with systems and
flow designators such that the fluid system maybe be traced from component to components
(such as pumps, valves, meters, regulators, and filters). The schematic shall document the
range requirements (flow, temperature, and pressure) for all component external interfaces
and line sizes. The placement and arrangement of these components shall follow a logical
sequence or presentation to provide a clear description of the flow of fluids in the system.
The schematics shall reference engineering drawings and associated lists for configuration
details.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 15 of 70
f. General drawing practices, drawing titles, and markings on drawing shall follow ASME
Y14.100.
g. The contractor shall revise engineering drawings and associated documents in accordance
with ASME Y14.35M.
6.4.1.3 Geometric dimensioning and tolerancing for drawings and models shall be applied as
described in ANSI Y14.5. GDT shall be used between all external and major internal interfaces.
6.4.1.4 Proprietary restrictions, such as limited rights and licensing, shall be marked on the
applicable drawing sheets with the appropriate approved legend within the field of the drawing.
Drawings otherwise restricted, such as export control, shall also be marked within the field of
the drawing.
6.4.2
Models. Computer Aided Design (CAD) models assist designers in preparing
drawings, specifications, parts lists, and other design-related elements using special graphics
and calculation-intensive computer programs. Its output is a three-dimensional model that
defines geometry (point, surface, curve, solid); topography (connectivity and order of
relationships of vertex, edge, face, object); and domain or structure (product position and
attributes). The CAD model greatly enhances the design process and detects errors before the
manufacturing process begins.
6.4.2.1 The contractor shall prepare digital data on a CAD in accordance with ASME Y14.41.
The contractor shall be capable of providing two dimensional drawings to the government for
design reviews, audits, or for other purposes.
6.4.2.2 The contractor shall use CAD as a means of developing design, using a neutral
format that shall be agreed to between the Government and the Contractor. The neutral format
serves as means of data transfer between dissimilar systems. Translators, developed to the
neutral standard, are used to export a design between the system of original and the destination
system. The model may be delivered to the Government by CD, DVD, or direct electronic
transfer. The CAD model vendor utilized by the contractor and the means of transfer shall be
negotiated between the contractor and the Government.
Note: MSFC design organizations use the following CAD vendor products: Ideas, Mentor
Graphics Expedition series, ProEngineer, Solid Edge, and Unigraphics.
6.5
Identification Numbering.
6.5.1
General. The contractor shall apply an identification numbering system that provides a
unique identification number for items and supporting documentation. Individual units of a
product shall be assigned a unique product unit identifier (serial/lot number) when there is a
need to distinguish one unit of the product from another unit of the product, each of which are
the same configuration. The product composition, (i.e. relationship and quantity of parts that
compose the product) is determinable from its configuration documentation. That is, there is a
hierarchical relationship of all parts composing the product. Assignment and use of numbers
and other identifiers shall be used for configuration identification, control, and accounting of all
(hardware, software, firmware) CIs, related equipment, and associated documentation. The
types of identification numbers include:
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 16 of 70
a. Document identification numbers
b. CI, system, subsystem, and part Identification
c. Software identifiers
d. Serial and lot numbers
e. Design activity (Commercial and Government Entity) CAGE Code
6.5.2
Identifiers Assigned by Other Design Activities. Where the CI incorporates the design of
a Government agency or of another contractor, subcontractor, vendor or supplier, the contractor
shall use identifiers assigned by these design activities without reidentification, except as
authorized by MSFC. An exception is noted to allow a new number when a part is procured
under a source control drawing.
6.5.3
Specification Identification. The contractor shall assign each specification an
identification number. Once a specification is identified, it shall maintain that identification
throughout the life of the program. The contractor shall uniquely identify specifications,
specification revisions, and specification changes. These numbers shall uniquely identify all
specifications required to control the design, fabrication, and test of hardware and computer
software items under MSFC contracts. The numbering system shall be identified in the
contractor's Configuration Management plan.
6.5.3.1
Government or Industry Specification Numbers. The contractor shall not apply further
identification to Government or industry specifications or standards unless the specifications or
standards are altered.
6.5.3.2
Specification Identification Number Records. The contractor shall develop and maintain
a record of all contractor-prepared specifications, including the revision level and specification
change status.
6.5.4
Interface Requirements/Control Documents. Consistent and accurate use of
identification numbers is required. If the contractor is responsible for development and
maintenance of an ICD/IRD, the numbering scheme shall be identified in the Configuration
Management Plan.
6.5.5
Drawing and Part Numbering. The contractor shall assign drawing and part identification
numbers in accordance with principles described in ASME Y14.100.
6.5.6
CI Selection and Numbering. The contractor shall assign unique identification numbers
to all CIs. These numbers are used by MSFC upon delivery and shall be maintained throughout
the life of the CI. The contractor shall select and recommend potential CIs to the Government.
Any item requiring logistics support or designated for separate procurement is a CI. The
contractor may designate CIs at any time during the life cycle of the program. Computer
hardware shall be treated as CIs. CI selection involves the grouping of software into
manageable entities based on coherence of design, implementation, and test. Other
considerations in the selection of CIs are risk, safety, complexity of interfaces, user interface,
and functionality. The final CI selection is made by the Government.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 17 of 70
6.5.7
Changing Drawing and Part Numbers. Before the Product Baseline or initiation of
manufacturing, release of a part drawing into the contractor’s Development Baseline is
accomplished by drawing change letter control. Thereafter, drawing change letter control shall
continue and part numbers shall be controlled and changed in accordance with the
requirements of ASME Y14.100 as follows:
a. When performance or durability is affected to such an extent that the previous versions
are required to be discarded or modified for reasons of safety or malfunction. A Part
Identification Number (PIN) shall also be assigned to all subsequent higher assemblies
up to the level at which interchangeability is reestablished.
b. When the new version of an item is not interchangeable with the previous version.
c. When a repair part within an item is changed so that it is no longer interchangeable with
its previous version. (A new PIN shall also be assigned to all subsequent higher
assemblies up to the level at which interchangeability is reestablished. (Either the
original or the new item may be used in all units of all next higher assemblies.))
d. When the previous version of an item is limited to use in specific articles or models of
articles, and its new version is not so limited. (A new PIN shall also be assigned to all
subsequent higher assemblies up to the level at which interchangeability is
reestablished.)
e. When a part used on multiple articles is changed so that it has limited effectivities.
f. When an item is changed in such a way that it necessitates a change to an operational
test, self-test, or maintenance test computer program. A new PIN shall be assigned to all
subsequent higher assemblies up to the level at which computer programs are no longer
affected.
g. When the design of the item is controlled by the contractor, the item may be identified by
a standard specification identification number when all the following criteria apply:
(1) It has a multiple usage and is expected to have a design application in more than
one CI.
(2) It is non-repairable (throw away) and is not to be provisioned under the contract
below the level identified by the standard specification identification number.
(3) It is completely specified in a specification document or source control drawing
with respect to performance, durability, reliability, form, fit, qualification, and
inspection requirements.
(4) Unless otherwise concurred in by MSFC, one or more alternate sources are
approved and qualified to supply the item.
6.6
Lot and Serial Numbering. The contractor shall utilize lot and serial numbering for
proper identification and control of components, parts, and CIs. Lot and serial numbers allow
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 18 of 70
one product to be distinguishable from another; identify the source of a product; and allow the
correct product information to be identified and retrieved.
6.6.1
Serial Numbers.
6.6.1.1
General. The contractor shall assign serial numbers to all complete units of a CI and to
critical parts and components when traceability is necessary. The contractor shall record and
maintain serial numbers assigned by subcontractors and suppliers/vendors.
6.6.1.2
CI Serial Numbers. Serial numbers shall be used for unit identification and engineering
effectivity. The contractor shall record serial numbers on all applicable manufacturing records
and configuration accounting records for each item.
6.6.1.3
Critical Parts and Components (Items) Serial Numbers. When serialization is required,
serial numbers shall be permanently assigned in numerical sequence for a particular part
number and shall not be changed even though the component, assembly, or part has been
identified by a new part number. The serial number shall be applied to the part in accordance
with MIL-STD-130 and shall be recorded on all manufacturing records and configuration
accounting records.
6.6.2
Lot Numbers.
6.6.2.1
General. A lot number is a unique number assigned to items that have been fabricated
from a particular batch of material, have undergone a particular process, or have been
manufactured/tested in a group with each item in the group having an identical history. For
items meeting the above criteria and which are not serialized, the contractor shall assign lot
numbers to contractor-developed and fabricated items and shall maintain lot numbers assigned
by suppliers.
6.6.2.2
Recording of Lot Numbers. The contractor shall record lot numbers on all
manufacturing records and configuration accounting records. In addition, the contractor shall
develop and maintain a utilization list that cross-references the item, component, or part lot
number to the next higher assembly to ensure traceability of lot numbers incorporated into next
higher assemblies.
7. ENGINEERING RELEASE INFORMATION
7.1
Engineering Release. The contractor shall establish an engineering release system to
issue configuration documentation to functional activities and to authorize the use of
configuration documentation associated with an approved configuration. The contractor shall
maintain current and historical engineering release information for all CIs and their component
parts. The contractor shall release engineering documentation for which it has design
responsibility or for equipment furnished to the contractor as Government Furnished Equipment
(GFE). Engineering release actions shall cite the authority for the release (ECP, CCBD,
contract letter). The contractor shall also cite the release authority for internal engineering
releases. The engineering release system shall be capable of defining product attributes and
shall be in such a format as to allow recovery and review to assure an actual match with actual
built units. The engineering release shall be included in configuration status accounting
records.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 19 of 70
7.1.1
Specification Release and Approval. For contractor-prepared specifications, the
contractor shall submit the proposed specification by ECP to MSFC for approval if required by
contract. The Government reviews the ECP and specification and provides comments to the
contractor as necessary. Following incorporation of agreed-to comments into the specification,
the contractor is informed of ECP approval as specified in the contract. The contractor shall
release the specification and establish or revise the appropriate baseline. If MSFC prepares a
specification, MSFC submits the specification and obtains contractor agreement on
implementation via appropriate contract procedures. The contractor shall release the MSFC-
prepared specification as part of its design baseline release system.
7.1.2
Engineering Release Information. The contractor shall use engineering release
information to release new or revised configuration documentation. The content requirements
for Engineering Release may utilize contractor’s formats, systems, and procedures. Each
release shall identify the data (documents/drawings/databases) released; the authorization for
release; whether the release is an initial release or a change release; the configuration item or
system affected (with effectivities); and date of release.
The contractor is not required to meet standardized formats for an engineering release system.
However, the contractor shall prepare and maintain engineering release records in accordance
with the minimum requirements stated herein. The contractor’s formats, systems, and
procedures may include information in addition to these minimum requirements, provided that
the engineering release records conform to the following:
The contractor shall maintain only one release record for each drawing number. The contractor
shall only release engineering documentation for which the contractor has design responsibility
or engineering documentation that is Government furnished. Engineering release actions that
result in the initial release of baseline engineering documentation shall cite the authority for that
release (e.g., ECP, Configuration Control Board Directive (CCBD).
7.2
Elements of Data Required for Hardware Items. The contractor’s engineering release
records for hardware items shall contain the following information.
7.2.1
CI Elements.
a. Item number
b. Item serial number(s) (Effectivity)
c. Top drawing number
d. Item specification identification number
7.2.2
Drawing Elements.
a. Drawing number
b. Drawing title
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 20 of 70
c. CAGE code
d. Number of sheets
e. Date of release
f. Drawing change or revision letter and release date of authorizing document which
directed the change or revision
g. Ancillary document numbers, e.g., engineering change notices, engineering orders
h. Specification document, specification control drawing, or source control drawing number
7.2.3
Part Number Elements.
a. Controlling drawing number
b. Part numbers released
c. Identification of change that created the part number
7.3
Elements of Data Required for Software Items. The contractor’s engineering release
records shall reference the software CSCI Version Description Document that contains the
elements required in the contract and the guidance provided in IEEE/EIA 12207.1.
7.4
Production Release Functional Capabilities. To the extent that the contractor has
detailed design responsibility, the contractor’s release function (for documentation, drawings,
and associated lists) shall be capable of determining these released engineering requirements:
a. The composition of any part number at any level in terms of subordinate part numbers.
b. All next higher or next assembly part numbers in which the part is used.
c. The composition of any software CSCI in terms of components and units and
subordinate item numbers.
d. The CI/CSCI number and serial numbers (effectivity) on which any subordinate part is
used. This does not apply to subcontractors, vendors, and suppliers who are not
producing CIs/CSCIs.
e. The Class I and Class II change identification numbers for engineering change packages
that have been partially or completely released for any part number or CI/CSCI number
and serial number.
f. The hardware CI numbers and serial numbers or software CSCI and version numbers
that constitute the effectivity of any change identification number.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 21 of 70
g. The subcontractor, vendor, or supplier part numbers which have been assigned in
response to critical component (item) specification documents, specification control
drawings, or source control drawings issued by the contractor.
h. The contractor’s specification document, specification control drawings, or source control
drawing numbers associated with any subcontractor, vendor, or supplier part number.
7.5
Release of Engineering Changes. The contractor’s release function and records shall
be capable of identifying Class I and Class II engineering change packages. The contractor
shall retain the record of superseded configuration requirements.
7.5.1
Release Records. Contractor release records shall identify all Class I and Class II
engineering releases accomplished under the authority of each contractor CCB directive. In
addition, for all Class I changes, the ECP number shall be identified.
7.5.2
Release Change Packages. All Class I and Class II engineering change packages
released for incorporation shall be completely released before formal acceptance of the
deliverable unit.
7.5.3
Retention of Records. The configuration released for each CI unit at the time of its
formal acceptance shall be retained for the life of the contract or otherwise dispositioned by
MSFC contractual authority.
7.6
Field Release Functional Capabilities. Engineering data defining equipment that is
under the jurisdiction of the contractor or MSFC and is progressing through testing or through
activation programs shall be maintained current with all field activity requirements and releases.
8.
CONFIGURATION CONTROL
8.1
General. Configuration control is the systematic process of presentation, evaluation, and
disposition of proposed changes and the implementation of approved changes into CIs and
baseline documentation after establishment of the baselines as defined in Section 6.
Configuration control begins with the establishment of a configuration baseline and continues
through the life cycle of the CI. The contractor shall establish and operate a configuration control
process that meets the requirements contained in this document.
8.2
Configuration Control Boards. The contractor shall establish Configuration Control
Boards (CCBs) for control of internal configuration identification documentation and to review,
evaluate, and approve the submission of proposed changes, deviations, or waivers to
established configuration baselines to MSFC. (Limited scope contracts, such as a single
avionics product, may not require a formal CCB. However, the contractor shall provide evidence
of internal configuration control processes.)
8.3
Changes, Deviations, and Waivers.
8.3.1
General. For the purposes of configuration control, the term “change” is hereby defined
to include Engineering Change Proposals (ECPs), Field Engineering Changes (FECs),
Deviations, and Waivers (DARs) that affect an established configuration baseline.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 22 of 70
8.3.2 Change Criteria. The contractor shall limit the initiation of changes to those that meet
one or more of the following criteria:
a. Correct safety, design, or performance deficiencies;
b. Satisfy a change in operational or support requirements;
c. Effect overall cost savings;
d. Prevent or control program/project schedule slippage;
e. Implement design improvements;
f. Implement performance requirements changes.
8.3.3
Change Classification. For purposes of configuration control, changes shall be classified
as Class I or Class II, depending upon their impact on established configuration baselines or
other contract requirements. Change classification definitions and submission requirements are
stated in the following paragraphs.
8.3.3.1
Class I Change. The contractor shall designate a proposed change as Class I when
any of the baseline factors listed in Table 1 are impacted. The contractor shall submit all Class I
changes to the MSFC contracting officer. The contractor shall not implement a Class I change
without specific direction from the MSFC contracting officer.
8.3.3.2
Class II Change. When the proposed change does not qualify as a Class I change, the
contractor shall designate the proposed change as Class II. The contractor shall process,
disposition, and implement Class II changes within the contractor’s CM system. Concurrent with
internal processing, the contractor shall submit copies of all Class II changes to the responsible
MSFC CCB, or its designated representative, for concurrence with the classification. In the case
of notification of nonconcurrence with the classification, the contractor shall resubmit the change
as a Class I change.
8.3.4
Program Control Number. MSFC utilizes a Program Control Number (PCN) to identify
the total contents of all Class I change packages. Upon request from the contractor, the PCN is
assigned by the MSFC CM function supporting the program or project. The contractor shall use
this PCN on all change proposals, supporting documents, and implementing documents related
to the change.
8.3.5
Change Priority. For all Class I changes, the contractor shall assign a proposed priority
of emergency, urgent, or routine in accordance with the following criteria:
a. Emergency. The contractor shall assign this priority if the proposed change is to correct a
safety condition that could result in fatal or serious injury to personnel or in extensive damage to
or destruction of equipment.
b. Urgent. The contractor shall assign this priority if the proposed change is to correct a
potentially hazardous condition that, if uncorrected, could result in injury to personnel or in
damage to equipment and reduction of mission effectiveness. The contractor shall also use this
classification for the following:
(1) Changes necessary to meet contractual requirements when lead-time would
necessitate slipping baselined production, activation, or construction schedules;
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 23 of 70
(2) Mission capability changes when delay would compromise the mission capability
and result in unacceptable impact to contract, production, or mission launch
schedules; and
(3) Changes associated with interface problems resulting from compatibility changes
made by other contractors.
c. Routine. The contractor shall assign this priority to a proposed change when
“emergency” or “urgent” is not applicable.
The contractor shall not process a proposed change through the contractor’s CM process in one
priority level and upgrade to a more critical priority upon submission to MSFC.
8.3.6
Submission of Changes. The contractor shall ensure that all proposed changes are
properly processed through the contractor’s CM system and that proper engineering and
management approvals are obtained before submission to MSFC. Requirements for the
specific categories are covered in paragraphs 8.4 through 8.5.
8.4
Engineering Change Proposal. The contractor shall submit Class I engineering changes
originated by contractor organizations or subcontractors, as an Engineering Change Proposal
(ECP), in accordance with contract requirements and instructions. Class I engineering changes
shall also contain project control considerations (e.g., cost estimates, schedule impact). Each
change that involves related changes on other items or facilities for which the same contractor is
responsible shall be presented as a total package for contractual implementation. A separate
ECP shall be submitted for each change that has its own distinct objective. A single ECP shall
not cover unrelated changes. The receipt of contractual approval shall constitute the sole
authority for the contractor to implement a Class I engineering change. MSFC Form 2348
Engineering Change Proposal identifies information required for ECP submittal. Appendix E
illustrates this form for reference only. Contractor format is acceptable.
8.5
Record Engineering Change Proposal (RECP). The contractor shall submit an RECP to
indicate acceptance of a change to the interface baseline. (The RECP sometimes is authorized
as a general format to process no-impact changes other than interface.) The RECP indicates
that the change is acceptable and in accordance with the contractor’s design. In other cases,
the contractor shall submit a formal ECP describing the changes required to comply with the
proposed interface changes. MSFC Form 4242, Record Engineering Change Proposal,
identifies information required for RECP submittal. Appendix D illustrates this form for reference
only. Contractor format is acceptable.
8.6
Field Engineering Change (FEC). An FEC is the expedited means for proposing
emergency or urgent engineering changes at using sites on equipment for which MSFC retains
design responsibility and shall be submitted in accordance with contract requirements and
instructions. An FEC shall be used when time is insufficient to process an ECP. Approval of an
FEC by MSFC authorizes implementation of the change and requires that the contractor submit
a follow-up ECP. It is mandatory that a copy of the approved FEC be incorporated into the
ADP... Before the FEC submittal, the contractor shall obtain a PCN for each FEC.
8.7
Software/Firmware Field Engineering Change. A software/firmware field engineering
change permits emergency or urgent changes to the software product after deployment. The
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 24 of 70
Using Site or Design Activity shall initiate an urgent or emergency change request when field
conditions warrant. With prior authorization by the Government, the software engineering group
shall prepare a software change to correct the problem. The Design Activity shall evaluate the
change, propose and test a fix, and prepare a software package, including the Version
Description Document (VDD). It shall submit the change package to the Government. The
Government’s Control Board Disposition provides direction on how the software change is to be
distributed and that an Installation Notification Card (INC) is required to confirm proper
installation and test. The Control Board, based on the urgency or emergency of the change,
determines the extent of verification/validation required and the extent of document changes. If
the change involves more than code, the Program/Project provides direction that a formal ECP
be submitted by the contractor to update documentation and fully incorporate the change.
Appendix H describes the process in detail.
8.8
Deviation and Waiver Request. The contractor shall submit Deviation/Waiver Approval
Request (DAR), originated by contractor organizations or subcontractors, in accordance with
contract requirements and instructions. Deviation and Waiver criteria are as follows:
a. When a departure from a specification, drawing, or related documents, which impacts Class
I change criteria, is known or planned before the production of an item, the contractor shall
submit a DAR as a deviation to identify and obtain authorization for the departure.
Deviations shall be used to obtain approval of departures when the “as-required” or “as-
designed” definition is correct, but a temporary departure from baseline requirements is
necessitated.
b. When a departure from a specification, drawing, or related documents, which impacts
Class I change criteria, is identified during or after production of an item, and the item is
considered suitable for use “as-is” or usable after repair by an approved method (other than
previously approved standard repairs), the contractor shall submit a DAR as a waiver to
obtain MSFC authorization for use of the item. Nonconformances which do not meet Class I
change criteria shall be processed in accordance with the contractor’s internal material
review procedures (Material Review Board or equivalent). MSFC Form 460 Discrepancy
Record may be used to record discrepancies that can lead to a deviation/waiver. MSFC
Form 460 is used during hardware testing and provides a waiver option if class I criteria are
violated. For software, a problem report serves the same purpose as the MSFC Form 460.
The use of the MSFC Form 460 does not obviate the use of the Deviation/Waiver Approval
Request (MSFC Form 847). (See Appendix E for MSFC Form 460.)
c. Deviations or waivers shall not be used as a means of correcting design errors or for
permanent changes to technical requirements. Permanent engineering changes require
submission of an ECP.
d. MSFC Form 847 Deviation/Waiver Approval Request (DAR) contains information required
for deviation/waiver submittal. AppendixE illustrates this form for reference only. Contractor
format is acceptable.
8.9
Modification Kit and Instructions. Modification of a CI at a using site shall be
accomplished by a released Modification Kit (mod kit), except for FECs originated and
processed at the using site. The documentation for a Mod Kit shall be submitted by the
contractor via an ECP. The Mod Kit documentation shall include the modification instructions,
installation notification requirements, and validation/testing requirements. The Mod Kit shall be
in accordance with contract requirements and instructions.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 25 of 70
Table 1. Class I Change Definition
Functional Baseline
Allocated Baseline
Product Baseline
(1) Approved Program/Project
Specification or equivalent.
(2) Preliminary Software
Requirements specification.
(3) Interface characteristics/
documents.
(4) Safety.
(5) Other imposed technical require-
ments definition document.
(6) Imposed or agreed-to price, fee,
guarantees, or schedules.
(1) through (6) Same as functional
baseline.
(7) Approved
Specification(s).
(8) Imposed qualification and
acceptance verification
requirements.
(9) Qualification status previously
accepted by the Government.
(10) Government-Furnished
Equipment.
(11) Specified critical processes.
(12) Change of vendors of
engineering critical
components.
(13) Retrofit.
(14) Software Design
Requirements
Specification(s).
(15) Software Interface
Requirements.
(1) through (15) Same as
functional and allocated
baseline.
(16) Change to approved Product
baseline documentation if any
of the following are affected:
(a) Interchangeability,
substitutability, or
replaceability as applied to
CIs (hardware/software), and
to all subassemblies and
parts except the pieces and
parts of nonrepairable
subassemblies.
(b) Operation, test/checkout,
logistics, maintenance
documentation, or computer
software.
(c) Compatibility with support
equipment trainers, training
devices/equipment.
(d) Preset adjustments or
schedules affecting operating
limits or performance to such
an extent as to require
assignment of a new
identification number.
(e) Electrical interference to
communications – electrical
equipment or electromagnetic
radiation hazards.
(f) Functional or performance
characteristics demonstrated
or experienced in previously
delivered articles.
(g) Electromagnetic
characteristics.
(h) Responsibilities of other
program elements.
(17) Software Detail Design
Specification(s) – As-Built.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 26 of 70
9. CONFIGURATION ACCOUNTING
9.1
General. Configuration accounting is the process of ensuring the accuracy and
timeliness of information throughout the life cycle. Configuration information content evolves
and is captured over the product life cycle as tasks occur. The contractor shall identify
configuration baselines, provide for the accounting of changes to those baselines, and provide
the status of all in-process changes. The contractor shall establish or utilize existing information
systems to meet the requirements of configuration accounting.
9.2
Configuration Accounting Requirements. The contractor shall implement and maintain a
configuration accounting system capable of the following general requirements:
a. Providing a complete record of configuration identification documentation for each CI;
b. Providing a record of all changes to configuration baseline documents, including
manufacturing records and field modifications, throughout the life cycle of the CI;
c. Providing status of all pending, in process, changes;
d. Maintaining a record of all internal change activity (e.g., Class II changes, minor
nonconformance) against CIs;
e. Accumulating and formatting data necessary to provide routine and special configuration
accounting reports as outlined in Sections 9.3.1 through 9.3.4 and as required by the
contract.
9.3
Configuration Accounting Reports. The contractor shall provide configuration accounting
reports as required by the contract. Report data element outlines are contained in Sections
9.3.1 through 9.3.4.
9.3.1
Dispositioned Class I Change Activity Report. This report shall list all proposed
changes, including deviations and waivers that have received MSFC disposition action and shall
be arranged in a change proposal number sequence. The following data elements are as
follows:
a. Identification of the change proposal, including the basic number, revision number, title,
and associated PCN
b. Identification of the CI affected, including the number, nomenclature, and CI effectivity
by serial number(s)
c. Identification of contractual change authorization including number and date
d. Disposition of the change proposal, i.e., “Approved”, “Approved with Changes”, or
“Disapproved”
e. Identification and date of contractor's internal authorization documentation
9.3.2
Pending Class I Change Activity Report. This report shall list all Class I change
proposals that are pending, either internal contractor approval or MSFC approval, and shall be
arranged in a change proposal number sequence. The following data elements shall be
included:
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 27 of 70
a. Identification of the change action, including the basic number, revision number, title,
and associated PCN;
b. Identification of the CI affected, including number, nomenclature and CI effectivity by
serial number(s); and
c. Depending on the processing status, enter the actual or estimated date of submittal to
MSFC.
9.3.3
Configuration Identification Report. This report shall identify the baseline configuration
and all configuration change actions for each CI. Hardware and software changes shall be
listed separately from Deviation/Waiver Approval Requests (DAR) actions. The following data
elements shall be included:
a. Contract and contractor identification;
b. CI identification including, as appropriate, CI number and nomenclature, part number,
and specification number;
c. Configuration change data including the following:
(1) Change proposal identification including type of action (e.g., ECP, Class II change,
or DAR), number, title, and associated Program Control Number (PCN) (if
applicable);
(2) Change application including item(s) affected (e.g., hardware, software, or
documentation), first and total effectivities, and the incorporation or installation
points; and
(3) Change disposition including the identification of contractual change authorization.
9.3.4
Change Incorporation Status Report. This report shall list the status of ECP
incorporation into CIs and shall be organized by CI number. The following data elements shall
be included:
a. CI identification number and serial number;
b. Change proposal number, title, type of change, and associated PCN;
c. Change effectivity, engineering release date, and incorporation point;
d. In-line incorporation completion date, scheduled and actual, as appropriate; and
e. Mod Kit data shall include identification, authorization, effectivity, man-hour estimates
and status, installation location, shipping date (scheduled and actual), and completion
date(s) for installation and retest, if required.
9.3.5
Software Configuration Status Accounting. Like hardware, the purpose of software
configuration status accounting is to record and report the status of evolving software
throughout the life cycle. The contractor’s software accounting shall provide reports as follows:
a. Released documentation, including specifications, interface information
b. Problem reporting, deviations/waiver activity including dispositions and open actions
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 28 of 70
c. Promotion tracking of code for each file through development, testing,
validation/verification and operational deployment
d. Build records and version control – provide data for the Version Description Document
10. CONFIGURATION VERIFICATION AND AUDIT
10.1
General. Configuration verification and audit determine that the design output has been
achieved and is accurately documented. The Functional Configuration Audit (FCA) verifies the
CI or system performance against its approved configuration documentation. The Physical
Configuration Audit (PCA) formally examines the as-built configuration of the CI or system
against its design documentation. Certification of successful FCA and PCA assures the design
meets performance requirements (FCA) and the build is accurate (PCA). The product baseline
is established following completion of the FCA/PCA.
The Government performs a verification of configuration documentation to assure that CIs and
systems have been identified, baselined, and controlled throughout the life cycle. The
Government performs verification as a continuous process to assure authenticity of
documentation used during a program/project’s life cycle.
10.2
Planning. A verification and audit effort is introduced to the contractor by a formal plan
that requires input and agreement between the contractor and MSFC. The process requires
that participants identify discrepancies or anomalies, and recommend courses of action. The
Chairperson shall review findings and determine appropriate actions. Audit minutes shall
provide a record of findings, conclusions, recommendations, and action items. Follow-up
occurs until all required action items are complete.
a. The plan shall clearly state the purpose and objectives of the review. The plan shall state
data required to perform the review.
Note: Appendix I identifies data relevant to the FCA/PCA. The exact data that is required
is identified in the contract Data Procurement Document (DPD).
b. The plan shall define criteria for a successful audit and provide formal certification thereto.
c. The plan shall define a means of recording and tracking open actions.
10.3
Contractor Support. The Government may elect to perform an overview FCA/PCA. In
this instance, the Contractor shall perform detailed functions necessary to assure compliance
with FCA/PCA criteria and provide all pertinent data to the Government to verify FCA/PCA
findings. In this instance, the Contractor shall perform the detailed reviews necessary to assure
the following:
a. Baseline for FCA/PCA established – a viable and complete history of the product is
available.
b. All documentation, drawings, test documentation reviewed – traceability is evident.
c. Deltas between as-designed configuration and as-built configuration identified and resolved.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 29 of 70
d. All prior open actions from previous design reviews resolved – or closure actions are clearly
defined.
e. Verification complete and exceptions recorded.
f. Interface control diagrams either complete - or exceptions being tracked.
g. All prior open actions for spec requirements closed or being specifically tracked – one open
action per requirement.
h. Material Identification and Usage List complete.
i. All agreements with other organizations (Government, contractor, academia) are current and
available.
j. Differences among models (test, production) identified.
k. All deviations and waivers identified.
l. Qualification testing complete and documented – waivers or deviations available when
criteria not met or explanation and action item expressed.
m. Verification matrix complete and available.
n. All technical issues identified and documented.
o. Acceptance Data Package meets criteria of Appendix F.
For software/firmware, the following actions in addition to those stated above, shall be
performed by the contractor:
a. Results of all prior reviews, including verification and validation, are available
b. Traceability exists from requirements documents through coding and actual software
performance
c. Interface issues are resolved or individually identified
d. Version Description Document available and reflects actual build of software
e. For firmware, control of both the hardware and software components is identified
10.4
Objectives. Regardless of the extent of participation, the contractor shall participate in
Functional and Physical Configuration Audits (or equivalents) to assure accomplishment of the
following objectives:
a. Document differences between the as-built configuration and the as-designed configuration
b. Provide the configuration identification documentation suitable for establishment of the
Product Baseline.
c. Provide the product specifications and associated drawings and software documentation
formally accepted as audited and reflect the qualified configuration.
d. When established, utilize the product baseline as a basis for processing and tracking
changes.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 30 of 70
e. Assure that the released engineering documentation, including authorized deviations,
waivers, and Material Review Board actions, reflects the configuration of the as-built and
tested CIs selected for audit.
f. Assure that the built hardware is tested to the released engineering documentation.
g. Compare the physical configuration of the CI unit selected for PCA with that unit’s as-built
technical data package.
Note: The as-built configuration includes details of manufacturing including a complete
description of physical characteristics such as tolerancing, material processes, and machine
tool computer controls. It also includes waivers/deviations, Material Review Board activities,
and all activities that affect how the product is built.
h. Specify the differences between the configurations specified in the PCA technical data
package and the as-built configuration and present for review and reconciliation before
establishment of the Product Baseline.
i. Identify the differences between the configuration of the PCA qualification unit and the CI
unit selected for the verification.
j. Submit any document changes necessary in accordance with the change clause in the
contract.
k. Check and verify the hierarchy of specification tree and drawing tree of the CI/CSCI for
continuity and integrity.
l. Verify the validity of all computer software and media applicable to the Product Baseline for
format, completeness, and conformance to software requirement specifications.
10.5
Contractor Responsibilities. The contractor shall participate in each verification and audit
required by contract and shall comply with the following:
a. Provide space, facilities, and support effort for conducting PCAs.
b. Appoint a single contractor representative to be responsible for each PCA review and
identify this representative by name to the designated MSFC program/project chairperson.
The representative shall have full decision-making capability and commitment authority.
c. Ensure availability of designated CIs and the associated documentation required for
performance of the PCA. The documentation shall include engineering drawings (and/or
computer presentations), specifications, Interface Control Documents, test procedures,
software, and test data proposed for release as the Product Baseline. If required by
contract, furnish preliminary documentation for review before PCA.
d. Provide identification listings of each item to be inspected including nomenclature,
specification identification number, drawing and part numbers, item identification, serial
numbers, and CAGE codes. Where applicable, document revision levels shall be included.
e. Provide lists of all outstanding engineering changes that have been incorporated into the CI
and are awaiting incorporation into documentation.
f. Provide a complete shortage list.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 31 of 70
g. Provide a noncompliance listing.
h. Examine the Acceptance Data Package (ADP) to ensure compatibility with established
review data plans or requirements. Appendix F provides more specific guidance on the
content and presentation of the ADP.
i. Provide and maintain a system for recording, processing, tracking, and reporting the status
of all action items emanating from an audit.
j. Establish organizational procedures for the preparation, processing, and disposition of
hardware verification and software/firmware verification and validation records, including as-
built records and ADPs.
Note: Guidance is provided in Appendix I regarding data required for FCA/PCA of
designated CIs and the associated documentation required for performance of the PCA.
The documentation shall include engineering drawings (and/or computer presentations),
specifications, Interface Control Documents, test procedures, software, and test data
proposed for release of the Product Baseline
10.6
In-process Configuration Management Audits. In-process CM audits are conducted
periodically by MSFC to verify the adequacy of the contractor’s implementation of contractual
CM requirements and to identify any areas needing correction or improvement. The contractor
shall support audits as contractually required. MPR 8040.1 defines the two-part audit process
utilized by which MSFC assures compliance with program/project requirements. Phase I of the
two part audit is self-assessment by the contractor; Phase II is the auditor’s evaluation of the
validity and adequacy of Phase I and the evaluation of areas that may not have been addressed
by Phase I.
10.7
“Other” Reviews. The Contractor may be required to support various readiness reviews
conducted by engineering activities and project or program activities with Configuration
Management records. The contractor shall make available, within the terms of the contract, CM
data and reports to facilitate the objectives of these reviews. Readiness reviews may be
conducted at various levels of control to review the status and readiness of all elements
associated with the project or program. Based on the result of incremental reviews, a top level
NASA Flight Readiness Review (FRR) may be conducted to establish the readiness level of all
engineering, operational, and support elements to accomplish and support a specific flight
mission. Contractor CM support to the incremental and final Flight Readiness Reviews (FRRs)
shall include the following:
a. Provide an accurate baseline configuration identification of the item(s) being reviewed.
b. Provide an accurate identification of configuration differences between item(s) selected
for the current mission and identical or similar item(s) used in previous missions.
c. Provide a current status of all in-process changes affecting the item(s) under review.
d. Provide configuration control support to ensure the expeditious and proper disposition of
open changes, deviations and waivers.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 32 of 70
11. SOFTWARE CONFIGURATION MANAGEMENT
11.1
Preparation. The contractor shall describe how Configuration Management of the
software product is to be performed in the project/project Configuration Management Plan. The
development and production of software/firmware Computer Software Configuration Item
(CSCI) shall be described with life cycle events and products defined. If authorized by the
contract, the contractor shall also prepare a detailed software Configuration Management Plan
that describes software Configuration Management within the context of the contractor’s
software development function.
11.2
Independent Verification and Validation (IV&V). The software or firmware product is
accepted by the Government through means of a software FCA and software PCA. The FCA
compares test results achieved with those defined in requirements. The PCA examines the as-
coded software against its design or delivery documentation. Quality Assurance may choose to
perform Independent Verification and Validation (IV&V), which measures how well software
performs its functions and, conversely, determines that the software is not performing
unintended functions. If IV&V is performed, the Government accepts the IV&V results as part
of the FCA/PCA. The FCA/PCA includes review of IV&V results in conjunction with the ADP
furnished. (See Appendix F.)
11.3
Delivery. The contractor shall deliver software deliverables for review, approval, and
baselining in accordance with contract requirements. As a minimum, MSFC controls CSCI
software/firmware requirements (design specifications) and release (the software version
description). Software deliverables shall be released using the baseline definitions in Section 6.
For FCA/PCA, deliverables shall also include the ADP as defined in Appendix F.
11.4
Software/Firmware Marking and Labeling
11.4.1
Software. The software identifier and version and computer program identification
number (CPIN), where applicable, shall be embedded in the source code header.
a. Software medium (e.g., magnetic tape, disk) containing copies of tested and verified
software entities shall be marked with a label containing or providing cross-reference to a
listing of the applicable software identifiers of the entities it contains.
b. Media for deliverable CSCIs shall be labeled with the government contract number, CSCI
number, CPIN, or other government identifier, CAGE code, media number (e.g., 1 of 2, 2 of
2, if there are multiple units per set) and copy number of the medium or media set (if there is
more than one copy being delivered).
c. Medium copy numbers shall distinguish each copy of the software from its identical copies.
Each time a new version of software is issued, new copy numbers, starting from 1, shall be
assigned.
11.4.2
Firmware. Firmware shall be labeled on the device or if the device is too small, on
the next higher assembly, as follows:
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 33 of 70
a. Where both the hardware device and the embedded code are controlled via a single
engineering drawing. The part number representing the device with the code embedded
shall comprise the label.
b. Where the product configuration documentation for the source code consists of a software
product specification, both the unloaded device part number and the software identifier of
the embedded code, including version number, shall comprise the label. In addition, the
software identification(s) shall be labeled on an identification plate or decal located
adjacent to the nameplate on the equipment containing the firmware.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 34 of 70
APPENDIX A
CONFIGURATION MANAGEMENT PLAN
1. SCOPE/PURPOSE
This Appendix provides the format and guidelines to be followed in the development of a CM
plan for the implementation of contractual CM requirements.
The requirements in this Appendix shall be implemented in accordance with the terms and
conditions of the contract. The plan, when approved, shall establish the formal agreement
between MSFC and the contractor on the CM policy and methods to fulfill the CM requirements
for a given contract.
2. CM PLAN REQUIREMENTS
2.1
Section 1. Scope/Purpose. State the plan's purpose and objective(s) and briefly
describe the contractor’s general management policy and methods as applied to Configuration
Management.
The scope shall include a brief description of the system and/or top-level hardware, firmware,
and software items and the lower level components to which the CM plan pertains.
2.2
Section 2. Applicable Documents. Only those documents referenced in the following
sections of the CM plan shall be listed. If the applicable documents list is extensive, it may be
included in an Appendix or a separate document and referenced in this section. This section
shall be organized as described in the following paragraphs.
2.2.1
Government Documents. The documents shall be listed in the following order:
a. Specifications
b. Standards
c. Drawings
d. Other Publications (e.g., manuals, regulations, handbooks)
2.2.2
Non-Government Documents. The documents shall be listed in the following order:
a. Specifications
b. Standards
c. Drawings
d. Other Publications (e.g., manuals, regulations, handbooks)
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 35 of 70
2.3 Section 3. Organization. This section shall describe and graphically portray the
contractor’s organization with emphasis on CM activities and shall include the following:
a. The relationship to and integration of the contractor’s project organization and functional
organization(s).
b. The responsibility and authority for CM in all participating groups and organizations
including their roles in Configuration Control Boards (CCBs).
c. The functional integration of CM activities into other program activities such as technical,
management, and design reviews.
d. The identification and description of the contractor’s CM organization, including
responsibilities.
e. The organizational interfaces for both the hardware and the firmware/software products
that show the contractor’s organization and the Government, other contractors, and
subcontractors.
f. The management integration activities between CM and project management. The
contractor shall define the relationship between events critical to CM and schedule
control; e.g., sequencing of design reviews, engineering release, production, testing.
2.4
Section 4. Configuration Management Phasing and Milestones. The contractor shall
propose the major milestones for implementation of CM. These milestones shall include, but not
be limited to, the following:
a. Phasing for implementation of the specification program, including release and submittal
of specifications and supporting configuration documentation.
b. Establishment of internal developmental and contractual configuration baselines.
c. Implementation of internal and Government configuration control.
d. Establishment of the contractors' CCBs.
e. Implementation of a status accounting system and provision of reports or access to
status accounting information.
f. Establishment of interface control agreements.
2.5
Section 5 - Configuration Identification. This section shall describe the contractor’s
methods and procedures for meeting the requirements of Section 2 of the basic portion of this
document, including the following:
a. Selection of hardware and software items requiring the application of CM.
b. Establishment of the Functional, Allocated, Design Requirements and Product
Baselines, definition of the configuration baseline documentation required for each, and
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 36 of 70
a graphic illustration of configuration documentation relationships. Explain development
baseline and process.
c. Definition of engineering release process and correlation to manufactured/fabricated
products.
d. Assignment, application, and control of hardware and software configuration identifiers
including specification, drawing, and document numbers; nomenclature; serial, lot, and
part numbers; and version identifiers for software and firmware.
2.5.1
Specifications. The plan shall identify the hardware and software specifications needed
to establish and control the configuration baselines. A Specification Tree shall be included that
depicts the interrelationship of the contractor-prepared specifications and the relationship to
applicable higher-level specifications. The plan shall also specify the intended time in the
program when the above specifications are to be presented for delivery (or otherwise made
available) to MSFC. Any limitation on delivery to, or use by, MSFC of contractor-prepared
specifications shall be stated.
2.5.2
Drawings. This section shall specify the drawing practices for application to the contract
including the effects of application of this document and standards referenced therein.
Drawings and associated lists shall be prepared in accordance with ASME Y14.100 as defined
in the contract. Any limitation on delivery or use of contractor-prepared drawings shall be stated.
2.6
Section 6. Interface Control. This section shall describe the methods for controlling
interface requirements between elements of the program/ project. These methods shall cover
the following elements of interface control:
a. Establishment of initial interface baseline documents.
b. Incorporation of and compliance with contractually imposed interface documents.
c. Control of changes to interface documents including initiation of proposed changes,
change coordination, change submission, and incorporation of approved changes.
d. Review and evaluation of proposed and authorized changes to related interface
documents controlled by other contractors or activities.
2.7
Section 7. Configuration Control. The contractor shall describe the procedures to be
used for meeting the requirements of Section 8 of the basic portion of this document, plus any
applicable Appendices or references. In these requirements, the term "processing" is defined
as the range of activities from initiation of the action through verification of change incorporation
or resolution of nonconformances. This description shall include the following:
a. Establishing organization, functions, responsibilities, and authority of CCBs;
b. Classifying changes and determining the level of authority for change approval or
concurrence;
c. Processing Class I ECPs and PCPs and processing Class II engineering changes;
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 37 of 70
d. Processing DARs;
e. Processing Specification Change Notices (SCNs)/Document Change Notices (DCNs);
f. Processing Interface Revision Notices (IRNs) and Preliminary IRNs (PIRNs);
g. Processing and controlling Field Engineering Changes (FECs); and
h. Processing and controlling mod kits.
2.8
Section 8. Configuration Accounting. The contractor shall describe procedures for
meeting the requirements of Section 9 of the basic portion of this document, including the
following:
a. Methods for collecting, recording, processing, and maintaining data necessary to provide
CM accounting information by means of reports or database access.
b. Description of reports or information system content as related to the identified data
elements.
c. Frequency of reporting and distribution and/or methods of access to CM information
database.
2.9
Section 9. Configuration Verification and Validation. The contractor shall describe the
system for verification of the hardware product and verifying and validating software/firmware
product. Verification and validation shall assure that the configuration identification
documentation and deliverable CIs are in compliance with the contractual baseline. As a
minimum, the contractors’ methods shall be addressed for the following:
a. Demonstrating that the contractually required qualification verification was accomplished
and that it substantiated compliance of the "as-verified" and "as validated"
(software/firmware) design with the original performance and configuration design
requirements and approved changes.
b. Demonstrating that the contractually required acceptance verification/validation was
accomplished and that it substantiated compliance of the performance and configuration
of the article being delivered with the "as-qualified" design.
2.10
Section 10. Configuration Reviews, Inspections, and Audits. The contractor shall
describe his plans for conducting and/or providing CM support to appropriate reviews,
inspections, and audits.
2.11
Section 11. Subcontractor/Vendor Configuration Management Control. The contractor
shall describe the methods for ensuring that subcontractors and vendors comply with CM
requirements, insofar as their activity impacts the contractors CM commitments to MSFC.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 38 of 70
2.12
Section 12. Modification Kits and Instructions. The contractor shall specify the planning
for and methods to be used in (1) identification of retrofit actions, (2) development of mod kits
and instructions, and (3) control and closeout of kit installation.
3. CM PLAN APPROVAL AND MAINTENANCE
The contractor shall submit the plan for approval by MSFC and shall maintain the plan with all
proposed changes and revisions submitted to MSFC for review and approval. Submittal and
update of the plan shall be as specified in the contract data requirements.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 39 of 70
APPENDIX B
SOFTWARE CONFIGURATION MANAGEMENT PLAN
1. SCOPE/PURPOSE
This Appendix provides the format and guidelines to be followed in the development of a
software CM plan for the implementation of contractual CM requirements.
Note: The content outlined below follows the subject matter topics included in NPR 7150.2
The requirements in this Appendix shall be implemented in accordance with the terms and
conditions of the contract. The plan, when approved, shall establish the formal agreement
between MSFC and the contractor on the CM policy and methods to fulfill software CM
requirements for a given contract.
The Program/Project Software Configuration Management (SCM) Plan shall be prepared in
accordance with the template and contents defined below. This template was derived from
IEEE-828, Standard for Software Configuration Management Plans. Sections not applicable to
a specific program or project shall be addressed as “Not Applicable.”
a. Title Page.
b. Signature Page (For Non-electronic Documents). This page contains: (1) document
number; (2) document title; (3) effective date; and (4) approval signature(s).
c. Document History Log.
d. Table of Contents. The Table of Contents lists the title and page number of all paragraphs,
subparagraphs, figures, tables, and appendices, in that order.
e. Section 1: Introduction. Introduction information provides a simplified overview of the SCM
activities so that those approving, those performing, and those interacting with SCM can
obtain a clear understanding of the SCM Plan.
(1) Purpose. The purpose shall briefly address why the SCM Plan exists and who the
intended audience is.
(2) Scope. The scope shall address SCM applicability, limitations, and assumptions on
which the SCM Plan is based.
(3) Definitions. This section contains definitions of key terms in order to establish a
common terminology among all users of the SCM Plan.
(4) References. This section lists the specifications, standards, manuals, and other
documents, including policy directives, specified in the plan by title, document number,
revision, and, when applicable, change notice, amendment number, and date of issue.
This section may provide definitions, glossaries, and acronym listing if necessary for
plan clarification.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 40 of 70
f. Section 2: SCM Management. SCM management information shall describe the allocation
of responsibilities and authorities for SCM activities to organizations and individuals within
the project structure.
(1) Organization. The SCM Plan shall include all organizations that participate in or are
responsible for any SCM activity on the project, the functional roles of these
organizations within the project structure, and the relationships between the
organizations.
(2) SCM Responsibilities. The allocation of SCM activities to specific organizations shall
be specified. For each activity listed within SCM Activities, the name of the
organization or job title to perform this activity shall be provided.
g. Section 3: Configuration Data Management. This section describes the methods for
meeting the configuration management technical data requirements under the computer-aided
transmission and distribution requirements for the program/project. The following lists some,
but not necessarily all, of the areas to be considered when addressing this subject in the SCM
Plan:
(1) Data Management. The plan shall address how the configuration management
identification data is to be managed and processed. This shall include information
concerning the type(s) of data records, and how the data is accessed and updated or
changed.
(2)
Data Status Accounting. The plan shall address data status accounting.
h. Section 4: Software Configuration Management Activities. SCM activities information
identifies all functions and tasks required to manage the configuration of the software system as
specified in the scope of the SCM Plan. Both technical and managerial SCM activities shall be
identified.
(1) Configuration Identification. This section describes the procedures and requirements
for establishing and maintaining identification of software, firmware, and related
interfaces during the life of the project and/or CI(s).
a) Identifying Configuration Items. The SCM Plan shall record the items to be
controlled, the project CI(s) and their definitions as they evolve or are selected.
b) Naming Configuration Items. The SCM Plan shall specify an identification system
for assigning unique identifiers to each item to be controlled. It shall also specify
how different versions of each are to be uniquely identified.
c) Acquiring Configuration Items. The SCM Plan shall identify the controlled software
libraries for the project and describe how the code, documentation, and data of the
identified baselines are to be physically placed under control in the appropriate
library. For each library the format, location, documentation requirements,
receiving and inspection requirements, and access control procedures shall be
specified.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 41 of 70
(2) Configuration Control. Configuration control activities request, evaluate, approve or
disapprove, and implement changes to baselined CI(s). Changes include both error
correction and enhancement.
a) Requesting Changes. The SCM Plan shall specify the procedures for requesting a
change to a baselined CI and the information to be documented for the request.
b) Evaluating Changes. The SCM Plan shall specify the analysis required to
determine the impact of the proposed change and the procedures for reviewing the
results of the analysis. Changes should be evaluated according to their effect on
the deliverable and their impact on project resources.
c) Approving or Disapproving Changes. The SCM Plan shall identify each
configuration control board (CCB) and its level of authority for approving proposed
changes.
d) Implementing Changes. The SCM Plan shall specify the activities for verifying and
implementing an approved change.
(3) Configuration Status Accounting. Configuration status accounting activities record and
report the status of project CI(s). If an automated system is used for any status
accounting activity, its function shall be described or referenced.
(4) Configuration Audits and Reviews. The SCM Plan shall identify the configuration
audits and reviews to be held for the project.
(5) Interface Control. This section describes the procedures for identification of interface
requirements, establishment of interface agreements, and participation in Interface
Control Working Groups (ICWGs).
(6) Subcontractor/Vendor Control. The SCM Plan shall define the activities to incorporate
the externally developed items into the project CI(s) and to coordinate changes to
these items with their development organizations for both subcontracted and acquired
software.
i. Section 5: SCM Schedule. The SCM schedule provides guidance on the timeline of
important SCM activities.
j. Section 6: SCM Resources. SCM resource information identifies the software tools,
techniques, equipment, personnel and training necessary for the implementation of the
specified SCM activities.
k. Section 7: SCM Plan Maintenance. The maintenance information identifies the activities
and responsibilities necessary to ensure continued SCM planning during the life cycle of the
project.
NOTE: The appendix requirements above shall be implemented to define the specific
requirements for each program/project/CI utilizing accepted software life cycle practices.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 42 of 70
APPENDIX C
SPECIFICATION CHANGE INSTRUCTIONS
1. SCOPE/PURPOSE
This Appendix provides uniform practices for the preparation of proposing and recording
changes in specifications.
a.
Information Required for Specification Changes
(1) Contractor Name and CAGE Code
(2) Specification Number - the identification number of the specification affected.
(3) Rev. - the revision letter of the baselined specification affected.
(4) Date – normally the date of the submitting ECP.
(5) Program/Project Name
(6) CI Nomenclature and CI Number - the nomenclature and identification number of the
hardware, firmware, or software CI or critical item governed by the specification.
(7) ECP Number, PCN, Contract Number – identifiers for contract records.
(8) Effectivity - CI or other effectivity of this change.
(9) Description of Change - Provide definitive description of the change as described in
paragraph 6.2.2.1
b.
Required Data Elements for Specification Change History Log
The following data elements shall be included for each entry in the log
(1) Release Date – The date the document is approved for release.
(2) Change Identification, including ECP No., date and PCN – (PCN is provided by
MSFC.)
(3) Disposition – approving disposition and date
(4) Description of the change – summary of content changed and rationale
(5) Identify new revision level.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 43 of 70
APPENDIX D
INTERFACE CONTROL
1. SCOPE/PURPOSE
The following is an example of the Preliminary/Interface Revision Notice (PIRN/IRN). MSFC
Form 4229 or a contractor equivalent form may be used. Required content is described for
each field in the instructions that follow the form.
Interface Revision Notice
1. AFFECTED ICD NO. & REV.:
2. PIRN NO.:
3. IRN NO.:
4. SHEET
1 of
5. PROGRAM: 6. PCN: 7. PANEL
AFFECTED:
8. ICD TITLE:
9. EFFECTIVITY(IES):
1O. REASON FOR CHANGE:
CHANGE
ICD
11. TO:
12. FROM:
13. IRN NO.:
14. NEW IRN EFFECTIVITY:
15. PREVIOUS IRN EFFECTIVITY:
16. DESCRIPTION OF CHANGE:
17. PREPARED BY:
18. ORG: 19. DATE: 20. CONCURRENCE:
21. CONCURRENCES
SIGNATURE SIGNATURE
22. APPROVALS
A
PPROVAL & DATE
A
PPROVAL & DATE
A
PPROVAL &
FOR REFERENCE ONLY
MSFC Form 4229 (January 1994) Computer Generated
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 44 of 70
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Interface Revision Notice
Complete all applicable blocks. If needed, continuation sheets may be used. The Preliminary IRN should be of
sufficient quality so that, if approved, it may be released to the ICD custodian and/or the MSFC Repository for
reproduction and distribution. The following instructions are keyed to the numbers on the form.
1.
AFFECTED ICD NO. & REV. Enter the complete number and revision of the ICD affected by the PIRN.
2,
PIRN NO. Enter an organizational tracking number for identification until an IRN number is assigned, and the
PCN (if assigned) of the basic change action.
3.
IRN NO. Leave blank. To be completed by CCB secretary. (IRN number will be assigned only after approval
of the proposed change.)
4.
SHEET 1 of _____ Enter total number of sheets.
5.
PROGRAM Enter the applicable program; e.g., SEDS-2, AADSF, etc.
6.
PCN Enter the PCN (if assigned) of the basic change action.
7.
PANEL AFFECTED Enter the identification of the IWG or other organization controlling the ICD.
8.
TITLE Enter the exact title of the affected ICD or the IRD.
9.
EFFECTIVITY(IES) Enter the effectivity(ies) of the change described by the PIRN, including launch vehicle
elements, upper stages, payloads, experiments, etc., as appropriate.
10.
REASON FOR CHANGE Enter a brief statement of the reason for the change and include related ECP
number.
11.
CHANGE ICD EFFECTIVITY TO Leave blank except when this PIRN is used to change the effectivity of
the ICD.
12.
CHANGE ICD EFFECTIVITY FROM Leave blank except when this PIRN is used to change the effectivity of
the ICD.
13.
IRN NO. Leave blank except when this PIRN is used to change the effectivity of a previous IRN.
14.
NEW IRN EFFECTIVITY Leave blank except when this PIRN is used to change the effectivity of a previous
IRN.
15.
PREVIOUS IRN EFFECTIVITY Leave blank except when this PIRN is used to change the effectivity of a
previous IRN.
16.
DESCRIPTION OF CHANGE Enter the proposed change to the affected ICD for all sides of the affected
interfaces, using continuation sheets, if required.
17.
PREPARED BY Enter the name of the engineer preparing the PIRN.
18.
ORGANIZATION Enter the name of the preparing organization.
19.
DATE Enter the date prepared.
20.
CONCURRENCE Enter the name of the engineering manager concurring in the PIRN.
21.
CONCURRENCES Leave blank. These fields are to be used to record technical acceptance by the authorized
representatives of the interfacing activities or recognized IWG.
22.
APPROVALS These fields are to be used to identify the applicable CCB and record their approval.
MSFC Form 4229
(
Reverse Side
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 45 of 70
APPENDIX E – CHANGE CONTROL
1. SCOPE/PURPOSE
This Appendix provides reference forms that describe requirements to identify and record
proposed changes and to provide a means of evaluating the effects on design, performance,
cost and schedule. The contractor may use its own format.
FOR REFERENCE ONLY
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 46 of 70
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 47 of 70
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 48 of 70
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 49 of 70
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 50 of 70
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 51 of 70
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 52 of 70
RECORD ENGINEERING CHANGE PROPOSAL
FOR REFERENCE ONLY
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 53 of 70
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 54 of 70
FOR REFERENCE ONLY
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 55 of 70
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 56 of 70
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 57 of 70
FOR REFERENCE ONLY
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 58 of 70
APPENDIX F
ACCEPTANCE DATA PACKAGE
1. SCOPE/PURPOSE
This Appendix provides guidance and requirements for the content of the Acceptance Data
Package (ADP) provided at the time of each Acceptance Review; Functional and Physical
Configuration Audit, or when a configuration item is transferred from one agency or site to
another. Other data deliverables may also be identified in the Data Procurement Document
(DPD) (like drawings, specifications or reports) to support Acceptance Reviews and Audits, in
addition to the specific content of the ADP. These documents shall also be made available
along with the ADP.
An ADP accompanies each configuration item when the configuration item is transferred to a
different site or agency. Accordingly, the ADP is updated and maintained current throughout the
life-cycle of the product.
2. REQUIREMENTS
a.
Acceptance Data Package Submission. The ADP shall be submitted in accordance with
contractual data delivery requirements. The ADP shall clearly identify the configuration of the
CI/CSCI being delivered, any differences from baselined requirements, and any effort or
deliveries that shall be accomplished after acceptance to fulfill contract requirements. The ADP
and associated documents shall provide sufficient description to allow for transfer responsibility
for a CI/CSCI from the contractor to MSFC.
b.
Acceptance Data Package Contents (Hardware).
(1) Copy of DD form 250/1149
(2) Notes/Comments
(3) Waivers/Deviations
(4) Shortages, Unplanned/Deferred and Preplanned/Assigned Work
(5) Identification – As-built configuration (see paragraph 2.4)
(6) CI Log Books (see paragraph 2.5)
(7) Configuration Records (see paragraph 2.6)
(8) Age Sensitive/time Action Items
(9) Non-standard Calibration data
(10) Repair limitation data
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 59 of 70
(11) Other technical data specified by the contract
c. Acceptance Data Package Contents (software/firmware)
(1) Summary and status of all accepted Change Requests (CRs) to the baselined
Software Requirements Specifications (SRSs)
(2) Summary and status of all major software capability changes since baselining of
the Software Design documents (SDDs)
(3) Summary and status of all major software tests (including development,
verification, and performance testing)
(4) Summary and status of all Discrepancy Reports (DRs) written against the software
(5) Summary and status of all software requirements deviations and waivers
(6) Summary and status of all software user notes
(7) Summary and status of all quality metrics historically and for this software
(8) Definition of open work, if any
(9) Software configuration records defining the verified and validated software,
including the final Software Version Description (SVD) for this software
(10) Copy of proposed DD Form 250
d. As-built-As designed Documentation.
The as-built as-designed comparison shall identify
differences between the built item and the designed item. The as-built as-designed shall
include the following:
(1) An indentured parts list of hardware being delivered.
(2) Identification of differences between the as-built and as-designed
(3) Necessary data elements include deliverable part number/serial number; part
numbers; quantity; drawing traceability code (serial or lot traceability); drawing
change letter and incorporated EOs; reference designations (electrical items only)
(4) Identification of source and spec controlled drawings
(5) Manufacturing build paper, including make or buy decision for each part
e. CI Log Books
. Log books shall be current to the time of acceptance by MSFC; the
following appropriate categories shall be included in the log book:
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 60 of 70
(1) Running/operating time and cycle log(s) for each time and cycle critical item of the CI.
These logs shall identify the item(s) by nomenclature, part number and serial number
and shall state the total authorized life and the life expended.
(2) Test history log, including post manufacturing checkout and final verification tests of
the CI, with the following data:
(3) Actual measurements identified to specified tests. References to applicable test
reports are satisfactory, provided that copies of the reports are included.
(4) Brief test summary.
(5) List of unaccomplished tests or portions of tests with estimated man-hours required
for completion.
(6) List of actual and recommended retest(s) including status.
(7) Special test instructions, investigations, warnings, and problems encountered during
factory testing
(8) Failure and corrective action data for all functional failures during the post
manufacturing and final acceptance test and checkout of the CI
(9) Inspection records for all inspections performed, such as packaging, presentation,
trouble shooting, removals and replacements, shortages, preventive maintenance, etc.
(10) Transfer records providing a history of all CI movement until time of transfer to the
procuring agent
(11) Alignment data records for the total CI and all alignment critical components (items)
(12) Component (including Government-Furnished Property) log books
(13) Weight and balance logs covering total weight and horizontal, vertical, and lateral
center of gravity
f. Configuration Records.
(1) Parts and drawing lists identifying all parts and drawings that have been changed from
baseline configuration.
(2) Software configuration records defining the verified and validated software including
the Version Description Document, Software Certification, and the validated software
program.
(3) A list of authorized deviations and waivers.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 61 of 70
(4) A complete list of hardware and software/firmware items shipped loose or separately.
This list shall cover all items needed to complete the CI or satisfy programmed work
and shall include scheduled dates of arrival.
g. Certifications
. A copy of the proposed DD Form 250, Material Inspection and Receiving
Report, or equivalent. The document shall identify the CI by model number, serial number, part
number and the governing CI specification.
h. Format and Updating ADP
. The Contractor shall develop a plan for formatting and
maintaining the ADPs current for each audit, review, or transfer of CI/CSCI.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 62 of 70
APPENDIX G
DEFINITIONS AND ACRONYMS
1. SCOPE/PURPOSE
This Appendix provides standardized definitions and explanations of the words, terms, phrases,
abbreviations, and acronyms that characterize the terminology used in CM implementing
instructions. Configuration Management terms and definitions are listed in alphabetical order in
the following section.
This Appendix is applicable to MSFC contractors who are providing design, development,
fabrication services, or products for MSFC-managed program or project activities.
2. DEFINITIONS
Acceptance Data Package (ADP)
. Complete documentation necessary to clearly identify the
configuration of the CI being accepted, including test and operating logs, any differences from
contract requirements, and any work to be performed after acceptance in order to fulfill contract
requirements.
Baseline
. The technical requirements of a program/project/CI as approved by the responsible
CCB at a specific time during its life cycle and recorded in a configuration identification
document or set of documents and changes thereto.
Class I Engineering Change Proposal
. A change classification that proposes a change to an
established baseline or affects a level of criticality (like form, fit, or function) of a configuration
item. (Class II change is a proposed change that does not meet Class I criteria.)
Commercial and Government Entity (CAGE) Code
. A five-character code listed in
Cataloging Handbook H4/H8 which is assigned to commercial and Government activities that
manufacture or develop items, or provide services or supplies for the Government. When used
with a drawing number or part number, the CAGE code designates the design activity to which
the drawing or part number is assigned. The CAGE Code was previously called manufacturer's
code, code identification number, or Federal Supply Code for Manufacturers.
Computer Software Configuration Item (CSCI)
. An aggregation of software that satisfied an
end use function and is designated by the Government for separate Configuration Management.
Configuration.
The functional and physical characteristics of existing or planned hardware,
firmware, software, or a combination thereof, as set forth in technical documentation and
ultimately achieved in a product.
Configuration Audit (FCA).
The formal examination of functional characteristics of a
Configuration Item, or system, to verify that the item has achieved the requirements specified in
its functional and/or allocated configuration documentation.
Configuration Accounting.
The recording and reporting of the information that is needed to
manage configuration effectively, including a listing of the approved configuration identification,
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 63 of 70
the status of proposed changes, deviations and waivers to configuration, and the
implementation status of approved changes.
Configuration Control.
The systematic definition, evaluation, coordination, and disposition of
each proposed change, deviation or waiver, and the implementation of each approved change
in the configuration of a program/project/CI after formal establishment of the configuration
identification.
Configuration Control Board (CCB)
. The functional body responsible for establishing
baselines and the reviewing and dispositioning of all changes, deviations or waivers to these
baselines.
Configuration Control Board Directive (CCBD)
. The document used to record the actions of
a CCB to establish baselines, disposition changes to baselines, and authorize
deviations/waivers to baselines. The document specifies each action, actionee, and due date
required to implement the change. The form contains a signature block for the concurrence or
nonconcurrence of each board member and the authorization of the CCB chairman.
Configuration Identification.
The establishment of approved technical documentation defining
the approved configuration of a program/project/CI throughout its life cycle and its maintenance
on a current basis. This documentation consists of specifications, drawings and associated
lists, including documents referenced therein and approved changes thereto.
Configuration Identification Numbers
. Numbers that, individually or in combination, permit
accurate selection of the configuration required to perform a given function. These numbers
may include: (a) specification identification numbers, (b) CI numbers, (c) drawing and part
numbers, (d) engineering change identification numbers, (e) Commercial and Government
Entity (CAGE) code numbers, (f) serial numbers, and (g) lot numbers.
Configuration Inspection.
A formal review that is used to establish the Product Baseline and
to verify that the contract end items have been, and other like items can be, manufactured,
tested, etc., to the released engineering documentation. This is accomplished by a comparison
of the "as-built" configuration to the "as-designed" requirements. The Configuration Inspection
is a one-time review conducted for each family of Contract End Items.
Configuration Item (CI)
. An aggregation of hardware/software or any of its discrete parts and
related documentation that satisfies an end-use function and is designated by MSFC for
configuration management.
Configuration Management (CM).
A discipline applying technical and administrative direction
and surveillance to accomplish the following tasks:
— Identify and baseline the technical requirements of programs/projects/CIs.
— Control changes, deviations, and waivers to these technical requirements.
— Record and report change processing and implementation status.
— Account for approved changes and their incorporation into programs/projects/CIs.
— Verify that the configuration of systems and CIs is as specified in configuration
identification documentation.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 64 of 70
Configuration Verification. The task of ensuring that the program hardware, software, and
firmware is certified as having been designed, built, and tested to the correct configuration
baseline.
Contractor
. An entity (e.g., individual, partnership, company, corporation, association) having a
product or services contract with a procuring activity.
Data Element (Software/Firmware)
. A single piece of information, the smallest unit normally
residing in a computer system (database). A record consists of one or more data elements.
Deviation.
A specific written authorization, granted prior to the manufacture of an item, to
depart from a particular requirement(s) of an item's current approved configuration
documentation for a specific number of units or a specified period of time. (A deviation differs
from an engineering change in that an approved engineering change requires corresponding
revision of the item's current approved configuration documentation, whereas a deviation does
not.)
Deviation/Waiver Approval Request (DAR).
A form used to define and request approval of
deviations and waivers.
Drawing (Engineering)
. An engineering document or digital data file(s) that discloses (directly
or by reference), by means of graphic or textual presentations, or combinations of both, the
physical and functional requirements of an item.
Effectivity.
The specific hardware or software family and serial number(s), specific missions, or
specific period of time to which part numbers, changes, deviations, waivers, etc., are identified.
Engineering Change Proposal (ECP).
A proposed engineering change and the
documentation by which the change is described, justified, and submitted to the Government for
approval or disapproval.
Engineering Release Record.
The single, authoritative data file identifying released
documentation and changes thereto.
Engineering Release System. The single, authoritative control system for assigning document
numbers, verifying requirements, recording and transmitting engineering documentation
required for fabrication, assembly, installation, and test of program hardware/software.
Facility.
Any fixed installation, e.g., test stand or launch mechanism, which is part of a
program/project. This includes real property and installed equipment.
Field Engineering Change (FEC)
. The method for proposing emergency/urgent engineering
changes at NASA using sites on equipment for which MSFC retains design responsibility and
for which time is not adequate for preparation and processing of an ECP.
Firmware
. The combination of a hardware device and computer instructions or computer data
that resides as read-only software on the hardware device. The software cannot be readily
modified under program control.
Flight Readiness Review (FRR).
A detailed review by which the system is certified as flight
worthy. The FRR includes review of the system verification process (both testing and analysis),
system compatibility, operational planning, and team preparedness. The review results in
certification of flight readiness of the operational team, the acceptability of the vehicle for each
flight, and the readiness of the system to achieve all flight objectives.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 65 of 70
Installation Notice Card (INC). The official document used after contract delivery to update
the Configuration Management system and to inform the procuring activity and the contractor
that a particular modification package has been installed, tested, verified, and accepted in
accordance with its associated change instruction.
Interface
. A region common to two or more elements, systems, projects, or programs
characterized by mutual physical, functional, and procedural properties.
Interface Control Drawing/Document (ICD)
. Documentation in the form of drawings and/or
written record that identifies the requirements that define and depict the physical, functional, and
procedural interfaces that are required to be met by separate developing contractors and/or
agencies.
Interface Requirements Document (IRD)
. A top level document that identifies and provides
mutually agreeable interface requirements between different programs or projects and specifies
basic requirements for allocation and quantification to lower level ICDs and/or interfacing
specifications.
Interface Revision Notice (IRN).
A form used to record approved changes to baselined
interface documents.
Modification Instruction (Mod Instruction)
. A form initiated by the designer to be used as a
checklist for mod kit completeness and to serve as instructions for accomplishing the
modification.
Modification Kit (Mod Kit).
A package containing necessary documentation, hardware,
software, and Mod Instructions to incorporate an approved engineering change in Government-
accepted or in-service articles.
Mod Kit Validation Requirements
. Information provided with a Mod Kit which defines
inspection and test requirements necessary to establish confidence in new system(s) added or
to restore confidence of system(s) invalidated by incorporation of a Mod Kit.
Physical Configuration Audit (PCA)
. The formal examination of the "as-built" configuration of
a Configuration Item against its technical documentation to establish or verify the Configuration
Item's product baseline.
Preliminary Interface Revision Notice (PIRN)
. An IRN form used to describe proposed
changes to IRDs/ICDs by participating contractors or design agencies.
Product Baseline.
The technical requirements as recorded in the initial approved part II CI
detailed specification and subordinate approved detail specifications and drawings. This
baseline is finalized as a product of the Configuration Inspection.
Product Definition Data
. Data elements required to completely define a product. (A product
definition data set is a collection of one or more computer files that disclose (directly or by
reference), by means of graphic or textual presentations, or combination of both, the physical
and functional requirements of an item.)
Program Control Number (PCN).
A unique number assigned to the first item of a change
package which initiates a particular engineering change. The same number is assigned to all
subsequent actions and documentation associated with that engineering change which,
together with the initial engineering change document, is recognized as a change package.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 66 of 70
This same concept applies to program control identification numbers, space station control
numbers, and any other name that may be applied to a number used for this purpose.
Software
. A combination of associated computer instructions and computer data definitions
required to enable the computer hardware to perform computational or control functions.
Software Version Description Document (VDD)
. A specification documenting the exact "as-
built" configuration of software to be delivered.
Specification.
A document prepared specifically to support acquisition which clearly and
accurately defines performance, design, and verification requirements.
Specification Change Instruction (SCI)
. A document that records all SCNs issued against a
specification, provides a chronological listing of all changes to the specification, and provides
the replacement page deletion/insertion instructions.
Specification Change Notice (SCN).
A form used to propose, transmit, and record changes to
a baselined specification.
Statement of Work (SOW)
. A document that accurately describes the requirements for
contracts providing items, materials, or services including the standards used to determine
whether requirements have been met.
Subcontractor
. A contractor who provides an item and/or service under the terms of a contract
with a prime contractor.
Supplier
. A source from whom a purchased item is obtained; used synonymously with the term
vendor.
System.
A composite of equipment, skills, and techniques capable of performing and/or
supporting an operational role. A complete system includes all equipment, related facilities,
material, software, services, and personnel required for its operation and support to the degree
that it can be considered a self-sufficient item in its intended operational environment.
Vendor
. See Supplier.
Verification/Validation
. The inspection and tests necessary to establish confidence in a new
system, to restore confidence in an added system, or to restore confidence in a system
invalidated by the installation of a modification into a CI.
Waiver.
A written authorization to accept an item, which during manufacture, or after having
been submitted for Government inspection or acceptance, is found to depart from specified
requirements, but nevertheless is considered suitable for use "as is" or after repair by an
approved method.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 67 of 70
3. ACRONYMS/DEFINITIONS
ADP Acceptance Data Package
CAGE Code Commercial and Government Entity (Code)
CCB Configuration Control Board
CCBD Configuration Control Board Directive
CI Configuration Item
CM Configuration Management
CPIN Computer Program Identification Number
CSCI Computer Software Configuration Item
DAR Deviation/Waiver Approval Request
DPD Data Procurement Document
ECP Engineering Change Proposal
FCA Functional Configuration Audit
FEC Field Engineering Change
FRR Flight Readiness Review
ICD Interface Control Document
INC Installation Notice Card
IRD Interface Requirement Document
IRN Interface Revision Notice
PCA Physical Configuration Audit
PCN Program Control Number
PCP Project Change Proposal
PDR Preliminary Design Review
PIRN Preliminary Interface Revision Notice
PRR Program/Project Requirements Review
RECP Record ECP
SCI Specification Change Instruction
SCN Specification Change Notice
SOW Statement of Work
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 68 of 70
APPENDIX H
GUIDANCE FOR PROCESSING URGENT-EMERGENCY SOFTWARE CHANGES
1. SCOPE/PURPOSE
This appendix provides guidance on organizational roles and duties in processing urgent or
emergency software changes.
Using Site or Design Activity
Identify need for emergency or urgent software update after
receipt/delivery of software CSCI(s).
Design Activity Generate Change Request (CR).
Design Activity
If approved by Program/Project manager, generate software
update and documentation package including software
Version Description Document (VDD).
Generate the software update instructions to include the
following items:
a. Title
b. Software version number
c. Authorization
d. Date
e. Installation site
f. Installation sequence
g. Operational manuals affected
h. Safety considerations
i. Purpose of software update
j. Effectivity
k. Documentation required
l. Instructions for installation
m. Special test equipment
n. Estimated man-hours required
o. Validation requirements
p. Prepared by
q. Tested by
r. Software requirements
A copy of the software update will be provided for each
installation site.
If validation requirements are not available for inclusion into
the initial installation instructions, the validation requirements
should be generated and shipped after delivery of initial
software update.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 69 of 70
MSFC Property
Management and
Transportation
Promulgate software update and documentation package.
Using Site Activity Receive software update.
Revise installation and operation documentation, as required.
Implement software update per instructions.
Complete installation and verification information and forward to
the project configuration management secretariat. MSFC Form
2490, Installation Notice Card, or the using-site format is
acceptable; however, the data items listed below are mandatory:
a. Software version number
b. ECR number that caused the modification
c. Date and location of installation
d. Work order number if applicable
e. Name, address, and telephone number of the person
responsible for the installation
f. Date and location of verification
g. Name, address, and telephone number of the person
responsible for the verification
h. Any additional remarks as required
Transmit software update installation and verification information.
CCB Secretariat Receive software update installation and verification information.
Design Activity
Generate revised ECR, as required, and process beginning with
step 6.2.1.
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
Multiprogram/Project Common-Use Document
ED03
Document No.: MSFC-STD-3394 Revision: A
Title: Standard for Contractor CM
Requirements, MSFC
Programs/Projects
Effective Date: January 31, 2005 Page 70 of 70
APPENDIX I
DOCUMENTATION GUIDANCE FOR FCA/PCA
1. SCOPE/PURPOSE
This appendix lists documentation that may be required for the FCA/PCA. Specific
requirements for documentation are identified in the contract.
Documentation for FCA
• Configuration Item Specifications
• Drawing and parts list
• ECPs and DARs incorporated and
pending
• Drawing trees (UPA and PSM)
• Fracture control plan
• Structural dynamics, analyses, loads,
and models documentation (updated)
• Material Usage Agreement (MUAs)
• Material Identification Usage List
(MIUL)
• Certification of Qualifications (COQs)
• Verification Plan
• Software verification data
• Software version description
• Critical Design Review (CDR) RIDS
and disposition
• Nonconformance reports (PRACAs
• Interface control drawings/documents
• Hazards analysis/risk assessment
(SHA)
• Test procedures
• Verification reports
• Verification tracking log
• ALERTS tracking log (GIDEP Alert
database
Documentation required for PCA
• Final verification of configuration item
specifications
• Product drawings and parts list
• Configuration accounting and status
report
• Final version of all software documents
• Final version of software version
description document
• Copy of all FCA findings for each CI
• List of approved and outstanding ECPs
and DARS
• Copies of ECPs and DARS as required
at the audit
• Drawing trees
• Indentured parts list/as-design
configuration definition
• As run test procedures (when
applicable, include any test
discrepancy reports).
• Copy of parts tags or verification
closure for verification items verified by
inspection method
• Manufacturing and inspection (build)
records
• Inspection records
• As-built data
• Discrepancy reports (DRs and MRBs)
• ADP
CHECK THE MASTERLIST
VERIFY THAT THIS IS THE CORRECT VERSION BEFORE USE
