软件项目的风险管理详解

1、软件工程的风险管理详解我是一名计算机软件开发人员。我精通多种编程语言。我热爱这份工作，设计程序、编程、调bug、解决问题这一切让我觉得很兴奋、很有成就感。我愿意学新东西，解决一个又一个技术难题这让我觉得自己是一个有用的人。我喜欢我的同伴们，他们是一群很棒的人，我们谈得来，技术上的事儿我们总能一起找到方法。但是工程是另外一回事儿，有时候真的让人很恼火，我们团队只有3个人，却干着6个人的活儿！我们只有1台调试机，几个团队都要用，每天因为争用调试机打架。忙死了，还要带一帮新人干活，他们什么都不会，光添乱！他们要是早一点儿来我还有时间带他们，如今？算了，我还是加班自己来吧。早干嘛去了，这时候才说要改架

2、构，我们开发都进展一半了！这活儿真没法儿干，客户干嘛总是来指手画脚啊，打乱我们的方案了。我在公司承受了3个月的培训，如今正式参加这个工程了。工程很大，任务很重，据说对公司的前途至关重要，我很兴奋。前辈们很有经历，也很忙，我也想做点儿什么，但是他们好似不太欢送我参加，有点儿沮丧。假如你是一名软件开发者或任何需要团队合作的工作参与者，上面的话是不是感觉很熟悉？每个人都有干劲儿，大家目的也一致，但是总是有这样那样的问题使我们无法专注于自己的本职工作。问题，问题，那么多的问题！虽然说解决难题能带来成就感，但是相信我，当意料之外的问题组团出现的时候，它们带来的只能是混乱！更糟糕的是，火气、丧气、疲惫感也

3、一起来凑热闹。对于工程，尤其是大工程来讲，这可不是个好现象。好吧，让我们静下来，想一想，那些问题在成为问题之前，我们真的一点儿都没意料过么？假如能意料的话，是否可以提早做些什么来防止，或者减轻问题的破坏力？退一步讲，最起码让人喘口气，问题别一起出现！要到达上述目的，用一个术语化的说法，就是进展风险管理。通俗的说，风险就是问题发生的可能性。所谓问题，就是之前我们提到的各种各样的不希望发生的闹心事儿。风险管理的主要任务是：在问题发生之前，识别它、评估它、做对策，降低其发生的可能性和发生时的危害程度；然后，在对策的施行过程中，进展定期跟踪、再评估、调整对策，以确保问题是可控的，直到平安解决。风险管理

4、综上所述，风险管理主要表达在下面几方面：风险识别：找到可能发生问题的地方风险评估：是哪类问题、发生的可能性、发生后的影响度以及危险等级风险对策：什么时间、做哪些工作、能降低风险发生的可能性还是发生后的影响风险跟踪：可能性的变化、影响度的变化、危险等级的变化、风险对策是否需要调整、是否引起新的风险等等风险管理是软件工程整个生命周期中的常规工作。在工程筹划、工程范围变更、工程方案变更、定期工程跟踪时，都要进展风险管理。风险识别在软件开发工程中，要识别风险，一个根本方法是模拟法用现有的人员、技术、资源设备、可以得到的支持等，在工程开场的时点上，审视现有流程上的每一个步骤，考虑并预测将会遇到什么问题。

5、这项工作将使我们得到一份风险描绘的列表。对风险列表中的风险进展合并同类项处理，尤其是当一个工程涉及到多个团队、较多人，不同的团队和个人提出与他们相关的风险的时候，这种合并同类项的处理就显得尤为重要。它可以保证资源的统一调配，最大限度复用，防止各自为政造成的浪费。风险评估对风险进展深化的评价，主要分析风险的种类、可能性和影响。风险的种类一般来讲，所有的风险都可以归结到软件工程的几个要素上去。如今，我们首先来提取这些要素。什么是工程？通俗的讲就是：在特定的时间内、特定的本钱下、完成特定的工作，成果物要质量达标，令用户满意。所以说，工程有下面几个关键的维度：进度：在什么时间完成本钱：花费多少代价范围

6、：做什么，做到什么程度质量：成果物的质量属性例如千行代码bug数、平安运行天数客户满意度：令客户满意所谓风险的种类，在软件工程中，通常指上述维度的某一个。当然，从市场及企业经营的级别来看，会有另外一套关于种类的定义标准，这里不做深化讨论。可能性：这个风险演变成问题的可能性有多少影响：这个风险演变成问题的话，其破坏力有多大风险级别：根据风险演变成问题的可能性和影响度，形成各风险评级。风险级别越高，越应该得到管理者的重视下表列举了风险评级的方法(表1)：首先，量化描绘可能性及影响度，然后把风险放到矩阵中的相应位置上，最后根据风险所处的区域，判断是S、A、B、的哪一个级别。S级：影响大、发生的可能性

7、大。这样的风险必须进展处理，一定要制定对策降低风险或者躲避风险。A级：影响度在中等程度以上，发生的可能性比拟大，或者影响度虽然小，但是发生可能性很高。这样的风险也应该进展处理，制定相应的对策来降低或者躲避风险。B级：影响大，但是发生概率很低。这样的风险不应该消耗太多的管理本钱，不必专门制定对策，只需做定期跟踪。级：影响小且发生概率低。这样的风险可以暂时不纳入管理体系。需要注意的是，不同的领域、不同的工程，对风险的影响度和发生可能性的量化标准是不一样的。对风险的容忍度，也就是SAB的断定标准也是不一样的。例如：同样是发生几率为万分之一的死机这样的风险。在某些日用消费品中，是完全可以承受的，可以列

8、为级风险，不予关注。但是在航天工程中，那么是绝对不能容忍的，必须以S级来处理。所以说，任何一个工程都需要为自己量身定做风险判断基准。甚至需要在工程外、组织级进展定义。在组织级定义工程风险判断基准的好处是：同一个组织内，为风险制定统一的量化标准，那么不同工程的风险之间具有可比性，为管理和决策提供根据。因为风险评估对后期的决策有很重要的影响，所以，为慎重起见，有些评估会经与相关人员一起进展几轮的讨论，才能最后确定下来。风险对策根据风险评估中得出的风险级别，优先处理S、A级别的风险，并为每一个风险制定专门的对策。在制定风险对策的时候，我们会发现，风险是可以转移的。不同的风险，根据对策的不同可能在属性

9、上有所转移，可能对原有的风险造成影响，也可能会带来新的风险。下表是对一个风险的识别、评估和对策(表2):上述对策会降低原有的风险，但是同时会增加一个新的风险，如下(表3)所示：上述对策就是一个典型的用本钱换日程的例子。假如对策获得认可，就会对开发方案等其他方面造成影响，所有受到影响的局部，在分析影响范围的时候，也要再次回忆已经识别的风险是否会因为这个变化而变化。在为风险制定对策的时候，需要掌握一个原那么：控制风险程度、分散重大风险。每一个风险都是一个不确定因素，是定时炸弹，尽量不要把太多的炸弹尤其是大炸弹集中在一个阶段解决。分散处理的话，万一问题爆发，控制起来也相对容易一些。多数情况下风险的对

10、策都不是唯一的，虽然对策本身可能也会带来风险，但是要尽量平衡的考虑对策本身对工程的影响。尽量让工程总的风险程度处于平稳，防止过大的波峰。如图1所示，文章开头所述的一团糟的情况，可能就是对风险没有事先的管理和干预，导致集中爆发或者风险过高，从而给工程整体带来不良的影响。更糟糕的是，打一场没有准备的仗，我们输掉战争的同时也输掉了士气和信心。假如有事先的管理和干预，工程的风险将会被控制在一个相对稳定的程度，管理起来会容易很多，如图表2所示。即使最后问题还是发生了，但是最起码之前大家对此有预期，知道会发生什么，对团队情绪方面的影响也会小很多。(图1、2)风险跟踪我们为工程识别了风险，评估了风险的级别，

11、为重要风险制定了对策，在这些工作之后，还需要对风险进展跟踪。一般在工程进展周报、月报的时候，要同时进展风险的跟踪和报告。对风险的跟踪主要集中在以下几个方面：对策跟踪：对策是否按照方案施行了，施行过程中是否有新的风险出现这里又是一个风险识别的过程可能性：随着时间的推移或对策的施行，这个风险演变成问题的可能性有什么变化影响：随着时间的推移或对策的施行，这个风险演变成问题的话，问题的破坏力有多大级别：随着可能性和影响的变化，级别也会随之变化风险状态：假如风险级别已经变得很低，不需要再继续处理的话，那么关闭这个风险，以后不再跟踪调整风险对策：判断是否需要调整对策方案，如何调整调整的过程又涉及到新的风险识别活动在进展风险跟踪的时候，需要注意的是：并非所有的变化都是我们的对策在起作用，有时候可能是市场变化，也可能是客户要求的变化，或者是其他外部环境的变化，让本来的可能性及影响度发生变化。管理好风险，把工程做出节奏感风险管理是工程管理的重要组成局部。作为软件开发的技术人员，通常我们是相信技术的力量的，我们享受解决问题所带来的成就感。对于企业或者组织来讲，团队成员的这种成就感是最物美价廉的鼓励，它可以让工程成功的同时，让每个人都很快乐，让队伍快速成长。做好风险管理，可以让所有的团队成员清楚的看到，我们在什么时