CBP’s SBI program is to leverage technology, tactical infrastructure, and people to allow CBP agents to gain control of the nation’s borders. Within SBI, SBInet is the program for acquiring, developing, integrating, and deploying an appropriate mix of (1) surveillance technologies, such as cameras, radars, and sensors, and (2) command, control, communications, and intelligence (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 established ports of entry. The longer-term SBInet systems solution also is to address requirements of CBP’s two other major components—the Office of Field Operations, which controls vehicle and pedestrian traffic at the ports of entry, and the Office of Air and Marine Operations, which operates helicopters, fixed-wing aircraft, and marine vessels used in securing the borders. Figure 1 provides a high-level, operational concept of the long-term SBInet systems solution. Surveillance technologies are to include a variety of sensor systems that improve CBP’s ability to detect, identify, classify, and track items of interest along the borders. Unattended ground sensors are to be used to detect heat and vibrations associated with foot traffic and metal associated with vehicles. Radars mounted on fixed and mobile towers are to detect movement, and cameras on fixed and mobile towers are to be used to identify, classify, and track items of interest detected by the ground sensors and the radars. Aerial assets are also to be used to provide video and infrared imaging to enhance tracking of targets. The C3I technologies are to include software and hardware to produce a Common Operating Picture (COP)—a uniform presentation of activities within specific areas along the border. The sensors, radars, and cameras are to gather information along the border, and the system is to transmit this information to the COP terminals located in command centers and agent vehicles and assemble this information to provide CBP agents with border situational awareness. More specifically, the COP technology is to allow agents to (1) view data from radars and sensors that detect and track movement in the border areas, (2) control cameras to help identify and classify illegal entries, (3) correlate entries with the positions of nearby agents, and (4) enhance tactical decision making regarding the appropriate response to apprehend an entry, if necessary. Initially, COP information is to be distributed to terminals in command centers. We observed that these terminals look like a standard computer workstation with multiple screens. From this workstation, an operator is to be able to view an area of interest in several different ways. For example, the operator is to see different types of maps, satellite images, and camera footage on the multiple screens. The operator is also to be able to move the cameras to track images on the screen. According to program officials, eventually, when the radars detect potential items of interest, the system is to automatically move the cameras so the operator does not always need to initiate the search in the area. We observed that COP data are also available on laptop computers, known as mobile data terminals, mounted in select agent vehicles in the field. These terminals are to enable field agents to see information similar to that seen by command center operators. Eventually, the COP technology is to be capable of providing distributed surveillance and tactical decision- support information to other DHS agencies and stakeholders external to DHS, such as local law enforcement. Figure 2 shows examples of COP technology in a command station and an agent vehicle. The first SBInet capabilities were deployed under a pilot or prototype effort known as “Project 28.” Project 28 is currently operating along 28 miles of the southwest border in the Tucson Sector of Arizona. Project 28 was accepted by the government for deployment 8 months behind schedule (in February 2008); this delay occurred because the contractor- delivered system did not perform as intended. As we have previously reported, reasons for Project 28 performance shortfalls and delays include the following: System requirements were not adequately defined, and users were not involved in developing the requirements. System integration testing was not adequately performed. Contractor oversight was limited. Project scope and complexity were underestimated. To manage SBInet, DHS established a program office within CBP. The program office is led by a program manager and deputy program managers for program operations and mission operations. The program manager is responsible for the execution of the program, including developing, producing, deploying, and sustaining the system to meet the users’ needs. Among other things, this includes developing and analyzing requirements and system alternatives, managing system design and development, evaluating the system’s operational effectiveness, and managing program risk. A system life cycle management approach typically consists of a series of phases, milestone reviews, and related processes to guide the acquisition, development, deployment, and operation and maintenance of a system. Among other things, the phases, reviews, and processes cover such important life cycle activities as requirements development and management, design, software development, and testing. Based on available program documentation, augmented by program official briefings and statements, key aspects of the SBInet system life cycle management approach are described below. In general, SBInet surveillance systems are to be acquired through the purchase of commercially available products, while the COP systems involve development of new, customized systems and software. Together, both categories are to form a deployable increment of the SBInet capabilities, which the program office refers to as a “block.” Each block is to include a release or version of the COP. SBInet documentation shows that the program office is acquiring the blocks incrementally using a “spiral” approach, under which an initial system capability is to be delivered based on a defined subset of the system’s total requirements. This approach is intended to allow CBP agents access to new technological tools sooner rather than later for both operational use and feedback on needed enhancements or changes. Subsequent spirals or iterations of system capability are to be delivered based on feedback and unmet requirements, as well as the availability of new technologies. Figure 3 illustrates conceptually how the different capabilities are to come together to form a block and how future blocks are to introduce more capabilities. The approach used to design and develop SBInet system capabilities for each block includes such key activities as requirements development, system design, system acquisition and development, and testing. The approach, as explained by program officials and depicted in part in various documents, also includes various reviews, or decision points, to help ensure that these activities are being done properly and that the system meets user needs and requirements. These reviews are to be used in developing both the overall SBInet Block 1 capability and the COP software. Table 1 provides a high-level description of the major reviews that are to be performed in designing and developing the system prior to deployment to the field and in the order that they occur. Before a set of capabilities (i.e., block) is deployed to a specific area or sector of the border, activities such as site selection, surveys, and environmental impact assessments are conducted to determine the area’s unique environmental requirements. The border area that receives a given block, or set of system capabilities, is referred to as a “project.” Each project is to have a given block configured to its unique environmental requirements, referred to as a project “laydown.” The deployment approach is to include such key activities as requirements development, system design, project laydown, integration, testing, and installation. The deployment approach is also to entail various reviews, or decision points, to help ensure that these activities are being done properly and that the system meets user needs and requirements. Table 2 provides a high-level description of the major reviews that are to be part of project laydown in the order that they occur. Among the key processes provided for in the SBInet system life cycle management approach are processes for developing and managing requirements and for managing testing activities. With respect to requirements development and management, SBInet requirements are to consist of a hierarchy of six types of requirements, with the high-level operational requirements at the top. These high-level requirements are to be decomposed into lower-level, more detailed system, component, design, software, and project requirements. Having a decomposed hierarchy of requirements is a characteristic of complex information technology (IT) projects. The various types of SBInet requirements are described in table 3. Figure 4 shows how each of these requirements relate to or are derived from the other requirements. With respect to test management, SBInet testing consists of a sequence of tests that are intended to verify first that individual system parts meet specified requirements, and then verify that these combined parts perform as intended as an integrated and operational system. Such an incremental approach to testing is a characteristic of complex IT system acquisition and development efforts. Through such an approach, the source of defects can be isolated more easily and sooner, before they are more difficult and expensive to address. Table 4 summarizes these tests. Important aspects of SBInet remain ambiguous and in a continued state of flux, making it unclear and uncertain what technology capabilities will be delivered, when and where they will be delivered, and how they will be delivered. For example, the scope and timing of planned SBInet deployments and capabilities have continued to change since the program began and, even now, remain unclear. Further, the approach that is being used to define, develop, acquire, test, and deploy SBInet is similarly unclear and has continued to change. According to SBInet officials, schedule changes are due largely to an immature system design, and the lack of a stable development approach is due to insufficient staff and turnover. The absence of clarity and stability in these key aspects of SBInet introduces considerable program risks, hampers DHS’s ability to measure program progress, and impairs the ability of the Congress to oversee the program and hold DHS accountable for program results.