1988

Project
RISK ASSESSMENT & MANAGEMENT

By

STUDENT NAME STUDENT ID

Nisar Ahmad (20169147)

SE512
Managing Software Development
Assoc. Prof. Dr. Kamil Dimiler

FACULTY OF ENGINEERING SOFTWARE DEPARTMENT

NEAR EAST UNIVERSITY
Academic Year
2017/2018 fall
 ACKNOWLEDGEMENT

I would like to present very special thanks to my Assoc. Prof. Dr. Kamil Dimiler who had guide
me since the beginning of Project. Thanks to him for provide guidance, advice, and useful feedback
regarding the semester project either in documentation parts or technical parts. In addition,
guideline and briefing on how to produce a good quality report for this project also provided to
me.
Besides that, my thanks also go to my parents who keep on encouraging me while I facing problem
and when I going to give up. Without their support, I may not be able finish my semester project
on time. Their supports are truly appreciated.

2
 ABSTRACTS
The project is concerned with the risks associated with software development and with the range

of factors that can impact on the quality of the project management process. The management goal

is to mitigate these risks leaving the project plan as unperturbed as possible. To achieve this goal

risk analysis must attempt to identify the high risk elements of the project, provide ways of

documenting the impacts of risk mitigation strategies and review the risks on a continuing basis as

the project proceeds. A model is proposed for such risk analysis and to demonstrate its realization

in a risk management tool.

Risk management's importance to software development is greater now than ever before. The
importance stems from the growing role software plays in delivering value to customers. As we
move to a knowledge economy, software embodies the knowledge that brings value. Software
applications have become larger, more complex, more susceptible to attack and unanticipated
interactions. They are being called on to solve problems for which solutions may not be possible;
either the knowledge doesn't yet exist to solve the problem or a reliable solution doesn't exist

3
 TABLE OF CONTENTS

ACKNOWLEDGEMENT .............................................................................................................. 2

ABSTRACTS ................................................................................................................................. 3

TABLE OF CONTENTS ................................................................................................................ 4

LIST OF FIGURES ........................................................................................................................ 6

1. Introduction ............................................................................................................................. 7

2. Categories of Risk ................................................................................................................... 7

3. Purpose of the Risk Management ........................................................................................... 8

4. The Process of Risk Management........................................................................................... 8

4.1 Risk identification ............................................................................................................ 9

4.2 Risk analysis ................................................................................................................... 10

4.3 Risk planning.................................................................................................................. 11

4.4 Risk monitoring .............................................................................................................. 13

5 Assessing Project Risk .......................................................................................................... 13

6 How is risk managed? ........................................................................................................... 14

7 How can risk management be improved? ............................................................................. 15

8 Why do Risk Management? .................................................................................................. 15

9 How To Do Risk Management ............................................................................................. 16

10 Risk Control Strategies ......................................................................................................... 17

11 Risk Control: Mitigation Plans ............................................................................................. 18

11.1 Risk Controls: Mitigation Strategy ............................................................................. 19

11.2 Choosing Risk control strategy................................................................................... 19

11.3 Risk Handling Decision points ................................................................................... 20

4
 11.4 Risk Control Cycle ..................................................................................................... 20

12 Categories of controls ........................................................................................................... 21

12.1 Control Function ......................................................................................................... 21

12.2 Architectural Layer ..................................................................................................... 21

12.3 Strategy Layer............................................................................................................. 22

12.4 Information Security Principles .................................................................................. 22

13 Feasibility Studies and the Cost Benefit Analysis ................................................................ 22

REFERENCES ............................................................................................................................. 23

5
 LIST OF FIGURES

Fig No Title Page

Figure 1: The process of risk management ..................................................................................... 9

Figure 2: Example of different types of risk ................................................................................. 10

Figure 3: Risk types and example ................................................................................................. 11

Figure 4: Strategies to help manage risk ....................................................................................... 12

Figure 5: Risk indicators ............................................................................................................... 13

Figure 7: Mitigation plans table .................................................................................................... 18

Figure 8: Risk handling decision points........................................................................................ 20

Figure 9: Risk control cycle .......................................................................................................... 20

6
1. Introduction
Risk management is one of the most important jobs for a project manager. Risk management
involves anticipating risks that might affect the project schedule or the quality of the software
being developed, and then taking action to avoid these risks.
 Risk management is the process of identifying vulnerabilities in an organization’s
information systems and taking carefully reasoned steps to assure the confidentiality,
integrity, and availability of all the components in the organization’s information systems
 The primary deliverable from risk assessment was a list of documented vulnerabilities,
ranked by criticality of impact

2. Categories of Risk
1. Project risks: Risk that affect the project schedule or resources. An example of a project risk is
the loss of an experienced designer. Finding a replacement designer with appropriate skills and
experience may take a long time and, consequently, the software design will take longer to
complete.
2. Product risks: Risk that affect the quality or performance of the software being developed. An
example of a product risk is the failure of a purchased component to perform as expected. This
may affect the overall performance of the system so that it is slower than expected.
3. Business risks: Risk that affect the organization developing or procuring the software. For
example, a competitor introducing a new product is a business risk. The introduction of a
competitive product may mean that the assumptions made about sales of existing software products
may be unduly optimistic.

Of course, these risk types overlap. If an experienced programmer leaves a project this can be a
project risk because, even if they are immediately replaced, the schedule will be affected. It
inevitably takes time for a new project member to understand the work that has been done, so they
cannot be immediately productive. Consequently, the delivery of the system may be delayed. The
loss of a team member can also be a product risk because a replacement may not be as experienced
and so could make programming errors. Finally, it can be a business risk because that
programmer’s experience may be crucial in winning new contracts. You should record the results
of the risk analysis in the project plan along with a consequence analysis, which sets out the

7
consequences of the risk for the project, product, and business. Effective risk management makes
it easier to cope with problems and to ensure that these do not lead to unacceptable budget or
schedule slippage.
Risk management is particularly important for software projects because of the inherent
uncertainties that most projects face. These stem from loosely defined requirements, requirements
changes due to changes in customer needs, difficulties in estimating the time and resources
required for software development, and differences in individual skills. You have to anticipate
risks; understand the impact of these risks on the project, the product, and the business; and take
steps to avoid these risks. You may need to draw up contingency plans so that, if the risks do occur,
you can take immediate recovery action.

3. Purpose of the Risk Management

A risk is an event or condition that, if it occurs, could have a positive or negative effect on a
project’s objectives. Risk Management is the process of identifying, assessing, responding to,
monitoring, and reporting risks. This Risk Management Plan defines how risks associated with the
project will be identified, analyzed, and managed. It outlines how risk management activities will
be performed, recorded, and monitored throughout the lifecycle of the project and provides
templates and practices for recording and prioritizing risks.
The Risk Management Plan is created by the project manager in the Planning Phase and is
monitored and updated throughout the project. The intended audience of this document is the
project team, project sponsor and management.

4. The Process of Risk Management

The process of risk management is illustrated in Figure 1. It involves several stages:
1. Risk identification you should identify possible project, product, and business risks.
2. Risk analysis you should assess the likelihood and consequences of these risks.
3. Risk planning you should make plans to address the risk, either by avoiding it or minimizing
its effects on the project.
4. Risk monitoring you should regularly assess the risk and your plans for risk mitigation and
revise these when you learn more about the risk.

8
 Figure 1: The process of risk management

4.1 Risk identification

Risk identification is the first stage of the risk management process. It is concerned with identifying
the risks that could pose a major threat to the software engineering process, the software being
developed, or the development organization. Risk identification may be a team process where a
team get together to brainstorm possible risks. Alternatively, the project manager may simply use
his or her experience to identify the most probable or critical risks. As a starting point for risk
identification, a checklist of different types of risk may be used. There are at least six types of risk
that may be included in a risk checklist:
1. Technology risks that derive from the software or hardware technologies that are used to
develop the system.
2. People risks that are associated with the people in the development team.
3. Organizational risks that derive from the organizational environment where the software is
being developed.
4. Tools risks that derive from the software tools and other support software used to develop the
system.
5. Requirements risks that derive from changes to the customer requirements and the process of
managing the requirements change.
6. Estimation risks that derive from the management estimates of the resources required to build
the system.
Figure 2 gives some examples of possible risks in each of these categories.
When you have finished the risk identification process, you should have a long list of risks that
could occur and which could affect the product, the process, and the business.

9
You then need to prune this list to a manageable size. If you have too many risks, it is practically
impossible to keep track of all of them.
4.2 Risk analysis
During the risk analysis process, you have to consider each identified risk and make a judgment
about the probability and seriousness of that risk. There is no easy way to do this.

Figure 2: Example of different types of risk

1. The probability of the risk might be assessed as very low (_ 10%), low (10–25%), moderate
(25–50%), high (50–75%), or very high (_ 75%).
2. The effects of the risk might be assessed as catastrophic (threaten the survival of the project),
serious (would cause major delays), tolerable (delays are within allowed contingency), or
insignificant.
You should then tabulate the results of this analysis process using a table ordered according to the
seriousness of the risk. Figure 3 illustrates this for the risks that I have identified in Figure 2.
Obviously, the assessment of probability and seriousness is arbitrary here. To make this
assessment, you need detailed information about the project, the process, the development team,
and the organization. Of course, both the probability and the assessment of the effects of a risk
may change as more information about the risk becomes available and as risk management plans

10
are implemented. Therefore, you should update this table during each iteration of the risk process.
Once the risks have been analyzed and ranked, you should assess which of these risks are most
significant. Your judgment must depend on a combination of the probability of the risk arising and
the effects of that risk. In general, catastrophic risks should always be considered, as should all
serious risks that have more than a moderate probability of occurrence.

Figure 3: Risk types and example

4.3 Risk planning

The risk planning process considers each of the key risks that have been identified, and develops
strategies to manage these risks. For each of the risks, you have to think of actions that you might
take to minimize the disruption to the project if the problem identified in the risk occurs. You also
should think about information that you might need to collect while monitoring the project so that
problems can be anticipated.

11
 Figure 4: Strategies to help manage risk

Again, there is no simple process that can be followed for contingency planning. It relies on the
judgment and experience of the project manager. Figure 4 shows possible risk management
strategies that have been identified for the key risks (i.e., those that are serious or intolerable)
shown in Figure 3.
These strategies fall into three categories:
1. Avoidance strategies following these strategies means that the probability that the risk will arise
will be reduced. An example of a risk avoidance strategy is the strategy for dealing with defective
components shown in Figure 4.
2. Minimization strategies following these strategies means that the impact of the risk will be
reduced. An example of a risk minimization strategy is the strategy for staff illness shown in Fig4.
3. Contingency plans following these strategies means that you are prepared for the worst and
have a strategy in place to deal with it. An example of a contingency strategy is the strategy for
organizational financial problems that I have shown in Figure 4.
You can see a clear analogy here with the strategies used in critical systems to from failures.
Obviously, it is best to use a strategy that avoids the risk. If this is not possible, you should use a
strategy that reduces the chances that the risk will have serious effects. Finally, you should have

12
strategies in place to cope with the risk if it arises. These should reduce the overall impact of a risk
on the project or product.
4.4 Risk monitoring
Risk monitoring is the process of checking that your assumptions about the product, process, and
business risks have not changed. You should regularly assess each of the identified risks to decide
whether or not that risk is becoming more or less probable. You should also think about whether
or not the effects of the risk have changed.
To do this, you have to look at other factors, such as the number of requirements change requests,
which give you clues about the risk probability and its effects.
These factors are obviously dependent on the types of risk. Figure 5 gives some examples of factors
that may be helpful in assessing these risk types. You should monitor risks regularly at all stages
in a project. At every management review, you should consider and discuss each of the key risks
separately. You should decide if the risk is more or less likely to arise and if the seriousness and
consequences of the risk have changed.

Figure 5: Risk indicators

5 Assessing Project Risk

The first thing you'll want to do is prepare a Risk Assessment to get a better understanding of the
kinds of risks you’re facing and their possible consequences.
Here's how, step-by-step:

13
Step 1: Identify potential risks. Sit down and create a list of every possible risk and opportunity
you can think of. If you only focus on the threats, you could miss out on the chance to deliver
unexpected value to the customer or client. Ask your team to help you brainstorm during the
project planning process, since they might see possibilities that you don't. Here's a list of 130
project risks to get you started.
Step 2: Determine probability. What are the odds a certain risk will occur? It’s a lot more likely
that a key team member will be out for a week with the flu than develop total amnesia. Rate each
risk with high, medium, or low probability.
Step 3: Determine Impact. What would happen if each risk occurred? Would your final delivery
date get pushed back? Would you go over budget? Identify which risks have the biggest effect on
your project's outcomes, and rate them as high impact. Rate the rest as medium or low impact
risks.

6 How is risk managed?

Risk management is recognized as an integral component of good management and governance.
It is an iterative process consisting of steps, which, when undertaken in sequence, enable continual
improvement in decision making.
Risk management is the term applied to a logical and systematic method of establishing the
context, identifying, analyzing, evaluating, treating, monitoring and communicating risks
associated with any activity, function or process in a way that will enable organizations to
minimize losses and maximize opportunities.
Risk management is as much about identifying opportunities as avoiding or mitigating losses.
The main elements of the risk management process are listed below.
 Establish the context
Establish the context in which the rest of the process will take place
Criteria against which risk will be evaluated should be established and the structure of the analysis
defined
 Identify risks
Identify what, why and how things can arise as the basis for further analysis
 Analyze risks

14
Determine the existing controls and analyses risks in terms of consequence and likelihood in the
context of those controls
 Evaluate risks
Compare estimated levels of risk against the pre-established criteria so risks can be ranked and
management priorities identified
 Treat risks
Low-priority risks should be monitored and reviewed
For higher consequence risks, develop and implement a specific management plan or procedure
that includes consideration of all aspects required to mitigate the risk to an acceptable level
 Monitor and review
Monitor and review the performance of the risk management system and changes that might affect
it
 Communicate and consult
Communicate and consult with internal and external stakeholders as appropriate at each stage of
the risk management process as well as the process as a whole.

7 How can risk management be improved?

 Maintaining effectiveness
To ensure changing circumstances do not alter risk profiles, it is necessary to monitor:
 risks
 the effectiveness of control measures, including
– the risk treatment plan
– strategies
– The management system set up to control implementation.
Few risks remain static. Factors that affect the likelihood and consequences of an outcome can
change, as may the factors that affect the suitability or cost of the various treatment options.
Ongoing review is essential to ensure the risk management treatment plan remains relevant.

8 Why do Risk Management?

The purpose of risk management is to:
 Identify possible risks.

15
  Reduce or allocate risks.
 Provide a rational basis for better decision making in regards to all risks.
 Plan.
Assessing and managing risks is the best weapon you have against project catastrophes. By
evaluating your plan for potential problems and developing strategies to address them, you’ll
improve your chances of a successful, if not perfect, project.

9 How To Do Risk Management

First we need to look at the various sources of risks. There are many sources and this list is not
meant to be inclusive, but rather, a guide for the initial brainstorming of all risks. By referencing
this list, it helps the team determine all possible sources of risk.
Various sources of risk include:
 Project Management
– Top management not recognizing this activity as a project
– Too many projects going on at one time
– Impossible schedule commitments
– No functional input into the planning phase
– No one person responsible for the total project
– Poor control of design changes
– Problems with team members.
– Poor control of customer changes
– Poor understanding of the project manager’s job
– Wrong person assigned as project manager
– No integrated planning and control
– Organization’s resources are overcommitted
– Unrealistic planning and scheduling
– No project cost accounting ability
– Conflicting project priorities
– Poorly organized project office
 External
 Unpredictable

16
 – Unforeseen regulatory requirements
– Natural disasters
– Vandalism, sabotage or unpredicted side effects
 Predictable
– Market or operational risk
– Social
– Environmental
– Inflation
– Currency rate fluctuations
– Media
 Technical
– Technology changes
– Risks stemming from design process
 Legal
– Violating trademarks and licenses
– Sued for breach of contract
– Labor or workplace problem
– Litigation due to tort law
– Legislation
–
10 Risk Control Strategies
Risk control is an important part of risk management. It involves determining what to do with
uncontrolled risks. Some questions to ask when selecting a risk control strategy are, “What is an
acceptable level of risk?” and “What should I do about the risks?” There are four basic strategies
for controlling risks: avoidance, transference, mitigation, and acceptance.
Avoidance – This step involves preventing the exploitation of a vulnerability. This can be
accomplished through applying technical security controls and safeguards that eliminate or reduce
the uncontrolled risk. For example, “system administrators can configure systems to use
passwords where policy requires them and where the administrators are both aware of the
requirement and trained to implement it” (Mattord & Whitman, p.310).

17
 Transference – This step involves shifting the risk to other areas or to outside entities. Some
companies transfer the risk by contracting with an outside company to provide security
expertise. For example, the organization might decide to contract with an ISP to outsource its Web
services. Risk can also be transferred by purchasing insurance. In this case, the insurance
company is responsible for the risk. The organization would be reimbursed if the risk actually
occurred.
Mitigation – This step involves taking a proactive approach to reduce the severity or impact should
an attacker successfully exploit a vulnerability. For example, an organization develops and
implements a disaster recovery plan in the event that a system attack causes disruption to
services. The disaster recovery plan would restore the organization’s IT operations to their former
state.
Acceptance – This step involves understanding the consequences and acknowledging the risk without any attempts
at control or mitigation. Some risks are accepted because they simply cannot be avoided. For example, a company
may decide to move its operations to the midwest part of the country where the market in that area is a perfect fit, yet
tornadoes are more prevalent. A tornado is a risk that cannot be avoided even though you can take necessary
precautions beforehand.

11 Risk Control: Mitigation Plans

Figure 7: Mitigation plans table

18
11.1 Risk Controls: Mitigation Strategy
 Level of threat and value of the play a major role in the selection of strategy
 Following rules of thumb can be applied in selecting the preferred strategy:
 If a vulnerability exist implement assurance techniques to reduce likelihood of its
exploitation.
 If a vulnerability can be exploited with a potential of substantial loss, apply layered
protections (i.e. using different mechanism or technology to keep threats at bay),
architectural designs, and administrative controls to minimize risk or prevent
occurrence.
 If the attacker’s cost is less than the potential gain, apply protections to increase the
attacker’s cost (e.g. security mechanism at the router and end- user levels).

11.2 Choosing Risk control strategy

 Risk control involves:
 Selection one of the four risk control strategies for the vulnerabilities present within
the organization( i.e. acceptance, avoidance, transfer and mitigation)
 Acceptance of risk:
 If the loss is within the range of losses the organization can absorb, or
 If the attacker’s gain is less than expected costs of the attack
 Otherwise, one of the other control strategies will have to be selected.

19
11.3 Risk Handling Decision points

Figure 8: Risk handling decision points

11.4 Risk Control Cycle

Figure 9: Risk control cycle

20
12 Categories of controls
 Controlling risk through avoidance, mitigation, or transference may be accomplished by
implementing controls or safeguards
 One approach to selecting controls is by category:
– Control Function
– Architectural Layer
– Strategy Layer
– Information Security Principles

12.1 Control Function

 Controls or safeguards designed to defend the vulnerability are either preventive or
detective
 Preventive controls stop attempts to exploit vulnerability by implementing enforcement of
an organizational policy or a security principle, such as authentication or confidentiality.
 Detective controls warn of violations of security principles, organizational policies, or
attempts to exploit vulnerabilities.
 Detective controls use techniques such as audit trails, intrusion detection, or configuration
monitoring.

12.2 Architectural Layer

 Some controls apply to one or more layers of an organization’s technical architecture
 Among the architectural layer designators in common use are:
– organizational policy
– external networks
– extranets (or demilitarized zones)
– Intranets (WAN and LAN)
– network devices that interface network zones (switches, routers, firewalls, and hubs)
– systems (computers for mainframe, server or desktop use)
– applications

21
 12.3 Strategy Layer
 Controls are sometimes classified by the risk control strategy they operate within:
– avoidance
– mitigation
– transference

12.4 Information Security Principles

 Controls operate within one or more of the commonly accepted information security
principles:
– Confidentiality
– Integrity
– Availability
– Authentication
– Authorization
– Accountability
– Privacy

13 Feasibility Studies and the Cost Benefit Analysis

Before deciding on the strategy for a specific vulnerability all information about the economic and
non-economic consequences of the vulnerability facing the information asset must be explored.
Fundamentally we are asking, “What are the actual and perceived advantages of implementing a
control contrasted with the actual and perceived disadvantages of implementing the control?”

22
 REFERENCES

Information or article from a website

 www.businessdictionary.com/definition/risk-management.html
 https://ieeexplore.ieee.org/document/896732/
 https://economictimes.indiatimes.com › Definitions › Economy
 https://en.wikipedia.org/wiki/Risk_management

Information from Books

 Software Engineering, 9th Edition [Ian Sommerville]

23