A Proactive Means for Incorporating a Software Architecture Evaluation in a DoD System Acquisition
July 2009 • Technical Note
This technical note provides guidance on how to contractually incorporate architecture evaluations in an acquisition.
Software Engineering Institute
CMU/SEI Report Number
DOI (Digital Object Identifier):10.1184/R1/6571715.v1
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.