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?

Slides:



Advertisements
Similar presentations
W5HH Principle As applied to Software Projects
Advertisements

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Project Risk Management
Risk Analysis and Management
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.
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.
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.
CIS 375 Bruce R. Maxim UM-Dearborn
Project Risk Management Risk Mitigation. Risk Management  The prime objective of risk management is to minimize the impact and probability of the occurrence.
Risk Management in Software Projects
Chapter 3 Project Management
1 Software Engineering: A Practitioner’s Approach, 6/e Chapter 25 Risk Management Software Engineering: A Practitioner’s Approach, 6/e Chapter 25 Risk.
Risk Analysis & Management
1 COSC 4406 Software Engineering COSC 4406 Software Engineering Haibin Zhu, Ph.D. Dept. of Computer Science and mathematics, Nipissing University, 100.
©Ian Sommerville 2006Software Engineering, 7th edition. Chapter 5 Slide 1 Project management.
Software Project Management
Chapter 25 Risk Management
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.
Software Testing Lifecycle Practice
Capability Maturity Model Part One - Overview. History Effort started by SEI and MITRE Corporation  assess capability of DoD contractors First.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 1 Concerned with activities involved in ensuring that software is delivered: on.
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.
Chapter 2 Project Management Lecture 1 1Chapter 22 Project management.
Project Tracking. Questions... Why should we track a project that is underway? What aspects of a project need tracking?
Chapter 6 : Software Metrics
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.
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.
ﴀ These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
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.
Object-Oriented Software Engineering
Chapter 22 – Risk Management 1Chapter 22 Project management.
1 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.
Chapter 3 Project Management Chapter 3 Project Management Organising, planning and scheduling software projects.
1.  an unrealistic deadline established by someone outside the software development group  changing customer requirements that are not reflected in.
1Coming up: Project Risks Chapter 28 – Modified by Fleck Risk Analysis Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger.
Parts of this presentation is extracted from Ian Sommerville’s slides located at
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.
Software Engineering Lecture 6: Risk Analysis & Management.
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.
Chap 4. Project Management - Organising, planning and scheduling
1 Chapter 3: Project Management Chapter 22 & 23 in Software Engineering Book.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Project.
1 Chapter 24 Project Scheduling and Tracking Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
Software Project Management Lecture # 9. Outline Chapter 25 – Risk Management  What is Risk Management  Risk Management Strategies  Software Risks.
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.
1 Chapter 24 Project Scheduling and Tracking Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
Chapter 3 Project Management Parts of this presentation is extracted from Ian Sommerville’s slides located at
Ashima Wadhwa.  Probably the most time-consuming project management activity.  Continuous activity from initial concept through to system delivery.
Chapter 25 Risk Management
Chapter 6: Database Project Management
Software Engineering B.Tech Ii csE Sem-II
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
Assessing Risk Impact Factors affecting the consequences Nature Scope
Chapter 28 Risk Analysis Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman Slides copyright © 1996, 2001,
Chapter 28 – Modified by Fleck
Chapter 6 Risk Management
Software Project Management
Risk Management.
Software Testing Lifecycle Practice
Presentation transcript:

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?

3 Reactive Risk Management  project team reacts to risks when they occur  mitigation—plan for additional resources in anticipation of fire fighting  fix on failure—resource are found and applied when the risk strikes  crisis management—failure does not respond to applied resources and project is in jeopardy

4 Proactive Risk Management  formal risk analysis is performed  organization corrects the root causes of risk  TQM concepts and statistical SQA  examining risk sources that lie beyond the bounds of the software  developing the skill to manage change

5 RISK Risk Management Paradigm control identify analyze plan track

6 Building a Risk Table RiskProbabilityImpactRMMM RiskMitigationMonitoring&Management

7 Building the Risk Table  Estimate the probability of occurrence  Estimate the impact on the project on a scale of 1 to 5, where  1 = low impact on project success  5 = catastrophic impact on project success  sort the table by probability and impact

8  mitigation—how can we avoid the risk?  monitoring—what factors can we track that will enable us to determine if the risk is becoming more or less likely?  management—what contingency plans do we have if the risk becomes a reality? Risk Mitigation, Monitoring, and Management

9 Risk Due to Product Size estimated size of the product in LOC or FP? estimated size of the product in LOC or FP? estimated size of product in number of programs, estimated size of product in number of programs, files, transactions? percentage deviation in size of product from percentage deviation in size of product from average for previous products? size of database created or used by the product? size of database created or used by the product? number of users of the product? number of users of the product? number of projected changes to the requirements number of projected changes to the requirements for the product? before delivery? after delivery? amount of reused software? amount of reused software? Attributes that affect risk:

10 Risk Due to Business Impact affect of this product on company revenue? affect of this product on company revenue? visibility of this product by senior management? visibility of this product by senior management? reasonableness of delivery deadline? reasonableness of delivery deadline? number of customers who will use this product number of customers who will use this product interoperability constraints interoperability constraints sophistication of end users? sophistication of end users? amount and quality of product documentation that amount and quality of product documentation that must be produced and delivered to the customer? governmental constraints governmental constraints costs associated with late delivery? costs associated with late delivery? costs associated with a defective product? costs associated with a defective product? Attributes that affect risk:

11 Risks Due to the Customer Have you worked with the customer in the past? Have you worked with the customer in the past? Does the customer have a solid idea of requirements? Does the customer have a solid idea of requirements? Has the customer agreed to spend time with you? Has the customer agreed to spend time with you? Is the customer willing to participate in reviews? Is the customer willing to participate in reviews? Is the customer technically sophisticated? Is the customer technically sophisticated? Is the customer willing to let your people do their Is the customer willing to let your people do their job—that is, will the customer resist looking over your shoulder during technically detailed work? Does the customer understand the software Does the customer understand the software engineering process? Questions that must be answered:

12 Risks Due to Process Maturity Have you established a common process framework? Have you established a common process framework? Is it followed by project teams? Is it followed by project teams? Do you have management support for Do you have management support for software engineering Do you have a proactive approach to SQA? Do you have a proactive approach to SQA? Do you conduct formal technical reviews? Do you conduct formal technical reviews? Are CASE tools used for analysis, design and Are CASE tools used for analysis, design and testing? Are the tools integrated with one another? Are the tools integrated with one another? Have document formats been established? Have document formats been established? Questions that must be answered:

13 Technology Risks Is the technology new to your organization? Is the technology new to your organization? Are new algorithms, I/O technology required? Are new algorithms, I/O technology required? Is new or unproven hardware involved? Is new or unproven hardware involved? Does the application interface with new software? Does the application interface with new software? Is a specialized user interface required? Is a specialized user interface required? Is the application radically different? Is the application radically different? Are you using new software engineering methods? Are you using new software engineering methods? Are you using unconventional software development Are you using unconventional software development methods, such as formal methods, AI-based approaches, artificial neural networks? Are there significant performance constraints? Are there significant performance constraints? Is there doubt the functionality requested is "do-able?" Is there doubt the functionality requested is "do-able?" Questions that must be answered:

14 Staff/People Risks Are the best people available? Are the best people available? Does staff have the right skills? Does staff have the right skills? Are enough people available? Are enough people available? Are staff committed for entire duration? Are staff committed for entire duration? Will some people work part time? Will some people work part time? Do staff have the right expectations? Do staff have the right expectations? Have staff received necessary training? Have staff received necessary training? Will turnover among staff be low? Will turnover among staff be low? Questions that must be answered:

15 Project: Embedded software for XYZ system Risk type: schedule risk Priority (1 low... 5 critical): 4 Risk factor: Project completion will depend on tests which require hardware component under development. Hardware component delivery may be delayed Probability: 60 % Impact: Project completion will be delayed for each day that hardware is unavailable for use in software testing Monitoring approach: Scheduled milestone reviews with hardware group Scheduled milestone reviews with hardware group Contingency plan: Modification of testing strategy to accommodate delay using Modification of testing strategy to accommodate delay using software simulation software simulation Estimated resources: 6 additional person months beginning Recording Risk Information