Software Engineering

Risk Management

II B.Tech IT
Unit – 5

Text Book: Software Engineering, A practitioner’s approach Roger s.

Pressman 6th edition McGraw-Hill

1
UNIT V
 Risk Management:
 Reactive vs. Proactive Risk strategies, software risks, Risk
identification, Risk projection, Risk refinement, RMMM,
RMMM Plan.
 Quality Management: Quality concepts, Software Reviews,
Formal technical reviews, Software reliability, The ISO 9000
quality standards.

November 9, 1997 2
 Introduction
 Risk is uncertainty
 We don’t know whether a particular event will occur or not,
but if it does has a negative impact on a project
 Risk can be defined as a:
 Risk is the “possibility of loss or injury”
 Risk provides an opportunity to develop the project better
 Risk exposure= Size(loss) * Probability of (loss)

 Difference between Risk and Problem

Problem is some event which has already occurred but risk is
something that is unpredictable
4
Risk Strategies
 Proactive risk management is what happens before a risk
becomes a threat.
 Reactive risk management is what happens after a risk
becomes a threat.
 Reactive risk management tries to reduce the damage of
potential threats and speed an organization’s recovery from
them, but assumes that those threats will happen
eventually. Proactive risk management identifies threats and
aims to prevent those events from ever happening in the first
place.

November 9, 1997 7
 Risk Strategies
 Reactive  Proactive
 Software team does nothing  Begins long before technical
about risks until something goes work is initiated
wrong  Identification of potential risks
 “fire fighting mode” (studies of probability, impact
and priorities)
 Objective: AVOID RISK
 Responds are in a controlled
 At best, monitors the projects
and effective manner
for likely risks
 Majority of the software teams
and managers rely on this
approach
Our Concern

8
9
 Risk Categorization

• Project Risks (budgetary, schedule, personnel, resource, customer)

• Technical Risks (design, implementation, interfacing, verification)
Software • Business Risks (market, strategic, management, budget)
Risk
• Known risks (Ex: unrealistic delivery date)
• Predictable risks (Ex: Past turnover)
• Unpredictable risks

10
Risk Identification
 Risk identification is a systematic attempt to specify threats to
the project plan

Identify known and predictable risks

Generic Product-specific
 Product size
 Business impact
 Customer characteristics What characteristics of
this product may threaten
 Process definition our project plan?
 Development environment
 Technology to be built
 Risk Item List  Staff size and experience

11
Risk Identification
 Product Size Risk :
 Estimated size of the product in LOC or FP?
 Percentage deviation in size of product from average for
previous products?
 Number of users/projected changes to the requirements
for the product?
 Amount of reused software?
 Business Impact risks:
 Effect of this product on the company revenue?
 Visibility of this product to senior management?
 Amount & quality of product documentation to be produced?
 Governmental constraints on the construction of the product?

12
Risk Identification
 Customer related risks: (needs, personalities, contradictions,
associations)
 Have you worked with the customer in the past?
 Does the customer have a solid idea of what is required?
 Will the customer agree to have meetings?
 Is the customer technically sophisticated in the product area?
 Does the customer understand the software process?
 Technology Risks:
 Is the technology to be built new to your organization?
 Does the SW interface with new or unproven HW/SW?
 Do requirements demand creation of new components ?
 Do requirements impose excessive performance constraints ?
13
 Risk Identification
 Process Risks :
 Does senior management support a written policy statement that emphasizes a
standard process for software development ?
 Is there a written description of the software process to be used?
Process  Is the software process used for other projects ?
Issues:  Is configuration management used to maintain consistency among
system/software requirements, design, code and test?
 Is a procedure followed for tracking subcontractor performance?

 Are facilitated application specification techniques used to aid in
communication between the customer and developer ?
Tech- 
Are specific methods used for software analysis?
nical
Issues:
 Do you use specific method for data and architectural design?
 Are software tools used to support the software analysis and design?
 Are tools used to create software prototypes?
 Are quality/productivity metrics collected for all software projects?
14
Risk Identification
 Development Environment Risks:
 Is a software project/process management tool available?
 Are tools for analysis and design available?
 Are testing tools available and appropriate for the product?
 Are all SW tools integrated with one another?
 Have members of the project team received training in
each of the tools?

 Risk Associated with Staff Size and Experience:

 Are the best people available?
 Do the people have the right combination of skills?
 Are staff committed for entire duration of the project?
 Do staff have the right expectations about the job at hand?
 Will turnover among staff be low enough to allow continuity15 ?
Risk Identification
 Risk Components and Drivers
 Performance risk: the degree of uncertainty that the
product will meet its requirements and be fit for its
intended use
 Cost risk: the degree of uncertainty that the project budget
will be maintained
 Support risk:the degree of uncertainty that the software
will be easy to correct, adapt and enhance
 Schedule risk: the degree of uncertainty that the project
schedule will be maintained

16
Risk Projection
 Also called risk estimation, attempts to rate each risk in two
ways:
 Likelihood (probability)
 Consequences
 Develop a risk table: A risk table provides a project
manager with a simple technique for risk projection
 For each identified risk, list likelihood, consequence
and impact
 Risk Assessment: Examine the accuracy of the
estimates that were made during risk projection. A risk
referent level must be defined and the referent point or
break point should be established
18
19
 Risk Projection
Risks Category Probability Impact RMMM
Size estimate may be significantly low PS 60% 2
Larger number of users than planned PS 30% 3
Less reuse than planned PS 70% 2
End users resist system BU 40% 3
Delivery deadline will be tightened BU 50% 2
Funding will be lost CU 40% 1
Customer will change requirements PS 80% 2
Technology will not meet expectations TE 30% 1
Lack of training on tools DE 80% 2
Staff inexperienced ST 30% 2
Staff turnover will be high ST 60% 2
.
.
.
PS: Product Size , BU: business risk , CU: Customer characteristics , PS: Process definition ,
DE: Development environment , TE: Technology to be built ,ST: Staff size and experience.

Impact values: 1—catastrophic, 2—critical , 3—marginal , 4—negligible 20

Risk Mitigation, Monitoring and
Management (RMMM)
 A risk management technique is usually seen in the software
Project plan. This can be divided into Risk Mitigation,
Monitoring, and Management Plan (RMMM).
 Risk Mitigation : 
It is an activity used to avoid problems (Risk Avoidance). 
Steps for mitigating the risks as follows. 
 Finding out the risk. 
 Removing causes that are the reason for risk creation. 
 Controlling the corresponding documents from time to time. 
 Conducting timely reviews to speed up the work.

21
 Risk Monitoring : 
It is an activity used for project tracking. 
It has the following primary objectives as follows. 
 To check if predicted risks occur or not. 
 To ensure proper application of risk aversion steps defined for
risk. 
 To collect data for future risk analysis. 
 To allocate what problems are caused by which risks throughout
the project.
 Risk Management:
 Risk management and contingency planning assumes that
mitigation efforts have failed and that the risk has become a
reality.

November 9, 1997 22
 Risk Mitigation, Monitoring and
Management (RMMM)
 An effective strategy must consider three issues:
 Risk Mitigation / Avoidance
 Risk Monitoring and
 Risk Management and Contingency planning.
 A proactive approach to risk avoidance is the best strategy.
Develop a plan for risk mitigation. For example: assume that
high staff turnover is noted as a project risk r1, some of the
possible steps to be taken are these:
 meet with current staff to determine causes for turnover
 assume turnover will occur and develop techniques to
ensure continuity when people leave.
 define a backup staff member for every critical
technologies. 23
Risk Mitigation, Monitoring and
Management
 As the project proceeds, the following factors can be
monitored:
 general attitude of team members based on project
pressures
 the degree to which the team has come together
 interpersonal relationship among team members
 availability of jobs within the company and outside it
 In addition of these factors, the project manager should
monitor the effectiveness of risk mitigation steps.
 Risk management and contingency planning assumes that
mitigation efforts have failed and that the risk has become
reality.
24
 Safety Risks and Hazards
 Software safety and hazard analysis are software quality
assurance activities that focus on the identification and
assessment of potential hazard that may impact software
negatively and cause an entire system to fail.

 If hazards can be identified early in the software

engineering process, software design features can be
specified that will either eliminate or control
potential hazards.

25
November 9, 1997 28
Software Development Risk

30
Summary
 Risk analysis is an important part of most software projects.
 Risk analysis requires a significant amount of project
planning effort.
 Understanding risk helps you know where to commit your
resources.
 If you don’t actively attack the risks, they will actively
attack you.
 Major projects should all have a risk management plan..

31