Risk Management Toolkit

Support Assets

Taxonomies

Risk Areas:
Software

Risk Management home

Risk Areas' page

Process Assets
Standard Process
  • Definitions
  • Steps of Process
  • Tailoring Guidelines

    Compliance

  • Self Assessment
  • Compliance Process
  • CMMI Risk Management Goals
  • Risk Review

    Policy

  • AF Policy Directive 90-9: Operational Risk Management, 1 April 2000
  • AFI 90-901: Operational Risk Management, 1 April 2000
  • AFMC Instruction 90-902: Operational Risk Management, Dec 2007

    Support Assets
    Procedures

  • Affinity Diagrams
  • Brainstorming
  • Risk Plotting
  • Risk Statements

    Taxonomies

  • Individual
  • Consolidated
  • Risk Areas

    • Tools & Techniques

  • RiskNav
  • Risk Matrix
  • Risk Radar

    Training

  • Risk Process Orientation
  • Detailed Risk Process
  • Facilitator Training

    Examples

  • Sample Risk Management Plan
  • Process Lessons Learned

    		•   

    Description:
    Computer programs, procedures, and possibly associated documentation and data, pertaining to the operation of a computer system.

    Risks:

    • Are the following software elements under configuration control?
      • prototype code?
      • system architecture, including software architecture?
      • source code?
      • manuals and installation instructions?
      • development environment?
      • test environment, including test procedures and configurations?
      • hardware platforms?
      • interface requirements?

    • Is the software achieving desired responsiveness?

    • Is the software achieving processing reserve goals?

    • Is the software achieving system response?

    • Is the software achieving system throughput?
      • at full load?

    • Are requirements allocated between software and hardware correctly?

    • Are there software requirements for:
      • real-time processing?
      • parallel/multi-processing?
      • reverse-engineering?
      • code reuse?

    • Are the performance constraints known and documented?

    • Are the software requirements beyond state-of-the-art?

    • Are the software requirements stable?

    • Is software tested early and repeatedly with hardware components as they become available?

    • How capable is the contractor for developing software?

    • How capable is the contractor for integrating software and hardware?

    • Does the contractor (or developer) have disciplines processes and practices for developing software?

    • Is the software within set thresholds for:
      • memory utilization?
      • operating system compatibility?
      • stability?

    • Are contingencies developed for software exceeding one or more set thresholds?

    • Does software interface with Commercial-off-the-Shelf (COTS) hardware or software?

    • Does software interface with Government-off-the-Shelf (GOTS) hardware or software?

    • Is the software migrating or porting to:
      • object-oriented languages and/or models?
      • another operating system?
      • another hardware platform?

    • Does software development require multiple programming languages?
      • Do developers have appropriate skill set for programming languages used?
      • Are developers aware of programming language dependancies (libraries, debuggers, etc.)?

    • Is software being developed at multiple locations?

    • Is there a single/consistent estimating process or method in use on the program for:
      • software size?
      • software schedule?
      • metrics and/or measures?

    • Has a software development of this size or complexity ever been completed successfully before?
      • Does the program have lessons learned from prior efforts?
      • Does the program have risk insight into prior efforts?

    • Are software standards required?

    • Is the software Year 2000 compliant?

    Related Topics:



    Back to top