<ul><li>An ongoing or an upcoming concern that has a significant probability of negatively affecting the completion or the quality of a product. </li></ul><ul><li>“ a bad thing that might happen.” </li></ul><ul><li>Risk = uncertainty + loss </li></ul><ul><li>An issue is a risk that has become a reality. </li></ul>
<ul><li>Risk Categories </li></ul><ul><li>Mission and Goals Any project accepted must fit within the organization’s mission and goals. For example, an organization whose mission is developing custom software accepts a generic software project. </li></ul><ul><li>Customer A project must have a customer committed to its success, and a project manager with good communication skills to understand the customer needs and to be aware of unrealistic expectations from users. </li></ul><ul><li> </li></ul>
<ul><li>Budget/Cost Understanding project size, having good historic information on similar projects and understanding the external influences, such as technology, are the main ways to reduce this category’s risk. </li></ul><ul><li>Schedule Schedule dates may be imposed externally from the </li></ul><ul><li>development team. If the development team does not have any input into the completion and delivery dates for the project, there is very little chance that the schedule will be met. Software development teams must be part of developing and modifying the project schedules. </li></ul>
<ul><li>Development Process This category is focused on processes that reduce overall risk and improve delivered product quality. </li></ul><ul><li>Development Environment </li></ul><ul><li>Focuses on the physical environment of facilities, hardware platforms and software development tools. Risk is present in not only the lack of adequate tools but in inadequate facilities. Not having a co-located team, or not having adequate meeting space, customer interviewing space and workrooms greatly increases the risk. Teams need face-to-face contact on a regular basis. </li></ul>
<ul><li>Development Team Having an experienced and proven high productivity software development team. Not being sure of the abilities of the team or their experience with the problem domain can increase the risk. </li></ul>
<ul><li>Known Become obvious through analysis. For example, resource limits and unrealistic deadlines. </li></ul><ul><li>Predictable Expected through previous experience. For example, employee problems. </li></ul><ul><li>Unpredictable Hard to expect. For example, adopting a new technologies and predicting user tastes. </li></ul>
<ul><li>Preparing a Risk Survey Asking management, developers, other development teams, customers and any other project stakeholders to describe the most critical issues facing the development project. The objective of this exercise is to produce a comprehensive statement of all potential risks facing the project. This exercise is ideally carried out early in the project lifecycle. </li></ul><ul><li>Pay special attention to those assuming a promising future where “everything works.” </li></ul>
<ul><li>Flowcharting </li></ul><ul><li>This helps spot risky areas. Draw the flow of execution to see all the dependencies to successful completion. </li></ul><ul><li>Looking for Bottlenecks Bottlenecks will show up in the project network as tasks that require other tasks to complete before they can begin. These are the real choke points in the project planning network and have the highest risk reaction with schedule slips. </li></ul>
3.5 1.0 3 0 0 1 5 5 2 1.0 1.0 4 1.5 1.5 6 3.5 3.5 7 3.5 1.0 5 7.5 7.5 8 8.0 8.0 12 9.0 9.0 13 10.0 10.0 14 0.5 0 0.5 0 7.5 6.0 11 0.5 0.5 0.5 2.0 1.0 4.0 0.5 1.0 1.0 A project network for the payroll project. Time expressed in weeks, the critical path is highlighted in dark Events 1-2 File design (analyst) 2-3 File creation (programmer) 2-4 Design data entry program (analyst) 3-7 Dummy 4-5 Write data entry program (programmer) 4-6 Design payroll reports (analyst) 5-7 Dummy 6-7 Design payroll program (analyst) 7-8 Write payroll program (programmer) 7-9 Design personnel program (analyst) 8-12 Write check writer program (programmer) 7.0 5.5 10 6.0 4.5 9 1.0 0.5
<ul><li>A continuous activity directed towards the assessing and monitoring of risks. </li></ul>Risk Management Risk Assessment Risk Control Risk Identification Risk Analysis Risk Prioritization Risk Mgt Planning Risk Resolution Risk Monitoring Boehm’s Risk Model Probability and Estimation Compare Identified Risks Identify All Possible Risks Develop Plans to Mitigate Risks Employ the Right People, Develop Prototypes and Simulations Provides Assurance
What Is the Relation Between Software Complexity and Risk?
Software Complexity Risk <ul><li>The need to manage risk increases with the complexity. </li></ul><ul><li>Both technical and non-technical (e.g. cost and schedule) risks increase with the increase of complexity. </li></ul>
<ul><li>Fault Trees (FT) </li></ul><ul><ul><li>Logic block diagrams that display the state of the system in terms of the state of its components. </li></ul></ul><ul><ul><li>Looks at the failure space of the system. </li></ul></ul><ul><ul><li>Built top-down. </li></ul></ul><ul><ul><li>Used by NASA. </li></ul></ul><ul><ul><li>Some FT symbols: </li></ul></ul>A B OR A B AND The failure of either of the events (A and B) causes the top event (or system) to fail The failure of both of the events (A and B) causes the top event (or system) to fail
<ul><li>Risk Matrix </li></ul><ul><ul><li>A tool used in the Risk Assessment process. </li></ul></ul><ul><ul><li>Allows us to determine the severity of an event. </li></ul></ul><ul><ul><li>The risk of an event E is the total number of hazards that contribute to it: </li></ul></ul>Hazard Probability Consequence
Consequence Probability Insignificant (1) Minor (2) Moderate (3) Major (4) Extreme (5) Rare (1) Low Low Low Low Low Unlikely (2) Low Low Low Medium Medium Possible (3) Low Low Medium Medium Medium Likely (4) Low Medium Medium High High Almost Certain (5) Low Medium Medium High Extreme
<ul><li>Wikipedia. </li></ul><ul><li>Managing Software Project Risk by Robert Armstrong and Gillian Adens - Tassc Limited - January 2008. </li></ul><ul><li>Risk-based planning with use cases by Mark Aked, Managing Consultant - Lamri Ltd. </li></ul><ul><li>Introduction to Risk Management by Charles Wallace - Michigan Technological University. </li></ul><ul><li>Risk Management Guide for Small Businesses – Department of State and Regional Development – New South Wales Government. </li></ul><ul><li>Software Risk Management by Ronald P. Higuera and Yacov Y. Haimes - June 1996. </li></ul><ul><li>Software Risk: Why must we keep learning from experience by Don Shafer, Chief Technology Officer - Athens Group, Inc., Houston, Texas, USA. </li></ul>
Thank You for Listening Feel free to send any comments or suggestions Presentation by: Muhammad Alhalaby Email: firstname.lastname@example.org
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.