Radar-guided missile systems emit radio-frequency energy, that is, radar signals, which reflect or bounce off the surfaces of aircraft in flight. In essence, all radar-guided missile systems use these reflected signals to locate and target aircraft. The Army currently has two types of radar countermeasure systems fielded on its helicopters to defend them from radar-guided missiles. The first type seeks to decoy the missile away from the aircraft by providing alternative reflected radar signals for the missile to follow. This is accomplished by using a missile warning system that detects approaching missiles and signals countermeasure dispensers on the aircraft to launch chaff in an attempt to confuse the missile’s radar.The second type of countermeasure system uses a radar-warning receiver and radar jammer to defeat radar-guided missile systems. A radar-warning receiver detects radar-guided missile systems so the aircraft’s pilot can navigate out of the missile’s range. If the systems cannot be avoided, a radar jammer emits electronic radio-frequency transmissions to confuse and/or blind the radar-guided missile system. The Army’s Suite of Integrated Radio Frequency Countermeasures system will include an advanced-threat radar-warning receiver and an advanced- threat radar jammer. (See figure 1.) These components are expected to provide state-of-the-art-radar warning and jamming capabilities and to perform better than the Army’s currently fielded radar warning receivers and radar jammers. The advanced-threat radar-warning receiver will provide enhanced situational awareness by more precisely detecting, identifying, locating, and tracking multiple radio-frequency threat systems. Likewise, the advanced-threat radar jammer is expected to counter multiple and simultaneous modern radio-frequency threats. In addition, the system can be reprogrammed to defeat different threat systems, and its modular open architecture allows for reconfiguring its components so that applications on multiple aircraft types are possible. For acquiring electronic warfare systems such as the new radar countermeasures system, departmental guidance states that developmental testing provides decisionmakers with knowledge about whether the system is ready to begin low-rate initial production—the next step in the acquisition process after engineering and manufacturing development. Developmental testing begins in a controlled environment by testing individual components of a system in the laboratory. Based on the results of this testing, individual components are modified, improved and/or replaced until they meet component-level performance requirements. After the performance of each component is tested and validated, the developmental test process is repeated at the subsystem and finally system level. The developmental test process continues until the system’s ability to meet performance requirements when installed on a weapon system platform is tested and validated. According to the Department’s guidance for acquiring systems, low-rate initial production is designed to (1) establish an initial production base for the system and ensure adequate and efficient manufacturing capability, (2) produce the minimum quantity necessary to provide production configured or representative articles for initial operational testing and evaluation, and (3) permit an orderly increase in the production rate for the system sufficient to lead to full-rate production upon the successful completion of operational testing. Operational testing, which follows developmental testing, is designed to determine whether a production- configured system can meet performance requirements in an operationally realistic environment. The Army’s contractor for its new radar countermeasures system has substantial software and hardware changes under way to improve the system’s performance and address the obsolescence of parts, reduce cost, and improve producibility. The Army intends to determine that the modified software performs as required in time for the low-rate initial production decision now scheduled for some point from January through March 2002. However, the current schedule does not provide for completion and integration of the hardware changes into the system until June 2002 with testing completed by September 2002. Beginning in 1999, laboratory testing of developmental prototypes of the new radar countermeasures system indicated that significant software deficiencies had to be corrected before the system could meet performance requirements. Because of these software deficiencies, the prototype countermeasures system could not properly perform any of its major functions; that is, it could not properly detect, identify, track, or defeat threat radars. In response to these results, the Army’s Program Manager directed the system contractor to undertake the major software maturation effort that is now under way. For the software maturation effort, the Army directed the contractor to follow a disciplined maturation process. This involved breaking down the system’s software into a series of 10 blocks with each successive block introducing more complex functionality (e.g., detect and identify one radar; detect and identify multiple radars; detect, identify and jam one radar; and so forth). To ensure that the contractor adheres to this process, the Army does not approve the introduction of succeeding software blocks into the system until the functionality of the prior block has been demonstrated in the Army’s laboratory at Fort Monmouth, New Jersey. According to the Defense Contract Management Agency, which the Army has engaged to oversee the program, the ongoing software maturation effort, as of April 2001, has been rated as high risk. Laboratory tests indicate that the software continues to have difficulty in properly detecting, identifying, tracking, and defeating threat-radar systems in complex environments where many radars are operating simultaneously. Moreover, according to the Agency, flight-testing on an Apache helicopter has begun recently and a new set of software problems is being experienced because the operating environments of the aircraft and open- air test range are very different than the controlled conditions of the laboratory. For instance, interference resulting from the simultaneous operation of the system with the Apache’s fire control radar is resulting in system resets. Resets are totally unacceptable for countermeasure systems because they refer to instances when the software causes the system to reboot. While the system is rebooting, the aircraft and aircrew are completely unprotected. Overall, the software maturation effort is 4 months behind schedule, and the contractor has been submitting increasing numbers of unanticipated software change requests each month for the past 6 months as the software blocks are becoming more complex. Change requests have increased each month from September 2000, when they numbered 699, to March 2001, when they reached 923. The need to make unanticipated changes is expected in a software maturation process, according to the Defense Contract Management Agency; nonetheless, increasing numbers of changes result in additional cost to the program and the extension of test schedules. Of the 10 software blocks, blocks 1 through 8a have now been accepted, and the contractor was scheduled to deliver block 9 for testing in April 2001. (Block 8 did not pass acceptance testing at Fort Monmouth, so the contractor had to create block 8a, which was accepted by the Army in March 2001.) While software maturation continues under the original developmental contract, the contractor is addressing hardware improvements under a separate $13.2 million technology insertion program contract to redesign, develop, and test new system components. The contractor plans to complete and integrate hardware changes into the system by June 30, 2002. The Army then plans to determine whether the modified system performs as required by September 2002. According to the contractor, replacing key hardware components of the current prototype system is necessary to reduce costs, address the obsolescence of electronic parts, enhance producibility and improve system performance. The contractor is developing replacements for such components as the primary computer processor, the tracker used to locate radar sources, and the frequency synthesizer used to produce the electronic responses to hostile radar signals. The contractor is also replacing the analog wide-band receiver used to detect radar signals with an improved receiver based on digital technology. (See figure 2.) As of April 2001, the Defense Contract Management Agency was rating hardware issues and the system’s readiness for production as moderate risk. According to the Agency, the bases for this assessment include staffing shortages, parts delivery delays, and failures during electromagnetic interference, shock/vibration, and humidity testing, all of which are delaying the contractor’s schedule. Besides physical changes to the system, hardware changes will cause additional changes to be made to the system’s software. This is because the hardware functions of the system are software-controlled. In order to exercise this control, the software has to be written to “recognize” the behavior of the new components so the right software commands are issued and the hardware will do what it is supposed to do at the right time. Additionally, while making changes to hardware components and software, the contractor discovered carcinogenic beryllium oxide residue on the system during humidity testing. To address this problem, the contractor is now developing and testing aluminum component casings for beryllium casings that had already been developed. Substituting aluminum for beryllium is troublesome because (1) aluminum is weaker and heavier than beryllium and (2) the weight of the radar countermeasures system was already more than 20 pounds over the Army’s requirement even with use of the lighter beryllium casings. Department officials told us that the insertion of the hardware modifications is not substantial enough to constitute a significant design change and that little risk is associated with the integration of the new hardware with the software and the aircraft. However, based on test results to date and monthly status reports from the Defense Contract Management Agency, we did not find that integrating the new hardware with the software and the aircraft will be a low-risk undertaking. According to departmental guidance for acquiring systems, one of the purposes of low-rate initial production is to produce production representative articles for initial operational test and evaluation. In our view, a key to assuring that these articles will be production representative is to first conduct developmental testing of the modified software and hardware together as a system in the aircraft to ensure the design is stable before beginning low-rate initial production. We believe, therefore, that the Department would decrease its risks by deferring the low-rate initial production decision until the hardware modifications are completed and integrated and the system is found to perform as required. Only the testing of the actual replacement components can provide assurance that the system’s design is stable.