csc 480 software engineering lecture 5 september 3, 2004

17
CSC 480 Software Engineering Lecture 5 September 3, 2004

Upload: blaze-payne

Post on 18-Jan-2016

220 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: CSC 480 Software Engineering Lecture 5 September 3, 2004

CSC 480 Software Engineering

Lecture 5September 3, 2004

Page 2: CSC 480 Software Engineering Lecture 5 September 3, 2004

Topics

PSP2 Project Risk Management PSP3 Project Assignment

Page 3: CSC 480 Software Engineering Lecture 5 September 3, 2004

Risk Management

A risk is a probability that some adverse circumstance will occur. Project risks affect schedule or resources Product risks affect the quality or

performance of the software being developed

Business risks affect the organisation developing or procuring the software

Page 4: CSC 480 Software Engineering Lecture 5 September 3, 2004

Software RisksRisk Risk type DescriptionStaff turnover Project Experienced staff will leave the

project before it is finished.Management change Project There will be a change of

organisational management withdifferent priorities.

Hardware unavailability Project Hardware which is essential for theproject will not be delivered onschedule.

Requirements change Project andproduct

There will be a larger number ofchanges to the requirements thananticipated.

Specification delays Project andproduct

Specifications of essential interfacesare not available on schedule

Size underestimate Project andproduct

The size of the system has beenunderestimated.

CASE tool under-performance

Product CASE tools which support theproject do not perform as anticipated

Technology change Business The underlying technology on whichthe system is built is superseded bynew technology.

Product competition Business A competitive product is marketedbefore the system is completed.

Page 5: CSC 480 Software Engineering Lecture 5 September 3, 2004

Risk Management Process

Risk avoidanceand contingency

plans

Risk planning

Prioritised risklist

Risk analysis

List of potentialrisks

Riskidentification

Riskassessment

Riskmonitoring

Page 6: CSC 480 Software Engineering Lecture 5 September 3, 2004

The Four Risk Activities

Identification

Mindset: try to continually identify risks

Retirement planning

Prioritization

Retirement or mitigation

Page 7: CSC 480 Software Engineering Lecture 5 September 3, 2004

Risk Identification

Technology risks People risks Organisational risks Requirements risks Estimation risks

Page 8: CSC 480 Software Engineering Lecture 5 September 3, 2004

Risks and Risk TypesRisk type Possible risksTechnology The database used in the system cannot process as many

transactions per second as expected.Software components which should be reused contain defectswhich limit their functionality.

People It is impossible to recruit staff with the skills required.Key staff are ill and unavailable at critical times.Required training for staff is not available.

Organisational The organisation is restructured so that different managementare responsible for the project.Organisational financial problems force reductions in the projectbudget.

Tools The code generated by CASE tools is inefficient.CASE tools cannot be integrated.

Requirements Changes to requirements which require major design rework areproposed.Customers fail to understand the impact of requirementschanges.

Estimation The time required to develop the software is underestimated.The rate of defect repair is underestimated.The size of the software is underestimated.

Page 9: CSC 480 Software Engineering Lecture 5 September 3, 2004

Risk Analysis

Assess probability and seriousness of each risk

Probability may be very low, low, moderate, high or very high

Risk effects might be catastrophic, serious, tolerable or insignificant

Page 10: CSC 480 Software Engineering Lecture 5 September 3, 2004

Risk AnalysisRisk Probability EffectsOrganisational financial problems force reductionsin the project budget.

Low Catastrophic

It is impossible to recruit staff with the skillsrequired for the project.

High Catastrophic

Key staff are ill at critical times in the project. Moderate SeriousSoftware components which should be reusedcontain defects which limit their functionality.

Moderate Serious

Changes to requirements which require majordesign rework are proposed.

Moderate Serious

The organisation is restructured so that differentmanagement are responsible for the project.

High Serious

The database used in the system cannot process asmany transactions per second as expected.

Moderate Serious

The time required to develop the software isunderestimated.

High Serious

CASE tools cannot be integrated. High TolerableCustomers fail to understand the impact ofrequirements changes.

Moderate Tolerable

Required training for staff is not available. Moderate TolerableThe rate of defect repair is underestimated. Moderate TolerableThe size of the software is underestimated. High TolerableThe code generated by CASE tools is inefficient. Moderate Insignificant

Page 11: CSC 480 Software Engineering Lecture 5 September 3, 2004

Risk Planning

Consider each risk and develop a strategy to manage that risk

Avoidance strategies Reduce the probability that the risk will arise

Minimisation strategies Reduce the impact of the risk on the project

Contingency plans

Page 12: CSC 480 Software Engineering Lecture 5 September 3, 2004

Projectfinish

Risk Management MindsetProject

start

Identification Retirement

2. “Java skills not high enough.”

1. “May not be possible to superimpose images adequately.”

1. Retirement by conquest: Demonstrate image super- imposition

Risk 1

Risk 2

Risk 1

Projectfinish

Risk 2

2. Retirement by avoidance: Use C++

Projectstart

Page 13: CSC 480 Software Engineering Lecture 5 September 3, 2004

Risk Management StrategiesRisk StrategyOrganisationalfinancial problems

Prepare a briefing document for senior management showinghow the project is making a very important contribution to thegoals of the business.

Recruitmentproblems

Alert customer of potential difficulties and the possibility ofdelays, investigate buying-in components.

Staff illness Reorganise team so that there is more overlap of work andpeople therefore understand each other’s jobs.

Defectivecomponents

Replace potentially defective components with bought-incomponents of known reliability.

Requirementschanges

Derive traceability information to assess requirements changeimpact, maximise information hiding in the design.

Organisationalrestructuring

Prepare a briefing document for senior management showinghow the project is making a very important contribution to thegoals of the business.

Databaseperformance

Investigate the possibility of buying a higher-performancedatabase.

Underestimateddevelopment time

Investigate buying in components, investigate use of a programgenerator.

Page 14: CSC 480 Software Engineering Lecture 5 September 3, 2004

Risk Monitoring

Assess each identified risks regularly to decide whether or not it is becoming less or more probable

Also assess whether the effects of the risk have changed

Each key risk should be discussed at management progress meetings

Page 15: CSC 480 Software Engineering Lecture 5 September 3, 2004

Risk FactorsRisk type Potential indicatorsTechnology Late delivery of hardware or support software, many

reported technology problemsPeople Poor staff morale, poor relationships amongst team

member, job availabilityOrganisational organisational gossip, lack of action by senior

managementTools reluctance by team members to use tools, complaints

about CASE tools, demands for higher-poweredworkstations

Requirements many requirements change requests, customercomplaints

Estimation failure to meet agreed schedule, failure to clearreported defects

Page 16: CSC 480 Software Engineering Lecture 5 September 3, 2004

Risk Sources Ordered by Importance

Lack of top management commitment

Failure to gain user commitment

Misunderstanding of requirements

Inadequate user involvement

Failure to manage end-user expectations

Changing scope and/or objectives

Page 17: CSC 480 Software Engineering Lecture 5 September 3, 2004

 

Likelihood1-10

 1 = least

likely

Impact1-10

 1 = least impact

Retire-ment cost

1-101 = lowest retirement

cost

Priority computation

Resulting priority

 Lowest number handled

first

The highest priority

risk

10(most likely)

10 (most

impact)

1 (lowest

retirement cost)

(11-10)*(11-10)

*1

1

The lowest

priority risk

1 (least likely)

1 (least

impact)

10(highest

retirement cost)

(11-1)*(11-1)

*10

1000

Compute Risk Priorities