SBInet includes the acquisition, development, integration, deployment, and operations and maintenance of a mix of surveillance technologies, such as cameras, radars, sensors, and C3I technologies. The initial focus of SBInet has been on addressing the requirements of CBP’s Office of Border Patrol, which is responsible for securing the borders between the land ports of entry. Longer term, SBInet is to address requirements of CBP’s Office of Field Operations, which controls vehicle and pedestrian traffic at the ports of entry, and its Office of Air and Marine Operations, which operates helicopters, fixed-wing aircraft, and marine vessels used in securing the borders. (See fig. 1 for the potential long-term SBInet concept of operations.) Surveillance technologies are to include a variety of sensor systems. Specifically, unattended ground sensors are to be used to detect heat and vibrations associated with foot traffic and metal associated with vehicles. Radar mounted on fixed and mobile towers is to detect movement, and cameras on fixed and mobile towers are to be used by operators to identify and classify items of interest detected and tracked by ground sensors and radar. Aerial assets are also to be used to provide video and infrared imaging to enhance tracking targets. These technologies are generally to be acquired through the purchase of commercial off-the-shelf (COTS) products. C3I technologies (software and hardware) are to produce a common operating picture (COP)—a uniform presentation of activities within specific areas along the border. Together, the sensors, radar, and cameras are to gather information along the border and transmit this informatio COP terminals located in command centers and agents’ vehicles, which in turn are to assemble it to provide CBP agents with border situational awareness. Among other things, COP hardware and software are to allow agents to (1) view data from radar and sensors that detect and track movement in the border areas, (2) control cameras to help identify and classify illegal entries, (3) correlate entries wit h the positions of nearby agents, and (4) enhance tactical decision making regarding the appropriate r esponse to apprehend an entry, if necessary. To increase border security and decrease illegal immigration, DHS launched SBI more than 4 years ago after canceling its America’s Shield Initiative program. Since fiscal year 2006, DHS has received about $4.4 billion in appropriations for SBI, including about $2.5 billion for physical fencing and related infrastructure, about $1.5 billion for virtual fencing (surveillance systems) and related technical infrastructure (towers), and about $300 million for program management. The SBI Program Ex Office, which is organizationally within CBP, is responsible for managing key acquisition functions associated with SBInet, including prime contractor tracking and oversight. It is organized into four components: SBInet System Program Office (referred to as the SPO in this report), Systems Engineering, Business Management, and Operational Integration As of Dece mber 31, 2009, the SBI Program Executive Office was staffed with 188 people—87 government employees, 78 contractor staff, and 13 detailees. . In September 2006, CBP awarded a 3-year prime contract to the Boeing Company, with three additional 1-year options for designing, producing, testing, deploying, and sustaining SBI. In 2009, CBP exercised the first option year. Under this contract, CBP has issued 10 task orders tha to SBInet, covering for example, COP design and development, system deployment, and system maintenance and logistics support. As of December 2009, 4 of the 10 task orders had been completed and 6 were ongoing. (See table 1 for a summary of the SBInet task orders.) One of the completed task orders is for an effort known as Project 28, which is a prototype system that covers 28 miles of the border in CBP’s Tucson Sector in Arizona, and has been operating since February 2008. However, its completion took 8 months longer than planned because of problems in integrating system components (e.g., cameras and radars) with the COP software. As we have reported, these problems were attributable to, among other things, limitations in requirements development and contractor oversight. Through the task orders, CBP’s strategy is to deliver SBInet capabilities incrementally. To accomplish this, the SPO has adopted an evolutionary system life cycle management approach in which system capabilities are to be delivered to designated locations in a series of discrete subsets of system functional and performance capabilities that are referred to as blocks. The first block, which has been designated as Block 1, includes the purchase of commercially available surveillance systems, development of customized COP systems and software, and use of existing CBP communications and network capabilities. Such an incremental approach is a recognized best practice for acquiring large-scale, complex systems because it allows users access to new capabilities and tools sooner, and thus permits both their early operational use and evaluation. Subsequent increments of SBInet capabilities are to be delivered based on feedback and unmet requirements, as well as the availability of new technologies. In general, the SBInet life cycle management approach consists of four primary work flow activities: (1) Planning Activity, (2) System Block Activity, (3) Project Laydown Activity, and (4) Sustainment Activity. During the Planning Activity, the most critical user needs are to be identified and balanced against what is affordable and technologically available. The outcome of this process is to be a set of capability requirements that are to be acquired, developed, and deployed as a specific block. This set of capabilities, once agreed to by all stakeholders, is then passed to the System Block Activity, during which the baseline system solution to be fielded is designed and built. Also as part of this activity, the verification steps are to be conducted on the individual system components and the integrated system solution to ensure that they meet defined requirements. The Project Laydown Activity is performed to configure the block solution to a specific geographic area’s unique operational characteristics. This activity involves assessing the unique threats, terrain, and environmental concerns associated with a particular area, incorporating these needs into the system configuration to be deployed to that area, obtaining any needed environmental permits, and constructing the infrastructure and installing the configured system. It also involves test and evaluation activities, including system acceptance testing, to verify that the installed block system was built as designed. The final activity, Sustainment, is focused on the operations and maintenance of the deployed block solution and supporting the user community. Associated with each of these activities are various milestone or gate reviews. For example, a key review for the System Block Activity is the Critical Design Review (CDR). At this review, the block design and requirements are baselined and formally controlled to approve and track any changes. Among other things, this review is to verify that the block solution will meet the stated requirements within the program’s cost and schedule commitments. An important review conducted during the Project Laydown Activity is the Deployment Design Review. At this review, information such as the status of environmental reviews and land acquisitions for a specific geographic area is assessed, and the location- specific system configuration is determined. The Deployment Readiness Review is another key event during this activity. During this review, readiness to begin site preparation and construction is assessed. In addition to the four above described workflow activities are various key life cycle management processes, such as requirements development and management, risk management, and test management. Requirements development and management, among other things, involves defining and aligning a hierarchy of five types of SBInet requirements. These five types begin with high-level operational requirements and are followed by increasingly more detailed lower-level requirements, to include system, component, C3I/COP software, and design requirements. To help it manage the requirements, the SPO relies on Boeing’s use of a database known as the Dynamic Object-Oriented Requirements System (DOORS). The various types of SBInet requirements are described in table 2. Risk management entails taking proactive steps to identify and mitigate potential problems before they become actual problems. The SPO has defined a “risk” to be an uncertain event or condition that, if it occurs, will have a negative effect on at least one program objective, such as schedule, cost, scope, or technical performance. The SPO has defined an “issue” as a risk that has been realized (i.e., a negative event or condition that currently exists or has a 100 percent future certainty of occurring). According to SBInet’s risk management process, anyone involved in the program can identify a risk. Identified risks are submitted to the Risk Management Team, which includes both the SPO Risk Manager and Boeing Risk Manager, for preliminary review. If approved for further consideration, the risk is entered into the Boeing-owned risk database, which is accessible by SPO and Boeing officials. These risks are subsequently reviewed by the Joint Risk Review Board, which is composed of approximately 20 SPO and Boeing officials. If a risk is approved, it is to be assigned an owner who will be responsible for managing its mitigation. Test management involves planning, conducting, documenting, and reporting on a series of test events that first focus on the performance of individual system components, then on the performance of integrated system components, followed by system-level tests that focus on whether the system (or major system increments) are acceptable and operationally suitable. For SBInet, the program’s formal test events fall into two major phases: developmental test and evaluation (DT&E) and operational test and evaluation (OT&E). DT&E is to verify and validate the systems engineering process and provide confidence that the system design solution satisfies the desired capabilities. It consists of four test events— integration testing, component qualification testing, system qualification testing, and system acceptance testing.