Paying Due Diligence to Software Architecture in Acquisition
• Presentation
Publisher
Software Engineering Institute
Topic or Tag
Abstract
Acquiring systems that provide the necessary capability and functionality to warfighters is at the heart of all system acquisition efforts. But what significantly impacts much of the development, integration, operation, and maintenance costs and risks are the nonfunctional drivers of the system, also called quality attributes. Examples of quality attributes include availability, security, openness, maintainability, reusability, performance, testability, and usability. Many quality attributes are embodied in the system and software architectures, and the supporting architectural approaches must be analyzed and traded off against each other to successfully achieve the mission and business drivers of the system. All too often, systems’ acquisition strategies and associated artifacts (e.g., RFI, RFP, SOO, SOW) do not adequately address the architecture and quality attribute drivers for the system. As a result, the program office has little control of or visibility into the architecture and design solutions provided by the contractor. When architecture and design issues eventually arise, it is often late in the lifecycle (e.g., during integration, operations, or maintenance), resulting in costly rework. Due diligence must be paid to the software architecture and quality attributes as early in the lifecycle as possible.
This presentation will describe approaches that the Carnegie Mellon Software Engineering Institute has used with program offices to adopt software architecture and quality attribute practices in acquisition contexts to give program offices better specificity, visibility, and management of the software architecture and the quality attributes of the system. The talk will also discuss lessons learned in the application of the approaches.
Part of a Collection
Software Solutions Conference (SSC) 2015 Presentations
This content was created for a conference series or symposium and does not necessarily reflect the positions and views of the Software Engineering Institute.