> **LANDSAT DATA CONTINUITY**
>
> **MISSION**
>
> **MISSION OPERATIONS ELEMENT**
>
> **CONTRACT DATA REQUIREMENTS LIST (CDRL)**
>
> **October 2007**

![](media/image1.png)

**LDCM PROJECT**

# DOCUMENT CHANGE RECORD {#document-change-record .unnumbered}

Sheet: 1 of 1

+------------+----------------------------------------------+---------+
| REV        | DESCRIPTION OF CHANGE                        | DATE    |
|            |                                              |         |
| LEVEL      |                                              | A       |
|            |                                              | PPROVED |
+------------+----------------------------------------------+---------+
|            |                                              |         |
+------------+----------------------------------------------+---------+

  ------------------------------------------------------------------------------------------
  **Section**   **Type**   **Description**                    **Resolution   **Responsible
                                                              Due By**       Party**
  ------------- ---------- ---------------------------------- -------------- ---------------
                                                                             

                                                                             

                                                                             

                                                                             

                                                                             

                                                                             
  ------------------------------------------------------------------------------------------

# Table of TBDs / TBRs / TBSs {#table-of-tbds-tbrs-tbss .unnumbered}

The term "To Be Determined" (TBD) applied to a missing requirement means
that the contractor shall determine the missing requirement in
coordination with the Government. The term "To Be Supplied" (TBS) means
that the Government will supply the missing information in the course of
this contract. The term "To Be Reviewed" (TBR) means that the
requirement is subject to review for appropriateness by the contractor
or the Government, with approval by the Government. The Government may
change TBR requirements in the course of this contract.

# TABLE OF CONTENTS {#table-of-contents .unnumbered}

[Page]{.underline}

[DOCUMENT CHANGE RECORD ii](#document-change-record)

[Table of TBDs / TBRs / TBSs iii](#table-of-tbds-tbrs-tbss)

[TABLE OF CONTENTS iv](#table-of-contents)

[1.0 INTRODUCTION 1-1](#introduction)

[2.0 DEFINITION OF DUE DATES/MATURITY, DEFINITION OF CATEGORIES, AND
MAILING DISTRIBUTION INSTRUCTIONS
2-1](#definition-of-due-datesmaturity-definition-of-categories-and-mailing-distribution-instructions)

[2.1 DUE DATES/MATURITY - Related Definitions
2-1](#due-datesmaturity---related-definitions)

[2.2 QUANTITY - Related Definitions
2-2](#quantity---related-definitions)

[2.3 MEDIA - Related Definitions 2-2](#media---related-definitions)

[2.4 CATEGORY - Related Definitions
2-3](#category---related-definitions)

[3.0 LDCM CONTRACT DATA requirementS LIST
3-1](#ldcm-contract-data-requirements-list)

[4.0 DESCRIPTIONS of required data 4-7](#descriptions-of-required-data)

**LIST of TABLES**

[Table]{.underline} [Page]{.underline}

**Table 3‑1 Contract Data Requirements List (CDRL)
[3-2](#__RefHeading___Toc10535819)**

# INTRODUCTION

This Contract Data Requirements List (CDRL) document defines the
requirements for deliverable documentation to be provided by the Mission
Operations Element (MOE) Contractor. Section 2.0 includes definitions
and instructions for mailing and/or distribution. Table 3-1 presents the
CDRL item by item, with due dates, quantity, and media format. Section
4.0 provides the Description of Required Data (DRD), a description of
each item which provides the use of the deliverable and the required
preparation information. Except where specifically indicated to the
contrary, the formats and drawing standards used shall be those normally
used by the MOE Contractor and by its subcontractors.

# DEFINITION OF DUE DATES/MATURITY, DEFINITION OF CATEGORIES, AND MAILING DISTRIBUTION INSTRUCTIONS 

## DUE DATES/MATURITY - Related Definitions

The following definitions apply to the \"DUE DATE, MATURITY\" column in
Table 3-1. Unless otherwise specified, deadlines are in working days.

> DUE DATE:

(1) [M-SRR, M-PDR, M-CDR, GS-PDR, GS-CDR, MOR, FOR, ORR, OAR, other
    milestone reviews, etc]{.underline}: MOE System Requirements Review,
    MOE Preliminary Design Review, MOE Critical Design Review, Mission
    Operations Review, Flight Operations Review, Operations Readiness
    Review, On-Orbit Acceptance Review etc. Electronic distribution to
    be delivered to the Government 5 working days prior to review,
    unless otherwise stated.

(2) [As Generated, Update As Required (UAR)]{.underline}: After each
    initial edition, revision, addition, etc. Items that are critical to
    schedule, performance, or interface shall be transmitted to GSFC by
    facsimile or express mail within 48 hours of generation. Where
    available, an electronic version shall also be provided.

(3) [Monthly]{.underline}: Submitted on monthly basis

(4) [T]{.underline}: Launch Date

(5) [DACA]{.underline}: (Calendar) Days After Contract Award

(6) [E]{.underline}: Electronic copies are due at the same time as hard
    copies unless otherwise specified.

```{=html}
<!-- -->
```
(b) MATURITY:

```{=html}
<!-- -->
```
(1) [Initial]{.underline}: The first submission of an item which will be
    revised and resubmitted at a later date.

(2) [Preliminary]{.underline}: An early submission of an item. To be
    completed as is practicable at the time of preparation. Preliminary
    submittals are written with the best available current information
    and are resubmitted when further information becomes available.

(3) [Final]{.underline}: The complete, thorough submission of an item
    for approval, review, or information that, to the best of the
    contractor's knowledge and intention, will not require further
    revision or updates. However, this does not preclude updating if
    later found to be necessary. Any updates shall require the same
    \"approval/review\" process as was required for the original
    submissions.

(4) [Current]{.underline}: The delivery is written with the best
    up-to-date information available at the time.

(5) [Update]{.underline}: The delivery is revised with the best
    up-to-date information available at the time.

Other entries in the \"DUE DATE, MATURITY\" column are self-explanatory.

## 2.2 QUANTITY - Related Definitions {#quantity---related-definitions .unnumbered}

The quantities to be delivered shall be per the CDRL listing in column
\"Quantity (QTY)\" in Table 3-1 of this document. If separate quantities
are not specified for separate submission due date/maturity items, then
the listed quantity applies to all submissions.

## MEDIA - Related Definitions

The following definition applies to the \""MEDIA" column in Table 3-1.

H -- Hardcopy(s) of this documentation shall be delivered to the
Contracting Officer at GSFC Code 427.

E - Data items shall be delivered in electronic format to a GSFC Landsat
specified web portal unless otherwise noted in Table 3-1. Quantities
refer to hardcopies, not electronic copies. The Contracting Officer
shall be notified of electronic submission of the deliverable in
writing. Electronic deliverables shall be delivered in the following
formats unless otherwise approved by the government:

> Text Documents: PDF (searchable) or MSWord
>
> Presentations: PDF (searchable) or PowerPoint
>
> Spreadsheets: Microsoft Excel
>
> Database: Delimited ASCII files accompanied with database schema
> document defining tables and entries.
>
> Schedules: PDF and MS Project
>
> Schematics and Drawings: Design Web Format (DWF) and PDF
>
> Photographs: JPEG or current industry standard.
>
> Video: Any readily available open standard (e.g., AVI, MPEG)

R -- For Reviews, hardcopies shall be made available at the review site
for government representatives. (Generally, this will be in addition to
electronic copies being made available prior to the review.) The
quantity specifies the number of hardcopies to be available at the
review for government representatives.

If separate distribution instructions are not specified for separate
submission due date/maturity items, then the listed distribution applies
to all submissions.

## CATEGORY - Related Definitions 

The following definitions apply to \"Submission Category (CAT)\" column
in Table 3-1. If separate approval instructions are not specified for
separate submission due date/maturity items, then the listed approval
instruction applies to all submissions.

> A Approval: CDRL items in this category require approval by the GSFC
> Contracting Officer's Technical Representative (COTR) or Contracting
> Officer prior to use by the contractor. Receipt by the Government
> shall occur within the time specified in the \"Due Date\" column of
> Table 3-1 of this document. Requirements for re-submission shall be as
> specified by the Contracting Officer. For most cases the contractor
> will be required to resubmit the document within 14 calendar days of
> receiving comments from the Government. If the contractor has not
> received response from GSFC within 30 calendar days of delivery of a
> CDRL item, the contractor may proceed as if the document has been
> approved.
>
> R Review. Documents in this category require delivery to the
> Government prior to use and within the time period specified in the
> \"Due Date\" column of Table 3-1 of this document. They are subject to
> evaluation by the Government or its designated representatives to
> determine Contractor effectiveness in meeting contract objectives.
> Upon submission, the Contractor may proceed with associated work while
> the Government reviews the submission.
>
> I Information. Data in this category shall be delivered to the
> Government within the time period specified in the "Due Date" column
> of Table 3-1 for the purpose of determining current program status,
> progress, and future planning requirements.

# LDCM CONTRACT DATA requirementS LIST

Table 3-1 comprises the LDCM Contract Data Requirements List.

The Table is in the following order:

Program Management (PM)

Reviews (RE)

System Engineering (SE)

Mission Operations (MO)

[]{#__RefHeading___Toc10535819 .anchor}Table 3‑1 Contract Data
Requirements List (CDRL)

+-----+-----------------------+--------------------+----+-------+----+
| *   | **MANAGEMENT**        | **DUE DATE,        | *  | **ME  | *  |
| *No |                       | MATURITY**         | *Q | DIA** | *C |
| .** |                       |                    | TY |       | AT |
|     |                       |                    | ** |       | ** |
+=====+=======================+====================+====+=======+====+
| P   | Monthly Project       | Monthly (nominally | 5  | E, R  | I  |
| M-1 | Status Reviews (MSR)  | the last Wednesday |    |       |    |
|     |                       | of each month)     |    |       |    |
+-----+-----------------------+--------------------+----+-------+----+
| P   | Integrated Master     | \- Initial 30 DACA | 3  | H, E  | A  |
| M-2 | Schedules (IMS)       |                    |    |       |    |
|     |                       | \- Update Monthly, | 3  | H, E  | A  |
|     |                       | delivered 7 days   |    |       |    |
|     |                       | prior to MPSR      |    |       |    |
+-----+-----------------------+--------------------+----+-------+----+
| P   | Final Report          | Delivered          | 2  | H, E  | I  |
| M-4 |                       | incrementally at:  |    |       |    |
|     |                       |                    |    |       |    |
|     |                       | M-CDR              |    |       |    |
|     |                       |                    |    |       |    |
|     |                       | MOC Installation   |    |       |    |
|     |                       |                    |    |       |    |
|     |                       | Launch -- 60 days  |    |       |    |
|     |                       |                    |    |       |    |
|     |                       | Acceptance + 30    |    |       |    |
|     |                       | days               |    |       |    |
+-----+-----------------------+--------------------+----+-------+----+
| P   | Engineering Peer      | \- with Proposal,  | 2  | H, E  | I  |
| M-5 | Review Plan           | Preliminary        |    |       |    |
|     |                       |                    | 2  | H, E  | A  |
|     |                       | \- 35 DACA, Final  |    |       |    |
+-----+-----------------------+--------------------+----+-------+----+
| P   | Earned Value System   | \- Preliminary     | 1  | E     | I  |
| M-6 | Management Plan       | submission after   |    |       |    |
|     |                       | notification of    | 1  | E     | A  |
|     |                       | selection, but     |    |       |    |
|     |                       | prior to contract  | 1  | E     | A  |
|     |                       | award              |    |       |    |
|     |                       |                    |    |       |    |
|     |                       | \- Initial         |    |       |    |
|     |                       | submission 60 DACA |    |       |    |
|     |                       |                    |    |       |    |
|     |                       | \- Updated if EVM  |    |       |    |
|     |                       | System             |    |       |    |
|     |                       | Architecture       |    |       |    |
|     |                       | changes            |    |       |    |
+-----+-----------------------+--------------------+----+-------+----+
| P   | Financial Reports     | 533Q: Quarterly    | 4  | H, E  | R  |
| M-7 |                       |                    |    |       |    |
|     |                       | 533M: Monthly      | 4  | H, E  | R  |
+-----+-----------------------+--------------------+----+-------+----+
| P   | Cost Performance      | \- Formats 1,3,5   | 1  | H, E  | I  |
| M-8 | Reports               | Monthly (no later  |    |       |    |
|     |                       | than 15 calendar   |    |       |    |
|     |                       | days after         |    |       |    |
|     |                       | accounting         |    |       |    |
|     |                       | calendar month end |    |       |    |
|     |                       | date)              |    |       |    |
+-----+-----------------------+--------------------+----+-------+----+
| PM  | Hardware and Software | Draft, with        | 2  | H, E  | R  |
| -10 | Configuration         | proposal           |    |       |    |
|     | Management Plan       |                    |    |       |    |
|     |                       | 60 DACA, Final     |    |       |    |
+-----+-----------------------+--------------------+----+-------+----+
| PM  | Project Management    | 30 DACA, Final     | 2  | H, E  | R  |
| -11 | Plan                  |                    |    |       |    |
+-----+-----------------------+--------------------+----+-------+----+
| PM  | Risk Management Plan  | Draft, with        | 2  | H, E  | R  |
| -12 |                       | proposal           |    |       |    |
|     |                       |                    |    |       |    |
|     |                       | 60 DACA, Final     |    |       |    |
+-----+-----------------------+--------------------+----+-------+----+
| PM  | Organizational        | 45 DACA, Final     | 2  | H, E  | A  |
| -13 | Conflict of Interest  |                    |    |       |    |
|     | Avoidance Plan        |                    |    |       |    |
+-----+-----------------------+--------------------+----+-------+----+

  ----------------------------------------------------------------------------------------------
  **No.**   **REVIEWS**                     **DUE DATE,       **QTY**   **MEDIA**      **CAT**
                                            MATURITY**                                 
  --------- ---------------------------- -- ----------------- --------- ----------- -- ---------
  RE-1      MOE System Requirements         Electronic copy   10        H,R,E          I
            Review Data Packages            in Project                                 
                                            library 5 days                             
                                            prior to review.                           
                                            Hard copies at                             
                                            review.                                    

  RE-2      MOE Preliminary Design          Electronic copy   10        H,R,E          I
            Review Data Packages            in Project                                 
                                            library 5 days                             
                                            prior to review.                           
                                            Hard copies at                             
                                            review.                                    

  RE-3      MOE Critical Design Review      Electronic copy   10        H,R,E          I
            Packages                        in Project                                 
                                            library 5 days                             
                                            prior to review.                           
                                            Hard copies at                             
                                            review.                                    

  RE-5      MOE Pre-Ship Review Data        Electronic copy   10        H,R,E          I
            Packages                        in Project                                 
                                            library 5 days                             
                                            prior to review.                           
                                            Hard copies at                             
                                            review.                                    

  RE-6      Input to Ground System and      Electronic copy   50        H, R, E        I
            Mission Reviews                 in Project                                 
                                            library 5 days                             
                                            prior to review.                           
                                            Hard copies at                             
                                            review.                                    

  RE-7      Engineering Peer Review Data    Hard copies at    10        H              I
            Packages                        review.                                    

                                                                                       
  ----------------------------------------------------------------------------------------------

+----+--------------------------+------------------+---+---+------+-----+
| *  | **SYSTEMS ENGINEERING**  | **DUE DATE,      | * | * |      | *   |
| *N |                          | MATURITY**       | * | * |      | *CA |
| o. |                          |                  | Q | M |      | T** |
| ** |                          |                  | T | E |      |     |
|    |                          |                  | Y | D |      |     |
|    |                          |                  | * | I |      |     |
|    |                          |                  | * | A |      |     |
|    |                          |                  |   | * |      |     |
|    |                          |                  |   | * |      |     |
+====+==========================+==================+===+===+======+=====+
| SE | Engineering Change       | Class I, As      | 2 |   | H, E | A   |
| -1 | Requests, Deviations,    | Generated        |   |   |      |     |
|    | and Waivers              |                  | \ |   | E    | I   |
|    |                          | Class II, As     | - |   |      |     |
|    |                          | Generated        |   |   |      |     |
+----+--------------------------+------------------+---+---+------+-----+
| SE | Contractor Generated     | As Requested     | 2 |   | Orig | I   |
| -2 | Internal Technical       |                  |   |   | inal |     |
|    | Information              |                  |   |   | fo   |     |
|    |                          |                  |   |   | rmat |     |
|    |                          |                  |   |   | (H   |     |
|    |                          |                  |   |   | or   |     |
|    |                          |                  |   |   | E)   |     |
+----+--------------------------+------------------+---+---+------+-----+
| SE | System Performance       | Electronic copy  | 5 |   | H, E | A   |
| -6 | Verification Plan and    | 10 days prior to |   |   |      |     |
|    | Matrix                   | M-PDR,           |   |   |      |     |
|    |                          | preliminary      |   |   |      |     |
|    |                          |                  |   |   |      |     |
|    |                          | Electronic copy  |   |   |      |     |
|    |                          | 10 days prior to |   |   |      |     |
|    |                          | M-CDR, update    |   |   |      |     |
|    |                          |                  |   |   |      |     |
|    |                          | Electronic copy  |   |   |      |     |
|    |                          | 15 days prior    |   |   |      |     |
|    |                          | M-PR, Final      |   |   |      |     |
|    |                          |                  |   |   |      |     |
|    |                          | Hard copies at   |   |   |      |     |
|    |                          | reviews.         |   |   |      |     |
|    |                          |                  |   |   |      |     |
|    |                          | Updates As       |   |   |      |     |
|    |                          | Required         |   |   |      |     |
+----+--------------------------+------------------+---+---+------+-----+
| SE | Verification Reports     | Within 30 days   | 2 |   | H, E | R   |
| -7 |                          | after each       |   |   |      |     |
|    |                          | verification,    |   |   |      |     |
|    |                          | Final            |   |   |      |     |
+----+--------------------------+------------------+---+---+------+-----+
| SE | Configuration Item       | M-PDR,           | 2 |   | H, E | I   |
| -8 | Identification List      | Preliminary      |   |   |      |     |
|    |                          |                  | 2 |   | H, E | I   |
|    |                          | M-CDR, Final     |   |   |      |     |
+----+--------------------------+------------------+---+---+------+-----+
| S  | Specification Tree       | M-SRR, Final     | 2 |   | H, E | I   |
| E- |                          |                  |   |   |      |     |
| 13 |                          |                  |   |   |      |     |
+----+--------------------------+------------------+---+---+------+-----+
| S  | Trades and Analyses      | Initial, M-PDR   | 3 |   | H, E | R   |
| E- |                          |                  |   |   |      |     |
| 20 |                          | Update, M-CDR    | 3 |   | H, E | R   |
|    |                          |                  |   |   |      |     |
|    |                          | Updates          | 3 |   | H, E | R   |
|    |                          | summarized twice |   |   |      |     |
|    |                          | per year         |   |   |      |     |
|    |                          | thereafter       |   |   |      |     |
+----+--------------------------+------------------+---+---+------+-----+
| S  | Acceptance Data Package  | At OAR           | 2 |   | H, E | A   |
| E- |                          |                  |   |   |      |     |
| 23 |                          |                  |   |   |      |     |
+----+--------------------------+------------------+---+---+------+-----+

+------+----------------------+--------------------+----+-------+----+
| **N  | **MISSION OPERATIONS | **DUE DATE,        | *  | **ME  | *  |
| o.** | ELEMENT**            | MATURITY**         | *Q | DIA** | *C |
|      |                      |                    | TY |       | AT |
|      |                      |                    | ** |       | ** |
+======+======================+====================+====+=======+====+
| MO-2 | Mission Operations   | Draft version at   | 3  | H,E   | R  |
|      | Element Interface    | M-PDR              |    |       |    |
|      | Control Document     |                    | 3  | H,E   | R  |
|      | (ICD) inputs         | Final version at   |    |       |    |
|      |                      | M-CDR              |    |       |    |
+------+----------------------+--------------------+----+-------+----+
| MO-3 | Mission Operations   | Electronic copy 5  | 3  | H, E  | I  |
|      | Element Lower-Level  | days prior to M-   |    |       |    |
|      | System Requirements  | SRR                |    |       |    |
|      | Document             |                    |    |       |    |
+------+----------------------+--------------------+----+-------+----+
| MO-4 | MOE Test Plan(s)     | Draft - electronic | 3  | H,E   | R  |
|      |                      | copy 2 weeks after |    |       |    |
|      |                      | M-PDR              | 3  | H,E   | R  |
|      |                      |                    |    |       |    |
|      |                      | Final - electronic |    |       |    |
|      |                      | copy 2 weeks prior |    |       |    |
|      |                      | to M-CDR           |    |       |    |
|      |                      |                    |    |       |    |
|      |                      | Hard copies at     |    |       |    |
|      |                      | reviews.           |    |       |    |
+------+----------------------+--------------------+----+-------+----+
| MO-5 | Mission Operations   | Drafts 2 weeks     | 3  | H,E   | I  |
|      | Element Test         | after M-CDR        |    |       |    |
|      | Procedures Document  |                    | 3  | H,E   | I  |
|      |                      | Final 2 weeks      |    |       |    |
|      |                      | prior to           |    |       |    |
|      |                      | applicable test    |    |       |    |
+------+----------------------+--------------------+----+-------+----+
| MO-6 | Mission Operations   | 3 work days after  | \- | E     | I  |
|      | Element Test Reports | Test, Final        |    |       |    |
+------+----------------------+--------------------+----+-------+----+
| MO-7 | MOE Installation,    | M-CDR, Preliminary | 3  | H, E  | R  |
|      | Setup, and           |                    |    |       |    |
|      | Configuration        | With each MOE      | 3  | H, E  | R  |
|      | Procedures           | delivery           |    |       |    |
+------+----------------------+--------------------+----+-------+----+
| MO-9 | MOE Software         | M-SRR              | 5  | H, E  | R  |
|      | Development          |                    |    |       |    |
|      | Management Plan      |                    |    |       |    |
|      | (SDMP)               |                    |    |       |    |
+------+----------------------+--------------------+----+-------+----+
| M    | MOE Software Version | With each MOE      | 3  | H, E  | I  |
| O-10 | Description Document | delivery           |    |       |    |
+------+----------------------+--------------------+----+-------+----+
| M    | MOE Hardware         | With each MOE      | 3  | H, E  | I  |
| O-11 | Inventory            | delivery           |    |       |    |
+------+----------------------+--------------------+----+-------+----+
| M    | MOE Design           | Draft 2 weeks      | 3  | H, E  | R  |
| O-12 | Specification and    | prior to M-PDR     |    |       |    |
|      | Description          |                    | 3  | H, E  | R  |
|      |                      | Final 2 weeks      |    |       |    |
|      |                      | after M-CDR        |    |       |    |
+------+----------------------+--------------------+----+-------+----+
| M    | Flight Operations    | Draft 6 weeks      | 3  | H, E  | R  |
| O-13 | Team Training Plan   | prior to first     |    |       |    |
|      |                      | training session   | 3  | H, E  | R  |
|      |                      |                    |    |       |    |
|      |                      | Final 2 weeks      |    |       |    |
|      |                      | prior to final MOE |    |       |    |
|      |                      | installation in    |    |       |    |
|      |                      | MOC / Ground       |    |       |    |
|      |                      | System Integration |    |       |    |
+------+----------------------+--------------------+----+-------+----+
| M    | MOE Facility         | Draft 2 weeks      | 3  | H, E  | R  |
| O-14 | Integration Plan     | prior to M-PDR     |    |       |    |
|      |                      |                    | 3  | H, E  | R  |
|      |                      | Final 2 weeks      |    |       |    |
|      |                      | after M-PDR        |    |       |    |
+------+----------------------+--------------------+----+-------+----+
| M    | MOE User's Manual    | With each MOE      | 3  | H, E  | I  |
| O-15 |                      | delivery           |    |       |    |
+------+----------------------+--------------------+----+-------+----+
| M    | Inputs to LDCM       | Every 3 months     | 1  | E     | A  |
| O-16 | Project Database     |                    |    |       |    |
+------+----------------------+--------------------+----+-------+----+
| M    | MYK-15 Documentation | With MYK-15        | 1  | H, E  | I  |
| O-17 |                      | delivery           |    |       |    |
+------+----------------------+--------------------+----+-------+----+
| M    | LDCM Key Management  | Preliminary, M-PDR | 1  | E     | R  |
| O-18 | Plan inputs          |                    |    |       |    |
|      |                      | Draft, M-CDR       | 1  |       |    |
|      |                      |                    |    |       |    |
|      |                      | Updates as         | 1  |       |    |
|      |                      | required           |    |       |    |
|      |                      |                    | 1  |       |    |
|      |                      | Final, ORR         |    |       |    |
+------+----------------------+--------------------+----+-------+----+

# DESCRIPTIONS of required data 

**MANAGEMENT DRDs**

**DESCRIPTION OF REQUIRED DATA**1. [CDRL No.:]{.underline} 2.
[Title:]{.underline}

PM-1 Monthly PROJECT STATUS REVIEWS

3\. [Reference:]{.underline}

SOW 1.1

SOW 1.2

4\. [Use:]{.underline}

To evaluate contract status. These reports will be used to provide an
opportunity for face-to-face discussions between the contractor and the
Government regarding project status, plans and issues.

5\. [Preparation Information:]{.underline}

Scope: The MPSR shall include all aspects of the contract effort.

The Monthly Project Status Review (MPSR) will be presented at a
face-to-face meeting with the Government. These meetings will take place
alternating between the Contractor\'s site and a Government site, unless
modified by mutual consent.

The Monthly Project Status Review shall include the following:

A.  Technical status for system and subsystem design and development
    activities, including subcontract technical performance

B.  A comparison of planned versus actual accomplishments for the period
    of time since the prior report.

C.  Summary of Integrated Master Schedule Status, including a brief
    description of the current status of each subsystem along with
    descriptions of any existing or potential problems areas. The
    critical path and near critical paths shall be explained along with
    possible work-arounds being considered to maintain the schedule. The
    third MPSR shall include a schedule baseline review. The basis of
    the review shall be the Integrated Master Schedule.

D.  A detailed 12-month "rolling-wave" schedule (3 months of actual,
    plus 9 months of forecast)

E.  Metrics summarizing all milestones depicting planned versus actual
    accomplishments and explanations for variances, e.g., graphic
    display of planned versus actual cumulative milestone status, xx of
    1000 milestones are behind plan and why, etc.

F.  Summary and explanation of key EVM parameter performance and trends

G.  Problems encountered during the reporting period, and anticipated
    approaches for resolution (including, as appropriate, technical
    issues, manpower and staffing, supplier and subcontractor issues,
    etc.)

H.  Status of open issues and problems from prior reporting periods

I.  Status of action items

J.  Significant plans and activities for the following month

K.  Identification of long-lead purchases/acquisitions/developments made
    prior to PDR and prior to CDR of the system in which the long lead
    item is a part of.

L.  Class I and Class II proposed and approved Configuration Control
    Board Changes

M.  Risk Status for top 10 risks, including risk mitigations and
    burn-down plans

N.  Software assurance reports

O.  Milestone events depicting critical items of project status for the
    succeeding month.

P.  Summary graphical presentation of project workforce staffing
    depicting planned versus actuals (3 months actual, 9 months of
    forecast), explanation of variances, and discussion of key vacancies
    and staffing issues.

Q.  Summary of financial status

R.  Business issues, including personnel changes

S.  CDRL Status Report that includes the following information for each
    document delivered in accordance with the CDRL or overdue from
    previous reporting periods:

> a\. Document Number.
>
> b\. Document Title.
>
> c\. Scheduled Due Date.
>
> d\. Actual Submittal Date.
>
> e\. Current Status
>
> f\. a list of documents planned for delivery during the next reporting
> period, listed by document number, title, and scheduled submittal
> date.

The contractor shall provide paper copies of the agenda, viewgraphs and
other presentation material for all Government attendees at the time of
the review. The contractor shall place MPSR material on the
Government-access electronic database by the day of the MPSR.
Presentation material may be in contractor format.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-2 Integrated master schedule (IMS)

3\. [Reference:]{.underline}

-   SOW 1.1

-   SOW 1.3

-   NPR 7120.5D, Program/Project Management Processes and Requirement

4\. [Use:]{.underline}

Schedules are used to plan, monitor, communicate status, and control all
activities, including pertinent resources and facilities, necessary to
accomplish assigned tasks in compliance with the LDCM MOE Statement of
Work. The IMS will provide the contractor's time-phased plan, current
status, key milestones, task interdependencies, and major development
phases necessary to accomplish the total scope of work. This schedule
will be used to provide management insight into contractor status,
potential problem areas, and critical path identification, which will
serve as the basis for evaluating contractor performance. The baseline
IMS will be the basis for evaluating the impact of government-directed
changes within the project.

5\. [Preparation Information:]{.underline}

The IMS shall be developed using the Critical Path Method-based
scheduling technique.  It will consist of the schedule baseline and the
current schedule updated each reporting period. The IMS shall relate
actual progress to the baseline and contain the current forecast for the
remaining tasks. The IMS shall be developed and maintained in the
current release of Microsoft Project.

The IMS shall include tasks necessary to accomplish the total scope of
work as defined in the work breakdown structure (WBS) including the
space segment and ground segment. The schedule shall also include all
logical relationships (interdependencies) between tasks. Schedules shall
contain the approved baseline schedule as well as current forecasted
dates and shall be traceable to the approved Work Breakdown Structure
(WBS). All key milestones shall be clearly identified including:
contract milestones, design reviews, readiness reviews, and
receivables/deliverables among subsystems/organizations (including
subcontractor effort). Milestones shall be logically linked to related
tasks. The project schedule shall be created and maintained in a manner
that supports automated time phasing of tasks, a logic driven critical
path, schedule assessment, and trend analysis capabilities.

The Integrated Master Schedule shall include:

A.  Activities detailed by task with early start and finish, and late
    start and finish dates

B.  Activity durations shall not exceed 20 work days (exceptions must be
    explained in the Contractor Schedule Assessment Report). The detail
    of the IMS submitted with the Proposal shall follow the instructions
    in [L.17, Subfactor C, C.6.]{.mark}

C.  Justification in the Contractor Schedule Assessment report for any
    activity or milestone not having a predecessor or successor
    activity, with the exception of the project start and finish
    milestones

D.  Clearly identified schedule reserve.

E.  Clearly identified need dates for GFE, if any.

F.  "As Soon As Possible" activity and milestone constraints (exceptions
    must be explained in the Contractor Schedule Assessment Report).

G.  "Finish To Start" activity relationships (exceptions must be
    explained in the Contractor Schedule Assessment Report).

H.  Realistic work calendars (indicating working and non-working
    periods)

I.  A month-end status date (i.e. "data date" or "as of date") REMARK:
    When the IMS is delivered on the 10^th^ calendar day of the month,
    it will reflect status as of the last calendar day of the preceding
    month)

J.  Activities associated with major items, components, or definable
    subsystems.

K.  Development schedules detailed to the subsystem level and showing
    substantive milestones.

L.  A development/test flow diagram that shows sequences of development,
    integration and test for subsystems and system and includes software
    assurance test points and associated requirements.

The IMS deliverable shall include the following items extracted from the
IMS database. All data contained in these items shall be consistent
(i.e. vertically and horizontally integrated), and based on the same
data/status date:

a\. Summary Master Schedule -- One page, top level, Gantt-type summary
document arranged by WBS that reflects all contract and major/mission
milestones, major project phases (i.e., design, development,
integration, test, etc.) and major end item deliveries.

b\. IMS Database -- an automated logic network database consisting of
schedule data for all WBS elements. The entire scope of work shall be
broken into schedule tasks and milestones at a consistent level of
detail to allow discrete progress measurement and visibility into the
overall development, integration, test, and delivery phase of each end
item deliverable. Additionally, all schedule tasks/milestones shall be
integrated with the appropriate sequence relationships to provide a
total end-to-end logic network leading to each end item delivery. This
database shall contain all contract and controlled milestones, key
subcontractor milestones, end item delivery dates, key data delivery
dates, and key Government Furnished Property (GFP) need dates. The IMS
Database shall contain the appropriate task coding attributes necessary
to provide sort, select, and summarization capabilities for, but not
limited to, WBS element, project phase, and level-of-effort tasks. The
logic network database serves as the basis for identification of project
critical paths as well as critical schedule analysis.

c\. Total Slack/Float Report -- This report shall be an extract from the
IMS Database and include all tasks and milestones with 10 workdays or
less of total slack (float). The report shall be submitted in a
waterfall format and organized in manner such that the path with least
amount of slack is delineated first and followed by each successive path
according to total slack values.

d\. Contractor Schedule Assessment Report -- This report shall contain a
count of the total number of tasks, milestones and non-detail (e.g.,
summary, hammock, rollup, etc.) activities contained in the schedule, a
count of the number of completed tasks and milestones, a count of the
number of tasks and milestones to be completed, a count of the number of
tasks and milestones that have no predecessor and/or successor
relationships, a count of the total number of tasks and milestones that
have a total float (slack) value greater than 25% of the remaining
duration of the total project schedule, a count of the total number of
non-detail (e.g., summary, hammock, rollup, etc.) activities that have
any predecessor or successor logical relationships, and a count of the
total number of tasks and milestones that have forced or fixed dates.
The report shall contain narratives explaining changes and impacts to
the critical path and total slack/float listed in section c above. The
report shall contain narrative explanations for contract milestones,
major/mission milestones and Project Control Milestones (PCMs) that have
been delayed by more than 10 calendar days into the future from their
baseline dates. PCMs shall be identified and negotiated with the project
office. These narratives shall include a proposed work-around schedule
detailing how the contractor plans to recover the lost schedule time.

e\. Project Control Milestone Trend Report -- A PCM cumulative trend
chart shall be submitted. This report shall consist of the baseline PCMs
and their corresponding early finish dates, actual PCMs completed to
date, and forecast PCMs for the remaining effort and their corresponding
early finish.

f\. Schedule Revision Log -- the contractor shall maintain and deliver a
revision log documenting all IMS changes (baseline and current forecast)
and their rationale (task additions, deletions, duration adjustments,
changes to logic, constraints, activity relationships, etc.).

g\. Weekly I & T Schedule -- A weekly I & T schedule shall be submitted
in contractor format containing prior week and the work planned for the
next two weeks.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-4 Final Report

3\. [Reference:]{.underline}

[Contract Clause C.3]{.mark}

SOW 1.1

4\. [Use:]{.underline}

To provide a summary of the performance of the contract.

5\. [Preparation Information:]{.underline}

The final report shall be written in increments so that the summary from
each phase of development can be more accurately captured. The final
report due at Acceptance + 30 days shall include all previously
delivered reports plus updates from the previous report delivery and
Acceptance.

Refer to contract clause [1852.235-73 (Section C.3 of]{.mark} the
contract) for additional instructions regarding the final report.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-5 engineering Peer review plan

3\. [Reference:]{.underline}

SOW 1.1

GPR 8700.6A, Engineering Peer Reviews

4\. [Use:]{.underline}

Early in project/product formulation, the Contractor shall identify
subsystems, components, software and crosscutting functions to be
subject to the Engineering Peer Review (EPR) process. The Peer Review
Plan is used to identify the methodology and scope of the contractor's
peer review process.

5\. [Preparation Information:]{.underline}

The Engineering Peer Review Plan shall:

a\. Describe the methodology used to determine the scope of the EPR
process, including rationale for specific components or subsystems that
will not be peer reviewed.

b\. Describe the peer review process, including personnel and expertise,
nominal agenda, and Request for Action (RFA) generation, tracking, and
closure process.

c\. Identify the concepts, designs, plans, processes, subsystems,
components, software, etc. that will be Peer Reviewed.

d\. Identify a schedule or associated milestones for the EPRs.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-6 Earned Value MANAGEMENT System (evms) Plan

3\. [Reference:]{.underline}

-   SOW 1.3

-   FAR 52.234-4 Earned Value Management System

*[\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_]{.underline}*

4\. [Description/Use:]{.underline}

The EVMS plan and documentation shall provide a description of the
contractor's implementation of an earned value management system that
demonstrates the use and understanding of the contract's overall
financial and project management system at all levels of management. It
shall also ensure that the system provides for the results of all
analyses based on EVM to be linked to the contractor's Risk Management
System (as applicable). Any cost and/or schedule risk being managed by
the contractor's Project Manager shall correlate the results of the EVM
analysis process to track, manage, and mitigate risk.

The contractor's plan shall include methods, policies, and procedures
utilized to demonstrate the ability to implement processes for managing
cost and schedule, management oversight, and variance analysis and
estimates at completion at the prime and subcontract levels.

This plan shall have flow down requirements to all major subcontracts to
ensure that subcontract management processes focus on those aspects
unique to managing subcontracts. The flow down of requirements shall
also ensure that subcontract costs and schedule are integrated, and that
assignment of earned value measurement methods, collection and reporting
of actual costs for subcontractor work scope, variance analysis, and
development of estimates to complete are in accordance with the
standards.

Revision to this may be required at the Government's request if a change
in the EVM system architecture occurs or in the event of a major
contract modification.

The use of electronic media is preferred unless disclosure of this
information would compromise information security.

5\. [Preparation Information:]{.underline}

The plan shall describe the development, approvals, software utilization
for EV reporting, responsibilities, and management thresholds.

The Contractor shall supply an EVM System Description as part of this
plan.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-7 FINANCIAL REPORTS

3\. [Reference:]{.underline}

-   SOW Paragraph 1.3

-   NPD 9501.2D, NASA Contractor Financial Management Reporting

-   G.1, Financial Management Reporting (GSFC 52.52.242-90)

-   G.8, NASA Contractor Financial Management Reporting(1852.242-73)

-   NPR 7120.5D, Program/Project Management Processes and Requirements

4\. [Use:]{.underline}

The 533M and Q, shall provide monthly and quarterly contractual planned
and actual expenditure data as defined by the Government including
subcontractor data. It shall also include estimated cost to complete.

5\. [Preparation Information:]{.underline}

-   The Monthly and Quarterly Financial Report shall be prepared in
    accordance with the G.1, Financial Management Reporting (GSFC
    52.52.242-90) as modified by the Government and G.8, NASA Contractor
    Financial Management Reporting (1852.242-73) clauses.

Financial reports shall be provided down to WBS level 4. A lower level
of reporting may be required for elements that are classed as technical,
schedule, cost and risk areas.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-8 Cost Performance Reports

3\. [Reference:]{.underline}

-   SOW 1.3

-   NPR 7120.5D, Program/Project Management Processes and Requirement

-   NFS 1852.242-75 Earned Value Management System (Deviation)

-   FAR 52.234-4 Earned Value Management System

-   DI-MGMT-81466A (3/30/2005)

-   Department of Defense Earned Value Management Implementation Guide
    (EVMIG) (website: <http://guidebook.dcma.mil/79/evmigoldversion.doc>
    October 2006)

4\. [Use:]{.underline}

To provide information to: (1) analyze integrated cost, schedule, and
variance at completion performance data with technical performance
measures, (2) identify the magnitude and impact of actual and potential
problem areas causing significant cost and schedule variances, and (3)
provide valid, timely contract status information to higher management.

5\. [Preparation Information:]{.underline}

The CPR shall include data pertaining to all authorized contract work,
including both priced and unpriced effort that has been authorized at a
not-to-exceed amount in accordance with the Contracting Officer\'s
direction. The CPR shall separate direct and indirect costs and identify
elements of cost for all direct reporting. The CPR shall include Formats
1, 3, and 5, down to a WBS Level 4. A lower level of reporting may be
required for elements that are classified as technical, schedule, or
cost risk areas.

Earned value performance measurement data for government-identified
high-risk WBS elements shall be reported on Format 1 of the monthly CPR
until such time as both Government project management and the Contractor
agree that they no longer represent high risks. This reporting shall be
at a level that is adequately sensitive to performance measurement
indicators to ensure earliest identification of cost and schedule
problems caused by the source risks (e.g., level 5, 6, or 7 or just
above control account level).

To ensure an integrated approach to risk management, the data provided
by this CPR DRD shall be in consonance with the Work Breakdown Structure
(WBS), Integrated Master Schedule (IMS), Risk Management Processes,
Plans and Reports (where required), Probabilistic Risk Assessment
Processes and Reports (where required),and the Monthly/Quarterly
Contractor Financial Management Reports (533M/Q). The financial
Management Reports shall include reconciliation between the 533M and Q
and the Cost Performance Report. This reconciliation may be included
within the required CPR Formats.

**[[FORMAT]{.underline}]{.smallcaps}**: EVSR formats shall be completed
according to the instructions outlined in DI-MGMT-81466 and the
following forms: Format 1 (DD Form 2734/1); Format 3 (DD Form 2734/3);
and Format 5 (DD Form 2734/5). Images of the EVSR forms are located at
<http://ceh.nasa.gov/webhelpfiles/earnedvaluecostperfrptp27a.htm> .
Format 5: The contractor shall classify and document monthly all cost
growth as either "risk-driven cost growth" or "externally-driven cost
growth". The explanations will be sourced at the control account levels,
addressed in any variance analysis and reported in two summary
paragraphs.  Definitions for "risk-driven" and "externally-driven" will
be discussed post contract award.

Contractor format may be substituted for EVSR formats whenever they
contain all the required data elements at the specified reporting levels
in a form suitable for NASA management use. The EVSR shall be submitted
electronically and followed up with a signed paper copy. The American
National Standards Institute (ANSI) X12/XML standards (transaction sets
839 for cost and 806 for schedule), or the United National Electronic
Data Interchange for Administration, Commerce and Transport (EDIFACT)
equivalent, shall be used for Electronic Data Interchange. This
information is located at <http://www.unece.org/trade/untdid/>.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

PM-10 Hardware and software Configuration Management Plan

3\. [Reference:]{.underline}

-   SOW 1.2

4\. [Use:]{.underline}

Defines the contractor's configuration management system (including
policies and procedures) that will be implemented for MOE hardware and
software.

5\. [Preparation Information:]{.underline}

The contractor's hardware/software configuration management plan shall
be prepared in accordance with the contractor's standards. This plan
shall describe in detail all software and hardware configuration
management processes, methods, and procedures the contractor intends to
use during the MOE contract. This plan shall describe how hardware and
software configuration management is accomplished and how consistency
between product definition, the product's configuration, and the
configuration management records is achieved and maintained throughout
the applicable phases of the product's life cycle by the contractor.

The configuration management plan shall describe the contractor's
approach, methodology, and application of configuration management
principles and practices and shall include the following:

1\. General product definition and scope

2\. Description of configuration management activities and procedures
for each of the following configuration management functions:

> a\. Configuration planning and management
>
> b\. Configuration identification
>
> c\. Configuration Change management
>
> d\. Configuration status accounting
>
> e\. Configuration verification and audit

f\. Configuration management of digital data

g\. Configuration management of software

3\. Organization, roles, responsibilities and resources

4\. Definition of terms

5\. Programmatic and organizational interfaces

6\. Subcontract flow down of configuration management

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:\
]{.underline}

PM-11 PROJECT MANAGEMENT PLAN

3\. [Reference:]{.underline}

SOW 1.1

4\. [Use:]{.underline}

Describes how the project is organized and managed by the contractor. It
provides the management structure, its system of operation, responsible
lines of communications, and key personnel assignments. The organization
chart identifies the contractor\'s project organization with names,
functions, lines of authority, coordination, etc

5\. [Preparation Information:]{.underline}

This plan shall address the overall organization, management approach,
and structure of the contractor's project plus its interrelationships
with the parent company and the subcontractors.

Describe how and where the project will operate during all phases of the
contract.

This plan shall identify and describe interfaces with the Government.

This plan shall include graphical displays such as flow diagrams, WBS,
logic networks, etc., to reduce verbal descriptive material.

This plan shall provide an organizational chart(s) and sufficient
supplemental narrative to describe fully the following:

\(a\) Organization proposed for carrying out the project showing
interrelationships of technical management, business management, and
subcontract management, from lower level through intermediate management
to top-level management with detailed explanation of:

> 1\. The authority of the Project Manager relative to other ongoing
> projects and applicable support organizations within the company
> structure. Discuss the Project Manager's control over essential
> resources and functions necessary to accomplish the work.
>
> 2\. How and by whom interdepartmental work will be monitored and the
> authority of the Project Manager over interdepartmental work.
>
> 3\. Process to be followed by the Project Manager in obtaining
> decisions beyond his/her authority and in resolving priority conflicts
> for resources and functions not under the Project Manager's direct
> control such as personnel, finances, and facilities.
>
> 4\. The project team members with names and functions.

\(b\) Implementation approach for the project. Describe in general how
the requirements of the Statement of Work (SOW) will be achieved.
Identify potential problems related to this work, and your approach to
problem avoidance and/or solution. Identify how your risk management
system and processes are integrated into the daily management, decision
making, and strategic direction of the project. Describe your schedule
management process. Address the degree to which your proposed personnel
and overall management procedures are proven through similar experience.
Describe such things as make/buy strategies, acquisition plans, sparing
philosophy, project dependencies, facility requirements, internal review
strategies and plans, significant work elements on critical paths,
long-lead items, and significant milestones down to at least the lowest
level of the WBS.

\(c\) Contractual procedures proposed for the project to effect
administrative and engineering changes, describing any differences from
existing procedures.

\(d\) Management techniques to be employed to minimize: 1) project costs
and schedule overruns, and 2) risks of violating interface requirements
and agreements. Describe associated controls to be exercised over
subcontractors and suppliers. Describe how issues will be surfaced in a
timely manner and at the proper levels. Identify initial proposed Key
Technical Parameters the project will use to monitor and report on (see
CDRL PM-1) interface compliance and resource status.

\(e\) The proposed Safety/Security and Software Assurance organizational
structure, including staffing plans, reporting channels, authority and
responsibilities, and management visibility. Discuss whether the
technical, test, and system safety/quality assurance/ reliability/
configuration management personnel required for this project (as
indicated in your proposed labor hours) are presently on your payroll
and immediately available for this work. State the number and
disciplines/skills of persons who would have to be hired, and plans to
obtain them.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:\
]{.underline}

PM-12 RISK MANAGEMENT PLAN

3\. [Reference:]{.underline}

SOW 1.1

GPR 7120.4A, Risk Management

NPR 8000.4 Risk Management Procedural Requirements w/Change 1 (4/13/04)
***e***

4\. [Use:]{.underline}

The Risk Management Plan is the basis for identifying and managing all
performance, reliability, schedule, cost, and safety risks on the
contractor's project.

5\. [Preparation Information:]{.underline}

The risk management plan shall clearly describe:

-   Overview of the risk management process

-   Organizational responsibilities

-   Risk identification approach

-   Risk mitigation planning

-   Interface of risk management to schedule and financial/cost
    management

-   Risk tracking/documentation

-   Risk management list reporting

The plan shall include risks associated with hardware and software
(e.g., technical challenges, new technology qualification, etc.), COTS,
system safety/security, performance, cost and schedule (i.e.,
programmatic risks). The plan shall identify which tools and techniques
will be used to manage the risks and the plan shall use the GSFC risk
5x5 definitions as described in Figure 1. The plan shall also express
risk statements in the condition-consequence format as expressed in the
following:

-   Risk Statement: For a risk to be understandable, it must be
    expressed clearly and include:

    -   Condition: A description of the current condition that may lead
        to the loss or consequence. It is a single phrase that
        identifies possible future problems, and describes current key
        circumstances, situations, etc. that are causing concern, doubt,
        anxiety, or uneasiness.

    ```{=html}
    <!-- -->
    ```
    -   Consequence: A description of the loss or consequence. It is a
        single phrase or sentence that describes the key, negative
        outcome (s) of the current conditions

> ![](media/image2.jpeg){width="6.192361111111111in"
> height="5.300694444444445in"}
>
> **DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:\
]{.underline}

PM-13 Organizational Conflicts of Interest Avoidance Plan

3\. [Reference:]{.underline}

SOW 1.1

NFS 1852.237-72

4\. [Use:]{.underline}

To provide the Contractor's plan for handling of sensitive information
from other contractors.

5\. [Preparation Information:]{.underline}

The Organizational Conflicts of Interest Avoidance Plan shall address
all the requirements of NASA FAR Supplement 1852.237-72.

**REVIEWS DRDS**

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

RE-1 moe System Requirements Review (m-SRR) Data package

3\. [Reference:]{.underline}

SOW 1.1

GSFC-STD-1001

4\. [Use:]{.underline}

To evaluate the requirements, requirements flow-down, and the
operational concepts and to validate the realism of the functional and
performance requirements and their congruence with the system
configuration selected to conduct the mission.

5\. [Preparation Information:]{.underline}

The M-SRR shall contain the flow-down of requirements from the MOE
Requirements Document to the MOE Design Specification (CDRL MO-12) and
first-order allocations.

The M-SRR Data Package shall contain all relevant information required
to satisfy paragraph 4.4 (Criteria for Successful Completion) of
GSFC-STD-1001, Criteria for Project Flight Critical Milestone Reviews.

The M-SRR Data Package shall discuss contractor system level
requirements, rationale, and flow-down plans to lower level
requirements.

The M-SRR Data Package shall show the allocation and traceability of
requirements to major subsystems.

The M-SRR Data Package shall address any identified Single Point
Failures.

The M-SRR Data Package shall show how the current concept meets all
government specified requirements including interface requirements.

The M-SRR Data Package shall discuss the preliminary operations concept
of the MOE.

The M-SRR package shall contain a matrix of the status of compliance
with GSFC-STD-1000. The M-SRR shall address compliance with
GSFC-STD-1000.

Results of Review---As a result of successful completion of the M-SRR,
the system and its operation are well enough understood to warrant
design and acquisition of the end items. Approved specifications for the
system, its segments, and preliminary specifications for the design of
appropriate functional elements may be released.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

RE-2 moe Preliminary Design Review (M-PDR) Data Package

3\. [Reference:]{.underline}

SOW 1.1

GSFC-STD-1001

4\. [Use:]{.underline}

To demonstrate that the MOE design meets the documented requirements.

5\. [Preparation Information:]{.underline}

The M-PDR Data Package shall address all relevant MOE information
required to satisfy paragraph 5.4 (Criteria for Successful Completion)
of GSFC-STD-1001, Criteria for Project Flight Critical Milestone
Reviews.

The M-PDR shall address MOE compliance with the MOE Requirements
Document.

The M-PDR data package shall include responses to action items from
previous reviews, including subsystem PDRs/Engineering Peer Reviews.

The M-PDR data package shall include changes since the last review.

The M-PDR data package shall address performance requirements and their
flow-down to the card or equivalent level.

The M-PDR data package shall address MOE performance budgets.

The M-PDR data package shall address error budget determination, if any.

The M-PDR data package shall contain a detailed report of Key Technical
Parameters down to a level below the one reported in the MPSR.

The M-PDR data package shall address interface requirements and
interface designs.

The M-PDR data package shall address life tests, if any.

The M-PDR data package shall address software requirements, design, and
development environment.

The M-PDR data package shall address MOE design verification, test flow
and test plans.

The M-PDR data package shall address the MOE operations concept.

The M-PDR data package shall address preliminary Failure Modes and
Effects Analysis (FMEA); Fault Tree Analysis; and reliability analysis
and results.

The M-PDR data package shall address redundancy and redundancy
management.

The M-PDR data package shall address single point failures.

The M-PDR Data Package shall address the list of long lead items/tasks,
identify those items that must be procured/developed prior to M-CDR
(including a list of those that were ordered/begun prior to M-PDR and
M-SRR), and provide a plan for procuring/developing these items and all
other items.

The M-PDR data package shall delineate the status of each document
required at PDR as to its acceptability for use as is.

The M-PDR Data Package shall present all MOE risks and address their
mitigation.

The M-PDR Data Package shall provide the status of all sub-contracts and
discuss the preliminary design status of critical assemblies and
sub-assemblies.

The M-PDR Data Package shall present a summary of testing and present
the available test results.

The M-PDR Data Package shall address the producability of the design
solution.

The M-PDR Data Package shall address mission assurance to be imposed
software assurance standards and processes imposed.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

RE-3 MOE Critical Design Review (M-CDR) Data Package

3\. [Reference:]{.underline}

SOW 1.1

GSFC-STD-1001

[\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_]{.underline}

4\. [Use:]{.underline}

To present the MOE design and operation, and to demonstrate that all
related documentation and processes are in place before significant
development begins, and to demonstrate that the design meets all
performance requirements.

[\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_]{.underline}

5\. [Preparation Information:]{.underline}

The M-CDR Data Package shall contain all relevant instrument information
required to satisfy paragraph 6.4 (Criteria for Successful Completion)
of GSFC-STD-1001, Criteria for Project Flight Critical Milestone
Reviews.

The M-CDR data package shall include responses to action items from
previous reviews, including M-PDR, subsystem CDRs/Peer Reviews.

The M-CDR data package shall include changes since the last review.

The M-CDR data package shall address compliance with the MOE
Requirements Document.

The M-CDR Data Package shall address the development/procurement status
of long lead items/tasks.

The M-CDR Data Package shall address development flow, and the status of
development, and integration plans..

The M-CDR Data Package shall address development procedures.

The M-CDR Data Package shall address software assurance product
checkpoints and evaluation criteria.

The M-CDR Data Package shall address standard applicable in-house
processes.

The M-CDR Data Package shall address special/unique processes.

The M-CDR Data Package shall address special facilities required for
development, integration, or testing.

The M-CDR Data Package shall address personnel resources (time phased).

The M-CDR Data Package shall address the delivery schedules for the MOE.

The M-CDR data package shall address detailed analysis from FMEA, fault
tree analysis, and reliability analysis.

The M-CDR Data Package shall address worst case analyses of performance.

The M-CDR data package shall contain a detailed report of Key Technical
Parameters down to a level below the one reported in the MPSR.

The M-CDR Data Package shall address integration and test plans

The M-CDR Data Package shall address materials and processes lists

The M-CDR Data Package shall provide a summary of deviations/waivers

The M-CDR Data Package shall address system safety/security hazards
analyses, including

(a) Hazards identification matrix

(b) Single point failure summaries

(c) Risk assessment rationale

The M-CDR Data Package shall delineate the status of each document as to
its acceptability for use as is.

The M-CDR package shall address the operations concept.

The M-CDR Data Package shall present any additional test results from
MOE or subsystem testing

The M-CDR Data Package shall address the status of all program risks and
their mitigation

The M-CDR Data Package shall address the status of all sub-contractor
activities and schedule for deliveries, as appropriate, and demonstrate
that designs are complete and have been adequately reviewed. Where
approval has been given by the Government Contracting Officer for
ordering of long lead items, the Contractor shall address the
design/delivery status of these items.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

RE-5 moe Pre-ship Review (M-PSR) Data Package

3\. [Reference:]{.underline}

SOW 1.1

4\. [Use:]{.underline}

To evaluate MOE performance during qualification or acceptance testing,
and evaluate readiness to deliver and install in the MOC and to
integrate to the LDCM Ground System. This review in intended to serve as
the Contractor's verification of MOE requirements (as defined in the
MOE-RD) prior to delivery to the MOC for Ground System Integration.

5\. [Preparation Information:]{.underline}

This data package shall address, as a minimum:

The M-PSR Data Package shall address responses to action items generated
at prior reviews

The M-PSR Data Package shall address the solutions to all problems
encountered during the test and validation program and the solution
rationale.

The M-PSR Data Package shall address any rework/replacement of software
or hardware, regression testing, and test plan changes.

The M-PSR Data Package shall address compliance with the MOE
verification plan and verification matrix (CDRL SE-6).

The M-PSR Data Package shall address measured test margins versus
requirements.

The M-PSR Data Package shall address any data that has been trended to
identify compliance with specification, indicating a change or drift to
the trend.

The M-PSR Data Package shall address total failure-free operating time
of the MOE and each sub-system.

The M-PSR Data Package shall address "could-not-duplicate failures"
along with assessment of the problem and the residual risk that may be
inherent in the item

The M-PSR Data Package shall address project assessment of any residual
risk

The M-PSR Data Package shall provide an update from M-CDR on shipping
containers, monitoring/transportation/control plans

The M-PSR Data Package shall address post delivery plans

The M-PSR Data Package shall address spacecraft and ground system
integration plan.

The M-PSR shall address the plans for storage of the MOE, if required.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

RE-6 input to ground system and mission reviews

3\. [Reference:]{.underline}

SOW 1.1

GSFC-STD-1001

4\. [Use:]{.underline}

To evaluate the requirements, requirements flow-down, and the
operational concepts and to validate the realism of the functional and
performance requirements and their congruence with the system
configuration selected to conduct the mission.

5\. [Preparation Information:]{.underline}

The Inputs to the Ground System Reviews (GS-PDR and GS-CDR) and selected
Mission-level Reviews (PDR, CDR, SIR), shall be a subset of the
corresponding MOE reviews, with appropriate updates.

The inputs to the following Mission Level Reviews shall be separate data
packages addressing the specific review objectives.

A. Mission Operations Review (MOR)

The MOR Data Package shall contain the relevant MOE information required
to satisfy paragraph 7.4 (Criteria for Successful Completion) of
GSFC-STD-1001, Criteria for Project Flight Critical Milestone Reviews.

The Mission Operations Review (MOR) data package shall address the
following items at a minimum:

> a\. Closure of action items from previous reviews (e.g.,
> Project-unique ground system, mission, or MOE reviews)
>
> b\. MOE Overview and Operations Concept
>
> c\. Any remaining MOE-specific pre-launch Test Plans including: MOC
> Compatibility Tests, Data Flow and End-to-End Tests, Simulations and
> exercises, Launch Site and Pad Tests
>
> d\. Launch and early orbit activities
>
> e\. In-orbit Checkout activities
>
> f\. Project Database and Procedure Development
>
> g\. MOE Requirements, Development, and Delivery/Release Status
>
> h\. Mission Readiness Testing
>
> j\. Issues and Concerns

b\. Flight Operations Review (FOR)

The FOR Data Package shall contain all relevant MOE information required
to satisfy paragraph 9.4 (Criteria for Successful Completion) of
GSFC-STD-1001, Criteria for Project Flight Critical Milestone Reviews.

The Flight Operations Review Data Package should include all of the
items specified for an MOR, updated to the present stage of progress,
plus the following additional items:

> a\. Closure of actions from the MOR
>
> b\. New requirements and changes in plans
>
> c\. Test result summaries including contractor's assessment of the
> criticality of open problems
>
> d\. Work remaining including tests, simulations, and closure of
> problems
>
> e\. Personnel location for launch and early orbit and in-orbit
> checkout
>
> f\. Contingency procedures, development and verification/validation
> status

g\. Safety and mission success

C. Operational Readiness Review (ORR)

The Operational Readiness Review shall address the following items:

1.  Status of completion of all validation testing.

```{=html}
<!-- -->
```
1.  Resolution of test failures and anomalies from validation testing
    and incorporation of the results into all supporting and enabling
    operational products.

2.  Status of all operational supporting and enabling products
    (facilities, equipment, documents, updated databases, etc) that are
    necessary for the nominal and contingency operations. Status of
    delivery/installation of these products at the site(s) necessary to
    support operations.

3.  Status of training to the users and operators on the correct
    operational procedures for the system.

4.  Status of operational contingency planning and all training of
    personnel.

The Contractor's portion of the Operational Readiness Review shall
address the above items that are in scope of the Contractor's effort.

Operations Readiness Review Success Criteria:

1.  The system, including any enabling products, is determined to be
    ready to be placed in an operational status.

2.  All applicable lessons learned for organizational improvement and
    systems operations have been captured.

3.  All waivers and anomalies have been closed.

4.  Systems hardware, software, personnel, and procedures are in place
    to support operations.

D. On-orbit Acceptance Review (OAR)

The On-Orbit Acceptance Review shall provide the following information:

1.  Data review (in the form of data plots/tables) of the results of
    operational performance identified during Launch and Early Orbit
    (L&EO) and observatory checkout.

2.  Data review (in the form of data plots/tables) for all anomalies and
    unexpected behavior encountered by the contractor during L&EO and
    observatory checkout, including:

    a.  Data showing the anomalous or unexpected behavior

    b.  Descriptions of any workarounds and/or fixes

    c.  Data illustrating response to the workarounds and/or fixes

3.  Current status of all anomalies, ground system problems, and
    database problems encountered by the contractor during L&EO and
    commissioning

4.  Measured on-orbit operations performance of the LDCM MOE versus the
    requirements of the Mission Operations Element Requirements
    Document.

**DESCRIPTION OF REQUIRED DATA**

[CDRL No.:]{.underline} 2. [Title:]{.underline}

RE-7 Engineering Peer Review Data Packages

3\. [Reference:]{.underline}

SOW 1.1

NPR 7150.2, 5.3.3.1

4\. [Use:]{.underline}

Engineering Peer Reviews (EPRs) focus on the design and implementation
details at levels that system-level reviews cannot address. They provide
a resource for Design Teams to identify potential engineering design and
implementation flaws, and increase the probability of success. Applying
the EPR process early and throughout the product life cycle affords the
maximum advantage in terms of resource efficiency as well as design
confirmation and ultimate mission success.  Peer review documentation
represents knowledge that may prove invaluable later.

5\. [Preparation Information:]{.underline}

Engineering Peer Review documentation shall be in contractor format and
include content as defined in NPR 7150.2, Section 5.3.3.1.

**SYSTEMS ENGINEERING DRDS**

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-1 ENGINEERING CHANGE REQUESTS, DEVIATIONS, WAIVERS

3\. [Reference:]{.underline}

SOW 1.2

4\. [Use:]{.underline}

To facilitate the orderly processing of change requests to appropriate
level of approval authority for disposition.

5\. [Preparation Information:]{.underline}

Consistent with the Contractor's Configuration Management Plan (CMP),
the contractor shall prepare and submit a Class I Configuration Change
Request (CCR). In addition to the change description, the CCR shall
contain sufficient information in the form of attachments, drawings,
test results, etc., to allow the Government to evaluate the total impact
of the proposed change. The Government Contracting Officer may direct
the contractor to prepare CCRs under the "Changes" clause of the
contract. The contractor shall also submit Class II changes for
Government review.

For the purposes of this DRD, a Class I CCR is a change that:

a\. Affects any Government Contract specification or interface
requirement.

b\. Affects schedules of end-item deliverables to the Government.

c\. Impacts Government Furnished Equipment.

d\. Affects configuration to the extent that changes would be required
to prior deliverables in order to maintain specified performance.

e\. Causes a Single Point Failure.

A change may be classified Class II when it does not fall within the
definition of a Class I change as given above. Examples of Class II
changes are:

a\. A change in documentation only (for example, correction of errors,
addition or clarifying notes or views).

b\. A minor change in hardware (for example, substitution with an
approved alternative material) which does not affect any item listed
under Class I changes.

c\. Drawing changes that do not affect a baseline, interface, etc.

Class II changes normally do not require Government CCB approval unless
they are written against Government CM-controlled documents.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-2 Contractor - Generated Internal Technical INFORMATION

3\. [Reference:]{.underline}

-   SOW 1.2

4\. [Use:]{.underline}

To document technical information and decisions related to the LDCM
program.

5\. [Preparation Information:]{.underline}

These memoranda shall preferably be in electronic format. Hand-drawn
sketches may be used if they preserve timeliness.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-6 System Performance Verification Plan and Matrix

3\. [Reference:]{.underline}

SOW 2.3

4\. [Use:]{.underline}

Provides the overall approach for accomplishing the verification
program. Defines the specific tests, analyses, hardware and software
architecture and/or models, etc. that will demonstrate that the MOE
complies with the mission requirements.

5\. [Preparation Information:]{.underline}

The System Performance Verification Plan (SPVP) shall:

A. Be separated into sections such that it is clear which requirements
are verified at the specific MOE sub-system level, at the integrated MOE
level, at the integrated Ground System level, and at the mission level.

B. Provide an overview of the entire MOE verification program.

C. Flow performance requirements to all levels of development and
describe the verification method for these tests.

The SPVP describes the approach (test, analysis, etc.) that will be
utilized to verify each Space Segment Requirements Document and Mission
Operations Element Requirements Document requirement. If verification
relies on measurements, tests, or analyses at lower (or other) levels of
assembly, this dependence shall be described.

This Plan includes level of development, configuration of item,
objectives, facilities, , safety considerations, , test phases and
profiles, appropriate functional operations, personnel responsibilities,
and requirements for procedures and reports. For each analysis activity,
include objectives, a description of the mathematical model, assumptions
on which the model will be based, required output, criteria for
assessing the acceptability of the results, interaction with related
test activity, and requirements for reports.

The Final SPVP due 15 days prior to M-PR shall incorporate all review
comments.

[System Performance Verification Matrix]{.underline}

The System Performance Verification Matrix (SPVM) shall summarize the
flow-down of system specification, Mission Assurance, and validation
requirements verification. The SPVM shall stipulate how each requirement
will be verified and summarizes current status of
compliance/non-compliance with requirements. The SPVM shall list a
summary description of each requirement and a summary of the
measured/analyzed/demonstrated performance of the system against each
requirement. It shall show each Mission Operations Element Requirements
Document, MAR, and Validation Plan requirement reference source (to the
specific paragraph or line item), the method of compliance, applicable
procedure references, report reference numbers, etc. for each
requirement set from the Mission Operations Element Requirements
Document. It shall show the flow-down of requirements verification
through the sub-system level.

The SPVM shall trace requirements backwards to the next level above,
i.e., a level 4 requirement shall be traced back to its level 3 parent,
etc

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-7 Verification Reports

3\. [Reference:]{.underline}

SOW 2.3

4\. [Use:]{.underline}

Provide summary of each integration and test result, conformance,
non-conformance, and trend data. A Verification Report for all
verification types indicated in the System Performance Verification Plan
(Test, Analysis, Inspection, Demonstration) shall be generated.

5\. [Preparation Information:]{.underline}

Verification reports are required for all integration and test
activities commencing at sub-systems level testing through Ground
Readiness Tests. Contents of these reports shall include, as a minimum:

A.  Summary of the test results of each activity and an assessment of
    the quality and acceptability of the item tested, including
    pass/fail criteria and performance against the criteria.

B.  Summary of non-conformances occurring during the test and the
    resolution and corrective actions taken

C.  Trends in the performance of critical components

D.  Actual sequence of these operations including dates and times

E.  Across-reference to the test procedure number(s) or analysis used in
    the verification.

Contractor format may be used for these reports as long as the required
information is included.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-8 configuration item identification list

3\. [Reference:]{.underline}

SOW 1.2

4\. [Use:]{.underline}

To establish a structure for controlling the configuration of the LDCM
MOE by identifying all Configuration Items (CIs) and Computer Software
Configuration Items (CSCIs) used on the program and correlating those
CIs/CSCIs to their Specification and test requirements documents.

5\. [Preparation Information:]{.underline}

The Configuration Item Identification List (CIIL) identifies all CIs and
CSCIs. This CIIL shall conform to the following:

> a\. The CIIL shall be organized and broken down as follows:

1\) All system level CIs and CSCIs.

2\) All subsystem level CIs and all CIs/CSCIs within each subsystem.

> b\. For each CI listed, the following information shall be provided:

1\) Assigned CI Number.

2\) The CI top drawing number.

3\) The CI nomenclature.

4\) The applicable specification number. For those CIs not governed by a
specification, the word "NONE" shall be entered in this column.

5\) Acceptance test procedure number and, if qualification tested, the
qualification test procedure number. If the CI is neither acceptance nor
qualification tested, the functional test procedure number should be
entered in this column.

> c\. For each CSCI listed the following information shall be provided:

1\) Assigned CSCI Number.

2\) The CSCI nomenclature.

3\) The applicable specification number. For those CSCIs not governed by
a specification, the word "NONE" shall be entered in this column.

4\) Acceptance test procedure number and, if qualification tested, the
qualification test procedure number. If the CSCI is neither acceptance
nor qualification tested, the functional test procedure number should be
entered in this column.

d\. This list shall be prepared in the contractor's format.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-13 Specification tree

3\. [Reference:]{.underline}

SOW 2.3

4\. [Use:]{.underline}

To provide a reference for contractor's specification breakout.

5\. [Preparation Information:]{.underline}

The specification tree shall document the breakout of the contractor's
specifications starting at the top-level LDCM Mission Operations Element
Design Specification, showing all lower-level specifications to the
sub-assembly (box/board) level, and indicating the relationships and
interfaces between the documents.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-20 trades and analysEs

3\. [Reference:]{.underline}

SOW 2.0

4\. [Use:]{.underline}

To provide a basis or rationale for the MOE design, integration, and
testing.

5\. [Preparation Information:]{.underline}

The Contractor shall document all necessary system studies, analyses,
trades, and risk assessments necessary to develop the MOE design, to
interface the MOE to the LDCM Space Segment and Ground System, and to
support MOE and Ground System integration and testing. Studies,
analyses, trades, and assessments can be in Contractor format shall
include at a minimum any studies, analyses, trades, or assessments
performed to develop the MOE software and hardware component/sub-system
design or tool selection.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

SE-23 Acceptance Data Package

3\. [Reference:]{.underline}

SOW [6.1.2]{.underline}

4\. [Use:]{.underline}

To ensure that the deliverable contract end-items are in accordance with
contract requirements prior to Government acceptance.

5\. [Preparation Information:]{.underline}

This acceptance data package, as a minimum, shall be comprised of the
following:

A.  Contract End Item Specification

B.  As-built configuration list

C.  Software components lists, including third-party software

D.  Hardware platforms and components lists (i.e. workstations, PC's,
    etc.)

E.  Test Log Book (including total operating time and cycle records)

F.  Open item lists (including reasons for being open)

G.  Safety compliance data package

H.  Subsystem tests results

I.  On Orbit Operations Performance Report

J.  Anomaly reports and disposition information

Item A above, the Contract End Item Specification, establishes the
architecture, configuration, function, and performance of the LDCM MOE,
and shall address design compliance with and traceability to the LDCM
Mission Operations Element Requirements Document, and other applicable
requirements documents.

[]{.mark}

Item M above, the On Operations Performance Report, shall contain the
following:

A.  Launch and early orbit operations results

B.  Lessons learned

A copy of this package shall accompany each end item.

**MISSION OPERATIONS ELEMENT DRDS**

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

MO-2 Mission Operations ELEMENT Interface Control documents

3\. [Reference:]{.underline}

SOW 2.2

SOW 4.1.11

4\. [Use:]{.underline}

To establish interface requirements, definition and control between the
LDCM Mission Operations Element and LDCM ground assets (including ICs).

5\. [Preparation Information:]{.underline}

This document(s) shall provide detailed information regarding the
interface of the LDCM Mission Operations Element to external interfaces.
The Government will provide input, and will provide requirements for,
the interfaces to Government ground systems (including ICs). This
document(s) shall address the following interfaces:

A.  Mission Operations Element (MOE) / LDCM Observatory

B.  MOE / LDCM Observatory Simulator (OBSSIM)

C.  MOE / LDCM Ground Network Element (LGNE)

D.  MOE / NASA Ground Network (NGN)

E.  MOE / NASA Space Network (SN)

F.  MOE / International Cooperators (ICs)

G.  MOE / Observatory I&T Facility and Launch Site

H.  MOE / Mission Operations Center (MOC) facility

I.  MOE / Flight Dynamics Facility (FDF)

J.  MOE / Flight Software Vendor (FSV)

K.  MOE / Collection Activity Planning Element (CAPE)

L.  MOE / Data Processing and Archive Segment (DPAS)

M.  bMOE / MOE

N.  LDCM Project Reference Data System

The Interface Control Documents shall contain at a minimum:

a.  Type of interface (API, internet, phone, physical, etc.)

b.  Data and media formats

c.  Data rates

d.  Duty cycles

e.  Protocols

f.  Physical interfaces

g.  Error conditions

h.  Timing

i.  Security

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

MO-3 Mission Operations Element system Lower-Level REQUIREMENTS document

3\. [Reference:]{.underline}

SOW 2.1

4\. [Use:]{.underline}

Stipulates functionality required of each of the Mission Operations
Element Subsystems derived from the Mission Operations Element
Requirements Document (MOERD) (NASA GSFC 427-09-03) and other
Government-provided requirements reference documentation.

5\. [Preparation Information:]{.underline}

A separate subsystem requirements document shall be written for each of
the MOE subsystems.

The Mission Operations Element System Lower-Level Requirements Documents
shall at a minimum contain the following items:

a.  Mission Operations Element Level 5 and MOE Subsystem level 6
    requirements (the MOERD is a Level 4 requirements document)

b.  All requirements relating to the MOE external interfaces

c.  All requirements relating to the MOE internal interfaces

d.  All requirements necessary to define the functionality required of
    each Mission Operations Element sub-system

e.  All requirements relating to the performance of the Mission
    Operations Element

f.  All requirements related to fault detection and handling within the
    Mission Operations Element

g.  All requirements related to check-pointing and logging of
    operational data

h.  All requirements related to persistent storage of operations data

i.  All requirements related to modes of operation of the Mission
    Operations Element

j.  All requirements related to MOE System displays

k.  All requirements related to allowable data types and data
    conversions

l.  All requirements related to Mission Operations Element alerts and
    warnings

m.  All requirements related to access control requirements

n.  Provide traceability to parent requirements documentation.

The Mission Operations Element System Lower-Level Requirements Documents
shall provide meta data for each requirement including the following:

a.  Requirement number

b.  Subsystem

c.  Test method

d.  Author

e.  Date written

f.  Authorization

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

MO-4 MOE TEST PLANs

3\. [Reference:]{.underline}

SOW 4.2

4\. [Use:]{.underline}

The MOE Subsystem Test Plans describe integration activities planned for
the contractor designed MOE Subsystems. A separate integration test plan
will be written for each of the contractor's subsystems using the
preparation information listed below.

5\. Preparation Information:

[]{.mark}

The MOE Test Plans shall describe in detail the integration test
activities associated with each MOE Subsystem along with expected
outcomes and results.

Each Test Plan shall contain the following items:

a.  List the executables under test, describes the test environment in
    detail (so that tests may be duplicated) and the specific version of
    the executables under test

b.  List and describe the utilities and tools needed or recommended to
    setup the environment, load the database, convert output data into
    readable reports, generate test data, etc

c.  List the test cases to be run on each executable in the subsystem

d.  Indicate the input data to be used for each test case along with the
    location of the data, whether in a flat file or database table

e.  Indicate the name and location of output files used to verify the
    outcome of each test case

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

MO-5 Mission Operations element Test Procedures

3\. [Reference:]{.underline}

SOW 4.2

4\. [Use:]{.underline}

The Mission Operations Element Test Procedures Documents are used too
define the software test procedures followed for each test case in the
test plan. A separate test procedures document is written for each test
plan.

5\. [Preparation Information:]{.underline}

The MOE Operations Test Procedures Document shall be prepared to
implement software testing as required in accordance with the MAR.

The MOE Operations Test Procedures Document shall provide the following
items:

a.  A description of the overall test plan and expected results

b.  A description of the environment setup

c.  A description of each test case along with the purpose of the test
    case and expected results

d.  The full set of steps and actions needed to execute each test case

e.  Procedures for environment setup, test execution, and data capture

f.  Procedures that define the objectives, test requirements, test
    limits, pass/fail criteria, environment, and test recording
    requirements

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

MO-6 Mission Operations Element Test Reports

3\. [Reference:]{.underline}

SOW 4.2

4\. [Use:]{.underline}

The Mission Operations Element Test Reports provide a summary of the
findings from each test. A separate Mission Operations Element Test
Report shall be written for each Mission Operations Element Test.

5\. [Preparation Information:]{.underline}

The Mission Operations Element Test Reports shall be developed for each
test described in the MOE Test Plan and shall include the following, as
a minimum:

A.  Version number of software tested

B.  Identity and number of planned tests that have been completed

C.  Conformance of test results to expected results

D.  Number, type, description, and criticality of discrepancies and
    defects

E.  Identification of software areas tested

F.  Analysis of any performance requirements that the tested software
    could affect

G.  Test result summary

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

MO-7 moe installation, setup, and configuration procedures

3\. [Reference:]{.underline}

SOW 4.3

SOW 5.1.1

4\. [Use]{.underline}

To define processes and steps for the installation, setup, and
configuration of the MOE hardware and software. For use in training
Government representatives and for use when performing installations and
updates of MOE hardware and software.

5\. [Preparation Information]{.underline}

The Contractor shall document the detailed step-by-step procedures for
installing MOE hardware and software for each of the facilities that
will host a MOE or bMOE system. The procedures shall include

A.  Procedures for installing and configuring each MOE hardware
    component

B.  Procedures for installing and configuring MOE software and
    sub-system software and software patches.

C.  Any facility-specific procedures

D.  MOE COTS Products and Licenses

E.  Unique MOE logistics, hardware and software maintenance and
    sustaining engineering

F.  Provide recommended MOE software and hardware maintenance plans.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

MO-9 MOE SOFTWARE DEVELOPMENT MANAGEMENT PLAN

3\. [Reference:]{.underline}

SOW 1.1

SOW 3.0

4\. [Use:]{.underline}

Defines contractor activities required to develop and manage all
software

5\. Preparation Information:

The Software Management and Development Plan shall describe processes
and activities used in the development and testing of the various types
of software being acquired, acknowledging the fact that not all software
has the same criticality level or process requirements (reference the
classification requirements in SOW sections 4.4.1.1.3 and 4.4.1.1.4.

Topics to be included in the Software Development and Management Plan
are:

A.  Purpose and Description;

B.  Resources, Budgets, Schedules, and Organization; A description of
    how the software personnel structure is integrated into the overall
    LDCM development organization.

C.  Acquisition Activities;

D.  Development methodologies and Activities;

E.  Sustaining Engineering and Operations Activities;

F.  Software Assurance Plan

G.  System safety;

H.  Software Risk Management plan;

I.  Delivery and Operational Transition

J.  V&V and IV&V;

K.  COTS, GOTS, and MOTS software.

L.  Subcontractor management and monitoring

M.  The plan and approach for training personnel (Contractor staff,
    external maintainers, Flight Operation Team) in the use of all
    delivered software and supporting facilities

Additionally, the Contractor shall evaluate all MOE software using
software metrics. The metrics collected, trended, and presented monthly.
Metrics shall include at a minimum:

A.  Number of software requirements and their change status

B.  Design/Code complexity index at CSU, CSC, and CSCI levels

C.  Source code production rate estimates versus actuals

D.  Number of Software Change Requests/Problem Reports and their status

E.  Resource margins for Utilization of memory, CPU, I/O Bandwidth and
    Bus traffic

F.  Effort data (staffing profile) estimates versus actuals

Include an alphabetized list of definitions for abbreviations and
acronyms used in this document. Include an alphabetized list of
definitions for special terms used in the document, i.e., terms used in
a sense that differs from or is more specific than the common usage for
such terms.

Material that is too detailed or sensitive to be placed in the main body
of text may be placed in an appendix or included as a reference. Include
the appropriate reference in the main body of the text. Appendices may
be bound separately, but are considered to be part of the document and
shall be placed under configuration control as such.

[]{.mark}

a.  **DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

MO-10 MOE SOFTWARE VERSION DESCRIPTION DOCUMENT

3\. [Reference:]{.underline}

SOW 4.3

4\. [Use:]{.underline}

The Software Version Description identifies and describes a software
version consisting of one or more CSCIs (including any open source
software). The description is used to release, track, and control
software versions.

5\. [Preparation Information:]{.underline}

The [Software Version Description]{.underline} shall identify and
provide:

a.  Listing of all resolved and unresolved DRs

b.  Listing of all COTS dependencies

c.  New Features and Problem Resolutions

d.  Full identification of the system and software (i.e., numbers,
    titles, abbreviations, version numbers, and release numbers).

e.  Executable software (i.e., batch files, command files, data files,
    or other software needed to install the software on its target
    computer).

f.  Software life cycle data that defines the software product.

g.  Archive and release data.

h.  Instructions for building the executable software including, for
    example, the instructions and data for compiling and linking and the
    procedures used for software recovery, software regeneration,
    testing, or modification.

i.  Data integrity checks for the executable, object code, and source
    code.

j.  Software product files (any files needed to install, build, operate,
    and maintain the software).

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

MO-11 Hardware inventory

3\. [Reference:]{.underline}

SOW 4.3

4\. [Use:]{.underline}

To provide an inventory of the MOE hardware to facilitate NASA property
accountability.

5\. [Preparation Information:]{.underline}

The hardware inventory of information system components shall contain
any information determined to be necessary to achieve effective property
accountability including the following items:

-   Manufacturer

-   Model number

-   Serial number

-   NASA property number

-   Location and "as of" date

-   System/component owner

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

MO-12 MOE Design Specification and Description

3\. [Reference:]{.underline}

SOW 4.1

4\. [Use]{.underline}:

To ensure that the MOE design requirements flow correctly from the
MOERD, and to present the MOE architecture and design.

5\. [Preparation Information]{.underline}

The MOE Design Specification and Description shall delineate the
architecture and design of the MOE. It shall establish the top-level
design and interface specification(s) placed on the MOE that flows from
the MOERD.

The MOE Design Specification and Description shall contain the
following, at a minimum:

-   Hardware architecture

-   Software architecture

-   Specifications

-   HCI display images and descriptions

-   Interface designs

-   Data flows

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

MO-13 Flight operations team Training Plan

3\. [Reference:]{.underline}

SOW 5.2.1

4\. [Use:]{.underline}

The Flight Operations Team Training Plan is used to train the Flight
Operations Team in the operation and functionality of the MOE, use of
the MOE System software and hardware and simulation activities. The
Training Plan includes the use of Launch Rehearsals for FOT training.

5\. [Preparation Information:]{.underline}

> The Flight Operations Team Training Plan shall describe course
> methodology and curriculum and shall include training in the following
> items:

a.  MOE Operations concepts

b.  Flight Operations Team positions and responsibilities for MOE
    operations

c.  All modes of operation and functionality of the MOE

d.  Operation and functionality of the MOE System

e.  Operation and functionality of each MOE Subsystem

f.  Operation and functionality of the MOE System hardware

g.  Interfaces between the Ground System Elements and the MOE System

h.  Interfaces between the Observatory Simulator and the MOE System

i.  MOE System Anomaly scenarios and procedures

j.  Lights Out Automation functionality

k.  Required meetings, status reports, etc.

In addition, the Training Plan shall include exercises and Launch
Rehearsals as part of the training curriculum.

[]{.mark}

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

MO-14 MOE Facility Integration Plan

3\. [Reference:]{.underline}

SOW 5.1.1

4\. [Use]{.underline}:

The MOE Facility Integration Plan details the physical requirements for
the MOC facilities to accommodate the MOE and bMOC, and also provides a
plan detailing the installation process and schedule. These requirements
will be incorporated into the Government LDCM MOC Facility Plan. The
LDCM MOC Facility Plan is a Government document that describes the
physical characteristics of the GSFC MOC, EROS MOC and TBD-location MOC
and includes internal and external physical interfaces, access and
security, and communications.

5\. [Preparation Information]{.underline}

The enumeration of the facility physical requirements for installation
of the MOE at the GSFC MOC and for installation of the Back-up MOE at
the EROS MOC shall include as a minimum:

-   Square footage requirements

-   AC Power requirements including connector types and grounding plan.

-   Cooling requirements

-   Data services (network, etc) requirements including connector types

-   Cable routing requirements

-   Number of racks and operator consoles.

-   Maximum weight per rack

-   Type of floor required

-   Clearance requirements

The MOE Facility Integration Plan shall include the MOE installation
process and a project plan (GANTT Chart) detailing the sequence of major
work elements required to install the equipment in the Government
provided facility.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

MO-15 MOE USER'S MANUAL

3\. [Reference:]{.underline}

SOW 2.3

SOW 4.3

4\. [Use]{.underline}:

To provide guidance and instruction on the use of the MOE for users and
operators of the MOE.

5\. [PREPARATION INFORMATION]{.underline}

The MOE User's Manual shall include at a minimum:

1.  A system overview of the MOE including architecture, hardware and
    software descriptions, configuration, and modes of operation

    a.  MOE System Overview

    b.  High Level Architecture and Functional Flow Diagrams

    c.  Overview of Internal and External Interfaces

    d.  MOE operational environment

    e.  MOE Hardware and Network

    f.  MOE Modes of Operation

2.  Overview of User Interface

    a.  Bringing up and down the MOE System and each MOE functional
        element, including cold and warm starts if applicable

    b.  Operation of hardware

    c.  Logging on/off

        i.  Description of user access levels

    d.  Using the startup GUI

    e.  Basic display management

    f.  Basic system directives

    g.  Introduction to the scripting language

    h.  Operation of software

    i.  Remote access

3.  System Operations

    a.  Front End Configuration and Management

    b.  Telemetry and Display Operations

    c.  Command Operations

        i.  Overview of Command Control

        ii. Overview of Command Load Generation

    d.  Planning and Scheduling Processes\
        including discussions of external scheduling interfaces and LTAP

    e.  Mission Monitor & Analysis Operations

    f.  Flight Dynamics Processes and Products

    g.  Flight Software Maintenance Operations

    h.  Overview of the Central Repository, Archiving and Restoration

    i.  Anomaly Identification, Notification and Resolution Capabilities

    j.  Lights Out Automation Capabilities

    k.  Overview of Simulation Operations

    l.  Functionality, Software and Hardware in the Primary and Backup
        MOEs

        i.  MOE functional data transfer and interface to the BMOC MOE
            System suite

    m.  Redundancy, Redundancy and Fail Over Capabilities

        i.  Recovery methods for each MOE Subsystem in cases of
            irrevocable errors or faults

    n.  MOE Interface Management

        i.  Between the MOE Subsystems and the LDCM Ground System

        ii. Between the MOE Subsystems and all external interfaces

4.  Scripting Language Guide (may be provided in Contractor format)

5.  Detailed MOE Database Descriptions (may be provided in Contractor
    format)

    a.  Database structures and locations

    b.  Detailed database definitions

    c.  Allowed operations

    d.  Database query and reports

    e.  Database modification

    f.  Utilization of the PRD

6.  Event, Logging And Report Operations

7.  System administration instructions/guides

8.  List of MOE system directives (may be provided in Contractor format)

9.  List of all alerts or notifications produced by each MOE Subsystem
    along with their meanings (may be provided in Contractor format)

10. List of all system parameter values stored and processed by the MOE
    System (may be provided in Contractor format)

11. List of all operator roles supported by each MOE Subsystem and the
    privileges associated with each role

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

MO-16 INPUTS TO LDCM PROJECT REFERENCE DATABASE

3\. [Reference:]{.underline}

SOW 4.1.1

4\. [Use]{.underline}:

To provide a formal delivery of system (application) database elements
for inclusion in the Project Reference Data (PRD) and subsequent
configuration management.

5\. [PREPARATION INFORMATION]{.underline}

The inputs to the LDCM PRD consist of configurable application databases
prepared and maintained by the application vendor over the course of
system development and maintenance (i.e. display header formats,
application environment files, etc).

Inputs are packaged in their native format consistent with the
government-provided Data Format Control Document and delivered via CD or
other government-approved electronic means with a Version Description
Document defining the contents of the package.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

MO-17 MYK-15 Documentation

3\. [Reference:]{.underline}

SOW 4.1.2.2

4\. [Use]{.underline}:

To provide design descriptions, manuals, and other documentation related
to the MYK-15 device for performing encryption and authentication.

5\. [PREPARATION INFORMATION]{.underline}

The Contractor shall provide all MYK-15 documentation received from the
supplier. The documentation shall be in the Contractor's or supplier's
format.

**DESCRIPTION OF REQUIRED DATA**

1\. [CDRL No.:]{.underline} 2. [Title:]{.underline}

MO-18 LDCM KEY MANAGEMENT PLAN INPUTS

3\. [Reference:]{.underline}

SOW 4.1.2.2

4\. [Use]{.underline}:

The Key Management Plan (KMP) describes the use and control of all key
management products and services used by a cryptographic application
(cryptographic engine, End Cryptographic Unit (ECU), or system)
throughout its lifetime. The KMP also documents the capabilities that
the cryptographic application requires from the current and planned Key
Management Infrastructure (KMI). This ensures that any lifecycle key
management services are supportable by and available from the KMI.

5\. [PREPARATION INFORMATION]{.underline}

The Government will lead the development of the LDCM Key Management Plan
(KMP). The KMP will follow an NSA-approved format. The Contractor shall
review and provide inputs regarding the Contractor's specific roles and
responsibilities related to COMSEC and key management.