Software Architectures and Acquisition
• Collection
Publisher
Software Engineering Institute
Topic or Tag
Abstract
A major responsibility of DoD acquisition programs is to perform technical oversight and technical monitoring of the systems it acquires during the contract performance phase. Although these system acquisitions are highly software intensive, software considerations often take a back seat to system considerations due to
- limited resources of the acquisition organization
- policies that emphasize a systems acquisition and system engineering focus
- software reviews that are often reactive or perfunctory in nature
- a lack of proven methods for evaluating software qualities early in the early software development cycle
Since the quality and longevity of a software intensive system is largely determined by its architecture, there is a growing recognition that the DoD acquisition community can realize significant benefits by adopting an architecture-centric software acquisition approach. Architecture-centric development involves iteratively
- understanding the mission drivers and creating the business case for the system
- understanding the stakeholder requirements
- creating or selecting the software architecture
- documenting and communicating the software architecture
- analyzing or evaluating the software architecture
- implementing the system based on the software architecture
- ensuring that the implementation conforms to the software architecture
The importance of focusing on the software architecture is that it embodies the earliest set of design decisions about a system. These design decisions
- are the most profound
- are the hardest to get right
- are most difficult to change
- drive the entire software development effort
- are most costly to fix downstream
- are critical to achieving mission/business goals
Software architectures that are poorly designed result in greatly inflated development and integration and testing costs and an inability to sustain systems in a timely and affordable manner. As a result, the earlier the acquisition organization can evaluate the architecture as to its ability to achieve the desired system qualities (e.g., performance, security, availability, interoperability, modifiability, openness, and so forth) the better.
To support the DoD, the SEI has collaborated with DoD acquisition organizations and their contractors in transitioning and applying some of the architecture-centric techniques and methods developed under at the SEI in actual systems acquisitions. The overarching goal is to reduce software acquisition risk.
A number of the architecture-based collaborations have been documented in technical reports and technical notes that are relevant to or address some aspect of promoting an architecture-centric software development approach in an acquisition context.
Collection Items
The U.S. Army's Common Avionics Architecture System (CAAS) Product Line: A Case Study
• Technical Report
By Paul C. Clements, John K. Bergey
This report offers a case study of organizations that have adopted a software product line approach for developing a family of software-intensive systems.
ReadUsing the Architecture Tradeoff Analysis Method to Evaluate a Reference Architecture: A Case Study
• Technical Note
By Brian P. Gallagher
This report describes the application of the ATAM (Architecture Tradeoff Analysis Method) to evaluate a reference architecture for ground-based command and control systems.
ReadUsing the Architecture Tradeoff Analysis Method (ATAM) to Evaluate the Software Architecture for a Product Line of Avionics Systems: A Case Study
• Technical Note
By Mario R. Barbacci, Paul C. Clements, Anthony J. Lattanze, Linda M. Northrop, William Wood
This 2003 technical note describes an ATAM evaluation of the software architecture for an avionics system developed for the Technology Applications Program Office (TAPO) of the U.S. Army Special Operations …
ReadUsing the SEI Architecture Tradeoff Analysis Method to Evaluate WIN-T: A Case Study
• Technical Note
By Paul C. Clements, John K. Bergey, Dave Mason
This report describes the application of the SEI ATAM (Architecture Tradeoff Analysis Method) to the U.S. Army's Warfighter Information Network-Tactical (WIN-T) system.
ReadArchitecture Tradeoff Analyses of C4ISR Products
• Technical Report
By Mario R. Barbacci, William Wood
This report describes how various C4ISR products can be used in the context of an ATAM evaluation and their relative value for generating quality attribute-specific scenarios required for an ATAM …
ReadDoD Architecture Framework and Software Architecture Workshop Report
• Technical Note
By William Wood, Mario R. Barbacci, Paul C. Clements, Steve Palmquist, Huei-Wan Ang, Loring Bernhardt, Fatma Dandashi, David Emery, Sarah Sheard, Lyn Uzzle, John Weiler, Art Krummenoehl
This report summarizes the activities of the Workshop on the Department of the 2003 Defense Architecture Framework and Software Architecture workshop.
ReadDoD Experience with the C4ISR Architecture Framework
• Technical Note
By William Wood, Sholom G. Cohen
This report discusses the context for using the C4ISRAF, the observations made during the interviews about its use, and the strengths and challenges of using it.
ReadRisk Themes Discovered Through Architecture Evaluations
• Technical Report
By Len Bass, Robert Nord, William Wood, David Zubrow
This 2006 report analyzes the output of 18 evaluations conducted using the Architecture Tradeoff Analysis (ATAM). The goal of the analysis was to find patterns in the risk themes identified …
ReadUse of the Architecture Tradeoff Analysis Method (ATAM) in Source Selection of Software-Intensive Systems
• Technical Note
By John K. Bergey, Matt Fisher, Lawrence G. Jones
This report explains the role of software architecture evaluation in a source selection and describes the contractual elements that are needed to support its use.
ReadUse of the ATAM in the Acquisition of Software-Intensive Systems
• Technical Note
By John K. Bergey, Matt Fisher
This report discusses the role of software architecture evaluations in a system acquisition and describes the contractual elements that are needed to accommodate architecture evaluations in an acquisition. The report …
ReadUsing the Architecture Tradeoff Analysis Method to Evaluate a Wargame Simulation System: A Case Study
• Technical Note
By Lawrence G. Jones, Anthony J. Lattanze
This report describes the application of the ATAM (Architecture Tradeoff Analysis Method) to a major wargaming simulation system.
ReadProgress Toward an Organic Software Architecture Capability in the U.S. Army
• Technical Report
By Stephen Blanchette, Jr., John K. Bergey
This 2007 report describes the Software Architecture Initiative of the Army Strategic Software Improvement Program.
ReadSoftware Architecture Evaluation with ATAM in the DoD System Acquisition Context
• Technical Note
By John K. Bergey, Matt Fisher, Lawrence G. Jones, Rick Kazman
This report explains the basics of software architecture and software architecture evaluation in a system acquisition context.
ReadStructural Modeling: An Application Framework and Development Process for Flight Simulators
• Technical Report
By Gregory Abowd, Len Bass, Larry Howard, Linda M. Northrop
This paper presents the structural modeling approach, an application framework and development process for the construction of flight simulators.
ReadA Case Study in Structural Modeling
• Technical Report
By Gary Chastek, Lisa Brownsword
This report describes structural modeling, a technique for creating software architectures based on a small set of design elements called structural types.
ReadSoftware Architecture in DoD Acquisition: A Reference Standard for a Software Architecture Document
• Technical Note
By John K. Bergey, Paul C. Clements
This report provides a reference standard for a Software Architecture Document (SAD). Acquisition organizations can use this to acquire documentation needed for communicating the architecture design and conducting software architecture …
ReadSoftware Architecture in DoD Acquisition: An Approach and Language for a Software Development Plan
• Technical Note
By John K. Bergey, Paul C. Clements
This report discusses the Software Development Plan (SDP), providing an example approach and corresponding SDP language that enable software architecture to play a central role in the technical and organizational …
ReadA Comparison of Requirements Specification Methods from a Software Architecture Perspective
• Technical Report
By Len Bass, John K. Bergey, Paul C. Clements, Paulo Merson, Ipek Ozkaya, Raghvinder Sangwan
In this report, five methods for the elicitation and expression of requirements are evaluated with respect to their ability to capture architecturally significant requirements.
Read