RFIMS-SE-PLN-16-V_1.0.pdf

Radio Frequency Interference Monitoring System (RFIMS)

Mission Assurance Plan (MAP)

Version 1.0

December 12, 2016

U.S. Department of Commerce (DOC) National Oceanic and Atmospheric Administration (NOAA) National Environmental Satellite, Data, and Information Service (NESDIS)

RFIMS Mission Assurance Plan RFIMS-SE-PLN-16

CHANGE RECORD

DOCUMENT TITLE: RFIMS Mission Assurance Plan

VERSION DATE PAGES AFFECTED DESCRIPTION

0.1 November 2, 2016 All Initial draft release

0.2 November 25, 2016 All Reformatting, new content

0.5 December 5, 2016 All Incorporated feedback from team

1.0 December 12, 2016 All Baseline version release

The document version number identifies whether the document is a working copy, final, revision, or update, defined as follows:

• Working copy or Draft: a document not yet finalized or ready for distribution; sometimes called a draft. Use 0.1A, 0.1B, etc. for unpublished documents.

• Final: the first definitive edition of the document. The final is always identified as Version 1.0.

• Revision: an edition with minor changes from the previous edition, defined as changes affecting less than one-third of the pages in the document. The version numbers for revisions 1.1 through 1.9, 2.1 through 2.9, and so forth. After nine revisions, any other changes to the document are considered an update. A revision in draft, i.e. before being re-baselined, should be numbered as 1.1A, 1.1B, etc.

• Update: an edition with major changes from the previous edition, defined as changes affecting more than one-third of the pages in the document. The version number for an update is always a whole number (Version 2.0, 3.0, 4.0, and so forth).

Table of Contents

1. Introduction

1.1. Purpose and Scope

1.2. System Overview

1.3. Applicable and Reference Documents

2. Mission Assurance Process

2.1. Definitions and Terms

3. Roles & Responsibilities for Mission Assurance

3.1. Project Manager

3.2. Mission Assurance Team

3.3. Independent MA Authority

3.4. Vendor Mission Assurance Team

4. Mission Assurance Tasks

4.1. Document Review

4.2. Quality System Evaluation

4.3. Problem Reporting

4.4. Risk Management

4.5. Quality Assurance

4.5.1. Project Assurance

4.5.2. Design Assurance

4.5.3. Software Assurance

4.5.4. Manufacture and Build Assurance

4.5.5. Integration, Test and Evaluation (IT&E) Assurance

4.5.6. System Safety

5. Project Life Cycle and Decision Gates

6. Mission Assurance Baseline Tool

6.1. Tailoring the Mission Assurance Baseline

6.2. Deploying/Executing the MAB

Appendix A: Acronym List

Table of Figures

Figure 1: Notional High-Level RFIMS Architecture Figure 2: RFIMS Mission Assurance Organization Figure 3: RFIMS Life Cycle Phases Figure 4: RFIMS MA Processes over Project Life Cycle Figure 5. Mission Assurance Baseline Example

1. Introduction

1.1. Purpose and Scope

Mission Assurance is the disciplined application of integrated systems engineering, quality, and management principles towards the goal of achieving mission success.

The role of Mission Assurance is to provide objective reviews and audits of project activities and products to ensure their compliance with the applicable processes, standards, and procedures. By using disciplined and controlled processes during the design, test, and acceptance of RFIMS, risk of inadequate performance or failure is reduced.

This Mission Assurance Plan (MAP) has been developed to insure that all aspects of the RFIMS Project lifecycle are tracked and all activities supporting the various necessary functions are documented and completion is verified by the RFIMS Project team.

This Mission Assurance Plan is a roadmap that identifies all the tasks and associated responsibilities necessary to successfully complete the design, test, and acceptance of the RFIMS Project. The RFIMS Project will use the Mission Assurance Baseline (MAB) as a tool to support Mission Assurance activities.

This tool tracks tasks that form a framework for activities identified as necessary to successfully complete

RFIMS.

Mission Assurance is conducted during all phases of the project life cycle. It focuses on development processes and outputs to deliver a system ready for use in an operational environment. The MAP should align with the respective acquisition phases and the decision gate reviews. Additionally, cross-cutting activities for Mission Assurance include document review, quality system evaluation, problem reporting, risk management, and quality assurance (QA).

This MAP covers the Government RFIMS Project actions throughout the formulation and implementation phases of the project life cycle; once on contract, it will link to the actions of the development Vendors.

The RFIMS Small Business Innovative Research (SBIR) project is out of scope for the MAP. Further, some of the Non-Recurring Engineering (NRE) Activities such as site surveys occurred prior to the existence of a formal Mission Assurance process for RFIMS.

1.2. System Overview

NOAA manages and operates the Nation's operational environmental satellites through its NESDIS Office.

NESDIS provides timely access to global environmental data from satellites to promote, protect and enhance the Nation's economy, security, environment and quality of life. NESDIS operates a variety of satellite constellations in the L-Band, S-Band, and X-Band frequencies from multiple Federal earth stations across the United States. These frequencies are used to command satellites as well as to receive state of health and mission data from the satellites.

In March 2014, the FCC updated Title 47 Code of Federal Regulations (47 CFR) to reflect the 1695-1710 megahertz (MHz) band is occupied by both meteorological satellites and fixed mobile communications and wireless communications. It states that if protected Federal operations receive harmful interference from Advanced Wireless Service-3 (AWS-3) operations in the 1695-1710 MHz band, the AWS-3 licensee(s) must, upon notification, modify their operations and/or technical parameters as necessary to eliminate the interference. Coordination procedures for the 1695-1710 MHz band are published jointly by the

Federal Communications Commission (FCC) and the National Telecommunications and Information Administration (NTIA) via public notices. Public Notice 14-1023 provides guidance for how the licensees will coordinate with Federal operators, both formally and informally, to avoid interference.

This spectrum sharing agreement represents the first time the Federal Government will share the same frequencies with non-Federal users. The licensee, or wireless carrier, may use the 1695-1710 MHz band for uplink communications only from the user equipment (UE), to its network base station on a non-interference basis only. If UE uplinks are active while a NOAA earth station is receiving a satellite downlink signal from its meteorological satellites, the UE signal(s) may interfere with or degrade the NOAA downlink signal.

The DOC Transition Plan lists each of the 17 NOAA Federal earth stations, the satellite receive equipment being protected, and indicates that the transition timeline for spectrum sharing is 39 months after Auction 97 ended in January 2015.

The purpose of the RFIMS is to support the sharing of spectrum between Federal incumbent users and commercial wireless Long-Term Evolution (LTE) licensees. The RFIMS will be used to monitor the frequency environment and ensure there is no harmful interference to NOAA users. Figure 1 depicts a notional high-level RFIMS architecture.

Figure 1: Notional High-Level RFIMS Architecture

The RFIMS must monitor the integrity of the signal of interest at the receiver, as well as the overall spectrum environment at the receive location, to detect the presence of interfering signals. To do this, the system must perform the four basic monitoring functions: detect, classify, and identify the source of the interference, as well as, notify NOAA and the wireless carriers of said interference. Monitoring will continue in order for the government operator to verify that the wireless carriers have mitigated the interference.

A detailed description of the functional capabilities are as follows:

• Detect - The system should detect, in real-time, “events” in which the interference level lies at or above -10 dB Interference-to-Noise Ratio (INR) during NOAA’s earth station downlink reception.

• Classify - The system should classify, in real-time, the nature of RF interference. Where “classify” is the discrimination between 1695 – 1710 MHz LTE UE uplink signals and all other radio frequency interference (RFI) such as background impulsive noise and out-of-band emissions from other RF sources.

• Identify - If the system determines the RFI is related to 1695 – 1710 MHz LTE UE uplink signal, then the system should identify the source(s) of interference in real-time or as near to real-time as possible.

• Notify - The system should notify NOAA operators, and the wireless carriers, that wireless carriers are creating interference to NOAA.

RFIMS at the NOAA earth station forwards information in real-time to a central node which will likely be co-located at one of the Federal earth stations. The central node is responsible for monitoring the data collected at each of the 17 locations, and reports status and interference information to wireless carriers and NOAA offices responsible for enforcing the spectrum sharing agreement.

1.3. Applicable and Reference Documents

The MAP has been developed in compliance with the following applicable documents.

Document Number Document RFIMS-SE-PLN-13 RFIMS Systems Engineering Plan (SEP)

The following reference documents, specifications, and standards were used to draft this plan. They contain additional clarifying information and details in the application of Mission Assurance for RFIMS.

Document Number Document RFIMS-SE-PLN-14 RFIMS Test and Evaluation Master Plan (TEMP) OSGS 5820.01A OSGS Systems Engineering Process Document NASA NPD 8730.5 National Aeronautics and Space Administration (NASA) Quality

Assurance Program Policy NASA NPR 8735.2A Management of Government Quality Assurance Functions for NASA

Contracts AS9100 Quality System Requirements – Aerospace Requirements ANSI/EIA 649 National Consensus Standard for Configuration Management, 04

October 2004 ANSI/EIA 748 Earned Value Management Systems, 28 August 2002 EIA HEB-1 Human Engineering – Principles and Practices, 02 June 2002 EIA 632 Processes for Engineering a System, TechAmerica Standard, January

ISO 9241-1 Ergonomic requirements for Office Work with Visual Display terminals

(VDTs), 01 June 1997 MIL-STD-1521B Technical reviews and Audits for Systems, Equipment, and Computer

Software, 04 June 1985 NIST Special Publication 800-53

Security and Privacy Controls for Federal Information Systems and Organizations, Revision 4, April 2013

CFR-47 U.S. Code of Federal Regulations, Title 47, Chapter I, Subchapter B, Part 27, http://www.ecfr.gov

Document Number Document DA-14-1023 FCC and NTIA: Coordination Procedures in the 1695-1710 MHz and

1755-1780 MHz Bands, Public Notice; 18 July, 2014, https://apps.fcc.gov/edocs_public/attachmatch/DA-14-1023A1.pdf

DOC NOAA, Transition Plan for the 1695-1710 MHz Band, 12 August, 2014 https://www.ntia.doc.gov/files/ntia/publications/doc_noaa_web-ready_1jul14_final_rev7_admin_chng.pdf

2. Mission Assurance Process

2.1. Definitions and Terms

Specific Mission Assurance terms and concepts used in this plan are documented here.

Mission Assurance (MA) is defined as the disciplined application of general systems engineering, quality, and management principles towards the goal of achieving mission success, and, toward this goal, provides confidence in its achievement. MA focuses on the detailed engineering of the acquired system and, towards this objective, uses independent technical assessments as a cornerstone throughout the entire concept and requirements, design, development, production, test, deployment, and operations phases.

Mission Assurance Baseline (MAB) is a tool containing a configuration-controlled set of tasks performed to increase confidence toward the goal of achieving mission success for the RFIMS ground components.

The set represents activities for all MA activities across all acquisition and mission phases, believed to be practically executable within the scope and constraints to meet the specific needs of the RFIMS program.

Mission Assurance Plan (MAP) provides a structured and consistent communication of Project Office support, customer set, and senior management as well as serve as guidance to the personnel in the Project Office. The MAP documents the Project’s risk posture consistent with the mission (e.g., operation or experimental), identifies MA technical command media (e.g., tailoring of required specifications and standards) as contractual requirements, and clearly communicates Project Office accountabilities and defines MA responsibilities. The MAP also identifies those aspects of the Project that will not be assessed.

Mission Assurance Verification is primarily focused on the identification, tailoring, and assessment of sets of tasks related to MA processes and disciplines. The identification and tailoring activities have the objectives of selecting and refining from a generic, comprehensive set of possible MA tasks, a tailored set that is believed to be practically executable within the scope and constraints of the RFIMS program.

Mission Assurance Process is a series of tasks, involving the practical application of accepted principles, which are architected and organized in logical sequence to achieve a broad set of objectives. MA processes contribute to Mission Success in terms of directly attributable positive consequences.

A supporting MA discipline (SMD) is an engineering discipline that is specifically oriented and organized to support MA processes and the entire MA program. Because of practical constraints on resources available to a specific program, such support is often limited to a partial, rather than complete, application of the discipline within the MA program itself. The following is a list of the nominal MA disciplines.

• Risk Assessment and Management

• Reliability Engineering

• Configuration Management (CM) https://apps.fcc.gov/edocs_public/attachmatch/DA-14-1023A1.pdf https://www.ntia.doc.gov/files/ntia/publications/doc_noaa_web-ready_1jul14_final_rev7_admin_chng.pdf https://www.ntia.doc.gov/files/ntia/publications/doc_noaa_web-ready_1jul14_final_rev7_admin_chng.pdf

• Parts, Materials, and Processes (PMP) Management

• Quality Assurance (QA)

• Systems Safety Assurance

• Software Assurance

• Information Assurance (IA)

Assessment is a systematic gathering of information about something to evaluate or estimate its nature, quality, ability, extent, or significance.

Audit is a review of the Vendor’s, or subcontractor's documentation, software or hardware to verify that it complies with project requirements.

Surveillance gains knowledge of Vendor performance through continuous independent assessment of processes. Methods also use product performance requirements and performance metrics to ensure process capability, product quality, and end-item effectiveness. It relies on gathering a minimum set of product or process data that provides adequate visibility into the integrity of the product or process. The data will be acquired from Vendor records in a non-intrusive method. Additionally, it relies heavily on evaluation planned deliverables, technical reviews, and existing Vendor procedures and working documents.

Inspection is the process of measuring, examining, gauging, or otherwise comparing an article or service with specified requirements.

Metrics are measurements that will be collected, reported and maintained; those associated with Mission Assurance might include the number of assessments (planned vs. actual), the number of risks identified from an assessment, the number of peer reviews, the number of open vs. closed action items from a review, etc.

3. Roles & Responsibilities for Mission Assurance

3.1. Project Manager

The RFIMS Project Manager has the responsibility for the successful development and deployment of the RFIMS to the NOAA earth stations locations identified in the AWS-3 Auction Coordination Procedures. The Project Manager has visibility into the Mission Assurance activities and processes in place for RFIMS.

3.2. Mission Assurance Team

The Mission Assurance team is comprised of members from the RFIMS Project Team and Aerospace, a Federally Funded Research and Development Center (FFRDC). The FFRDC members maintain a level of independence from the Project and the Vendor quality team.

The MA Team is responsible for supporting the Project Manager for coordination, definition, and implementation of the Project Mission Assurance Program. They provide the PM with insight into the processes being using by the Vendors and the quality of the products being built. The team identifies key processes, products, documents, records, mandatory inspection points, and performance characteristics requiring Government assurance actions. They continuously evaluate the adequacy of surveillance and support.

The team meets on a monthly basis to review tasking and update the MAB. They track and analyze MA metrics and generate reports for the PM and the Independent MA Authority.

3.3. Independent MA Authority

To maintain independence from the RFIMS Project Manager, the RFIMS Mission Assurance team also has a reporting chain to the OSGS Systems Engineering Division Chief, as shown in Figure 2. The team will report on MA status and any anomalies or audit results. As needed, they will have ad-hoc meetings. Risk escalation begins at the RFIMS Project level and extends to OSGS as necessary.

Figure 2: RFIMS Mission Assurance Organization

3.4. Vendor Mission Assurance Team

The Vendors will conduct MA activities of their development project. In addition to performing their MA processes and tasks, they will support the RFIMS MA team as needed. This could include providing audit results, metrics, and evaluation reports.

As described in the SOO, the Vendors are expected to use a minimum of Capability Maturity Model Integration for Development Level 3 Certification, demonstrating compliance with maturity standards and methodologies for development of products and services in a repeatable and consistent high-quality manner. Additionally, they are required to have a minimum of International Organization for Standardization (ISO) 9001 Certification, demonstrating a quality management system to meet NOAA requirements.

The Vendors will follow the RFIMS Quality Assurance Surveillance Plan (QASP) and will create a Quality Control Plan (QCP) tailored for RFIMS. The QASP identifies product/service requirements and performance standards for ensuring contract performance, and as such, can vary from those surveillance activities identified in this Mission Assurance Plan.

OSGS

Resources Support Division PETD

Systems Engineering Division Division Chief

RFIMS Project Project Manager

Mission Assurance Team

4. Mission Assurance Tasks The following activities are the primary MA tasks that cross the boundaries of the acquisition phases. They are identified in the RFIMS MAB and can be tracked across the acquisition phases as required as individual activities are completed and the respective artifacts are collected and verified.

4.1. Document Review

Mission Assurance will participate in document reviews of formal deliverables and project plans.

Inspections, assessments, or audits will be recommended when trends indicate compliance issues with the policies, procedures, and standards.

4.2. Quality System Evaluation

The MA team will evaluate the Vendor’s quality system primarily through surveillance to assure compliance with documented quality requirements. Vendor quality data, including anomaly reports will be reviewed to identify problem areas. Formal evaluations or audits may be needed when trends indicate oversight. Typical evaluation area include:

• Control of records

• Internal audit

• Training and certification

• Rework/repair workmanship

• Inspection

• Communications

• Calibration

• Monitoring and control of process

• Non-conforming product control

• Problem reporting

• Continual improvement

4.3. Problem Reporting

When issues (problems or audit nonconformance) are identified by the Mission Assurance team, they will be tracked and monitored to resolution. Corrective action requests will be reviewed and status reported on a regular basis until completion. The metrics of action items and problems will be tracked as well.

4.4. Risk Management

Risk identification and management/mitigation at all stages of the life cycle is vital. The MA team will apply a risk-based approach to surveillance and will generate risks based on their findings. These risks will be managed in accordance with the OSGS System Engineering Division Risk, Issues, and Opportunity Management Process Document and the RFIMS Risk Management approach, described in the Systems Engineering Plan.

4.5. Quality Assurance

QA is the engineering and management specialty discipline that implements the planned and systematic activities in a quality system so that quality requirements for a product or service will be fulfilled. QA activities support many other disciplines such as reliability engineering, configuration management (CM), parts, materials, and process engineering, safety engineering, systems engineering, manufacturing and test engineering, purchasing, and systems integration and test.

4.5.1. Project Assurance

The goal of project assurance is to establish and control a project delivering the required capabilities within the allocated budget and schedule at acceptable risk. In simple terms, project assurance is aimed at appropriately balancing desired/required technical performance within cost, schedule, and risk constraints. In this sense, it expands the meaning of “mission success” to include meeting cost and schedule objectives in addition to system performance.

4.5.2. Design Assurance

Design assurance supports “design-to-test” by ensuring that appropriate design integration and verification is planned and performed. Test equipment and processes should be shown adequate in providing results that validate design requirements. Not only must the physical aspects of test processes be examined (e.g., harness connection into the proper socket), but also how the results of tests are processed and how they are related to and validate design requirements.

Design assurance supports the maintenance and logistics support functions by ensuring that the design, once produced, can be maintained. This is especially true of software where long-term maintenance costs can far exceed the cost of the initial design phase. An example from the hardware side might be the consideration of whether or not component parts are likely to become obsolescent before committing to a particular design.

Trades against different solutions should consider how handling and support equipment, test and checkout equipment, logistics support, sparing, facilities, and the maintenance operations concept will be accommodated. This also includes verifying that support equipment meets reliability and mean-time-to-repair (MTTR) requirements.

4.5.3. Software Assurance

Software assurance is the planned and systematic set of activities that ensure that software life cycle processes and products conform to requirements, standards, and procedures. The surveillance activities include:

• Conduct scheduled and unscheduled software audits

• Assess software reports and data and establish the degree of conformance to standards

• Assure reviewed documents and tested software is the current and correct version

• Assure adherence to design standards and all software requirements are allocated to software design components

• Assure procedures for non-conformance reporting and corrective action follow up are working properly

4.5.4. Manufacture and Build Assurance

The objectives of manufacturing assurance are (1) to ensure the manufacturing processes are able to produce hardware and that meets the design requirements and (2) to translate the design into a reliable, durable manufactured item using manufacturing processes that are highly repeatable and error free.

Consistent, reliable, and repeatable manufacturing processes improve hardware quality and reduce the potential for escapes, thereby improving mission success.

During conceptual design and preliminary design phases, the objective of manufacturing assurance is to influence the design process from the perspective of hardware production. Based on an understanding of proven manufacturing processes, technologies, and practices, the objective is to design hardware that satisfies the functional and design intent while optimizing ease and economy of fabrication. At the end of the preliminary design phase, manufacturing assurance further ensures that there is a qualified supply chain and further verifies that acceptance criteria for workmanship, data collects, receiving inspection, and build acceptance are well defined.

4.5.5. Integration, Test and Evaluation (IT&E) Assurance

IT&E MA activities assess the system concept and any new technology that will be introduced with that concept. Consideration will be given to mission utility, performance, material composition, structure size, etc., that may impact the way the ground testing should and can simulate the service environments (e.g., multiple UEs and/or aggregate UE power etc.). The integration and test environment (e.g., type of test signals emulating a UE, etc.) can also impact the IT&E MA activities. Additionally, IT&E evaluates existing technology or delivered HW that will be potentially considered.

During concept definition through final design, IT&E is concerned with the scope, rigor, and sufficiency of the overall test program. The proper test program scope is critical to ensure that all required component, unit, subsystem, and system-level development and certification testing is defined and that margin is available. Test scope includes adequate resources and schedule margin for retest in the event of failures/rework that inevitably occur in a development program.

4.5.6. System Safety

The system safety assurance discipline applies engineering and management principles, criteria, and techniques throughout the life cycle of a system to control system hazards within the constraints of operational effectiveness, schedule, and cost. System safety should be an inherent element of system design and is essential to system requirements. Successful system safety efforts depend on clearly identifying and mitigating hazards.

5. Project Life Cycle and Decision Gates Mission Assurance activities are conducted throughout the Project life cycle. As described in the RFIMS Systems Engineering Plan, the major project phases are Concept Definition, Proof of Concept, Prototype, Production & Deployment and Operations & Sustainment, shown in Figure 3.

Figure 3: RFIMS Life Cycle Phases

During the Concept Definition phase, the MA team will evaluate and surveil the activities of the NRE studies. This includes the test bed development and implementation, and creation of test data.

During each phase of the Vendor life cycle, the MA team will conduct assurance activities, including assessments, audits, and surveillance. These activities will be focused primarily on the deliverables and the decision gate reviews, as shown in Figure 4. The reviews include:

• Systems Requirements Review (SRR)

• Alternative System Review (ASR)

• Preliminary Design Review (PDR)

• Critical Design Review (CDR)

• Test Readiness Review (TRR)

• Operations Readiness Review (ORR)

• Systems Acceptance Review (SAR)

The entrance/exit criteria and the associated deliverables are defined in the SEP.

Concept Definition

• Project Formulation (develop requirements, cost/schedule basis, concept of operations)

• Non-Recurring Engineering studies to analyze problem space (environmental tests and site surveys)

• Acquisition activities (contractual documents, Industry Days, Request for Proposal released)

Proof of Concept

• Vendor(s) conduct design and development of initial concept

• Vendor(s) develop set of performance and functional specifications

• Demonstration of initial concepts at factory

Prototype

• Vendor(s) conduct preliminary design and development of a prototype system with increased functionality and maturity from the Proof of Concept

• Interface (internal and external) documents are developed and tested

Production & Deployment

• Vendor conducts detailed design and development of first article system

• Full verification and validation testing

• Production of additional systems

Operations & Sustainment

• Operators and users are trained

• Vendor conducts system updates and maintenance activities

Figure 4: RFIMS MA Processes over Project Life Cycle

Mission Assurance participates in RFIMS decision gate reviews to provide status of MA program and to provide MA evaluation as a review board member. During the design reviews, the MA team reviews documents to ensure compliance with applicable requirements and allocated budgets (where applicable).

6. Mission Assurance Baseline Tool The MAB is a tool containing a configuration-controlled set of tasks performed to increase confidence toward the goal of achieving mission success for the RFIMS ground components. This set is based on mission success guidance found in specifications and standards, policy and other guidance, subject matter expertise, industry best practices, and lessons learned. Tasks in the MAB are intended to be relevant, actionable, and tailorable. Not all tasks are applicable to all programs and some tailoring will be required to meet the unique needs of each program. The MAB is managed as a stand-alone database.

It is a detailed Microsoft Excel spreadsheet of tasks that form a framework for the activities identified as necessary in order to successfully complete the RFIMS Project from initial inception to transfer to operations. Figure 5 below depicts a typical MAB to the Level task description. The full version includes both Level 1 and Level 2 tasks along with the capability to address tasks by acquisition phase along with the ability to add references, descriptions and artifacts that supply proof of completion.

Concept Definition Proof of Concept Production/ Deploy Prototype Operations

SRR PDR ASR CDR TRR ORR SAR

Monitor & Control Vendors

Design & Build Assurance

I&TE Assurance

MA

Process Activities

MA

Product Outputs

Risks Anomaly Reports

MAB Evaluations

Monitor NRE

Metrics

Figure 5. Mission Assurance Baseline Example

6.1. Tailoring the Mission Assurance Baseline

As discussed, not all tasks are applicable to all programs and some tailoring will be required to meet the unique needs of RFIMS. This step is best approached by first surveying the baseline to assess relevant tasks for the program. A recommended best practice is to note the reason why certain sections of the MAB are excluded from the program baseline. For example, the tasks may not be considered for the following reasons: Not applicable to this phase of the program; non-mission area (i.e., non-applicable payloads). Tailoring at this level is conducted at a top-level with little required resources.

Once the initial filtering of the MAB is complete, the final tailoring can be conducted. Considerations include resolution of perceived overlap of accountabilities with other functional areas as specific task responsibilities are assigned to specific organizational areas. Equally important is the consideration of accountability for specific sets of tasks and if there are adequate resources to execute. Again, a recommended best practice is to capture with a short note why MAB tasks are not included in a specific program’s tailored task plan (i.e., outside defined accountability; not funded; or not consistent with risk posture of program). Once L1 tasks are accepted there may be additional tailoring of the L2 tasks to include addition of unique program tasks. A final review should be conducted of the task plan in consideration of the program milestones and definition of internal evaluation/review dates of the selected tasks. Experience has shown that the tailoring process must include the entire project’s management staff to ensure appropriate accountabilities are assigned to the applicable functions.

6.2. Deploying/Executing the MAB

Implementation of the task plan should include deployment that includes a way to track and monitor completion of tasks as accepted by the Project Office. Part of the deployment process will be to determine the appropriate evaluation points (e.g., milestone reviews) for the mission. Engineers perform assessment of the task, and manager’s review and concur on task closure. This is a continual process as products are developed and delivered. In general, the MAB is updated as tasks are completed and the list is reviewed on a monthly basis.

Appendix A: Acronym List

AWS-3 Advanced Wireless Service-3

ASR Alternative System Review

CFR Code of Federal Regulations

CM Configuration Management

DOC Department of Commerce

FCC Federal Communications Commission

FFRDC Federally Funded Research and Development Center

GEO Geostationary Earth Orbit

GOES Geostationary Operational Environmental Satellite

IT&E Integration, Test and Evaluation

INR Interference-to-Noise Ratio

ISO International Organization for Standardization

LEO Low Earth Orbits

LTE Long-Term Evolution

MHz Megahertz

MetOp Meteorological Operational

MA Mission Assurance

MAB Mission Assurance Baseline

MAP Mission Assurance Plan

MTTR Mean-Time-to-Repair

NASA National Aeronautics and Space Administration

NESDIS National Environmental Satellite, Data, and Information Service

NOAA National Oceanic and Atmospheric Administration

NRE Non-Recurring Engineering

NTIA National Telecommunications and Information Administration

POES Polar-orbiting Operational Environmental Satellites

QA Quality Assurance

QASP Quality Assurance Surveillance Plan

QCP Quality Control Plan

RFI Radio Frequency Interference

RFIMS Radio Frequency Interference Monitoring System

SEP Systems Engineering Plan

SBIR Small Business Innovative Research

TEMP Test and Evaluation Master Plan

UE User Equipment

VDT Visual Display Terminal

Appendix A: Acronym List