Software Acquisition
AAF > Software Acquisition > Develop Strategies > Product Support Strategy
Phases
Planning Phase
Execution Phase
Activities
Define Capability Needs
Develop Strategies
Cost Estimation
Engage Users, Assess Value
MVP, MVCR, Deployment
Architecture, Interoperability
Cybersecurity
Ent Services, DevSecOps
Metrics and Reporting
DBS in SWP
Additional Resources
*AAF Pathway Resources*
SWP Quick Start Primer
SWP Artifact Templates
SWP Programs
SW In NDAAs
Glossary
FAQs
Product Support 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. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.
DoD and Service policy is indicated by a BLUE vertical line.
Directly quoted material is preceeded with a link to the Reference Source.
Reference Source: DODI 5000.87 Section 3.2.h
The PM will develop a product support strategy in accordance with applicable DoDIs that treats software development as the continuing evolution of capability across the lifetime of the system, rather than assume discrete “acquisition” and “sustainment” phases. Such a strategy will incorporate early integration of key stakeholders and planning for supportability of the software from program inception, in order to facilitate software maintenance upgrades and evolution in key activities throughout the development. If using the embedded software path, the product support strategy should be aligned with the overall sustainment strategy for the weapon system. The strategy should consider concurrent program activities that may span multiple funding appropriations.
The strategy will address contracting for tailored technical data in order to enable seamless transition of the software and its support to another organization, if and when needed. The strategy will discuss how key enabling resources (e.g., a continuous authority to operate (cATO), if applicable, automated test environments and support, or a selected development environment) will transition to government or other sources of software engineering competence. The strategy will include how any transitions allow for continuous testing and monitoring, and address the need to provide subject matter experts and/or ensure all software engineering staff are trained in the tools, techniques, and environments.