2.0 Background

The SEI Risk Program defines software technical risk as the possibility that the application of selected theory, principles, and techniques will fail to yield the right software product. The management of software technical risks is a practice which is key to the maturation of software development into an engineering profession. A disciplined and systematic method of identifying, confronting, and resolving technical risk is critical to controlling the quality, cost, and schedule of software products.

The SEI Risk Program is focused on identifying and developing methods and processes that support systematic management of software technical risk. The program seeks to improve software development successes by identifying key risk management practices and the criteria by which these practices can be integrated into software development processes and program management. The focus of the SEI Risk Program provides solid support for the creation of an encompassing SRE model that may be applied in DoD software intensive acquisitions. The SWAP-WG recognizes that government acquisition program managers are generally sensitive to the risks associated with software acquisitions, but require a systematic and disciplined approach for identifying and addressing those risks. The work of the SEI Risk Program's Independent Risk Assessment (IRA) Project is designed to address these needs.

Earlier work by the Risk Program produced a Risk Management Paradigm (see Figure 2-1) which provides the infrastructure for evolving the building blocks to managing risks and integrating risk management into existing and future software development programs. The paradigm defines a continuous set of activities that must be undertaken to identify, communicate, and resolve technical risk. This model is represented as a circle to emphasize that risk management is a continuous process, while the arrows show the logical and temporal flow of in- formation between the activities in risk management. A brief summary of each risk management paradigm activity follows:

Identify: Identification surfaces software-related risks before they become actual problems which adversely affect the project. Before risks can be managed, they must be identified.

Analyze: Analysis is the conversion of identified risk data into decision-making information, and provides the quantification and oversight clarity needed to guide the project manager to work on the "right" risks.

Plan: Planning involves developing actions to mitigate individual software risks, prioritizing risk mitigation actions, and integrating these actions into an executable risk management plan.

Track: Tracking consists of implementing the risk management plan and monitoring the status of risks and actions taken to mitigate those risks. Risk metrics and triggering events are monitored as part of the tracking function.

Control: Control corrects for deviations from planned risk mitigation actions; and builds on project management processes to control mitigation plans, respond to triggering events, and improve risk management processes.

Communication: Communication among the appropriate organizational entities must exist for risks to be identified, analyzed, planned for, tracked, and controlled correctly. Risk communication lies at the center of the paradigm to emphasize both its pervasiveness and its criticality.

As of this writing, the SEI Risk Program has drafted a questionnaire-based risk identification method scheduled for formal release as an SEI Technical Report in June 1993) as an approach to addressing the first activity in the Risk Management Paradigm. The questionnaire was developed to provide coverage of the risk areas defined in the SEI's Taxonomy of Software Development Risk (see Figure 2-2). The taxonomy defines a framework for organizing and studying the full breadth of potential software technical risk. Appendix A describes the tax- onomy hierarchy in detail. The taxonomy-based questionnaire applies a systematic data gathering technique to facilitate an objective and consistent identification of software technical risks across the entire taxonomic spectrum. The taxonomy-based questionnaire is at Appendix B.

Field testing of the taxonomy-based questionnaire approach to risk identification has evolved a method of application based on a form of non- judgmental, assisted self-assessment performed in support of the target program. One outcome of these field tests was a widely supported recommendation that similar, formal risk identifications might also be conducted in an evaluative environment during the early phases of software acquisitions. The knowledge gained regarding potential project risks might then be used to directly reduce acquisition risk either by removing or mitigating high risk items in the acquisition, or by evaluating the contractor proposals for dealing with the risks.

The development approach for the SRE methodology has been to tailor the application of the Risk Program's taxonomy-based questionnaire to support independent, evaluative reviews of target programs. The resulting methodology is designed to be a reliable and coherent alternative to the numerous ad hoc "expert" review approaches typically employed to conduct program audits.

The SRE is designed to surface risk issues that jeopardize successful completion of a subject software development program at a snapshot in time. The SRE extracts risk issues as seen from the perspective of the developing contractor. The final product of an SRE is a presentation to the acquisition management customer.