Critical Code: Software Producibility for Defense

  • Published

Critical Code: Software Producibility for Defense by the National Research Council. National Academies Press, 2010, 160 pp.

As the title implies, computer software is critical to the mission of the Department of Defense. Hence, the National Research Council (NRC) was tasked by the Office of the Secretary of Defense in 2006 to analyze and make recommendation on all aspects of software development and sustainability pertaining to the DoD. Specifically, NRC’s Committee for Advancing Software Intensive Systems Producibility delved into current DoD processes for building or buying software for the vast number of systems—both weapon-related and administrative—used by the military.

The research group, comprised of 14 recognized software gurus from corporate America and renowned American universities, complied with OSD’s direction to analyze current software producibility in the military and to debunk myths surrounding defense software. Software producibility, as defined by the NRC, is “the capacity to design, produce, assure, and evolve innovative software-intensive systems in predictable manner while effectively managing risk, cost, schedule, and complexity.”

The committee outlined its findings associated with eight software producibility myths and made salient recommendations on what the DoD should do to fix the problems. These myths range from software producibility challenges associated with management and processes to the one that “There is sufficient software research already underway, sponsored primarily by NSF [National Science Foundation] and other basic science agencies to meet the DoD’s software needs.”

In the first chapter, the committee defines the role of software in the defense industry and how the DoD addresses the software needs of the military. One statistic in this chapter readily defines the salient issue of the study—“the percentage of system functions performed by software has risen from 8 percent in the F-4 in 1960, to 45 percent of the F-16 in 1982, to 80 percent of the F-22 in 2000.” This is the fundamental reason why the DoD must examine its current way of handling military software to ensure it is properly designed and implemented. According to the study, the DoD has actually decreased its software producibility in recent years by contracting out production or purchasing “off the shelf” from Microsoft and other software companies, both US and foreign.

Chapter 2 addresses a common belief in the military that commercial off-the-shelf (COTS) software avoids the huge costs of training military members to write software and produce it in house. It also discusses risks associated with software and how the DoD can manage such risks. The DoD cannot afford to lag behind in this area because its adversaries are constantly looking at new ways to hack into computer systems and writing counter-cyber programs to protect their own IT infrastructures. The only way to beat the threat and accept risks is to “engage experts outside the DoD” to be effective and stay ahead in software producibility.

Another issue identified by the NRC is that software is not at a plateau but is growing as along with the technology surrounding it. Moore’s Law is alive and well in the software realm and not just relevant to firmware or hardware.

The NRC study stresses the importance of leaders getting involved in the architecture side of software. According to the committee, “architecture is an important enabler of reuse and the key to system evolution, enabling management of future uncertainty.” It is something that must be managed not only during the first phases of development and employment, but all the way through the life of the system using that software. The DoD must learn from corporate America and use those lessons to aid in mitigating the risks in architecture systems.

Chapter 4 discusses the importance of quality assurance in software, both the defense and civilian systems that the DoD uses. Without quality assurance, all the systems that use millions of lines of code could put the operator in harm’s way and/or cost billions of dollars to fix. Weak software is also a breeding ground for cyber attacks and infiltration by the enemy. Studies suggest that “overall software assurance costs account for 30 to 50 percent of the total project costs for most software projects.” Software assurance is not an inexpensive endeavor but one that must be incorporated at the start of the software life cycle.

The final chapter “summarizes and recommends technology research areas as critical to the advancement of defense software producibility.” The laundry list varies from DoD influence on academic research and development; to the impact of past investments, challenges, and opportunities for investment; to areas for future research investment.

Overall, the message in Critical Code is very pertinent to today’s interest in cyber security and the software that the DoD uses in ensuring national security. The text is rather technical and a bit hard to follow at times. However, it is a good read for cyber officers and leaders (both military and civilian) to ensure nothing slips through the cracks and causes catastrophic issues with the myriad of systems in DoD.

Lt Col Deborah Dusek, USAF

Offutt AFB, Nebraska

"The views expressed are those of the author(s) and do not reflect the official policy or position of the US government or the Department of Defense."