Software Acquisition

AAF  >  Software Acquisition  >  Planning Phase

Reference Source: DODI 5000.87 Section 3.2

 

The purpose of this phase is to better understand the users’ needs and plan the approach to deliver software capabilities to meet those needs. The planning phase will be guided by a draft CNS developed by the operational community. The sponsor will approve the CNS before the execution phase starts.

 

• The program office and related stakeholders will actively engage users throughout the software lifecycle to understand their mission deficiencies, required enhancements to existing operational capabilities, cybersecurity requirements, features, interoperability needs, legacy interfaces, intelligence needs, threat intelligence, and other desired attributes.
• All required capabilities in the CNS should be prioritized to effectively guide the software development.
• Periodic review of the CNS should occur at least as often as each value assessment to determine if updates are warranted.

During the planning phase, the DA will select a PM and may establish a new program office or assign an existing program office to shape and plan the software acquisition. The PM will develop a constrained, tailored set of strategies to acquire, develop, and deliver the software capabilities, and will obtain the necessary resources (e.g., people, funding, technology) to effectively execute the strategies.

 

The program should begin developing the software design and architecture, leveraging existing enterprise services as much as possible.

• The program will also consider the development environment, processes, automated tools, designs, architectures, and implications across the broader portfolio, component, and joint force.
• The chosen software development methodology will incorporate continuous testing and evaluation, resiliency, and cybersecurity, with maximum possible automation, as persistent requirements and include a risk-based lifecycle management approach to address software vulnerabilities, supply chain and development environment risk, and intelligence threats throughout the entire lifecycle.
• The program may develop prototypes or initial capabilities to explore possible solutions, architecture options and solicit user and stakeholder feedback.

 

The DA will validate there are appropriate strategies, analysis, and resources are in place to successfully transition from the planning phase to the execution phase. The approved artifacts required to enter the execution phase include the CNS, user agreement (UA), acquisition strategy, test strategy, and cost estimate. The DA may have a meeting with key stakeholders to review the program’s strategies to make the decision. Programs using the embedded software
path align their strategies with the programs into which they will be integrated.

 

Programs using the software acquisition pathway will be identified in component and DoD program lists and databases within 60 calendar days of initiating the planning phase in accordance with DoD’s implementation of Section 913 of Public Law 115-91 on acquisition data analysis.

Entering the Planning Phase

Reference Source: USD(A&S) Guidance

The following are required to enter the SWP Planning Phase:

Reference Source: DODI 5000.87 Section 3.1

The DA will document the decision and rationale for a program to use the software acquisition pathway in an acquisition decision memorandum.

Procuring Hardware on the SWP

Reference Source: OUSD (A&S) Guidance

While the primary intent of the SWP is to provide acquisition programs with a streamlined means of delivering software capability faster, there is broad recognition that hardware will need to be procured to support the development, testing and fielding of that software.

Commonly expected hardware procurement items to support and enable software delivery includes servers, racks, workstations, computer equipment, peripherals, and hardware-in-the-loop test suites (for embedded path programs). There is no threshold for procurement of hardware items in direct support of development, testing, training, and fielding activities.

Less common hardware procurement items include sensors, non-commercial user equipment and other electronic equipment items that are intended to be employed by operational users.  While there is no clear threshold for the purchase of these types of hardware items, the expectation is that the funding allocated to hardware procurement is at a reasonable level and does not disproportionally outweigh the funding dedicated to software development, testing and fielding activities.

Custom design and development of hardware, even if intended to enable software, should not be conducted on the SWP.  There are other pathways, such as the Middle Tier of Acquisition, that can be seamlessly combined with the SWP to enable that type of work. (For an example of combined pathways, see Vignette: MTA and SWP Hybrid Acquisition Approach)