1 By the name of the god Risk management Dr. Lo ’ ai Tawalbeh DONE BY: AMNA ISMAIL RASHAN

2 The elements of risk 1) asset is anything within an environment that should be protectedasset 2) Threat: is any potential danger to information, or systems (e.g. fire)

3 The elements of risk 3) Vulnerability: is a software, hardware, or procedural weakness that may provide an attacker the open door to enter a system. 4) Exposure: It means that, if there is a vulnerability and a threat that can exploit it, there is the possibility that a threat event can occur.

4 The elements of risk 5) Risk: is the possibility that any specific threat will exploit a specific vulnerability to cause harm to an asset. risk = threat + vulnerability. 6) safeguard : or countermeasure, is anything that removes a vulnerability or protects against one or more specific threats.  Safeguards and counter-measures are the only means by which risk is mitigated or removed.mitigated

5 Sources of risk A) Internal: * Changes in budget * change of initial requirement * disruption to day to day operation of the organization * key staff leaving * equipment failure. B) External: * Hardware/software not delivered * supplier becomes insolvent * unauthorised access into systems * disruption through power/communication

6 Parts of risk Risk event: the adverse event that results in a risk. Risk probability: the likelihood or uncertainty of a risk to occur. Risk impact: the loss or extent of damage caused by a risk.

7 Types of risk 1. Technical risk 2. Managerial risk 3. Operational risk 4. Environment risk 5. Testing risk

Types of risk 1. Technical risk 2. Managerial risk 3. Operational risk 4. Environment risk 5. Testing risk (1)Do we really know what the problem is? (2) Is the problem solvable?

1. Technical risk 2. Managerial risk 3. Operational risk 4. Environment risk 5. Testing risk * Schedule risk; * Financial risk; * Personnel risk; * Quality risk; Types of risk

1. Technical risk 2. Managerial risk 3. Operational risk 4. Environment risk 5. Testing risk * Inadequate user education or training; * Software Misuse; * Inadequate maintenance of the product. Types of risk

1. Technical risk 2. Managerial risk 3. Operational risk 4. Environment risk 5. Testing risk physical risks that may threaten a particular data center as: Fire, water Types of risk

1. Technical risk 2. Managerial risk 3. Operational risk 4. Environment risk 5. Testing risk The quality control practitioner plays a key role in addressing the testing of risk Types of risk

13 Risk Management is the process of controlling risk and monitoring the effectiveness of the control mechanisms. The goal of RM: is to preserve the quality and integrity of a project by reducing cost escalation and project slippage.

14 Risk management process 1) Identifying the risk; 2) Assessing the risk's magnitude; 3) Determining the response to the risk; 4) Planning for the addressing of, and reporting on, the risk if encountered

15 Risk assessment  The cost potential of the risk's occurrence;  The probability of the risk occurring;  The risk exposure;  The cost to respond to the risk.

16 Risk response 1) Elimination; 2) Avoidance; 3) Mitigation; 4) Acceptance.

17 Risk Analysis the process of identifying, estimating, and evaluating risk.

18 Risk Analysis Benefits of RA Ease of data comprehension. Identification and prioritization of critical activities and functions Identification of areas where policies and procedures need to be enhanced and implemented Justification of cost of implementation of measures Assessment of the preparedness of an organization with respect to the risks. Assessment of the security awareness among employees

19 Risk Analysis 1) Software Risk Analysis 2) Planning Risks and Contingencies The purpose of software risk analysis: to determine what to test, the testing priority, and the depth of testing.

20 Risk Analysis Who Should Do the Analysis? The risk analysis should be done by a team of experts from various groups within the organization include developers, testers, users, customers, marketers, and other interested, willing, and able contributors. When Should It Be Done? A risk analysis should be done as early as possible in the software lifecycle. A first cut at a risk analysis can usually be done as soon as the high-level requirements are known.

21 Software Risk Analysis Process How Should It Be Done Step 1: Form a Brainstorming Team Step 2: Compile a List of Features Step 3: Determine the Likelihood Step 4: Determine the Impact Step 5: Assign Numerical Values Step 6: Compute the Risk Priority Step 7: Review/Modify the Values Step 8: Prioritize the Features Step 9: Determine the "Cut Line“ Step 10: Consider Mitigation

22 Software Risk Analysis Process How Should It Be Done Step 1: Form a Brainstorming Team Include: users (such as business analysts) developers testers marketers customer service representatives support personnel and anyone else that has knowledge of the business and/or product, and is willing and able to participate.

23 Software Risk Analysis Process How Should It Be Done Step 2: Compile a List of Features Compile an inventory of features, attributes, or business functions for the entire system. Global attributes include: Accessibility, availability, compatibility, maintainability, performance, reliability, scalability, security, and usability.

24 Software Risk Analysis Process How Should It Be Done Step 3: Determine the Likelihood Assign an indicator for the relative likelihood of failure.

25 Table 2: Likelihood of Failure for ATM Features/Attributes LikelihoodATM Software AttributesFeatures HighWithdraw cash MediumDeposit cash LowCheck account balance MediumTransfer funds HighPurchase stamps LowMake a loan payment MediumUsability LowPerformance MediumSecurity

26 Software Risk Analysis Process How Should It Be Done Step 4: Determine the Impact What would be the impact on the user if this feature or attribute failed to operate correctly?

Table 3: Impact of Failure for ATM Features/Attributes ImpactLikelihoodATM Software AttributesFeatures High Withdraw cash HighMedium Deposit cash MediumLow Check account balance Medium Transfer funds LowHigh Purchase stamps MediumLow Make a loan payment HighMediumUsability MediumLowPerformance HighMediumSecurity

28 Software Risk Analysis Process How Should It Be Done Step 5: Assign Numerical Values Brainstorming team should assign numerical values for H, M, and L for both likelihood and impact. Usually assign a value of 3 for H, 2 for M, and 1 for L.

29 Software Risk Analysis Process How Should It Be Done Step 6: Compute the Risk Priority The values assigned to the likelihood of failure and the impact of failure should be added together.

30 Table 4: Summed Priorities for ATM Features/Attributes PriorityImpactLikelihoodATM Software AttributesFeatures 6High Withdraw cash 5HighMedium Deposit cash 3MediumLow Check account balance 4Medium Transfer funds 4LowHigh Purchase stamps 3MediumLow Make a loan payment 5HighMediumUsability 3MediumLowPerformance 5HighMediumSecurity

31 Software Risk Analysis Process How Should It Be Done Step 7: Review/Modify the Values Values of the likelihood of failure for each feature may be modified based on additional information or analyses that may be available.

32 Software Risk Analysis Process How Should It Be Done Step 8: Prioritize the Features The brainstorming team should reorganize their list of features and attributes in order of risk priority.

Table 5: Sorted Priorities for ATM Features/Attributes PriorityImpactLikelihoodATM Software AttributesFeatures 6High Withdraw cash 5HighMedium Deposit cash 5HighMediumUsability 5HighMediumSecurity 4Medium Transfer funds 4LowHigh Purchase stamps 3MediumLow Make a loan payment 3MediumLow Check account balance 3MediumLowPerformance

34 Software Risk Analysis Process How Should It Be Done Step 9: Determine the "Cut Line“ To indicate the line below which features will not be tested (if any) or tested less. In order to do that, it's necessary to estimate the amount of testing that is possible with the available time and resources.

35 Table 6 "Cut Line" for ATM Features/Attributes PriorityImpactLikelihoodATM Software AttributesFeatures To Be Tested6High Withdraw cash 5HighMedium Deposit cash 5HighMediumUsability 4Medium Transfer funds 4LowHigh Purchase stamps 4HighLowSecurity Not to Be Tested (or tested less) 3MediumLow Make a loan payment 3MediumLow Check account balance 3MediumLowPerformance

36 Software Risk Analysis Process How Should It Be Done Step 10: Consider Mitigation The mitigation activities may require action by developers, users, testers, or others. Risk mitigation helps reduce the likelihood of a failure, but does not affect the impact.

Table 7: Mitigated List of Priorities for ATM Features/Attributes MitigationPriorityImpactLikelihoodATM Software AttributesFeatures Code inspection6High Withdraw cash Early prototype5HighMedium Deposit cash Early user feedback 5HighMediumUsability 5HighMediumSecurity 4Medium Transfer funds 4LowHigh Purchase stamps 3MediumLow Make a loan payment 3MediumLow Check account balance 3MediumLowPerformance

38 2) Planning Risks and Contingencies Purpose:  To determine the best contingencies in the event that one of the planning risks occurs.  This is important because the scope and nature of a project almost always change as the project progresses.  The planning risks help us to do the "What if … " and develop contingencies.

39