The following are best practices detailed in the Defense Acquisition Guidebook (DAG) in Chapter 4.4.16 for software systems but also could be applied in general to any system: [1]

  • Viewing the software “content,” particularly complex algorithms and functional flows, as enabling technologies requiring maturation and risk reduction before Milestone B,
  • Developing architectural-based software systems that support open system concepts,
  • Exploiting Commercial off-The-Shelf (COTS) computer systems products,
  • Allowing incremental improvements based on modular, reusable, extensible software,
  • Identifying and exploiting, where practicable, government and commercial software reuse opportunities before developing new software,
  • Selecting the Programming Language in context of the systems and software engineering factors that influence system performance, overall life-cycle costs, risks, and the potential for interoperability,
  • Using DoD standard data and following data administrative policies in DoD Directive 8320.02,
  • Selecting contractors with domain experience in developing comparable software systems, successful past performance, and demonstrated commitment to disciplined software development process.
  • Assessing information operations risks (see DoD Directive 3600.01) using techniques such as Program Support Reviews (PSR),
  • Preparing for life-cycle software support or maintenance by planning early in the system life cycle for the transition of fielded software to the support/maintenance activity, developing or acquiring the necessary documentation, host systems, test beds, and computer-aided software engineering tools consistent with planned support concepts,
  • Tracking COTS software purchases and maintenance licenses, and
  • Performing system safety engineering tasks on safety-critical systems to reduce the safety risk in all aspects of a program, including the software system safety (SSS) activities involving the design, code, test, Independent Verification and Validation (IV&V), operation & maintenance, and change control functions of the software engineering development process.

The Program Manager (PM) should structure a Software Development Process to recognize that emerging capabilities and missions will require modification to software over the life cycle of the system. To deliver truly state-of-the-software, this process should allow for periodic software enhancements. [1]

When contemplating the use of Non-Developmental Software (NDS), consider the following: [1]

  • Ensure decisions to use NDS are based on and are traceable to validated system architecture and design requirements.
  • Include appropriate NDS activities in the program Integrated Master Plan (IMP) / Integrated Master Schedule (IMS).
  • Evaluate all proposed NDS to the extent possible at the start of the development
  • Establish configuration control procedures to address NDS integration, upgrades, and changes throughout the system life cycle.
  • Assess suitability and manage technical risk inherent in NDS during the system development phase. ·         Address security/assurance concerns with COTS software.
  • Track COTS software purchases and maintenance licenses.

AcqLinks and References:

Updated: 7/19/2017

Print Friendly, PDF & Email