壞钕
范文一：软件开发过程存在的风险
软件项目成果的需求分析方和软件项目的承担者都十分关心这样的一个问题：什么样的因素会导致软件项目的失败？与项目有关的因素的改变将对按时、按经费预算交付符合预定质量要求的软件成果产生什么样的影响？这些都属于软件项目开发过程中考虑的风险问题。
软件项目的风险是指在软件开发过程中可能出现的不确定因而造成损失或者影响，如资金短缺、项目进度延误、人员变更以及预算和进度等方面的问题。风险关注未来的事情，这意味着，软件风险涉及选择及选择本身包含的不确定性，软件开发过程及软件产品都要面临各种决策的选择。风险是介于确定性和不确定性之间的状态，是处于无知和完整知识之间的状态。另一方面，风险将涉及思想、观念、行为、地点等因素的改变。
软件项目风险会影响项目计划的实现，如果项目风险变成现实，就有可能影响项目的进度，增加项目的成本，甚至使软件项目不能实现。因此有必要对软件项目中的风险进行分析并采取相应的措施加以管理，尽可能减少风险造成的损失。风险是在项目开始之后才对项目的执行过程其负面的影响，所以软件项目开始之前风险分析的不足，或者是软件项目实施过程中风险应对措施不得力，都有可能造成软件失败。
如果对项目进行风险管理，就可以最大限度的减少风险的发生。它是为了将不确定因素出现的概率控制到最低，将不确定性所造成的损失减少到最低限度，对软件项目全过程中的风险识别、分析和应对的过程。在整个软件项目的实施过程中，可能形成项目风险的因素有很多，如在项目启动阶段可能存在项目目标不明确，与用户沟通少导致项目范围不明确等分先因素；在系统设计阶段可能因为缺乏有经验的分析人员、设计人员导致和设计的结果不能直接用于程序员的开发；在项目实施阶段可能因为开发环境没有准备好，程序员开发能力差，或者因为用户提出新的功能需求导致原有设计实效、开发费用超支，还有可能因为开发人员的流动导致项目延期，客户不满意等情况。
软件项目运用专家调查法和头脑风暴法分析软件开发项目中，并将其进行整理分类。
由于与客户沟通不畅对客户的需求了解不足造成的风险在软件开发项目整个生命周期的中都存在的风险，主要包括需求变更风险，涉及风险，过程风险，安装及维护风险。
由于管理人员素质不够，经验不足，沟通不畅，任务或其分配不合理，对项目的控制力度不够造成的各种风险，主要包括进度风险，预算风险，管理能力风险，信息安全风险。
由于技术力量不足，开发环境工具不足造成的。主要包括技术风险，质量风险，软件设计工具风险，软件开发工具风险，员工技能风险。
由于公司或项目组内外部环境变化所导致的风险，主要包括人力资源风险，政策风险，市场风险，营销风险。
软件项目中的风险永远不能全部消除，而只能采用避免、减轻、和接受三种因对策略。
避免：通过分析找出发生风险事件的原因，消除这些原因来避免一些特定风险事件的发生。
减轻：通过降低风险事件发生的概率或得失衡量来减轻风险对项目的影响，也可采用风险转移的方法来减轻风险对项目的影响。
接受：对于一些无法避免的风险，应当接收风险造成的后果或者提前设计相应的应对措施，但这需要一定的资金做后盾。
下面我们就以上四大类别中的一些主要风险进行具体分析以及提出应对策略。
需求变更风险
需求变更风险是指需求已经成为项目基准,但需求还在继续变化;需求定义欠佳,而进一步的定义会扩展项目范畴;添加额外的需求;产品定义含混的部分比预期需要更多的时间;在做需求中客户参与不够;缺少有效的需求变化管理过程。一个看似很有“钱途”的软件项目，往往由于无限度的需求变更而让项目承建方苦不堪言，甚至最终亏损（实际上项目建设方也面临巨大的风险）。
预防这种风险的办法是需要团队成员的高度配合和密切协作的阶段，在进行需求分析的时候要仔细分配团队成员的工作，具体分配如下：如项目经理负责需求分析阶段项目进度的安排和控制；参与项目的各种资源调度；负责项目的总体协调工作，人员组成为双方项目负责人。再如系统分析人员要通过与用户方的技术人员和业务人员进行良好的沟通，了解业务流程、功能需求、系统构想和项目目标，完成软件需求说明书的编制任务，等等。要求需求分析阶段的团队按照项目管理中典型的矩阵式结构来开展，这种结构能够有效的利用项目资源，减少条块分割的冲突，增加了沟通和协调的机会，降低了项目的执行成本，能够充分发挥项目经理和个分组人员的积极性，并通过采用一些激励机制，保证项目成员有充分的责任感和成就感。并且要有效的遏制需求变更，软件的需求变更时软件项目开发和实施的最大敌人，在软件项目的各个阶段都可能出现。需求变更的越晚，对项目造成的危害就越大。所以对软件的需求变更控制贯穿与软件实施的各个阶段。在需求分析阶段用户需求变更主要表现为用户需求的反复，容易使需求分析工作原地转圈，无法按计划完成需求分析工作。要遏制分析阶段的变更风险，采用以下几种方法：1、充分到位的需求调研。2、用户签字制度。签字的方法可以是用户在需求调研中积极负责的态度，认真对待每个需求分析项。在实际分析中，分析人员要善于与用户沟通，通过系统原型或相似系统演示等手段，消除用户的顾虑；另外，如果用户方代表个人难以决定，可通过召开项目协调会议，由用户的项目有关人员集体决定。3、定期的工作通报制度。即开发项目经理要定期将需求分析阶段的工作进展情况、存在的问题进行汇总，向项目双方的高层领导、项目管理委员会进行工作汇报。促使项目双方人员以积极协作的心态开展需求调研工作，减少变更，确定进度。4、对签字认可的需求纳入需求管理，对发生的需求变更，执行需求变更处理流程。另外，在该过程中，分析人员需要对所有需求项目分析项目进行分类管理，按照其重要程度及发现变更后造成的影响范围大小，将不同的需求项分别设置不同的优先级。在需求分析工作中，重点要解决好优先级别更高的需求项的调研及确认工作。可最大限度地降低需求变更发生的可能性，将变更造成的影响减小到最小。
进度风险
有些项目对进度要求非常苛刻（进度要求不高的项目，我们同样要考虑该风险），项目进度的延迟意味着违约或市场机会的错失。软件的工期常常是制约软
件项目的主要因素。软件项目工期估算是软件项目初期最困难的工作之一。很多情况下，软件用户对软件的需求是出于实际情况的压力，希望项目承担方尽快开发出软件来。在软件招标时，开发方为了尽可能争取到项目，对项目的进度承诺出已远远超出实际能做到的项目进度，使项目在开始时就存在严重的时间问题。软件开发组织在工期的压力下，往往放弃文档的编写与更新，结果在软件项目的晚期大量需要通过文档进行协调时，却拖累软件进度越来越慢。此外，由于用户配合问题、资源调配等问题也可能使软件项目不能在预定的时间内完成任务。软件项目过程中有自身的客观规律性，用户对软件项目的进度要求不能与软件开发过程的时间需要相矛盾。
因此，对于这种风险解决方案一般是分阶段交付产品、增加项目监控的频度和力度、多运用可行的办法保证工作质量避免返工。在项目实施的时间进度管理上，需要充分考虑各种潜在因素，适当留有余地；任务分解要详细，便于考核；在执行过程中，应该强调项目按照进度执行的重要项，再考虑任何问题时，都要经保持进度作为先决条件；同时，合理利用赶工期及快速跟进等方法，充分利用资源。乐观主义应受到慎重分析。在进度安排上适度悲观，在项目的实施中适度乐观，做到悲观并不消极，乐观并不大意。项目进行中盲目增加人员可能造成事倍功半的效果，所以任务、人力、时间三者之间存在最佳组合，值得项目负责人引起足够重视。应该避免：某方面的人员没有到位，或者在多个项目的情况下某方面的人员中途被抽到其他项目，或身兼多个项目，或在别的项目中无法抽身投入本项目。为系统测试安排足够的时间，能使项目进度在改变之初就被发现，这对及时调整项目进度至关重要。渐近明细是项目的特点，特别是对于软件开发项目，并不是一个一成不变的过程。开始时的项目计划可以先制定得比较粗一些，随着项目的进展，特别是需求明确以后，项目的计划就可以进一步的明确，这时候应该对项目计划进行调整修订，通过变更手续取得项目干系人的共识，在这个过程中发生错误是在所难免的，因此必要的测试是项目渐近明细的方式之一，随着项目的推进再进一步细化、调整、修正和完善。持续地监控，项目进度控制是随着项目的进行而不断进行的，是一个动态过程，也是一个循环进行的过程。从项目开始，实际进度就进入了进行轨迹，直到项目结束，这个过程的每一个环节都必须完全在监控之中。在计划制定时就要确定项目总进度目标与分进度目标；在项目进展的全过程中，进行计划进度与实际进度的比较，及时发现偏离，及时采取措施纠正或者预防，协调项目参与人员之间的进度关系。
预算风险
技术风险
在软件项目开发和建设的过程中，战略管理技术因素是一个非常重要的因素。项目组一定要本着项目的实际要求，选用合适、成熟的技术，千万不要无视项目的实际情况而选用一些虽然先进但并非项目所必须且自己又不熟悉的技术。如果项目所要求的技术项目成员不具备或掌握不够，则需要重点关注该风险因素。重大的技术风险包括：软件结构体系存在问题，使完成的软件产品未能实现项目预定目标；项目实施过程中才用全新技术，由于技术本身存在缺陷或对技术的在掌握不够深入，造成开发出的产品性能以及质量低劣。
预防这种风险的办法是选用项目所必须的技术、在技术应用之前，针对相关人员开展好技术培训工作。首先，做好各阶段的技术评审工作，通过集体智慧确保项目所采用技术的可行性以及技术方案的正确性。其次，对新技术的使用要谨慎，要循序渐进，尽量采用成熟的技术方案完成软件开发工作。再次，在技术创新与技术风险之间进行平衡，并做好创新技术的研究和试验工作。需要对软件项目过程中使用的各种技术进行评估，软件项目管理在制定软件开发计划时必须考虑这些因素，并作出合理的权衡决策。
质量风险
任何软件项目实施过程中缺乏质量标准，或者忽略软件质量监督环节都将对软件的开发构成巨大的风险。有些项目，用户对软件质量有很高的要求，如果项目组成员同类型项目的开发经验不足，则需要密切关注项目的质量风险。矫正质量低下的不可接受的产品,需要比预期更多的测试、设计和实现工作;开发额外的不需要的功能(镀金),延长了计划进度;严格要求与现有系统兼容,需要进行比预期更多的测试、设计和实现工作;要求与其他系统或不受本项目组控制的系统相连,导致无法预料的设计、实现和测试工作;在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题;开发一种全新的模块将比预期花费更长的时间;依赖正在开发中的技术将延长计划进度。
预防这种风险的办法一般是经常和用户交流工作成果、品牌管理采用符合要求的开发流程、认真组织对产出物的检查和评审、计划和组织严格的独立测试等。软件质量的保证体系是软件开发成为可控制过程的基础，也是开发商和用户进行交流的基础和依据。所以制定卓有成效的软件质量监督体系，是任何软件开发组织必不可少的。
工具风险
软件项目开发和实施过程，所必须用到的管理工具、开发工具、测试工具等是否能及时到位、到位的工具版本是否符合项目要求等，是项目组需要考虑的风险因素。有些软件项目属于多用户并发的应用系统，系统对性能要求很高，这时项目组就需要关注项目的性能风险。
预防这种风险的办法一般是在项目的启动阶段就落实好各项工具的来源或可能的替代工具，在这些工具需要使用之前（一般需要提前一个月左右）跟踪并落实工具的到位事宜。在进行项目开发之前先设计和搭建出系统的基础架构并进行性能测试，确保架构符合性能指标后再进行后续工作。并且团队成员的技术是偏向该种工具的。
人力资源风险
软件的开发不同于其他的工程，它是智力密集型、劳动密集型、项目，受人员资源的影响很大。软件的开发在不同的工程阶段，需要的人员不同，同样需要团队成员之间的密切配合。在人力资源使用过程中，人员能力的表现往往体现在软件成果监控的困难导致对人员能力观察的困难。人员流失、人员不能适合软件项目的要求，都可造成人力资源上的风险。人力资源的能力（包括业务能力和技术能力）和素质，对项目的进展、项目的质量具有很大的影响，项目经理在项目的建设过程需要实时关注该因素。
预防这种风险的办法是在用人之前先选对人、开展有针对性的培训、将合适的人安排到合适的岗位上。要降低项目的人力资源风险，就要保证参加项目的各
类人员能够胜任项目中所承担的工作。因此，实施双方应对参与人员进行认真地评估。这种评估是两个方面的，不仅是用户对开发方人员的评估，也包括开发方对参与项目的用户方成员的评估。同时，应保证项目人员对项目的投入程度。另外，项目经理要采取相应的措施维持开发队伍的稳定，将参与项目人员的业绩评估与项目实施的状况相联系，制定适当的奖惩措施。同时，项目经理也需要做好项目组人员变动的应对措施。开发人员的水平应该符合项目开发要求。技术上是应该和算选取的开发工具相配套。是能够自始至终地参加软件开发工作。是能够集中全部精力投入软件开发工作。并且员工对自己的工作有正确的期望。要接受过必要的培训。保证开发人员的流动保证工作的连续性。尽可能将项目的核心工作分派给多人（而不要集中在个别人身上）、加强同类型人才的培养和储备。
结论：
软件项目开发过程中面临的风险是多种多样的，风险的大小以及重点各不相同，项目管理人员应当充分考虑，认真分析，在考虑风险损失和合理的风险应对成本之后，选择采用合适的风险应对计划，避免因风险造成各方面的重大损失。
如何进行风险控制
识别和分析风险并不是软件风险管理的最终目标。针对所发现的每一个软件风险，尤其是高危险度的软件风险，风险管理还需要对它们进行有效的控制，包括：（1） 制定风险管理计划：针对各个重要风险制定风险管理计划，并确保它们的一致性；（2）化解风险：执行风险管理计划，以缓解或消除风险；（3）监控风险：监控风险化解的过程。
n 制定风险管理计划
针对每一个重要的软件风险，制定相应的处理该软件风险的计划。风险管理计划主要描述有关软件风险处理的以下内容-
软件风险名称
- 软件风险由谁引起
- 软件风险的表现形式是什么
- 软件风险可能什么时候发生
- 为什么会发生该软件风险
- 如何避免或者消除软件风险的发生
- 软件风险发生后的处理措施
n 风险化解方式
执行风险管理计划，以缓解或消除风险。一般地，软件风险化解有以下几种方式。
- 避免风险
采取主动和积极的措施来规避软件风险，将软件风险发生的概率控制为零。例如针对用户可能没有时间参加需求评审这一软件风险，项目组可以考虑选择用户方便的时间来进行需求评审，这样“用户不能出席需求评审会”这一软件风险就不会发生。
- 转移风险
将可能或者潜在的软件风险转移给其它的单位或个人，从而使得自己不再承担该软件风险。例如如果开发某个子系统存在技术和人力资源方面的风险，可以考虑将它外包给其它软件开发公司，从而将该软件风险从项目中转移出去。
- 消除发生软件风险的根源
如果知道导致软件风险发生的因素，那么针对这些因素，采取手段消除软件风险发生的根源。例如如果发现导致小刘离开项目组的主要原因是薪酬太低，那么可以通过给小刘增加薪酬来消除发生软件风险的根源。
n 风险监控
在风险评估和控制过程中，项目组人员和负责人必须对软件风险的化解程度及其变化（如发生概率、可能导致的损失和危险度）进行检查和监控，并对收集到的有关软件风险信息进行记录，以促进对软件风险的持续管理。
风险监控的主要内容包括：监控和跟踪重要软件风险，记录这些软件风险危险度的变化以及软件风险化解的进展，确认软件风险是否已经得到化解和消除，是否有新的软件风险发生等等。
范文二：软件开发的风险管理
论软件开发的风险管理
摘要
本文讨论了某公司实施SAP 系统的风险管理．该公司原先运行着一套ERP 系统，现在要转到SAP 上，需要完成新系统的流程的重新定义，数据的切换，用户的培训等工作．项目要求在11个月的时间内完成．实施一个大型的ERP 系统有着各种的风险，这些风险如果不加分析和控制，将会给整个项目造成致命的影响．本人作为项目经理，主要从控制进度风险，人员流动风险和系统功能风险三个方面去进行风险的管理．最后这三方面的风险都得到了有效的控制，从而使项目顺利完成．
正文
2003年1月，本人参与了西门子集团下某公司的SAP 留系统的实施，提任项目经理．该公司之前运行着另一套ERP 软件：QAD 的MFG/PRO系统．由于集团总部的要求，要用SAP 系统替换原先的MFG/PRO系统，并且要在2003年11月前完成．整个项目完成以下阶段，首先是项目的引进，包括成立项目小组，由顾问对项目小组成员进行初步的培训，让小组成员对SAP 的标准流程有个大概的认识．接下来是要分模块进行讨论，制定出各模块的实施蓝图 1
范文三：软件开发的需求风险分析
软件开发的需求风险分析 摘要：随着软件开发技术的不断更新、软件数量的不断增多、软件复杂程度不断加大、客户对产品的要求也在不断的提高，随之而来的是市场对软件开发项目需求的不断变化，这便给软件开发企业和需求企业带来的巨大风险。市场对软件开发项目的需求会直接影响到公司的生存。这对软件开发企业来讲应该是更大的难题。本文通过对当前软件行业的需求风险状况进行分析，列举软件开发项目的需求风险来源，并进行分析，总结需求风险产生的原因和对项目成败的影响，最后给出软件开发项目在需求风险管理和控制方面的建议。 关键字：软件开发 需求风险 风险分析
一、对需求风险的理解
产品开发过程中，由于产品需求本身的隐含性、用户与开发者之间的沟通障碍，以及需求随着时间、用户的变化而变更等原因，可能使需求分析偏离实际需求而最终导致产品开发的失败，这种可能性称为需求风险。软件开发项目风险是指在软件生命周期中所遇到的所有的预算、进度和控制等各方面的问题，以及由这些问题而产生的对软件项目的影响。需求分析是软件开发过程中最初始、最基础的工作，也是最重要的工作之一，其成败将直接并最终决定软件开发的成败，并且呈倍增效应。需求分析的关键是使隐含的需求明确，使变更的需求可控，采用座谈会、需求调查表、需求启发、角色扮演等方法可以使需求明确化；采用面向对象的方法及UML 工具、领域专家的全程参与、需求分级、二次开发接口等方法可以使需求变更处于可控范围内。实践证明，这些都是控制需求风险的有效方法。
二、需求的获取
（一） 产品前景和项目范围
应该在软件开发项目早期，编写一份包括业务需求在内的前景和范围文档，并将它作为添加新需求和修改现有需求的指导。
（二）需求开发所需的时间
将每个软件开发项目中需求开发所耗费的实际工作量记录下来，这样就可以判断出需求开发是否充分，并可以改进未来项目的工作计划。
（三）需求规格说明的完整性和正确性
为了确保需求是客户真正需要的，应该以用户任务为中心，应用用例技术来获取需求。
（四）创新产品的需求
对软件开发项目中的第1个产品，不太容易把握市场对软件产品的反映。
（五）定义非功能需求
由于我们一般都会强调产品的功能，所以很容易忽略产品的非功能性需求。
（六）客户对产品需求意见一致
确定那些主要的客户，并采用产品代言人的方法，保证有足够的客户代表的积极参与
（七）未加说明的需求
一般的客户会有一些隐含的期望要求，但并未以文档的方式说明出来。尽量识别客户可能做出的任何假设。
（八）把已有的产品作为需求基线来源
把通过逆向工程发现的需求编成文档，让客户来评审这些需求，确保其正确性和相关性。
（九）根据需要提出解决方案
软件产品分析人员必须提炼出隐藏在客户提出的解决方案背后的真正意图。
三、需求风险的来源
软件项目风险经常会涉及许多方面，如：缺乏用户的参与，缺少高级管理层的支持，含糊的要求，没有计划和管理等，这里我们主要分析需求的风险。
很多开发项目在确定需求时都面临着一些不确定性。当在开发项目早期容忍了这些不确定性，并且在项目进展过程当中得不到解决，这些问题就能对项目的成功造成非常大的威胁。如果不控制与需求相关的风险因素，就很有可能产生错误的软件产品或者拙劣地建造预期的软件产品。每一种情况对产品来讲都可能致命的。
需求风险的来源包括：没有足够用户参与、不断增加的用户需求 、模棱两可的市场需求 、不必要的特性、过于精简的规格说明 、被忽略的用户分类 、不准确的产品开发计划 。 软件开发项目风险中与客户相关的风险因素有：(一) 对软件产品缺少清晰的认识，(二) 对产品需求缺少认同，(三) 开发者在做需求调查中客户参与不够，(四) 市场中没有优先需求，
(五) 不确定的需要导致出现新的市场，(六) 不断变化市场需求，(七) 缺少有效的需求变化管理过程，(八) 对需求的变化缺少相关分析等。
四、需求风险的管理
软件开发项目管理人员可以运用对风险管理来提高对造成项目损失的条件的警惕，在市场需求获取阶段要有用户的积极参与。精明的产品开发管理者不但能认识到它能带来风险的条件，而且将它编入风险清单，并依据以往产品开发项目的经验估计其可能性和影响。如果用户一直没有参与，风险危害值将会扩大以至危害项目的成功。即使不能控制项目可能遇到的所有风险，风险管理也能使软件开发项目管理者看清形势，做出的决策是有所依据。
(一) 制定风险管理计划
对于一个软件开发项目，你可以把控制风险的计划放在软件项目管理计划里面。但是一个大项目则需要有一份独立的风险管理计划，包括用于识别、评估、编写、跟踪产品开发风险的各种方法与途径。这份计划还应包括风险管理活动的角色和责任。通常情况下，项目小组为他们的关键活动制定了计划，但是在项目中并没有按计划去实施或者没能按实际情况进行及时的调整。一定要坚持按照所采取的风险管理活动计划去执行。项目的进度安排上也应该要给风险管理留出足够时间来确保项目并未浪费早期投资在风险计划制定上面。工程项目的工作分类细目结构中包括降低风险的活动、状态报告，与更新风险清单。和其它项目管理活动一样，需要建立起周期性的监控措施。保持对十来个有最大危害的风险的高度重视，并追踪降低风险措施的有效性。当完成一项活动后，重新评估那项风险的可能性和影响，更新风险清单和其它相关的计划。当控制住原本有很高优先级的风险后，必然有新条目会进入前十条。值得注意的是，不要仅仅因为完成了一项降低风险的活动而人为增加一条风险来进行控制。应当想想降低风险的方法是否真的减少了风险的危害，使它减少到了一个可以接受的水平。
周期性地进行需求风险跟踪可以使项目经理了解风险对软件产品开发项目的威胁，没有得到有效控制的需求风险应该上报高层管理人员，他们可能开始采取一些纠正措施，也可能不管风险，依旧按照原来的业务决策思路进行。即使不能控制项目可能遇到的所有风险，风险管理也能帮助我们看清形势，做出合理的决策。
（二）具体管理措施
1、首先要明确你当前软件开发项目面临的一些与需求有关的风险，不要把当前的问题当作风险，一定要是那些还未发生的事情。将风险的因素编写成文档，为每项需求风险推荐至少一种可能的降低风险的方法。
2、召集代表开发、市场、客户和管理各方面的涉众召开风险“集体研讨”会议。尽力找出更多与需求有关的风险因素。估计每项风险发生的可能性及其影响，两者乘积就是风险危害值。通过按风险危害值降序排列找到最高的五项风险。为每项风险安排一个负责人负责实施
降低风险的活动。
五、结束语
软件开发项目中的需求风险是所有风险中的一个不可忽视的组成部分，对其认识的必要性不言而喻，应该重视对它的分析，对需求风险的合理管理也是软件开发项目项目管理中不可或缺的部分。
参考文献：
[1]黄国光，周勇. 软件需求工程, 清华大学出版社,2008.(5).
[2]陶履彬. 工程风险分析理论与实践，同济大学出版社,2006.(12).
范文四：软件开发项目的风险管理过程
软件开发项目的风险管理过程
风险管理过程
软件风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。风险的最大特征是不确定性，也就是说它可能发生，也可能不发生。
风险管理在项目管理中有非常重要的地位：
· 有效的风险管理可以提高项目的成功率。在项目早期就应该进行必要的风险分析，并通过规避风险降低失败概率，避免返工造成成本上升。
· 提前对风险制定对策，就可以在风险发生时迅速作出反应，避免忙中出错造成更大损失。 · 风险管理可以增加团队的健壮性。与团队成员一起做风险分析可以让大家对困难有充分估计，对各种意外有心理准备，不至受挫后士气低落；而项目经理如果心中有数就可以在发生意外时从容应对，大大提高组员的信心从而稳定队伍。
· 有效的风险管理可以帮助项目经理抓住工作重点，将主要精力集中于重大风险，将工作方式从被动救火转变为主动防范。 风险管理可以简单分成五个步骤：风险识别、风险分析、风险计划、风险跟踪、和风险应对。如下图所示：
***识别风险和分析风险包含了评估风险所需的活动。计划风险、跟踪风险和应对风险包含了控制风险所需的实践。
一、风险识别
风险识别过程的活动是将不确定性转变为明确的风险陈述。包括下面几项，他们在执行时可能是重复，也可能是同时进行的：
1、 进行风险评估。在项目的初期，以及主要的转折点或重要的项目变更发生时进行。这些变
更通常指成本、进度、范围或人员等方面的变更。
2、 系统地识别风险。采用下列三种简单的方法识别风险：风险检查表，定期会议（周例会上），日常输入（每天晨会上）。
3、 将已知风险编写为文档。通过编写风险陈述和详细说明相关的风险背景来记录已知风险，相应的风险背景包括风险问题的何事、何时、何地、如何及原因。
4、 交流已知风险。同时以口头和书面方式交流已知风险。在大家都参加的会议上交流已知风险，同时将识别出来的风险详细记录到文档中，以便他人查阅。
二、风险分析
风险分析过程的活动是将风险陈述转变为按优先顺序排列的风险列表。包括以下活动：
1、 确定风险的驱动因素。为了很好地消除软件风险，项目管理者需要标识影响软件风险因素的风险驱动因子，这些因素包括性能、成本、支持和进度。
2、 分析风险来源。风险来源是引起风险的根本原因。
3、 预测风险影响。如果风险发生，就将可能性和后果来评估风险影响。可能性被定义为大于0而小于100，分为5个等级（1、2、3、4、5）。将后果分为4个等级（低，中等，高，关键的）。
其风险严重程度等于1，优先级别最低的风险，其风险严重程度等于20。对级别高的风险优先处理。
三、风险计划
风险计划过程的活动是将按优先级排列的风险列表转变为风险应对计划。包括以下内容：
1、 制定风险应对策略。风险应对策略有接受、避免、保护、减少、研究、储备和转移几种方式。
2、 制定风险行动步骤。风险行动步骤详细说明了所选择的风险应对途径。它将详细描述处理风险的步骤。
四、风险跟踪
风险跟踪过程的活动包括监视风险状态以及发出通知启动风险应对行动。包括以下内容：
1、 比较阈值和状态。通过项目控制面板来获取。如果指标的值在可接受标准之外，则表明出现了不可接受的情况。
2、 对启动风险进行及时通告。对要启动的风险，在每天的晨会上通报给全组人员，并安排负责人进行处理。
3、 定期通报风险的情况。在定期的会议上通告相关人员目前的主要风险以及他们的状态。
五、风险应对
风险应对过程的活动是执行风险行动计划，以求将风险降至可接受程度。包括以下内容：
1、 对触发事件的通知作出反应。得到授权的个人必须对触发事件作出反应。适当的反应包括回顾当前现实以及更新行动时间框架，并分派风险行动计划。
2、 执行风险行动计划。应对风险应该按照书面的风险行动计划进行。
3、 对照计划，报告进展。确定和交流对照原计划所取得的进展。定期报告风险状态，加强小组内部交流。小组必须定期回顾风险状态。
4、 校正偏离计划的情况。有时结果不能令人满意，就必须换用其他途径。将校正的相关内容记录下来。
相关准则和规定
1 可能性评估准则
4 风险的驱动因素
风险因素是以如下的方式定义的：
1、 性能风险——产品能够满足需求且符合于其使用目的的不确定的程度。
2、 成本风险——项目预算能够被维持的不确定的程度。
3、 支持风险——软件易于纠错、适应及增强的不确定的程度。
4、 进度风险——项目进度能够被维持且产品能按时交付的不确定的程度。
过程工具
以下介绍的过程工具，只给出了工程描述。大家可根据自己公司的实际情况进行修改，并定制出适合自己的工具进行使用。
1 风险数据库
风险数据库是用来记录风险，跟踪风险处理过程，并能够对风险进行简单查询和统计的风险管理工具。
一般内容：
包括项目的一般信息（如名称），和在本项目中风险处理采用的一些标准和规定等。
1、 项目名称
2、 可能性评估准则（1，2，3，4，5）
3、 后果评估准则（低，中等，高，关键的）
4、 时间框架准则（短，中等，长）
5、 风险应对策略（风险应对策略用接受、避免、保护、减少、研究、储备和转移）
6、 风险的状态（Watch，Execute Contingency，Mitigate，Transfer，Avoid，Retired ）
7、 风险驱动因素的类别（性能，成本，技术，进度）
风险记录的内容：
风险的内容是在风险处理的不同阶段不断添加进去的，如在风险计划阶段填写应对策略和行动步骤两列。
1、 编号
2、 识别日期
3、 识别者姓名
4、 风险类别（产品规模、商业影响、客户特性、过程定义、开发环境、技术难题、人员数目及经验）
5、 风险标题
6、 风险评估
a. 风险背景
b. 驱动因素（性能，成本，技术，进度）
c. 风险来源
d. 可能性（1、2、3、4、5）
e. 后果（低、中等、高、关键的）
f. 时间框架（短、中等、长）
g. 风险影响（1、2、3、4、5、6、7、8、9、10、11、12、13、14、15、16、17、18、19、20）
7、 风险计划
a. 应对策略（风险应对策略用接受、避免、保护、减少、研究、储备和转移）
b. 行动步骤
8、 风险跟踪
a. 风险的状态（Watch，Execute Contingency，Mitigate，Transfer，Avoid，Retired ） b. 批注
9、 风险应对
a. 负责人
b. 完成日期
c. 批注
辅助的管理功能：
1、 查看所有风险的状态（风险矩阵）
2、 对所有的当前风险进行优先排序
3、 已结束风险的备案
2 项目控制面板
项目控制面板可用作自动项目跟踪工具。将项目的各方面的数据（如需求变更数量，Bug数量等）录入对应的表格，即可自动得到当前关键指标的状态（是否处于正常的范围之内）。关键的项目指标包括：项目的进度，工作的效率，需求的变化，配置项的变化，人员的流动，不同阶段的缺陷数目，加班时间等。如果我们给每个指标一个可接受的阈值，当超过这个阈值时，系统便会自动给出警告。
控制面板的首页面是一系列的度量仪表，仪表上的指示将随着你输入的项目信息计算迩来。每个仪表分为两部分，白色的安全区和红色的警告区。如果指针处于红色区域，则说明有不可接受的情况发生。除此之外，当你单击每个仪表或图表时，会自动联接并切换到对应的更详细的分析图表中。
3 风险检查表
该检查表可以用来识别风险，并可以集中来识别下列常见子类型中已知的及可预测的风险：
1、 产品规模——与要建造或要修改的软件的总体规模相关的风险。
2、 商业影响——与管理或市场所加诸的约束相关的风险。
3、 客户特性——与客户的素质以及开发者和客户定期通信的能力相关的风险。
4、 过程定义——与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。
5、 开发环境——与用以建造产品的工具的可用性及质量相关的风险。
6、 技术难题——与待开发软件的复杂性以及系统所采用的新技术相关的风险。
7、 人员数目及经验——与参与工作的软件工程师的总体技术水平及项目经验相关的风险。
范文五：软件开发项目的风险管理
软件开发项目的风险管理
作/转载者：李艺兰 发布时间：2003-4-2 浏览量：729
1月27日参加了项目管理联盟组织的‘北京项目管理爱好者聚会’，我被易风邀请做了一个主题演讲，其实不是什么演讲，只是结合理论谈了自己的一些想法和工作中遇到过的经验教训，更主要的目的是给大家出一个讨论和交流的主题，希望能起个抛砖引玉的作用。
我讲的主题是：软件开发项目的风险管理，因为我认为风险管理在软件项目中很重要，又不容易做好，所以希望通过和大家讨论能够有一些思路和启发。
现在把我准备的内容整理帖出来，希望在这里继续讨论，大家在如下几方面多展开讨论：
1． 在软件项目管理中如何做好风险防范
2． 软件项目中的典型风险事件是哪些
软件开发项目的风险管理
众所周知，软件开发过程可分为：需求分析、设计、编码、测试、安装及维护等几个过程（在RUP方法中：业务建模、需求、分析设计、实施、测试、部署），实际上一个完整的软件项目前后还有其它过程，在这里列出的只是和软件开发相关的核心过程。
软件项目的生命周期可以分为四个阶段（不同行业的项目生命周期不同），即初始阶段、设计阶段、实施阶段、收尾阶段。软件开发过程在软件项目的这四个阶段中的分布情况如下（括弧里面表示RUP方法中的过程）：
初始阶段：大部分需求分析，少部分设计（大部分业务建模和需求，少部分分析设计）
设计阶段：大部分设计，少部分编码（大部分分析设计，部分实施及测试，开始考虑部署）
实施阶段：大部分编码和测试，少部分设计（大部分实施及测试，部分部署）
收尾阶段：安装及维护（大部分部署）
而项目管理则贯穿在整个生命周期的每个阶段。
根据PMBOK，项目管理可以从范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理等9个方面考虑，对于软件项目管理来讲软件配置管理（属于整体管理）、软件质量管理、软件风险管理及开发人员管理（属于人力资源管理）等四个方面的管理尤为重要，软件开发的每个阶段、每个过程都要重视这几方面的管理。
下面就以软件项目的风险管理为主题展开讨论。
软件项目管理的四个阶段中，在初始阶段项目成功的可能性最小，风险发生的概率也就最高，但是这时候一旦预计的风险发生了，损失是最小的，比如：在这个阶段如果某种原因突然资金来源断了（这在需求阶段是很有可能的），以至于不能继续进行项目，不得不终止项目，那么这时候的损失只是需求分析阶段的投入。随着项目的进
展项目成功的可能性变大，风险发生的概率逐渐变小，风险对项目的损失逐渐变大，快到收尾阶段的时候风险对项目的损失最大，随着收尾阶段的进行风险又逐渐变小。
风险管理是对项目风险进行识别、分析和应对的过程。我们先看看项目风险可以怎么分类，然后再对风险管理的这三个过程逐一进行讨论。
1．风险的分类
按内容分
范围风险：与范围变更有关的风险
质量风险：没有按照要求的技术性能和质量水平完成任务
进度风险：没有在预算的时间范围内完成任务
成本风险：没有在预算的成本范围内完成任务
技术风险：技术变化
法律风险：许可权、专利、合同失效、诉讼、不可抗力
外部可预测风险：市场风险（原材料可利用性、需求）、日常运作（维修需求）、环境影响、社会影响、货币变动、通货膨胀、税收
外部可预测风险：规章（不可预测的政府干预）、自然灾害
内部非技术风险：战略风险（公司的经营战略发生了变化）、管理风险（公司管理人员是否成熟等）
按可确定性分
已知风险（Knowns）：员工离职
已知-未知风险（Known-unknowns）：可预知风险
未知-未知风险（Unknown-unknowns）：不可预知风险
2．风险识别
风险的识别就是确定何种风险事件可能影响项目。在项目开始、每个项目阶段中间、主要范围变更批准之前都要进行风险识别，实际上它在整个项目生命周期内都是一个连续的过程。
要识别风险，首先我们应该了解在软件开发的各个阶段都有可能发生哪些风险（风险事件或风险来源）。
初始阶段
在这个阶段进行大部分需求分析、少部分设计（大部分业务建模和需求、少部分分析设计）。
可能的风险事件：
l 项目目标不清
l 项目范围不明确（范围太大太小都不可以）
l 用户参与少或和用户沟通少
l 对业务了解不够
l 对需求了解不够
l 没有进行可行性研究
设计阶段
在这个阶段进行大部分设计、少部分编码（大部分分析设计，部分实施及测试，开始考虑部署）
可能的风险事件
l 项目队伍缺乏经验，如缺乏有经验的系统分析员
l 没有变更控制计划，以至于变更没有依据，该变更的不变，不该变的也变，这样得来的设计势必会失败或者偏离用户需求
l 仓促计划，可能带来进度方面的风险
l 漏项，由于设计人员的疏忽某个功能没有考虑进去
实施阶段
在这个阶段进行大部分编码和测试，也涉及少部分设计（大部分实施及测试，部分部署），如：设计变更或补充设计。
可能的风险事件
l 开发环境没有具备好
l 设计错误带来的实施困难
l 程序员开发能力差，或程序员对开发工具不熟
l 项目范围改
变（突然要增加或修改一些功能，需要重新考虑设计）
l 项目进度改变（要求提前完成任务等）
l 人员离开，在一个项目内软件开发工作有一定的连续性，需要移交和交接，有时人员离开对项目的影响会很大
l 开发团队内部沟通不够，导致程序员对系统设计的理解上有偏差
l 没有有效的备份方案
l 没有切实可行的测试计划
l 测试人员经验不足
收尾阶段
在这个阶段进行安装及维护（大部分部署）。
可能的风险事件
l 质量差
l 客户不满意
l 设备没有按时到货
l 资金不能回收
以上只是例具了常见的风险事件，对不同项目可能发生的风险事件不同，应该对具体项目识别出真正有可能发生在该项目的风险事件。而且还要对这些风险事件进行描述，如：可能性、可能后果范围、预计发生时间、发生频率等。
风险识别的有效方法有很多，如：建立风险项目检查表、因果分析图、采访各种项目干系人等。
软件项目的风险可以从以下几方面检查：
产品规模风险
业务影响风险检
与客户相关的风险
过程风险
技术风险
开发环境风险
与人员的模式和经验有关的风险
以上我们讨论了在软件项目各个阶段中可能发生的风险事件和识别方法。下面我们看看如何对这些风险事件进行分析。
3．风险分析
风险分析就是对以上识别出来的风险事件做风险影响分析。
和风险相关的有四个因素：
风险事件，破坏或影响项目的事件
风险概率（%），事件发生的可能性
风险得失量（金额），说明可能造成的损失
风险影响（金额），等于 风险概率 × 风险得失量
通过对风险及风险的相互作用的估算来评价项目可能结果的范围，从成本、进度及性能三个方面对风险进行评价，确定哪些风险事件或来源可以避免，哪些可以忽略不考虑（包括可以承受），哪些要采取应对措施。
4．风险应对
1、应对方法
项目中的风险永远不能全部消除，PMBOK提到三种应对方法：
避免
通过分析找出来发生风险事件的原因，消除这些原因来避免一些特定的风险事件发生。
比如：
如何避免客户不满意？
客户不满意有两种情况，一种情况是没有判断客户满意度的依据，即没有双方互相认可的客户验收标准，还有一种是开发方没有达到验收标准，即没有满足用户需求。不管是哪一种，开发方都有不可推卸的责任，只要做好以下环节完全可以避免：
l 业务建模阶段要让客户参与
l 需求阶段要多和客户沟通，了解客户真正的需求
l 目标系统的模型或DEMO系统要向客户演示，并得到反馈意见，如果反馈的意见和DEMO系统出入比较大时，一定要将修改后的DEMO系统在次向客户演示
，直到双方都达成共识为止
l 要有双方认可的验收方案和验收标准
l 做好变更控制和配置管理
减轻
通过降低风险事件发生的概率或得失量来减轻对项目的影响。也可以采用风险转移的方法来减轻风险对项目带来的影响。项目预算中考虑应急储备金是另一种降低风险影响的方法。
比如：
经过风险识别发现，项目组的程序员对所需开发技术不熟。可以采用熟悉的技术来减轻项目在成本或进度方面的影响。也可以事先进行培训来减轻对项目的影响。
接受
接收风险造成的后果。
比如：
为了避免自然灾害造成的后果，在一个大的软件项目中考虑了异地备份中心。
2、开发应对计划
针对需要采取应对措施的风险事件，开发应对计划，一旦发生风险事件，就实施应对计划。
比如：
有一个软件集成项目中包括了设备，而且计划在部署阶段之前设备必须到位，而这些设备从厂家直接进货。经过分析发现有可能不能按时进货，那就应该考虑备选方案，比如能不能周转等。
又比如：
在一个软件开发项目中，某开发人员有可能离职，离职后会对项目造成一定的影响，则应该对这个风险事件开发应对计划，过程可以参照如下：
l 进行调研，确定流动原因
l 在项目开始前，把缓解这些流动原因的工作列入风险管理计划
l 项目开始时，做好计划一旦人员离开时便可执行，以确保人员离开后项目仍能继续进行
l 制定文档标准，并建立一种机制，保证文档及时产生
l 对所有工作进行细微详审，使更多人能够按计划进度完成自己的工作
l 对每个关键性技术人员培养后备人员
在考虑风险成本之后，决定是否采用上述策略。
以上仅供大家参考，有什么不恰当的地方望大家多提出来。
转载请注明出处范文大全网 » 软件开发过程存在的风险
