软件项目风险研究（共5则范文）

第一篇：软件项目风险研究（共）

软件项目风险研究

摘要： 阐述了软件项目风险的概念和风险定义，并且分析了在软件项目中的风险类型，最后根据风险的定义和类型，分析出相应的风险避免措施。

关键词：风险的概念；风险定义；风险类型；避免措施；

The Analysis Of Software Project Risk

WengHuaBin 10703080227

（ChongQing University Of Technology-Software Engineering）

Abstract: Describes the concept and definitions of software project risk ,And analyzed the types of software projects risk ,Finally, according to the definition and types of Software project risk analysis to avoid the risk of the corresponding measures.Key words: The concept of risk;The definition of risk;The risk types;The avoid measures;

软件行业在社会各界（包括政府、教育机构以及各个企业）的日益剧增的信息化需求下，已经成为高速信息化建设中必不可少的一个元素。所以软件行业要不断的提高稳定程度和运行效率，然而软件项目本身就是一个高风险的项目类型，任何项目都是存在一定的风险性，软件项目更是不例外，所以软件项目需要更好的风险避免措施，只有做到更好更科学的防御措施，才能在最大程度上降低软件项目成本和提高软件项目的成功率。再者，国内外的一些成功的软件项目案例告诉我们，软件项目风险分析是一个相当重要不容忽视的环节，只有做好了软件项目风险分析才能致使软件项目成功地进行，得到用户满意的软件，这也是众多软件公司的最终目的，所以科学的风险分析和必备的防御措施是一个好的软件项目的先决条件。软件项目风险概念

首先，我们知道任何项目都是有一定的不确定性和风险性，然而，软件项目是一个风险 比较大的项目种类，所以总而言之，零风险的项目基本上是不存在，项目中的风险分为多种类型的，只是我们在遇到风险的多少、大小以及严重程度是不同的。

再者，我们分析一下，在软件项目中，我们一般遇到的软件项目风险是怎么样的。在软件项目风险分析中，基本上所有的软件项目管理者都会很大程度上地关注软件项目的进展程度、完成情况以及对成本的控制等等，但是我们必须不可以忽视的问题是我们在项目进行当中遇到的风险，这些风险虽然一时半会可能会隐藏于软件开发中，但是一旦这些问题暴露出来，就会给软件项目带来不可挽回的灾难，任何一个技术人员、管理人员的一个失误或者软件开发中的任何一个负面的因素都有可能成为软件项目成功的威胁，所以我们不能忽视任何的失误，更不能忽视任何一个可能的风险。然后在我们的软件项目中，有可能就是因为一种侥幸的心理往往让我们得不偿失，因为风险本来就是一个不及时出现而又可能本质存在的客观因素，所以我们说它是一种潜在的风险，但是当它真正威胁到我们的时候，也就是我们发现风险存在的时候，这个时候它已经给我们带来了很大的麻烦，并且严重的有可能是不能挽回的损失，所以作为一个软件项目技术人员或者管理人员，我们都应该及时的关注软件的发

展进度，并且的不断的尝试有可能出现的风险的分析。

所以，我们要对软件项目进行规划来查找可能的风险，这样软件项目的期望值才会由低变高，进行了风险分析，这样软件项目的成功率也会大大提高，根据成功软件项目的经验和失败软件项目的教训，我们得知成功的软件项目都必须采取积极的步骤对要发生或者有可能存在的风险进行分析，从而才可能采取有效的措施避免软件项目的失败。软件项目风险定义

风险是潜在的对软件项目的威胁，未来可能发生损失的一种度量，当然也有可能不发生，但是一旦这种危险出现了，就会对软件项目带来很大甚至不可估量的损失，也是对公司的一种负面消极影响。软件项目风险是是未来的一种关注，本来风险就是不确定性的，所以这种潜在的危险就给开发过程中带来了各种决策的选择，另，风险还和人为因素（例如思想、行为）和环境因素（例如时间、地点）有关，等等这些因素都会导致软件项目的风险，所以在对软件项目进行分析的时候这些因素都是不容忽视的。

软件项目风险一旦出现就会影响软件的开发进度、成本，这些都可能导致最后的软件项目的失败，这些都应该是软件项目组所关心的重点。在软件项目的开发过程中，我们都知道现在软件行业的技术是日新月异的，所以必然会用到一些新技术，以及我们的人力方面，这些都是影响项目开发的主要因素，然而正是这些因素的复杂性，也就造就了软件项目风险的复杂性，这些因素本身就是不确定的，当我们面对这些复杂的未知数时，要进行科学的分析得出更加合理的答案，才能使软件项目不断地向成功的方向发展，并且对软件开发做出一个正确的引导，反而言之，项目损失带来的将是项目的无法如期完成或者大量的超出成本预算，这些都将给企业带来直接的损失和消极的影响，所以我们在这里可以定位软件项目风险的重要性。

综合上述的分析，我们可以总结出风险的几个要素，风险首先是一个不确定的风险因素，然后会导致一个风险事件，这样带来的结果就是直接的损失，这样开发出来的软件就和企业以及客户的预期值相差太远，最后就有了风险结果，我们可以用一个图来表示这个风险描述：软件项目风险类型

软件项目风险的类型可以从不同角度进行分类，以下就范围角度和预测角度进行风险类 型的分析：

从范围角度，风险主要分为：商业风险、管理风险、人员风险、技术风险、开发环境风险、客户风险、过程风险和产品规模风险等等。

1）商业风险：是指与管理或市场所加诸的约束相关的风险，主要包括市场风险、策略风险、管理风险和预算风险等；

2）管理风险：是指在项目开发进程中，对潜在的人力和物力以及相关资源的管理风险，这

其中包括对时间、技术人员和项目相关资源的分配不合理，还有对项目计划实施没有做到足够好的预期安排等；

3）人员风险：人员风险主要是指在开发和实施的过程中技术人员自己的相关因素，其中主

要包括技术人员自身的不稳定性和错误判断，还有包括项目参与人员的经验不够丰富以至于做出错误的决定，这些都会影响项目的质量；

4）技术风险：是指在不断更新的软件开发技术中，会有某些不稳定的技术的参与，或者与

正在进行的项目不兼容的现象等等，所以在做技术风险分析的时候，我们先要对技术的稳定性和兼容性进行准确的测试，这样才能给软件项目进行准备的技术定位；

5）开发环境风险：主要是指开发环境以及工具可能会对项目造成的风险；

6）客户风险：在软件项目开发中，我们可以很明确的感觉到用户的需求的确定是一件具有

一定复杂性的工作，这样往往在我们的开发过程中，可能是因为客户的理解的差异造成客户修改需求的风险，这样的风险是最常见的，我们不能随时的变更需求，但是客户又必须要求更改需求的时候，这时候我们的客户风险就大大的出现在软件项目中了，所以为了避免这种风险或者减小这种风险发生的可能性，所以我们在分析客户需求的时候就要尽量想到以后可能会出现的风险；

7）产品风险：产品风险主要是指在产品成型之后，所出现的产品质量与客户或者开发人员

自己所预期的不相符合的情况；

8）过程风险：过程风险是与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险；

从预测角度分析风险类型：

1）已知风险：在软件开发过程中，已经知道的风险是通过评估项目计划、开发项目的商业

及技术环境以及其他的可靠的信息来源而得来的；

2）可预测风险：这种风险类型是通过以往的项目经验来进行预测的风险类型；

3）不可预测风险：不可预测的风险往往是隐藏在项目开发过程中，这种风险是很难在其中

得知的，但是这种风险出现几率就没有那么大了，所以一个强大的企业需要有能够承担这种风险的能力；软件项目风险避免措施

当我们了解了风险的概念、定义以及类型以后，就应该根据风险的一些特性制定出相应 的避免措施。

在软件开发的初级阶段，最重要的工作当然是需求分析，当然这个里面包含了风险分析，做一个好的风险分析就等于为软件项目的成功打下了坚实的基础。首先，我们在需求分析的时候，必须要深刻的了解客户的使用情况，要深入到企业或者试用人员的周围调研用户需求，这样得到的需求才是真正的用户需求，如果我们只是一味的听从客户所描述的需求来定义软件需求的话，那么我们就大错特错了，在一般情况下，用户描述需求都不能全面的或者专业的转达他们理解下的需求，所以软件项目人员必须自己做好需求调研工作，这是一个至关重要的阶段，做好了这个阶段，也就减小了后续开发中的风险。其次，在软件开发的过程中，我们应该合理科学地安排技术人员以及其它与项目相关的资源，安排好这些资源后，才能减小开发中人员风险存在的可能性。还要做好其他相关风险的安排和考查工作，这里就每个风险类型不做一一介绍。最后，软件项目参与人员还应该根据已有的成功项目和失败项目的经验和教训，对此加以总结和比较，得出影响软件项目的相关重要因素，并且对这些可能存在的因素进行分析，尽可能地得出已知的和潜在的风险，根据相应的风险类型，及时的做出最合理的避免措施，以至于有效的防止风险的扩大化和普遍化。结束语

本论文主要介绍了软件项目风险的概念、风险的定义、风险的类型以及避免措施。我们 了解了风险的危害性，风险会对项目的成功造成决定性的威胁，所以当我们知道了风险危害性以后，应该怎么地去避免措施，做好合理科学的检查和预测，才能高效的防御风险发生的可能性，所以，要想做好一个软件项目，软件项目中的风险分析是一个重中之重的环节，不容忽视的，我们要总结已有的软件项目的成功和失败之处，然后运用到自己的项目中来，这样才可以最好的做到软件项目风险分析工作。参考文献：

【1】韩万江 姜立新 软件项目管理案例教程（第二版）机械工业出版社，2009.04.【2】卢有杰 卢家仪 项目管理系列教材 清华大学出版社 2001.08

【3】王卓甫 工程项目风险管理 中国水利水电出版社 2003.02

【4】Elaine M.Hall（王海鹏 周靖译）风险管理 清华大学出版社 2002.09

【5】王梅源 软件外包项目全过程风险管理 华中科技大学出版社 2009.10

第二篇：软件项目风险管控

推介导读：

此论文从需求调研、开发、实施以及项目收尾四个项目阶段，列举了11种典型的常见风险，并给出了这些风险的详细和切实可行的风险规避措施。这些风险和措施实用、实在，值得做为公司项目管理财富库进行收藏，值得各项目组借鉴。

软件项目风险管控

1.什么是软件项目风险

软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。软件项目风险会影响项目计划的实现，如果项目风险变成现实，就有可能影响项目的进度，增加项目的成本，甚至使软件项目目标不能实现。如果对项目进行风险管理，就可以最大限度的减少风险的发生。2.项目风险及应对措施

软件项目的生命周期可以分为四个阶段，即需求调研阶段、开发阶段、实施阶段、收尾阶段，软件开发过程可分为：需求分析、设计、编码、测试等几个过程，在软件项目的每个阶段、每个过程都可能存在风险。下面结合项目谈谈各阶段碰到的风险。

2.1.需求调研阶段 1． 风险描述：

调研涉众没有足够的时间参与调研活动，严重影响调研进度与调研质量。应对措施：

 开始调研时，召集公司的高层领导、各部门主管及参与调研的关键涉众召开调研启动会，让所有涉众都重视本次调研活动，努力配合调研工作。在调研启动会上明确调研涉众的职责；

 在制定调研计划时，应事前与相关涉众做好沟通工作，努力减少调研计划与日常工作安排的冲突；

 相关人员通过移交日常工作等办法，有效保证相关涉众的调研时间；  调研人员设计调研提纲时，要有针对性，尽量努力提高调研效率。2． 风险描述： 调研成果不能真实和完整地体现管理层意图与企业经营管理需要。应对措施：

 通过客户方的多方协调，让管理层要重视调研人员的访谈，客观而真实地回答访谈问题；

 管理层调研提纲在设计时，不仅要做到有针对性，而且要有全面性；  调研人员在访谈管理层，要善于挖掘与总结管理层的管理意图与经营思路；  管理层的意图应宣达到所有涉众，努力做到在繁多的需求中，把握住管理思路的主线。

3． 风险描述：

在某些需求议题上，不同部门、不同单位可能会有不同的理解与要求，且可能会各自坚持自己的意见，无法达成共识。应对措施：

 通过管理层宣传与教育，让相关涉众认识到业务流程标准化的重要性；  由总部成立业务专家小组，在出现需求不一致，提出权威的解决方案；  调研人员凭借自身的流程分析能力，尽量定义出能兼容不同需求的解决方案。 对确实无法达成共识的需求，可以采用暂时搁置争议办法，以保证进度。4． 风险描述：

调研成果偏离调研涉众的需求 应对措施：

 调研时认真聆听调研涉众的需求，然后理解及复述调研的需求；

 调研完成后，在当天整理出涉众备忘录、调研涉众的交付物清单，梳理并绘制流程图；

 第二天安排足够的时间，与调研涉众核对涉众备忘录、流程图、交付物清单，并得到调研涉众的书面确认；

 每家分公司的所有调研成果最终都要有分公司领导的书面签字确认。2.2.开发阶段 1． 风险描述： 错误理解需求分析，导致开发成果与用户需求偏离。应对措施：

 准确规范的文字表达模式；

 系统分析师与开发人员保持密切沟通，必要时召开会议向全体开发小组成员介绍需求的详细情况；

 功能开发完后，系统分析师检查功能实现情况及效果； 2． 风险描述：

项目周期短导致开发周期短，需要把SQL翻译为ORACLE，而且要统一平台整合船代与货代系统，开发任务艰巨，可能导致开发无法如期开发完成的风险。应对措施：

 增加项目组熟练开发人员；  分析、设计、开发、测试迭代进行；

 在客户方搭建测试环境，开发完成部分功能后，发布到客户方测试环境，让关键用户一起验证，及时纠正偏离的需求。

2.3.实施阶段 1． 风险描述：

基础数据收集不完整、不及时，导致系统UAT效果不好。应对措施：

 尽早整理所有需要收集的基础信息表，发给各公司系统负责人，并告知收集的期限，收集的期限必须要预留缓冲时间。

 收集到基础信息表要必须在UAT开始前导入系统的UAT环境。

 基础数据维护是一个漫长的过程，建议UAT的基础数据按正确的数据进行维护，上线时直接导入正式环境。

2． 风险描述：

UAT效果不好，导致无法如期上线。应对措施：

 与公司领导、各业务部门主管了解公司的业务线，制定UAT计划时必须涵盖公司的所有业务线；

 与UAT用户共同制定各业务线的录入数据量，每天或者每周统计数据录入情况，汇报相关项目干系人。统计清单中必须有计划录入数据量、实际录入数据量、完成百分比情况；

 若录入数据量比计划数据量偏差比较大时，必须及时召开例会并让公司领导一起参与会议。

 UAT时，必须让关键用户清楚知道整个操作流程及功能点，必须要有功能清单。3． 风险描述：

UAT后上线还是有一大堆问题，上线效果非常差，没达到用户的预期。应对措施：

 UAT后建议安排系统并行，根据各业务线的情况制定并行计划。例如：有的业务线数据量比较少可以采取完全并行的模式，有的业务线数据量比较大可以采取并行50%的方式；

 让所有的最终用户参与系统的并行；

 并行阶段每天或者每周统计数据录入情况，汇报相关项目干系人。统计清单中必须有计划录入数据量、实际录入数据量、完成百分比情况；

4． 风险描述：

UAT阶段都没什么问题，上线时因某个功能原因推迟上线。应对措施：

 项目启动时，严格制定上线标准；

 UAT阶段要有详细的功能清单、EDI清单、打印套版、接口清单，让关键用户知道试用的内容；

 在UAT期间，必须要让关键用户对这些清单进行试用，并规定问题反馈的期限；  上线一周前收集关键用户对这些清单的签字确认，至少预留一周的缓冲时间。2.4.收尾阶段 1． 风险描述：

系统的验收是整个项目过程中最难的里程碑点，系统不可能做到完全没有问题，客户可以找一些理由迟迟不验收系统。应对措施：

 签订商务合同的时候，规定验收的期限，例如：上线后多长时间完成验收工作；  验收标准正常情况下是按需求规格说明书及合同规定的交付物进行验收，但是项目周期紧，开始写的需求规格说明书到了系统验收阶段往往偏离比较大。双方项目经理及相关领导讨论制定系统需求收集期限，并对需求进行划分，划分出合同范围内验收前解决的需求清单，合同范围外验收前解决的需求清单。针对这些需求进行集中处理。

 双方对合同交付物的理解可能会存在一定的偏差，也需要双方项目经理及相关领导进行详细的沟通，确定验收时的不违背合同的交付物清单，项目组集中收集这些信息。

3.总结

软件项目风险贯穿整个项目的始终，风险无处不在，风险无时不有，风险并不可怕，可怕的是没识别风险，可怕的是没有风险管控。

第三篇：软件项目风险评估报告范文

软件项目风险评估报告范文

本文主要针对软件开发涉及到的风险，包括在软件开发周期过程中可能出现的风险以及软件实施过程中外部环境的变化可能引起的风险等进行评估。在文中对所提到的风险都一一做了详细的分析，并提出了相应的风险回避措施。

由于风险是在项目开始之后才开始对项目的开发起负面的影响，所以风险分析的不足，或是风险回避措施不得力，都很有可能造成软件开发的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施，是避免损失的重要环节。

主要风险综述

任何软件的开发，其主要风险均来自于两个方面，一是软件管理，二是软件体系结构。软件产品的开发是工程技术与个人创作的有机结合。软件开发是人的集体智慧按照工程化的思想进行发挥的过程。软件管理是保证软件开发工程化的手段。软件体系结构的合理程度是取决于集体智慧发挥的程度和经验的运用。

软件管理将影响到软件的下列因素：

软件是否能够按工期的要求完成：软件的工期常常是制约软件质量的主要因素。很多情况下，软件开发商在工期的压力下，放弃文档的书写，组织，结果在工程的晚期，大量需要文档进行协调的工作时，致使软件进度越来越慢。软件的开发不同于其他的工程，在不同的工程阶段，需要的人员不同，需要配合的方面也不同，所有这些都需要行之有效的软件管理的保证。

软件需求的调研是否深入透彻：软件的需求是确保软件正确反映用户的对软件使用的重要的文档，探讨软件需求是软件开发的起始点，但软件的需求却会贯穿整个软件的开发过程，软件管理需要对软件需求的变化进行控制和管理，一方面保证软件需求的变化不至于造成软件工程的一改再改而无法按期完成;同时又要保证开发的软件能够为用户所接受。软件管理需要控制软件的每个阶段进行的成度，不能过细造成时间的浪费，也不能过粗，造成软件缺陷。

软件的实现技术手段是否能够同时满足性能要求：软件的构造需要对软件构造过程中的使用的各种技术进行评估。软件构造技术通常是这样：最成熟的技术，往往不能体现最好的软件性能;先进的技术，往往人员对其熟悉程度不够，对其中隐含的缺陷不够明了。软件管理在制定软件开发计划和定义里程碑时必须考虑这些因素，并做出合理的权衡决策。

软件质量体系是否能够被有效地保证：任何软件管理忽略软件质量监督环节都将对软件的生产构成巨大的风险。而制定卓有成效的软件质量监督体系，是任何软件开发组织必不可少的。软件质量保证体系是软件开发成为可控制过程的基础，也是开发商和用户进行交流的基础和依据。

软件体系结构影响到软件的如下质量因素：

软件的可伸缩性：是指软件在不进行修改的情况下适应不同的工作环境的能力。由于硬件的飞速发展和软件开发周期较长的矛盾，软件升级的需要显得非常迫切。如果软件的升级和移植非常困难，软件的生命期必定很短，使得化费巨大人力物力开发出的软件系统只能在低性能的硬件或网络上运行，甚至被废弃不用，造成巨大的浪费。

软件的可维护性：软件的维护也是必然的事情，为了保证软件的较长使用寿命，软件就必须适应不断的业务需求变化，根据业务需求的变化对软件进行修改。修改的成本和周期都直接和软件的体系结构相关。一个好的软件体系结构可以尽可能地将系统的变化放在系统的配置上，即软件代码无需修改，仅仅是在系统提供的配置文件中进行适当的修改，然后软件重新加载进入运行状态，就完成了系统部分功能和性能要求的变化。对于重大改动，需要打开源代码进行修改的，也仅仅是先继承原先的代码，然后用新的功能接替原先的调用接口，这样将把软件改动量减小到最低。

软件易用性：软件的易用性是影响软件是否被用户接受的关键之关键因素。在软件产品中，设计复杂，功能强大而完备，但因为操作繁复而被搁置者屡见不鲜。造成的主要原因在于缺乏软件开发中软件体系结构的宏观把握能力。另一方面，缺乏有效的手段进行软件需求的确定和对潜在需求的挖掘。

项目管理的风险

软件项目管理的风险来自于软件项目自身的特点：

软件产品不可见：开发的进展以及软件的质量是否符合要求难于度量，从而使软件的管理难于把握。

软件的生产过程不存在绝对正确的过程形式：可以肯定的是不同的软件开发项目应当采用不同的或者说是有针对性的软件开发过程，而真正合适的软件开发过程是在软件项目的开发完成才能明了的。因此项目开发之初只能根据项目的特点和开发经验进行选择，并在开发过程中不断的调整。

大型软件项目往往是“一次性”的。以往的经验可以被借鉴的地方不多。回避和控制软件管理风险的唯一办法就是设立监督制度，项目开发中任何较大的决定都必须有主要技术环节甚至是由用户参与进行的。在该项目中项目监督由项目开发中的质量监督组来实施。

一般参与软件开发的人员(包括管理者和技术人员)和其责任进行分析如下：

参与者

项目经理1人

主要职责：进行全局把握，侧重于项目的商务方面，充当项目组同客户正式交流的接口环节。

项目负责人1人

主要职责：制定项目开发计划和开发策略，参与项目核心系统的分析设计，同时努力保证开发计划的按时完成和开发策略的真正贯彻落实。

领域专家1或2人

主要职责：在软件分析阶段帮助分析人员界定系统实现边界和实现的功能，对特定检测点进行算法审核，同时对测试策略和软件操作界面提出参考意见。

质量监督组1或2人

主要职责：编制软件质量控制计划，并负责落实;控制必要文档的生产，通过文档，监督项目实施过程中软件的质量，并产生软件质量报告，提请项目经理和项目负责人审阅;对于项目中出现的质量问题，主持召开质量复审会议。

系统分析员1或2人

主要职责：协同项目负责人进行软件系统的分析和设计工作，书写软件需求分析和系统设计相关文档。在软件实现阶段进行测试策略的编制和对性能测试的指导。

程序员2或3人

主要职责：协助分析人员进行详细设计，和软件系统的代码实现，并进行适当的白盒测试。

测试员2或3人

主要职责：已经实现的软件组件、构件或系统进行正确性验证测试，整合后的系统的性能测试等。书写测试报告和测试统计报告提请质量监督组复审。

技术支持2或3人

主要职责：协同系统分析人员听取用户需求，对需求分析进行参考性复审。协同测试人员进行测试，书写操作手册和在线帮助，在项目交付用户之后进行跟踪服务。

文档组1或2人

主要职责：对各部门产生的文档进行格式规范、版本编号和控制、存档文件的检索;协助质量监督组进行软件质量监督。通过适当的人员配备和职责划分，能有效的降低软件开发在后期的失控的可能性，和软件对关键人员的依赖性。

软件技术风险

本系统拟订采用的两个重大的软件技术是面向对象的构件和基于微软的COM组件技术。组件和构件技术都是为了提高软件的可靠性和软件的可扩展性而采用的技术手段。从技术成熟度上说不存在风险，但为了实现良好的软件构架和稳定的组件，与传统开发方法比较，有相当的多的额外工作需要做，这会给项目工期带来较大的风险。

回避和控制这部分风险的办法是在项目进行的过程不断的对该阶段进行风险估计和指定有效的里程碑。同时采用“范例”方式提高开发人员的构件组件的分析识别能力，适时调整构件组件的数量和粒度。

软件过程风险

软件需求阶段的风险

软件的开发是以用户的需求开始，在大多数情况下，用户需求要靠软件开发方诱导才能保证需求的完整，再以书面的形式形成《用户需求》这一重要的文档。需求分析更多的是开发方确认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。需求和需求分析的任何疏漏造成的损失会在软件系统的后续阶段被一级一级地放大，因此本阶段的风险最大。

设计阶段的风险

设计的主要目的在于软件的功能正确的反映了需求。可见需求的不完整和对需求分析的不完整和错误，在设计阶段被成倍地放大。设计阶段的主要任务是完成系统体系结构的定义，使之能够完 成需求阶段的即定目标;另一方面也是检验需求的一致性和需求分析的完整性和正确性。

设计本身的风险主要来自于系统分析人员。分析人员在设计系统结构时过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担，和维护成本的激增。对用户来说系统的使用比例会有明显的折扣，甚至造成软件寿命过短。反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会上升，这又会在实现和测试阶段带来风险，系统的稳定性也会受到影响。从另一个角度上看，业务规则的变化，或说用户需求和将来软件运行环境的变化都是必然的情况，目前软件设计的所谓“通用性”是否就能很好的适应将来需求和运行环境的的变化，是需要认真折衷的。这种折中也蕴涵着很大的风险。

设计阶段蕴涵的另一种风险来自于设计文档。文档的不健全不仅会造成实现阶段的困难，更会在后期的测试和维护造成灾难性的后果，例如根本无法对软件系统进行版本升级，甚至是发现的简单错误都无从更正。

实现阶段引入的风险

软件的实现从某种意义上讲是软件代码的生产。原代码本身也是文档的一部分，同时它又是将来运行于计算机系统之上的实体。源代码书写的规范性，可读性是该阶段的主要风险来源。规范的代码生产会把属于程序员自身个性风格的成分引入代码的比例降到最低限度，从而减小了系统整合的风险。

维护阶段的风险

软件维护包含两个主要的维护阶段，一个是软件生产完毕到软件试运行阶段的维护，这个阶段是一种实环境的测试性维护，其主要目的是发现在测试环境中不能或未发现的问题;另一个阶段是当软件的运行不再能适应用户业务需求或是用户的运行环境(包括硬件平台，软件环境等)时进行的软件维护，具体可能是软件的版本升级或软件移植等。

从软件工程的角度看，软件维护费用约占总费用的55%~70%，系统越大，该费用越高。对系统可维护性的轻视是大型软件系统的最大风险。在软件漫长的运营期内，业务规则肯定会不断发展，科学的解决此问题的做法是不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。

在软件系统运营期间，主要的风险源自于技术支持体系的无效运转。科学的方法是有一支客户支持队伍不断收集运行中发现的问题，并将解决问题的方法传授给软件系统的所有使用者。

项目风险表

风险评估表中所提到的风险是一般项目在开发过程中都客观存在的，表中所列出的风险系数是指在不对风险进行深入的分析和有效的规避的情况下，该风险项发生的概率。比如软件产品的设计目标是运行十年，体系结构不合理的风险是40%的含义是，如果不对系统进行深入的分析，未采用最合理的软件技术进行设计，则生产出一个不具备可扩展性的软件系统的概率是40%。由于客户公司是仍将不断发展的，在十年内，该软件系统都能满足公司运营要求的可能性极低。由此而可能产生的灾难性后果是公司在业务发展的时候，必须重新开发新系统。

向客户提供风险评估，是按照国际惯例进行的例行操作，一方面让客户对潜在的风险有更充分的了解，表明公司诚信 为本的态度，另一方面也用以鞭策和激励全体开发人员严格执行开发标准，共同监督项目开发过程，努力避免风险的发生。

第四篇：【资料】软件项目风险评估报告

软件项目风险评估报告

本文主要针对软件开发涉及到的风险，包括在软件开发周期过程中可能出现的风险以及软件实施过程中外部环境的变化可能引起的风险等进行评估。在文中对所提到的风险都一一做了详细的分析，并提出了相应的风险回避措施。由于风险是在项目开始之后才开始对项目的开发起负面的影响，所以风险分析的不足，或是风险回避措施不得力，都很有可能造成软件开发的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施，是避免损失的重要环节。主要风险综述

任何软件的开发，其主要风险均来自于两个方面，一是软件管理，二是软件体系结构。软件产品的开发是工程技术与个人创作的有机结合。软件开发是人的集体智慧按照工程化的思想进行发挥的过程。软件管理是保证软件开发工程化的手段。软件体系结构的合理程度是取决于集体智慧发挥的程度和经验的运用。

1.1 软件管理将影响到软件的下列因素：

软件是否能够按工期的要求完成：软件的工期常常是制约软件质量的主要因素。很多情况下，软件开发商在工期的压力下，放弃文档的书写，组织，结果在工程的晚期，大量需要文档进行协调的工作时，致使软件进度越来越慢。软件的开发不同于其他的工程，在不同的工程阶段，需要的人员不同，需要配合的方面也不同，所有这些都需要行之有效的软件管理的保证。软件需求的调研是否深入透彻：软件的需求是确保软件正确反映用户的对软件使用的重要的文档，探讨软件需求是软件开发的起始点，但软件的需求却会贯穿整个软件的开发过程，软件管理需要对软件需求的变化进行控制和管理，一方面保证软件需求的变化不至于造成软件工程的一改再改而无法按期完成；同时又要保证开发的软件能够为用户所接受。软件管理需要控制软件的每个阶段进行的成度，不能过细造成时间的浪费，也不能过粗，造成软件缺陷。

软件的实现技术手段是否能够同时满足性能要求：软件的构造需要对软件构造过程中的使用的各种技术进行评估。软件构造技术通常是这样：最成熟的技术，往往不能体现最好的软件性能；先进的技术，往往人员对其熟悉程度不够，对其中隐含的缺陷不够明了。软件管理在制定软件开发计划和定义里程碑时必须考虑这些因素，并做出合理的权衡决策。

软件质量体系是否能够被有效地保证：任何软件管理忽略软件质量监督环节都将对软件的生产构成巨大的风险。而制定卓有成效的软件质量监督体系，是任何软件开发组织必不可少的。软件质量保证体系是软件开发成为可控制过程的基础，也是开发商和用户进行交流的基础和依据。

1.2 软件体系结构影响到软件的如下质量因素：

软件的可伸缩性：是指软件在不进行修改的情况下适应不同的工作环境的能力。由于硬件的飞速发展和软件开发周期较长的矛盾，软件升级的需要显得非常迫切。如果软件的升级和移植非常困难，软件的生命期必定很短，使得化费巨大人力物力开发出的软件系统只能在低性能的硬件或网络上运行，甚至被废弃不用，造成巨大的浪费。软件的可维护性：软件的维护也是必然的事情，为了保证软件的较长使用寿命，软件就必须适应不断的业务需求变化，根据业务需求的变化对软件进行修改。修改的成本和周期都直接和软件的体系结构相关。一个好的软件体系结构可以尽可能地将系统的变化放在系统的配置上，即软件代码无需修改，仅仅是在系统提供的配置文件中进行适当的修改，然后软件重新加载进入运行状态，就完成了系统部分功能和性能要求的变化。对于重大改动，需要打开源代码进行修改的，也仅仅是先继承原先的代码，然后用新的功能接替原先的调用接口，这样将把软件改动量减小到最低。

软件易用性：软件的易用性是影响软件是否被用户接受的关键之关键因素。在软件产品中，设计复杂，功能强大而完备，但因为操作繁复而被搁置者屡见不鲜。造成的主要原因在于缺乏软件开发中软件体系结构的宏观把握能力。另一方面，缺乏有效的手段进行软件需求的确定和对潜在需求的挖掘。项目管理的风险

软件项目管理的风险来自于软件项目自身的特点：

软件产品不可见：开发的进展以及软件的质量是否符合要求难于度量，从而使软件的管理难于把握。软件的生产过程不存在绝对正确的过程形式：可以肯定的是不同的软件开发项目应当采用不同的或者说是有针对性的软件开发过程，而真正合适的软件开发过程是在软件项目的开发完成才能明了的。因此项目开发之初只能根据项目的特点和开发经验进行选择，并在开发过程中不断的调整。

大型软件项目往往是“一次性”的。以往的经验可以被借鉴的地方不多。回避和控制软件管理风险的唯一办法就是设立监督制度，项目开发中任何较大的决定都必须有主要技术环节甚至是由用户参与进行的。在该项目中项目监督由项目开发中的质量监督组来实施。

一般参与软件开发的人员（包括管理者和技术人员）和其责任进行分析如下： 参与者 项目经理1人

主要职责：进行全局把握，侧重于项目的商务方面，充当项目组同客户正式交流的接口环节。项目负责人1人

主要职责：制定项目开发计划和开发策略，参与项目核心系统的分析设计，同时努力保证开发计划的按时完成和开发策略的真正贯彻落实。领域专家1或2人

主要职责：在软件分析阶段帮助分析人员界定系统实现边界和实现的功能，对特定检测点进行算法审核，同时对测试策略和软件操作界面提出参考意见。质量监督组1或2人

主要职责：编制软件质量控制计划，并负责落实；控制必要文档的生产，通过文档，监督项目实施过程中软件的质量，并产生软件质量报告，提请项目经理和项目负责人审阅；对于项目中出现的质量问题，主持召开质量复审会议。系统分析员1或2人

主要职责：协同项目负责人进行软件系统的分析和设计工作，书写软件需求分析和系统设计相关文档。在软件实现阶段进行测试策略的编制和对性能测试的指导。程序员2或3人

主要职责：协助分析人员进行详细设计，和软件系统的代码实现，并进行适当的白盒测试。测试员2或3人

主要职责：已经实现的软件组件、构件或系统进行正确性验证测试，整合后的系统的性能测试等。书写测试报告和测试统计报告提请质量监督组复审。技术支持2或3人

主要职责：协同系统分析人员听取用户需求，对需求分析进行参考性复审。协同测试人员进行测试，书写操作手册和在线帮助，在项目交付用户之后进行跟踪服务。

文档组1或2人

主要职责：对各部门产生的文档进行格式规范、版本编号和控制、存档文件的检索；协助质量监督组进行软件质量监督。通过适当的人员配备和职责划分，能有效的降低软件开发在后期的失控的可能性，和软件对关键人员的依赖性。软件技术风险

本系统拟订采用的两个重大的软件技术是面向对象的构件和基于微软的COM组件技术。组件和构件技术都是为了提高软件的可靠性和软件的可扩展性而采用的技术手段。从技术成熟度上说不存在风险，但为了实现良好的软件构架和稳定的组件，与传统开发方法比较，有相当的多的额外工作需要做，这会给项目工期带来较大的风险。

回避和控制这部分风险的办法是在项目进行的过程不断的对该阶段进行风险估计和指定有效的里程碑。同时采用“范例”方式提高开发人员的构件组件的分析识别能力，适时调整构件组件的数量和粒度。软件过程风险 软件需求阶段的风险

软件的开发是以用户的需求开始，在大多数情况下，用户需求要靠软件开发方诱导才能保证需求的完整，再以书面的形式形成《用户需求》这一重要的文档。需求分析更多的是开发方确认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。需求和需求分析的任何疏漏造成的损失会在软件系统的后续阶段被一级一级地放大，因此本阶段的风险最大。设计阶段的风险

设计的主要目的在于软件的功能正确的反映了需求。可见需求的不完整和对需求分析的不完整和错误，在设计阶段被成倍地放大。设计阶段的主要任务是完成系统体系结构的定义，使之能够完成需求阶段的即定目标；另一方面也是检验需求的一致性和需求分析的完整性和正确性。

设计本身的风险主要来自于系统分析人员。分析人员在设计系统结构时过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担，和维护成本的激增。对用户来说系统的使用比例会有明显的折扣，甚至造成软件寿命过短。反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会上升，这又会在实现和测试阶段带来风险，系统的稳定性也会受到影响。从另一个角度上看，业务规则的变化，或说用户需求和将来软件运行环境的变化都是必然的情况，目前软件设计的所谓“通用性”是否就能很好的适应将来需求和运行环境的的变化，是需要认真折衷的。这种折中也蕴涵着很大的风险。

设计阶段蕴涵的另一种风险来自于设计文档。文档的不健全不仅会造成实现阶段的困难，更会在后期的测试和维护造成灾难性的后果，例如根本无法对软件系统进行版本升级，甚至是发现的简单错误都无从更正。实现阶段引入的风险软件的实现从某种意义上讲是软件代码的生产。原代码本身也是文档的一部分，同时它又是将来运行于计算机系统之上的实体。源代码书写的规范性，可读性是该阶段的主要风险来源。规范的代码生产会把属于程序员自身个性风格的成分引入代码的比例降到最低限度，从而减小了系统整合的风险。维护阶段的风险

软件维护包含两个主要的维护阶段，一个是软件生产完毕到软件试运行阶段的维护，这个阶段是一种实环境的测试性维护，其主要目的是发现在测试环境中不能或未发现的问题；另一个阶段是当软件的运行不再能适应用户业务需求或是用户的运行环境（包括硬件平台，软件环境等）时进行的软件维护，具体可能是软件的版本升级或软件移植等。

从软件工程的角度看，软件维护费用约占总费用的55%~70%，系统越大，该费用越高。对系统可维护性的轻视是大型软件系统的最大风险。在软件漫长的运营期内，业务规则肯定会不断发展，科学的解决此问题的做法是不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。

在软件系统运营期间，主要的风险源自于技术支持体系的无效运转。科学的方法是有一支客户支持队伍不断收集运行中发现的问题，并将解决问题的方法传授给软件系统的所有使用者。项目风险表

风险评估表中所提到的风险是一般项目在开发过程中都客观存在的，表中所列出的风险系数是指在不对风险进行深入的分析和有效的规避的情况下，该风险项发生的概率。比如软件产品的设计目标是运行十年，体系结构不合理的风险是40%的含义是，如果不对系统进行深入的分析，未采用最合理的软件技术进行设计，则生产出一个不具备可扩展性的软件系统的概率是40%。由于客户公司是仍将不断发展的，在十年内，该软件系统都能满足公司运营要求的可能性极低。由此而可能产生的灾难性后果是公司在业务发展的时候，必须重新开发新系统。

向客户提供风险评估，是按照国际惯例进行的例行操作，一方面让客户对潜在的风险有更充分的了解，表明公司诚信为本的态度，另一方面也用以鞭策和激励全体开发人员严格执行开发标准，共同监督项目开发过程，努力避免风险的发生。

第五篇：怎样做好软件项目风险计划

怎样做好软件项目风险计划

风险评价是识别并分析潜在风险区域的过程。可以通过列举通常的软件项目风险因素以使风险识别更加明析。制作风险评估表是识别风险的好办法，在风险评估表中我们统计特定风险对项目可能造成的潜在后果，风险计划的要素有：

风险描述 对于风险情况的介绍。

可能性 风险发生的可能性。风险不是必然要发生的，如果一个对项目存在危害的事件是必然要发生的，那这个事件就不能作为风险。对于风险可能性的标识有助于对那些高可能性的风险投入更大的关注。

严重性 风险如果发生对于项目的危害程度。

危害值 一个综合考虑可能性和严重型后对风险的一个评估，这个评估反应了风险应该被关注的程度。

对策 对策分为两个部分：一是对于采取预防措施以阻止风险的发生，另一方面也要考虑如果风险发生后需要采取什么措施。这两方面的计划构成了完整的风险对策。

触发标志 风险是一种可能性，并且制定风险主要的出发点是预防它，但也要考虑到风险发生后情况。对于风险发生后的应对策略，需要争取一定的提前时间以启动必要的各项工作，设立触发标志是为设立一个判别标识，在该触发标志所标明的条件具备时，说明风险已经越来越可能成为现实了。

风险责任人 风险预防和跟踪需要有人的参与，在风险计划中责任明确是一个重要的原则，对每一个列入了视线的风险都要指定对风险预防和跟踪负责的人员。

风险计划不是一个静止的文件，它应该随着项目状况的变化而变化。所以在任何项目中，风险管理都必须被作为一个日常的正式活动列入项目工作计划，成为项目管理人员的一个重要工作。在下一节风险跟踪中将对风险的动态变化作出更详细的阐述。

在标定风险可能性和危害时，重要的是清楚地标明风险之间重要性的相对比较，所以采取一个简明的标注标准十分重要。