453-PMP-SWSI

Mission Services Program

SPACE NETWORK (SN)

WEB SERVICES INTERFACE (SWSI)

PRODUCT MANAGEMENT PLAN

Original

February 2002

![](media/image1.wmf)![](media/image2.emf)

**Space Network (SN) Web Services Interface (SWSI) Product Management
Plan**

**Original**

**February 2002**

![](media/image3.jpeg){width="4.46875in" height="2.84375in"}**Prepared
By:**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Thomas E. Sardella Date

SWSI Product Design Lead

**Approved By:**

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Roger N. Clason Date

Technology & Upgrades Project Manager

**Goddard Space Flight Center**

Greenbelt, Maryland

# Preface {#preface .unnumbered}

This Product Management Plan establishes the approach for managing the
implementation of the Space Network (SN) Web Services Interface (SWSI),
and constitutes an agreement between the SWSI Product Design Lead and
the GSFC Data Services Upgrades Manager.

This document is under the configuration management of the Space Network
Project. Proposed changes to this document shall be submitted to the
Space Network Project along with supportive material justifying the
proposed change. Changes to this document shall be made by Document
Change Notice (DCN) or by complete revision.

Direct all comments, questions, or suggestions regarding this document
to:

SWSI Product Design Lead

Code 453

Goddard Space Flight Center

Greenbelt, Maryland 20771

# Change Information Page {#change-information-page .unnumbered}

  --------------------- -------------- ---------- ---------------- ----------------
  List of Effective                                                
  Pages                                                            

  Page Number                          Issue                       

  Title                                Original                    
                                       Issue                       

  Signature Page                       Original                    
                                       Issue                       

  iii/iv (blank)                       Original                    
                                       Issue                       

  v/vi (blank)                         Original                    
                                       Issue                       

  vii/viii (blank)                     Original                    
                                       Issue                       

  ix through x                         Original                    
                                       Issue                       

  1-1 through 1-3                      Original                    
                                       Issue                       

  2-1 through 2-5/2-6                  Original                    
  (blank)                              Issue                       

  3-1 through 3-3                      Original                    
                                       Issue                       

  4-1/4-2 (blank)                      Original                    
                                       Issue                       

  5-1/5-2 (blank)                      Original                    
                                       Issue                       

  AB-2 through AB-3                    Original                    
                                       Issue                       

  Document History                                                 

  Document Number       Status/Issue              Publication Date CCR Number

  453-PMP-SWSI          Original Issue            February 2002    450/136

                                                                   

                                                                   

                                                                   

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

# DCN Control Sheet  {#dcn-control-sheet .unnumbered}

  -------------- -------------- -------------- --------------- --------------
  **DCN\         **Date/Time\   **Month/\      **Section(s)\   **Initials**
  Number**       Group**        Year**         Affected**      

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

                                                               

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

Contents

Preface

Change Information Page

DCN Control Sheet

Section 1. Introduction

1.1 Purpose [1-1](#__RefHeading___Toc485796770)

1.1.1 Background [1-1](#__RefHeading___Toc485796771)

1.1.2 Scope [1-2](#__RefHeading___Toc485796772)

1.1.3 Applicable Documents [1-2](#__RefHeading___Toc485796773)

1.2 Objectives [1-3](#__RefHeading___Toc485796774)

1.3 Overall Approach [1-3](#__RefHeading___Toc485796774)

1.4 Plan Maintenance and Control [1-3](#refheading___toc485796775)

1.5 Implementation Authority [1-3](#__RefHeading___Toc485796776)

Section 2. Management

2.1 General 2-[1](#__RefHeading___Toc485796778)

2.2 NASA Responsibilities 2-[1](#__RefHeading___Toc485796779)

2.2.1 Organization 2-[1](#__RefHeading___Toc485796780)

2.2.2 Definitions 2-[3](#__RefHeading___Toc485796781)

2.3 Contractor Responsibilities 2-[4](#__RefHeading___Toc485796782)

2.4 Configuration Management 2-[4](#__RefHeading___Toc485796783)

2.4.1 Configuration Control Board 2-[4](#__RefHeading___Toc485796784)

2.4.2 Configuration Management Plan and Quality Assurance
2-[5](#__RefHeading___Toc485796785)

2.5 Data Management 2-[5](#__RefHeading___Toc485796786)

2.6 Schedule 2-[5](#__RefHeading___Toc485796787)

2.7 Resources 2-[6](#__RefHeading___Toc485796788)

2.7.1 Product Budget 2-[6](#__RefHeading___Toc485796789)

2.7.2 Labor Requirements 2-[6](#__RefHeading___Toc485796790)

2.7.3 Cost Estimates 2-[6](#__RefHeading___Toc485796791)

2.8 Controls 2-[6](#__RefHeading___Toc485796792)

2.9 Implementation Approach and Milestones
2-[7](#__RefHeading___Toc485796793)

2.9.1 Implementation Approach 2-[7](#__RefHeading___Toc485796794)

2.9.2 Implementation Milestones 2-[7](#__RefHeading___Toc485796795)

2.10 Reporting Requirements 2-[7](#__RefHeading___Toc485796796)

2.10.1 Monthly Status Reviews 2-[7](#__RefHeading___Toc485796797)

2.10.2 Action Item Report 2-[7](#__RefHeading___Toc485796798)

2.10.3 Metrics 2-[8](#__RefHeading___Toc485796799)

2.11 Evaluation Process 2-[8](#__RefHeading___Toc485796800)

2.11.1 Performance Assurance 2-[8](#__RefHeading___Toc485796801)

2.12 Security 2-[8](#__RefHeading___Toc485796802)

2.13 Safety 2-[9](#__RefHeading___Toc485796803)

Section 3. Technical Summary

3.1 General 3-[1](#__RefHeading___Toc485796805)

3.2 Architecture 3-[1](#__RefHeading___Toc485796806)

3.3 Formulation Process 3-[2](#__RefHeading___Toc485796807)

3.3.1 Documentation Requirements 3-[2](#__RefHeading___Toc485796808)

3.3.2 Facility Requirements 3-[2](#__RefHeading___Toc485796809)

Section 4. System Implementation Strategy

4.1 Approval and Funding 4-[1](#__RefHeading___Toc485796811)

4.2 Acquisition Summary 4-[1](#__RefHeading___Toc485796812)

4.3 Risk Management 4-[1](#__RefHeading___Toc485796813)

Section 5. System Transition, Support, Logistics and Operations

5.1 SWSI Transition to Operations 5-[1](#__RefHeading___Toc485796815)

5.2 Operations and Maintenance 5-[1](#__RefHeading___Toc485796816)

5.2.1 Operations and Maintenance Approaches
5-[1](#__RefHeading___Toc485796817)

5.2.2 Life Cycle Costs 5-[1](#__RefHeading___Toc485796818)

5.3 Support and Logistics 5-[1](#__RefHeading___Toc485796819)

Abbreviations and Acronyms

Figures

Figure 2-1 Organization 2-[1](#__RefHeading___Toc463325969)

Figure 2-2 SWSI Schedule 2-[5](#__RefHeading___Toc463325970)

Figure 3-1 SWSI System Diagram 3-[3](#refheading___toc463325971)

Tables

Table 2-1 Responsibility Matrix 2-[2](#__RefHeading___Toc485696618)

Table 2-2 SWSI Detailed Labor Requirements - Civil Service
2-[6](#__RefHeading___Toc485696619)

Table 2-3 SWSI Detailed Labor Requirements - Contractor
2-[6](#__RefHeading___Toc485696620)

Table 3-1 SWSI Documentation 3-[2](#__RefHeading___Toc485696621)

# Introduction

[]{#__RefHeading___Toc485796770 .anchor}1.1 Purpose

The purpose of this document is to describe the Space Network (SN) Web
Services Interface (SWSI) implementation. The major driver is to provide
a standards-based customer interface for performing Tracking and Data
Relay Satellite (TDRS) scheduling and real-time service monitoring and
control. The intent of the SWSI is not to replace existing scheduling
and real-time systems for all SN customers. It is rather to provide a
simple low-cost interface option, especially for suborbital and
infrequent SN customers.

[]{#__RefHeading___Toc485796771 .anchor}1.1.1 Background

The interface between a customer Mission Operations Center (MOC) and the
Network Control Center Data System (NCCDS) consists of formatted
messages exchanged electronically using either Nascom 4800 Bit Block
(BB) protocol or Transmission Control Protocol (TCP). This interface is
described in detail in the NCCDS/MOC Interface Control Document (ICD).
New SN customers have traditionally been provided with a limited number
of options for implementing this interface. A full-featured SN
scheduling tool is provided by the User Planning System (UPS), which
runs on a Hewlett-Packard (HP) Unix host. New customers desiring to use
UPS for scheduling must either purchase their own system at a cost of
approximately \$35K per system, or interface with an institutional UPS
located within the Multisatellite Operations Control Center (MSOCC). A
NASA Integrated Services Network (NISN) Closed Internet Protocol (IP)
Operational Network (IONET) connection is required for the latter
option.

No standard option exists to provide a real-time (reconfiguration and
performance data monitoring) interface. All SN customers have been
required to implement their own systems at considerable cost.

Prospective SN customers have brought to light the need for a simple,
standard, readily available interface to the NCCDS. In response to this
need, NASA funded an in-house project to determine the feasibility of
such a tool. This project resulted in a prototype of a web-based
cross-platform customer interface to the NCC, called the SN Web Services
Interface (SWSI). Prototyping and proof of concept work was completed
and has been used to provide support to the Long Duration Balloon
Project (LDBP).

The final operational SWSI is a follow-on to the prototype effort and
will provide improvements in the form of a Java-based Graphical User
Interface (GUI) and better management of user schedule information.
Using the SWSI, SN customers will be able to perform scheduling,
real-time functions, and state vector storage for only the cost of a
desktop computer or workstation. A web browser and a Java virtual
machine, both of which are freely available, will also be required. The
SWSI is designed to be accessed from the NISN Closed IONET or Open
IONET. NISN's Open IONET allows access from the NASA Science Internet
and the public Internet, thus allowing cooperation with NASA\'s
university, enterprise, and inter/intra-agency partners.

This Product Management Plan (PMP) covers the SWSI product development
cycle beginning with the period after the technology demonstration phase
and terminates with completion of the implementation phase.

[]{#__RefHeading___Toc485796772 .anchor}1.1.2 Scope

This PMP applies to those activities that are being managed by the SWSI
Product Design Lead. The SWSI PMP encompasses the policy, organization,
control, direction, resources and responsibilities that apply to the
SWSI procurement, implementation, installation, integration, testing and
acceptance. This document has been developed in accordance with the
*Mission Services Program Office System Management Plan (SMP) Document
No. 450-PG-8700.2.2* and the *Space Network (SN) Project Plan Document
No. 451-MGMT-001*.

[]{#__RefHeading___Toc485796773 .anchor}1.1.3 Applicable Documents

a.  *Space Network (SN) Project Plan, Document No. 451-MGMT-001*

b.  *Quality Program Provisions for Aeronautical and Space Systems
    Contractors, NHB 5300.4(1B)*

c.  *Maintainability Program for Systems and Equipment, MIL-HDBK-470*

d.  *Maintainability for Verification/Demonstration/Evaluation,
    MIL-HDBK-471*

e.  *Mission Services Program Office Configuration Management Plan,
    450-PG-8700.2.1*

f.  *Mission Services Program Office Quality Assurance Plan,
    450-PG-8730.3.1*

g.  *Mission Services Program Office Systems Management Plan (SMP),
    450-PG-8700.2.2*

h.  *Standard for Product Data Packages, 500-TIP-3109*

i.  *NASA Policy Directive (NPD) 2810.1, NASA Policy for Security of
    Information Technology*

j.  *NASA Procedures and Guidelines (NPG) 2810.1, Security of
    Information Technology*

k.  *GSFC Security Manual, Goddard Handbook (GHB) 1600.1B*

l.  *NASA Safety Policy and Requirements Handbook, NHB 1700.1*

m.  *Interface Control Document Between the Network Control Center Data
    System and Mission Operations Center, 530-ICD-NCCDS/MOC*

n.  *Network Control Center Data System (NCCDS) System Requirements,
    1998, 530-SRD-NCCDS/1998*

o.  *Network Control Center (NCC) User Planning System (UPS) System
    Requirements Specification, Document No. 511-4SRD/0196*

p.  *Network Systems Integration & Analysis Master Test Plan for Network
    Control Center Data Systems, CSOC-GSFC-TEST-000924*

q.  *Collector Project Commitment Document (PCD) for GSFC Data Services*

[]{#__RefHeading___Toc485796774 .anchor}1.2 Objectives

The objectives of the SWSI are:

a.  Provide a standards-based web interface to the NCCDS to perform
    customer scheduling, real-time service monitoring and control, and
    state vector storage.

b.  Support all full support customer messages as defined in NCCDS/MOC
    ICD.

c.  Allow access from NISN Closed IONET, Open IONET, and Internet.

d.  Provide for secure message exchange using encryption.

e.  Provide a High Availability (HA) configuration to adhere to existing
    NCC Reliability/Maintainability/Availability (RMA) requirements.

f.  Implement the SWSI with a goal of minimizing acquisition,
    development, and life cycle cost.

g.  Provide customer access to Tracking and Data Relay Satellite System
    (TDRSS) Unscheduled Time (TUT) information from the Open IONET and
    Internet.

    3.  Overall Approach

The approach of the SWSI product development and deployment is to
establish a basic capability for performing web-based SN customer
scheduling and real-time functions. The basic infrastructure may be
added to at later dates to include more advanced capabilities, such as
increased automation of manual functions. The basic infrastructure will
provide for secure message exchange on all NISN and open networks and
will implement the complete NCCDS customer interface. Commercial
Off-The-Shelf (COTS) products (hardware, system software, database
tools, and security tools) will be used to the extent possible. Since no
other commercial or government application exists to perform the NCCDS
interface function, much of the SWSI effort will consist of custom
software development to be performed by a government/contractor team.
Some code reuse is expected from the Java-based Spacecraft Web Interface
to Telemetry and Command Handling (Jswitch) project, which performs a
similar function to SWSI and upon which the SWSI design is based.

[]{#refheading___toc485796775 .anchor}1.4 Plan Maintenance and Control

The SWSI Product Management Plan is under the control of the Goddard
Space Flight Center (GSFC) Flight Projects Directorate (FPD) Mission
Services Program (MSP) Project SN Project Configuration Control Board
(CCB) and is maintained as a baseline document. Changes in this plan
will be issued as revisions. A review of this plan will take place as
required. An updated or revised version will be published as required.
Control of resource estimates is exercised through the Program Operating
Plan (POP) budgeting cycle. Product Status is reported at Code 450
Project Monthly Reviews and SN Project Staff Meetings.

[]{#__RefHeading___Toc485796776 .anchor}1.5 Implementation Authority

Authority for this activity is contained in the POP under the Unique
Project Number (UPN) 218-10. The approval of the Space Operations
Management Office (SOMO) is contained in the Collector Project
Commitment Document (PCD) for GSFC Data Services under Web-based NCC
Services Interface Product.

# Section 2. Management {#section-2.-management .unnumbered}

[]{#__RefHeading___Toc485796778 .anchor}2.1 General

To achieve the SWSI implementation objectives of optimizing life cycle
costs and providing a simple low-cost SN customer interface, a
management approach is being adopted that capitalizes on experience
gained from the Network Control Center (NCC) Project. This approach
shall employ an existing management structure with the authority and
responsibility residing with the SWSI Product Design Lead. Other
resources shall be utilized when appropriate.

[]{#__RefHeading___Toc485796779 .anchor}2.2 NASA Responsibilities

[]{#__RefHeading___Toc485796780 .anchor}2.2.1 Organization

SWSI Product Design Team organizational relationships and matrixed
personnel are shown in Figure 2-1. The functional responsibilities of
key personnel for the SWSI are shown in Table 2-1.

[]{#__RefHeading___Toc463325969 .anchor}Figure 2-1 Organization

[]{#__RefHeading___Toc485696618 .anchor}Table 2-1 Responsibility Matrix

<table>
<colgroup>
<col style="width: 47%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
<col style="width: 4%" />
</colgroup>
<tbody>
<tr class="odd">
<td></td>
<td><blockquote>
<p>PRODUCT DESIGN LEAD (NASA)</p>
</blockquote></td>
<td><blockquote>
<p>SN SYSTEMS MANAGER (NASA)</p>
</blockquote></td>
<td><blockquote>
<p>RESOURCE MANAGER (NASA)</p>
</blockquote></td>
<td><blockquote>
<p>PRODUCT ENGINEERS (NASA)</p>
</blockquote></td>
<td><blockquote>
<p>TEST &amp; TRANSITION MANAGER (CSOC)</p>
</blockquote></td>
<td><blockquote>
<p>SODA TASK MANAGER (NASA)</p>
</blockquote></td>
<td><blockquote>
<p>SODA CSR/TASK LEAD (CSOC)</p>
</blockquote></td>
<td><blockquote>
<p>SODA SYSTEMS ENGINEER (CSOC)</p>
</blockquote></td>
<td><blockquote>
<p>SODA DEVELOPMENT ENGINEERS (CSOC)</p>
</blockquote></td>
<td><blockquote>
<p>INTEGRATION &amp; TEST ENGINEERS(CSOC) (CSOC) TEST(CSOC) (CSOC)
(CSOC)</p>
</blockquote></td>
<td><blockquote>
<p>OPERATIONS &amp; MAINTENANCE (CSOC CF)</p>
</blockquote></td>
</tr>
<tr class="even">
<td>Product Management</td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>√</strong></td>
<td><strong>A</strong></td>
<td><strong>A</strong></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>Interface to Systems Engineering Team</td>
<td></td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>A</strong></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>SODA Task Management</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>√</strong></td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>Cost/Schedule Control</td>
<td><strong>√</strong></td>
<td></td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>√</strong></td>
<td><strong>A</strong></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td>Configuration Management</td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>A</strong></td>
<td><strong>A</strong></td>
<td></td>
<td><strong>A</strong></td>
<td><strong>√</strong></td>
<td></td>
<td><strong>A</strong></td>
</tr>
<tr class="odd">
<td>Requirements, Specifications and ICDs</td>
<td><strong>√</strong></td>
<td><strong>√</strong></td>
<td></td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>√</strong></td>
<td><strong>A</strong></td>
<td><strong>A</strong></td>
<td><strong>A</strong></td>
</tr>
<tr class="even">
<td>Design</td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>A</strong></td>
<td><strong>√</strong></td>
<td></td>
<td></td>
</tr>
<tr class="odd">
<td>Verification Planning</td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td><strong>√</strong></td>
<td><strong>A</strong></td>
<td><strong>√</strong></td>
<td><strong>A</strong></td>
</tr>
<tr class="even">
<td>Security</td>
<td><strong>√</strong></td>
<td><strong>√</strong></td>
<td></td>
<td><strong>√</strong></td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td><strong>A</strong></td>
<td><strong>√</strong></td>
<td><strong>A</strong></td>
<td></td>
</tr>
<tr class="odd">
<td>Development</td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>A</strong></td>
<td><strong>√</strong></td>
<td><strong>A</strong></td>
<td><strong>A</strong></td>
</tr>
<tr class="even">
<td>Integration and Test</td>
<td><strong>A</strong></td>
<td></td>
<td></td>
<td><strong>A</strong></td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td><strong>A</strong></td>
<td><strong>A</strong></td>
<td><strong>√</strong></td>
<td><strong>A</strong></td>
</tr>
<tr class="odd">
<td>Installation</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>A</strong></td>
<td><strong>A</strong></td>
<td><strong>A</strong></td>
<td><strong>√</strong></td>
</tr>
<tr class="even">
<td>Installation Test</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td><strong>A</strong></td>
<td><strong>A</strong></td>
<td><strong>√</strong></td>
<td><strong>√</strong></td>
</tr>
<tr class="odd">
<td>Acceptance Tests</td>
<td><strong>A</strong></td>
<td></td>
<td></td>
<td>A</td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td><strong>A</strong></td>
<td><strong>A</strong></td>
<td><strong>√</strong></td>
<td><strong>√</strong></td>
</tr>
<tr class="even">
<td>Training</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>A</strong></td>
<td><strong>A</strong></td>
<td><strong>A</strong></td>
<td><strong>√</strong></td>
</tr>
<tr class="odd">
<td>Integrated Logistics Support Plan</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>A</strong></td>
<td><strong>A</strong></td>
<td></td>
<td><strong>√</strong></td>
</tr>
<tr class="even">
<td>Product Assurance</td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td></td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td><strong>A</strong></td>
<td><strong>A</strong></td>
<td></td>
<td><strong>√</strong></td>
</tr>
<tr class="odd">
<td>Operations and Maintenance Concept</td>
<td></td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td><strong>A</strong></td>
<td></td>
<td></td>
<td><strong>√</strong></td>
</tr>
<tr class="even">
<td>Transition to Operations</td>
<td></td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td><strong>√</strong></td>
<td></td>
<td></td>
<td><strong>A</strong></td>
<td></td>
<td><strong>A</strong></td>
<td><strong>√</strong></td>
</tr>
<tr class="odd">
<td><strong>A</strong> = Assist</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>

[]{#__RefHeading___Toc485796781 .anchor}2.2.2 Definitions

**Product Management** - Ensure the performance of all management
functions necessary for delivery of the SWSI product. Direct and control
system definition, design development, and validation of the system.
Develop and implement the product plan to define the schedules and to
identify, justify, allocate, obligate, account, and manage fiscal and
human resources (civil service and contractor) necessary to deliver the
SWSI product. Liaison with other NASA programs and offices is performed
under this responsibility.

**Interface to Systems Engineering Team -** Advise the Product Design
Lead of SN system requirements that could affect the implementation of
the SWSI. Monitor the SWSI implementation to ensure compatibility with
as-built and/or future installations.

**SODA Task Management -** Management of the support provided to the
SWSI Product Design Lead via Consolidated Space Operations Contract
(CSOC) Space Operations Directive Agreement (SODA).

**Cost/Schedule Control -** Establish and support a formal performance
measurement system that will realistically monitor the actual work
completed versus the budget and schedule agreements. Prepare all
financial and schedule performance and status reports to permit upper
levels of management to exercise necessary cost/schedule control over
the SWSI product.

**Configuration Management** -- Maintain system requirements and
documentation baselines in a disciplined and traceable manner to support
the development and delivery of the product. This term also applies to
the change control process(es) applicable to the integrity of each
deliverable software Configuration Item (CI).

**Requirements and Specifications -** Establish and maintain all system
requirements for the product. Allocate system functional and performance
requirements and specifications to hardware and software functions;
generate software requirements specifications and software interface
requirements specifications. Approve all hardware and software design
specifications.

**Design --** Perform and maintain the system design necessary to meet
the overall SWSI specifications. Conduct all design reviews.

**Verification Planning --** Generate all system level test plans and
supporting documentation. Conduct system level performance analyses to
ensure that the SWSI will demonstrate that all requirements have been
met. Approve system level test procedures. Approve all hardware and
software configuration item test plans and procedures.

**Security --** Ensure equipment, material, and procedures are present
which provide personnel, physical, communications, computer, and
information security in accordance with NASA and Designated Approving
Authority (DAA) directives and guidance. Perform a security assessment
at the appropriate point.

**Development --** Develop and build hardware, software and firmware
systems to meet requirements. Perform appropriate subunit tests.
Maintain development documentation for all new development items.
Prepare appropriate engineering changes.

**Integration & Test --** Integrate and test each deliverable CI.

**Installation** - Perform the installation of the deliverable system(s)
at the appropriate sites.

**Installation Test --** Conduct tests on systems and components to
identify any damage due to shipping, and to verify that assembly and
integration procedures have been correctly performed.

**Acceptance Tests --** Conduct system and subsystem tests to verify and
validate adherence to requirements.

**Training** - Develop plans and procedures to ensure all Operations and
Maintenance (O&M) of the SWSI are performed in a safe and satisfactory
manner. Classroom training and actual equipment training are included in
this responsibility.

**Integrated Logistics Support Plan** - Provide logistics support to the
SWSI product effort including provision of spare mechanical and
electronic parts and the procurement of equipment and materials
necessary to support operation and maintenance functions.

**Product Assurance -** Control all phases of SWSI product development
to ensure that systems meet the standards and tolerances as required by
*NHB 5300.4(1B)*, *MIL-HDBK-470*, and *MIL-HDBK-471*.

**Operations and Maintenance Concept --** Develop plans and concepts to
operate and maintain the SWSI within the SN. Develop plans and
procedures to conduct corrective and preventive maintenance on all
systems and subsystems.

**Transition to Operations --** Perform activities that are necessary to
deploy SWSI to make it available to support SN customers.

[]{#__RefHeading___Toc485796782 .anchor}2.3 Contractor Responsibilities

Hardware installation, software development and integration, operations
and engineering testing, and transition to operations shall be
implemented through a CSOC SODA Task**.**

[]{#__RefHeading___Toc485796783 .anchor}2.4 Configuration Management

[]{#__RefHeading___Toc485796784 .anchor}2.4.1 Configuration Control
Board

A CCB shall be established. The SWSI Product Design Lead shall function
as the head of this board and shall have approval authority over all
Configuration Change Requests (CCRs). The head of the SWSI CCB shall
instigate CCRs to be reviewed by the appropriate NASA personnel prior to
approval by the board. The SWSI CCB shall consist of the following
members or their representatives:

-   Product Design Lead (NASA)

-   SN System Manager (NASA)

-   Product Engineers (NASA)

-   GSFC IOA CSOC Architect

-   SODA Systems Engineer (CSOC)

-   SODA Software Development (CSOC)

-   Integration & Test Engineers (CSOC)

-   Operations & Maintenance \[CSOC Completion Form (CF)\]

The head of the SWSI CCB shall instigate CCRs to be reviewed by and
receive input from all board members prior to its approval.

Configuration changes that interface with other systems or projects
shall be submitted to the cognizant CCB(s)/Systems Engineering Review
Boards (SERB) for concurrence and approval. The CCB shall work closely
with the CSOC SERB during transition to operations.

[]{#__RefHeading___Toc485796785 .anchor}2.4.2 Configuration Management
Plan and Quality Assurance

The implementation contractor shall conform to the Configuration
Management (CM) quidelines defined in the *MSPO Configuration Management
Plan 450-PG-8700.2.1*. Quality assurance and performance verification
shall conform to the *MSPO Quality Assurance Plan 450-PG-8730.3.1*.

[]{#__RefHeading___Toc485796786 .anchor}2.5 Data Management

New documents and drawings shall be prepared in accordance with the
requirements defined in the *MSPO Systems Management Plan (SMP),
450-PG-8700.2.2*, and the *Standard for Product Data Packages,
500-TIP-3109*.

[]{#__RefHeading___Toc485796787 .anchor}2.6 Schedule

  ------------------------------------------------ ----------------------
  Product Development Review (PDR)                 06/01/00

  Detailed Design                                  04/15/00 -- 07/07/00

  Requirements/Design Review (R/DR)                07/07/00

  Build 1 Development                              07/07/00 - 12/29/00

  Code and Test                                    07/07/00 -- 11/30/00

  System Testing                                   12/01/00 -- 12/29/00

  Build 2 Development                              11/01/00 - 03/30/01

  Code and Test                                    11/01/00 - 02/28/01

  System Testing                                   03/01/01 - 03/31/01

  Test Readiness Review (TRR)                      04/01/01

  Acceptance Testing                               04/02/01 - 04/30/01

  Final Hardware Installation                      05/01/01 - 05/31/01

  Operations Readiness Review (ORR)                06/01/01

  Transition to Operations                         06/15/01
  ------------------------------------------------ ----------------------

[]{#__RefHeading___Toc463325970 .anchor}Figure 2-2 SWSI Schedule

[]{#__RefHeading___Toc485796788 .anchor}2.7 Resources

[]{#__RefHeading___Toc485796789 .anchor}2.7.1 Product Budget

SWSI funding requirements are based on the POP-00 budget exercise.
Funding shall be provided under UPN 218-10 and UPN 224-10.

[]{#__RefHeading___Toc485796790 .anchor}2.7.2 Labor Requirements

An estimate of Civil Service and Product support contractor requirements
are provided in Tables 2-2 and 2-3 respectively. These estimates are
based on past NCCDS Project experience.

[]{#__RefHeading___Toc485696619 .anchor}Table 2-2 SWSI Detailed Labor
Requirements - Civil Service

  --------------------------------- ------------ ------------ ------------
  **POSITION**                      **FY00**     **FY01**     **TOTAL**

                                                              

  SWSI PRODUCT DESIGN LEAD          .7           .7           1.4

  RESOURCE MANAGER                  .1           .1           .2

  PRODUCT ENGINEERS                 1.0          1.0          2.0

  **TOTAL**                         1.8          1.8          3.6
  --------------------------------- ------------ ------------ ------------

[]{#__RefHeading___Toc485696620 .anchor}Table 2-3 SWSI Detailed Labor
Requirements - Contractor

+--------------------------------+-----------+-----------+-----------+
| #### PR                        | **FY00**  | **FY01**  | **TOTAL** |
| ODUCT SYS ENG SUPPORT {#produc |           |           |           |
| t-sys-eng-support .unnumbered} |           |           |           |
+--------------------------------+-----------+-----------+-----------+
|                                |           |           |           |
+--------------------------------+-----------+-----------+-----------+
| MANAGEMENT SUPPORT             | .1        | .1        | .2        |
+--------------------------------+-----------+-----------+-----------+
| SYSTEMS ENGINEERING            | .5        | .4        | .9        |
+--------------------------------+-----------+-----------+-----------+
| SYSTEMS DEVELOPMENT            | 2.4       | 2.9       | 5.3       |
| ENGINEERING                    |           |           |           |
+--------------------------------+-----------+-----------+-----------+
| INTEGRATION & TEST             | .25       | .45       | .7        |
+--------------------------------+-----------+-----------+-----------+
| DOCUMENTATION                  | .1        | .1        | .2        |
+--------------------------------+-----------+-----------+-----------+
| OPERATIONS TRANSITION/TRAINING | 0         | .2        | .2        |
+--------------------------------+-----------+-----------+-----------+
| **TOTAL**                      | 3.35      | 4.15      | 7.5       |
+--------------------------------+-----------+-----------+-----------+

[]{#__RefHeading___Toc485796791 .anchor}2.7.3 Cost Estimates

The cost estimates for the SWSI Product are available from the SWSI
Product Design Lead.

[]{#__RefHeading___Toc485796792 .anchor}2.8 Controls

The SWSI Product Design Lead shall exercise control of the
implementation budget, schedules, procurements, risk management
planning, requirements performance and baseline documents. This control
shall be maintained through the configuration management process defined
in Section 2.4, the Performance Verification Plan regular status
meetings, monthly technical and financial reviews, and an action item
reporting system. The formats of reviews and action item reporting shall
be developed by the implementation contractor and approved by the
Product Design Lead.

[]{#__RefHeading___Toc485796793 .anchor}2.9 Implementation Approach and
Milestones

[]{#__RefHeading___Toc485796794 .anchor}2.9.1 Implementation Approach

The implementation approach will follow traditional waterfall model.
However, due to schedule limitations and an attempt to get some of the
benefits of a spiral model, the development phases will have significant
overlap.

[]{#__RefHeading___Toc485796795 .anchor}2.9.2 Implementation Milestones

The life-cycle reviews that will be conducted are listed below:

-   Product Development Review (PDR)

-   Requirements Design Review (R/DR)

-   Test Readiness Review (TRR)

-   ORR/Transition Readiness Review (TRR)

The Preliminary Design Review was completed in conjunction with the
prototyping activities. The R/DR will be a peer review to be conducted
after the completion of the draft System Requirements Document and
System Design Specification.

[]{#__RefHeading___Toc485796796 .anchor}2.10 Reporting Requirements

[]{#__RefHeading___Toc485796797 .anchor}2.10.1 Monthly Status Reviews

The implementation contractors shall present a monthly oral review to
the SWSI Product Design Lead reviewing the technical status and
indicating progress in achieving scheduled project milestones. The
Monthly Status Review (MSR) package shall suffice as a Monthly Progress
Report (MPR).

The SWSI Product Design Lead shall present the product status to the
GSFC Data Services Upgrades Manager. The review shall cover the
significant aspects of the project, including technical progress,
schedule adherence, and resource utilization. Performance measurement
reports shall be presented at these reviews. Emphasis shall be placed on
the accomplishments for the concluded reporting period, the planned
project activity for the next reporting period, and the identification
and resolution of all issues and problems.

[]{#__RefHeading___Toc485796798 .anchor}2.10.2 Action Item Report

The implementation contractor shall submit a weekly report of action
items that ensures the actions to be taken are clearly defined and
responsibility is assigned. The report shall indicate which items are
closed and the rationale for closure, which items are open, and the
scheduled closure date. This report shall note any changes in the
progress/status of action items since the last report.

[]{#__RefHeading___Toc485796799 .anchor}2.10.3 Metrics

The implementation contractor shall submit a weekly report of metrics
related to the progress and quality of the product. This report will
specify the following metrics when applicable:

-   Number of units/files planned/completed

-   Number of Delivered Source Instructions (DSI) in each unit/file

-   Number of test cases planned/completed

-   Number of Problem Reports (PRs) generated against the product by
    priority and status

-   The computed error rate/KDSI

Based on new development in NCC 98, the quality goal for this PMP is 5
errors/KDSI.

[]{#__RefHeading___Toc485796800 .anchor}2.11 Evaluation Process

[]{#__RefHeading___Toc485796801 .anchor}2.11.1 Performance Assurance

2.11.1.1 Product Validation Planning

A Product Validation Plan shall be developed which identifies acceptance
criteria for product validation. Details of this plan shall be contained
in several documents. A Test Requirements Verification Matrix (TRVM)
shall provide traceability to specific test procedures. The methodology
along with test procedures and matrix development review cycles are
identified in the *Network Systems Integration & Analysis Master Test
Plan for Network Control Center Data Systems, CSOC-GSFC-TEST-000924.*

2.11.1.2 Document Review

All project documents shall be reviewed and approved by the SWSI Product
Design Lead prior to release. The Implementation Contractor shall submit
for the Product Design Lead's approval a table defining the documents to
be prepared for this product. This table shall list the document name,
the date the format was approved, the current status; the date drafts
are delivered for approval, and the approval date. This table shall be
included in the slides presented at the Monthly Status Review.

2.11.1.3 Lessons Learned

Lessons learned will be submitted to the Flight Programs and Projects
Directorate (FPPD) Lessons Learned Database at
http://fpd.gsfc.nasa.gov/llis.html for possible inclusion into the NASA
HQ Lessons Learned Information System at
<http://llis.nasa.gov/llis/llis.html>.

[]{#__RefHeading___Toc485796802 .anchor}2.12 Security

The SWSI implementation shall comply with the security policies and
procedures established in the *NASA Policy Directive (NPD) 2810.1*,
*NASA Policy for Security of Information Technology*, and the *NASA
Procedures and Guidelines (NPG) 2810.1, Security of Information
Technology*.

[]{#__RefHeading___Toc485796803 .anchor}2.13 Safety

The SWSI implementation shall comply with the safety policies and
procedures established in the *NASA Safety Policy and Requirements
Handbook, NASA Handbook (NHB) 1700.1*.

# Section 3. Technical Summary {#section-3.-technical-summary .unnumbered}

[]{#__RefHeading___Toc485796805 .anchor}3.1 General

The SWSI Implementation will result in a new generation low cost
cross-platform solution for scheduling Space Network services. A
web-based approach means that the solution will be cross-platform
compatible, since there are web browsers and Java virtual machines
available for almost every computer platform \[Personal Computer (PC),
Macintosh, Unix, and the like\]. The web browser and Java provide a
reduced hardware dependency for the customer\'s Mission Operations
Center (MOC). All MOCs use either PC, Unix, or Macintosh workstations,
or some combination of the three.

[]{#__RefHeading___Toc485796806 .anchor}3.2 Architecture

Figure 3-1 depicts the overall SWSI architecture. The SWSI prototype
provided Hypertext Markup Language (HTML) forms for the user to enter
requests such as schedule and reconfiguration requests and to display
results such as user schedules and user performance data. The final
operational SWSI is instead Java-based and is based on work previously
performed on the Java-based Spacecraft Web Interface to Telemetry and
Command Handling (Jswitch). Jswitch objectives are very similar to those
of SWSI in that it provides a secure, platform-independent user
interface to a spacecraft MOC from any network, including the Internet.

SWSI customers will be provided with client software capable of
executing on multiple platforms using Java Virtual Machine from Sun
Microsystems. Clients will establish connections to a SWSI server using
the Secure Socket Layer (SSL) protocol and authentication with digital
certificates. Two sets of SWSI servers are provided to allow access from
clients via both the Open IONET and Closed IONET. The Open SWSI Server
will act as a proxy, routing requests from Open IONET and Internet-based
customers to the Closed SWSI Server using encrypted connections through
the NISN Secure Gateway.

The Closed SWSI Server establishes the appropriate TCP connections with
the NCCDS and performs an exchange of messages according to the formats
defined in the NCCDS/MOC ICD. A separate set of connections is
maintained on behalf of each SWSI customer. Schedule information
returned from the NCCDS in the form of User Schedule Messages (USMs) is
stored in a database on the Closed SWSI Server for later customer
viewing.

In addition to providing a Java interface to SN customers for performing
scheduling and real-time functions, SWSI will also provide an HTML-based
web page for displaying TUT information. The current NCCDS provides TUT
service on the Closed IONET only. An identical service will be provided
by SWSI for Open IONET and Internet-based customers. This will be
accomplished by the Closed SWSI Server periodically downloading the
information from the NCCDS TUT Server and passing it to the Open SWSI
Server through the Secure Gateway. The Open SWSI Server will then
display TUT using the same software as is used on the NCCDS TUT Server.

This PMP describes the activities involved for a portion of the
equipment depicted in Figure 3-1. The efforts described herein shall
result in the development, integration and test of four operational SWSI
servers.

[]{#__RefHeading___Toc485796807 .anchor}3.3 Formulation Process

[]{#__RefHeading___Toc485796808 .anchor}3.3.1 Documentation Requirements

Technical requirements and constraints, interface control documents,
hardware and software specifications and designs, test planning, and
operating instructions shall be documented as shown in Table 3-1.

[]{#__RefHeading___Toc485696621 .anchor}Table 3-1 SWSI Documentation

  -----------------------------------------------------------------------
  System Requirements Document

  System Design Specification

  Software Design Specification

  Hardware Specification and Configuration

  Product Validation Plan

  User\'s Guide

  Release History Report

  Integrated Logistics Support (ILS) Plan
  -----------------------------------------------------------------------

[]{#__RefHeading___Toc485796809 .anchor}3.3.2 Facility Requirements

The SWSI shall be initially housed within GSFC Building 13, and possibly
be transitioned at a later date to the White Sands Data Services
Management Center (DSMC). The facilities shall include a development and
test suite of equipment that can emulate the operational configuration.
The facility shall include an operational suite of equipment. The
operational suite also requires a connection to Open IONET (with
applicable IP addresses from NISN) and to Closed IONET (with applicable
IP addresses from NISN).

No significant modifications are required to Building 13 to support
these facilities. Minor modifications may include adding a connection to
Open IONET, running new cables from the SWSI servers to the NISN
routers, and adding racks or tables. Power shall be drawn from existing
Technical Power panels and power and power cables shall be routed
primarily in existing cableways. Where necessary, the SWSI may require
new power outlet boxes and cable hangers within the existing underfloor
infrastructure.

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

[]{#refheading___toc463325971 .anchor}Figure 3-1 SWSI System Diagram

# Section 4. System Implementation Strategy {#section-4.-system-implementation-strategy .unnumbered}

[]{#__RefHeading___Toc485796811 .anchor}4.1 Approval and Funding

Prior actions have approved the SWSI for implementation. The Collector
PCD for GSFC Data Services containing the Web-based NCC Services
Interface Product has been approved by the SOMO and funds have been
committed under UPN 218-10.

[]{#__RefHeading___Toc485796812 .anchor}4.2 Acquisition Summary

NASA shall perform SWSI hardware and Commercial Off-The-Shelf (COTS)
software procurement. Where possible this procurement will take place
using the Scientific and Engineering Workstation Procurement (SEWP)
contract. For products not available on SEWP, acquisition will be via
establishment of a contract with the appropriate vendor.

[]{#__RefHeading___Toc485796813 .anchor}4.3 Risk Management

The technical risk associated with SWSI development is low, since
established technology has been applied from the outset. An extensive
amount of experience was gained by the implementation contractor in
developing Java-based systems through work on the Jswitch project. Also,
a high degree of success was demonstrated by the SWSI Prototype in
support of the LDBP in June 1999.

If a schedule slip occurs in implementation and/or transition to
operations, other options are available to accommodate early customers.
The SWSI prototype is available for scheduling, real-time, and state
vector support for customers in the pre-launch testing phase. For the
launch and post-launch phases, the MSOCC UPS is available for scheduling
using an X-Windows interface over the Closed IONET. Real-time support
may be provided by NCC operators through voice coordination with the
customer.

Establishing suitable incentives with the contractor and/or reducing
capability in the final system can mitigate cost growth.

# Section 5. System Transition, Support, Logistics and Operations {#section-5.-system-transition-support-logistics-and-operations .unnumbered}

[]{#__RefHeading___Toc485796815 .anchor}5.1 SWSI Transition to
Operations

The Implementation Contractor shall develop an Operations Transition
Plan.

[]{#__RefHeading___Toc485796816 .anchor}5.2 Operations and Maintenance

[]{#__RefHeading___Toc485796817 .anchor}5.2.1 Operations and Maintenance
Approaches

The SWSI shall be operated under the appropriate CSOC Contract Service
Level Agreement (CSLA) to provide SN customer interface capabilities for
scheduling, service monitoring and control, and state vector storage
interfaces. The CSOC contractor shall perform maintenance as an integral
function of support to these CSLAs.

[]{#__RefHeading___Toc485796818 .anchor}5.2.2 Life Cycle Costs

Life cycle costs estimates have been included in the Collector PCD for
GSFC Data Services and are available from the SWSI Product Design Lead.

[]{#__RefHeading___Toc485796819 .anchor}5.3 Support and Logistics

The implementation contractor shall prepare an Integrated Logistics
Support Plan that shall define the logistics requirements of the SWSI.
The following elements shall be assessed in developing this plan:

a.  Maintenance planning

b.  Sparing Plan

c.  Supply, product, and sales support

d.  Support and test equipment

e.  Packaging, handling, storage, and transportation

f.  Training and logistics support personnel

g.  Government furnished and contractor furnished equipment

h.  Technical data and documentation

# Abbreviations and Acronyms {#abbreviations-and-acronyms .unnumbered}

  ------------------ ----------------------------------------------------
  ANCC               Auxiliary Network Control Center

  BB                 Bit Block

  CCB                Configuration Control Board

  CCR                Configuration Change Request

  CCS                Communication and Control Segment

  CDR                Critical Design Review

  CF                 Completion Form

  CI                 Configuration Item

  CM                 Configuration Management

  COTS               Commercial-off-the-Shelf

  CSLA               Contract Service Level Agreement

  CSOC               Consolidated Space Operations Contract

  CSR                Customer Service Representative

  DAA                Designated Approving Authority

  DCN                Document Change Notice

  DR                 Design Review

  DSI                Delivered Source Instructions

  DSMC               Data Services Management Center

  FPD                Flight Projects Directorate

  GHB                GSFC Handbook

  GSFC               Goddard Space Flight Center

  GUI                Graphical User Interface

  HA                 High Availability

  HP                 Hewlett-Packard

  HTML               Hypertext Markup Language

  ICD                Interface Control Document

  ILS                Integrated Logistics Support

  IONET              IP Operational Network

  IP                 Internet Protocol

  Jswitch            Java-based Spacecraft Web Interface to Telemetry and
                     Command Handling

  KDSI               One Thousand Developed Source Instruction

  LDBP               Long Duration Balloon Project

  MOC                Mission Operations Center

  MPR                Monthly Progress Report

  MSOCC              Multisatellite Operations Control Center

  MSP                Mission Services Program

  MSR                Monthly Status Review

  NASA               National Aeronautics and Space Administration

  NCC                Network Control Center

  NCCDS              Network Control Center Data System

  NHB                NASA Handbook

  NISN               NASA Integrated Services Network

  NPG                NCCDS Protocol Gateway

  O & M              Operations and Maintenance

  PC                 Personal Computer

  PCD                Project Commitment Document

  PDR                Product Development Review

  PMP                Product Management Plan

  POP                Program Operating Plan

  PR                 Problem Report

  RMA                Reliability/Maintainability/Availability

  SERB               Systems Engineering Review Board

  SEWP               Scientific and Engineering Workstation Procurement

  SMP                System Management Plan

  SN                 Space Network

  SODA               Space Operations Directive Agreement

  SOMO               Space Operations Management Office

  SPSR               Service Planning Segment Replacement

  SSL                Secure Socket Layer

  SWSI               Space Network Web Services Interface

  TCP                Transmission Control Protocol

  TDRS               Tracking and Data Relay Satellite

  TDRSS              TDRS System

  TRR                Test Readiness Review

  TRR                Transition Readiness Review

  TUT                TDRSS Unscheduled Time

  UPN                Unique Project Number

  UPS                User Planning System

  USM                User Schedule Messages
  ------------------ ----------------------------------------------------