1 / 16

Risk management in Software Engineering T erm Paper

Risk management in Software Engineering T erm Paper. By Praveenkumar Sammita CSC532. INTRODUCTION. What is Risk? A Risk is a possibility of suffering harm or loss or danger. What is Risk management?

chidi
Download Presentation

Risk management in Software Engineering T erm Paper

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Risk management in Software EngineeringTerm Paper By Praveenkumar Sammita CSC532

  2. INTRODUCTION What is Risk? A Risk is a possibility of suffering harm or loss or danger. What is Risk management? It’s a software engineering practice with processes, methods and tools for managing risks in a project.

  3. What is the need for Risk management? Software development involves • New technology • Challenging or unknown requirements • tight schedules All these makes the software project prone to several types of risk. After the risks are identified, Risk management develops plans for mitigating risk before they sabotage the projects.

  4. Implementing Risk management Steps involved in implementing risk management • Identify new risks • Evaluate new risks • Classify new risks • Prioritize new risks • Planning Risk mitigation • Tracking Risks and mitigation plans • Reviewing and adjusting mitigation plans

  5. Installation of risk management 5

  6. Identify new risks • write down the risk and make them visible to all. • A risk can be caused by • Diminished quality of the product • Increased costs • Delayed completion • Total program failure • Don’t depend on managers to recognize and articulate all possible problems. • Make a large list of 100 or more analyzed and priority-ordered risk statements

  7. Evaluate new risks • A risk should be quantified by its probability and impact. • Assess the probability of a future event and estimate its cost. • Don’t make a detailed quantitative assessment of probability and impact for one risk. • An effective way is to avoid early quantification of impact and probability unless the risk has a significant impact on the program.

  8. Classify new risks • Classify or group risks statements in to categories based on shared characteristics can help us solve global risks. • With a single risk, • A configuration manager might see an aspect that affect configuration management. • A software engineer might see an aspect that affects component quality. • A project manager might see an aspect that affects the customer.

  9. Prioritize new risks • The organization should deal with the most important risks first and should decide how many of these it has the resources to mitigate. • A group’s weekly prioritization of the top n risks results in constant thrashing and some risks move on and off the priority list such that the action on the most important risk will be taken first to avoid the sabotage of the whole project.

  10. Planning Risk mitigation • To mitigate a risk, the goal and constraints must be known. • We can use problem solving and analytical techniques to develop strategies and guide our actions. Resolution can be a single action item or a complex, long range prototyping effort. • Mitigation plans can be action item lists or the equivalent of task plans.

  11. Tracking risks and mitigation plans • Documentation of risks like in spreadsheets summarize the project’s risks well. • For important risks, we may need backup data. • Complex tracking reports are needed for critical risks. • An effective portrayal of risk exposure vs time is the mitigation status report, to monitor mitigation progress on critical risk.

  12. Reviewing and adjusting mitigation plans Controlling a risk involves • Altering the mitigation strategy when it becomes ineffective. • Taking action on a risk that becomes important enough to require mitigation. • Taking a preplanned contingency action. • Dropping to a watch-only mode at a specific threshold. • Closing the risk when it no longer exists.

  13. Risk and mitigation plan database • Information is only useful if it’s accessible and easy to understand. • Its very effective to to use electronic databases to implement and support risk management. • It requires extra effort and time to set up a database when compared to paper-based risk documentation systems. • Integrating risk data with other types of data such as problem and safety reports will present risk data in a meaningful way to users.

  14. Conclusion • So, An effective risk management focusses on avoiding future problems rather than solving the current ones. • With effective risk management, people recognize and deal with potential problems daily before they occur and produce the finest product they can within the budget and schedule constraints. • People and workgroups understand that they are building just one end product and have a shared vision of a successful outcome.

  15. References • Risk management for software projects. Fairley, R.; Software, IEEE , Volume: 11 , Issue: 3 , May 1994 Pages:57 - 67 • Managing commitments and risks: challenges in distributed agile development Kontio, J.; Hoglund, M.Ryden,J.; Abrahamsson,P.; Software Engineering, 2004. ICSE 2004. Proceedings. 26th International Conference on , 23-28 May 2004 Pages:732 - 733 • Putting risk management into practice. Williams, R.C.; Walker, J.A.; Dorofee, A.J.; Software, IEEE ,Volume: 14 , Issue: 3 , May-June 1997 Pages:75 - 82

  16. Thank You! Any Questions?

More Related