Introduction

In the original article, the author gives a review of two major software risk management methods: Boehm’s risk management method [2] and SEI’s risk management method [3]. The whole article consisted of three main parts. First, the author illustrated the necessity of risk management in the software industry. Second, two main risk management methods for software were given. The author demonstrated the primary principles and content of those methods. Finally, the authors analysed the advantages and also drawbacks of those methods according to some comparative papers. [1]

This article expounded two software risk management methods on the level of description its content. The author used a bullet point to analyse the sub-methods of them, which is comprehensive and easy-understood. However, because of the limitation of the length of the article probably, two methods of risk management were mentioned in the article. As for the reviews and comparisons of the methods, I take the viewpoint that the authors should provide more comments from his/her own idea not only from other essays. According to that, what I am going to talk about in this article is offering reviews of those two methods, giving their strengths and weaknesses according to my knowledge, and comparing these two methods.

Review of two methods

Review of Boehm’s risk management method

As demonstrated in the original article, Boehm’s risk management method [2] divides the risk management on software into two parts: risk assessment and risk control. The risk assessment is aimed at identifying the underlying risks and gives the risks an assessment about the degree of risks and priority of risks. After estimation, the risk control part plays an important role in the whole management process, which includes risk management planning, risk resolution and risk monitoring.

Since the Boehm’s risk management method is the first risk management methods in software industry, it has deeper meaning on creating a pioneer rather than a practical instrument of risk management. To consider a method from a certain perspective, Boehm focuses more on the steps and systematization of the ideal risk management. More details about how to actually running and maintaining a risk control are expected from Boehm’s methodology. I think the risk management of the software is different between it of business or entrepreneur. The software system is the most exquisite and precise masterpiece than business which has better robustness. By telling you that I mean business system normally has ‘inborn’ ability to control the gusty risk of self-adjustment and macro-control. As for the software system, an eligible risk control method should provide the procedures and process of tackling self-risk at least in my opinion, which is lacking in Boehm’s risk.

I agree with the point of the mutability of the top 10 software risk items checklist based on an in-depth investigation of several large US aerial or defense system software programs. Although the checklist is very useful for risk identifying and avoiding and has doubtless universality and practicality, it is still just the general summary of existing risks which is insufficient on supported article and real situation. Admittedly, as a first method of risk management, this checklist contributes to building for the whole methodology as foundational principles.

Review of SEI’s risk management method

SEI’s risk management method [2] is presented by the Software Engineering Institute (SEI). It uses SEI-Software Risk Management (SRM) model. This method adopts cycling process to operate the risk management. Two remarkable advantages and innovation can be seen in this method: firstly, the cycling process provides macroscopical operation instrument. Five main sub-processes are involved, including identity, analyse, plan, track and control, which are linked and coordinated by communication. Secondly, Software Risk Evaluation (SRE) team is employed for supporting the running of the whole process. SRE team also takes responsibility of communication, which is a vital part of SEI’s method.

Strengths of the SEI’s risk management method are obvious. The author concluded the review part of the original article that the reliability and the efficiency of the risk management process will be greatly increased due to the involving of SRE team. Moreover, in my opinion, the participation of a specific team is beneficial to follow aspects: Firstly, professional team is technically at tackling the specific risk management problems. Engaging of SRE team will increase the operational capability of risk control no matter what types risk management type they use. Secondly, the impeccable SRE team guarantees the cooperation between different functional team of the whole software project by efficient and goal-oriented communication. The conflicting, misunderstanding and ambiguity of function between various teams in the same project will be removed at the greatest extent. Thirdly, and more importantly, the major advantage of the SRE team is the improvement of efficiency. With the participation of the SRE team, relevant discussion and information collection / integration can be made more properly and in time. Meanwhile, members of SRE team can join the discussions and decision-making whenever and wherever during the five main sub-process we mentioned before for the sake of reliability and the effectiveness of the risk management process. Expect the usage of the SRE team, SEI’s risk management method also benefits from its circulation model which is not mentioned in the original article. I take the view that cycling process is more helpful for enhancing the quality of risk control by providing all-sided risk identifying, rapid and detailed feedbacks, and planning fixing for underlying shortcomings.

In terms of the drawbacks of SEI’s risk management method, the original article seems cover the majority respects which I cannot agree more. Human efforts during this method may cause inconclusive results. Communication between individuals contains uncertainty features which will influence on the operation of systematically process. One of possible ways to address this problem is training a professional SRE team, but it causes the other drawbacks of the SEI’s method, which is the fact that employing and managing such an SRE team is, in a way, difficult and expensive.

Comparison

In this part, the comparison of two methods will be provided in order to contrast the pros and cons of them. Firstly, from the view of architecture, Boehm’s adopts a linear process while SEI’s methods use cycling process to repeat iteration. Obviously, SEI’s method ensures the correctness and stability of risk management. Secondly, as only the fixed principles (top-10 checklist and calculation of parameters) are used in Boehm’s method, it has a weakness in handling the continual changes which relies on a stable environment. SEI’s method, because of the involvement of human, is able to respond to the uncertainty situation. Robustness and universality are increased significantly due to this. As for the description of the method from the respect of reality operation, SEI’s method concentrates on practical and operation, while Boehm’s method focuses more on conception model. In terms of weaknesses, SEI needs an abundant human resource to support whole method, which is challenging for small software companies.

Conclusion

Overall, the original article demonstrated two separate risk management methods in software industry clearly and well-organized. I just fill the gap on the review part which the author did not concentrate on. In this article, strengths and weaknesses of two software risk managements are evaluated according to my knowledge. I also compare these methods. Consequentially, SEI’s method is better to operate, especially for a large-scale software company under a well-manage the situation.

References

[1] M. J .Han,” A Review of Two Software Risk Management Methods”, retrieved on 4th, March, 2014 from https://blog.inf.ed.ac.uk/sapm/2014/02/13/a-comparison-of-two-software-risk-management-methods/

[2] B. W. Boehm, “Software risk management: principles and practices,” Software, IEEE, vol. 8, no. 1, pp. 32–41, 1991.

[3] Y. B. et al, “Software risk management: A practical guide,” 2000. http://cio.doe.gov/sqas.