1. Risk management in Software Engineering T erm Paper By By Praveenkumar Sammita Praveenkumar Sammita CSC532 CSC532

2. INTRODUCTION What is Risk? What is Risk? A Risk is a possibility of suffering harm or loss or danger. 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. 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 Software development involves  New technology  Challenging or unknown requirements  tight schedules All these makes the software project prone to several types of risk. 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. 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 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. 1055 Installation of risk management

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 Diminished quality of the product Increased costs Increased costs Delayed completion Delayed completion Total program failure 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 configuration manager might see an aspect that affect configuration management. A software engineer might see an aspect that affects component quality. A software engineer might see an aspect that affects component quality. A project manager might see an aspect that affects the customer. 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 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 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? Any Questions?