A
risk is a potential problem – it might happen or it might not. But, regardless
of the outcome, it’s a really good idea to identify it, assess its probability
of occurrence, estimate its impact, and establish a contingency plan. Risk management is a series of steps that
help a software team to understand and manage uncertainty. The first step in
risk management is to recognize what can go wrong, called risk identification.
Next, each risk is analyzed to determine the likelihood that it will occur and
the damage that it will do if it does occur. Once this information is
established, risks are ranked, by probability and impact. Finally, a plan is
developed to manage those risks with high probability and high impact.
Software
risk always involves two characteristics:
Ø Uncertainty: The risk may or may not
happen. There are no 100% probable risks.
Ø Loss: If
the risk becomes a reality, unwanted consequences or losses will occur.
When
risks are analyzed, it is important to quantify the level of uncertainty and the
degree of loss associated with each risk. To accomplish this, different
categories of risks are considered.
Risk Identification
Risk
identification is a
systematic attempt to specify threats to the project plan (estimates, schedule,
resource loading, etc.). There are two distinct types of risks for each of the
categories that have been presented earlier: generic risks and product-specific
risks.
®
Generic risks are a potential threat to every software project.
® Product-specific risks can be identified only by those with a clear understanding of the technology, the people, and the environment that is specific to the project at hand. To identify product-specific risks, the project plan and the software statement of scope are examined.
One
method for identifying risks is to create a risk item checklist. The checklist can be used for risk
identification and focuses on some subset of known and predictable risks in the
following generic subcategories:
®
Product size: Risks associated with
the overall size of the software to be built or modified.
®
Business impact:
Risks associated with constraints imposed by management or the market place.
®
Customer characteristics: Risks associated with the
sophistication of the customer and the developer's ability to communicate with
the customer in a timely manner.
®
Process definition:
Risks associated with the degree to which the software process has been defined
and is followed by the development organization.
®
Development environment: Risks associated with the
availability and quality of the tools to be used to build the product.
®
Technology to be built: Risks associated with the
complexity of the system to be built and the "newness" of the
technology that is packaged by the system.
Staff size and experience: Risks associated with the overall technical and project experience of the software engineers who will do the work.
0 Comments