Software Quality Engineering (SQE)

Final Exam Study Notes

Lecture: Risk Management & Hazard Analysis
Prepared by: Humais Ali | UET Mardan, Dept. of CSE | 6th Semester

1. Introduction to Risk Management

Risk management is a systematic process used in software engineering to identify,
analyze, and control potential threats to a project's success. It answers four
fundamental questions:

Core Question Explanation

What can go wrong? Identify all possible risks before they happen
What is the likelihood? Estimate the probability of each risk occurring
What will the damage be? Assess the impact if the risk becomes real
What can we do about it? Plan mitigation, monitoring, and contingency
strategies

Source: Pressman, R. Software Engineering: A Practitioner's Approach. McGraw-Hill,

2005.

2. Core Definitions
2.1 What is a Software Risk?
A risk is a potential problem that might or might not happen. It involves two key
dimensions:
• Probability of occurrence – How likely is it that the problem will arise?

SQE Final Exam Notes | Risk Management & Hazard Analysis | Page 1
 • Severity of consequences – How much damage will it cause if it does occur?

Key characteristics of risk:

• Uncertainty: A risk may or may not occur. Events that are 100% certain are
called constraints, not risks.
• Loss: If a risk becomes real, it leads to unwanted consequences such as
increased cost, schedule delays, or poor software quality.

Example: There is a 20% chance that the newly developed payment module may fail
under peak load, potentially causing system downtime and financial loss.

2.2 What is a Hazard?

A hazard is a potential source of harm or adverse effect in a software system. It
represents a condition or vulnerability that could lead to a problem, regardless of
whether it actually occurs.
• Hazards are inherent in the system or its environment.
• They describe what might go wrong structurally or technically.

Example: A buffer overflow vulnerability in a software module is a hazard because it

could potentially be exploited to crash the system or leak sensitive data.

Risk vs. Hazard at a glance:

Term Meaning
Risk A potential problem with a certain probability and
impact (future event)
Hazard A condition or vulnerability already present in the
system (current state)

3. Types of Software Risks

Software risk exists because the future is uncertain. Risks can be classified in two major
ways.

3.1 Classification by Control (Approach #1 – Internal vs. External)

Type Description
Internal Risks Risks within the control of the project manager.

SQE Final Exam Notes | Risk Management & Hazard Analysis | Page 2
 Example: poor planning, inadequate staffing.
External Risks Risks beyond the control of the project manager.
Example: market changes, regulatory issues.

3.2 Classification by Nature (Approach #2 – Project, Technical,

Business)

Risk Type What it Threatens Example

Project Risks Threaten the project plan Example: key developer
(schedule & budget) leaves the team
Technical Risks Threaten quality & Example: a new algorithm
timeliness of the software doesn't scale
Business Risks Threaten the viability of Example: no market
the product itself demand for the software

Sub-categories of Business Risks

• Market Risk: Building a great product nobody wants.
• Strategic Risk: Product no longer fits the company's overall strategy.
• Sales Risk: Sales team doesn't know how to sell the product.
• Management Risk: Loss of senior management support.
• Budget Risk: Loss of budget or personnel commitment.

3.3 Classification by Predictability (Approach #3)

Category Description
Known Risks Uncovered after careful evaluation of the project
plan and environment. Example: unrealistic delivery
date.
Predictable Risks Extrapolated from past project experience. Example:
high staff turnover based on history.
Unpredictable Risks Can occur but are extremely difficult to identify in
advance. Example: sudden regulatory changes.

SQE Final Exam Notes | Risk Management & Hazard Analysis | Page 3
4. Risk Management
4.1 Goals of Risk Management
Risk management is carried out to achieve four goals:
1. Identify the risk
2. Reduce the probability or likelihood of risk
3. Reduce the impact of risk
4. Monitor the risk throughout the project lifecycle

4.2 Reactive vs. Proactive Risk Strategies

Strategy Description
Reactive Strategy Do nothing until a problem occurs, then react ("fire
fighting"). Crisis management is the default
technique. Most software teams use this approach.
Proactive Strategy Systematically follow risk management steps before
problems arise. Primary goal: avoid risks and have
contingency plans ready for unavoidable ones.

4.3 Steps for Risk Management (Proactive Approach)

5. Identify possible risks – Recognize what can go wrong.
6. Analyze each risk – Estimate the probability of occurrence and its impact if it
does occur.
7. Rank the risks – Sort by probability and impact. Impact levels: Negligible,
Marginal, Critical, Catastrophic.
8. Develop a contingency plan – For risks with high probability AND high impact,
prepare a plan to handle them.

5. Risk Identification
5.1 Overview
Risk identification is a systematic attempt to specify threats to the project plan. There
are two types of risks to identify:
• Generic Risks: Potential threats to every software project.
• Product-Specific Risks: Identified only by those who understand the technology,
people, and environment of the specific project.

SQE Final Exam Notes | Risk Management & Hazard Analysis | Page 4
5.2 Seven Known Risk Categories (Risk Item Checklist)
Risk Category Description
1. Product Size Risks from overall size of the software being built.
2. Business Impact Risks from constraints imposed by management or
the marketplace.
3. Customer Characteristics Risks related to customer sophistication and
communication ability.
4. Process Definition Risks from how well the software process is defined
and followed.
5. Development Environment Risks from availability and quality of tools used to
build the project.
6. Technology to be Built Risks from system complexity and use of
new/unfamiliar technology.
7. Staff Size and Experience Risks from overall technical and project experience
of the team.

5.3 Risk Components and Drivers

The project manager identifies risk drivers that affect four key risk components:

Risk Component Meaning

Performance Risk Uncertainty that the product will meet its
requirements and be fit for use.
Cost Risk Uncertainty that the project budget will be
maintained.
Support Risk Uncertainty that the software will be easy to correct,
adapt, and enhance.
Schedule Risk Uncertainty that the project schedule will be
maintained and the product delivered on time.

Impact of each risk driver is assessed at one of four levels:

• Negligible – minimal or no impact
• Marginal – minor impact, manageable
• Critical – significant impact, threatens project success
• Catastrophic – project failure or severe damage

SQE Final Exam Notes | Risk Management & Hazard Analysis | Page 5
Risk driver occurrence is assessed as: Impossible, Improbable, Probable, or Frequent.

5.4 Recording Risk Information

Each identified risk should be documented with the following fields:
• Project and risk type
• Priority (1 = low to 5 = critical)
• Risk factor description
• Probability percentage
• Impact description
• Monitoring approach
• Contingency plan and estimated resources

6. Risk Projection (Estimation)

6.1 Overview
Risk projection (also called risk estimation) rates each identified risk in two ways: the
probability that it is real, and the consequence if it actually occurs. The goal is
prioritization so resources are allocated effectively.

6.2 Risk Projection Steps

9. Establish a scale for likelihood – e.g., 1 (low) to 10 (high).
10. Delineate the consequences of the risk – what exactly would happen.
11. Estimate the impact on the project and product – using the four risk components.
12. Note the accuracy of the projection – to avoid misunderstandings and over-
confidence.

6.3 The Risk Table

A risk table is a simple technique for risk projection. It has five columns:
Column Description
Risk Summary Short description of the risk
Risk Category One of the seven risk categories (Product Size,
Business Impact, etc.)
Probability Estimated likelihood of the risk occurring
Impact (1) Catastrophic (2) Critical (3) Marginal (4)
Negligible

SQE Final Exam Notes | Risk Management & Hazard Analysis | Page 6
 RMMM Pointer to the Risk Mitigation, Monitoring, and
Management Plan

Building the risk table:

13. List all risks in the first column using checklists.
14. Mark the category of each risk.
15. Estimate the probability of each risk.
16. Assess the impact by averaging across the four risk components.
17. Sort rows by probability and impact in descending order.
18. Draw a cutoff line to separate risks that need further attention from those that do
not.

6.4 Risk Exposure (RE) Formula

Risk Exposure measures the overall danger of a risk:
RE = P x C
Variable Meaning
P Probability of occurrence for the risk
C Cost to the project if the risk actually occurs
RE Risk Exposure (combined measure of danger)

Example: There is an 80% probability that 18 of 60 software components must be re-

developed. The cost to develop those 18 components is $25,000. Therefore, RE = 0.80
x $25,000 = $20,000.

6.5 Three Factors that Affect Risk Consequences

• Nature – What problems are likely if the risk occurs?
• Scope – Severity (how serious?) combined with distribution (how widely is the
project affected?).
• Timing – When and for how long will the impact be felt?

SQE Final Exam Notes | Risk Management & Hazard Analysis | Page 7
7. Risk Mitigation, Monitoring, and Management
(RMMM)
7.1 Overview
An effective risk strategy must address three issues (not mutually exclusive):
• Risk Mitigation (Avoidance): Eliminate or reduce the risk before it occurs.
• Risk Monitoring: Track indicators that show whether a risk is becoming more or
less likely.
• Risk Management & Contingency Planning: Handle the risk when mitigation has
failed.

7.2 Risk Mitigation (Avoidance)

Risk mitigation is the primary strategy and is achieved through a proactive plan.
Example — Strategy to Reduce High Staff Turnover:
19. Meet with current staff to determine causes of turnover (low pay, poor conditions,
competitive market).
20. Mitigate controllable causes before the project begins.
21. Assume turnover will occur — develop continuity techniques.
22. Organize teams so that knowledge is widely dispersed, not held by one person.
23. Define documentation standards and ensure timely document development.
24. Conduct peer reviews of all work so multiple people stay up to speed.
25. Assign a backup staff member for every critical technologist.

7.3 Risk Monitoring

During risk monitoring, the project manager tracks factors that indicate whether a risk is
becoming more or less likely. This is a continuous project tracking activity.

Three objectives of risk monitoring:

• Assess whether predicted risks actually occur.
• Ensure that risk aversion steps are being properly applied.
• Collect information usable for future risk analysis.

7.4 Risk Management and Contingency Planning

Risk management assumes that mitigation efforts have failed and that the risk has
become a reality. The team must then execute the pre-defined contingency plan.
• RMMM steps incur additional project cost.
• Large projects may have 30–40 identified risks.

SQE Final Exam Notes | Risk Management & Hazard Analysis | Page 8
 • Risk is not limited to the project phase — risks can occur after delivery.

7.5 Software Safety and Hazard Analysis

Software safety and hazard analysis are SQA activities that focus on identification and
assessment of potential hazards that may negatively affect software and cause system
failure.
• If hazards are identified early, design features can be specified to eliminate or
control them.
• This is part of proactive risk management embedded into the software process.

7.6 The RMMM Plan

The RMMM Plan may be part of the Software Development Plan or a separate
document. It documents the mitigation, monitoring, and management steps for every
identified risk.

8. Seven Principles of Risk Management

Principle Explanation
1. Maintain a Global View software risks within the context of the overall
Perspective system and the business problem it is meant to
solve.
2. Take a Forward-Looking Think about risks that may arise in the future and
View establish contingency plans.
3. Encourage Open Encourage all stakeholders and users to point out
Communication risks at any time without fear.
4. Integrate Risk Management Integrate risk consideration into every phase of the
software process.
5. Emphasize Continuous Continuously modify identified risks as more
Process becomes known; add new risks as better insight is
achieved.
6. Develop a Shared Product A shared vision by all stakeholders leads to better
Vision risk identification and assessment.
7. Encourage Teamwork Pool the skills and experience of all stakeholders
when conducting risk management activities.

SQE Final Exam Notes | Risk Management & Hazard Analysis | Page 9
9. Risk Identification Questionnaire
This questionnaire helps assess project risk. Questions are ordered by relative
importance to project success:

26. Have top software and customer managers formally committed to support the
project?
27. Are end-users enthusiastically committed to the project and the system/product
to be built?
28. Are requirements fully understood by both the software engineering team and its
customers?
29. Have customers been fully involved in the definition of requirements?
30. Do end-users have realistic expectations?
31. Is the project scope stable?
32. Does the software engineering team have the right mix of skills?
33. Are project requirements stable?
34. Does the project team have experience with the technology to be implemented?
35. Is the number of people on the project team adequate to do the job?
36. Do all customer/user groups agree on the importance of the project and on the
requirements?

10. Summary
Key takeaways from this lecture:
• Risk management is critical for any serious software project but is often done
informally or not at all.
• Risk = Probability of Occurrence x Impact (Consequences).
• Hazard = A condition or vulnerability already present that could lead to a risk
event.
• Three categories of risk: Project, Technical, and Business.
• Three predictability levels: Known, Predictable, Unpredictable.
• The proactive strategy (identify, analyze, rank, plan) is far superior to reactive
fire-fighting.
• Risk Exposure Formula: RE = P x C
• RMMM covers Mitigation, Monitoring, and Management/Contingency Planning.
• Risk management effort is always worth it — it leads to less upheaval, better
control, and greater confidence.

End of Notes — Good Luck on Your Final Exam!

SQE Final Exam Notes | Risk Management & Hazard Analysis | Page 10