1. Object-Oriented Software Engineering
Risk Management
Object-Oriented Software Engineering

2. 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

3. 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.

4. 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.

5. 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

6. 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

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

8. 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

9. 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

10. 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

11. 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

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

13. 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

14. 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

15. 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.

16. 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

17. 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

18. 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)

19. 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.

20. 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

21. 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.