Software Acquisition

AAF  > Software Acquisition  >  Definitions and Glossary

Definitions and Glossary

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: Software Acquisition Pathway Interim Policy and Procedures, 3 Jan 2020

Acronyms

ATO

authority to operate

C2

command & control

CAE

Component Acquisition Executive

CNS

capability needs statement

DAE

Defense Acquisition Executive

DAS

Defense Acquisition System

DoDI

Department of Defense Instruction

DT&E

developmental test & evaluation

MVCR

minimum viable capability release

MVP

minimum viable product

OT

operational test

PEO

Program Executive Officer

PM

Program Manager

UA

user agreement

USD(A&S)

Under Secretary of Defense (Acquisition and Sustainment)

 

Definitions

Unless otherwise noted, these terms and their definitions are for the purpose of this interim policy.

Adaptive Acquisition Framework.  A defined series of pathways for material capability acquisition to adopt that recognizes the different characteristics of capabilities to be acquired and describes the general approach and expectations that results in accelerated delivery of improved secure, prioritized capability to the end user with acceptable risk.

Backlog. A product backlog is a list of the new capabilities / features, changes to existing Capabilities / Features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome. The development team will work with the user community to decompose and prioritize the roadmap

Capabilities/Features. An iteration backlog is a list of the new stories, changes to existing stories, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome, within an iteration cadence.

Capability. Higher level solutions typically spanning multiple releases. Capabilities are made up of multiple Features to facilitate implementation.

Capability Needs Statement. Capability Needs Statements identify mission deficiencies, or enhancements to existing operational capabilities, features, interoperability needs, legacy interfaces and other attributes required for new software intensive systems or upgrades to existing systems.

Continuous ATO. The core concept of continuous ATO is to build software security into the software development methodology so that the ATO process (as with the testing process) is done alongside development. If done correctly, an ATO is nearly guaranteed once the software is release ready.

Continuous Engineering. A practice that merges requirements, design, development, quality assurance, security, test, integration, delivery, and deployment to operations into a single, continuous set of processes to continually, or iteratively, provide working functional systems to internal and external customers and to deliver high quality software more frequently.

Defect. A defect is a condition in a (software, system, hardware) product which does not meet its requirements or end-user expectation, causes it to malfunction or to produce incorrect/unexpected results, or causes it to behave in unintended ways. 

  • Escaped Defects are defects detected, or resolved, after release of the product and version containing the defect.
  • Contained Defects, also known as Saves, are defects detected and resolved before release of the product and version containing the defect.

Note: a project may decide to add detected defects to the backlog and resolve them in a later iteration or release.

DevSecOps. An organizational software engineering culture and practice that aims at unifying software development (Dev), security (Sec) and operations (Ops).  The main characteristic of DevSecOps is to automate, monitor, and apply security at all phases of the software lifecycle: plan, develop, build, test, release, deliver, deploy, operate, and monitor.  In DevSecOps, testing and security are shifted left through automated unit, functional, integration, and security testing – this is a key DevSecOps differentiator since security and functional capabilities are tested and built simultaneously.

DevSecOps Pipeline. A collection of DevSecOps tools, upon which the DevSecOps process workflows can be created and executed. DevSecOps tools are comprised of a tailored series of software products configured to integrate end-to-end software definition, design, development, test, delivery, and potentially deployment in a highly automated and secure way.

Embedded Software. Software with a dedicated function within a larger mechanical or electrical system, often with real-time computing constraints, or software applications embedded in a platform (e.g. air vehicle, ground vehicle, or ship). In the context of this policy, embedded software does not apply to firmware or software dedicated to controlling devices.

End user. Those who will ultimately use the software solution. Users convey operational concepts and requirements/needs, participate in continuous testing activities, and provide feedback on developed capabilities.

Enterprise Services. A term for services that have the proper scope to play a productive role in automating business processes in enterprise computing, networking, and data services. Responsibility for these functions is generally above the program manager.

Features. A Service or distinguishing characteristic of a software item (e.g., performance, portability, or functionality) that fulfills a stakeholder need and includes benefit and acceptance criteria within one release. Features are used to complete capabilities and are comprised of multiple Stories (or tasks, use cases, etc.).Government Developed Source Code. The product resulting from the implementation of needed capabilities into executing software that is created by the government workforce.

Iteration. A small internal time block in which the development team develops and demonstrates a set of Stories or use cases. An iteration is a full development cycle that can result in a Release. In some methodologies, an iteration is called a Sprint.

Lifecycle sustainment strategy. A strategic vision that shapes the overall development, deployment, and improvement strategy and processes so that the most important capabilities are preserved in the software while new and emerging capabilities are delivered over the entire software life cycle.

Man-Machine Interface.(also Human-Computer Interaction, Human-Machine Interaction). The actions, reactions, and interactions between humans and other system components. This also applies to a multi-station, multi-person configuration or system. Term also defines the properties of the hardware, software or equipment which constitute conditions for interactions.

Minimum Viable Capability Release. A set of features and\or capabilities suitable to be delivered to an operational environment. It provides value and capability on a reduced delivery timeline. The MVCR is analogous to a Minimum Marketable Product (MMP) in commercial industry.

Minimum Viable Product. An early version of the software that has just enough working features to meet basic minimum functional capabilities and fill a user’s need. The goal of an MVP is to quickly deliver basic capabilities into users’ hands for evaluation, feedback, and improvements.

Mission Operations. The real-world environment within which the needed military capability is required and must perform.

Mission Thread.A sequence of end-to-end activities and events, given as a series of steps that accomplish the execution of one or more capabilities that the system of systems supports.

Modern software development practices. Modern software development practices make it easier to focus teams for rapid results. Continuous engagement with end users encourages the development team to concentrate on usability and most important functionality. Cloud architecture facilitates more rapid project starts with both speed and scale as needed.

Operational Release. A release that has been approved for operational use.

Product Roadmap. A high-level visual summary that maps out the vision and direction of product offerings over time. It describes the goals and features of each software iteration and increment.

Program Manager. Designated individual with responsibility for and authority to accomplish program objectives for development, production, and sustainment to meet the user’s operational needs.

Release. A grouping of Capabilities and\or Features that can be used for demonstration or evaluation.  A release may be internal for integration, testing, or demonstration; or external to system test or as user delivery.  A release may be based on a time block or on product maturity.

Safety-critical.  Used in the context of software system safety, is a term applied to a condition, event, operation, process, or item whose mishap severity consequence is either Catastrophic or Critical (e.g., safety-critical function, safety-critical path, and safety-critical component).

Software-intensive.A system in which software represents the largest segment in one or more of the following criteria: system development cost, system development risk, system functionality, or development time.

Sponsor. The organization that holds the authority and advocates for needed end user capabilities and associated resource commitments.

Task. Steps to be completed to satisfy a Story or use case.

Technical Debt.A concept in software development that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. It represents the cost that is incurred by implementing a software solution that is expedient rather than choosing a better approach that would take longer. Technical debt often accrues over the life of a program as code is expanded and patched. Technical debt can often be “paid down” by investing in refactoring or re-architecting the code.

Use Case. In software and systems engineering, a use case is a list of actions or event steps, typically defining the interactions between a user and a system (or between software elements), to achieve a goal. Use cases can be used in addition to or in lieu of user stories.

User Agreement.A commitment between the Program Manager’s systems engineering and software program teams, the sponsor, and end-user(s) of the system.

User Story. A small desired behavior of the system based on a user scenario that can be implemented and demonstrated in one iteration. A story is comprised of one or more tasks. In software development and product management, a user story is an informal, natural language description of one or more features of a software system. User stories are written from the perspective of an end user or user of a system.

Value Assessment. The sponsor and user community shall perform a value assessment at least annually and provide justification for resources expended to deliver capabilities. End users will determine if the mission improvements and/or efficiencies realized from the delivered software capabilities are worth the investment. The decision authority will use the value assessments to measure progress on the program and inform resourcing decisions. Additional interim value assessments can be performed at any periodicity agreed to by the user and the PM.

Weapon System. A combination of one or more weapons with all related equipment, materials, services, personnel, means of delivery and deployment (if applicable) required for self-sufficiency.