Software Risk Management: Principles and Practices

Critique On Software Risk Management: Principles and Practices

Introduction
Author of the article : Barry W. Boehm. Title of the article : Software Risk Management: Principles and Practices Source of the article : IEEE Software: 1. 32 41 January/1991

Summery
Like many other fields software field also have to face project disasters. But the software project disasters is a serious concern according to the authors view. Because software is not just itself fails but it is the key role player in a large scale project. Then the failure of a software cause seviere disaster. But when we examine the failure situations most of the software project disasters have indicate an early concern with identifying and resolving projects high risk elements can strongly reduced or have been avoided the problem. Then the developers can forcus on the positive aspects of their software product. The waterfall process model which is sequential and document-driven, lead people to indicate software capabilities in contractually binding requirement specifications before they understand their risk implecations. In evalutionary development process model which is a code-driver, the developer code his idea and finally it will modify according to the user requirements. This approach is well supported in minidomains like spreadsheet applications but for more complex application domains it is often creates or neglets high risk elements and and that would be lead a project failure. Most of the time developers use complex mixtures of these approaches like prototyping, simulation and various kinds of cost benefit analysis. So that the successful project managers are good risk managers. They use general concept of risk exposure and thier projects tended to avoid pitfalls and finally produce good products. The author define the risk exposure is the probability of an unsatisfactory outcome and is the loss to the parties affected if the outcome is satisfactory. And he defined the Unsatisfactory Outcome a project involves several classes each with different but with highly important satisfaction criteria. These components provide top-level check list for identifying and assessing risk items. It reffered as unsatisfactory outcome is multidimensional. According to the authors example of satellite experiment the software has been under development by the team which is understand well but inexperience in casual software development and it will lead to have a critical error. The platform manager identifies 2 major options for reducing the risk of losing the experiment. One is apply better development
1

Software Risk Management: Principles and Practices

method and the other is hiring a contractor to independently to verify and validate the software. The decision tree provides a framework for analyse the sensitivity of the preffered solutions to the risk exposure parameters. Sensitivity analysis helps dealing with many situations in which probabilities and losses cannot be estimated well enough to perform a precise analysis. The risk-exposure framework also supports some even more approximate but still very useful approaches like range estimation and scale-of-10 estimation. Risk Management The practice of risk management involves two primary steps each with three subsidiary steps. The first primary step is Risk Assessment and it involves with Risk Identification, Risk Analysis and Risk Prioritization. - Risk Identification produce lists of the project specific risk item which lead to project success. This technique include checklists, decision driver analysis, assumption analysis and decomposition. - Risk Analysis assess the loss probability and loss magnitude for each identified risk item. This include performance models, cost models, network analysis and decision analysis. - Risk Prioritization produces a ranked ordering of the risk item identified and analysed. This technique include risk exposure analysis, risk leaverage analysis and compound risk reduction. The second primary step is Risk control and it involves with Risk-Management Planning, Risk resolution and Risk Monitoring. - Risk-Management planning helps to address each risk item. This technique include cost-benefit analysis, risk avoidance, risk transfer ans risk-element planning. - Risk resolution produces in which the risk items are eleminated or resolved.This use prototypes, simulation, benckmarks and staffing. - Risk monitoring involves tracking the progress towards resolving its risk items and this technique use milestone tracking, top 10 tracking and corrective action. Risk management provide an improved way to address and organize the life cycle. Risk driven approaches like spiral model avoid many of the difficulties which comes with the previous process models like waterfall and evolutionary development model. The author is more concern on four significant subsets of risk management techniques in this article. 1) Risk-Identification Checklist Managers and system engineers can use the checklists to help identify and resolve the most serious risk items on the project and also provide corresponding set of risk management techniques that have usefull to avoid or resolve source of risks.

Software Risk Management: Principles and Practices

2) Risk Analysis and Prioritization After using all the techniques we can identify so many risk items. Then the risk analysis and prioritization become essential. As described in the article the most effective technique is risk-exposure quantity. 3) Risk-Management Planning Once you identify the major risk items and their relative priorities then you need to establish a set of risk control functions to bring the risk item under control. 4) Risk Resolution and Monitoring Once you have establish efffective set of risk management plans the risk resolution process is invoked and implementing risk resolution techniques. Risk monitoring ensures tracking risk reduction progress and applying corrective action to keep the resolution process on track.

Conclusion
The authors (Boehms) software risk management model mainly focuses on the concept of Risk Exposure which was expalin in the summery. The author hardly trying to expalin the early identification of risk elements will easy the way to reduce or avoid the failures of software projects. I am agree with authors view because if we identify the threats earlier then we can prevent or detect them by taking appropreate decisions and actions on the right time. But there are some cases if we identify the risk elements, take actions on time but at the end software will failure due to some other reasons. So that we cannot say that risk management is the only reason but it is a just one reason for a software failure.