Skip to main content

Currently Skimming:

Summary
Pages 1-24

The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.


From page 1...
... Second, will the advances in software producibility needed by DoD emerge unaided from the defense industrial base at a pace sufficient to meet evolving defense requirements? Third, in which technology areas should DoD invest in research to advance defense software producibility?
From page 2...
... The research would focus on ways to mitigate these engineering risks at early stages of the process through new approaches to early validation, modeling, and architectural analysis. The second area where DoD has leading demand and could benefit from technological advancement is software quality assurance for defense systems.
From page 3...
... Second, will the advances in software producibility needed by DoD emerge unaided from the defense industrial base (which includes both civilian and defense producers) at a pace sufficient to meet evolving defense requirements?
From page 4...
... , Report of the Defense Science Board Task Force on Mission Impact of Foreign Influence on DoD Software, Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics, Washington, D.C., September 2007.
From page 5...
... But this 5% drives 25% of overall growth and about 40% of our increase in productivity, which is the fundamental source of new wealth in the economy." 14 DSB, Report of the Defense Science Board Task Force on Mission Impact of Foreign Influence on DoD 5
From page 6...
... 18 DSB, Report of the Defense Science Board Task Force on Mission Impact of Foreign Influence on DoD Software, op.
From page 7...
... the role of academic R&D in software innovation generally. DoD Supply Chains and Sourcing of Software Components and Technologies The supply chain structure for modern defense software is significantly more complex, and international than it was even just a decade ago.
From page 8...
... 25 This tension was a focus of the DSB's 2007 Report of the Defense Science Board Task Force on Mission Impact of Foreign Influence on DoD Software. How to mitigate risk from COTS software, given global supply chains, continues to be a focus of DoD activities, including those of the National Security Agency (NSA)
From page 9...
... In the next section, on research showing promise for advancing software producibility, the committee suggests research that could lead to more effective approaches for large-scale systems with unprecedented architectures. These approaches include both technological advances and organizational measures.
From page 10...
... In addition to making a number of recommendations to improve the overall quality of defense software and provide for more knowledgeable acquisition, the DSB Task Force report on foreign software asks this question in the particular area of software assurance, noting the essential requirement that the United States maintain 31 Standards setting can involve a number of challenges and trade-offs, including a trade-off between currency and stability. This is why many firms follow industry conventions, which may evolve relatively more rapidly than formally ratified standards; this can further complicate matters for DoD.
From page 11...
... 17. 39 See, for example, DSB, Report of the Defense Science Board Task Force on Mission Impact of Foreign Influence on DoD Software, Office of the Undersecretary of Defense for Acquisition, Technology, and Logistics, Washington, D.C., September 2007, which grapples with the implications of foreign entities in its COTS supply chain.
From page 12...
... 44 See also DSB, Report of the Defense Science Board Task Force on Mission Impact of Foreign Influence on 12
From page 13...
... Moreover, the IT industry relies on a number of technical and process commonalities or standards such as the suite of Internet protocols, programming languages, core design patterns, and architectural styles."45 These innovations effectively raise everyone's "boat" in the same way as do government investments in bioscience, health care, and other strategically important scientific disciplines. This includes many of the most highly leveraged areas of software research such as improvements in abstraction mechanisms, design notations, programming languages, software analysis and model checking, basic algorithms, design patterns and architecture concepts, and other core techniques.
From page 14...
... Role of Academic R&D The academic research community has traditionally addressed core technical problems related to software producibility. It is the committee's impression, 50 however, that in recent years many of the researchers in these areas have moved into other fields or scaled down their research efforts as a result of, among other things, DoD's having shifted funding priorities away from software-related R&D, apparently on the assumption that industry can address the problems without government intervention.
From page 15...
... Given the role of externalities in IT economics, it is not unreasonable to consider the innovation center of gravity changing rapidly in many key areas, which could shift control in critical areas of the technology stack described above. This is 53 See DSB, Report of the Defense Science Board Task Force on Mission Impact of Foreign Influence on DoD Software, Office of the Undersecretary of Defense for Acquisition, Technology, and Logistics, Washington, D.C., September 2007, p.
From page 16...
... For example, DARPA's deliberately strong relationship with the IT research community, which began in the 1960s and endured for nearly 40 years, has had profound influence on IT research priorities, the overall culture of computer science research, and the massive economic and national outcomes. 57 When DoD shifted funding away from university IT R&D, informal reports indicate that researchers in many areas key to DoD's software future scaled back their research teams and redirected their focus to other fields that were less significant to DoD in the long term.
From page 17...
... regarding prototyping early in the systems development process to reduce software-related engineering risk and support design validation, cost estimation, and specification refinement. 63 TheFutureofInformationTechnology.pdf, accessed February 26, 2007; Michael D
From page 18...
... . Indeed, the process-focused systems now include links not only within the enterprise but also deep into supply chains (as was the case with the Boeing 777 global development project 20 years ago)
From page 19...
... In all engineering projects, and particularly software engineering projects, this usually means moving as early in the process as possible the time at which the consequences of provisional or "risky" decisions can be understood. If the consequences are understood only late in the process, then the costs of unwinding previous bad decisions may have become prohibitive, and instead the architecture becomes a legacy infliction that is constantly worked around.
From page 20...
... In addition, this issue is a core concern in DSB, Report of the Defense Science Board Task Force on Mission Impact of Foreign Influence on DoD Software, Office of the Undersecretary of Defense for Acquisition, Technology, and Logistics, Washington, D.C., September 2007, pp.
From page 21...
... The subject has been taken up in a number of studies (including DSB's 2007 Report of the Defense Science Board Task Force on Mission Impact of Foreign Influence on DoD Software) and most recently by the NSA in its forthcoming COTS strategy proposal.
From page 22...
... Walker and G Murphy, "Implicit Context: Easing Software Evolution and Reuse," Proceedings of the 8th ACM SIGSOFT International Symposium on Foundations of Software Engineering: Twenty-First Century Applications, ACM (Association for Computing Machinery)
From page 23...
... Accessed February 28, 2008. 75 Engineering risk, roughly, is the product of the probability of an unexpected outcome and the consequences of that particular outcome.
From page 24...
... Through this growth cycle there will likely always be some critical dimensions of software engineering that appear to be primary sources of cost and risk. Understanding the nature of progress in software technology and producibility, as contrasted with progress in other engineering disciplines, is essential to create appropriate expectations for how these risks can be managed and, more generally, how the risk/value balance can be addressed as requirements and technology continue to evolve.


This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More information on Chapter Skim is available.