如何对软件项目开发过程中的风险进行风险控制？

IT项目中的风险管理

软件项目的风险无非体现在以下四个方面：需求、技术、成本和进度。IT项目开发中常见的风险有如下几类：

需求风险

①需求已经成为项目基准,但需求还在继续变化;②需求定义欠佳,而进一步的定义会扩展项目范畴;③添加额外的需求;④产品定义含混的部分比预期需要更多的时间;⑤在做需求中客户参与不够;⑥缺少有效的需求变化管理过程。

计划编制风险

①计划、资源和产品定义全凭客户或上层领导口头指令,并且不完全一致;②计划是优化的,是"最佳状态",但计划不现实,只能算是"期望状态";③计划基于使用特定的小组成员,而那个特定的小组成员其实指望不上;④产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大;⑤完成目标日期提前,但没有相应地调整产品范围或可用资源;⑥涉足不熟悉的产品领域,花费在设计和实现上的时间比预期的要多。

组织和管理风险

①仅由管理层或市场人员进行技术决策,导致计划进度缓慢,计划时间延长;②低效的项目组结构降低生产率;③管理层审查 决策的周期比预期的时间长;④预算削减,打乱项目计划;⑤管理层作出了打击项目组织积极性的决定;⑥缺乏必要的规范,导至工作失误与重复工作;⑦非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。

人员风险

①作为先决条件的任务(如培训及其他项目)不能按时完成;②开发人员和管理层之间关系不佳,导致决策缓慢,影响全局;③缺乏激励措施,士气低下,降低了生产能力;④某些人员需要更多的时间适应还不熟悉的软件工具和环境;⑤项目后期加入新的开发人员,需进行培训并逐渐与现有成员沟通,从而使现有成员的工作效率降低;⑥由于项目组成员之间发生冲突,导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作;⑦不适应工作的成员没有调离项目组,影响了项目组其他成员的积极性;⑧没有找到项目急需的具有特定技能的人。

开发环境风险

①设施未及时到位;②设施虽到位,但不配套,如没有电话、网线、办公用品等;③设施拥挤、杂乱或者破损;④开发工具未及时到位;⑤开发工具不如期望的那样有效,开发人员需要时间创建工作环境或者切换新的工具;⑥新的开发工具的学习期比预期的长,内容繁多。

客户风险

①客户对于最后交付的产品不满意,要求重新设计和重做;②客户的意见未被采纳,造成产品最终无法满足用户要求,因而必须重做;③客户对规划、原型和规格的审核 决策周期比预期的要长;④客户没有或不能参与规划、原型和规格阶段的审核,导致需求不稳定和产品生产周期的变更;⑤客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长;⑥客户提供的组件质量欠佳,导致额外的测试、设计和集成工作,以及额外的客户关系管理工作。

产品风险

①矫正质量低下的不可接受的产品,需要比预期更多的测试、设计和实现工作;②开发额外的不需要的功能(镀金),延长了计划进度;③严格要求与现有系统兼容,需要进行比预期更多的测试、设计和实现工作;④要求与其他系统或不受本项目组控制的系统相连,导致无法预料的设计、实现和测试工作;⑤在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题;⑥开发一种全新的模块将比预期花费更长的时间;⑦依赖正在开发中的技术将延长计划进度。

设计和实现风险

①设计质量低下,导致重复设计;②一些必要的功能无法使用现有的代码和库实现,开发人员必须使用新的库或者自行开发新的功能;③代码和库质量低下,导致需要进行额外的测试,修正错误,或重新制作;④过高估计了增强型工具对计划进度的节省量;⑤分别开发的模块无法有效集成,需要重新设计或制作。

过程风险

①大量的纸面工作导致进程比预期的慢;②前期的质量保证行为不真实,导致后期的重复工作;③太不正规(缺乏对软件开发策略和标准的遵循),导致沟通不足,质量欠佳,甚至需重新开发;④过于正规(教条地坚持软件开发策略和标准),导致过多耗时于无用的工作;⑤向管理层撰写进程报告占用开发人员的时间比预期的多;⑥风险管理粗心,导致未能发现重大的项目风险。

软件项目风险管理模型

针对软件项目中的风险管理问题，不少专家、组织提出了自己的风险管理模型。主要的风险管理模型有：Boehm模型，CRM模型和SERIM模型。

Barry Boehm模型

模型：RE=P(UO)L(UO)

其中RE表示风险或者风险所造成的影响，P(UO)表示令人不满意的结果所发生的概率，L(UO)表示糟糕的结果会产生的破坏性的程度。Boehm思想的核心是10大风险因素列表。针对每个风险因素，都给出了一系列的风险管理策略。在实际 *** 作时，Boehm以10大风险列表为依据，总结当前项目具体的风险因素，评估后进行计划和实施，在下一次定期召开的会议上再对这10大风险因素的解决情况进行总结，产生新的10大风险因素表，依此类推。

SEI的CRM(Continuous Risk Management)模型

SEI CRM模型的风险管理原则是：不断地评估可能造成恶劣后果的因素；决定最迫切需要处理的风险；实现控制风险的策略；评测并确保风险策略实施的有效性。CRM模型要求在项目生命期的所有阶段都关注风险识别和管理，它将风险管理划分为个步骤：风险识别、分5析、计划、跟踪、控制。

SERIM(Software Engineering Risk Model)模型

SERIM从技术和商业两个角度对软件风险管理进行剖析，考虑的问题涉及开销、进度、技术性能等。它还提供了一些指标和模型来估量和预测风险，由于这些数据来源于大量的实际经验，因此具有很强的说服力。

结

语

IT项目管理从某种意义上讲，就是风险管理。我们尽量去定义明确不变的需求，以便进行计划并高效管理，但商业环境总是快速变化的，甚至是无序的变化。所以，软件企业在进行项目管理的过程中，必须采用适合自己的风险管理方法进行风险管理，以确保软件项目在规定的预算和期限内完成项目。

希望上述提供的资料对您有所帮助！

以我多年参与、主导IT实施/开发项目的经验，我觉得项目实施过程中没有任何问题几乎是不可能的事儿，因此出现问题本身没什么值得大惊小怪的，而如何对待问题、如何处理问题却是一个最值得关注的问题。这就是我所信奉的“问题本身不是问题，对待问题的态度是个大问题”。1、合同签署前要充分了解未来客户方项目负责人的实施方法论有些客户自己不懂该如何实施项目，也谈不上方法论，那么项目过程中可能要以实施人员引导、制订实施方案及项目计划并且征得客户方关键干系人的认可。如果客户自己在实施方面就有自己成熟的一套想法，而且客户反复在沟通过程中强调自己对于项目的要求，那么前期负责和客户接洽的人员就必须对这些信息敏感并且尝试着挖掘一下，客户可能对实施有哪些要求，我们自己是否熟悉这套东西，应该提早准备哪些应对措施。前期与客户接洽的人员切不可不加思索地就来一句“肯定没有问题。。。”之类的承诺。2、要多琢磨客户在项目过程中反复强调的东西一个成熟的客户会在项目启动早期把一些他特别在意的东西反复强调，这些东西很有可能就是客户所预见的项目风险或者项目的方向。实施方项目组成员一定要仔细琢磨客户的意图，琢磨不清楚就多找客户沟通、多提问题以帮助自己理解他的意图。倾听和提问是一个实施顾问特别应该具备的一个素质。3、出了问题要及时回应是人都害怕不确定的东西，客户也一样。如果出了问题，实施方项目组成员或高层没有及时回应对于客户来说是一个非常大为光火的事情。这就跟我们到商场买东西发现所购买商品存在某些问题或者某些疑问时向导购人员提出来，导购人员置之不理是同类的问题。及时做出反应不是要求马上拿出解决方案，而是让客户知道我们已经在采取措施，并且明确给出客户提出解决方案的时间。尤其是获悉相关信息的公司高层更应该及时响应，一个理性的客户肯定不会把芝麻小事也让实施方高层知道，既然知会了高层想必会有客户的道理，比如问题升级了或者遇到了严重的问题。4、针对问题的解决方案切忌含糊、托辞作为客户，项目出现了问题还心情超好的可能性不大。所以，实施方在针对问题给出解决方案一定要慎重：首先仔细分析问题是否真正存在，是否超出了项目的范围，如果存在也不超出范围那么问题的根源可能是什么，现实情况下能否有解决方案，解决方案所需要耗费的成本是否可以承受（是否存在客户承担部分成本的可能？），是否会给客户方带来任何风险，解决方案估计什么时间可以完成等等都需要经过内部专家团队反复推敲、论证、模拟。然后把有完整分析、明确解决方案、完成时间及接口人的信息发给客户，征求客户意见。如果有些东西超出项目范围或者超出实施方的能力，那么也建议诚恳地和客户沟通，看如何通过其他方式来弥补因为这些问题存在所造成的遗憾。提供解决方案时有五个大忌：1)、忌含糊其辞，没有多少人喜欢这些看不明白的东西，可千万别在客户的坏心情上面火上加油；3)、忌没有解决问题的时间表；4)、忌为自己方辩护；5)、忌信口开河似的承诺5、出现问题后要及时展开沟通，丰富沟通的渠道和层次上面谈到了及时回应，算是及时沟通的一种，但还不全面，那只能在问题出现以后稍稍缓和客户的情绪。在提出解决方案、和客户确认以及方案实施的过程中，建议实施方负责人要在自己公司内部(尤其与高层之间)、以及客户方项目干系人之间及时、定期展开沟通。如果问题的确比较严重，对项目有较大影响，项目负责人还应该考虑丰富沟通渠道、提高双方沟通的层次，以便于可以有效地把处理的进度、遇到的问题传递给双方项目组、管理层，及时调动优质资源配合问题的及时管控、处理。我觉得做到了以上五点，再配合以专业技术层面的努力，大部分客户应该都会满意，而不至于项目合作双方的不愉快从此成为项目的一个噩梦烦扰着彼此。其实我们不需要也无法苛求彻头彻尾的专业，但我们一定要有一个专业的态度和精神，这是我看待项目合作的一个基本态度。

识别和分析风险并不是软件风险管理的最终目标。针对所发现的每一个软件风险，尤其是高危险度的软件风险，风险管理还需要对它们进行有效的控制，包括：（1） 制定风险管理计划：针对各个重要风险制定风险管理计划，并确保它们的一致性；（2）化解风险：执行风险管理计划，以缓解或消除风险；（3）监控风险：监控风险化解的过程。n�0�2�0�2�0�2�0�2�0�2�0�2 制定风险管理计划针对每一个重要的软件风险，制定相应的处理该软件风险的计划。风险管理计划主要描述有关软件风险处理的以下内容-�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2 软件风险名称-�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2 软件风险由谁引起-�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2 软件风险发生后的处理措施n�0�2�0�2�0�2�0�2�0�2�0�2 风险化解方式执行风险管理计划，以缓解或消除风险。一般地，软件风险化解有以下几种方式。-�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2 避免风险采取主动和积极的措施来规避软件风险，将软件风险发生的概率控制为零。例如针对用户可能没有时间参加需求评审这一软件风险，项目组可以考虑选择用户方便的时间来进行需求评审，这样“用户不能出席需求评审会”这一软件风险就不会发生。-�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2 转移风险将可能或者潜在的软件风险转移给其它的单位或个人，从而使得自己不再承担该软件风险。例如如果开发某个子系统存在技术和人力资源方面的风险，可以考虑将它外包给其它软件开发公司，从而将该软件风险从项目中转移出去。-�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2 消除发生软件风险的根源如果知道导致软件风险发生的因素，那么针对这些因素，采取手段消除软件风险发生的根源。例如如果发现导致小刘离开项目组的主要原因是薪酬太低，那么可以通过给小刘增加薪酬来消除发生软件风险的根源。�0�2n�0�2�0�2�0�2�0�2�0�2�0�2 风险监控在风险评估和控制过程中，项目组人员和负责人必须对软件风险的化解程度及其变化（如发生概率、可能导致的损失和危险度）进行检查和监控，并对收集到的有关软件风险信息进行记录，以促进对软件风险的持续管理。风险监控的主要内容包括：监控和跟踪重要软件风险，记录这些软件风险危险度的变化以及软件风险化解的进展，确认软件风险是否已经得到化解和消除，是否有新的软件风险发生等等。

IT项目管理的风险有哪些

项目风险是一种不确定事件或状况，一旦发生，会对至少一个项目目标，如进度、成本、范围或质量目标产生积极或消极影响。那么IT项目管理的风险有哪些呢？一起来了解下吧：

(1)技术风险。

核心系统升级引入了外包厂商的最新产品，使用了很多新技术，行内研发人员熟悉这些技术需要一定的时间，而在项目过程中却不可避免地会遇到一些技术问题。如何能快速解决这些棘手的技术问题我们的做法是：第一，指定行内外包厂商接头人，由接头人负责和外包厂商的技术人员进行沟通，同时该接头人也是行内对厂商产品最熟悉的人，一般性的小问题基本上此人就可以解决，比较复杂的问题才提交给厂商解决，这样比起全部问题都去找厂商解决，节省了时间。第二，购买厂商的人力进行技术支持，请厂商的研发人员来到开发现场和我们一块研发。第三，预约厂商在系统上线期间到现场待命，以应对紧急问题发生，对可能出现的问题进行第一时间的响应。

(2)沟通风险。

参与项目的外包厂商有多个，沟通渠道多，沟通成本大，而且容易出现理解不一致的情况。所以，项目组成立了专门的PMO，负责制定相应的沟通计划，为每个厂商指定行内的接头人，对内部人员实行分级管理，组织定期例会解决项目过程中出现的问题，防范由于对需求理解不一致造成的项目延误，充分利用已有的邮件、会议、电话和短信等沟通工具，并推广使用某即时通讯工具以作为主要的工作沟通工具。

(3)需求变更风险。

针对IT软件项目中不可避免的需求变更活动，在项目开始后，我部就停止了除政策性需求以外的所有规模超过20人/天的新业务需求，同时制定了需求变更流程：所有业务需求的变更必须由业务方的代表统一提出，变更必须有书面记录，开发人员仔细评估是否接受，最后由总管变更的领导(CCB)复审，总管领导具有一票否决权，从而精简了一些不合理的需求变更。在项目中期引入了IBM的配置管理工具CCCQ来管理代码和缺陷，所有Bug都进行了分类，并录入CQ系统，防止重复修改和修改后无记录等情况的发生。迁移演练之后的缺陷都由各个系统的负责人统一对缺陷进行分析评审，消除Bug修复可能导致的系统关联问题。

(4)进度风险。

项目进行核心升级，引起了客户面数据结构和一些外部接口的变化，同时前端业务平台也做了很大的调整，如开发了新的权限系统、迁移主机老权限系统上的权限数据到微机、替换传输协议XML为JSON、改造微机调用主机框架等。主机平台和开放平台开发工作量巨大，需要留有足够的ST、UAT测试时间，项目开发时间有限，为了应对可能造成的进度延误，我们采用了以下应对方法：一是制定详细的进度计划，明确每个人的任务，各项目组每周定期检视项目进度，如出现偏差及时纠正;二是与外包公司合作，引入外包人力，为项目临时增派了多名生力军;三是强制加班;四是并行化详细设计和编码同时加强代码评审，在加快进度的同时减少返工。

(5)数据迁移风险。

项目涉及的系统多达上百个，系统集成环境复杂，需要迁移的数据量庞大，而且数据迁移对数据的准确性和完整性有着很高的要求。项目制定了分阶段集成和多次迁移演练的策略：将迁移工作进行提前预演，模拟真实上线迁移场景。经过多次演练以后，问题大大减少，减轻了系统上线的数据迁移风险。

(6)人力资源风险。

项目建设周期长，历时两年，大范围人员流动可能会造成项目延误。针对这一风险，应对的方法是：做两手准备，尽力挽留要走的人员，晓之以理，动之以情，请求公司人力资源部提升员工待遇;同时加紧社会招聘，在重要的岗位上安排备份，防止由于成员生病、离职等意外造成的减员。最终这个风险没有成为问题。

在项目升级项目中，我负责两个子系统的开放部分，由于高层对风险管理的重视，我在执行的时候也特别重视对风险的控制。项目组有四个人，沟通成本比较低，所以我们每隔一周进行一次代码评审，解决遇到的一些技术难题和编码规范问题，在实际开发中使用Checkstyle进行代码规范检视，及早扼杀了可能出现的Bug和不规范的代码;制定组员每周报告进度制度，防范进度偏差;面对前端最可能出现的需求变更——UI变更，我尝试在设计初期使用原型方法和业务进行有效沟通，大大减少了后期UAT阶段UI变更需求。回想刚进公司时我做过的某个项目，由于没有考虑到UI类需求变更风险，前期没有进行UI设计的交流，导致UAT阶段大量返工，使项目延误了一个多月，并且浪费了不少人力资源。设想如果当时识别了这类风险，在早期就把风险发生的概率降低，那么项目可能会顺利得多。

由于前期风险控制得当，一直到迁移演练前我负责的项目都很顺利，但是在迁移演练过程中出现了一些问题，其中一个问题是导库程序不能正常执行，并多次发生。我和同事花了很多时间研究问题，最后找到的原因是某个配置参数的问题，研发人员使用了错误的配置参数，ST、UAT期间导库的数据量比真实演练期间的数据量小太多，所以没有被发现，修改配置后再演练环境导库成功。还有一些问题是没有有效沟通导致的。例如，在演练的时候用户反映某个查询交易很慢，经排查，后台人员说前台调错了交易，前台人员提出异议：为什么ST环境查询很快原来后台人员写了多个查询交易，新交易确实能提升查询速度，但是没有在正式的文档上注明前台应使用新交易替换老交易，也没有通过别的途径告知前台，这样前台调用的还是老交易，导致了查询性能问题。由于ST、UAT环境和生产环境的差异性，上述两类问题很难暴露，试想如果没有进行迁移演练，这个问题恐怕要在生产上出现了。迁移演练提前暴露了ST、UAT所不能测出的系统缺陷，使得研发人员能有充分的时间去排查问题和修复缺陷，有效降低了系统上线风险。

经过这次核心升级项目的洗礼，我深深认识到风险管理在IT项目中的重要性，正因为对风险管理足够重视，提前制定了风险应对计划，我们才得以如庖丁解牛般化解项目中遇到的各种风险，并最终取得了上线的胜利。任何项目都不能回避风险问题，风险的存在导致几乎每个项目都不可能顺风顺水地完成项目目标，良好的风险管理技能将帮助项目经理处理好项目中的不确定因素，保证项目的顺利进行。

;

IT项目的风险管理

风险一词越来越被概念化，并随着人类活动的复杂性和深刻性而逐步深化，及时在IT项目同样存在，下面我为大家准备了关于IT项目风险管理的文章，欢迎阅读。

一、风险的定义

风险有两种定义：一种定义强调了风险表现为不确定性;而另一种定义则强调风险表现为损失的不确定性。

若风险表现为不确定性，说明风险产生的结果可能带来损失、获利或是无损失也无获利，属于广义风险，金融风险属于此类。而风险表现为损失的不确定性，说明风险只能表现出损失，没有从风险中获利的可能性，属于狭义风险。

广义的风险展现出来的是机会，虽然这种机会可能让我们的项目变得颗粒无收，但如果一旦机会有利于项目，则可以大赚一笔，风险投资家们心中的风险正是广义的风险，所以风险才会吸引他们投入巨大的资金。而作为项目管理者来说，风险对他们意味着失败的危险，因此必须将任何风险扼杀于摇篮之中。

二、IT项目风险的特征

由于软件本身的特点，导致IT项目与传统项目有很大差异，因此IT项目的风险管理难度要比传统项目大。

1需求不稳定

软件项目的需求多变已成为软件业界的共识，正因为需求的多变，才让瀑布模型一直遭受到软件工程界的抨击，因此诞生了原形模型。在IBM的RUP和众多的敏捷方法论中，一直将需求不确定列为软件项目的最大特点，因而出现了拥抱变化一说。

当一个IT项目开始实施的时候，如果客户连他需要做什么，要实现一些什么功能都不能确定的话，那么做软件实施的工程师他们又如何能够知道自己要开发一个什么样的软件系统出来呢所以他们只有在漫长的等待过程中，不断遭受到客户的“批评”，在经历了“九九八十一次磨难”之后，才恍然大悟，原来就是要做一个这样的系统啊!

这有点像盲人走路一样，盲人根本就不知道前面是什么，因此他往前走一小步，如果不是路，则向左旋转一点点，再次用脚探探前面，如果是路的话，则可以往前迈一步。如果这个盲人运气不好的话，第一脚就在悬崖边上踏空，那么他将跌入万劫不复的深渊。我们的项目也如同这个盲人，稍有不慎就可能让自己走向失败，这是一个多么大的风险啊。

2项目规模估计不准确

当老师给我们布置作业的时候，如果他多布置了几个题目，下面的同学便会大声地嘘叹，开始私下的嘟噜：“又要做一个多小时了!”。学生们在很短的`时间内就能够准确的估计作业量大不大，他们的估计凭借着他们每天一次的做作业的经验和那一瞬间对题目的印象，虽然他们并没有做过刚布置的这些题目，但是估计得仍然是那么的准确。

任何一个建筑工程的项目经理都能对自己的项目进度掌握准确，在他们的眼中，只要资金到位，则进度就可以得到保证。工地需要多少人，什么时候需要开始进行什么工序的施工，什么时候需要加班，这些都在他们的心中掌握着。资金就是他们最大的风险。

而软件项目与之不同，在软件项目开始后，很少有缺钱的。只看到过资金没有到位的“烂尾楼”，但是从来没有看到过由于项目资金没有到位的问题而导致未完成的软件项目，就算是缺钱也是因为签合同的时候要少了。

再优秀的软件项目经理，他也无法预计好自己的项目什么时候能够完成，因为在他进行估算的时候，客户的需求还没有搞清楚呢!再者，建筑工程可以通过预算很准确地得出整个建筑的工程造价，而软件项目却很难，因为不管是代码行估算法，还是功能点方法，都远不及“我猜，我猜，我猜猜猜”中猜得准确，这些方法很多时候甚至不如算命先生算得准。

3人的因素对项目影响很大

人可以说是整个软件项目的灵魂，软件项目不需要钢筋、水泥和沙石，也不需要任何的施工机械。软件项目的原材料就是人的思想和智慧，而计算机和CASE软件则是项目的施工工具。通过键盘和鼠标，无数的程序代码在程序员手中诞生了。如果要问软件项目最大的成本在哪里，那么答案只有一个，就是人力成本。

一个优秀的程序员的工作效率要远远高于一个蹩脚的程序员，一个程序新手甚至根本就不能够产生任何生产效率。不仅如此，新手的错误行为，将让熟练员工牺牲很多时间来帮助新手纠正他们的错误，甚至可能导致降低软件开发的效率。

虽然软件项目已经实施角色分工和管理，但是相对于其他工程的分工来说则分工比较单一。软件项目中，一般分有：系统分析师、架构师、设计师、程序员、测试工程是及配置管理人员和项目经理等。这样的分工并不能有效地降低他们工作内容的复杂度。如果能像建筑工程中的砌墙、浇注混凝土、搭脚手架那样分工细致的话，则培训软件蓝领也不会需要费如此大的力气了。

;

风险是指损失或损害的可能性。项目由于它们独一无二的本质而具有风险。

风险管理是一项投资，也就是说，风险管理需要花费与识别风险、分析风险和制定风险减轻计划相关的成本。这些成本必须包括在成本、进度和资源的计划编制中。

组织部门承担风险，以从潜在机会中获利。

风险效用或风险承受度是指从潜在回报中得到满足或快乐的程度。风险喜好者乐于高风险，风险厌恶者不喜欢冒险，风险中性者试图在风险和潜在回报之间取得平衡。

风险管理是一种行业准则，它要求项目团队不断地评估什么会对项目产生消极的影响，并确定这些事件发生的概率，以及确定这些事件如果发生所造成的影响。风险管理也涉及分析和决定对付风险的备选战略。风险管理中包含的四个主要过程是：风险识别、风险量化、风险应对计划制定和风险应对控制。风险管理计划是风险管理的重要输出。

ITS,目经常涉及下列风险：缺乏用户的参与、缺少高级管理层的支持、不明晰的要求、拙劣的计划编制，等等。由斯坦迪什集团、麦克法兰和其他组织开发的风险列表，有助于识别IT项目的潜在风险。在项目管理知识领域的一般风险条件列表也会很有帮助。

量化风险的工具和技术包括期望货币值(EMV)、计算风险因子、PERT估计、模拟和专家判断。期望货币值有助于你根据项目的预期价值来评价潜在的项目。风险因子代表了具体事件的风险，它基于其发生的概率和如果发生时所造成的后果。PERT估计需要收集乐观估计值、悲观估计值和最可能估计值。模拟是一种与PERT相比更加复杂的估算方法，它有助于你确定满足具体项目进度或成本目标的可能性。专家判断也是一种评估项目风险的有价值的工具。

三个应对风险的基本措施是：规避、接受和减轻。风险规避涉及根除具体的威胁和风险。风险接受意味着如果风险发生接受风险产生的后果。风险减轻是指通过减少风险发生的概率来减轻风险事件的影响。

风险管理计划记录了管理整个项目过程中相关风险的步骤。项目团队也会准备应急计划，这样，如果一项已识别的风险发生时，他们就知道应该采取什么措施。项目发起人经常提供应急储备来帮助应付项目范围或质量上的可能变更，从而减轻整体上的成本或，和进度风险。

风险控制涉及执行风险管理过程和计划来应对风险事件。“十大风险事项追踪”是一种在整个项目生命期始终保持风险意识的方法。

几种类型的软件在风险管理过程中会起到辅助作用。蒙特卡罗模拟软件是一种特别有用的工具，有助于更好地理解项目风险和风险或风险驱动者的几大来源。

关于软件项目管理及风险分析

摘要： 软件项H的有效管理，对项目的成败具有至关重要的作用。软件项目的风险体现存些方血，如何回避这些风险，存本文中进行了探讨，最后指出建立合理的管理流程，对软件项目的管理来说，是非常重要的。

关键词： 软件项目：管流程;风险分析

软件项目管理的提出是在2O世纪70年代中期的美国，当时美国国防部专研究了软件开发不能按时提交，预算超支和质量达到用户要求的原因，结果发现70%的项目是因为管理不善引起的，而非技术原因。于是软件开发者开始逐渐重视起软件开发中的各项管理。到了20世纪90年代中期，软件研发项日管理不善的问题仍然存在。据美国软件工程实施现状的调查，软件研发的情况仍然很难预测，大约只有10%的项目能够在预定的费用和进度下交付。

究竟怎么样才能做好软件项目的管理及风险分析，保证项目顺利实施呢这是个比较复杂的问题，下面就软件项目的特点，缩合大家的经验总结，谈一点看法。

1、软件项目管理风险分析

软件项目管是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员、产品、过程和项目进行分析和管理的活动。目的是为了让软件项目尤其是大型项目的整个软件生命周期(从分析、设计、编码、测试、到维护全过程)都能在管理者的控制之下，以预定成本按期，按质的完成软件交付用户使用。

怎样进行有效的项目管理呢首先我们来分析下影响软件项目的质量因素。

软件项目，尤其是大型项目有二项非常重要的因素，会影响整个项目的进度与质量，它们分别是：“人”、“流程” 与“技术”。

“人”是项目中最难预料与掌控的一项要素，人可分成两部份，一是客户，二是开发团队。

“技术”是指软件项目所使用的开发半台，主要指开发环境及开发语言。是最容易掌握的部份。

“流程”是指软件开发流程或是项目流程，定义流程的目的是要掌控所有的情况。项目的最大敌人是时间及预算，这两者都是有限的，如何在有限预算内准时完成项目，可说是一项艺术。

11“人”因素分析

“人”是指客户和开发团队，其中开发团队的因素对项目影响很大，对于这方面影响因素主要分析如下：

人员技能未达到要求

在项目开始之初，我们假设项目成员都能够达到组织级的要求，但往往并不是每个成员都能够达到要求。而且项目中每个成员的生产率差异可能很大，也给项目进度安排造成影响。所以在项目始之初，应该对项目成员的技能进行一次总体的评估，对于大家都欠缺的技能，应该安排统一的培训，后续需要对培训的效果进行跟踪;对于个别人员技能欠缺的，应该单独预留自我学习时间或通过以师带徒的方式进行培养，使其技能能够尽快达到要求：对于项目新员的工作和任务，应该加强评审和检查，保证输出不出现大的偏差而导致后续大量的返工。对于这方影响因素主要分析如下：

项目成员责任心不强

态度决定一切，细节决定成败。对于项目过程中的各项任务，经常出现由于项目成员责任心不强敷衍了事，导致产出的工件质量较差，引起大量返工的情况。在这种情况下，项目更应该加强项目规范的建设，项目经理应加强同这些成员的单独沟通，加强项目的团队建设和集体荣誉感。让项目成员感觉到做的系统是他们自己的产品，而不是公司的项目，项目经理的项目。

项目沟通问题

在软件项目中，保证项目各种角色和成员中的高效沟通是很重要的，如何建立起快捷顺畅的沟通渠道，采用最佳的沟通方式来解决问题，必须在项目中经常强调。如果一周的项目任务花存实际做事情上有2天，而花在沟通上却占用了3天，这时必须及时分析和总结原因。沟通最重要的`就是要在最短的时间里面，采用各种方法或工具，使交流双方或多方达成一致。

项目人员流失

项目人员特别是项目关键成员在项目进行过程中的流失，对项目影响很大，对于这种情况，应该在项目开始之初，就作为专门的风险进行跟踪，并考虑具体的应对措施。

12“流程”因素分析

软件的开发流程般定义为：

需求分析一可行性分析一概要设计一结构化设计一详细设计一编码一软件测试一软件维护。

“流程”中软件项目的风险，主要体现存4个阶段：软件需求阶段、软件设计阶段、软件实现阶段和软件维护阶段

软件需求阶段

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

软件设计阶段

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

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

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

企业规避IT外包风险的方法：

1．减少核心业务外包。根据调查，企业信息泄露的80%来自企业内部，例如来自对公司或领导不满的员工等。公司在决定IT外包之前，必须确定外包的部分包含的公司数据量较少。

2．制定外包工作进行期间的规范，例如，不得携带存储设备进入工作场地等。

3．法规制约。检查外包公司是否遵循数据隐私法案和特殊行业法规，例如萨班斯法案、HIPPA、ISO20007等。

4．技术保证。检查外包供应商是否具备保障信息安全的技术条件。

5．公司在选择外包供应商之初，应该首先查看外包供应商的保密政策，并在外包合同中明确保密协议和信息泄露后的责任归属。

以上就是关于IT风险管理内容全部的内容，包括:IT风险管理内容、该如何应对IT实施项目中的问题、如何对软件项目开发过程中的风险进行风险控制等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！