A Proactive Means for Incorporating a Software Architecture Evaluation in a DoD System Acquisition

Department of Defense (DoD) acquisition programs routinely acquire systems that are highly software reliant. With the increasing functionality and complexity of these systems, software problems often contribute to schedule slippages, cost overruns, and system deficiencies. As a result, DoD acquisition organizations need to take proactive measures to reduce software acquisition risk. They cannot afford to just perform perfunctory reviews during software development and wait until after system delivery to determine whether key performance parameters (KPPs) and other acquisition/mission drivers that are important to stakeholders will be achieved. Since the architectural design of a system and its software has a major influence on whether a system achieves its KPPs (and other acquisition/mission drivers), conducting an architecture evaluation is an effective means for reducing software acquisition risk. The evaluation involves the active participation of key stakeholders and focuses on identifying risks (and overarching risk themes) that can affect the architecture's ability to accommodate the system's quality attribute requirements (e.g., performance, safety, and security). Satisfying these quality attribute requirements is key to satisfying KPPs and other stakeholder-specific acquisition/mission drivers. This technical note describes a proactive means for incorporating such a software architecture evaluation (in collaboration with the development contractor) early in the contract performance phase of a DoD system acquisition. The proven means that is described revolves around a sample Software Architecture Evaluation Plan that a DoD program office can easily customize and use in its own Request for Proposal (RFP)/contract. The sample plan covers all aspects-that is, the "who, why, when, where, and how"-of the government's approach to conducting a software architecture evaluation during an acquisition. Moreover, this sample plan provides acquisition organizations and potential offerors with the insight needed to understand the impact of, and government's expectations for, proactively conducting a software architecture evaluation in an acquisition context

Use of Quality Attribute Workshops (QAWs) in Source Selection for a DoD System Acquisition: A Case Study

The architecture of a software-intensive system is critical to its quality. For an acquisition organization within the Department of Defense (DoD), evaluating architectures as early as possible in an acquisition can have a favorable impact on the delivered system. This technical note is a case study of how a DoD organization used architecture analysis and evaluation in a major system acquisition, early on, to reduce program risk. The case study begins by describing the system, the motivation for including architecture evaluation in the acquisition, and the Quality Attribute Workshop (QAW) approach. Following this is a brief description of the system acquisition strategy. The case study then describes the set of events (and supporting artifacts) that were required to incorporate QAW architecture analysis and evaluation in the acquisition strategy. In addition, it describes the relationship of these events and artifacts to the source-selection process. Concluding the case study is a description of the accomplishments and lessons learned, along with sample sections from the request for proposal (RFP). These sections provide additional insight into the contractual language that was used to implement the architecture analysis and evaluation approach

Progress Toward an Organic Software Architecture Capability in the U.S. Army

The goal of the United States Army Strategic Software Improvement Program is to dramatically improve the acquisition of software-intensive systems. One of the initiatives undertaken by the program is to begin building a level of technical expertise in modern software architecture practices within the Army acquisition community. This report describes the Software Architecture Initiative of the Army Strategic Software Improvement Program. Results to date are encouraging and serve as a guide for other acquisition organizations seeking to strengthen their technical competencies

Use of the Architecture Tradeoff Analysis Method (ATAM) in the Acquisition of Software-Intensive Systems

Software architecture is critical to the quality of a software-intensive system. For an acquisition organization, such as the Department of Defense (DoD), the ability to evaluate software architectures early in an acquisition can have a favorable impact on the delivered system. This technical note 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 note then provides an example of contractual language that incorporates the Architecture Tradeoff Analysis Method (ATAM) as a software architecture evaluation method in a system acquisition

Product Line Acquisition in a DoD Organization—Guidance for Decision Makers

In the Department of Defense (DoD) acquisition environment, many organizations have not seriously considered adopting a product line approach or are reluctant to because it is not a well-understood acquisition paradigm. Nonetheless, a compelling case can be made for adopting a product line approach because it addresses a problem facing many program managers today's how to cost-effectively acquire, develop, and maintain a set of related software-intensive systems and how to respond to the needs of greater product agility in the face of the current DoD transformation. This technical note chronicles the decisions a program manager might face in considering the adoption of a product line approach. This report uses a hypothetical acquisition to focus on why an acquisition organization should consider adopting a product line approach ?"instead of the traditional stovepipe approach ?"when acquiring a number of software-intensive systems that have a lot in common. The technical note provides a program manager with insight into the many benefits of adopting a product line approach and examines alternative acquisition approaches for acquiring a product line capability

Software Architecture in DoD Acquisition: A Reference Standard for a Software Architecture Document

The right software architecture is essential for a software-intensive system to meet its functional requirements as well as its quality requirements that govern real-time performance, reliability, maintainability, and a host of other quality attributes. Because an architecture comprises the earliest, most important, and most far-reaching design decisions, it is important for an acquisition organization to exercise its oversight prerogatives with respect to software architecture. Having the right software architecture documentation is a prerequisite for managing and guiding a software development effort and conducting in situ software architecture evaluations. Conducting an architecture evaluation to determine the software architecture's fitness for purpose is one of the most powerful, technical risk mitigation strategies available to a program office. This report provides an example reference standard for a Software Architecture Document (SAD). An acquisition organization can use this standard to contractually acquire the documentation needed for communicating the software architecture design and conducting software architecture evaluations. The example used in this report is drawn from an actual SAD written by a major U.S. Department of Defense contractor in a weapon system acquisition. The intent of this report is to provide an example for other acquisition efforts to use (and adapt as appropriate) in their own procurements

The U.S. Army’s Common Avionics Architecture System (CAAS) Product Line: A Case Study

This report is one in a series of Carnegie Mellon Software Engineering Institute case studies of organizations that have adopted a software product line approach for developing a family of software-intensive systems. The U.S. Army's Technical Applications Program Office (TAPO) has adopted a product line approach for the avionics software used for the Army's special operations helicopters. That software is based on Rockwell Collins' Common Avionics Architecture System (CAAS). The product line has evolved beyond its original scope and is now being adopted to include other Army aviation platforms such as cargo and utility helicopters. This case study describes the acquisition context and organizations involved in the product line, the history behind the development and evolution of the product line, its application to the mission of the Army's special operations helicopters, the Army's motivation for adopting a product line, specifics of the product line approach, and the underlying CAAS system and software architecture. The case study also highlights the software product line accomplishments, examines the results and lessons learned from TAPO's and Rockwell Collins' perspective, and discusses future considerations

Software Architecture in DoD Acquisition: An Approach and Language for a Software Development Plan

The right software architecture is essential for a software-intensive system. Meeting behavioral requirements and providing quality attributes such as real-time performance, reliability, and maintainability are essential architectural drivers. Because an architecture comprises the earliest, most important, and most far-reaching design decisions, making sure that the architecture will be fit for purpose is one of the most powerful, technical risk mitigation strategies available to a program office. This technical note covers one avenue of exercising architectural control-the Software Development Plan (SDP). The report provides an example approach and corresponding SDP language that enable software architecture to play a central role in the technical and organizational management of a software development effort. The example is drawn from an actual SDP written by a major U.S. Department of Defense contractor in a weapon-system procurement. The intent is to provide an example for other acquisition organizations to use (and adapt as appropriate) in their own procurements. While the example is based on a contracting approach with a lead system integrator, it can serve as a model for using an architecture-centric approach effectively to unify and manage software development across multiple suppliers, as found in the conventional prime-with-subcontractors acquisition context

An Application of an Iterative Approach to DoD Software Migration Planning

In recent years, system modernization has received much attention within the Department of Defense (DoD). Typically, that attention has focused on the technical and acquisition issues associated with the new system. Less attention has been paid to the equally important issue of planning the migration from the old system to the new system. This technical note reports on the early results of an approach that is currently being piloted to support software migration planning. This approach focuses on deriving actionable mini-plans for focus areas that are identified in an initial increment of an overall migration plan

Use of the Architecture Tradeoff Analysis Method (ATAM) in Source Selection of Software-Intensive Systems

Software architecture is critical to the quality of a software-intensive system. For an acquisition organization, such as the Department of Defense (DoD), the ability to evaluate software architectures as early as possible in an acquisition can have a favorable impact on the delivered system. This technical note explains the role of software architecture evaluation in a source selection and describes the contractual elements that are needed to support its use. The note then briefly describes the Architecture Tradeoff Analysis Method (ATAM) and provides an example that shows how to apply this method in a source selection. The example includes sample contractual language that an acquirer can adapt to meet specific acquisition needs