Overview
In this activity, identified risks are documented, analyzed, mitigated, tracked, and closed. For a detailed discussion of risk management see [SEI, 1996] .
Roles and Responsibilities
All software project personnel are responsible for identifying risks.
The project software manager is responsible for assigning personnel to analyze the identified risks, prioritizing the risks, determining a risk mitigation strategy, and tracking the risks.
Controls
The software project’s risk management approach as documented in the Risk Management section of the Software Development Plan (SDP) (see Appendix E).
The Risk Information Form (see Appendix C) used to document and analyze risks.
The Project Plan which documents how project-level risks are to be reported and handled.
Inputs
Risks identified by software project personnel.
Procedures
1) Risks are identified by software project personnel throughout the software project’s life cycle. Risks are reported by completing the Risk Statement and Context Sections of the Risk Information Form, and entered into the risk tracking system (see activity 1.1.1.4 Plan Risk Management).
2) The project software manager assigns an individual to analyze the identified risks.
3) The individual analyzing the identified risks determines the potential impact, products which could be impacted, probability, and time frame associated with the risk. This analysis should be periodically repeated based upon software project changes. This information is documented in the appropriate sections of the Risk Information Form. A risk that impacts the entire project or other domains (e.g., hardware, optics) should be identified to the project manager in accordance with the risk management approach defined in the Project Plan.
4) As risks are identified and analyzed, the project software manager prioritizes them to identify those that are the most critical and must be handled. This prioritization is documented in the Priority section of the Risk Information Form.
5) For an identified critical risk, the project software manager (or a designee) determines an approach to mitigating the risk, and contingency plans for handling the problem if it occurs. The software project plans (e.g. SDP, Software Test Plan (STP)) are updated accordingly (see activity 1.2.1.4 Maintain Software Project Plans). As part of the risk mitigation strategy, the software metrics required to track the identified risks (and determine if the problem has materialized) are identified. This information is documented in the Mitigation Strategy and Contingency Plan and Trigger sections of the Risk Information Form. If the identified metrics include software metrics not being tracked and/or reported by the software engineering process group (SEPG), a Software Change Request (SCR) (see Appendix C) (see activity 2.2.4 Request Software Product Change) may be written and submitted to the SEPG (see activity 4.2.4 Maintain Process Standard) requesting that the software metric database be modified to track and/or report the required data.
6) As the software project continues, the risk tracking data is monitored. If a risk ceases to exist, it is closed and the Closing Date and Closing Rationale are documented on the Risk Information Form. If the risk increases or becomes realized, the project management plans must be updated (see activity 1.2.1.4 Maintain Software Project Plans). As long as a risk is open, it should be discussed at the software project team meetings, and if necessary, reanalyzed and prioritized (see steps 2 and 3). The changes in the status of the risk are documented in the Status section of the Risk Information Form.
Outputs
Documented risks identified on the Risk Information Form(s)