# Presentation: 270268

## Space Network Access System (SNAS) Preliminary Design Review

**September 12, 2005**
***NASA Code 452 ***
***Space Network (SN) Project***

## PDR Agenda

**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**

## Welcome/Purpose of Review

**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**

## Review Board

**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**

## Review Process

**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**

## Organizational Chart

## SNAS Team 

**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**

## System Requirements Status

**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 **

## System Requirements Status (cont)

**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**

## Documentation

**System Requirements Document****	****CCB approved**
**System Operations Concept Document****	**** CCB approved**
**Security Plan****	**** 2****nd**** draft in development**
**System Test Document****	****1****st**** draft in development**
**Acceptance Test Document****	**** 1****st**** 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

**SNAS Design Approach**

- Presented By:
**Damon Smith**

## Customer Centric Design

**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**

## Customer Centric Design (cont)

**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**

## Functional Wish List (1 of 4)

**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.**

## Functional Wish List (2 of 4)

**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.**

## Functional Wish List (3 of 4)

**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.**

## Functional Wish List (4 of 4)

**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

**System Overview**

- Presented By:
**David Warren**

## Current SWSI System Architecture

## Proposed SNAS System Architecture

## SNAS Notional Reference Architecture

## Key Design Concepts

**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) **

##  SNAS Context Diagram 

##  SNAS Context - Internal

##  SNAS Data Transfers – NCCDS Scheduling (Ref. 1)

** ****SNAS Data Transfers – ****NCCDS Scheduling (Ref. 1)**

** from 452 ICD SN/CSM*

##  SNAS Data Transfers – NCCDS Real-time (Ref. 2)

** from 452 ICD SN/CSM*

##  SNAS Data Transfers – DAS Scheduling (Ref. 3)

** from 452 ICD DAS/SNAS*

##  SNAS Data Transfers – DAS Real-time (Ref.  4)

** from 452 ICD DAS/SNAS*

##  SNAS Data Transfers – External Processing System (Ref. 5)

** future 452 ICD EPS/SNAS*

## System Data Flow

## Diagramming Conventions

## SNAS Data Server

**SNAS Data Server**

- Presented By:
**David Warren**

## Data Server Context

## Data Server Level 1

## Data Server Level 2

## Database Components - SWSI

**SNAS database starting with current SWSI Schema**

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

## Database Components - UPS

## SNAS Closed Server

**SNAS Closed Server**

- Presented By:
**Hoai Vo**

## SNAS Server Key Points

**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 Server Level 1

## Server Context Connection Manager

## Server Level 2 Connection Manager

## Server Context Message Router

## Server Level 2 Message Router

## Server Context SNAS-DAS Interface (SDIF)

## Server Level 2 SNAS-DAS Interface (SDIF)

## Server Context SNAS-NCCDS Interface (SNIF)

## Server Level 2 SNAS-NCCDS Interface

## SNAS Client

**SNAS Client**

- Presented By:
**Helly Maghsoudlou**

## Client Context

## Client Level 1

## Client Level 2  Graphical User Interface

## Client Level 2EPS Interface

## Client Level 2 Transaction Processor 

## Client Level 3  Single Transaction Processor 

## Client Level 3  Bulk Transaction Processor 

## Client Level 3 Recurrent Transaction Processor

## Client Level 2 Client Data Manager

## Client Level 3Connection to Server

## Client Level 2 Workspace Saver / Restorer 

## SNAS Graphical User Interface

**SNAS Graphical User Interface**

- Presented By:
**Damon Smith**

## GUI Prototype Design Principles

**Assumptions:**
**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 MOC Client Main Menu

**Proposed Main Menu with Traceability to SWSI and UPS Functions**

## Prototype Demo Preface

**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 O&M Client Main Menu

**Proposed Main Menu with Traceability to SWSI and UPS Functions**

## Prototype Demo Preface

**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**

## Advanced Workspace and Scheduling Concepts

**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**
**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**

## SNAS GUI Prototype Download

**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**

## SNAS GUI Prototype

## Security

**Security**

**Presented By:**
**Joe Clark**

## Outline

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

## System Description

**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 Security Architecture

## SNAS System Boundaries

## SNAS Server Interconnectivity

**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 Client Interconnectivity

**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

## Constraints on Information Sharing

**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**

## Preliminary Risk Assessment

**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**

## Technical Controls

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

## Identification and Authentication

**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**

## Logical Access Controls

**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**

## Audit Trails

**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**

## System and Communication Protection

**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

** ****Architecture Recommendation**
**&**
**Development Environment**

**Presented By:**
**Scott Robinson**

## Architecture Recommendation

- Open
- Server

- Open
- Server

- Closed
- Server

- Closed
- Server

- Data
- Server

- Data
- Server

- Heartbeat LANs

- Heartbeat LANs

- Heartbeat LANs

- Open IONET

- Closed IONET

- Switch

- Switch

- RAID

- RAID

- RAID Network

- Inter-segment Network

## Architecture Recommendation (cont)

**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**

## Development Environment - Hardware

**3 HP Server Systems**
**Configurable-HP ProLiant DL145 AMD OpteronTM - SCSI Rack Model Server **
**AMD OpteronTM 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 **

## Development Environment - Software

**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

** ****SNAS Software Size Estimate**

**Presented By:**
**Chii-der Luo**

## SWSI Software Reuse Analysis

**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 Software Reuse Analysis

**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

**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**

**SNAS Software Size Estimate**

**New Code**

## Development Resource Estimate

**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**

- FTE

- Design

- Code

- Test

- Transition

**CDR**

##  Risks & Mitigation

** ****Risks & Mitigation**

**Presented By:**
**Dave Warren**

## Risks & Mitigation (1 of 6)

**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**

## Risks & Mitigation (2 of 6)

***SNAS Risk Classification Chart***

**Note:**
** ****= SNAS Risk #’s**

**11**

**3**

**5**

**6**

## Risks & Mitigation (3 of 6)

**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**

## Risks & Mitigation (4 of 6)

**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**

## Risks & Mitigation (5 of 6)

**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**

## Risks & Mitigation (6 of 6)

**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 site**** ****meetings and CIM’s**

## Closing Remarks

**Closing Remarks**

**Presented By:**
**Rose Pajerski**

## Next Steps

**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**

## Assess System Impacts

**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**

## Schedule

**	****	****Revised ****	****Original**
**	****	**_**Schedule**_**	**** **_**Schedule**_
**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

## Post PDR Activities

**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**

## In Closing

**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

** ****Backup Slides**
- Acronym and Abbreviation List
- Requirement Traceability Matrix
- SNAS COCOMO II Model Cost Drivers

## Acronym and Abbreviation List (1 of 2)

- ANCC	Auxiliary Network Control Center
- 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

## Acronym and Abbreviation List (2 of 2)

- RFA		Request For Action
- 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

## Requirement Traceability Matrix (1 of 6)

**Requirement Traceability Matrix ****(1 of 6)**

## Requirement Traceability Matrix (2 of 6)

**Requirement Traceability Matrix ****(2 of 6)**

## Requirement Traceability Matrix (3 of 6)

**Requirement Traceability Matrix ****(3 of 6)**

## Requirement Traceability Matrix (4 of 6)

**Requirement Traceability Matrix ****(4 of 6)**

## Requirement Traceability Matrix (5 of 6)

**Requirement Traceability Matrix ****(5 of 6)**

## Requirement Traceability Matrix (6 of 6)

**Requirement Traceability Matrix ****(6 of 6)**

## 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