Risk Analysis
The
purpose of a risk analysis is to get an idea of how uncertain the
development will be for the complex electronics. Risk relates to what
might happen, how likely it is to occur, and the consequences if that
event does happen. These factors, when considered together, provide a
prioritized set of risks. Usually, only the most severe risks are
directly mitigated. Other risks may be simply watched, or a contingency
plan may be developed.
A risk
analysis for complex electronics should be performed soon after it is
determined that the project will use complex electronics. The initial
risk analysis will likely focus more on project-level issues, such as
requirement uncertainty, available technology, and personnel
experience. The risk analysis should be updated periodically to ensure
that the risk activities (mitigations, monitoring, contingency) are
still adequate and that the risk priorities are still correct. New
risks may be identified, older risk priorities may change, and
mitigations may need to be updated. Ideally, a continuous risk
management approach would be used to ensure that the most relevant
risks to complex electronics at any time are being monitored, tracked,
and mitigated.
Technique
A risk
analysis first considers all the potential problems that may occur with
the requirements. Consider the following items as guidelines when
assessing complex electronics:
- Are the Complex
Electronics (CE) requirements complete, settled, and unambiguous?
If not, what percentage of requirements is still uncertain? Does
the project have a process to handle uncertain or changing
requirements?
- How mature is the
foreseen CE manufacturers and possible technology? Has the
technology, supplier, and/or manufacturer been used by this team
before?
- What is the experience
and familiarity of the engineering resources with the design type,
tools, technology, etc.? Has the project considered the "learning curve" for new tools or technology when
designing the schedule?
- How likely is it that
the design and verification effort has been underestimated? Has
the effort been significantly underestimated?
- Has the debug and repair
efforts, after formalized design and/or manufacturing is complete,
been underestimated? If so, how far is the estimation off from
industry standards? What degree of confidence is there in the
estimation of effort?
- How close are the
requirements to technology limits? For example, is there a risk of
overestimation of actual gate capacity and clocking frequency for
the selected device?
- Is there a risk of
undetermined I/O behavior during power up? Do the requirements
adequately address this possibility?
- Is there a risk of
external failures adversely affecting the complex electronics? Can
internal failures propagate into other parts of the system?
Each
risk is assigned a value for the probability and the impact
(consequences). Usually, the ratings are either a three (low, medium,
high) or a five value quantity. In the following example, the
probability is given the value of 1 (low), 2 (medium), or 3 (high). The
impact is also rated on the same scale. The numbers are multiplied to
give a risk value of 1 through 9, where 1 is a low probability/low
impact risk and 9 is a high probability/high impact risk.
|
Risk Matrix for
Complex Electronics (example)
|
|
|
|
Probability
|
Impact
|
|
|
Risk ID
|
Risk
|
L
|
M
|
H
|
L
|
M
|
H
|
Rating
|
|
1
|
Requirements uncertainty will cause changes in design
and/or rework
|
|
X
|
|
|
|
X
|
6
|
|
2
|
Technology is mature but has not been used by this team,
leading to "learning curve" issues
|
X
|
|
|
|
X
|
|
2
|
|
3
|
Team has problems learning the new technology and tools
|
X
|
|
|
|
X
|
|
2
|
|
4
|
Design and verification efforts are underestimated
|
|
|
X
|
|
|
X
|
9
|
|
5
|
Debug and repair efforts are underestimated
|
X
|
|
|
|
|
X
|
3
|
|
6
|
Requirements may not be able to be implemented in
planned technology
|
X
|
|
|
|
|
X
|
3
|
|
7
|
State of CE
device on power-up may not be deterministic
|
|
X
|
|
|
X
|
|
4
|
|
8
|
External failures may cause the CE device to not
function properly
|
X
|
|
|
|
X
|
|
2
|
|
9
|
Failures in the CE device may propagate to other parts
of the system
|
|
X
|
|
|
X
|
|
4
|
Based on
the matrix presented above, the most critical risk is #4, that the
design and verification efforts are underestimated. Risk #1, that
requirements uncertainty may lead to changes in design or require
rework later in the project, is also an important risk. From this
analysis, the assurance engineer can help the project work to mitigate
the risks in an effective way. The assurance engineer can also monitor
the project’s planning and requirements activities, to ensure that the
risks are not becoming problems.
References:
|
