Software Architecture

Software Architecture and Acquisition

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. This means engaging contractors who adhere to architecture-centric principles and who follow an iterative process for creating software that involves

  • understanding the mission drivers and creating the business case for the system
  • understanding the stakeholder requirements
  • creating software architecture that will enable the system to meet both functional and quality requirements
  • 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 costs for development, integration, and testing 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 at the SEI in actual systems acquisitions. The overarching goal of this research was to reduce software acquisition risk.

Software Architecture Training and Publications

Training

Publications

A number of the architecture-based collaborations have been documented in technical reports that are relevant to or address some aspect of promoting an architecture-centric software development approach in an acquisition context. These reports are listed below.

Case Studies

The U.S. Army's Common Avionics Architecture System (CAAS) Product Line: A Case Study
Paul Clements & John Bergey

Using the Architecture Tradeoff Analysis Method to Evaluate a Reference Architecture: A Case Study
Brian Gallagher

Using the Architecture Tradeoff Analysis Method (ATAM) to Evaluate the Software Architecture for a Product Line of Avionics Systems: A Case Study
Mario Barbacci, Paul Clements, Anthony Lattanze, Linda Northrop, & William Wood

Using the SEI Architecture Tradeoff Analysis Method (ATAM) to Evaluate WIN-T: A Case Study
Paul Clements, John Bergey, & Dave Mason

Architecture-Focused Standards

Architecture Tradeoff Analyses of C4ISR Products
M. Barbacci & W. Wood

DoD Architecture Framework and Software Architecture Workshop Report
William G. Wood, Mario Barbacci, Paul Clements, Steve Palmquist, Huei-Wan Ang, Loring Bernhardt, Fatma Dandashi, David Emery, Sarah Sheard, Lyn Uzzle, John Weiler, & Art Krummenoehl

DoD Experience with the C4ISR Architecture Framework
William G. Wood & Sholom Cohen

Architecture Evaluation in an Acquisition Context

Risk Themes Discovered Through Architecture Evaluations
Len Bass, Robert Nord, William Wood, & David Zubrow

Use of the Architecture Tradeoff Analysis Method (ATAM) in Source Selection of Software-Intensive Systems
John K. Bergey, Matthew J. Fisher & Lawrence G. Jones

Use of the Architecture Tradeoff Analysis Method (ATAM) in the Acquisition of Software-Intensive Systems
John K. Bergey & Matthew J. Fisher

Using the Architecture Tradeoff Analysis Method to Evaluate a Wargame Simulation System: A Case Study
Lawrence G. Jones & Anthony J. Lattanze

Using the Architecture Tradeoff Analysis Method (ATAM) to Evaluate the Software Architecture for a Product Line of Avionics Systems: A Case Study
Mario Barbacci, Paul Clements, Anthony Lattanze, Linda Northrop, William Wood

Using the SEI Architecture Tradeoff Analysis Method to Evaluate WIN-T: A Case Study
Paul Clements, John Bergey, Dave Mason

Using the Architecture Tradeoff Analysis Method to Evaluate a Reference Architecture: A Case Study
Brian Gallagher

Software Architecture Evaluation with ATAM in the DoD System Acquisition Context
John K. Bergey, Matthew J. Fisher, Lawrence G. Jones, & Rick Kazman

Architecture Training

Progress Toward an Organic Software Architecture Capability in the U.S. Army
Stephen Blanchette Jr. & John Bergey

Architecture-Related Documentation

A Comparison of Requirements Specification Methods from a Software Architecture Perspective
Len Bass, John Bergey, Paul Clements, Paulo Merson, Ipek Ozkaya, & Raghvinder Sangwan

Software Architecture in DoD Acquisition: An Approach and Language for a Software Development Plan
John K. Bergey & Paul C. Clements

Software Architecture in DoD Acquisition: A Reference Standard for a Software Architecture Document
John K. Bergey & Paul C. Clements

Other Architecture-Related Applications

A Case Study in Structural Modeling
Gary Chastek & Lisa Brownsword

Structural Modeling: An Application Framework and Development Process for Flight Simulators
Gregory Abowd, Len Bass, Larry Howard, & Linda Northrop

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to del.ico.us  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us

info@sei.cmu.edu

412-268-5800

Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.