Space Network Access System (SNAS) Preliminary Design Review - PowerPoint PPT Presentation

Space Network Access System (SNAS) Preliminary Design Review

September 12, 2005

NASA Code 452

Space Network (SN) Project

• Opening Remarks Rose Pajerski
• SNAS Design Approach Damon Smith
• SNAS Overview Dave Warren
• Data Server Design Dave Warren
• Closed/Open Server Design Hoai Vo
• Client Design Helly Maghsoudlou
• Graphical User Interface Design Damon Smith
• Security Joe Clark
• Architecture Recommendation & Scott Robinson

Development Environment

• Software and Effort Estimates Chii-der Luo
• Risks & Mitigation Dave Warren
• Closing Remarks Rose Pajerski

• Review System Requirements adjusted from Delta-SRR due to RFA’s
• Updated SRD
• Updated OCD
• Baselined documents 08/31
• Review High Level System Design
• Review GUI Prototyping Effort
• Approval for Detailed Design

• Jon Walker (chair), NASA Code 452
• Merri Benjamin, WSC Operations
• John Bristow, NASA Code 583 – GMSEC
• Tim Rykowski, NASA Code 581 – GPM
• Steve Tompkins, NASA Code 581

Originator accepts or rejects response

Originator writes RFA

SRR Chair assesses and assigns

Assignee prepares response

Accepts

SRR Chair Disposition

Actions assigned and executed

Assignee feels rejection is warranted and reworks response

Assignee feels response is valid and appropriate

Rejects

• Request for Action (RFA) items may be written by any party and are to be submitted to the review Chair
• Forms are available at this review or via the SNAS website: http://snas.gsfc.nasa.gov
• RFAs are due Friday, September 16, 2005
• The Chair will assess RFA validity, combine similar ones if necessary, and assign them to appropriate personnel
• RFA responses will be prepared by the assignee and forwarded to the originator for their acceptance or rejection
• The RFA assignee will notify the Chair after working the RFA response with the originator
• RFA responses will be approved/disapproved by the SRR Chair at a meeting to be scheduled by the Chair

SN Project Manager

Code 452

Keiji Tasaki

SNAS Deputy Product Development Lead

Rose Pajerski/

Frank Herman

Resource/Business Manager

Paula Tidwell

IT Security

Curtis Emerson

Code 451

GSFC Customer

Commitment Manager

S. Greatorex / NENS

Systems Engineering Contractor

ITT

Implementation Contractor

NENS

Product ManagementContractor

PAAC-II

NASA

Contractor

• Product Development Lead (Code 452)
• Fraunhofer USA: Rose Pajerski / Frank Herman
• System Engineering Support
• ITT: Denise Gilliland, Joe Clark
• Customer Liaison Lead
• BAH: Farrokh Jahandari
• Core Implementation Team
• BAH: Damon Smith
• HTSI: Chii-der Luo, Dave Warren, Helly Maghsoudlou, Hoai Vo, Scott Robinson, Yuen-Han Kan, Dave Smith, Marcelo Reynolds

• Delta-SRR RFAs
• 28 RFA’s submitted and responded to
• Automation (3, 9, 12, 15)
• Certification & encryption (1, 8, 11, 21)
• Client Capability (5, 16, 20, 27)
• Configuration and Specs (4, 7, 9, 13, 23)
• Report and Data Access (2, 6, 10, 17, 18, 24, 25, 26, 28)
• Schedule Planning (14, 22)
• SNAS Interface with DAS (14) withdrawn
• Additionally, 3 RFAs from the 2003 SRR (62, 65 and 83) were Closed

• Decomposition of the 337 SNAS System (software) Requirements
• 282 are partially applicable to Client
• 13 fully applicable to Client
• 247 are partially applicable to GUI
• 8 fully applicable to GUI
• 202 are partially applicable to Open/Closed Server
• 22 fully applicable to Open/Closed Server
• 138 are partially applicable to Data Server
• 2 fully applicable to Data Server

• System Requirements Document CCB approved
• System Operations Concept Document CCB approved
• Security Plan 2nd draft in development
• System Test Document 1st draft in development
• Acceptance Test Document 1st draft in development
• Customer Liaison Plan in NENS Review
• ICD between DAS/SNAS derived from DAS/SWSI for CDR
• ICD between EPS/SNAS derived from UPS/EU for CDR

SNAS Design Approach

Presented By:

Damon Smith

• Requirements: Involved end users early to address customer requirements while supporting:
• MOC operations
• Legacy MOC components
• Various MOC configurations
• O&M Operations
• Design: Presented the SNAS prototype to illustrate and negotiate design features
• Solicited design options during customer demonstrations
• Testing: Planning Involvement of selected customers in beta testing

• Group Customer Interface Meetings
• CIM #1, April 13, 2005
• CIM #2, June 14, 2005
• CIM #3, August 25, 2005
• CIM #4 (tentative), January 2006
• Meetings with Individual Missions
• JSC, TX (HSF, Shuttle, ISS)
• GSFC & APL (GPM, R-XTE, EOS, TRMM, HST & STSCI, SP&M, GLAST)
• Raytheon, CO (NPOESS & Aura)
• Stanford University, CA (GP-B)
• WSC, NM (O&M Operations)
• Meetings with other Programs
• GMSEC, IONet, TKUP, SNIS
• RFAs
• Original SRR, and Delta-SRR on April 28, 2005
• PDR, September 12, 1:00 – 4:00

• Majority of customer requests already included in the current requirements (wish list features are not in the current requirements)
• Workspace concept for scheduling
• The Workspace is envisioned as a bulk schedule builder and compatible with UPS RS. A Workspace is saved locally for a multi-day building period. Local file sharing for (Orbital Data, Schedule Data, and Reports) supports collective group scheduling. Degraded mode of operations and local off-line building are supported by the Workspace.
• Auto processing for various file types (GCMR, TSW, TCW, PSAT/UAV)
• SWSI and UPS contain functionality to pass TSW files automatically. Importing PSAT/UAV is only available in UPS and requires manual processing.
• UPS Queries
• UPS canned queries are easy to implement and satisfy customer requests for access to mission data in the database.

• Show 24 hour UPD history in the UPD panel & Alert history in the Alert panel
• These features are currently in the concept to support lights-out MOC operations. Unattended operations can show a selectable 24 hours of event information.
• Drag/Drop & Point/Click features in the graphical scheduling mode
• The Java development environment allows for advanced user interactions with the graphics. In line comparisons and overlaying user selected data types (e.g. TUT with orbital data and schedule requests).
• Performance Statistics (active) reporting
• Currently in the concept to provide counters for input/output file transfers. Ensures that the message counts for “sent” and “received” match.

• UPD summary panel
• Currently in the SNAS concept, triggered off the current UPD stream panel for user specified services. Provides a high level summary for active services (concept currently used at JSC).
• User configurable alert threshold settings
• In addition to configurable color coding, users would possess the ability to adjust thresholds for alert settings and UPD settings (audibles, confirmation dialog)
• Combine NCC and DAS scheduling
• DAS and NCC schedules are presented together in the graphical scheduling mode, the user must resolve schedule conflicts.
• Schedule SN and GN resources
• The SNAS graphical mode can display GN resource in the scheduling mode, when it is loaded as orbital data exclusion periods.

• User ability to change SIC after login
• This function does not currently exist in SWSI or UPS. SNAS incorporation of this function would support SNIS when platforms can uniquely (IP) address science instruments.
• GMSEC configurable support in the SNAS client
• A SNAS interface with GMSEC would enhance the support for lights-out MOC operations. GMSEC could allow SNAS to utilize the pager feature for critical alerts. SNAS could also interface with the system status reporting on the GMSEC bus.
• Display the current values and acceptable values for each reconfigurable parameter
• Current values are available – bound range values are not.

System Overview

Presented By:

David Warren

NISN Secure

Gateway

MOC Clients

DAS

MOC Clients

MOC Clients

Operational

Firewall

NCCDS

Internet

Closed

IONet

Open

IONet

Auxiliary

NCCDS

Firewall

NISN/CNE

SNAS Open Server

SNAS Open Server

SNAS Closed Server

SNAS Closed Server

RAID

(Prime)

(Backup)

(Prime)

(Backup)

Data

NISN Secure

Gateway

Operational

NCCDS

MOC Clients

Firewall

DAS

MOC Clients

MOC Clients

Internet

Closed

IONet

Auxiliary

NCCDS

Firewall

Open

IONet

NISN/CNE

SNAS Closed Server

(Prime)

SNAS Closed Server

(Backup)

SNAS Open Server

SNAS Open Server

(Prime)

(Backup)

SNAS Data Server

(Backup)

SNAS Data Server

(Prime)

RAID

Data

Open IONET

Internet

Closed IONET

SNAS

SNAS

SNAS

SNAS

SNAS

SNAS

CLIENT

CLIENT

CLIENT

CLIENT

CLIENT

CLIENT

SNAS Closed Server

Connection Manager

Connection Manager

NISN

Secure Gateway

SNAS Open Server

Message Router

Message Router

Message Router

Message Router

Connection

Manager

TUT

Connection

Webserver

Manager

Open

Closed

IONET

IONET

SNAS-

DAS IF

SNAS-DAS

Interface

SNAS-

NCCDS IF

SNAS-NCCDS

Interface

Data

Interface

SNAS Data Server

Data

Manager

NCCDS

DAS

SNAS

Data

• Reuse of Applications with Modifications
• Maximize code reuse:
• 25% UPS (of 305K SLOC)
• 75% SWSI (of 200K SLOC)
• Reuse of “logic” for all UPS C code assimilated into SNAS
• Design Features
• Framework provided by current SWSI system for stability and security
• Enhance GUI functionality while providing combined SWSI/UPS menu functionality
• Incorporate UPS functionality for orbital data processing & recurrent scheduling for automated SAR generation
• Include External Processing System (EPS) interface for MOC data exchanges, which enables “lights-out” MOC operations
• Provide Scheduling Workspace for users working “what if” forecast schedules
• Separate O&M client application (better security, remote admin control)
• SNAS/NCCDS interface (SNIF) process rewritten in Java
• New common alert logging package for use by all processes in Client and Servers
• New common data message logging package for use by Client, SNIF and SNAS/DAS interface (SDIF)

* from 452 ICD SN/CSM

* from 452 ICD SN/CSM

* from 452 ICD DAS/SNAS

* from 452 ICD DAS/SNAS

* future 452 ICD EPS/SNAS

SNAS Data Server

Presented By:

David Warren

• SNAS database starting with current SWSI Schema

• Adding UPS tables to support orbital, recurrent scheduling, and EPS

SNAS Closed Server

Presented By:

Hoai Vo

• Maximize SWSI Server code reuse
• Move Database Server Process to separate (3-tier) system
• Rewrite SNIF in Java
• Communications with NCCDS uses XDR protocol
• Log NCCDS input messages after XDR decoding
• Log NCCDS output messages before XDR encoding
• Create and use common alert logging package for all processes, including the client application
• Create and use common NCCDS/DAS message logging package for all processes, including the client application
• Replace SWSI custom HA package
• System Administration functions moved to separate O&M client
• TUT data resident on the Open IONET web server & MOC client

SNAS Client

Presented By:

Helly Maghsoudlou

SNAS Graphical User Interface

Presented By:

Damon Smith

SWSI used as the development base

Selecting inherited features from SWSI or UPS

Maximize code reuse for logic

Minimize development cost while providing full feature functions

UPS Recurrent Schedule logic specifically cited for reuse to provide expected SAR results

Report functions support current MOC systems

SNAS retains UPS EU reporting functions, (request/response protocol & file naming)

Methodology:

SNAS Main Menu illustrates the multi-stage development, arriving at the current solution

Main Menu - SWSI with SNAS Overlay

Main Menu - SWSI/SNAS with UPS Overlay

Main Menu - SNAS Fully Combined

Main Menu - SNAS Optimized

SWSI GUI Flow Illustrated

UPS GUI Flow Illustrated

SNAS Fully Combined GUI Flow

Revisit Main Menu - SNAS Optimized

Proposed Main Menu with Traceability to SWSI and UPS Functions

• The O&M client is separate from MOC client
• Provides electronic client interface between O&M-MOC
• O&M and MOC Client electronic interactions for Mission Data
• SSC data
• Mission User Lists
• Prototype Events
• O&M functions are not distributed for security reasons
• SNAS O&M Positions are: System Administrator, Database Administrator
• O&M Client Functional Segments
• SNAS User Data
• Static Mission Data
• System Maintenance
• System Monitor

Proposed Main Menu with Traceability to SWSI and UPS Functions

• Prototype demonstrated at CIM #3, August 25, 2005
• Currently collecting feedback
• All GUIs will include the following capabilities as a standard: Execute/Transmit/OK/Submit, Print, Save, Duplicate/Clone, Cancel
• The distinction for Simulated or Operational environment is established at login
• A “Simulation” or “Operational” label will appear in a status indicator Main Menu panel
• The Main Menu shown in the prototype includes selections for all MOC positions
• SNAS User positions are: Mission Manager, Mission Scheduler/Planner, Mission Controller, Mission Support, Mission Observer

A Workspace is saved locally for a multi-day building period

Local file sharing for (Orbital Data, Schedule Data, and Reports) supports collective group scheduling

Degraded mode of operations and local off-line building are supported by the Workspace

Graphics pane will include both DAS and NCC schedule data for visual inspection

Visually support combined scheduling for GN and SN resources, with a concept for GN schedules imported as orbital constraint data

The combined tabular and graphical scheduling concept supports drag/drop features between panels

The current graphical scheduling concept contains 20 timelines, so all lines can be viewed in a single pane

Ability to overlay user selected timelines in the graphics pane

Download the Prototype:

• Via the WWW at swsi.gsfc.nasa.gov/hoai
• Request the download password from the SNAS Website

Provide Feedback:

• Via the WWW at snas.gsfc.nasa.gov/
• Enter the “Customer Input” section
• Email at snascusinput@class.gsfc.nasa.gov

Security

Presented By:

Joe Clark

• System Description
• Purpose, status, etc.
• Responsible organization(s) and individuals
• System Architecture
• boundaries
• Interconnections and information sharing and
• Preliminary Risk Assessment
• Technical Controls

• The Space Network Access System (SNAS) is considered a General Support System (GSS)
• Acquisition and Development Phase
• The purpose of the SNAS 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 SNAS is to replace existing scheduling and real-time systems (i.e. SWSI and UPS) for SN customers.
• The SNAS servers and database will be housed with the NCCDS at the White Sands Complex (WSC). Customer access will be through an application running on a customer-provided workstation, which will normally be housed at the Customer’s Mission Operations Center (MOC). Approved mobile workstations, e.g. notebooks, will be used by Customers in an uncontrolled environment in some cases.
• SNAS falls under the WSC security plan

• SNAS Servers and Database
• SNAS Closed IONet Server and Database
• SNAS Database only interconnects with the SNAS Closed IONet Server
• SNAS Closed IONet Server interconnects with
• SNAS Database (directly)
• NCCDS and ANCC through the Closed IONet
• DAS through the Closed IONet
• SNAS Open IONet Server through the NISN Secure Gateway
• SNAS Clients in Customer MOCs through the Closed IONet
• SNAS Open IONet Server
• SNAS Open IONet Server interconnects with
• SNAS Closed IONet Server through the NISN Secure Gateway
• SNAS Clients in Customer MOCs through the Open IONet
• SNAS Clients in Customer MOCs through the Public Internet ***

***Note: Some SNAS Clients may be under the control of a Customer MOC but not physically present in the MOC

• SNAS Clients *
• SNAS Clients on the Closed IONet interconnect with the SNAS Closed IONet server through the Closed IONet
• SNAS Clients on the Open IONet interconnect with the SNAS Open IONet server through the Open IONet
• SNAS Clients on the public Internet interconnect with the SNAS Open IONet server through the public Internet and the Open IONet ***
• SNAS Clients may interconnect with a MOC EPS

*Note the SNAS Client application is a software module that runs on a customer supplied computing platform

*** Note: Some SNAS Clients may be under the control of a Customer MOC but not physically present in the MOC

• The SNAS servers are constrained by
• Rules for interconnecting with the IONet
• Rules for interconnecting through the NISN Secure Gateway
• Limitations of the NCCDS/ANCC interface
• Limitations of the DAS interface
• The SNAS clients are constrained by
• The Customer MOC security program
• Rules for interconnecting with the IONet
• This includes accessing the Open IONet through the public Internet

• SNAS carries the same information as SWSI
• SNAS has the same vulnerabilities as SWSI
• SNAS faces the same threat environment as SWSI
• The SNAS approach to security will be very much like the SWSI approach
• The SNAS servers and database will be housed at WSC
• WSC management policies will apply
• WSC operational policies will apply
• The SNAS clients will be under MOC management
• MOC management policies will apply
• MOC operational policies will apply
• The Technical control provided by SNAS will be the focus of this presentation

• Identification and Authentication
• Logical Access Controls
• Audit Trails
• System and Communication Protection

• All SNAS users will have an established User ID
• Provided to SN O&M personnel by project official
• Determines roles and privileges
• Determines which SIC or SICs can be accessed
• All SNAS users will have a password
• Meets common minimum standards
• Must be changed at least every 90 days
• All SNAS sessions require a passphrase
• Meet common minimum standards for passphrases
• Must be changed at least every year
• All SNAS Client workstations will have a known fixed IP address
• MOC Mission Manager and SNAS Database Administrator will coordinate to maintain currency of SNAS user IDs

• Server OS (Linux/UNIX) limits user access to server and/or database resources
• SNAS defined user roles will support least privilege and separation of responsibilities
• MOC will be responsible for determining how roles are applied
• Attempted unauthorized transactions will not be monitored except for failed login attempts
• User Inactivity will not be monitored by SNAS
• Lights out operation requires that a SNAS terminal be left with an active, unattended session for extended periods of time
• All actions will be logged to an unique User ID
• MOC must ensure
• SNAS workstation is protected when left unattended
• Automatic transactions are safe
• SNAS will provide the MOC with the option of encrypting SNAS files stored locally to the SNAS Client

• SNAS will log
• All message that transit the servers
• Records pertaining to
• Establishment and termination of communications
• System alerts
• Database alerts
• Successful login and logout including Switch User
• Failed login including Switch User
• SN O&M personnel will be able to selectively control logging of messages and records
• SN O&M personnel will be able to selectively delog all logged data
• SNAS will display a 24-hour alert history for
• SNAS clients
• SNAS Database Administrators
• SNAS System Administrators
• Automated tools for monitoring logs will be investigated

• Data on the SNAS servers and the SNAS database is protected by access restrictions
• The SNAS system administrator has access to all data on the SNAS servers and database
• The SNAS database administrator has access to all information in the SNAS database
• SNAS users can only access data
• Using predefined queries and
• Only data related to the specific SIC(s) for which they are authorized
• Unauthorized access is prevented by the Identification and Authentication provisions
• Data stored locally on the SNAS Client is protected by the MOC security plan
• SNAS will provide an encryption option
• Data transported between the SNAS Client and the SNAS Servers will be encrypted

NOTE: “Encryption is required for data that is sensitive, requires confidentiality, has a high value, or would expose NASA to legal liability, criminal sanction, or embarrassment in any way if the information were compromised.”

Architecture Recommendation

&

Development Environment

Presented By:

Scott Robinson

Open

Server

Closed

Server

Data

Server

RAID

Switch

Switch

Heartbeat LANs

Open IONET

Closed IONET

Heartbeat LANs

Heartbeat LANs

RAID

Open

Server

Closed

Server

Data

Server

Inter-segment Network

RAID Network

• Rack mountable servers and peripherals
• Shared monitors, mice, and keyboards with KVM switches
• Dual 64-bit processor capability for each server
• 10/100 Mbps Ethernet for external and heartbeat LANs
• Gigabit Ethernet for Inter-segment Network
• RAID Network (TBD): either Fiber Channel or iSCSI (Copper)
• Tape drives (TBD): either one drive per server or shared network tape drives
• Supports active/passive and active/active clustering

• 3 HP Server Systems
• Configurable-HP ProLiant DL145 AMD Opteron™ - SCSI Rack Model Server
• AMD Opteron™ Model 242 (1.6GHz/1MB) processor
• 1GB of Advanced ECC PC2700 DDR SDRAM DIMM Memory Kit (2 x 512 MB)
• Dual Channel Ultra 320 SCSI HBA
• HP 36.4GB Ultra320 Non-Hot Plug 15,000 rpm (1") Hard Drive
• 16X DVD-ROM Drive
• Two (2) integrated Broadcom 5704 10/100/1000 Ethernet NICs w/WOL and PXE support
• 500W power supply (non-hot plug, auto-switching)
• 6 HP Workstations
• Same as above except in Tower Model

• UPS and SWSI Code analyzers for mapping current logic and reverse engineering
• Understand for C++
• Understand for Java
• With Class 2000 Professional
• GUI Builders and Code outline generators
• JBuilder
• Eclipse
• With Class 2000 Professional
• Configuration Management
• Concurrent Versioning System (TBR)
• Red Hat Enterprise Linux AS Standard (AMD64/Intel EM64T)

SNAS Software Size Estimate

Presented By:

Chii-der Luo

• Client
• All SWSI Client code written in Java
• Over 92% of SWSI Client code reusable
• About 3,260 lines of new DSI to be developed for SNAS Client
• Server
• SNIF logic will be reused and code implemented in Java for SNAS
• Remaining SWSI Server code is written in Java language
• Reuse percentage: 70%
• About 39,130 lines of new DSI necessary for SNAS Servers, including SNIF rewrite

• UPS GUI was developed with TAE+ and will not be reused
• Majority of remaining UPS code is in C programming language
• Major subsystem logic reuse
• Recurrent Scheduling
• Orbital Data Processing
• Electronic User
• User Input Validation
• About 67,910 lines of new Java DSI to be written for implementing select UPS functions on SNAS

• SNAS GUI will be written in Java with an estimated size of about 64,020 DSI
• Software tools such as Eclipse and JBuilder will be used to build GUI graphics
• Estimated SNAS software size:

3,260 – from SWSI Client (SNAS Client)

39,130 – from SWSI Server (SNAS Servers)

67,910 – from UPS (SNAS Client & Servers)

64,020 – SNAS GUI

95,130 – Reused SWSI code

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

269,450 – SNAS Software DSI

New Code

• Estimation: COCOMO II Post-Architecture model
• Software size used in the calculation: 142,310 lines of new DSI
• Range of effort in person-month (PM): 223 to 349

Transition

FTE

Code

CDR

Design

Test

Risks & Mitigation

Presented By:

Dave Warren

• SNAS Risk Type # Risks Severity Range
• Customer Support Related 6 Low - High
• DAS 2 Med - High
• Mgmt 1 Low
• Security 2 Low
• System 3 Low

L

I

K

E

L

I

H

O

O

D

Very High 5

High 4

Moderate 3

Low 2

Very Low 1

Criticality

High

Medium

Low

CONSEQUENCES

1 2 3 4 5

Very Low Moderate High Very

Low High

SNAS Risk Classification Chart

3

6

11

5

Note:

 = SNAS Risk #’s

• Risk # 03 – Interface between Customer Critical Activities & SNAS Test Schedule
• Risk: Customer lack of availability to test with SNAS due to other high priority customer activities or implementation issues at the customer site could delay the completion of SNAS interface testing.
• Likelihood: 3 Consequence: 4 Timeframe: Testing
• Approach & Plan:
• Identification of potential customers that will be involved in the SNAS test program will be identified early.
• Tests that are key to validating SNAS functionality versus those that can be completed as a customer post-SNAS transition activity will also be identified.
• The SNAS staff will regularly communicate with customers and will request a commitment from those agreeing to participate during the SNAS test period.
• Test and transition activities will be designed to minimize impact on Customer resources and schedule.
• Status:
• Open: advertising schedules through notifications; and CIM’s; missions signing up for beta-testing

• Risk # 11 – Lack of a DAS Test Interface
• Risk: The lack of an activity to design and prototype a Demand Access System (DAS) Simulator will put the development of the interface between SNAS and DAS at very high risk. As seen with the current SWSI sustaining engineering environment, developers cannot adequately verify reported DAS user problems or resolve contributing software errors because a DAS interface is unavailable.
• Likelihood: 2 (4) Consequence: 4 Timeframe: CDR
• Approach & Plan:
• A DAS Simulator would mitigate the risk for the need of this direct interface.
• The team will continue to monitor the status of the NASA's review of the current WSC DAS upgrade activities and the decisions for provision of a backup system to determine the need/implementation of a DAS simulator for SNAS testing.
• Status:
• Open: the WSC DAS team currently working towards a Release 05.1 for Oct. ’05; SWSI has limited access to the WSC DAS Testbed to investigate functionality and verify open SWSI-DAS problem reports

• Risk # 5 – Customer Liaison and System Acceptance
• Risk: Conflicting design issues may result in a system that doesn’t meet desired customer expectations
• Likelihood: 1 (3) Consequence: 2 Timeframe: PDR
• Approach & Plan:
• The Customer Liaison Plan will be utilized to achieve customer participation in all phases of development to mitigate a lack of user input and feedback.
• The design will include those requirements where the majority of the user community agrees that the functionality is necessary.
• Customer inputs will be balanced against reasonable cost and time considerations.
• Status:
• Open: meetings held at customer sites; held three group CIMs to keep future SNAS users abreast of requirement changes and design, especially in the GUI functionality

• Risk # 6 – SN Customer Transition from UPS and SWSI to SNAS
• Risk: An ineffective transition from UPS and SWSI to SNAS could potentially impact SN customer service support.
• Likelihood: 2 (3) Consequence: 4 Timeframe: Transition
• Approach & Plan:
• A period of time for transitioning SN customers from UPS and SWSI to SNAS has been provided in the schedule.
• The SNAS system engineering support contractor will develop a plan early during SNAS development to facilitate a smooth transition.
• The Customer Liaison Plan will be utilized to achieve customer participation in all phases of development to mitigate a lack of user input and feedback.
• Status:
• Open: keeping customers aware of schedule and development through sitemeetings and CIM’s

Closing Remarks

Presented By:

Rose Pajerski

• Accept Mod for new Task Order and begin critical design
• Continually assess potential impacts to requirements & design
• Continue supporting the Customer Liaison Program
• Hold CDR in late April 2006
• Adjust baseline schedule

41% increase in functional size

Anticipate <10% increase in functional size

• Sources of potential impacts
• Results from RFA actions
• Functional and subsystem requirement changes
• Evolving SN and mission operational needs
• Assess impacts
• Track identified changes as risks
• Estimate “size” of change using function point analysis
• Factor changes into requirements, implementation plan, and schedule
• Functionality change analysis (ongoing)
• Use recently baselined requirement & preliminary design materials
• Analyze function point counts to calculate growth
• 760 FPs (initial count in 2003)
• 1074 FPs (prior Delta-SRR in 2005)
• ? FPs (after this PDR)
• Factor into schedule and effort estimates

Revised Original

ScheduleSchedule

• CDR #1 --- 12/2005
• CDR #2 4/2006 5/2006
• Implementation 2/2007 11/2006
• System Test 5/2007 1/2007
• Acceptance Test 7/2007 3/2007
• Training & Transition to Ops 11/2007 7/2007

***Note: Beta testing to begin early 2007

• Respond to RFAs
• Existing: 9 deferred to design phase (from July 2003 SRR)
• New from today’s review
• Refine hardware architecture proposal
• Finalize project documentation for CDR
• Security Plan
• ICD between DAS and SNAS
• ICD between EPS and SNAS
• Draft Detailed Design Specification
• Configuration Management Plan
• System Test Plan
• Acceptance Test Plan

• Closing remarks from review board
• Thanks for your attendance
• RFA due date, September 16 (PAAC II)
• See you at the CDR in April

Backup Slides

Acronym and Abbreviation List

Requirement Traceability Matrix

SNAS COCOMO II Model Cost Drivers

BAH Booz, Allen, Hamilton

CA Certificate of Authority

CDR Critical Design Review

CIM Customer Interface Meeting

CLP Customer Liaison Plan

CNE Center Network Environment

COCOMO Constructive Cost Model

COTS Commercial-Off-the-Shelf

DAS Demand Access System

DBMS Database Management System

DSI Delivered Source Instruction

EPS External Processing System

EU Electronic User

FTP File Transfer Protocol

FP Function Points

GCM Ground Control Message

GCMR Ground Control Message Request

GMSEC GSFC Missions Services Evolution Center (Code 581)

GUI Graphical User Interface

HTSI Honeywell Technology Solutions Inc.

HTTP Hypertext Transfer Protocol

ICD Interface control Document

IIRV Improved Inter Range Vector

IONet Internet Protocol Operational Network

IT Information Technology

ITT ITT-SNAS System Engineering Contractor

JSC Johnson Spaceflight Center

MOC Mission Operations Control

NASA National Aeronautics and Space Administration

NCCDS Network Control Center Data System

NENS Near Earth Networks Services

NISN NASA Integrated Services Network

NPOESS National Polar-orbiting Operational Environmental Satellite System

O&M Operations and Maintenance

OCD Operations Concept Document

PAAC-II Program Analysis and Control

PDR Preliminary Design Review

PE Prototype Event

PSAT Predictive Satellite Acquisition Table

RCTD Return Channel Time Delay

RR Replace Request

RV Requirement Volatility

SAR Schedule Add Request

SCP Space Communications Program

SDIF SNAS DAS Interface

SDR Schedule Delete Request

SHO Schedule Order

SIC Spacecraft Identification Code

SN Space Network

SNAS Space Network Access System

SNIF SNAS NCCDS Interface

SP Security Plan

SP&M Special Projects and Missions

SPSR Service Planning Segment Replacement

SRD Systems Requirement Document

SRM Schedule Result Messages

SRR System Requirements Review

SRR Schedule Result Request

SSC Service Specification Code

SSL Secure Socket Level

SUPIDEN Support Identifier

SV State Vector

SWSI Space Network Web Services Interface

TAE Transportable Application Executive

TCP/IP Transmission Control Protocol/Internet Protocol

TCW TDRSS Communications Window

TDRSS Tracking and Data Relay Satellite System

TRMM Tropical Rainfall Measuring Mission

TSW TDRSS Satellite Window

TTM Time Transfer Message

TUT TDRSS Unscheduled Time

UAV User Antenna View

UPD User Performance Data

UPS User Planning System

WSC White Sands Complex

UPDR User Performance Data Request

UPS User Planning System

USM User Scheduling Message

WLR Wait List Request

SNAS COCOMO Modeling Scale Factors

Note: Refer to COCOMO II Model Definition Manual for details on features and ratings

SNAS COCOMO Modeling Effort Multipliers

Note: Refer to USC COCOMO II Reference Manual for details on features and ratings