SBInet SEP.doc

Secure Border Initiative SBInet Program

Systems Engineering Plan

Version 0.5 Supporting Development & Demonstration of

SBInet Block 1

February 12, 2008

Kirk Evans Date SBInet Program Manager Secure Border Initiative SBInet Program

Systems Engineering Plan

Version 0.5 Supporting Development & Demonstration of

SBInet Block 1

SUBMITTED BY

Phil Smith Date Patrick Dolan Date

SBInet CHENG Boeing CHENG

APPROVAL

Kirk Evans Date

SBInet program Manager

Table of Contents

1.0

INTRODUCTION

1.1 Program Description and Applicable Documents 1.2 Current Program Status 1.3 Approach for SEP Update 2.0

PROGRAM REQUIREMENTS

2.1 Capabilities and Key Performance Parameters 2.2 Statutory and Regulatory Requirements 2.3 Specified and Derived Requirements 2.4 Certification Requirements 2.5 Design Considerations 3.0

SYSTEMS ENGINEERING ORGANIZATIONAL INTEGRATION

3.1 Chief Engineer and Functional Leads 3.1.1 Systems Engineering Division 3.1.2 Architecture Division 3.1.3 Test and Evaluation Division 3.1.4 Configuration Management Division 3.1.5 Software Division 3.1.6 Prime Mission Product Division 3.1.7 Communications Division 3.1.8 Information Security and Accreditation Division 3.2 IPT Organization and Structure 3.3 IPT Coordination 3.3.1 Organizational Interfaces 3.4 Integration with Contractor and External Organization 3.4.1 Control Boards, Working Groups, and Other Forums 3.4.2 Configuration Control Boards and Panels 4.0

SYSTEMS ENGINEERING PROCESS

4.1 Technical Baseline Management Responsibility 4.1.1 SBInet Block Workflow 4.2 Defining, Approving, and Maintaining the Technical Baseline……………20…

4.3 Requirements Traceability and Verification and Validation 4.4 Specification Tree and WBS Link 4.5 Technical Approach to Assess Risk

4.6 Technology Insertion………………………………………………... 24………

5.0 TECHNICAL REVIEWS

5.1 Event-Driven Technical Reviews 5.2 Participation in Technical Reviews and Audits 5.2.1 Contractor Participation and Responsibilities 5.2.2 Government Participation 5.3 Stakeholder Participation in Technical Reviews 6.0

INTEGRATION WITH OVERALL PROGRAM MANAGEMENT……………...30

6.1 Linkage to Other Program Management 6.2 Risk Management Integration 6.3 Test and Evaluation 6.4 Life-Cycle Sustainment Integration 6.5 Contracting Considerations

List of Figures and Tables Figure 1-1 SBInet System Segment Concept Figure 3-1 SBInet Engineering Organization Table 3-1 Functional Areas and Responsibilities Figure 3-2: SBInet IPT Organizational Structure Table 3-2 Current IPT List Table 3-3 Working Groups and Review Boards………………………………………16… 3Figure 4-1 SBInet Block Development Workflows

Figure 4-2 Functional Analysis Figure 4-3 Verification Planning Process 3Figure 4-4 SBInet Specification Tree

Figure 4-5 SBInet WBS Figure 4-6 Generalized Risk Management Process……………………………………...24 Figure 5-1 System Level Review

1.0 INTRODUCTION

The purpose of this SEP is to guide the systems engineering management necessary in the development of the first fieldable increment of the SBInet system, which will be known as SBInet Block 1. This document will be used by the Government engineering and management team as well as by the contractor management team to control all technical aspects throughout the development, testing, and fielding of the Block 1 capability. The current schedule for Block 1 leading up to fielding and operational use is very short; however, the SEP will be updated and adjusted as needed if program conditions and guidance may change, requiring changes to schedule, performance, and associated cost and funding. It is anticipated that the basic program structure and engineering processes described herein will serve as the blueprint for subsequent future SBInet Blocks and associated Systems Engineering Plan versions. This plan is a joint document prepared by the Government and the Prime Contractor and follows the guidance of the Systems Engineering Plan, Preparation Guide, October 18, 2007, Version 2.0 with reference to Chapter 4, System Engineering, of the Defense Acquisition Guidebook . If it should be deemed necessary, the contractor will develop a separate, more detailed Systems Engineering Master Plan (SEMP) that will use the contractor’s own format to guide the contractor’s internal engineering activities. However, the SEP and the SEMP will be closely linked such that the described activities are consistent.

1.1 Program Description and Applicable Documents

The Secure Border Initiative (SBI) is a comprehensive, multi-year plan to secure the borders of the United States and reduce illegal cross border activities such as smuggling of economic migrants, illegal drugs, and articles and people with terrorist intent. The SBInet program was defined as a C3I system project to develop, produce, and deploy a technologically advanced command and control capability that will fulfill the Department of Homeland Security’s (DHS) directive to secure the nation’s borders through the comprehensive and systematic deployment of technological upgrades to existing border control systems. SBInet will take a holistic approach to securing the border and immigration enforcement, focusing enforcement efforts on cross-border violations and the continuum of those crimes into the interior of the United States. Achieving control of the border requires determining the optimum mix of personnel, technology and infrastructure, which is required for maximum tactical advantage in each unique border environment. The initial focus of SBInet will be between the Ports of Entry (POEs) where there are serious vulnerabilities to border security. There is a requirement to build a common operating picture (COP) of the border environment within a command center environment, which will provide commonality within DHS agencies and stakeholders external to DHS. The U.S. Customs and Border Protection (CBP) will act as the executive agent for DHS in the development of the SBInet solution.

There are six primary mission elements that form the basic SBInet concept necessary for CBP to gain control of the U.S. borders. Border control is achieved in a given area when CBP is able to consistently perform the six elements listed below:

a. Predict – Anticipating the actions of an Item of Interest (IoI) prior to illegal activity.

b. Deter – Dissuade illegal cross border activity into and out of the U.S. by impeding entry or creating and conveying the certainty of detection and apprehension.

c. Detect – Discover a possible IoI.

d. Identify – Determine whether an IoI is a conveyance, a human, an animal, or another entity.

e. Classify – Determine the potential intent and level of threat of an IoI.

f. Respond/Resolve – Employ an appropriate level of law enforcement resources to successfully address an IoI.

Figure 1-1 SBInet System Segment Concept

Figure 1-1 shows the basic SBInet system concept as a system of systems with each segment serving a unique system or operational function. Several external database systems are interfaced with the SBInet capability which will receive and provide information from and to SBInet.

The following documents provide information describing the current concepts and status of the SBInet program. It is expected that, as the program evolves, some of the information will mature and change in order to develop the most cost, schedule, and performance effective solutions.

· SBInet Mission Need Statement (MNS), Version 1.0, October 1, 2006

· SBInet Operational Requirements Document (ORD), Version 1.0, March 6, 2007

· SBInet Concept of Operations (CONOPS), May 2, 2007

· SBInet T&E Master Plan (TEMP)

· SBInet Acquisition Strategy Report (ASR)

· SBInet Program Management Plan (PMP)

· SBInet System A-Level Specification, August 14, 2007

· Common Operating Picture (SBInet COP) ORD, May 3, 2007

· SBInet System B-Level Specifications, 2007

· Requirements Allocation, A-Specification to B-2 Specification, August 31, 2007

· IEEE Std 12207.1-1997 Guide for Information Technology Software Life Cycle Processes

· IEEE Std 1012, Software Verification and Validation

· IEEE Std 829, Software Test Documentation

· MIL-STD 1521B, Technical Reviews and Audits

· C3I System Product Design, Development, and Deployment Task Order, Statement of Work, version 1.0, 5 November, 2007

1.2 Current Program Status

The SBInet Program is being managed by a Systems Program Office (SPO) under the SBI Program Executive Office (PEO), which is part of the Customs and Border Patrol (CBP) organization, which in turn falls under the Department of Homeland Security (DHS). In September 2006 CBP competitively selected the Boeing Company to be the SBInet Prime Contractor. Based on early versions of a Concept of Operations (CONOPS) and an Operational Requirements Document (ORD) Boeing developed A and B- level systems specifications and built and fielded an initial prototype of the SBInet technology solution deployed along a 28-mile stretch of the Arizona border with Mexico in Sasabe. This prototype is referred to as Project 28 (P28). P28 has been conditionally accepted by the Government and will serve as an Engineering Development Model (EDM) and operational test bed. A Deep Dive Team of outside consultants under the chairmanship of DHS has reviewed the accomplishments of P28 and the SBInet as a whole and made recommendations both concerning the technical aspect of work to date and the acquisition strategy approach used. The lessons learned will be applied by the program going forward and specifically as they apply to the development of SBInet Block 1. Extensive operational and developmental tests including software and hardware control of the system are being planed to be conducted on the P28 prototype as well as in a systems integration laboratory (SIL) to burn down program risks. These tests will be addressed later in this document and detailed in the program TEMP.

At the time of writing this SEP the SBInet program is undergoing an extensive re-planning activity, which will define the detail of the Block 1 capability, the associated development schedule and cost, and the test activities required to reduce program risk. From a top level point of view the Block 1 will utilize the Baseline 1 hardware components currently selected for the “toolbox” and a newly to be developed software solution for the C3I/COP. These two elements will be separately tested, integrated, and subjected to thorough system DT&E/OT&E before a deployment decision will be made. In order to significantly reduce risk it is important to structure a detailed and intensive test program to run in parallel with the development activities. Specifics of this test program will be defined in the SBInet system TEMP written to meet the Block 1 test requirements.

1.3 Approach for SEP Update

This is the first SEP version specifically produced by the SBInet SPO. Its purpose is to describe the systems engineering approach and organization leading to a fielded Block 1 capability. Since program re-planning is still ongoing some of the details herein may require updates as new direction may be forthcoming, funding and technical issues may arise, and the system concept matures during the course of development and testing. Furthermore, the SEP will be updated as required once the program proceeds to subsequent block implementations.

2.0 PROGRAM REQUIREMENTS

The ultimate goal of border control is deterrence. Until that goal is realized, DHS must consistently detect illegal entries, identify and classify entries and determine the level of threat involved, then respond with the knowledge of the threat level to be encountered and bring the event to a satisfactory law enforcement resolution. SBInet will take a holistic approach to securing the borders at and between the Ports of Entry (POEs). The initial focus of SBInet will be between the ports of entry where there are serious vulnerabilities to border security. Further, there is a requirement to build a common operating picture (COP) of the border environment within a command center environment, which will provide commonality within Department Homeland Security (DHS) agencies and interoperability with stakeholders who are external to DHS.

Block 1 threshold Key Performance Parameters (KPPs) and requirement values generally reflect capabilities immediately available using existing, off-the-shelf commercial or government technology. Follow-on time phased threshold values will reflect technology performance anticipated in future years and may be adjusted according to realized or disruptive technology maturation. The overarching objective for Block 1 deployment is to provide virtual “eyes-on-target” so law enforcement officials have the ability to make an informed apprehension decision at reduced cost.

Due to the over-riding stringent schedule requirements imposed on the program by a national security mandate, the program will depend heavily on existing COTS and GOTS solutions. However, it is fundamental to systems engineering to take a total life cycle approach in the development, even of Block 1. The cost to implement a system change increases dramatically as a program moves further along in the life cycle. The greatest leverage exists in the early stages of development, when the program is most flexible. In this sense Block 1 takes on a great deal of significance in that the system engineering process has to assure that Block 1 will be a logical first increment of the future total system. Therefore, while Block 1 only implements a partial capability, the end system has to be reasonably well scoped to avoid expensive system changes later on. The maturity of the system architecture must be continuously validated through modeling and simulation in conjunction with ongoing testing during the Block 1 development. This will also be the basis for reliable sector “lay-down” or deployment analysis. The decision has to be made whether earlier block implementations will be continuously updated as subsequent blocks come off line or whether blocks will be replaced. If technology changes rapidly the latter might be the more cost effective approach.

2.1 Capabilities and Key Performance Parameters

Alternatives to the SBInet system have been examined including the Integrated Surveillance and Intelligence System (ISIS) and the America’s Shield Initiative. These activities resulted in a SBInet Mission Needs Statement (dated October 1, 2006) and a preferred system concept articulated in the SBInet Concept of Operations Document (dated May 2, 2007). The SBInet Operational Requirements Document (dated March 6, 2007) is presently under review to incorporate time-phased requirements. An Acquisition Decision Memorandum (dated January 2, 2007) authorized SBInet to commence capability development and demonstration. It further directed that DHS retain full rights in developed systems and information from any deliverables.

Key Performance Parameters (KPPs) and System Requirements are listed in the SBInet Operational Requirements Document (ORD). Many are time-phased by near, mid and far term. This SEP is presently concerned with the near-term KPP and requirement values as they correlate directly with the Block 1 deployment. In general, KPP and requirement objective values do not change in time as they reflect the final, objective system. However, most threshold values will change and become more stringent with the different system Block deployments.

Block 1 threshold KPP and requirement values generally reflect capabilities immediately available using existing, off-the-shelf commercial or government technology. This nominally corresponds to Technology Readiness Levels (TRL) 8 and 9. Follow-on time phased threshold values will reflect technology performance anticipated in future years (presently TRL 5 through 7) and may be adjusted according to realized or disruptive technology maturation. The overarching objective for Block 1 deployment is to provide virtual eyes-on-target to enable an informed apprehension decision by law enforcement officials at reduced cost.

Key Performance Parameters are essential system capabilities that, if not met, will produce a system that fails to meet fundamental customer expectations and may result in program termination. Qualitative SBInet objective system KPPs are:

1. The system shall detect items of interest crossing the border.

2. The system shall provide for successful law enforcement resolution for items of interest crossing the border.

3. The system shall eliminate unnecessary intercepts.

4. The system shall be operationally available (Ao).

5. The system shall provide for accurate apprehensions (intercepts) by law enforcement officers.

6. The system shall provide a common operating picture (COP) with minimum specified standards for information content, timeliness and assurance. (Net-ready KPP

Key Performance parameters for Block 1 deployment are:

1. The system shall detect items of interest crossing into the US along the southern border prior to leaving the control zone (Pd => 0.75).

2. The system shall provide for successful law enforcement resolution for items of interest entering the United States (Psler => 0.6).

3. The system shall eliminate unnecessary intercepts (unnecessary intercepts <= 10 per hour).

4. The system shall achieve a minimum specified operational availability (Ao => 0.7).

5. The system shall provide a common operating picture (COP) with minimum specified standards for information content, timeliness and assurance.

6. The system shall provide accurate intercept information for apprehension (Pi=>.6).

These parameter values are less stringent than those listed in the ORD as threshold and objective values; however, they will be a great improvement over the currently achievable values of P28 prototype system.

The Director, Mission Engineering (ME) is responsible for establishing, maintaining, and periodic review of SBInet requirements and associated processes and procedures. Additionally, the Director is the focal point for customer advocacy. The SBInet Requirements Integrated Product Team (IPT) is chaired by the Director, ME and is responsible for documenting and maintaining SBInet requirements in the SBInet Operational Requirements Document (ORD). The SBInet Chief Engineer is a member of the Requirements IPT and is responsible for designing and developing the SBInet system that meets the requirements specified in the SBInet ORD. Any conflicts between SBInet Requirements and system design that cannot be resolved by the Requirements IPT will be elevated to the SBInet Program Manager for adjudication.

2.2 Statutory and Regulatory Requirements

Statutory and regulatory requirements affecting the SBInet deployment include:

· Spectrum allocation and management

· Environmental impact assessments

· Private land ownership and right-of-way

· Privacy Act of 1974 (5 U.S.C. § 552a)

· Clinger-Cohen Act

· Federal Information Security Management Act (FISMA)

· DHS Management Directive System, Management Directive (MD) # 1400 Investment Review Process

· CBP System Life Cycle (SLC)

Each of these may have a profound impact on the system design and sensor location requiring additional assets or design trades. The engineering design process must account for restrictions imposed by these requirements. Subject matter experts in these areas should be participants in the system engineering and design working groups.

Additionally DHS and CBP are imposing Enterprise Architecture(s), IT standards, enterprise standard practices, including data models, information sharing and communications protocols, as well as standard technologies and data warehousing programs solutions. These mandates are expected to further impact available design options. These impacts either have to be taken into account or waivers have to be negotiated. In either case the systems engineering process has to be sufficiently detailed to find early answers to these questions.

2.3 Specified and Derived Requirements

Key Performance Parameters and system level user requirements are found in the SBInet Operational Requirements Document (ORD). The process owner for this document is the Mission Engineering led Requirements IPT. The “flow-down” of these requirements to the SBInet function and component levels along with their traceability back to the ORD is the responsibility of the SBInet Chief Engineer. This responsibility may be delegated in writing to the SBInet System Engineer. Established systems engineering processes such as those contained in the Defense Acquisition University’s Systems Engineering Fundamentals handbook shall be employed in all phases leading to the final deployable product.

The System Engineering IPT, chaired by the SBInet System Engineer, shall maintain requirement traceability by using a requirements tracking tool such as the Dynamic Object Oriented Requirements System (DOORS) database. Requirements and resources (schedule and funding for example) shall be allocated in writing to sub-system or component engineers or working groups who are responsible for satisfying the allocated requirement within the resource allotment. Technical performance measures shall be established and tracked for each such allocation. After they have been established, requirements and/or resources can only be reallocated by the System Engineering IPT along with Program Manager’s concurrence.

The Block 1 implementation as a first spiral evolutionary development will not necessarily implement all of the stated ORD requirements and meet all of the associated threshold or objective requirements. The early engineering process must establish a firm set of requirements to be implemented in Block 1. The chosen solutions for Block 1 are based on the current toolbox component and on version 0.5 of the C3I/COP.

2.4 Certification Requirements

SBInet Information Technology (IT) systems that store Sensitive-But-Unclassified (SBU) information will be certified and accredited for operation in accordance with federal and DHS standards. Consult the DHS Information Technology Security Program Handbook for Sensitive Systems, Publication 4300A, for more detailed information. Implementations and lessons learned from P28 will be applicable.

2.5 Design Considerations

The Block 1 deployment design will only consider the southern land border area between Ports of Entry. Additionally, air and marine assets will not be considered in the deployment design. Intelligence functions of the common operating picture as well as integration with other national and international law enforcement data exchanges will not be included. The Block 1 system will be primarily composed of fixed and mobile sensor towers, unattended ground sensors, means to communicate sensor data to one or more control facilities, and a situational awareness software package to allow interaction with the sensor systems. Fixed tower sites are comprised of three basic designs; sensor towers, communications relay towers, and a combination of the two. There may be minor variations in these fixed tower sites allowing for adjustments in tower height, footprint, or power options. However, the intent for the Block 1 deployment is to refine these three fixed site designs and deploy them as common items (design drawings and bill of materials) for ease of configuration management, maintenance, logistic support, in-service engineering needs, and total ownership cost. Unattended ground sensors will be deployed in conjunction with each sensor tower site to ensure adequate sensor coverage to meet program performance parameters. The unattended ground sensor placement will be unique to each sensor tower site and driven by terrain, environmental, or other sensor limitations.

The Block 1 design will be based on the experience from P28; the evolving system design is the result of an iterative task, performed within the framework of systems engineering to achieve the “best value” for the user. The best value solution will optimize the system operational effectiveness through balancing of system performance, system availability, interoperability, and total system life-cycle cost. This is not a trivial task and is the basis for the “spiral” approach to total system design. Definite design considerations at this point are the schedule and cost constraints that have led to standard system segment design approaches, such as the standard tower segment design, use of widely supported and consensus based standards, and an open system design approach, which employs modular design concepts and standard and well defined interfaces. This approach will assure that future spirals and blocks are easy extensions of the initial block implementation.

3.0 SYSTEMS ENGINEERING ORGANIZATIONAL INTEGRATION

The following section describes the SBInet Chief Engineer organization and how it is structured to implement SBInet program requirements and achieve program and project milestones as outlined in Section 2. The Chief Engineer and reporting functional leads are listed in Figure 3-1.

Figure 3-1, SBInet Engineering Organization

The following Table 3-1 shows Key Duties and responsibilities by Functional Area

Ensure compatibility of all interfaces*

Integrate specialty factors into total engineering effort to meet cost, schedule, and technical performance objectives*

Systems Eng. Project Leads for each deployment project provide technical leadership and access to systems eng. process services

Trace designs to requirements**

Define and understand interfaces**

- Ensure consistency between product and its supporting documentation**

Identify and (if necessary) provision for COMM services (voice & data)

Facilitate spectrum management

Highlight integration issues among legacy equip. & proposed COMM solutions

Define the framework or structure of components*

Define relationships among components*

Define principles & guidelines that govern their design & evolution over time*

Oversee the introduction & removal of toolbox items

Highlight integration challenges among legacy equipment, existing toolbox items, & proposed toolbox items

Monitor and evaluate development process to reduce risk**

Support decision making**

Engage external test agent to provide independent assessment of development process and system performance

Oversee the introduction, maintenance, and removal of software solutions for C3I

Ensure compliance with federal regulations

Oversee the implementation of security protocols

Facilitate certification & accreditation activities

Table 3-1 Functional Areas and Responsibilities

3.1 Chief Engineer and Functional Leads

The Chief Engineer is the primary technical authority for the SBInet Technical Baseline and the mission products developed for the program. The Chief Engineer serves as the SBInet Systems Engineer and reports to the SBInet Program Manager. He maintains technical coordination with the SBI PEO and Assistant Commissioner for Information Technology to ensure architectural alignment with the DHS/CBP Enterprise Architecture. The Chief Engineer has authority over the translation of operational needs into a description of system performance requirements and a preferred system configuration. The Chief Engineer approves engineering staff to serve on Integrated Product Teams. The Chief Engineer manages the Engineering Directorate which is primarily organized around SBInet Systems Engineering functions and is composed of the following divisions: Systems Engineering Division; Architecture Division; Test and Evaluation Division, Configuration Management Division; Software Engineering Division; Toolbox Integration Division; Communications Division; and the Information Security and Accreditation Division. The Chief Engineer also directly manages R&D Projects and Special Projects through the Chief C3I Engineer, Special Projects Engineer and the Chief Scientist.

3.1.1 Systems Engineering Division

The Systems Engineering (SE) Division is responsible for transforming operational requirements into the description of system performance requirements and a configuration baseline for SBInet. This responsibility is based on Government and Industry standards for systems engineering for compliance with DHS and CBP System Life Cycle (SLC) standards. The SE Division partners with the System Prime to ensure a full understanding of the mission requirements for the system and that the system operators and stakeholders understand the “trade space” between technical performance, cost, and delivery schedule leading to an agreement that the technical performance capabilities provided by the contractor meet mission needs. These performance capabilities are base-lined and the baseline is managed through strict configuration control with adequate flexibility to support spiral and evolutionary development as the system matures and requirements and expectations change.

The SE Division supports and forms IPTs as necessary with the other divisions within the purview of the Chief Engineer and SBInet Program Manager. Systems Engineering Project Leads are assigned for each deployment project to provide technical leadership and access to systems engineering process services. SE Division responsibilities include: development of system and design specifications; performance baselines; testing processes and activities; engineering processes; technical risk management; technical configuration management; technical performance metrics and tracking; software development; enterprise architecture integration; reliability, maintainability and availability; compatibility of all interfaces; integration of specialty factors into total engineering effort to meet cost, schedule, and technical performance objectives; production, system integration, compatibility; deployment; testing, evaluation and sustainability. To execute “insight and oversight” of the SBInet development contractor, the SE Division is responsible for reviewing, reporting, and providing recommendations to the Chief Engineer on contractor deliverables and activities such as: system and component requirements, design documents, performance metrics and their usage, design reviews, developmental testing, deployment and logistics planning, and interface reviews.

3.1.2 Architecture Division

The Architecture Division will leverage the business blue-print to develop an Application and Technical Architecture. The Division aligns SBInet as a system within the DHS and CBP enterprise to ensure program alignment, mapping to the business architecture, transition strategy, data architecture, and the technology standards. Responsibilities include defining the framework or structure of components and the relationships among components and the principles and guidelines that govern their design and evolution over time. The Architecture Division submits technologies to the appropriate review boards for inclusion in the DHS and CBP Enterprise Architecture Technical Reference Model to ensure the SBInet components and systems are compatible with existing and future infrastructure. The Division submits Program Alignment Requests and Technology Insertion Requests to the DHS CIO Enterprise Architecture Board.

3.1.3 Test and Evaluation Division

The Test and Evaluation Division participates in all Systems Engineering activities and acts as subject matter experts for the oversight or conduct of: Development Test & Evaluation; Integration Testing; Security Certification; Operational Test & Evaluation; development of Special Purpose Test Equipment; Test Facilities and Environments; and Assessment Testing. The Test and Evaluation Division develops the Test and Evaluation Master Plan (TEMP) and Test and Evaluation Reports. Testing is conducted to verify technical performance, operational effectiveness, and operational suitability. Operational Test and Evaluation and Independent Validation and Verification (IV&V) testing services are provided by independent testers and are coordinated by the Test and Evaluation Division. Testing decisions are critical to the monitoring and evaluation of the development process to reduce risk and support the major program milestone decisions.

3.1.4 Configuration Management Division

The Configuration Management (CM) Division is responsible for establishing and controlling the system baselines at major program and project milestones through the integrity of configurable items by using configuration identification, configuration control, configuration status accounting, and configuration audits. The CM Division manages defined requirements, traces the designs to requirements, defines and understands interfaces, and ensures consistency between product and its supporting documentation. The System Prime Contractor and other SBInet contractors establish their own CM capabilities to ensure that products they develop are appropriately controlled. These contractors are required to follow DHS and CBP configuration, change and baseline management practices, and operate within established DHS and CBP configuration management governance structures and guidelines. To help ensure program success and deal with the program’s integration complexities, the SBInet SPO develops and facilitates effective collaboration between the SPO’s and the contractors’ CM functions as well as those of other government entities.

3.1.5 Software Division

The Software Division oversees the development, design, and/or creation of software that satisfies SBInet C3I system operational needs or objectives and the introduction and maintenance of software solutions for C3I. This includes the integration of COTS/GOTS software from the various product vendors into the common architecture of the SBInet Toolbox solution. The Software Division determines technical interface requirements based on the CONOPS (all C3I layers) and the way in which the system and user interact with the C3I functionality with information accessed at each layer of the SBInet architecture. The Software Division supports the maintenance and enhancements of SBInet software such as the Mission Engineering modeling and simulation system.

3.1.6 Prime Mission Product Division

The Prime Mission Product Division participates in all Systems Engineering activities and acts as subject matter experts for the development and integration of all prime mission products. The Division reviews prime mission product item specifications and oversees the introduction and removal of prime mission product, “toolbox” items, and resolves the integration challenges among legacy equipment, existing and proposed prime mission product items. The Division also participates in the testing of prime mission product components to assure their suitability for inclusion in the system design and configuration.

3.1.7 Communications Division

The Communication Systems Division participates in all Systems Engineering activities and acts as the subject matter expert in the development and integration of communications systems. The Division is responsible for reviewing communication-related specifications and overseeing trade studies; identifying and (if necessary) providing for communications services (voice and data); facilitating spectrum management, and resolving integration issues among legacy equipment and proposed communication solutions.

3.1.8 Information Security and Accreditation Division

The Information Security and Accreditation Division participates in all Systems Engineering activities and acts as the subject matter expert for the development, integration and accreditation of SBInet IT Infrastructure, including Networks, Data Centers, Information Security, Servers, Data Systems, and Utility Software. The Division is responsible for reviewing information security specifications, ensuring compliance with federal regulations, overseeing the implementation of security protocols, and facilitating the certification and accreditation activities.

3.2 IPT Organization and Structure

The SBInet SPO has directed that IPTs play an integral role in the program’s acquisition oversight and review process to assure the products delivered to the field meet the stated requirements of the overall SBInet 6,000 mile system. IPTs shall serve as advisory bodies to the Program/Project Manager (PM).

Figure 3-2 illustrates the organizational structure of the SBInet IPTs. The SBInet System IPT will primarily be responsible for the definition and implementation of systems engineering processes and procedures throughout the lifecycle of the program. Tasks may include system architecture definition, trade study performance, requirements development and management, product design, test and evaluation, and requirements verification.

The SBInet Chief Engineer chairs the SBInet System Engineering Overarching IPT (SE IPT) which focuses on strategic guidance, tailoring, program assessment, and resolving issues elevated by Working-level IPTs. The Chief Engineer assigns resources at the execution level to support the Integrating IPTs which coordinate Working-level IPT efforts and cover all topics not otherwise assigned to another Working-level IPT. As such, both Integrating IPTs and Working-level IPTs plan for program success, identify and resolve program issues, monitor program status, and actively seek opportunities to innovate and streamline the program’s acquisition approach. System Project Engineers are assigned by the Chief Engineer to support Project/Sector IPTs to focus on project execution and issue identification and resolution; system project engineers are responsible for ensuring system engineering processes are followed during project execution and engage system engineering resources to assist with project execution. SBInet has two systems engineering specific Oversight and Review IPTs that cover multiple working level IPTs (i.e., Prime Mission Products and Systems Architect).

Additional Working-level IPTs will be formed as needed to address areas such as mobile response platforms, and field agent systems. Furthermore, if a specific topic arises within a Working-level IPT that requires action but not necessarily the attention of the entire

Figure 3-2: SBInet IPT Organizational Structure

IPT’s membership, a temporary Working Group can be formed. Said Working Group shall have a limited scope (defined by the parent Working-level IPT) and shall dissolve when its purpose has been fulfilled. Members of the IPT can include personnel from outside the SPO. In addition, the following roles and responsibilities apply to all IPTs:

1. Assist the PM in developing strategies and in program/project planning, as requested by the PM.

2. Establish an IPT plan-of-action and milestones (POA&M)

3. Propose tailored documentation and milestone requirements

4. Review and provide early input to documents

5. Coordinate Working-level IPT activities with the Overarching IPT members

6. Resolve or elevate issues in a timely manner

7. Assume responsibility to obtain principals’ concurrence on issues, as well as with applicable documents or portions of documents

8. Capture IPT meeting minutes and distribute to team members nationwide

9. IPT meetings protocols (including who can call a meeting, how the meetings are called, what's considered a quorum) are established by the individual IPT charter. All SBInet IPTs are co-chaired by a government representative and a Boeing representative. Current IPTs are listed in Table 3-2 with corresponding Government and Boeing points of contact.

EO/IR

Table 3-2 Current IPT List

In addition to the IPTs the following Working Groups and Review Boards have been established, chaired by the Prime Contractor and co-chaired by the Government:

Weekly

Weekly

Weekly

Weekly

Weekly

Weekly

Engineering Review Board

Weekly

Program Configuration Control Board

Weekly

Table 3-3 Working Groups and Review Boards

3.3 IPT Coordination

The responsibility for all systems engineering-related tasks lies within the SE IPT. All of the individual design groups that fall under the SE IPT report to the Chief Engineer. The Chief Engineer will periodically present the results of IPT efforts to the SBInet Program Manager at periodic Program Management Reviews (PMR) so that the consolidated efforts of the entire IPT can be presented and coordinated.

3.3.1 Organizational Interfaces

The SBInet SPO will require frequent interaction with various other groups in order to function effectively to make the SBInet system a reality. Relationships will not only need to be established internally within the SPO between the various IPTs but also within DHS CBP, Boeing and their Teaming Partners, and also with DHS CBP Partners to include Associate Contractors. The responsibility for all SBInet program-related tasks lies within the SBInet PMO. All of the individual IPTs that fall under the SPO report to the Program Manager through periodic PMRs so that the consolidated efforts of the individual IPTs can be presented and cross-coordinated.

3.4 Integration with Contractor and External Organization

In essence, SBInet is a system of systems. The systems engineering for a system of systems deals with the planning, analyzing, organizing, and integrating the capabilities of a mix of existing and new systems into a system of systems capability which is greater than the sum of the capabilities of the constituent parts. The overall objective of developing a system of systems is to satisfy required capabilities that can only be met with a mix of multiple, autonomous, and interacting systems. The systems engineering process, therefore, must deal not only with the constituent parts but with the expected system of system behavior and performance. This will require close collaboration and interaction with many different groups including those that are outside of the immediate SBInet community.

As the DHS CBP SBInet SPO sets forth its organization, Boeing will ensure that its DHS CBP counterparts have insight into the appropriate Boeing IPTs to include establishing POCs. For example, it is critical for the Modeling and Simulation (M&S) lead for the DHS CBP SPO to establish contact with the M&S lead on the Boeing team early on. With respect to the preparation and review of contract deliverables, the DHS CBP SPO will be closely coordinating with Boeing to ensure better understanding of SBInet goals, respond more effectively to requests, and to reduce the number of review cycles required prior to submittal. Other prime opportunities for personnel from the Government and contractor Systems Engineering IPTs to coordinate are in preparation for design reviews and regularly scheduled PMRs. The interface with selected teaming partners will occur through the SE IPT, specifically the Design Integration Team. The team lead for Design Integration will periodically schedule PMRs so that the consolidated efforts of the design team, including partners, can be presented and coordinated.

3.4.1 Control Boards, Working Groups, and Other Forums

Several regularly scheduled forums will be instituted to support the activities occurring within the SBInet program organization. Most of those planned are discussed as follows:

To support the Configuration/Data Management process, Internal Review Boards (IRB) will be put in place by the individual design teams within the SE IPT so that the design team lead can understand what item is being proposed before it is elevated to the Systems Engineering Review Board (SERB) for review. The SERB will be chaired by the SE IPT lead or designee and will coordinate with the Boeing PMO Engineering Review Board (ERB), as necessary. The PMO ERB will be chaired by the Program Manager or designee and will have the final authority to approve an item on the agenda or recommend its submission to the Boeing PMO CCB. The Boeing PMO CCB will typically serve as the final authority when a proposal directly impacts the design baseline and is also chaired by the Program Manager. The Configuration/Data Management IPT will be responsible for hosting both the Boeing PMO CCB and ERB meetings. The DHS CBP SPO will be encouraged to participate in the Boeing PMO CCB meetings.

A Requirements Working Group (RWG) will be put in place by the SE IPT. The charter of this group will be to assist in the development and peer-review of system requirements related to the SBInet program. Other tasks may include the documentation and disposition of requirement issues and requirement database tool management.

An Interface Control Working Group (ICWG) will also be put in place by the SE IPT. The charter of this group will be to assist in the development, coordination, and peer-review of system interface requirements (to include both external and internal) related to the SBInet program. Other tasks may include the documentation and disposition of interface requirement issues and the development of interface control diagrams.

A Risk Management Board (RMB) will also be put in place by the SE IPT. The charter of this group will be to assist in the identification, tracking, and mitigation of system risk issues related to the SBInet program.

A Failure Review Board (FRB) will be put in place by the SE IPT. The charter of this group will be to assist in the tracking and disposition of documented hardware/software system failures and discrepancies related to the SBInet program.

3.4.2 Configuration Control Boards and Panels

The Configuration Control Board (CCB) is chaired by the SBInet Program Manager and will typically serve as the final approval authority for proposals that involve direct impacts to the design baseline. The governing body of the CCB panel will be composed of representatives from each of the individual SBInet IPTs, the chair (Program Manager or designee), and the DHS CBP PMO. This board will meet on a regularly scheduled basis as decided by the Program Manager and the DHS CBP PMO.

The primary charter and responsibility of the PMO CCB will be to review and disposition ERB-approved proposals in a forum-type setting with DHS CBP PMO participation. Agenda items for this board will need to satisfy two key criteria before consideration, must be approved by the Boeing PMO ERB and must result in a direct impact to the design/program baseline (i.e. major change). Since this control board is tasked with disposition of proposals that affect the baseline, the DHS CBP PMO representative will have voting authority on agenda items being presented.

4.0 SYSTEMS ENGINEERING PROCESS

At this time the systems engineering process being used in the development and implementation of the SBInet capabilities follows the “Block”, i.e. a spiral or evolutionary process. It is paramount to field early capabilities in order to provide the border patrol agents the technological tools to better protect the nation’s borders now rather than later and get operational feedback from the users of these capabilities. As the SBInet systems capabilities are proliferated along the entire U.S. borders the lessons learned from the field as well as maturing new technologies are folded into subsequent Blocks enhancing the fielded capabilities and realizing the full required operational requirements as stated in the SBInet ORD.

4.1 Technical Baseline Management Responsibility

4.1.1 SBInet Block Workflow

Figure 4-1 illustrates the typical workflow which is involved in the development and fielding of a SBInet Block implementation, specifically Block 1, which is the subject of this Systems Engineering Plan. The workflow divides into two distinct primary

Figure 4-1 SBInet Block Development Workflows activities, the development of the system hardware and associated software, which together constitute the Block operational capability, shown in the figure as “Block”; and the deployment of such capability in a specific area or sector of the border, shown in the figure as “Sector/Area”.

The development of the Block involves two sub-activities, the…