Software Management

Standard Software Risks


Standard Software-related Risks should be addressed on every program with significant software content. These are risks that can be addressed by the proper attention up front, but while such attention may reduce the level of risk, the only thing that can fully eliminate these risks is the maturing of the understanding of the system and related design over time. Risks that fall into this category include: [1]

  • Ability to properly estimate the software size and account for growth during development
  • Software reuse (if not achieved as planned, can also increase the size of the software development)
  • Performance (the degree of uncertainty that the software will meet its requirements)
  • Support (the degree of uncertainty that the resultant software will be maintainable)


Section: Risk Management


Software size and reuse erosion risks typically linger at least until the subsystem designs and related software requirements are complete, and can even be adversely affected by the completion of the software design. An increase in the overall software development/integration size or erosion of the planned software reuse (which most likely also results in an increase in the size) is early indicators that the planned software effort and schedule baselines are in jeopardy. [1]


A list of potential software risks that have been encountered in weapons system development:

  • Incompatible software development performance, effort, and schedule baselines.
  • Planned rapid staff buildup at the start of new development programs.
  • Complex, poorly defined, incomplete, or unstable system or software requirements.
  • Hand-off of software requirements from systems engineering without adequate interaction.
  • Inability to agree on and control block/increment content (also known as lack of a baseline).
  • Commercial off-the-Shelf (COTS) / Government Furnished Software availability, suitability, integration, and sustainment
  • Integration-heavy effort (significant integration effort for existing components).
  • Concurrent hardware development or requirements that drive the use of unproven tools or technology.
  • Extensive security requirements (as in multi-level security), which drive the use of immature technology. Unprecedented system and software architectures.
  • Long-duration development timeframes
  • Technical obsolescence of computing architectures and hardware.
  • Safety-critical requirements. Uncontrolled, unknown, or untrusted sources of software (foreign developers, open-source).
  •  Government Furnished Software with unknown performance capability.
  • Use of tools, methods, and technologies with which the developer has no previous experience.
  • A developer or developer team that is attempting to build systems outside their normal domains/experience.
  • Multiple developers and subcontractors teaming to develop complex software-intensive systems which must be tailored and integrated into a total system capability.


AcqLinks and References:

Updated: 7/19/2017

Leave a Reply