Software acquisition

Software Acquisition. Return to SW Acq Home. Acquisition Strategy. How to use this site Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. Directly quoted material is preceeded with a link to the Reference Source.

The PM will actively collaborate with program stakeholders and functional experts in developing the acquisition strategy given the current environment, priorities, risks, and approach.

The DA will approve the acquisition strategy to include process and documentation tailoring. The acquisition strategy for an embedded software system must align with and may be included as part of the platform acquisition strategy.

The PM will mature the strategy to the point where it has sufficient rigor for the DA to approve beginning development, and will continuously refined it throughout the acquisition lifecycle.

Key elements of the acquisition strategy include, but are not limited to: Risk-based business and technical management approach to rapidly and iteratively deliver software capabilities balanced against quality, security, intelligence threats, system safety, performance, and other factors.

Roadmap and cadence for software deliveries to operations including: Demonstrating the viability and effectiveness of capabilities for operational use not later than 1 year after the date on which funds are first obligated Continuously delivering capabilities to operations at least annually thereafter. If using the embedded software path, aligning and integrating with the development and fielding for the systems in which the software is embedded.

Flexible and modular contract strategy that enables software development teams to rapidly design, develop, test, integrate, deploy, and support software capabilities. Planned use of government personnel and resources for software activities. Tailoring of acquisition processes to adopt modern software development practices e. Planned use of existing enterprise services, infrastructure, and resources. High level test strategies, coordinated with the test and evaluation community, to validate software quality, integration and automation of testing, along with planned test platforms, resources, and infrastructure.

Architecture strategies to enable a modular open systems approach that is interoperable with required systems. Cybersecurity strategies in accordance with the applicable cybersecurity policies and issuances which include recurring assessment of the supply chain, development environment, processes and tools, continuous automated cybersecurity test and operational evaluation to provide a system resilient to offensive cyber operations.

IP, training, and product support strategies; and records management requirements in accordance with the appropriate DoDIs to ensure lifecycle supportability. Constructing the acquisition strategy for an iterative software development program also requires the following activities: Develop the roadmap: The roadmap must identify how often to deliver working software to operational users, based on a cadence that is appropriate to meet user needs. The roadmap must also describe the overall approach for managing iterative software development, showing how the software iterations fit with any constraints from interfacing systems or hardware dependencies.

The program must describe how it will allow detailed requirements to be prioritized and developed with user involvement while ensuring progress toward implementing the high-level features needed. Select a software development framework to guide the work: Based on technical constraints, prior experience and other considerations, the program should state whether it has already selected an Agile framework e.

Develop a plan for obtaining competencies in modern software development practices on the government team: The program should describe what gaps exist, in terms of bringing sufficient expertise in modern software practices into the team, and have a plan for filling those gaps in a way that scales up realistically e.

The SWP is designed to be the ideal, default pathway for software development to balance speed with rigor. While the middle two columns discuss the typical thought patterns on switching, the right most column outlines measures to reduce switching costs and make it more attractive to transition to the pathway specifically tailored for software.

Software Acquisition. Return to AAF Pathways. Software Acquisition This pathway is to facilitate rapid and iterative delivery of software capability to the user. How to use this site Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. Directly quoted material is preceeded with a link to the Reference Source.

Lifecycle View of Software Acquisition. The applications path provides for rapid development and deployment of software running on commercial hardware, including modified hardware, and cloud computing platforms.

The embedded software path provides for the rapid development, deployment, and insertion of upgrades and improvements to software embedded in weapon systems and other military-unique hardware systems.

The system in which the software is embedded could be acquired via other acquisition pathways e. Why the Software Acquisition Pathway? Speed and cycle time matter. Faster is more reliable, secure, and possible.

Section directed DoD to: Create software acquisition pathways for applications and embedded systems. Programs using these pathways shall not be treated as an MDAP.

DoD shall streamline software requirements, budget, and acquisition processes. Programs using these pathways must demonstrate viability and effectiveness of capabilities for operational use within one year after funds first obligated.

Sponsors and users are delighted with results. Program is failing to delivery anticipated value. Sponsors and users are not satisfied with results.

Documents Program strategy documents are approved and current. Concerned about time and energy to restaff docs for approval and add unique SWP docs. Program strategy documents do not reflect current environment. DA is PEO or below with limited coord required for new or updated docs. Delegate decision authorities. Enable transition to SWP yet allow time to update docs.

Leverage portfolio strategies. Requirements Approved requirements documents cover current scope, fairly current, and flexible enough. Requirements are not expected to change. Process to update or staff new req doc is long, unknown, or painful.

Requirements and needs of customers change frequently. Service has streamlined process to approve CNS. Tailor and streamline CNS content and approvals. Program able to do Agile within current constraints. Train leadership and workforce on Agile, DevSecOps. Leverage coaches to guide programs and execs.

Develop portfolio or Service contracts for SW dev services. Train workforce on effective Agile contracting. Contractors are not flexible to meet the needs of Agile, DevSecOps practices.

Rate vendors and compile research of effective SW development vendors. Capture customer, team satisfaction ratings with vendors for future contracting purposes. Timing Program just got through a major Milestone decision, documents were approved, and contract awarded. Now is a good time to reconsider approach. Delegate decisions, maximize tailoring and streamlining. Break Point Program in the middle of development for a major set of capabilities, infrastructure, contracts, etc. Provide flexibility to scope new development, while completing current efforts.

Delivery Cadence Low confidence the PMO or contractors can regularly deliver software or have the ability to scope an MVCR to deliver within a year of obligating funds. Program already delivering within an annual cadence or can scope an MVCR to deliver within a year.

Aggressively lean functional processes to accelerate software deliveries. Service HQs are knowledgeable, have tailored, and streamlined processes for SW with delegated decision authorities. Educate, train, and incentivize functional leaders to shift to customer-centric processes that drive value, lean, and continuously improve processes.

HW and SW are able to be de-coupled and the interfaces between the pathway can be managed effectively. Infuse modern design, architecture, digital engineering, and related practices. If SWP programs operate with greater speed and flexibility to deliver software. Apply above recommendations and continuously improve. SWP Overview Video. SWP Overview Briefing. Operationalizing the SWP Video. Contact the Software Acquisition Pathway Team. Program is delivering anticipated value efficiently and effectively.