Defense Acquisitions
Significant Challenges Ahead in Developing and Demonstrating Future Combat System's Network and Software Gao ID: GAO-08-409 March 7, 2008The Army's Future Combat System (FCS) requires a software-based advanced information network to meld people, sensors, and weapons into a cohesive fighting force. As software controls 95 percent of FCS's functionality, it determines the success or failure of the program. The Army contracted with the Boeing Company as a lead systems integrator (LSI) to define, develop and integrate FCS, including software development. GAO must by law report annually on FCS. This is one of two reports to meet this requirement. It addresses risks facing the development of network and software, the practices being used to manage software, and the timing of key network demonstrations. In conducting our work, GAO has contacted numerous DOD, Army, and contractor offices; reviewed technical documents on software and network development and plans; attended meetings; and spoken to Army and other officials on various aspects of FCS network and software development. GAO also performed detailed work at five FCS software developers.
Almost 5 years into the program, it is not yet clear if or when the information network that is at the heart of the FCS concept can be developed, built, and demonstrated by the Army and LSI. Significant management and technical challenges have placed development of the network and software at risk. These risks include, among others, network performance and scalability, immature network architecture, and synchronization of FCS with Joint Tactical Radio System and Warfighter Information Network Tactical programs that have significant technical challenges of their own. Software being developed for the network and platforms is projected to total 95.1 million lines of computer code, almost triple the size since the program began in 2003. FCS's software is about four times larger than the next two largest software-intensive defense programs. Although several disciplined practices are being used to develop FCS's network and software, the program's immaturity and aggressive pace during development have delayed requirements development at the software developer level. For example, software developers for 5 major software packages that GAO reviewed report that high-level requirements provided to them were poorly defined, late, or omitted in the development process. This caused the software developers to do rework or defer functionality out to future builds. In turn, these poor or late requirements had a cascading effect that caused other software development efforts to be delayed. It is unclear when or how it can be demonstrated that the FCS network will work as needed, especially at key program junctures. For example, in 2009, network requirements, including software, may not be adequately defined nor designs completed at the preliminary design review; and at the FCS milestone review later that year, network demonstration is expected to be very limited. The first major FCS network demonstration--the limited user test in 2012--will take place at least a year after the critical design review and only a year before the start of FCS production. That test will seek to identify the impact of the contributions and limitations of the network on the ability to conduct missions. This test will be conducted after the designs have been set for the FCS ground vehicles, which poses risks because the designs depend on the network's performance. A full demonstration of the network with all of its software components will not be demonstrated until at least 2013 when the fully automated battle command system is expected to be ready.
RecommendationsOur recommendations from this work are listed below with a Contact for more information. Status will change from "In process" to "Open," "Closed - implemented," or "Closed - not implemented" based on our follow up work.
Director: Team: Phone:GAO-08-409, Defense Acquisitions: Significant Challenges Ahead in Developing and Demonstrating Future Combat System's Network and Software
This is the accessible text file for GAO report number GAO-08-409
entitled 'Defense Acquisitions: Significant Challenges Ahead in
Developing and Demonstrating Future Combat System's Network and
Software' which was released on March 11, 2008.
This text file was formatted by the U.S. Government Accountability
Office (GAO) to be accessible to users with visual impairments, as part
of a longer term project to improve GAO products' accessibility. Every
attempt has been made to maintain the structural and data integrity of
the original printed product. Accessibility features, such as text
descriptions of tables, consecutively numbered footnotes placed at the
end of the file, and the text of agency comment letters, are provided
but may not exactly duplicate the presentation or format of the printed
version. The portable document format (PDF) file is an exact electronic
replica of the printed version. We welcome your feedback. Please E-mail
your comments regarding the contents or accessibility features of this
document to Webmaster@gao.gov.
This is a work of the U.S. government and is not subject to copyright
protection in the United States. It may be reproduced and distributed
in its entirety without further permission from GAO. Because this work
may contain copyrighted images or other material, permission from the
copyright holder may be necessary if you wish to reproduce this
material separately.
GAO:
March 2008:
United States Government Accountability Office:
Report to Congressional Committees:
Defense Acquisitions:
Significant Challenges Ahead in Developing and Demonstrating Future
Combat System's Network and Software:
FCS Software:
GAO-08-409:
GAO Highlights:
Highlights of GAO-08-409, a report to Congressional Committees.
Why GAO Did This Study:
The Army‘s Future Combat System (FCS) requires a software-based
advanced information network to meld people, sensors, and weapons into
a cohesive fighting force. As software controls 95 percent of FCS‘s
functionality, it determines the success or failure of the program. The
Army contracted with the Boeing Company as a lead systems integrator
(LSI) to define, develop and integrate FCS, including software
development.
GAO must by law report annually on FCS. This is one of two reports to
meet this requirement. It addresses risks facing the development of
network and software, the practices being used to manage software, and
the timing of key network demonstrations.
In conducting our work, GAO has contacted numerous DOD, Army, and
contractor offices; reviewed technical documents on software and
network development and plans; attended meetings; and spoken to Army
and other officials on various aspects of FCS network and software
development. GAO also performed detailed work at five FCS software
developers.
What GAO Found:
Almost 5 years into the program, it is not yet clear if or when the
information network that is at the heart of the FCS concept can be
developed, built, and demonstrated by the Army and LSI. Significant
management and technical challenges have placed development of the
network and software at risk. These risks include, among others,
network performance and scalability, immature network architecture, and
synchronization of FCS with Joint Tactical Radio System and Warfighter
Information Network Tactical programs that have significant technical
challenges of their own. Software being developed for the network and
platforms is projected to total 95.1 million lines of computer code,
almost triple the size since the program began in 2003. As shown, FCS‘s
software is about four times larger than the next two largest software-
intensive defense programs.
Figure: Comparison of FCS Software Size to the Next Largest Software
Intensive Defense Programs:
This figure is a bar graph showing a comparison of FCS software size to
the next largest software intensive defense programs.
Joint Strike Fighter: 22.9;
Multi-mission Maritime Aircraft: 24.5;
Future Combat System: 95.1.
[See PDF for image]
Source: Army, Navy, Air Force (data); GAO (analysis and presentation).
[End of figure]
Although several disciplined practices are being used to develop FCS‘s
network and software, the program‘s immaturity and aggressive pace
during development have delayed requirements development at the
software developer level. For example, software developers for 5 major
software packages that GAO reviewed report that high-level requirements
provided to them were poorly defined, late, or omitted in the
development process. This caused the software developers to do rework
or defer functionality out to future builds. In turn, these poor or
late requirements had a cascading effect that caused other software
development efforts to be delayed.
It is unclear when or how it can be demonstrated that the FCS network
will work as needed, especially at key program junctures. For example,
in 2009, network requirements, including software, may not be
adequately defined nor designs completed at the preliminary design
review; and at the FCS milestone review later that year, network
demonstration is expected to be very limited. The first major FCS
network demonstration”the limited user test in 2012”will take place at
least a year after the critical design review and only a year before
the start of FCS production. That test will seek to identify the impact
of the contributions and limitations of the network on the ability to
conduct missions. This test will be conducted after the designs have
been set for the FCS ground vehicles, which poses risks because the
designs depend on the network‘s performance. A full demonstration of
the network with all of its software components will not be
demonstrated until at least 2013 when the fully automated battle
command system is expected to be ready.
What GAO Recommends:
GAO recommends that the Secretary of Defense direct the program to
stabilize network and software requirements on each build to enable
adherence to disciplined practices and establish clear criteria on
acceptable network performance and demonstrations at each of the key
program events. DOD concurred with GAO‘s recommendations.
To view the full product, including the scope and methodology, click on
[hyperlink, http://www.GAO-08-409]. For more information, contact Paul
L. Francis at (202) 512-4841 or francisp@gao.gov.
[End of section]
Contents:
Letter:
Results in Brief:
Background:
Unclear If or When the Army Can Develop, Build, and Demonstrate the FCS
Network:
Software Practices Have Been Adopted, but Implementation Has Been
Hampered by Evolving Requirements:
Uncertainty about Network Development and Demonstration Present
Challenges for Decisionmakers at Key Program Events:
Conclusions:
Recommendations for Executive Action:
Agency Comments and Our Evaluation:
Appendix I: Scope and Methodology:
Appendix II: Comments from the Department of Defense:
Appendix III: List of FCS Software (Network & Non-network) Packages
Developed by Contractors (as of July 2007):
Appendix IV: GAO Contact and Staff Acknowledgments:
Related GAO Products:
Tables:
Table 1: FCS Software Growth Estimates:
Table 2: Software Packages and Associated Requirements Problems:
Figures:
Figure 1: Examples of Sensors for FCS Brigade Combat Teams:
Figure 2: Visual Depiction of How the Warfighter Could See the
Battlefield:
Figure 3: JTRS Radios for FCS Platforms:
Figure 4: Comparison of FCS Software SLOC Size to Other Major Defense
Programs:
Figure 5: Traditional Spiral Development Illustration:
Figure 6: FCS Spiral Development Strategy and Software Life Cycle
Reviews:
Abbreviations:
BCT: Brigade Combat Team:
DOD: Department of Defense:
FCS: Future Combat System:
JTRS: Joint Tactical Radio System:
LSI: lead systems integrator:
SOSCOE: System of Systems Common Operating Environment:
WIN-T: Warfighter Information Network-Tactical:
United States Government Accountability Office:
Washington, DC 20548:
March 7, 2008:
Congressional Committees:
The Army's transformation to a lighter, more agile, better equipped,
and more lethal and survivable combat force--the Future Combat System
(FCS) program, which comprises 14 integrated weapon systems--depends on
successfully developing an advanced information network that links
people, platforms, weapons, and sensors together. The FCS program is
considered by the Army to be the greatest technology and integration
challenge that they have ever undertaken and the network may be the
most important element of FCS. In order to make this leap, software and
technology must be developed that will allow the network to (1)
collect, process, and deliver vast amounts of information such as
imagery and communications; (2) seamlessly link people and systems; and
(3) integrate and enhance the individual performance of the systems
themselves. Because software is expected to control about 95 percent of
FCS's functionality, it is the linchpin to the success or failure of
the program. The magnitude, size, and complexity of the network and
software development are unprecedented in the Department of Defense's
(DOD) history. To help them with this ambitious endeavor, the Army
contracted with the Boeing Company as the lead systems integrator (LSI)
in 2003 to define, develop, and integrate FCS, including software
development that is being done in cooperation with the FCS program
office.
Given its cost, scope, and technical challenges, section 211 of the
National Defense Authorization Act for Fiscal Year 2006 requires GAO to
report annually on the FCS program.[Footnote 1] As one of two reviews
conducted this year by GAO under this authority, this report addresses
(1) challenges and technological risks that could hamper successful
development of the network and software, (2) whether disciplined
software practices have been effectively implemented for managing
development of FCS's network and software, and (3) whether the Army
will have the necessary network and software at key program events such
as preliminary design review, critical design review, and start of FCS
production. A second report addresses the specific elements of section
211 to include FCS development, production, and cost issues.[Footnote
2]
In conducting our work, we have contacted numerous DOD, Army, and
contractor offices. We also conducted detailed work and held
discussions with selected contractors on their efforts to develop five
major software packages that are to operate the network, training,
combat identification, and other elements for FCS. We reviewed
technical network and software plans, assessments, and studies
pertaining to the FCS program, attended meetings at which DOD and Army
officials reviewed program progress, and held discussions with key Army
and LSI officials on various aspects of the network and software
development for FCS. Officials from DOD, Army, and LSI have provided us
access to sufficient information to make informed judgments on the
matters in this report. In addition, we drew from our body of past work
on weapon systems acquisitions practices and software development best
practices. We conducted this performance audit from July 2007 to March
2008 in accordance with generally accepted government auditing
standards. Those standards require that we plan and perform the audit
to obtain sufficient, appropriate evidence to provide a reasonable
basis for our findings and conclusions based on our audit objectives.
We believe that the evidence obtained provides a reasonable basis for
our findings and conclusions based on our audit objectives. Appendix I
further discusses our scope and methodology.
Results in Brief:
It is not yet clear if or when the Army and LSI can develop, build, and
demonstrate the information network that is at the heart of the FCS
concept. The Army is faced with significant management and
technological challenges that place development of FCS's network and
software at risk. Almost 5 years into the program, the Army and LSI
have not yet fully defined how the FCS network is expected to function,
how they plan to build it, and how they plan to demonstrate it. The
Army and LSI have identified and need to address numerous areas of high
risk such as network performance and scalability, immature network
architecture, and synchronization of FCS with the Joint Tactical Radio
System (JTRS) and Warfighter Information Network Tactical (WIN-T)
programs, which are having difficulty with technology maturation and
are at risk of being delayed or delivering incomplete capabilities to
FCS. Software being developed for the network and platforms by the LSI
and software developers is now projected to total about 95.1 million
lines of computer code, which almost triples the size since the program
began in 2003. A June 2006 report issued by the Secretary of Defense's
Cost Analysis Improvement Group found that the FCS program is at risk
of higher costs due to, among other things, the size and complexity of
the FCS software development program. This group also said the
development schedule is highly likely to take several years beyond the
Army's plan, and the network is at risk because it is tied to JTRS and
WIN-T programs that could cause delays in FCS's development schedule.
Similarly, a recent study by the Institute for Defense Analysis found
that the FCS program would likely experience additional growth in
unplanned software effort, unplanned rework before and after
operational testing, and additional work to address system of systems
integration, validation, and test after the critical design review
point.
While the Army and LSI have implemented several disciplined practices
that have proven successful at leading software companies, such as the
use of repeatable and managed development processes and use of a
structured management review process to ensure quality development, we
found that the immature definition of system-level requirements by the
Army and LSI was causing problems. For example, the software developers
for the five major software packages we reviewed report that high-level
requirements provided to them by the LSI for decomposition and
refinement were poorly defined, omitted, or late in the software
development process. Also, we found that poor or late requirements
development has had a cascading effect as late delivery or poorly
defined requirements on one software development effort, in turn,
caused other software development efforts to be delayed. For example,
four of the five software developers report that problems with late
requirements have caused them to do rework or to defer functionality
out to future builds because of insufficient time. These software
developers report that schedule compression caused much of this strain,
which could have been averted if they had been allowed sufficient time
to adequately understand and analyze the requirements.
It is unclear when or how the Army and LSI will be able to demonstrate
that the network will work as needed, which poses risks for the designs
of individual FCS systems and the ability to assess FCS's viability at
key decision points. For example, it is unclear if network
requirements, including software to be developed, will be adequately
defined and designs completed at the preliminary design review
scheduled for February 2009. To date, only some elementary aspects of
the FCS network, such as basic connectivity have been demonstrated. At
the time of the FCS milestone review in 2009, the extent of network
demonstration is expected to be very limited. For example, the Army
expects to demonstrate some network functions, such as linkage with
remote sensors, during the spinout demonstrations in fiscal year 2008.
Other limited demonstrations are scheduled on a regular basis. However,
the first major demonstration of the FCS network is the limited user
test scheduled for fiscal year 2012, which will be at least a year
after the critical design review and only about a year before the start
of FCS production. This event comes after the vehicle designs on manned
ground platforms have been established. One of the key objectives of
that test will be to identify the contributions and limitations of the
network regarding the ability of the FCS brigade combat team to conduct
missions across the full spectrum of operations. However, the fully
automated battle command system is not expected until 2013 when the
Army expects 100 percent of the network capabilities including software
to be available.
We are making recommendations to the Secretary of Defense regarding the
stabilization of network and software requirements on each build to
enable adherence to disciplined software practices, and establishment
of clear performance criteria for acceptable network performance and
demonstrations at each of the key program events. In commenting on a
draft of this report, DOD concurred with our recommendations.
Background:
The advanced information network is the heart of the Army's FCS concept
and is intended to allow fielded FCS Brigade Combat Teams (BCT) to see
the enemy first, understand the situation first, act first, and finish
decisively. The FCS network management system to be deployed to the
Army's BCT is envisioned to: (1) plan and manage multi-technology
mobile tactical communication; (2) encompass satellite, aerial and
ground communication assets that provide multi-media voice, data, and
video services to all elements of the FCS BCT; and (3) interface with
terrestrial, aerial, and satellite assets of an Army division. If the
FCS network works as intended, all commanders in the BCT and throughout
areas of operations will have a common set of data that will allow for
the synchronization of many BCT activities including the integration of
fire and maneuver, intelligence collection, fusion, and dissemination,
and sustainment of the force. The Army envisions that the network
architecture would also permit connectivity with other military
services, thus allowing additional situational awareness and
understanding, and synchronized operations that are unachievable by
current systems.
FCS-equipped BCTs are to have significant warfighting capabilities that
differ substantially from the large division-centric structure. The
survival and combat effectiveness of FCS BCTs are critically dependent
on the ability to see first, understand first, act first, and finish
decisively. Through an advanced information network, the concept is to
replace mass with superior information that will allow soldiers to see
and hit the enemy first rather than to rely on heavy armor to withstand
a hit. This new way of fighting solely depends on developing an
information network that can successfully link the people, platforms,
weapons, and sensors seamlessly together in a system of systems. This
new way of fighting can be achieved only if the data can be made
available in near real-time at sensor processors, at the battle command
nodes, and at lethal systems. For example, FCS's survivability depends
on the brigade-wide availability of the network-based situational
awareness plus the inherent survivability of the FCS platforms.
FCS Network Elements:
Elements of the FCS information network will include the software and
technology (applications, computers, and radios) that will link the
people, platforms, weapons, and sensors together. These elements are
expected to provide delivery of voice, data, video, still images, and
network control services wirelessly over a mobile ad hoc
network.[Footnote 3] In contrast to traditional wireless systems such
as cellular phones that connect to a fixed station or permanent access
point, FCS's ad hoc network will not have access to such an
infrastructure. Thus, the quality of service--the capability to
transport information across the network while satisfying communication
performance requirements such as low delay, low loss, or high
throughput--becomes critically important and challenging due to limited
available bandwidth.[Footnote 4] Essentially, tasks like mission
planning, platform and soldier logistics management, battlespace
analysis, collaboration, fire and effect controls, and network
management will be done on the move. All of the 14 FCS platform types-
-manned ground vehicles, unmanned ground vehicles, unmanned air
vehicles, and unattended ground sensors--are expected to have network
elements that will enable them to share information and coordinate with
one another. These elements include:
Sensors. Sensors are the hardware and software that will provide FCS
with the ability to "see first" and achieve situational awareness and
understanding of the battlefield. These sensors will include such
functions as search and detection of enemy fire, personnel, munitions,
minefields, and terrain. The intelligence, surveillance and
reconnaissance sensors will be integrated onto all manned and unmanned
ground vehicles and aerial platforms, and will be capable of
accomplishing a variety of missions that include, among others,
surveillance over wide areas and target detection, enabling
survivability. The unmanned aerial vehicles will be able to maneuver to
an area of attack and the on-board sensors will provide surveillance of
targets and terrain, among other functions. There are two types of
unattended ground sensor systems that FCS will use--the tactical
unattended ground sensors will provide intelligence, surveillance, and
reconnaissance awareness to the BCTs, while urban unattended ground
sensors will support clearing operations in confined spaces or urban
chokepoints. According to the Army, complex data processing, filtering,
aided target recognition, and fusion will be supported by software to
provide warfighters with vital information. For example, the sensor
data management software will organize the sensor data and track the
information received from sensors. Figure 1 shows some types of FCS
sensors.
Figure 1: Examples of Sensors for FCS Brigade Combat Teams:
This is a figure of a combination pictures of examples of sensors for
FCS brigade combat teams. The pictures are of an electro-optical sensor
on aerial platforms, an electo-optical sensor on ground combat
platforms, and unattended ground sensors.
[See PDF for image]
Source: U.S. Army.
[End of figure]
Software. Software is expected to control about 95 percent of FCS's
functionality and will be included in all FCS platforms. In its
simplest form, software is the collection of computer programs and
procedures that perform some task on a computer system or platform. It
includes: (1) system software such as operating systems, which
interface with hardware to provide the necessary services for
application software; (2) middleware, which controls and coordinates
distributed systems; and (3) application software such as word
processors, which perform productive tasks for users. Overall
development of FCS software is being managed by the LSI in cooperation
with the Army's FCS Program Office. There are over 100 software vendors
involved in the development of software programs for FCS, including the
LSI, 14 first-tier contractors, and other sub-contractors.
Over 75 percent of software being developed for FCS is to operate the
network. Network software is expected to integrate the collection of
individual systems into a system of systems. This software will include
the System of Systems Common Operating Environment (SOSCOE), Network
Management System, Battle Command and Mission Execution, Sensor Data
Management, Warfighter Machine Interface[Footnote 5], and others. These
will be included on all the FCS platforms and will perform a variety of
functions. For example, software on platforms is to control the
individual systems, such as radios and air and ground vehicle
communications. SOSCOE is the operating environment that serves as the
middleware between the operating systems and the software applications,
integrating all other FCS software. The Battle Command software is to
provide functions such as mission planning and preparation, situational
understanding, and battle management and mission execution. Warfighter
Machine Interface software is expected to provide the visual interface
of the network to the warfighter. According to the Army, Warfighter
Machine Interface is "the face of the FCS network," which includes the
display of services, touch screens, and buttons. It will provide a
visual picture of the battlespace and allows the ability to collaborate
across the forces. Figure 2 shows how the warfighter may see the
battlefield through the network.
Figure 2: Visual Depiction of How the Warfighter Could See the
Battlefield:
This figure is a picture of a visual depiction of how the warfighter
could see the battlefield.
[See PDF for image]
Source: U.S. Army.
[End of figure]
Integrated Computing System. The integrated computing system is the on-
board computer that will fit into the various FCS platforms. There are
eight types of Integrated Computing Systems that vary in size to fit
into the various FCS platforms--manned ground vehicles, unmanned aerial
vehicles, and unattended ground vehicles. The computing system is
expected to provide an integrated common operating environment to
manage processing, secure the system, and allow access to the network
on the move. It is also envisioned to support battle command
applications, sensor processing, communications, weapons and platform
management, and have embedded security and safety features that will
help ensure a secure operating environment with certified firewall and
network intrusion protection.
Joint Tactical Radio System (JTRS)/Warfighter Information Network-
Tactical (WIN-T). The Army plans to use the JTRS and WIN-T radios that
employ "software-defined radio" technology in which many functions are
performed by computer processing and technology. These and other
critical software-intensive technologies are being developed outside of
FCS control--termed complementary programs--and are expected to
interoperate with existing systems and provide additional
communications capability. The JTRS family of software-based radios is
to provide the high-capacity, high-speed information link to vehicles,
weapons, aircraft, sensors, and soldiers, while WIN-T is to provide
high bandwidth connectivity to Army units on the move with higher
levels of command to other forces, and provide the Army's tactical
extension to the Global Information Grid.[Footnote 6] Such capabilities
include access to maps and other visual data, communication via voice
and video with other units and levels of command, and the acquisition
of information directly from battlefield sensors. The JTRS family of
programs includes the Ground Mobile Radios that are being developed for
vehicles. Smaller JTRS Handheld, Manpack, and Small Form Factors radios
are being developed that will be carried by soldiers and embedded in
several FCS core systems. Software will be used to control how JTRS
radios will work. For example, JTRS radios will use two software
waveforms[Footnote 7] called the Wideband Networking Waveform and
Soldier Radio Waveform. The function of the Wideband Networking
Waveform software is to provide communications signals, routing,
transport, network management, quality of service, information
assurance, transport, and mobility. The Soldier Radio Waveform is being
developed for JTRS radios--ground mobile radio, and handheld manpack
and small form factors radios--and will primarily be used for tactical
networking by soldiers, unattended systems, and embedded radios in
munitions. Because FCS has unique applications and networking needs,
the program is responsible for integrating these into their distributed
applications that are running on SOSCOE. Figure 3 shows the JTRS
radios.
Figure 3: JTRS Radios for FCS Platforms:
This figure is a picture of JTRS radios for FCS platforms.
[See PDF for image]
Source: U.S. Army.
[End of figure]
Unclear If or When the Army Can Develop, Build, and Demonstrate the FCS
Network:
The Army is faced with significant management and technological
challenges that place development of the FCS network at risk. All of
the projected FCS capabilities are heavily dependent on wide
availability and high performance of the network. Further, preliminary
design of the network is still being matured and much development and
integration of the network hardware and software remains. It has taken
almost 5 years for the Army and LSI to develop an understanding of what
the network needs to be, what may be technically feasible, how to build
it, and how to demonstrate it. In addition, the definition of the
detailed network requirements is still not complete and there are
numerous risks that must be overcome, such as the constraints imposed
by a mobile ad hoc network, gaps between FCS network design and
complementary program requirements, and interoperability issues with
strategic networks of the Global Information Grid. While progress has
been reported on software development, the continued growth in software
code and underestimation of what it will take to develop and integrate
software poses risk to the successful development of the network.
Army Has Reached Understanding of the Network:
Although maturity of network design is still a work in progress (i.e.,
numerous high risks remain and full network demonstration is years
away), the Army has achieved an understanding of what the network needs
to be, what may be technically feasible, how to build it, and how to
demonstrate it. However, in addition to challenges and risks that need
to be addressed, much learning and work remains before the Army and LSI
can mature the network. For example, the Army and LSI are still
determining what network management means in terms of: (1) what is
needed to support each specific mission (radios, routers, satellites,
computers, information assurance devices, and policies); (2) how to
allocate network resources to the mission spectrum; and (3) how to
fuse, process, and present extensive FCS sensor data to appropriate
users. They are also learning how to maintain the network, such as
monitoring the status and performance of the network (hardware faults,
network quality of service, and overall performance); managing the
spectrum to ensure connectivity; avoiding interference; and
reconfiguring the network in real-time based on changing network
conditions and mission critical traffic.
To provide managed communication services between the soldiers,
platforms, and sensors to complete military missions successfully, the
Army must decide what information the individual users will need and
its priority, where that information may reside, and how and when to
get it to the user. For example, current plans call for the network
supporting a BCT to include more than 5,000 nodes on over 1,500 radio
sets running at least four different advanced networking waveforms,
supporting networks and sub-networks interconnected by gateways, and
carrying 3 million identified, point-to-point information exchange
requirements.[Footnote 8] The Army's FCS program office provides that
the primary interface types for FCS will include discovery, publish/
subscribe, and multi-cast methods. Given the reality that the amount of
traffic to be sent over the network may exceed its capacity, assuring
end-to-end quality of service over the network presents a major
challenge. The Army and LSI have undertaken studies to better
understand it.
Mobile Adhoc Networks Have Inherent Constraints:
The Army and LSI are in the midst of developing the next generation of
wireless communications, referred to as the mobile ad hoc network,
which is a fundamentally new capability that presents a host of
technical challenges. For example, the mobile ad hoc network will
operate with lower network capacity and have fewer options for
increasing capacity due to limitations on the amount of radio frequency
that is available. Performance of the ad hoc network is expected to
decrease as more radios or nodes are added and eventually can reach an
unacceptable level. That is, the size of the network may reach a
maximum when all fixed capacity is consumed for routing traffic from
other radios or nodes and no capacity is available for local
consumption. In a network of limited capacity, decisions need to be
made on how to control admission to the network, account for network
resources, ensure end-to-end services basis, and do so in a mobile ad
hoc network environment with varying routes and link capacities. As a
result, the Army and LSI are working on how best to allocate functions
throughout the FCS system of systems.
Further, unlike common wireless systems that have access to the
Internet--such as cellular and wireless networking protocols where
every node is connected directly to the network by a single local
wireless link--the FCS information network will change dynamically as
the mobile nodes are expected to be able to communicate with each
other, while on the move. In the FCS information network, most network
nodes will not have local access to the network. Thus, each radio must
also be a router, meaning that it is responsible for passing traffic
(voice, data, and video) from other radios as well as traffic local to
the radio. As a result, networking becomes extremely difficult for the
following reasons:
* The FCS information network is wireless and, consequently, the
bandwidth limits the availability of the radio frequency spectrum.
* A mobile ad hoc network has known characteristics that pose
difficulties in providing quality of service such as, among others, the
lack of precise information about network performance, lack of central
control, and insecure media over the network.
The research community is still studying various approaches and trade-
offs to these open problems because they are not yet fully understood.
Because these problems have not been solved and are not supported by an
existing and proven technology base, there is serious concern whether
the Army and LSI can overcome them within the current schedule.
Network Risks Identified:
While some progress is being made to understand what the network needs
to be, how to build it, and how to demonstrate it, the Army and LSI
have identified major technical and integration risks to be addressed
in order to meet overall FCS requirements. In July 2007, the Army and
LSI reported their findings from a network review that identified 7
high-risks and 16 medium-risks, totaling 23 risks specific to the FCS
network. Although Army and LSI officials are confident that such risks
can be addressed, the scale and complexity of what is involved is
without precedent. Among others, network risks include:
* Enterprise network performance and scalability. There is a high
likelihood that the FCS network performance will be affected because ad
hoc networks have limited scalability, and performance decreases as
more radios are added.
* End-to-end quality of service on mobile ad hoc networks. The
probability is high that the FCS network will not be able to ensure
that the information with the highest value is delivered on time to the
intended recipients. Failure to support the warfighter in defining and
implementing command intent for information management will result in
substantially reduced force effectiveness. These capabilities are
dependent on actual performance of JTRS and WIN-T, both of which have
their own technology, development, and programmatic difficulties and
are at risk of being delayed or delivering incomplete capabilities. The
FCS Program Office and LSI are working closely with program offices
responsible for managing these complementary programs, but
synchronization of the detailed requirements is still problematic.
* End-to-end interoperability with strategic networks of the Global
Information Grid. The requirements of interoperability with strategic
networks of the Grid will be another challenge. Given the already
stressed conditions envisioned for FCS tactical networks,
interoperability with strategic networks will be technically
challenging.
* Soldier radio waveform availability. The soldier radio waveform
provides functional capability that is needed to support many FCS
systems but may not be completed in time to support FCS. These
capabilities facilitate interoperability functions between the FCS
family of systems. The development of waveforms remains a technically
challenging and lengthy effort, which involves complex software
development and integration work. The program has already experienced
schedule delays, cost increases, and requirements changes. As such,
these functional capabilities are critical to FCS's performance and
these delays will negatively impact the schedule.
* System of Systems Common Operating Environment availability and
maturity. There is recognized risk that SOSCOE may not reach the
necessary maturity level required to meet program milestones. There are
also recognized risks associated with interoperability of the software
and dissemination of data to the mobile ad hoc network.
* Software productivity. There is recognized high risk that the LSI and
its contractors may not be able to build, test, and integrate as much
software as planned in the projected times. If software productivity
falls short of planned efforts, the overall software build schedules
will be impacted by 2 to 4 months, and integration will also be
correspondingly impacted.
Software Code Estimates Continue to Grow:
The amount of estimated software code required for FCS has recently
increased to 95.1 million lines. This is nearly triple the original
estimate made in 2003 and the largest software effort by far for any
weapon system. Software code is difficult to estimate and
underestimation is not unique to FCS. Compounding this inherent
difficulty on FCS were the program's poorly defined requirements,
indicative of its immaturity. Lines of code have grown as requirements
have become better understood. While the Army believes the latest
increases will not command higher costs, independent estimates suggest
otherwise.
The Army and LSI continue to underestimate the size of software needed
for FCS. Studies show this is a common mistake made by defense and
private industry that develop software-intensive systems, which can
lead to longer schedules and increased cost. Apart from the sheer
difficulty of writing and testing such a large volume of complex code,
a number of risks face the FCS software development effort. As
requirements have become better understood, the number of lines of code
has grown significantly since the program began in 2003. Table 1 shows
FCS code growth for total source lines of code[Footnote 9] (SLOC) and
the effective source lines of code[Footnote 10] (ESLOC).
Table 1: FCS Software Growth Estimates:
Numbers in millions of source lines of code.
SLOC;
Numbers in millions of source lines of code: Original estimate (May
2003): 33.7;
Numbers in millions of source lines of code: Revised estimate (as of
January 2006): 63.8;
Numbers in millions of source lines of code: Revised estimate (as of
August 2007): 95.1;
Numbers in millions of source lines of code: Percentage increase: 182.
ESLOC;
Numbers in millions of source lines of code: Original estimate (May
2003): 12.8;
Numbers in millions of source lines of code: Revised estimate (as of
January 2006): 17.1;
Numbers in millions of source lines of code: Revised estimate (as of
August 2007): 19.6;
Numbers in millions of source lines of code: Percentage increase: 53.
Source: U.S. Army (data); GAO (analysis and presentation).
[End of table]
Since May 2003, projected SLOCs have increased by 61.4 million to an
estimated 95.1 million lines of computer software code, almost triple
in size compared to original estimates. Similarly, ESLOCs increased by
6.8 million to 19.6 million lines of computer software code, a 53
percent increase. Since January 2006, both SLOC and ESLOC estimates
have significantly increased. For example, SLOC estimates increased by
31.3 million lines of computer code, or about 50 percent, while ESLOC
estimates increased by 2.5 million lines of computer code, or about 15
percent. Army officials attributed this surge to operating system
software that was greatly underestimated in 2003 when the program
began. These latest estimates now include operating system software
that will be used on the integrated computer system.
While the Army and LSI have completed the first software build--and
were close to completing the second of five total software builds at
the time of our review--each build required more "actual" software
coding than was originally estimated, further indicating that efforts
on what it will take to develop and integrate software may be more than
planned. For example, the ESLOCs for Build "0" increased 6 percent from
an estimated 0.96 million to 1.02 million actual source lines of
computer code. Similarly, at the time of our review, ESLOCs for Build
"1" increased 17 percent from an estimated 5.3 million lines of code to
6.2 million lines of computer code.[Footnote 11] Army officials
maintain that these increases will not have a major impact on the
program. However, experiences of other organizations that develop
software-intensive systems suggest otherwise, according to leading
experts who conducted extensive research of over 20,000 software
development projects spanning 18 years. For example, poor size
estimation is one of the main reasons that major software-intensive
acquisition programs ultimately fail. In fact, the defense industry,
private sector, and academia note that software size is a critical
factor in determining cost, schedule, and effort, and failure to
accurately predict software size results in cost overruns and late
deliveries. According to guidance made available by the Software
Technology Support Center at Hill Air Force Base[Footnote 12] for
defense organizations that develop software, deviations in software
size data indicate problems with:
* faulty software productivity estimates;
* requirements stability, design, coding, and process;
* unrealistic interpretation of original requirements and resource
estimates; and:
* rationale used to develop the estimates.
A contributing factor for the Army and LSI's inaccurate software sizing
estimates is that system-level requirements have not been fully
defined, which makes it difficult to determine what will be needed in
terms of software. In May 2003, the Army and LSI estimated that it
would take about 34 million lines of code at a time when they were
still trying to identify and understand the high-level requirements.
Despite not fully understanding those high-level requirements, the Army
proceeded with efforts to develop software for FCS. To date, estimating
accuracy continues to be hampered by evolving requirements, immature
architecture, and insufficient time to thoroughly analyze software
subsystems sizing. The difficulties associated with accurate software
estimating is an indication that complexity increases as the design is
better understood and this serves to increase the level of effort. The
potential consequences are longer development time and greater costs.
Taking the latest code estimate into consideration, the total size of
FCS's software is about four times larger than the next largest
software-intensive defense programs. Figure 4 compares FCS's software
SLOC size estimate to the next two largest software intensive defense
programs--the Navy's P-8A Multi-mission Maritime Aircraft, and the
Joint Strike Fighter aircraft.
Figure 4: Comparison of FCS Software Size to the Next Largest Software
Intensive Defense Programs:
This figure is a bar graph showing a comparison of FCS software size to
the next largest software intensive defense programs.
Joint Strike Fighter: 22.9;
Multi-mission Maritime Aircraft: 24.5;
Future Combat System: 95.1.
[See PDF for image]
Source: Army, Navy, Air Force (data); GAO (analysis and presentation).
[End of figure]
Independent cost analyses done for FCS have cited software as a likely
source of cost growth. According to a June 2006 report issued by the
Office of the Secretary of Defense's Cost Analysis Improvement Group,
the FCS program was found to be at risk of higher costs due to, among
other things, the size and complexity of the FCS software development
program. The Cost Analysis Improvement Group also said that the network
is at risk because it is tied to the JTRS and WIN-T programs that could
cause delays in FCS's development schedule. Another study issued in
April 2007 by the Institute for Defense Analyses for the Office of the
Under Secretary of Defense for Acquisition, Technology and Logistics on
FCS costs found that Army plans for developing FCS, including the
network, were optimistic with regard to time and money needed for the
program. The Institute projected at least $3 billion in additional FCS
development costs due to unplanned software effort including code
growth, software integration difficulties, and longer development
schedules. The Army does not agree with the Institute's assessment and
believe these issues can be offset.
Software Practices Have Been Adopted, but Implementation Has Been
Hampered by Evolving Requirements:
The Army and LSI have adopted a number of disciplined software
practices, but their effective implementation at the software developer
level has been hampered by evolving system-level requirements. In
accordance with CMMI[Footnote 13] and under the advisory of the
Software Engineering Institute, the Army and LSI have adopted software
practices that are known to be successful in fostering quality software
development, such as disciplined processes, structured management
review processes, and an "evolutionary" development process. In our
analysis of five FCS software developers, we found that requirements
management was the cause of most problems, indicating that a key
practice for managing and developing requirements has not been
effectively implemented for the five software packages reviewed.
Key Software Development Practices and Processes Used:
For FCS software development, the Army and LSI are jointly in charge of
oversight and decision-making, and have attempted to do so effectively
through the use of disciplined processes, structured management review
processes, and an "evolutionary" development process. Seventy-five
percent of the FCS software is being developed by 14 software
developers (all certified at CMMI level 3 or above) who are developing
52 major software packages. Detailed information about those software
developers and what they are responsible for delivering is provided in
appendix III.
Through the use of disciplined processes, the Army and LSI have strived
to organize and synchronize the large amount of concurrent software
development that is taking place. In keeping with the spiral model for
development, software development is divided into five builds, and each
build has an "early" and "final" stage. Furthermore, each build has
four phases--requirements, design, code, and test. Essentially, the
spiral model condenses all four phases into builds so that certain
interim capabilities can be provided and "spun out" before the entire
program is completed. Figure 5 shows a traditional spiral model.
Figure 5: Traditional Spiral Development Illustration:
This figure is an chart showing traditional spiral development
illustration.
[See PDF for image]
Source: U.S. Army (data); GAO (analysis and presentation).
[End of figure]
The LSI's structured management review processes involve the management
of network and software development through the use of several
mechanisms that keep track of a series of weekly and monthly program
meetings, agendas, progress, and issues. In addition, key metrics are
tracked by the software developers and reported to the LSI such as
defect age, process compliance, product defects, progress, requirement
stability, software development environment, software lines of code,
code reuse, and staffing. In the event these metrics reveal a problem
or undesirable trend, the LSI takes action to attempt to remedy the
situation.
Anchor points are also used by the LSI to maintain structured
management review. At a minimum, three software development reviews
will be performed for software within a build--life cycle objectives,
life cycle architecture, and test readiness reviews. Developers conduct
life cycle objective anchor point reviews (or software requirements
reviews) to communicate their detailed understanding of the
functionality and performance to be provided by the software item(s)
for a given build. Life cycle architecture anchor point reviews (or
preliminary design reviews) demonstrate the feasibility of implementing
the planned functionality for the software item(s) for a given build
within the planned architecture, requirements, cost, and schedule.
Successful completion of a formal test readiness review will mean that
the developer is ready to start software item formal qualification
testing for the applicable software items for a given build.
The Army and LSI also use the evolutionary development process, in
which software builds are begun with the understanding that the user
need is not fully understood and all requirements cannot be defined up
front. In this strategy, user needs and system requirements are
partially defined up front and then refined in each succeeding build.
The way in which all 52 software packages are being developed at the
same time has been called concurrent engineering, which has pros and
cons. A pro is that the concurrent development aims to keep the program
as a whole on schedule. But software developers reported that when
requirements are late or ambiguous, the concurrent engineering approach
has a negative cascading effect as all of the software efforts are
interrelated.
The Army and LSI are also using modeling and simulation, which takes
place in System Integration Labs, and in Huntington Beach, California,
at the System of Systems Integration Lab (SoSIL). Since integration and
interoperability will be the major challenge in building the FCS, the
SoSIL is intended to provide a distributed capability to develop and
integrate not only the software but also early hardware and system
prototypes to assess and ultimately verify the integration and
interoperability of the FCS system of systems and also give program
management critical feedback from the user.
Lack of Stable Requirements Has Disrupted Implementation of Good
Software Practices:
Our analysis of the LSI's software practices and the effect they are
having on five subcontracted software developers revealed key problem
areas that may be indicators of broader software development problems.
We focused mainly on the following areas: Agreement Management,
Acquisition Requirements Development, Project Monitoring and Control,
Project Planning, and Requirements Management. Of these areas,
Requirements Management was found to be the cause of most problems,
indicating that a key practice for managing and developing requirements
has not been effectively implemented for the five software packages
reviewed. In practice, phases within a build are becoming concurrent,
and the completion of one build is overlapping the start of the next
build. Software developers stated that additional time, cost, and
deferred functionality were the most common results of poorly defined,
late, or unstable requirements.
The continuing evolution of FCS system-level requirements, including
that caused by Army decisions on what it can afford to develop, and the
aggressive pace of the program, are causing disruptions at the software
developer level. In an effort to control overall FCS development costs,
the Army is reviewing many areas of FCS development, including
software, to potentially eliminate areas that are not absolutely
essential or critical. Whereas it is a good practice to eliminate these
non-essential areas, the drawback is that this causes change in
requirements, thereby directly impacting the design and writing of
software code. According to LSI officials, changes at the Operational
Requirements Document level are not major or frequent, and requirements
at that level have actually decreased. Even so, requirements growth and
changes are occurring at the system level, which has a cascading effect
on the detailed requirements all the way down to the software developer
level. The growth results in requirements provided to software
developers that are poorly defined, late, or unstable.
For example, developers at iRobot told us they received poorly defined
requirements which specified that the small unmanned ground vehicle
have a fire extinguisher onboard and be able to withstand direct
lightning strikes. Since the small unmanned ground vehicle is a small
man-packable robot, these requirements were not practical, but the Army
and LSI failed to realize the fundamental differences between this
small robot and its other unmanned ground vehicles such as the
Multifunction Utility/Logistics Equipment vehicle, which is a 2-1/2 ton
vehicle, compared to the small unmanned ground vehicle, which weighs
less than 30 pounds. The developer of Battle Command and Mission
Execution told us that additional requirements were received after the
life cycle architecture review, which is considered late in
development. The SOSCOE developers also told us they received late
requirements for build 1.8, which caused problems for many other
software developers since the late requirements caused them to deliver
build 1.8 late and with missing functionality that many developers had
expected and were counting on for their own work packages. SOSCOE
developers stated that this happened because of misaligned schedules
from the top down, and indicated that they too had experienced problems
with requirements. Unstable requirements have also been a problem for
developers of the Network Management Systems who reported requirements
that changed have caused rework in many cases. Table 2 summarizes
problems experienced by the software developers we visited.
Table 2: Software Packages and Associated Requirements Problems:
Software packages: Combat Identification;
Causes: Poorly defined requirements: X;
Causes: Late: requirements: [Empty];
Causes: Missing requirements: X;
Effect: Deferred functionality: [Empty].
Software packages: Battle Command and Mission Execution;
Causes: Poorly defined requirements: X;
Causes: Late: requirements: X; Causes: Missing requirements: X;
Effect: Deferred functionality: X.
Software packages: Network Management System;
Causes: Poorly defined requirements: X;
Causes: Late: requirements: X;
Causes: Missing requirements: X;
Effect: Deferred functionality: X.
Software packages: Small Unmanned Ground Vehicle;
Causes: Poorly defined requirements: X;
Causes: Late: requirements: X;
Causes: Missing requirements: X;
Effect: Deferred functionality: X.
Software packages: Training Common Components;
Causes: Poorly defined requirements: X;
Causes: Late: requirements: X;
Causes: Missing requirements: X;
Effect: Deferred functionality: X.
Software packages: System of Systems Common Operating Environment;
Causes: Poorly defined requirements: X;
Causes: Late: requirements: X;
Causes: Missing requirements: [Empty];
Effect: Deferred functionality: X.
Source: U.S. Army (data); GAO (analysis and presentation).
Note: SOSCOE is not considered one of the software packages being
developed by the 14 first-tier contractors. It is part of the 25
percent of software being developed for FCS by the LSI. We include
SOSCOE in this table to point out that problems with requirements
effect all levels of software development, from the LSI down to the
smallest software package developer.
[End of table]
As shown in table 2, four of the five software developers (and SOSCOE)
that we met with report that the problems with requirements have
resulted in functionality being deferred to future builds, or waived
altogether, for the sake of keeping to the existing schedule. Deferring
work into the future means that the associated software code writing
and testing will take place later than planned, meaning that more code
will be written later and the associated functionality will not be
testable until later. These events help partially explain the growth of
software estimates already recorded for the early builds. Furthermore,
this indicates that less functionality than planned has been delivered
and that software estimates will only grow larger in future builds.
Overall, software developers told us that these problems could have
been avoided if they had been allowed sufficient time to understand and
analyze the requirements. This is why the aggressive pace of the
program presents such a problem for the development effort. The current
FCS practice is to overlap builds more than the traditional spiral
model does, as is seen in figure 6.
Figure 6: FCS Spiral Development Strategy and Software Life Cycle
Reviews:
This figure is a visual depiction of the FCS spiral development
strategy life cycle reviews. It has lines from left to right sowing
Build 0, 1, 2, 3, and 4.
[See PDF for image]
Source: U.S. Army data; GAO (analysis and presentation).
[End of figure]
Before the testing phase is complete on one build, the requirements
phase of the next build will start. Program officials told us that the
purpose of this is to set requirements so that the next build is ready
for design by the time the former build has completed testing. In
practice, however, this has been an issue because software developers
report that evolving requirements have caused them to interpret and
implement changes in requirements well into the design and code phases,
compromising the amount of time allotted for testing. This is not to
say that the requirements should have been defined more quickly; the
state of requirements accurately reflects the maturity of the FCS
program. Rather, it is the relative immaturity of the program, coupled
with its aggressive pace, that amplify requirements instability, the
pronounced overlap of the FCS builds and the cascading effect on
software developers.
Uncertainty about Network Development and Demonstration Present
Challenges for Decisionmakers at Key Program Events:
It is unclear if network requirements, including software to be
developed, will be adequately defined and designs completed at the
preliminary design review scheduled for February 2009. To date, only
some elementary concepts of the FCS network, such as connecting and
exchanging information among limited network nodes, have been
demonstrated (Experiment 1.1). The first major demonstration of the FCS
network is the limited user test scheduled for fiscal year 2012, which
will be at least a year after the critical design review and only about
a year before the start of FCS low-rate initial production. One of the
key objectives of that test will be to identify the contributions and
limitations of the network on the ability of the FCS brigade combat
team to conduct missions across the full spectrum of operations. The
Army hopes that test will be enough to meet the congressional
requirement to conduct a network demonstration prior to obligating any
funds for FCS low-rate initial production of manned vehicles.
Unclear Picture of Network Status and Outlook at 2009 Milestone Review:
A substantial amount of development work remains before the Army and
LSI can demonstrate the full expected capability of the network.
Modeling and simulation are being employed as key parts of the FCS
network and software development process. While modeling and simulation
is a cost effective approach for proving out technological advances
incrementally, this approach has limitations in predicting the
performance of first-of-kind systems. For example, commercial firms in
the past have learned that modeling and simulation is very reliable for
predicting the performance of products that are evolutionary advances
over existing products, for which there is a large base of experience
to draw from. However, it is generally understood that without
sufficient data on past behavior and a better understanding of
assumptions, the results of modeling and simulation may not entirely
reflect the workings of the new or advanced systems. A number of
limited demonstrations have been scheduled within the FCS system
development and demonstration phase to help move the Army toward a
network-centric environment. To date, only basic network concepts, such
as connecting and exchanging information among limited network nodes
have been demonstrated (Experiment 1.1). The Army plans to demonstrate
some network functions, such as linkage with remote sensors, during the
spinout demonstration in 2008. Other demonstrations are scheduled in
2010 and 2012. However, the fully automated battle command system is
not expected until 2013 when the Army envisions 100 percent of network
capabilities such as the full networked joint and multi-national battle
command, full interoperability and network integration with platforms,
full sensing and targeting, full networked logistics, and planning and
training services. This event will occur near the time of the FCS
production decision, after the designs on manned ground vehicles have
been established.
At the time of the FCS milestone review in 2009, the extent of network
demonstration is expected to be very limited. For example, the Army
plans to demonstrate, among other basic things, sensor control, terrain
analysis, and unmanned platform planning and operations in 2008. As
mentioned earlier, network design and maturity are in the early stages
as the Army and LSI are still determining what network management means
in terms of what is needed to support each specific mission, how to
allocate network resources to the mission spectrum, how to fuse,
process, and present extensive FCS sensor data to appropriate users,
and how to maintain the network. The Army is still in the midst of
stabilizing the network and software requirements, and hardware and
software designs are still maturing. Further, there is uncertainty
about when the network requirements will be fully defined. More
importantly, it is unclear, if not doubtful, that recognized technical
risks will be reduced to acceptably low levels by the 2009 review.
Major Demonstration of FCS Network Scheduled in 2012 after Vehicle
Designs Are Set:
The first major demonstration of the FCS network is limited user test 3
scheduled for fiscal year 2012, which will be at least a year after
critical design review and about a year before the start of low-rate
initial production for the core FCS program scheduled to begin in 2013.
By then, billions will have been spent and it may be too late to fix
any network problems revealed in this significant test before
production begins. At critical design review in 2011, the Army expects
that the FCS network capabilities will be completed on the manned
platform planning and operations. In section 211 of the recently
enacted National Defense Authorization Act for Fiscal Year 2008,
Congress directed that a network demonstration be conducted prior to
obligation of funds for low-rate initial production (Milestone C) or
full-rate production of FCS manned ground vehicles.[Footnote 14] One of
the key objectives of that test will be to use FCS prototypes to
identify the contributions and limitations of the network on the
ability of the FCS brigade combat team to conduct missions across the
full spectrum of operations. The limited user test 3 will be pivotal to
the FCS program because it is the first test event to incorporate each
of the 14 FCS platforms, and it serves as a seminal event to generate
system-of-systems test data to underpin the modeling and simulation
environment used to support the test. However, the fully automated
battle command system is not expected until 2013 when all the software
application capabilities are expected, including the full networked
joint and multinational battle command, interoperability, integration
of all platforms, integrated training, sensing and targeting, and other
functions.
Even if the demonstration of the network takes place in 2012 as
planned, it will follow the design reviews of the other FCS systems.
The design of these systems depends significantly on the performance of
the network, such as its delivered quality of service. There are a
number of FCS systems or platforms, such as manned ground
vehicles,[Footnote 15] that are scheduled to have their critical design
reviews in fiscal years 2009-2010, about 2 years before the first major
demonstration of the network in fiscal year 2012. For manned ground
vehicles, most developmental prototypes will be in testing and the Army
will have begun preparation for low-rate initial production for these
platforms before the network is demonstrated. This is a significant
risk as the software, which supports the information network, is
critical to the design and performance of the platforms and is expected
to control about 95 percent of FCS's functionality. If the network
underperforms, it could affect the lethality and survivability of the
vehicles. Because of this sequence of events, there will be little
opportunity for the vehicle designs to compensate for any shortfalls in
network performance.
Conclusions:
The advanced information network is the linchpin to the Army's FCS
concept; yet, it is unclear whether, how, or when the Army will be able
to demonstrate that the network performs as needed. The Army and the
LSI have focused a great amount of attention on the network and
software, evidenced by the sound development practices they have
attempted to put in place. However, network and software requirements
are not yet stable at the system level and below, which has caused
rework and deferred functionality. Such instability may be expected
given the relative immaturity of FCS, but the program is halfway
through development and the remaining schedule is very ambitious;
program decisions have been and will continue to be made in advance of
acquisition knowledge. Demonstrations to date have been small and not
sufficient--nor intended--to prove the network's performance. Large-
scale demonstrations of the network's ability to deliver the quality of
service essential to the FCS fighting concept will not come until 2012,
the year before the low-rate initial production decision, assuming the
remainder of development goes as planned. Even if this date is met, it
will trail the critical design reviews of the individual FCS systems by
2 years. This is disquieting because the designs of the systems--
including the manned ground vehicles--depend on the quality of service
delivered by the network. Finally, the overall magnitude of the FCS
software effort has nearly tripled to 95 million lines of code. This
growth gives credence to the higher cost estimates put forth by the
Cost Analysis Improvement Group and the Institute for Defense Analysis-
-both of which concluded that the FCS software effort would be more
extensive than the Army envisioned.
For these reasons, it is essential that the software and network
efforts be held to meeting clear performance criteria at key junctures
that are linked to the network's needed quality of service. These
junctures include the 2009 milestone review, the 2009-2010 vehicle
critical design reviews, the 2011 FCS critical design review, and the
2012 network demonstration. Allowing demonstrations or network
functions to be deferred past these junctures on the basis that
modeling and simulation results are promising will not suffice. Given
the difficulty of predicting performance in full-scale operations,
testing must be the primary basis for judging the sufficiency of
progress. Because the performance of the network and the success of the
software effort are not assured, decision makers should allow for the
possibility that full success will not be achieved. Thus, it will be
wise to keep alternative courses of action viable to guard against such
an eventuality.
Recommendations for Executive Action:
We recommend that the Secretary of Defense:
* Direct the FCS program to stabilize network and software requirements
on each software build to enable software developers to follow
disciplined software practices, including having realistic and
synchronized test schedules.
* Establish a clear set of criteria for acceptable network performance
at each of the key program events including the:
- 2009 milestone review,
- platform and system-of-system critical design reviews,
- major network demonstration in 2012, and:
- Milestone C for core FCS program.
We further recommend that the Secretary of Defense, in setting
expectations for the 2009 milestone review, include:
* a thorough analysis of network technical feasibility and risks,
* synchronization of network development and demonstration with that of
other elements of FCS such as the manned ground vehicles, and:
* a reconciliation of the differences between independent and Army
estimates of network and software development scope and cost.
Agency Comments and Our Evaluation:
DOD concurred with our recommendations and stated that growing the
networking capability of the ground forces is a priority and network
development for FCS is a critical element in the Army's effort to
modernize its tactical network. In recognizing FCS's network
development and importance to the Army's efforts to modernize the
tactical network, DOD stated that criteria for network performance
would be established. The criteria for network performance would be
documented in the FCS acquisition strategy, the system engineering
plan, and test plans. However, because these documents will not be
updated until the 2009 milestone review, that could leave in question
what will be expected in terms of network performance by the time of
the 2009 milestone review itself. DOD should establish in advance the
network criteria that will be applied at the 2009 milestone review,
such as at the time of the annual review to be held in 2008.
In concurring with our recommendation on setting expectations for the
2009 milestone review, DOD stated that an analysis of network technical
feasibility and risks will inform the FCS 2009 review. DOD further
stated that manned ground vehicle and network development and
demonstration will be synchronized and that the 2009 FCS review will
evaluate the network and software cost estimates and cost risks
identified for the development, integration, and testing of the FCS
network and software. These are constructive steps that will contribute
to the FCS milestone review in 2009. However, we believe that DOD needs
to go beyond evaluating cost estimates and risks. The differences
between the Army's estimate and independent cost estimates have been
substantial. The lower Army estimate has been allowed to prevail,
without a determination that it is the better estimate--that is, the
one more likely to accurately predict the actual cost of FCS. DOD, in
determining the official cost estimate for FCS, should provide the
rationale for its position. Heretofore, the Army's estimates have been
constrained by available funding and Army officials have stated that
they will reduce program scope if costs are higher than expected. If
FCS is found to be worth doing in its entirety during the 2009
milestone review, its most likely cost should be understood.
We also received technical comments from DOD which have been addressed
in the report, as appropriate.
We are sending copies of this report to the Secretary of Defense; the
Secretary of the Army; and the Director, Office of Management and
Budget. Copies will also be made available to others on request. In
addition, the report will be made available at no charge on the GAO Web
site at [hyperlink, http://www.gao.gov].
If you, or your staff, have any questions concerning this report,
please contact me at (202) 512-4841. Contact points for our offices of
Congressional Relations and Public Affairs may be found on the last
page of this report. The major contributors are listed in appendix IV.
Signed by:
Paul L. Francis:
Director Acquisition and Sourcing Management:
List of Congressional Committees:
The Honorable Carl Levin:
Chairman:
The Honorable John McCain:
Ranking Member:
Committee on Armed Services:
United States Senate:
The Honorable Daniel K. Inouye:
Chairman:
The Honorable Ted Stevens:
Ranking Member:
Subcommittee on Defense:
Committee on Appropriations:
United States Senate:
The Honorable Ike Skelton:
Chairman:
The Honorable Duncan L. Hunter:
Ranking Member:
Committee on Armed Services:
House of Representatives:
The Honorable John P. Murtha:
Chairman:
The Honorable C. W. (Bill) Young:
Ranking Member:
Subcommittee on Defense:
Committee on Appropriations:
House of Representatives:
[End of section]
Appendix I: Scope and Methodology:
To develop the information on the Future Combat System program's
network and software challenges and technological risks, assess whether
disciplined software practices have been effectively implemented, and
determine whether the Army will have the necessary network and software
at key program events, we interviewed the Assistant Secretary of the
Army (Acquisition, Technology, and Logistics); the Program Manager for
the Future Combat System (Brigade Combat Team); the Future Combat
System Lead Systems Integrator; officials from the Army's Software
Engineering Directorate; and Lead Systems Integrator One Team
contractors. We selected 5 of 52 software packages and conducted
detailed structured interviews to determine how the use of the LSI's
software best practices affected the developers at various levels
within FCS. In consultation with the Army, LSI, University of Maryland
(Fraunhofer Center for Experimental Software Engineering) and experts
from GAO's Applied Research and Methods group, we selected software
packages that are critical to FCS's network and those that would
provide a good cross section of the development efforts being conducted
by contractors under LSI's direction. This software included the Battle
Command and Mission Execution, Combat Identification, Network
Management System, Small Unmanned Ground Vehicle, and Training Common
Components. Limited work was conducted on SOSCOE. We reviewed, among
other documents, the Future Combat System's Integrated Master Schedule
and CMMI Evolution, Test and Evaluation Master Plan, Software
Configuration Management, Development, Integration, Quality Assurance,
Risk Mitigation, and Measurement Plans. In addition to CMMI for
Acquisition, Version 1.2, we also reviewed individual software
developers' Software Development, Configuration Management,
Integration, Quality Assurance, System Engineering Management, Risk and
Opportunity Management, and Test Plans, Software Architecture
Description Documents, and Software Requirements Specifications. We
attended FCS Board of Director's meetings and the Delta Engineering
Iteration 2 Definition Anchor Point and System of Systems Build 2
Definition Checkpoint Review. In our assessment of the FCS network and
software development, we used the knowledge-based acquisition practices
drawn from our large body of past work as well as DOD's acquisition
policy and the experiences of other programs. We discussed the issues
presented in this report with officials from the Army and the Secretary
of Defense and made changes as appropriate. We performed our review
from July 2007 to March 2008 in accordance with generally accepted
auditing standards.
[End of section]
Appendix II: Comments from the Department of Defense:
Office Of The Under Secretary Of Defense:
3000 Defense Pentagon:
Washington, Dc 20301-3000:
Acquisition, Technology And Logistics:
February 28, 2008:
Mr. Paul L. Francis:
Director, Acquisition and Sourcing Management:
U.S. Government Accountability Office:
441 G Street, N.W.:
Washington, DC 20548:
Dear Mr. Francis:
This is the Department of Defense (DoD) response to the GAO draft
report, "Defense Acquisitions: Significant Challenges Ahead in
Developing and Demonstrating Future Combat System's Network and
Software," dated January 31, 2008 (GAO Code 120667/GAO-08-409).
The report recommends that the Secretary of Defense direct the Future
Combat System (FCS) program to stabilize network and software
requirements on each software build and establish criteria on
acceptable network performance for each key program event.
The Department concurs with the GAO recommendations and our comments
are enclosed. Growing the networking capability of the ground forces is
a Department priority and the FCS network development is a critical
element in the Army's effort to modernize its tactical network.
Acquisition of networking capability requires a disciplined, yet agile,
acquisition construct. The network aspect of the FCS program is an
important component of the periodic acquisition reviews of FCS
conducted by the Department, including the Defense Acquisition Board
review subsequent to the FCS preliminary design review in 2009.
Detailed technical comments were provided separately.
Sincerely,
Signed by:
David G. Ahern:
Director:
Portfolio Systems Acquisition:
Enclosure:
As stated:
GAO Draft Report Dated January 31, 2008 GAO-08-409 (GAO Code 120667):
"Defense Acquisitions: Significant Challenges Ahead In Developing And
Demonstrating Future Combat System's Network And Software":
Department Of Defense Comments To The GAO Recommendation:
Recommendation 1: The GAO recommended that the Secretary of Defense
direct the Future Combat System (FCS) program to stabilize network and
software requirements on each software build to enable software
developers to follow disciplined software practices, including having
realistic and synchronized test schedules.
DOD Response: Concur. The FCS program will finalize and release network
and software requirements prior to each software build. The test
schedules for each build, and for overall system network testing, will
be documented and synchronized for realistic, informed network
assessments.
Recommendation 2: The GAO recommended that the Secretary of Defense,
establish a clear set of criteria for acceptable network performance at
each of the key program events including the following: a. 2009
milestone review; b. platform and system-of-system critical design
reviews; c. major network demonstration in 2012, and; d. milestone C
for core FCS program.
DOD Response: Concur. Criteria for network performance for key program
events shall be established. These criteria shall be reflected in the
appropriate program documentation. The update to the FCS Acquisition
Strategy shall include network performance criteria for the 2009
Defense Acquisition Board and Milestone C. The update to the FCS System
Engineering Plan shall reflect network performance criteria anticipated
for the platform and system-of-system critical design reviews. The
assessment criteria for network performance shall be documented in test
plans for test events to include the Technical Field Tests and Limited
User Tests.
Recommendation 3: The GAO recommended that the Secretary of Defense, in
setting expectations for the 2009 milestone review, include: a. a
thorough analysis of network technical feasibility and risks; b.
synchronization of network development and demonstration with that of
other elements of FCS such as the manned ground vehicles, and; c. a
reconciliation of the differences between independent and Army
estimates of network and software development scope and cost.
DOD Response: Concur: An analysis of network technical feasibility and
risks will inform the FCS 2009 review. Additionally, manned ground
vehicle and network development and demonstration will be synchronized
in the areas where there are interfaces and dependencies. The 2009 FCS
review will evaluate the network and software cost estimates and cost
risks identified for the development, integration, and testing of the
FCS network and software.
[End of section]
Appendix III: List of FCS Software (Network & Non-network) Packages
Developed by Contractors (as of July 2007):
FCS contractors: (First-tier): AcuSoft, Inc;
Number of software packages: 1;
Name of software (network and non-network) packages: Training Common
Components Software Suite[A].
FCS contractors: (First-tier): AT&T GSI;
Number of software packages: 1;
Name of software (network and non-network) packages: Training Common
Components Software Suite[A].
FCS contractors: (First-tier): BAE Systems;
Number of software packages: 10;
Name of software (network and non-network) packages: Acoustic Locating
Array Subsystem; Emitter Mapper Subsystem; Ground/Air Platform
Communication; FCS Recovery and Maintenance Vehicle operational;
Infantry Carrier Vehicle operational; Medical Vehicle operational;
Common operational (all 8 manned ground vehicles); Non Line of Sight
Cannon operational; Non Line of Sight Mortar operational; Armed Robotic
Vehicle.
FCS contractors: (First-tier): DRS;
Number of software packages: 3;
Name of software (network and non-network) packages: Short- range
Electro-optical sensor; Small Unmanned Ground Vehicle Electro- optical
Infrared; Class 1 Electro-optical Infrared.
FCS contractors: (First-tier): General Dynamics;
Number of software packages: 8;
Name of software (network and non-network) packages: Autonomous
Navigation System[A]; Sensor Data Management[PLANNING/PREPARATION
SERVICES] cesa; Integrated Computer Services; Command and control
vehicle operational; Mounted combat system operational; Reconnaissance
and surveillance vehicle operational; Common operational (all 8 manned
ground vehicles).
FCS contractors: (First-tier): Honeywell;
Number of software packages: 5;
Name of software (network and non-network) packages: Vehicle Management
Computer; Board Support Package (for Vehicle Management Computer,
Psuedo-integrated Computer System, & vehicle simulation); Platform
Soldier Readiness System[A].
FCS contractors: (First-tier): IBM;
Number of software packages: 3;
Name of software (network and non-network) packages: Logistics Data
Agent[A] ; Logical Data Manager[A]; Logistics Data Management
Service[A].
FCS contractors: (First-tier): iRobot;
Number of software packages: 2;
Name of software (network and non-network) packages: Small Unmanned
Ground Vehicle operational and Small Unmanned Ground Vehicle modeling
and simulation.
FCS contractors: (First-tier): Lockheed Martin;
Number of software packages: 5;
Name of software (network and non-network) packages: Warfighter
Centralized Controller Device[A] ; Common Electro- Optical Sensor;
Level 1 Fusion[A]; Training Common Components Software Suite[A];
Vehicle Control, Mobility control, weapons control, power service,
vehicle management.
FCS contractors: (First-tier): Northrop Grumman;
Number of software packages: 5;
Name of software (network and non-network) packages: Class IV Unmanned
Aerial Vehicle; Logistics Decision Support System-Manned Ground
Vehicle[A] ; Air Sensor Integration[A]; Aided Target Recognition;
Network Management[A].
FCS contractors: (First-tier): Overwatch Systems;
Number of software packages: 1;
Name of software (network and non-network) packages: Situation
Understanding[A].
FCS contractors: (First-tier): Raytheon;
Number of software packages: 5;
Name of software (network and non-network) packages: Ground Sensor
Integrator[A] ; Combat Identification[A]; Multi-function radio
frequency; Common Electro-Optical Sensor; Battle Command and Mission
Execution[A].
FCS contractors: (First-tier): SAIC;
Number of software packages: 1;
Name of software (network and non-network) packages: Training Common
Components Software Suite[A].
FCS contractors: (First-tier): Textron;
Number of software packages: 2;
Name of software (network and non-network) packages: Tactical and Urban
Ground Sensors; Unattended Ground Sensors.
FCS contractors: (First-tier): Total: 14;
Number of software packages: Total: 52;
Name of software (network and non-network) packages: [Empty].
Source: U.S. Army (data); GAO (analysis and presentation).
[A] Software packages expected to provide partial or full networking
functions.
[End of table]
[End of section]
Appendix IV: GAO Contact and Staff Acknowledgments:
GAO Contact:
Paul L. Francis (202) 512-4841 or FrancisP@gao.gov:
Acknowledgments:
In addition to the individual named above, William R. Graveline,
Assistant Director; John M. Ortiz Jr; Letisha T. Watson; Helena Brink;
Noah B. Bleicher; Robert S. Swierczek; and Senior Technologists Madhav
S. Panwar and Dr. Hai V. Tran made key contributions to this report.
[End of section]
Related GAO Products:
Defense Acquisitions: Role of Lead Systems Integrator on Future Combat
Systems Program Poses Oversight Challenges. GAO-07-380. Washington,
D.C.: June 6, 2007.
Defense Acquisitions: Future Combat System Risks Underscore the
Importance of Oversight. GAO-07-672T. Washington, D.C.: March 27, 2007.
Defense Acquisitions: Key Decisions to Be Made on Future Combat System.
GAO-07-376. Washington, D.C.: March 15, 2007.
Defense Acquisitions: The Army Faces Challenges in Developing a
Tactical Networking Strategy. GAO-07-10SU. Washington, D.C.:
October 4, 2006.
Defense Acquisitions: Restructured JTRS Program Reduces Risk, but
Significant Challenges Remain. GAO-06-955. Washington, D.C.: September
11, 2006.
Defense Acquisitions: Improved Business Case Key for Future Combat
System's Success. GAO-06-564T. Washington, D.C.: April 4, 2006.
Defense Acquisitions: Assessments of Selected Weapon Programs. GAO-07-
406SP. Washington, D.C.: March 30, 2007.
Defense Acquisitions: Improved Business Case is Needed for Future
Combat System's Successful Outcome. GAO-06-367. Washington, D.C.: March
14, 2006.
Defense Acquisitions: Business Case and Business Arrangements Key for
Future Combat System's Success. GAO-06-478T. Washington, D.C.: March 1,
2006.
Defense Acquisitions: Resolving Development Risks in the Army's
Networked Communications Capabilities is Key to Fielding Future Force.
GAO-05-669. Washington, D.C.: June 15, 2005.
Defense Acquisitions: Future Combat Systems Challenges and Prospects
for Success. GAO-05-428T. Washington, D.C.: March 16, 2005.
Defense Acquisitions: Future Combat Systems Challenges and Prospects
for Success. GAO-05-442T. Washington, D.C.: March 16, 2005.
Defense Acquisitions: The Global Information Grid and Challenges Facing
Its Implementation. GAO-04-858. Washington, D.C.: July 28, 2004.
Defense Acquisitions: The Army's Future Combat Systems' Features,
Risks, and Alternatives. GAO-04-635T. Washington, D.C.: April 1, 2004.
Defense Acquisitions: Stronger Management Practices Are Needed to
Improve DOD's Software-Intensive Weapon Acquisitions. GAO-04-393.
Washington, D.C.: March 1, 2004.
Issues Facing the Army's Future Combat Systems Program. GAO-03-1010R.
Washington, D.C.: August 13, 2003.
Defense Acquisitions: Army Transformation Faces Weapon Systems
Challenges. GAO-01-311. Washington, D.C.: May 2001.
Best Practices: Better Matching of Needs and Resources Will Lead to
Better Weapon System Outcomes. GAO-01-288. Washington, D.C.: March 8,
2001.
[End of section]
Footnotes:
[1] Pub. L. No. 109-163, § 211 (2006).
[2] GAO, Defense Acquisitions: 2009 Is a Critical Juncture for the
Army's Future Combat System. GAO-08-408 (Washington, D.C.: Mar. 7,
2008).
[3] A mobile ad-hoc network is an autonomous collection of mobile users
that communicate over relatively bandwidth-constrained wireless links.
Since the nodes are mobile, the network topology may change rapidly and
unpredictably over time. The network is decentralized, meaning all
network activity including discovering the topology and delivering
messages must be executed by the nodes themselves (i.e., routing
functions will be incorporated into mobile nodes). In a military
environment such as FCS, ensuring security and reliability are major
concerns. Military networks are designed to maintain a low probability
of intercept and/or a low probability of detection. Hence, nodes are to
radiate as little power as necessary and transmit as infrequently as
possible, thus decreasing the probability of detection or interception.
A lapse in any of these requirements may degrade the performance and
dependability of the network.
[4] Bandwidth is a term used in much of the telecommunications industry
as a measure, usually expressed in bits per second, of the rate at
which information moves from one electronic device to another.
[5] The Warfighter Machine Interface software is to be part of manned
systems and warfighter or soldier systems only.
[6] The Global Information Grid is a large and complex set of programs
and initiatives intended to provide Internet-like capability allowing
users at virtually any location to access data on demand, share
information in real time, and collaborate in decision making,
regardless of which military service produced which weapon system, thus
having greater joint command of a battle situation.
[7] A waveform is the representation of a signal that includes the
frequency, modulation type, message format, and/or transmission system.
In general usage, the term waveform refers to a known set of
characteristics, for example, frequency bands (VHF, HF, and UHF),
modulation techniques (FM, AM), message standards, and transmission
systems. In JTRS usage, the term waveform is used to describe the
entire set of radio functions that occur from the user input to the RF
output and vise versa. A JTRS waveform is implemented as a reusable,
portable, executable software application that is independent of the
JTRS operating system, middleware, and hardware.
[8] FCS Program Office, "Network Quality of Service Analysis (SDD-129):
System of Systems Engineering and Integration, Document Number: D786-
11421-1, July 28, 2005.
[9] SLOC measures the raw size of software.
[10] ESLOC is a surrogate for effort that measures the effective size
of reused and adapted code, and is adjusted to its equivalent size in
new lines of code. This is not a deliverable product.
[11] ESLOC data in Build 1 is a cumulative total that includes ESLOCs
from Build 0.
[12] In 1987, the U.S. Air Force selected Ogden Air Logistics Center at
Hill Air Force Base in Ogden, Utah, to establish and operate its
Software Technology Support Center to provide assistance to help
organizations identify, evaluate, and adopt software technologies that
improve software product quality, production efficiency and
predictability. Today, the Center provides services to include, among
others, software acquisition best practice support for government
organizations, and process maturity appraisals and technology adoption
projects across five Air Force major commands, the Navy, the Department
of Defense, and the U.S. Treasury Department. The Center also publishes
a free journal called CrossTalk, The Journal of Defense Software
Engineering to more than 24,000 professionals on practical software
engineering technologies and best practices.
[13] CMMI® (Capability Maturity Model® Integration) is a collection of
best practices that helps organizations improve their processes. It was
initially developed by product teams from industry, government and the
Software Engineering Institute for application to process improvement
in the development of products and services covering the entire product
life cycle from conceptualization through maintenance and disposal.
Following the success of CMMI models for development organizations, the
need was identified for a CMMI model addressing the acquisition
environment.
[14] Pub. L. No. 110-181, § 211 (2008).
[15] FCS manned ground vehicles includes infantry carrier vehicles, non-
line of sight cannon, mounted combat system, reconnaissance and
surveillance vehicles, command and control vehicles, non-line of sight
mortar, and support vehicles.
GAO's Mission:
The Government Accountability Office, the audit, evaluation and
investigative arm of Congress, exists to support Congress in meeting
its constitutional responsibilities and to help improve the performance
and accountability of the federal government for the American people.
GAO examines the use of public funds; evaluates federal programs and
policies; and provides analyses, recommendations, and other assistance
to help Congress make informed oversight, policy, and funding
decisions. GAO's commitment to good government is reflected in its core
values of accountability, integrity, and reliability.
Obtaining Copies of GAO Reports and Testimony:
The fastest and easiest way to obtain copies of GAO documents at no
cost is through GAO's Web site [hyperlink, http://www.gao.gov]. Each
weekday, GAO posts newly released reports, testimony, and
correspondence on its Web site. To have GAO e-mail you a list of newly
posted products every afternoon, go to [hyperlink, http://www.gao.gov]
and select "Subscribe to Updates."
Order by Mail or Phone:
The first copy of each printed report is free. Additional copies are $2
each. A check or money order should be made out to the Superintendent
of Documents. GAO also accepts VISA and Mastercard. Orders for 100 or
more copies mailed to a single address are discounted 25 percent.
Orders should be sent to:
U.S. Government Accountability Office:
441 G Street NW, Room LM:
Washington, D.C. 20548:
To order by Phone:
Voice: (202) 512-6000:
TDD: (202) 512-2537:
Fax: (202) 512-6061:
To Report Fraud, Waste, and Abuse in Federal Programs:
Contact:
Web site: [hyperlink, http://www.gao.gov/fraudnet/fraudnet.htm]:
E-mail: fraudnet@gao.gov:
Automated answering system: (800) 424-5454 or (202) 512-7470:
Congressional Relations:
Ralph Dawn, Managing Director, dawnr@gao.gov:
(202) 512-4400:
U.S. Government Accountability Office:
441 G Street NW, Room 7125:
Washington, D.C. 20548:
Public Affairs:
Chuck Young, Managing Director, youngc1@gao.gov:
(202) 512-4800:
U.S. Government Accountability Office:
441 G Street NW, Room 7149:
Washington, D.C. 20548:
