0% found this document useful (0 votes)
12 views

Risk Management

The document discusses software risk management, including defining risk, risk management activities, and classifications of risks like project risks, technical risks, and business risks. It also covers risk assessment, identification, and analysis activities and principles of risk management.

Uploaded by

k79aushik7540
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
12 views

Risk Management

The document discusses software risk management, including defining risk, risk management activities, and classifications of risks like project risks, technical risks, and business risks. It also covers risk assessment, identification, and analysis activities and principles of risk management.

Uploaded by

k79aushik7540
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 16

Software Risk Management

Risk
• Risk is a problem that could cause some loss or threaten the progress
of the project, but which has not happened yet.
• Might harm cost, schedule or technical success of the project and the
quality of our software device, or project team morale.
Risk Management
• Risk Management is the system of identifying addressing and
eliminating these problems before they can damage the project.
• We need to differentiate risks, as potential issues, from the current
problems of the project.
• Different methods are required to address these two kinds of issues.
• There are three main classifications of risks which can affect a
software project:
• Project risks
• Technical risks
• Business risks
• Project risks: Project risks concern differ forms of budgetary,
schedule, personnel, resource, and customer-related problems. A vital
project risk is schedule slippage. Since the software is intangible, it is
very tough to monitor and control a software project. It is very tough
to control something which cannot be identified. For any
manufacturing program, such as the manufacturing of cars, the plan
executive can recognize the product taking shape.
• Technical risks: Technical risks concern potential method,
implementation, interfacing, testing, and maintenance issue. It also
consists of an ambiguous specification, incomplete specification,
changing specification, technical uncertainty, and technical
obsolescence. Most technical risks appear due to the development
team's insufficient knowledge about the project.
• Business risks: This type of risks contain risks of building an excellent
product that no one need, losing budgetary or personnel
commitments, etc.
Other Risk Categories
• 1. Known risks: Those risks that can be uncovered after careful
assessment of the project program, the business and technical
environment in which the plan is being developed, and more reliable
data sources (e.g., unrealistic delivery date)
• 2. Predictable risks: Those risks that are hypothesized from previous
project experience (e.g., past turnover)
• 3. Unpredictable risks: Those risks that can and do occur, but are
extremely tough to identify in advance.
Principle of Risk Management

• Global Perspective: In this, we review the bigger system description, design, and
implementation. We look at the chance and the impact the risk is going to have.
• Take a forward-looking view: Consider the threat which may appear in the
future and create future plans for directing the next events.
• Open Communication: This is to allow the free flow of communications
between the client and the team members so that they have certainty about the
risks.
• Integrated management: In this method risk management is made an integral
part of project management.
• Continuous process: In this phase, the risks are tracked continuously throughout
the risk management paradigm.
Risk Management Activities
Risk Assessment

• The objective of risk assessment is to division the risks in the


condition of their loss, causing potential. For risk assessment, first,
every risk should be rated in two methods:
• The possibility of a risk coming true (denoted as r).
• The consequence of the issues relates to that risk (denoted as s).
• Based on these two methods, the priority of each risk can be
estimated:
• p=r*s
Contd.
• Where p is the priority with which the risk must be controlled, r is the
probability of the risk becoming true, and s is the severity of loss
caused due to the risk becoming true. If all identified risks are set up,
then the most likely and damaging risks can be controlled first, and
more comprehensive risk abatement methods can be designed for
these risks.
• 1. Risk Identification: The project organizer needs to anticipate the
risk in the project as early as possible so that the impact of risk can be
reduced by making effective risk management planning.
• A project can be of use by a large variety of risk. To identify the
significant risk, this might affect a project. It is necessary to categories
into the different risk of classes.
Contd.
• There are different types of risks which can affect a software project:
• Technology risks: Risks that assume from the software or hardware technologies that
are used to develop the system.
• People risks: Risks that are connected with the person in the development team.
• Organizational risks: Risks that assume from the organizational environment where
the software is being developed.
• Tools risks: Risks that assume from the software tools and other support software
used to create the system.
• Requirement risks: Risks that assume from the changes to the customer requirement
and the process of managing the requirements change.
• Estimation risks: Risks that assume from the management estimates of the resources
required to build the system
• Risk Analysis: During the risk analysis process, you have to consider
every identified risk and make a perception of the probability and
seriousness of that risk.
• There is no simple way to do this. You have to rely on your perception
and experience of previous projects and the problems that arise in
them.
Contd.
• It is not possible to make an exact, the numerical estimate of the
probability and seriousness of each risk. Instead, you should authorize
the risk to one of several bands:
• The probability of the risk might be determined as very low (0-10%), low (10-
25%), moderate (25-50%), high (50-75%) or very high (+75%).
• The effect of the risk might be determined as catastrophic (threaten the
survival of the plan), serious (would cause significant delays), tolerable (delays
are within allowed contingency), or insignificant.

You might also like