Critical Code Software Producibility for Defense (2010) / Chapter Skim
Currently Skimming:
3 Assert DoD Architectural Leadership for Innovative Systems
3 Assert DoD Architectural Leadership for Innovative Systems
Pages 68-85
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 68... ...
This chapter characterizes the special role of architecture in software producibility, describes its particular challenges, and discusses how the DoD can strengthen its architectural leadership in software development when so much of its software development is conducted by contractors working at arm's length from DoD mission stakeholders. SOFTWARE ARCHITECTURE AND ITS CRITICAL ROLE IN PRODUCIBILITY Software architecture is conventionally defined as "the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relation ship among them."1,2 Just as in physical systems, architectural commitments comprise more than struc tural connections among components of a system.
|
From page 69... ...
As systems scale up, the extent of effort that must be devoted to architecture also scales up, and slightly more steeply so that a greater percentage of overall effort is devoted to architectural consid erations.5 These include design, tradeoff analysis with respect to quality attributes from requirements, identification and analysis of precedent and related ecosystems, etc. It is noted by Boehm and Turner 6 that risk and precedent drive the balance between practices appropriate for precedented systems (i.e., "plan-driven methods")
|
From page 70... ...
The committee's definition of software architectures includes more than just structural considerations relating to which components may interact with which other components through what kinds of "con nectors."1 Semantic architectural commitments may relate to protocols, data representation invariants, exceptional flow of control, timing properties and deadlines, concurrency and threading, pattern compli ance, and other attributes. This combination of structural and semantic commitments is of benefit when 1 David Garlan, 2003, "Formal Modeling and Analysis of Software Architecture: Components, Connectors, and Events" in Formal Methods for Software Architectures, Pp.
|
From page 71... ...
9 Jeffrey Dean and Sanjay Ghemawat, 2004, "MapReduce: Simplified Data Processing on Large Clusters," OSDI'04: Sixth Sym posium on Operating System Design and Implementation, San Francisco, CA, December 2004. Available online at http://labs.google.
|
From page 72... ...
Morgan, Bosch, and Siemens engage in rigorous training and certification processes for their architects. In the case of Microsoft, software architects are drawn from the most senior and accomplished technical people in the company and have the responsibility for investigating architectural alterna tives, designing a system's architecture, and ensuring that the resulting software product adheres to the desired architecture.
|
From page 73... ...
Finding 3-1: Industry leaders attend to software architecture as a first-order decision, and many follow a product-line strategy based on commitment to the most essential common software architectural elements and ecosystem structures. Note that this finding focuses on the most essential commitments as comprising initial architectural decisions -- more is not necessarily better.
|
From page 74... ...
Royce, 1998, Software Project Management: A Unified Framework , Reading: Addison Wesley. 15 DSB, 1994, Report of the Defense Science Board Task Force on Acquiring Defense Software Commercially , Washington, DC: Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics.Available online at http://www.dod.gov/pubs/foi/ reading_room/859.pdf.
|
From page 75... ...
23 in DSB, June 1994, Report of the Defense Science Board Task Force on Acquiring Defense Software Commercially , Washington, DC: Office of the Under Secretary of Defense for Acquisition and Technology. Available online at http://www.dod.gov/pubs/foi/reading_room/859.pdf.
|
From page 76... ...
Despite the organizational presence of PEOs, the committee has unfortunately not seen evidence that the DoD has moved toward an overall acquisition strategy for innovative software-intensive sys tems in which software architecture has a principal role. As noted above, such approaches can make sense for several possible reasons: First, where software requirements for multiple systems are similar, software architectural commitments enable product-line strategies, with the benefits not only of reuse of common infrastructure, but also of reduced engineering risk because the reuse is planned.
|
From page 77... ...
product lines 24 "Software Architecture and Tradeoff Analysis Method," available online at http://www.sei.cmu.edu/architecture/consulting/ systematam/index.cfm. Last accessed February 20, 2010.
|
From page 78... ...
SUPPORTING TECHNOLOGY AND RESEARCH NEEDS A number of tools are emerging or maturing that can assist in assessing potential architectural design decisions. One of the most fundamental is the tradeoff analysis of diverse quality attributes in require ments with architectural models.
|
From page 79... ...
35 When there are design decisions that are expected to change over time, architectural structures can be developed to "contain" or encapsulate those particular design decisions in an implementation such that anticipated subsequent changes influence relatively few other components. Techniques related to dependency matrices are used to assess interdependencies and, based on models of potential changes to design decisions, assess the extent of impact of potential changes.
|
From page 80... ...
Specifically, each PEO could be appropriated a budget to support: • Identification and analysis of existing software architectures and ecosystems for the application areas for which the PEO is responsible; • Evaluation of the common features of those architectures leading to the definition of a productline approach for those systems and of common architectural elements and data models across systems; and • Development of improved architecture-based practices for future development. 36 Industry examples can be seen in Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall, and Werner Vogels, 2007, "Dynamo: Amazon's Highly Available Key-value Store," st ACM SIGOPS Symposium on Operating Systems Principles, W.A.
|
From page 81... ...
However, they will be trained in software architecture practices and how that relates to acquisition of software-reliant systems in the Army. The skill set they will need includes: understanding how to evaluate software architectures, having analy ses available to understand which architectural decisions will be appropriate for their requirements, employing tools to ensure that code conforms to the architecture, and building on experience to manage integrity of the software architecture during system evolution.
|
From page 82... ...
Recommendation 3-2: This committee reiterates the past Defense Science Board recommendations that the DoD follow an architecture-driven acquisition strategy, and, where appropriate, use the software architecture as the basis for a product-line approach and for larger-scale systems potentially involving multiple lead contractors. Recommendation 3-3: The DoD should enhance existing practices to afford better distinctions between precedented portions of systems and innovative portions of systems, wherein architectures are developed both to encapsulate the innovative elements and to afford maximum opportunity to build on experience and existing ecosystems for precedented elements.
|
From page 83... ...
Because the power prom ised by these systems comes at a significant price in complexity (e.g., the multitude of sensors, weapons, and battle command centers) , a greater focus is needed on engineering risk when planning the sequence of engineering commitments.
|
From page 84... ...
A theme that cuts across many of these topics is the idea of developing modeling and simulation tools suitable to informing architectural decisions, analogous to the modeling and simulation done for physical elements of many different kinds of DoD systems. This creates the possibility of a trybefore-buy approach to key architectural decisions, wherein architectural concepts are modeled using tools, and analysis and testing can be done to assess scalability, performance, robustness, and resiliency to failures and attacks.
|
From page 85... ...
Additionally, if tools are in place that can support more aggressive restructuring, then a more principled approach can be taken to architectural design that includes iterative development, currently very difficult at the architectural level. This could also enable constructive response even to relatively late-breaking news regarding the consequences of early architectural commitments.
|
Key Terms
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.