Software Engineering Lecture 6: Risk Analysis & Management.

Slides:



Advertisements
Similar presentations
Risk Analysis and Management M Taimoor Khan
Advertisements

Project Management.
Risk Management Planning for Problems. Characteristics of Risk Risk has two principle characteristics Uncertainty – It may or may not happen Loss – If.
Issue Tracking John D. McGregor Module 10 Session 1 Issue Tracking and Risk.
Chapter 7: Managing Risk
Projmgmt-1/33 DePaul University Project Management I - Risk Management Instructor: David A. Lash.
Risk Analysis and Management
Computer Engineering 203 R Smith Risk Management 7/ Risk Management The future can never be predicted with 100% accuracy. Failure to plan for risks.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 Chapter 6 Risk Management. 2 Project Risks What can go wrong? What is the likelihood? What will the damage be? What can we do about it?
SE is not like other projects. l The project is intangible. l There is no standardized solution process. l New projects may have little or no relationship.
Types of Risks 1.Project risks –Impact schedule and cost –Includes budgetary, schedule, personnel, resource, customer, requirement problems 2.Technical.
Risk Management CS 414, Software Engineering I Mark Ardis, Rose-Hulman Institute January 28, 2003.
CIS 375 Bruce R. Maxim UM-Dearborn
8 Managing Risk Teaching Strategies
Risk Management. What is risk? You have some expected outcome –Of some event in the future Risk is the deviation of the actual future outcome from the.
Chapter 25 Risk Management
Software Project Management
Chapter 25 Risk Management
1 RISK ANALYSIS AND MANAGEMENT By Hüseyin Gürsev 2005.
Software Engineering Risk Management. Steps in Project Planning lScope—understand the problem and the work that must be done. lEstimation—how much effort?
Software Project Management Lecture # 8. Outline Chapter 25 – Risk Management  What is Risk Management  Risk Management Strategies  Software Risks.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Risk management in Software Engineering T erm Paper By By Praveenkumar Sammita Praveenkumar Sammita CSC532 CSC532.
HIT241 - RISK MANAGEMENT Introduction
1 Chapter 6 Risk Management. 2 Project Risks What can go wrong? What is the likelihood? What will the damage be? What can we do about it?
Software Project Management Lecture # 8. Outline Earned Value Analysis (Chapter 24) Topics from Chapter 25.
Managing Risk. Objectives  To Describe Risk Management concepts and techniques  To calculate and analyze a project using Probability of completion 
Risk management process
Managing Risks in Projects. Risk Concepts The Likelihood that some Problematical Event will Occur The Likelihood that some Problematical Event will Occur.
Risk Analysis and Management. Reactive Risk Management Project team reacts to risks when they occur. More commonly, the software team does nothing about.
Software Engineering Risk Management. Understanding Risks Risks involve :  Uncertainty – there are no 100% probable risks  Loss – if the risk becomes.
Chapter 12 Project Risk Management
Risk Analysis & Management
1 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
What is it? A risk is a potential problem — it might happen, it might not. But, regardless of the outcome, it’s a really good idea to identify it. Assess.
Software Project Management
Chapter 3 Project Management Chapter 3 Project Management Organising, planning and scheduling software projects.
Ch 10 - Risk Management Learning Objectives You should be able to: List and describe risk management processes, inputs, outputs, and tools List and describe.
Question Four: Project Risk Management PMBOK definition of Project Risk Project risk management is the art and science of identifying, analyzing, and responding.
Risk Analysis 1. Project Risks 2 What can go wrong? What is the likelihood? What will the damage be? What can we do about it? Check : List of potential.
Software Engineering B.Tech IT/II Sem-II Term: Unit-7 PPT SLIDES Text Books:1.Software Engineering, A practitioner’s approach Roger s. Pressman.
EFFORT ESTIMATION RISK MANAGEMENT. Total time required by the project to get completed. The overall cost of the project.
Project & Risk Management
Project Risk Management. Risk-Defined A situation involving exposure to danger; “The combination of the probability of an event and its consequences”
Dr. Rob Hasker. Avoiding failure  Standish Report, 2014 Standish Report 31% projects cancelled before completion 53% projects ~190% of original estimate.
Software Project Management Lecture # 9. Outline Chapter 25 – Risk Management  What is Risk Management  Risk Management Strategies  Software Risks.
Software Engineering Lecture 8: Quality Assurance.
R i s k If you don’t attack risks, they will attack you.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
11 CPIT 456 by Dr. M. Rizwan Jameel Qureshi Chapter 3 Risk Management.
ON “SOFTWARE ENGINEERING” SUBJECT TOPIC “RISK ANALYSIS AND MANAGEMENT” MASTER OF COMPUTER APPLICATION (5th Semester) Presented by: ANOOP GANGWAR SRMSCET,
Ashima Wadhwa.  Probably the most time-consuming project management activity.  Continuous activity from initial concept through to system delivery.
RISK MANAGEMENT FOR IT PROJECTS SAHIRA MTECH, MBA(MIS), CISSO, CPTE.
Chapter 25 Risk Management
Software Engineering (CSI 321)
Chapter 25 Risk Management
Software Engineering B.Tech Ii csE Sem-II
Chapter 25 Risk Management
Risk Analysis.
Chapter 35 Risk Analysis Slide Set to accompany Software Engineering: A Practitioner’s Approach, 8/e by Roger S. Pressman and Bruce R. Maxim Slides copyright.
Chapter 25 Risk Management
SE 3800 Note 10 Project Management
Chapter 28 Risk Analysis Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright © 1996, 2001,
Software metrics.
Chapter 25 Risk Management
Presented To: Sir Ali Raza Presented By: Kainat(06)Riffat(024)Asqsa(034) Group#06.
Chapter 6 Risk Management
Risk Management.
Software Risk Management
Presentation transcript:

Software Engineering Lecture 6: Risk Analysis & Management

Today’s Topics l Reactive vs. proactive strategies l Types of software risk l Risk identification & projection l Risk mitigation, monitoring, management (RMMM) l Safety risks and hazards

Characterizing Risk l Risk concerns the future What can we do today to avoid problems tomorrow? l Risk involves change What aspects of the problem domain and solution are unstable? l Risk involves choice & uncertainty We often make decisions based on incomplete information

Quotes l “..risk, like death and taxes, is one of the few certainties of life” [Charette, 1989] l “While it is futile to try to eliminate risk, and questionable to try to minimize it, it is essential that the risks taken be the right risks.” [Drucker, 1975]

Reactive vs. Proactive Strategies l Reactive “Indiana Jones school of risk management” Risk management = Crisis management (“fire-fighting mode”)

Reactive vs. Proactive [2] l Proactive Identify risks in advance Assess probability, impact Prioritize by importance Explicit risk management plan “Risk is unavoidable”

Software Risks l uncertainty : The event that characterizes the risk may or may not happen; P never equals 1.0 l loss : If the risk becomes a reality, unwanted consequences or losses will occur l Important to quantify these for each risk analyzed!

Categories of Risk l Project risks l Technical risks l Business risks l Known risks l Predictable risks l Unknown risks

Project Risks l Threaten the project plan l Problems with budget, schedule, personnel, resources, customer, requirements

Technical Risks l Threaten quality and timeliness of software l “Implementation may become difficult or impossible” l Problems with design, implementation, interfacing, verification, maintenance

Technical Risks (2) l Include specification ambiguity, technical uncertainty, technical obsolescence, “leading- edge” technology l “The problem is harder to solve than we thought it would be”

Business Risks l No market for product (market risk) l Product no longer fits in the business plan (strategic risk) l Sales force doesn’t know how to sell the product (sales risk) l Loss of management support (management risk) l Loss of budget, people (resource risk)

Known Risks l Uncovered during plan evaluation l Examples: Unrealistic delivery date Lack of documented requirements Lack of scope Poor development environment

Predictable Risks l Extrapolate from past experience l Examples: Staff turnover Poor customer communication Dilution of staff effort by maintenance

Unpredictable Risks l Everything else that can’t be anticipated… l Experience in a particular development domain suggests certain risk factors that can and should be applied globally

Risk Identification l Specify threats to the project plan l “Identification is the better part of mitigation” l “If you don’t actively attack the risks, they will attack you” [Gilb, 1988]

Risk Subcategories l Generic risks (affect every software project) l Product-specific risks, specific to: the particular technology the specific individuals the particular environment

Risk Item Checklist l Product size: What risks are associated with overall size of the software? l Business impact: Risks associated with management or market constraints

Risk Checklist [2] l Customer characteristics: risks associated with the sophistication and communication skills of the customers l Process definition: risks associated with the maturity of the development process

Risk Checklist [3] l Development environment: risks associated with the quality of development tools l Technology to be built: risks associated with system complexity and ‘newness’ of the solution l Staff size and experience

Product Size Risks l Estimate LOC or FP degree of confidence in estimates? # of programs, files, events? % deviation from average size?

Size Risks [2] l Size of associated database(s)? l Number of users? l Number of projected requirements changes? l Amount of reused software?

Business Impact Risks l Impact on revenue? l Visibility to management? l Reasonableness of deadlines? l Number of customers? l Consistency of customers?

Business Risks [2] l Interoperability? l User sophistication? l Documentation required? l Government constraints? l Cost of late delivery, defects?

Customer-Related Risks l Customers have different needs and personalities l Customer / supplier relationships vary l Customers are contradictory l “Bad” customers are a significant threat and a substantial risk

Generic Customer Risks l Have you worked with them before? l Do they understand what is needed? l Are they willing to write specs? l Are they willing to attend reviews? l Level of technical understanding? l Do they understand the development process?

Process Risks l Is there a standard development process which is well-documented? l Do staff follow the process? l Do they have adequate training? l Do you track the process with formal reviews and walkthroughs? l Do you use configuration management?

Technology Risks l Is the technology new to you? l New algorithms or I/O? l Interface with new/unproven HW/SW/DB? l Specialized user interface? l New analysis, design, testing methods?

Technology Risks (2) l Unconventional development methods? (e.g., AI) l Excessive performance constraints? l Customer uncertain about feasibility?

Impact Assessment l Four risk types: Performance Risk, Cost Risk, Support Risk, Schedule Risk l Four impact categories: Negligible, Marginal, Critical, Catastrophic l Characterization of consequences (1) errors, (2) failure to achieve outcome

[From SEPA 5/e] Impact Assessment

Sample Risk Table [From SEPA 5/e] Assigned using impact assessment table

Risk and Management Concern [From SEPA 5/e]

Risk Referent Level [From SEPA 5/e]

RMMM Risk Mitigation, Monitoring, and Management Mitigation: Reduce probability and/or impact of risks in advance Monitoring: Watch factors that indicate change in risk probability Management: Implement contingency plan(s)

RMMM (2) l RMMM adds overhead! l 80/20 rule: 80% of overall risk from 20% of identified factors l RMM Plan for every risk above a certain threshold, create a risk information sheet (RIS) track / update RMMM plan regularly

Risk Information Sheet [From SEPA 5/e]

Safety Risks and Hazards l Classic case: control systems l Language systems: critical control or instructional scenarios l Mitigation: limit scope of software, increase human role limit scope of human intervention, increase redundant backup systems

Questions?