Object-Oriented Software Engineering Risk Management Object-Oriented Software Engineering

The Concept of Risk A risk is defined as a variable that can take a value that endangers or eliminates success for a project. In plain terms, a risk is whatever may stand in our way to success and is currently unknown or uncertain. We can qualify risks further as direct or indirect: Direct risk: The project has a large degree of control Indirect risk: The project has little or no control

Risk Attributes We can also add two important attributes: The probability of occurrence The impact on the project (severity) These two attributes can be combined in a single risk magnitude indicator, and five discrete values are sufficient: High, Significant, Moderate, Minor, Low.

How to Cope with Risks Three main routes are possible: Risk avoidance: Reorganize project so that it cannot be affected by the risk. Risk transfer: Reorganize project so that someone or something else bears the risk (the customer, vendor, bank, or another element). Risk acceptance: Decide to live with the risk. Monitor its symptoms and determine what to do if it materializes.

Types of Risks Risks that can be avoided or worked around Risks that cannot be avoided “What if the project leader in this 15-person team leaves the company?” Retire this by preparing a backup person. From: Software Engineering An Object-Oriented Perspective By: Eric J. Braude

A Way to Compute Risk Priorities Likelihood 1 to 10 Impact Retirement Cost Priority Computation Resulting priority (1=least likely) (1=least impact) (1=lowest cost) (Lowest number handled first) Highest Risk 10 1 (11-10) x (11-10) x 1 Lowest Risk (11-1) x (11-1) x 10 1000 From: Software Engineering An Object-Oriented Perspective By: Eric J. Braude

From Software Engineering R7 By Sommerville Risk Management From Software Engineering R7 By Sommerville

Important Goals for Project Management Deliver the software to customer at the agreed time Keep overall costs within budget Deliver software that meets customer’s expectations Maintain a happy and well-functioning development team

Software Characteristics Product is intangible Software project managers cannot see progress by looking at the artifact that is being constructed. They rely on others to produce evidence that they can use to review the progress Large software projects are often ‘one-off’ projects Large software projects are usually different in some ways from previous projects Software processes are variable and organization-specific Engineering process for bridges and buildings is well understood Software processes vary from one organization to another

Software Project Manager’s Responsibility Project planning Planning, estimating and scheduling project development, and assigning people to tasks Reporting Reporting on progress of a project to customers and managers of the company Risk management Assessing and monitoring risks, and taking action when they arise People management Managing a team of people Proposal writing Writing a proposal to win a contract

Risk Category Risks may be categorized into: Project Risks Risks that affect project schedule or resources: the loss of an experienced designer. Product Risks Risks that affect quality or performance of the software: failure of a purchased component to perform as expected Business Risk Risks that affect organization developing or procuring software: a competitor introducing a new product

Risk Management Process Identification Risk Analysis Risk Planning Risk Monitoring List of Potential Risks Prioritized Risk List Risk Avoidance And Contingency Plans Risk Assessment

Risk Management Process Risk identification Identify possible project, product, and business risks Risk analysis Assess the likelihood and consequences of these risks Risk planning Make plans to address the risk by avoiding it or minimizing its effects on the project Risk monitoring Assess risk and plans for risk mitigation and revise these when we learn more about the risk

Risk Identification (Risk Types) Technology risks Derive from software or hardware technologies that are used to develop system People risks Associated with people in the development team Organizational risks Derive from organizational environment Tools risks Derive from software tools and other support tools used to develop Requirement risks Derive from changes to customer requirements and process of managing the requirements changes Estimation risks Derive from management estimates of resources required to build

Risks and Risk Types (Risk Identification) Possible Risks Technology Database used cannot process as many transactions per second as expected. Reused SW components contain defects which limit their functionality. People It is impossible to recruit staff with skills required. Key staff are ill and unavailable at critical times. Required training for staff is not available. Organizational Organization is restructured so that different managements are possible for the project. Organizational financial problems force reductions in project budget. Tools The code generated by CASE tools is inefficient. CASE tools cannot be integrated. Requirements Changes to requirements which require major design rework are proposed. Customers fail to understand the impact of requirements changes. Estimation The time required to developed SW is underestimated. The rate of defect repair is underestimated. The size of the software is underestimated.

Risks Analysis Probability of the risk might be assessed as: Very low ( <10% ) Low ( 10-25% ) Moderate ( 25-50% ) High ( 50-75% ) Very high ( >75% ) Effects of risk might be assessed as: Catastrophic (threaten the survival of project) Serious (would cause major delays) Tolerable (delays and within allowed contingency) Insignificant

Risks Analysis Risk Probability Effects Financial problems force reductions in project budget. Low Catastrophic It is impossible to recruit staff with skills required for the project. High Key staff are ill at critical times in the project Moderate Serious Customers fail to understand the impact of requirements changes. Tolerable The code generated by CASE tools is inefficient. Insignificant

Risk Planning (Strategies) Avoidance strategies Probability that risk will arise will be reduced i.e. Defective components (see next slide) Minimization strategies Impact of the risk will be reduced i.e. Staff illness (see next slide) Contingency plans We are prepared for the worst and have strategy in place to deal with it. i.e. Organizational financial problem (see next slide)

Risks Management Strategies Strategy Organizational financial problem Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of business. Recruitment problems Alert customer of potential difficulties an possibility of delays, investigate buying-in components Staff illness Reorganize team so that there is more overlap of work and people therefore understand each other’s jobs Defective components Replace potentially defective components with bought-in components of know reliability Requirements changes Derive traceability information to assess requirements change impact, maximize information hiding in the design. Database performance Investigate the possibility of buying a higher-performance database.

Risk Monitoring Checking that our assumptions about the product, process, and business risks have not changed Regularly assess each of the identified risks to decide whether or not that risk is becoming more or less problem Think about whether or not the effects of the risk have changed Look at other factors, such as the number of requirements change requests

Risk Factors Risk Type Potential indicators Technology People Late delivery of hardware of support SW, many reported technology problems. People Poor staff morale, poor relationships amongst team members, job availability. Organizational Organizational gossip, lack of action by senior management. Tools Reluctance by team members to use tools, complaints about CASE tools, demands for higher-powered workstations. Requirements Many requirements change requests, customer complaints. Estimation Failure to meet agreed schedule, failure to clear reported defects.