1 / 28

RISK MANAGEMENT

RISK MANAGEMENT. BY MANISH REDDY KORENDA PRAGNA VEMURI. WHAT IS A RISK?. Risk is a combination of an abnormal event or failure, and its consequences to the system’s environment, users, etc . Early indicates about the failures that are about to come in the future.

plato-diaz
Download Presentation

RISK MANAGEMENT

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 BY MANISH REDDY KORENDA PRAGNA VEMURI

  2. WHAT IS A RISK? Risk is a combination of an abnormal event or failure, and its consequences to the system’s environment, users, etc. • Early indicates about the failures that are about to come in the future. • Likely to appear at any stage of software development, so delay occurs not only itself but also the next phases of software development.

  3. RISK • It effects cost, scheduling and working of the software project. • It involves two characteristics- uncertainty, probability. • Based on the intensity of occurrence, it is categorized into- minute, average and potential risks. • It can range from catastrophic( huge damage to the system) to negligible (no system damage).

  4. INTRODUCTION Risk management is the process of handling and resolution of the risks. It involves identification and elimination of risks. It helps to deliver desired and satisfactory projects to customers. Helps in developing reliable software.

  5. SOFTWARE RISK MANAGEMENT It is a team of managers, senior software developers/designers, programmers and various experts. Activities are: Identify risk Analyze the risk. Respond to the risk.

  6. RISK IDENTIFICATION AND RESOLUTION Fig 1: Risk identification and resolution [3]

  7. SYSTEMATIC APPROACH • Analysis- intensity of risk is analyzed. • Identification- phase in which the risk occurred is identified. • Planning- proper planning is done to resolve the risk. • Resolution- two types: Primary resolution- deals with minute risks. Complete resolution- deals with potential risks.

  8. IMPACT OF RISK ON SOFTWARE PROJECT • Depends on the intensity of the risk. • Delays the development process. • Increase in the cost. • Discouragement to the team. • Reliability is lost.

  9. MYTH AND REALITY • EXAMPLE: if the organization is working on the last phase of development cycle and if some of the developers quit. Myth: organization can assign new developers and task will meet the deadline. Reality: time increases due to training of new developers as they are not aware of the task.

  10. GOAL-DRIVEN SOFTWARE DEVELOPMENT RISK MANAGEMENT MODEL • A layered architecture is considered to manage risk. • Goal layer- identifies and models the goals. • Risk-obstacle layer- identifies potential risk factors as obstacles. • Assessment layer- analyzes the risk event that can be caused by the identified risk factor. • Treatment layer- identifies the optimized control actions to mitigate the risk.

  11. GOAL DRIVEN MODEL Fig 2: Goal driven model [2]

  12. DEFECT ESTIMATIONS USING A RISK MATRIX System test risk matrix • Indicates which test activity would and would not be conducted. • Projects the defects based on the level of testing carried out. • Indicates the possible consequences of carrying out or bypassing specific test activities. • Demonstrates the applicability of software metrics in decision support role.

  13. PROCESS INTEGRATION OF TEST RISK MATRIX Fig 3: Process integration of test risk matrix [1]

  14. TEST RISK MATRIX Table 1: Test Risk Matrix [1]

  15. Test Scope Matrix Table 2: Test Scope Matrix [1]

  16. ELEMENTS OF TEST RISK MATRIX • Standard element- values do not change from application to application. Example: test scope(combinations of various test process activities), intensity, environment, etc. • Custom element – values need to be calculated specifically for each application. Example: number of calendar weeks, staff, predicted defects, etc.

  17. DERIVE ESTIMATES FOR THE MATRIX • Software and staff estimates- scale down from worst case to fix test risk matrix. • Defect prediction methods-historicaldata is the superior method. • Test effectiveness/defect removal efficiency- E=N/(N+S) Where, E= effectiveness of activity N=number of faults found by activity S=number of faults found by subsequent activities

  18. TECHNICAL AND PROCESS RISK MEASUREMENT • Methodology composed of six steps: • Identify sources to get risk information. • Identify what information from source helps. • Assess the intensity of risk. • Define goals and questions for each risk area. • Develop measures and models. • Propose responses to identifies risks.

  19. SOFTWARE ACQUISITION • What is software acquisition? It is a process of buying software and software processes. It can be reused in the development of some other software, etc. This can be done in three ways: • Contract development • Purchased packages • Transported system Fig 4: OTS-based custom software project [4]

  20. RISK MANAGEMENT IN SOFTWARE ACQUISITION • 20% to 25% of large acquisition projects fail within 2 years. • 50% of these projects fail within 5 years. • It is understood that all this is due to mismanagement, project failure is identified very late. • Risk management must be integrated in the early stages of software acquisition process.

  21. DIFFERENCES IN RISK PERCEPTION BETWEEN DEVELOPERS AND ACQUIRERS • Both of these are affected by risks and are capable to control risks. • A survey was conducted and were asked to choose type of stakeholders, impacted by and can control each risk. • Then risk responsibilities were rationalized.

  22. METHOD TO ANALYZEDIFFERENCES Fig 5: A method for analyzing differences in off-the-shelf risks between the developer and acquirer[4]

  23. STEPS TO RATIONALIZE RISK RESPONSIBILITIES • Risk impacting stakeholders. • Risks stakeholders can control. • Mapping stakeholders from step 1 and 2 into risk control/impact matrix. • Comparing risks using the risk control/impact matrix. • Identify stakeholder agreement on and reconcile differences.

  24. RISK CONTROL/IMPACT MATRIX Fig 6: Risk Control/Impact Matrix [4]

  25. CONCLUSION • Risk management process must be integrated with each and every phase of software development process. • To minimize the future problems. • To resolve threats within the time. • Risk management team must be focused in the task for benefit of both customer and the organization.

  26. REFERENCES [1] Cusick. J., Kluwer. W.,Applying Software Defect Estimations: Using a Risk Matrix for Tuning Test Effort. Computer.org 2007. [2] Islam. S., Software Development Risk Management Model – A Goal Driven Approach. European Software Engineering Conference (ESEC/FSE) Doctoral Symposium’09 (August 25, 2009), Amsterdam, The Netherlands. [3] Kumar. D., Risk Management in Software Engineering. International Journal of Computer Science & Communication( IJCSC ) (January-June 2012) , Vol.3 No.2.

  27. REFERENCES [4]Kusumol. D. S., Staples. M., Zhu. L., Jeffery. R., Analyzing Differences in Risk Perceptions between Developers and Acquirers in OTS-based Custom Software Projects Using Stakeholder Analysis. International Symposium on Empirical Software Engineering and Measurement (ESEM’12), September 19–20, 2012, Lund, Sweden. [5] Layman. L., Basili. V., Fisher. K., A Case Study of Measuring Process Risk for Early Insights into Software Safety. International Conference on Software Engineering (ICSE) 11 (May 2011, HI, USA). [6]Villalón. J., Agustín. G., Hurtado. G., Gilabert. T., State of the Art for Risk Management in Software Acquisition. Special Intrest Group on Software Engineering (SIGSOFT) Notes (July 2009), Vol.34 No.4.

  28. THANK YOU!!!

More Related