![](media/image1.wmf){width="2.0in" height="1.2222222222222223in"}

**ICE, CLOUD AND LAND ELEVATION SATELLITE**

**(ICESAT) PROJECT**

**CONFIGURATION MANAGEMENT PLAN**

Prepared by:
[\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_]{.underline}

OSC/Fairchild Space

Approved by:
[\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_]{.underline}

Joseph A. Dezio

ICESat Project Manager/Code 401.6

Approved by:
[\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_]{.underline}

Ronald E. Kolecki

Systems Assurance Manager/Code 303

![](media/image2.wmf){width="1.332638888888889in"
height="1.1527777777777777in"}

ICESat Project/Code 401.6

NASA/GSFC, Greenbelt, MD 20771

**Ice, Cloud and Land Elevation Satellite (ICESat) Project CM Plan**

**Document Change Record**

+--------+------------------------------+---------+---------+---------+
| **Revi | **Description of Change**    | **      | *       | **App   |
| sion** |                              | Pages** | *Date** | roval** |
|        |                              |         |         |         |
|        |                              | **Aff   |         |         |
|        |                              | ected** |         |         |
+========+==============================+=========+=========+=========+
| \-     | Baseline Release of Document | All     | 4/23/98 | JAD     |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+

i

**[ACRONYM LIST]{.underline}**

BCE Bench Checkout Equipment

CAL Configured Articles List

CCB Configuration Control Board

CCR Configuration Change Request

CDR Critical Design Review

CEI Contract End Item

CI Configuration Item

CM Configuration Management

CMO Configuration Management Officer

CMP Configuration Management Plan

CoMITS Configuration Management Information Tracking System

DCR Document Change Record

EO Engineering Order

EOS Earth Observing System

EOSDIS Earth Observing System Data and Information System

ESDIS Earth Sciences Data and Information System

ESSP Earth Science Systems Program

GEM Goddard Engineering Memo

GFE Government Furnished Equipment

GMI Goddard Management Instruction

GSFC Goddard Space Flight Center

ICD Interface Control Document

ICESat Ice, Cloud and Land Elevation Satellite

IRD Interface Requirements Document

LAM Laser Altimetry Mission

MDR Mission Design Review

MOU Memorandum of Understanding

OFA Office of Flight Assurance

PAR Performance Assurance Requirements

PDR Preliminary Design Review

PM Project Manager

RFP Request for Proposal

SAM Systems Assurance Manager

SOW Statement of Work

ii

**Ice, Cloud, and Land Elevation Satellite (ICESat) Project**

**Configuration Management Plan**

**ABSTRACT**

Configuration Management (CM) has been defined as a "tool used to ensure
that the configuration of project hardware and software is known at any
point in time during the project life cycle. " Recognizing the
importance of this discipline is imperative in regards to the production
of hardware and software necessary to support mission requirements. It
should not be thought of as a hindrance to progress, but as the means
for achieving it, in the most effective and thorough manner possible.

The purpose of this document is to provide the Ice, Cloud and Land
Elevation Satellite (ICESat) Project team with guidelines and
organizational responsibilities deemed necessary for the release and
control of documentation and the processing of changes that arise during
design and development. The ICESat Project was previously known as the
Laser Altimetry Mission (LAM).

The appendices which follow identify the functions and responsibilities
of CM, Project team members, and participating organizations for
processing all pertinent information which is applicable during design,
development, assembly, and integration.

iii

**[Table of Contents]{.underline}**

[Page]{.underline}

1.0 Introduction 1

> 1.1 Objectives 1
>
> 1.2 Scope 3
>
> 1.3 Applicable Documents 3

2.0 ICESat Organization and Responsibilities 4

> 2.1 ICESat Project Manager 4
>
> 2.2 ICESat Configuration Management Officer 4
>
> 2.3 ICESat Configuration Control Board 4
>
> 2.4 GSFC Supporting Organizations and Contractor Support 4

3.0 Configuration Identification 6

> 3.1 Configuration Items 6
>
> 3.2 Configuration Baseline 6

4.0 Configuration Change Control 7

4.1 Configuration Control Levels 7

4.1.1 ICESat CCB 7

> 4.2 Configuration Changes 7
>
> 4.3 Change Classification 7
>
> 4.4 Deviation/Waiver Requests 8

5.0 Configuration Status Accounting and Reporting 10

6.0 Configuration Verification 11

**List of Figures**

[Page]{.underline}

Figure 1 CM Discipline Applied to ICESat Project 2

Figure 2 ICESat Project Organization 5

Figure 3 CCB Disposition Sheet 9

Figure 3A Project CCB Structure 10

Figure 4 Document Change Record Form E-3

Figure 5 CCR Processing Chart F-2

Figure 6 CCR Form F-3

Figure 7 EO Form H-2

iv

**[Table of Contents]{.underline}**

**Appendices**

[Page]{.underline}

Appendix A CMO Responsibilities A-1

Appendix B Configuration Control Board B-1

Appendix C Supporting Organizations\' Responsibilities C-1

Appendix D Contractor Organizations\' Requirements D-1

Appendix E Document Control E-1

Appendix F Processing of Configuration Change Requests F-1

Appendix G Drawing Control G-1

Appendix H Processing of Engineering Orders H-1

Appendix I Deviations and Waivers I- 1

Appendix J CM Information Tracking System (CoMITS) J-1

v

**1.0 [Introduction]{.underline}**

> This plan defines and describes the system to be used to implement
> Configuration Management (CM) for the design and development of flight
> hardware and/or software for the Ice, Cloud and Land Elevation
> Satellite (ICESat) Project.

This CM system provides the means by which all Contract End Items (CEIs)
are to be documented and controlled, and defines a process which is
intended to ensure that all proposed and actual technical and
programmatic changes to ICESat hardware and software and associated
documents and drawings shall be systematically evaluated for validity,
merit, need, and impact.

> The identification of the spacecraft configuration is baselined
> progressively by approving technical documentation at selected times
> during the development process. This plan establishes the framework
> for the implementation and verification of all approved configuration
> baselines and changes to those baselines. Changes to approved
> baselines are formally controlled through the Configuration Control
> Board (CCB).
>
> This plan uses the CM terminology defined in GMI 8040.1A, or the
> latest revision, unless otherwise specified, and fulfills the GMI
> Exhibit A - \"Minimum Requirements Reference\".

**1.1 [Objectives]{.underline}**

> The objectives of this plan are to define and to describe the CM
> system to be implemented for the development of ICESat flight
> hardware.

The CM system functions defined are as follows:

• Configuration Identification

• Configuration Control

• Configuration Accounting and Reporting

• Configuration Verification

> This CM system provides the means by which the ICESat Project Manager
> (PM) may effectively assess and control all proposed changes to flight
> program documentation (contracts, statements of work, specifications,
> plans, procedures, reports, drawings, etc.) that may affect form, fit,
> or function and all changes that may impact performance, cost, or
> schedule. Figure 1 shows the major tenets of the CM discipline.
>
> 1
>
> ![](media/image3.wmf){width="6.745138888888889in"
> height="5.020833333333333in"}

**1.2 [Scope]{.underline}**

> This plan establishes the requirements and control for a CM system
> which meets the intent of GMI 8040.1A. This document is applicable to
> all ICESat Project contracts and agreements, and all codes or agencies
> who have signed a Memorandum of Understanding (MOU) with GSFC for
> joint development of flight hardware. This plan also applies to the
> Spacecraft, Instrument, system level Bench Checkout Equipment (BCE),
> flight and BCE software.

**1.3 [Applicable Documents]{.underline}**

> The following documents are applicable to this plan. In the event of a
> conflict between this plan and the referenced documents, the
> instruction in this plan has precedence.

[NASA/GSFC]{.underline}

GMI 8040.1A \"Configuration Management (CM)\"

X-673-64-IF \"Engineering Drawing Standards Manual"

3

**2.0 [ICESat Project Organization and Responsibilities]{.underline}**

> The ICESat Project is managed by Code 401.6 as part of the Earth
> Science Systems Program/Earth Observing System (ESSP/EOS). The current
> ICESat Project organization is shown in Figure 2.

**2.1 [ICESat Project Manager]{.underline}**

> The ICESat Project Manager (PM) will chair the Configuration Control
> Board (CCB), appoint standing and ad hoc CCB members, and establish
> subordinate CCBs at subsystem levels as he deems necessary. The ICESat
> PM authorizes the establishment of baselines and evaluates the
> recommendations of the CCB, dispositioning changes, and determining
> the level of approval required. The day to day implementation of CM
> for ICESat is delegated to a CM contractor who shall ensure that CM
> practices by all GSFC organizations and contractors meet the intent of
> GMI 8040.1A.

**2.2 [ICESat Project Configuration Management Officer]{.underline}**

> The ICESat Project Configuration Management Officer (CMO) will serve
> as the central point of contact for all CM processes. The
> responsibilities of the CMO are detailed in Appendix A.

**2.3 [ICESat Project Configuration Control Board]{.underline}**

> The purpose of the ICESat Project CCB is to determine the impact of
> proposed changes on the project and to recommend approval/disapproval
> to the Chairperson of the CCB. The membership and responsibilities are
> defined and established in Appendix B.
>
> When time constraints do not permit a formal review, or no further
> inputs are required for a proposed change, the ICESat PM may
> disposition a Configuration Change Request (CCR) without convening a
> formal CCB. Informational copies of changes processed "out of board"
> will be sent to the CCB membership and to impacted team members by the
> ICESat Project CMO. Emergency CCBs may also be scheduled, if
> necessary.

**2.4 [GSFC Supporting Organizations and Contractor
Support]{.underline}**

> All GSFC organizations supporting the ICESat Project shall comply with
> the CM processes detailed in this plan. The CM requirements for
> supporting organizations are outlined in Appendix C. Contractors shall
> comply with the ICESat Project CM requirements as specified in their
> contractual Statement of Work (SOW). The CM requirements for
> Contractor organizations are outlined in Appendix D.

4

**(FOR REFERENCE ONLY\--See http://icesat.gsfc.nasa.gov For Updates)**

Figure 2: ICESat Project Organization

5

**3.0 [Configuration Identification]{.underline}**

> Configuration identification is the ongoing process of identifying and
> documenting a product\'s functional and physical characteristics, from
> initial selection through design, development, fabrication, test, and
> delivery. Configuration identification provides unique identity to
> complete configuration documentation as well as the product itself.
> Documentation includes all specifications, test procedures, drawings,
> and data lists which define or support the product and approved
> changes thereto. Configuration identification further includes
> physical part numbering and serialization of parts, subassemblies, and
> assemblies.

**3.1 [Configuration Items]{.underline}**

> Configuration Item (CI) is the designation applied to the aggregation
> of hardware and software product(s), or any of its discrete portions,
> that have been designated subject to configuration management
> requirements and procedures that satisfy an end use function.

**3.2 [Configuration Baseline]{.underline}**

> Configuration baseline is the point at which configuration
> documentation is considered "frozen" during the developmental
> lifecycle of each CI. Baseline documentation initiates formal
> configuration control, and changes to that documentation must be
> tracked and approved. Baseline documentation includes, but is not
> limited to, Specifications, Interface Requirements Documents (IRDs),
> Mission Assurance Requirements (MARs), Functional Requirements
> Documents (FRDs), drawings, engineering orders (EOs) against drawings,
> test documentation, and any other documentation that makes up the end
> baseline.

6

**4.0 [Configuration Change Control]{.underline}**

> Configuration change control is the systematic evaluation and
> disposition of all proposed changes to an established baseline. The
> ICESat Project CCB members review and determine any impact that could
> result from the change and recommend approval or disapproval of the
> change to the CCB Chairperson, who has final authority to disposition
> the change. Recommendations to the Chairperson are noted on a CCB
> Disposition Sheet, as shown in Figure 3.

**4.1 [Configuration Control Levels]{.underline}**

> The ICESat Project has a multi-level CCB, as shown in Figure 3A. Each
> CCB has the authority to disposition changes for which it has
> responsibility. Changes affecting higher level requirements will be
> submitted, with recommendations, to the next higher level CCB for
> disposition.

**4.1.1** **[ICESat Project CCB]{.underline}**

The ICESat Project CCB shall be chaired by the ICESat PM and shall meet
at his direction to evaluate all CCRs submitted to the board. The ICESat
Project CCB is responsible for all changes affecting mission objectives,
total program cost, scheduled launch dates, mission component
interfaces, and MOU requirements.

**4.2 [Configuration Changes]{.underline}**

> Changes to baselined documentation are accomplished by submittal of a
> CCR to the ICESat Project CCB, through the ICESat Project CMO. The CCR
> form and procedure for processing CCRs are included in Appendix F.
>
> Changes to released drawings are accomplished by submittal of an
> Engineering Order (EO) to the ICESat Project CMO for processing. See
> Appendix G for drawing control procedures and Appendix H for the EO
> processing procedures.

**4.3 [Change Classification]{.underline}**

> All proposed changes to ICESat Project documentation submitted to the
> CCB for consideration are designated as Class 1 or Class 2 changes.

• Class 1 change requests and all deviation/waiver requests will be
submitted to the ICESat Project CCB, through the CMO, for processing and
disposition.

7

• For an approved Class 1 change that impacts mission safety, mission
component interfaces, an instrument milestone, or total program cost, a
CCR shall be submitted to the Project Office for approval before
implementation.

• Class 2 changes are approved by the Systems Assurance Manager (SAM)
and the Systems Engineering lead, as appropriate, but copies are
submitted to the ICESat Project CMO for verification of class and for
status accounting input.

**[Class 1 Changes]{.underline}**

A Class 1 change is a proposed change that impacts the form, fit,
function, interfaces, weight/power/data rate allocations, technical
risk, science performance, cost, or instrument schedule of a baseline
configured item. Class 1 changes must be submitted for Configuration
Control Board (CCB) approval.

**[Class 2 Changes]{.underline}**

Class 2 changes shall be limited to substitution of equivalent parts,
clerical errors, or clarification additions.

**4.4 [Deviation/Waiver Requests]{.underline}**

Requests for a deviation or waiver to any baselined ICESat document are
submitted to the CCB, through the ICESat Project CMO using CCR form.
Procedures for processing deviations and waivers are described in
greater detail in Appendix I.

8

Figure 3: ICESat CCB Disposition Sheet

9

![](media/image4.wmf){width="6.743055555555555in"
height="7.629166666666666in"}

Figure 3A: ICESat Project CCB Structure

10

**5.0 [Configuration Status Accounting and Reporting]{.underline}**

> Configuration status accounting, defined as the recording and
> reporting of significant information needed to effectively manage
> configuration items, includes the reporting of all such information to
> personnel and organizations associated with the project.
>
> In order to provide this status accounting, an established relational
> database, known as the Configuration Management Information Tracking
> System (CoMITS), is used to record and report the status of all ICESat
> Project activity pertinent to changes, deliverables, drawings,
> documents, Configured Articles Lists (CALs), and associated action
> items. Access to this database shall be through the ICESat Project
> homepage via the World Wide Web (WWW). The site information currently
> is: **http://icesat.gsfc.nasa.gov**.
>
> 11

**6.0 [Configuration Verification]{.underline}**

> Configuration verification is accomplished by flight product final
> inspection and documentation review at each configured level of
> development to determine product compliance with the latest approved
> ICESat configuration.
>
> The responsibility for configuration verification rests with GSFC
> Assurance Management Office, Code 303.

12

**APPENDIX A**

**CONFIGURATION MANAGEMENT OFFICER RESPONSIBILITIES**

**1.0** **[Purpose]{.underline}**

The purpose of this appendix is to establish the responsibilities of the
Configuration Management Officer (CMO) for fulfilling CM requirements as
set forth by this Configuration Management Plan (CMP) and GMI 8040.1A,
in support of the ICESat Project.

**2.0 [Responsibilities]{.underline}**

The CMO will:

• Ensure the requirements of the CMP are adhered to;

**•** Exist as the central repository, providing safe storage, for all
original ICESat Project master documentation and the repository from
which controlled CM data is disseminated to the Project team;

• Serve as the central point of location for the processing of all
configuration changes, ensuring appropriate review;

• Provide the secretary for the (CCB) and coordinate all CCB-related
documentation (i.e., meeting notification, agenda, minutes), as
described in Appendix B;

• Establish numbering systems for documentation, CCRs, and EOs and
control their dissemination;

• Act as liaison among program personnel, contractors, and higher levels
of authority, particularly when interfaces are impacted;

• Verify all changes are properly incorporated into affected documents
and drawings, once approved;

• Distribute updated documentation to appropriate individuals, once
revisions are released;

• Maintain and control all program documentation;

A-1

• Provide guidance to preparers of CM documentation;

• Provide complete status accounting for change activity, documentation,
drawings, and action items;

• Distribute copies of documentation (including drawings and documents)
for review;

> • Prepare and maintain a Configured Articles List (CAL), that includes
> an as-built drawing list with any deviations or waivers;

• Perform periodic audits, in conjunction with the Systems Assurance
Manager, if required; and

• Provide assistance to product assurance to verify configuration of
deliverable items prior to delivery.

A-2

**APPENDIX B**

**CONFIGURATION CONTROL BOARD**

**1.0 [Purpose]{.underline}**

> The ICESat Project shall formally control changes to all baselined
> items. This control shall be administered through a CCB and the ICESat
> Project CMO. The purpose of this appendix is to define the
> responsibilities of the Configuration Control Board (CCB) for the
> ICESat Project.

**2.0 [CCB Responsibility]{.underline}**

> The CCB members have the responsibility for making recommendations to
> the Project Manager for approving, rejecting, or deferring for further
> study, each Configuration Change Request (CCR) submitted to the Board
> by Project team members. If required, CCR originators shall present
> and defend their recommendations to the CCB. If any of the required
> personnel are in the field at the time a CCB is held, they shall
> participate via teleconference.
>
> The CCB will be responsible for reviewing each proposed change from
> all aspects, (technical, interface, operational, logistics, schedule,
> cost, contractual) for the project. Also, they shall evaluate,
> disposition, and document actions for proposed changes. Although
> members' responsibility and authority may differ, each voting member
> shall have an equal vote in the CCB. Final decisions on all CCB
> recommendations will be the responsibility of the Project Manager (CCB
> Chairperson), who will provide signature approval or disapproval of
> all change actions submitted to the CCB.

**3.0 [Membership of the Configuration Control Board]{.underline}**

The following personnel shall comprise the membership of the
Configuration Control Board:

**Standing Members:**

> Project Manager (Chairperson)
>
> Deputy Project Manager
>
> Deputy Project Manager/Resources (DPM/R)
>
> Observatory Manager

Project Scientist

> Project Systems Engineer
>
> Systems Assurance Manager
>
> Configuration Management Analyst (Secretary)

B-1

**Ad Hoc Members:**

Operations Manager

Subsystem Lead Engineers

> Software Manager/Engineer
>
> Flight Systems I&T Manager

Instrument Manager

Spacecraft Contractor

Any Expertise/Discipline as needed

**4.0 [Membership Responsibility]{.underline}**

**4.1 [CCB Chairperson Responsibilities]{.underline}**

The CCB Chairperson will:

• Preside over all CCB meetings;

• Appoint additional members to the CCB, as the project warrants, for
both the standing and the ad hoc membership;

• Authorize the scheduling of regular and emergency CCB meetings, as
well as authorize the Out of Board processing of CCRs;

• Resolve any class designation, effectivity, or approval requirement
disputes;

• Ensure that potential financial, manpower, and schedule impacts of all
proposed changes have been considered; and

• Make the final approval/disapproval decisions on the CCB change
proposal recommendations.

**4.2 [The CMO Responsibilities]{.underline}**

The CMO shall be a non-voting member of the CCB and shall be responsible
for the administrative aspects of the CCB/CCR process.

The CMO will:

• Assist individuals in the completion of forms used for change request;

• Forward change requests to appropriate individual(s) for review and
direction and approval for processing;

B-2

• Assign tracking numbers and distribute the change requests to
identified CCB members for review prior to a scheduled CCB;

• Notify members of the scheduled meeting date, time, location and
agenda;

• Perform as recording secretary for the CCB;

• Track and report CCR status; If a CCR is denied, the CMO will notify
the CCR initiator;

• Distribute copies of the approved minutes and dispositioned change
requests to all CCB members and affected personnel in a timely manner;

• Track action items and ensure that all affected documents and drawings
are changed in accordance with CCB direction;

• Ensure all changes are properly incorporated into affected documents
and drawings;

• Distribute updated documentation to appropriate individuals.

**4.3 [The Standing Membership Responsibilities]{.underline}**

The standing members of the CCB will:

• Provide thorough technical review of changes submitted to the Board;

• Attend CCB meetings or send a designated alternate; and

• Recommend approval or disapproval of the change.

**4.4 [Ad Hoc Membership Responsibilities]{.underline}**

Ad hoc members to the CCB will:

• Review proposed changes based on their particular expertise;

• Support meetings when specifically requested; and

• Recommend approval/disapproval of proposed changes.

B-3

**APPENDIX C**

**RESPONSIBILITIES OF SUPPORTING ORGANIZATIONS**

**1.0 [Mission Baseline and Product Control]{.underline}**

> The mission baseline for the designs of GSFC supporting organizations
> will be established at specified design reviews such as the
> Preliminary Design Review (PDR), Mission Design Review (MDR), Critical
> Design Review (CDR) or other approved milestones in accordance with
> mission requirements.

**1.1 [Baseline Documents]{.underline}**

> Responsibility for developing the baseline documents (specifications,
> schematics, drawings, processes, material/parts lists, software
> programs and test procedures) resides with the Project Manager and his
> lead engineers or designees in other GSFC functional organizations.
> The maintenance of the baseline documentation, working in conjunction
> with the responsible discipline/lead engineers, resides with the
> configuration management support group.
>
> Lead engineers have the responsibility to verify that all approved
> changes are reflected in the applicable documents, drawings, and
> procedures.

**1.2 [Instrument Integration and Test]{.underline}**

> The individual, or supporting organization, responsible for the
> assembly and test of the major instrument subsystems will implement
> procedures, in compliance with Code 300, Office of Flight Assurance
> (OFA) requirements, that will properly identify and control the flight
> hardware subsystems during the assembly and test phase.

**1.3 [Launch Vehicle Integration and Test]{.underline}**

> During the launch vehicle integration and test phase, when the
> observatory is mated to the launch vehicle and made operational, the
> responsible organization will also implement procedures that identify
> and control flight hardware from the initial build through final
> buy-off.

C-1

**APPENDIX D**

**CONTRACTOR ORGANIZATIONS REQUIREMENTS**

**1.0 [Purpose]{.underline}**

> The purpose of this appendix is to define the Configuration Management
> (CM) requirements for contractors supporting the ICESat Project
> Office.

**2.0 [Requirements]{.underline}**

Contractors shall implement configuration management procedures that are
compatible with the GSFC CM practices, as specifically tailored in
ICES-401-PLAN-001.

> Each Project contractor shall derive a list of lower-level
> Configuration Items (CI) from the Deliverable List, as identified in
> the Request for Proposal (RFP) and Statement of Work (SOW). These
> CI\'s shall be subject to contractor CM requirements and procedures.
> The contractor\'s CI list shall be explicitly documented in the
> contractor\'s CM Plan, and shall be subject to PM approval.
>
> Each contractor shall establish baseline documentation for the
> products for which he/she is responsible. The appropriate
> specifications, drawings, and other documentation defining the CI,
> shall be generated in accordance with published CM guidelines, and
> placed under configuration control.
>
> All Class 1 changes shall require GSFC approval prior to
> implementation and should be submitted in an expeditious manner.
> Copies of all Class 2 changes will require CCB review for concurrence
> of classification.
>
> Copies of all contractor changes to baseline drawings shall be
> submitted to GSFC using the contractor\'s Engineering Change Proposal
> (ECP), or equivalent. The implementation of all approved changes
> should be closely monitored.
>
> If requested, contractors should support the change review board by
> reviewing changes, generating inputs, and attending meetings. They
> should also ensure that all products are procured or built to approved
> documentation.

D-1

**APPENDIX E**

**DOCUMENT CONTROL**

**1.0 [Purpose]{.underline}**

> The purpose of this appendix is to describe the ICESat Project
> documentation system. This documentation system will be administered
> by the Configuration Management Officer (CMO) and shall be applicable
> to all documentation generated and maintained current on the ICESat
> Project.

**2.0 [Document Numbering]{.underline}**

> Document identification numbers shall be assigned by the CMO for all
> GSFC generated documents by using the scheme described below:

PROJECT SUBMITTING DOCUMENT SEQUENCE ACRONYM ORGANIZATION TYPE NUMBER

ICES XXXX XXXX 001

> Organization types for ICESat are as follows:
>
> 401 = ICESat Project
>
> 303 = Systems Assurance
>
> 924 = GLAS Instrument
>
> 423 = ESDIS Project
>
> 505 = EOSDIS
>
> BALL = Spacecraft Contractor
>
> SA = Spectrum Astro, Inc.
>
> Document types are defined below:
>
> ANYS = Analyses
>
> FRAC = Fracture Control Documents
>
> ICD = Interface Control Documents
>
> LEGL = Legal Documents, MOAs, SOWs
>
> LOG = Logbooks
>
> MGMT = Management Plans and Procedures
>
> MISC = Miscellaneous
>
> PLAN = Plans
>
> PROC = Procedures
>
> REF = Reference Documents and Standards
>
> REVW = Review Packages (CDRs, PDRs)
>
> SER = System Engineering Reports
>
> SFTY = Safety Documents
>
> SPEC = Design Specifications
>
> TEV = Test & Evaluation Documents/Verification Plans and Reports
>
> TM = Technical Memos
>
> TR = Test Reports
>
> E-1
>
> The sequence numbers shall be assigned based on document type as a
> request for document numbers is received. The revision letter is
> advanced in alphabetical order as approved revisions are incorporated
> into the document.

Contractor originated documents submitted to the ICESat Project CMO
shall receive an ICESat Project CMO control number for internal CMO
tracking. The originator's document control number will remain in
effect.

**3.0 [Document Release]{.underline}**

> When a document is ready to be baselined and officially released, it
> should be submitted to the ICESat Project CMO. The CM Officer shall
> assist in the review/signature process, if requested. After a document
> has been approved by all necessary project members it is considered
> "baselined" and, therefore, under CM control.
>
> Officially released documents will have a control stamp marking
> (showing it's a product of the GSFC ICESat Project CMO) and the date
> of release, along with the initials of the CMO who released the
> document.
>
> Once baselined, the CMO shall maintain the original document, the
> word-processing file (which shall be supplied by the individual
> submitting the document), and distribute copies to the appropriate
> individuals. Word-processing files are then "linked" via the CoMITS
> (See Appendix J) to the Project Homepage, where they can be viewed by
> all Project members.
>
> If documents are not to be baselined for some time, preliminary
> versions can be submitted for reference purposes, and will be stamped
> as such.

**4.0 [Document Change Control]{.underline}**

> The CMO shall be responsible for the processing of submitted changes
> to baselined (under CM control) documents. All document changes will
> require the approval of the original approval disciplines, and should
> be submitted to the CMO on a CCR form. These forms are available from
> the CM Officer and are also available online.

**4.1 [Document Change Record]{.underline}**

> Each controlled document shall contain a Document Change Record (DCR)
> preceding the document's Table of Contents (see Figure 4). This DCR
> shall be updated and released with each change or revision
> incorporated into the document. The DCR will identify the revisions by
> letter and the changes by number and the date and number of the
> Configuration Change Request (CCR) that authorizes the revision or
> change.

E-2

**DOCUMENT TITLE**

**DOCUMENT CHANGE RECORD**

+--------+------------------------------+---------+---------+---------+
| *      | **Description of Change**    | **      | *       | **App   |
| *Revis |                              | Pages** | *Date** | roval** |
| ion/Ch |                              |         |         |         |
| ange** |                              | **Aff   |         |         |
|        |                              | ected** |         |         |
+========+==============================+=========+=========+=========+
| \-     | Baseline Release of Document | All     | 1/10/96 | JD      |
+--------+------------------------------+---------+---------+---------+
| Ch. 1  | Mechanical Requirements      | 5       | 2/14/96 | JD      |
|        | (Section 5.0) updated per    |         |         |         |
|        | ICES-CCR-015                 |         |         |         |
+--------+------------------------------+---------+---------+---------+
| Ch. 2  | Update to Stress Analysis    | 3       | 2/20/96 | JD      |
|        | (Section 3.4) per            |         |         |         |
|        | ICES-CCR-019                 |         |         |         |
+--------+------------------------------+---------+---------+---------+
| A      | Incorporated changes per     | All     | 6/12/96 | i       |
|        | ICES-CCR-025                 |         |         | nitials |
|        |                              |         |         |         |
|        |                              |         |         | here    |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+
|        |                              |         |         |         |
+--------+------------------------------+---------+---------+---------+

Figure 4: Sample Document Change Record (DCR) Form

E-3

**APPENDIX F**

**PROCESSING OF CONFIGURATION CHANGE REQUESTS**

**1.0 [Purpose]{.underline}**

> The purpose of this appendix is to describe the method for processing
> Configuration Change Requests (CCRs).

**2.0 [Review and Approval Process]{.underline}**

> CCRs (or adequate information for the CMO to prepare a CCR) will be
> submitted to the CMO for processing. Figure 5 depicts the CCR
> processing flow.
>
> • All CCRs should be as complete as possible, with cost, schedule,
> design, and documentation impacts identified. The CMO assigns the CCR
> a number and enters it into the database, from which time it is
> tracked throughout its lifetime. The CCR form is shown in Figure 6.
>
> • CCRs should contain technical information in sufficient detail to
> determine the merits of the requested change. Documentation changes
> should be identified and rough copy attached to the CCR, where
> possible.
>
> The CMO reviews the CCR for accuracy and completeness and distributes
> the request for change, with all supporting documentation attached, to
> all disciplines which might be impacted, for inputs. As the returned
> inputs are received, the CMO will attempt to resolve any conflicts
> which might result from individual inputs prior to a CCB meeting.
>
> The CCB Chairperson will convene a CCB meeting, as necessary, to
> discuss and disposition each CCR. CCB decisions, together with any
> action or follow-up, will be coordinated by the CM Officer.
>
> If higher authority disposition is required the CCR will be forwarded
> to the appropriate level.
>
> The CMO will prepare and distribute minutes of the CCB, implement all
> documentation changes, provide copies to holders of the documents, and
> monitor resolution of any other action items. The CMO will document
> close-out activity and maintain current the CCR status report.

F-1

![](media/image5.wmf){width="6.748611111111111in"
height="4.570138888888889in"}

Figure 5: Configuration Change Request (CCR) Processing Chart

Figure 6: Configuration Change Request (CCR) Form (Page 1)

F-3

Figure 6: Configuration Change Request (CCR) Form (Page 2)

F-4

**APPENDIX G**

**DRAWING CONTROL**

**1.0 [Purpose]{.underline}**

> The purpose of this appendix is to describe the methods used for
> assigning drawing numbers, revising drawings, and overall drawing
> control.

**2.0 [Drawing Number Assignment]{.underline}**

Drawing numbers shall consist of assigned, basic seven-digit numbers,
prefixed by the letter "G" (identifying it as a GSFC drawing) and a
second letter signifying the drawing size (A, B, C, D, E, F, or J).

> Blocks of official drawing numbers are issued by the Mechanical
> Engineering Branch, Code 543, and shall be obtained by the CMO for
> distribution to project team members or organizations during the
> design phase.

**3.0 [Drawing Release]{.underline}**

> Upon completion of the Mission Critical Design Review (CDR) and
> establishment of the product baseline, approved drawings will put
> under Configuration Change Control and officially released.
>
> The CM Officer shall assist in the review/signature process in the
> following manner:
>
> Drawing Files will be sent via email (or FTP) to the CM Officer when
> the drawing is ready for review. It is requested that all files be
> sent in a ".EPS" (encapsulated post script) or ".PS" (post script)
> format.
>
> Individuals needing to review the drawing(s) will be able to do so
> electronically by accessing the ICESat Project homepage, where the
> drawings will be available in a "review" location.
>
> After review, the responsible individuals will electronically "sign"
> the drawing by marking an "X" in the appropriate location (using their
> assigned password) if they approve the drawing. If there are any
> problems with the drawing, the CM Officer should be notified
> immediately, so that any conflict can be resolved.
>
> The CM Officer will then be responsible for notifying the draftsperson
> of the correct names, initials, and approval dates so that an updated
> file can be forwarded to the CM Officer.

G-1

> The CMO will verify that the drawing format is in compliance with the
> GSFC Engineering Design Standards Manual (X-673-64-1F). Officially
> released drawings will have a control stamp marking (showing it's a
> product of the GSFC ICESat Project CMO) and the date of release, along
> with the initials of the CMO who released the drawing.
>
> Once baselined, the CMO shall maintain drawing originals (if
> requested), CAD files (which shall be supplied by the individual
> submitting the drawing), and distribute copies to the appropriate
> individuals, upon request. Drawing files will be sent via email (or
> FTP) to the CM Officer when the drawing is ready for release.
>
> The drawing will then be added into the CoMITS database in the
> "controlled" area and the drawing file will be "linked" to the record.
> At this point, the drawing can be accessed from the "controlled" or
> released area by all Project members (see Appendix J for further
> details).
>
> If drawings are not to be baselined for some time, preliminary
> versions should be submitted for reference purposes and will be
> stamped as such.

**4.0 [Revisions]{.underline}**

> It is the responsibility of the originator of the change to submit an
> EO prior to changing a drawing. The individual initiating the change
> must complete an EO and submit it to the CMO for processing. This form
> must be submitted and approved prior to making any changes to the
> original drawing.
>
> Revisions to drawings **shall** automatically be made once five EOs
> have accumulated. The methodology for revising drawings is described
> in the GSFC Engineering Design Standards Manual (X-673-64-IF). All
> drawings will comply with the engineering drawing manual.

**5.0 [Multi-sheet Revisions]{.underline}**

> The following method excerpted from the engineering drawing manual
> (X-673-64-IF) will be used for revising multi-sheet drawings:

*7.3 Revision of Multi-sheet Drawings*

*Revisions to any sheet(s) shall be recorded in the revision description
block on sheet 1, and reference shall be made to sheet(s) affected.
Level of revision shall be changed on each drawing sheet whether or not
that particular sheet is affected. The revision description block on all
sheets other than sheet 1 shall state \"See sheet 1 for revision".*

G-2

**APPENDIX H**

**PROCESSING OF ENGINEERING ORDERS**

**1.0 [Purpose]{.underline}**

> The purpose of this appendix is to describe the method for processing
> an engineering order (EO) for the modification of a released drawing.

**2.0 [EO Number Assignment]{.underline}**

> All EO numbers are assigned sequentially by the Configuration
> Management Officer (CMO) per drawing number.

**3.0 [EO Form Submittal]{.underline}**

> All changes to drawings under Configuration Control are to be
> submitted on an EO Form, as shown in Figure 7. The EO form is to be
> completed as defined in the GSFC Engineering Standards Design Manual
> (X-673-64-IF).

**4.0 [Review and Approval Process]{.underline}**

> Completed EOs, requesting a change, are sent to the CMO to review for
> completeness and processing. EOs will be reviewed by designated
> personnel as they impact their disciplines. The Project Manager, or
> his designee, has final approval authority.

**5.0 [Class 1 Changes]{.underline}**

> EO Class 1 changes which impact higher level interfaces shall be
> forwarded as an attachment to a Configuration Change Request (CCR) and
> follow the approval cycle described in Appendix F.

**6.0 [EO Incorporation ]{.underline}**

> All unincorporated EOs are attached to drawings until the drawing is
> revised. No more than five (5) unincorporated EOs shall be accumulated
> before a drawing revision is initiated and the new drawing revision is
> released.

**7.0 [EO Files]{.underline}**

> All original EOs, that have been approved, will be logged and filed.
> Unincorporated EO copies will be provided with any drawing copy
> requests.

H-1

Figure 7: Engineering Order (EO) Form (Page 1)

H-2

Figure 7: Engineering Order (EO) Form (Page 2)

H-3

**APPENDIX I**

**DEVIATIONS AND WAIVERS**

**1.0 [Purpose]{.underline}**

This appendix defines and explains the procedure for preparing
deviations and waivers.

**2.0 [Definitions]{.underline}**

A [deviation]{.underline} is a specific written authorization, granted
prior to the manufacture or testing of an item, to depart from a
particular performance or design requirement for that item.

A [waiver]{.underline} is a specific written authorization, granted
after manufacture or testing of an item, to accept a departure from a
particular performance or design requirement for that item.

**3.0 [Classifications]{.underline}**

• Minor - does not materially reduce usability of the end item.

• Major - affects baselined documentation, technical requirements,
non-technical contractual provisions, Government Furnished Equipment
(GFE), interfaces, or retrofit.

• Critical - affects requirements involving health or safety.

> All requests for deviations/waivers shall be submitted to the CMO for
> processing through the Configuration Control Board (CCB) on a CCR
> Form. A deviation or waiver will not revise the requirement, but it
> will be appended to applicable documentation for information and
> traceability.

I-1

**APPENDIX J**

**CONFIGURATION MANAGEMENT INFORMATION TRACKING SYSTEM (CoMITS)**

The Configuration Management Information Tracking System (CoMITS) is a
dedicated information tracking and management tool, currently being used
to enter, query, and display engineering drawings and project
documentation online. Project documentation includes drawing and
document information, as well as Engineering Orders and Configuration
Change Request information.

This system is currently in use by several major instrument projects at
Goddard Space Flight Center, providing dynamic WEB page generation based
on user-definable queries. The use of "wildcard" features enables the
user to input as few or as many entities about the drawing or document
to narrow the search. Electronically viewable files are offered for
display when available.

CoMITS is accessed by team members via the project homepage located on
the World Wide Web **(http:// icesat.gsfc.nasa.gov)**.

From this menu, individuals can query the entire database (to include
drawings, documents, EOs, CCRs, memos, GEMs, general action items, and
data requirements) and electronically sign-off on assigned items. A
check mark (**√**) next to a document or drawing number signifies that a
file link exists and the file can then be viewed by the team member, if
necessary. Change request information (for both EOs and CCRs) is
generally linked, once it is scanned, to the applicable documentation
and can be viewed from this location.

J-1