软件开发项目的风险分析与控制

、软件开发项目的风险背景

信息产业的发展是目前发展最快的行业之一，也是对社会影响最大的一 个 行业，它不但为我们创造了巨大的财富，而且从各个方面改变着我们的生活 ， 达到一个行业，小到一项服务。我们不得不承认软件是二十一世纪最不可思 议 的产品。

伴随着软件开发技术的不断更新、软件数量的增多、软件复杂程度不断 大、客户加对产品的要求也在不断的提高，随之而来的是软件开发项目给软件 发企业和需求企业开公带来的巨大风险。软件开发项目的成功与否会直接影响到 司的生存。这对软件开发企

加业来讲应该是更大的难题。一方面是业务需求更 复杂。人们对软件质量和用途的期望越大幅度提高，对业务系统的要求也越来 挑剔。另一方面是开发成本不断缩减。在此形势下，风险管理与控制已成为 件开发项目成败的关键。

软件开发项目由于其具有连续性、复杂性、少参照性，无标准规范等特点 其风险程度较高。目前国内的大多数软件开发企业还缺乏对软件开发项目 的 风 险认识，缺少进行系统、有效的度量和评价的手段。据有调查数据显示， 有 15—35%的软件项目中途被取消，剩下 的项目不是超期就是超出预算或是无法达 到预期目标。另外，软件项目因风险控制和管理原因失败的约占 90% ，可见， 软件风险控制与管理在目前的软件开发项目中的重要性。 二、 软件开发项目的风险来源及对项 目成败的影响

软件开发项目风险是指在软件生命周期中所遇到的所有的预算、进度和 控 制等各方面的问题，以及由这些问题而产生的对软件项目的影响。软件项目 风 险经常会涉及许多方面，如：缺乏用户的参与，缺少高级管理层的支持，含 糊 的要求，没有计划和管理等，总体概括下来应该由五大方面。

1、 产品规模风险

项目的风险是与产品的规模成正比的。与软件规模相关的常见风险因素 有 ： (1)估算产品规模的方法 (包括：代码行，文件数，功能点等 ) ，(2)产品规模 估 算的信任度， (3) 产品规模与以前产品规模平均值的偏差， (4) 产品的用户数 ， (5) 复用的软件有多少， (6) 产品的需求变更多少等。一般规律，产品规模 越 大， 以上的问题就越突出，尤其是估算产品规模的方法，复用软件的多少， 需 求变 化。

2、 需求风险

很多项目在确定需求时都面临着一些不确定性。当在项目早期容忍了这 些 不确定性，并且在项目进展过程当中得不到解决，这些问题就会对项目的成 功

造成很大威胁。如果不控制与需求相关的风险因素，那么就很有可能产生错 误 的产品或者拙劣地建造预期的产品。每一种情况对产品来讲都可能致命的。

与客户相关的风险因素有： (1) 对 产品缺少清晰的认识， (2) 对产品需求缺 少认同， (3) 在做需求中客户参与不够 ， (4) 没有优先需求， (5) 由于不确定的需 要导致新的市场， (6) 不断变化需求， (7) 缺少有效的需求变化管理过程， (8) 对 需求的变化缺少相关分析等。

3、 相关性风险

许多风险都是因为项目的外部环境或因素的相关性产生的。经常我们在 控 制外部的相关性上做的不够，因此缓解策略应该包括可能性计划，以便从第 二 资源或协同工作资源中取得必要的组成部分，并且觉察潜在的问题。与外部 环 境相关的因素有： (1) 客户供应条目或信息， (2) 交互成员或交互团体依赖性， ( 3) 内部或外部转包商的关系， (4) 经验丰富人员的可得性， (5) 项目的复用性。 项目经理圈子

4、 技术风险

软件技术的飞速发展和经验丰富员工的缺乏，意味着项目团队可能会因 为 技巧的原因影响项目的成功。在早期，识别风险从而采取合适的预防措施是 解 决风险领域问题的关键，比如：培训、聘请顾问以及为项目团队招聘合适的 人 才等。主要有下面这些风险因素： (1) 缺乏培训， (2) 对方法、工具和技术理解 的不够， (3) 应用领域的经验不足， (4) 新的技术和开发方法应用等。

5、 管理风险

尽管管理问题制约了很多项目的成功，但是不要因为风险管理计划中没 有 包括所有管理活动而感到惊奇。在大部分项目里，项目经理经常是写项目风 险 管理计划的人，他们有先天性的不足——自己检查自己的错误，这是最难的 。 然而，像这些问题可能会使项目的成功变得更加困难。如果不正视这些棘手 的 问题，它们就很有可能在项目进行的某个阶段影响项目本身。当我们定义了 项 目追踪过程并且明晰项目角色和责任，就能处理这些风险因素： (1) 计划和任务 定义不够充分， (2) 实际项目状态， (3) 项目所有者和决策者分不清， (4) 不切实 际的承诺， (5) 员工之间的沟通等。项 目管理培训

6、 安全风险项目管理者联盟

软件产品本身是属于创造性的产品，产品本身的核心技术保密非常重要 。 但一直以来，我们在软件这方面的安全意识比较淡薄，对软件产品的开发主 要 注重技术本身，而忽略了专利的保护。软件行业的技术人员流动是很普遍的 现 象，随着技术人员的流失、变更，很能会导致产品和新技术的泄密，致使我 们 的软件产品被它公司窃取，导致项目失败。而且在软件方面关于知识产权的 认 定目前还没有明确的一个行业规范，这也是我们软件项目潜在的风险。

风险的分析、管理与控制

1、风险分析

1．1 “流程”因素分析

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

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

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

•软件需求阶段

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

•软件设计阶段

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

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

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

软件实现阶段

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

•软件维护阶段

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

1.2 “技术”因素分析

存软件项目开发和建设的过程中，技术因素是一个非常重要的因素。项 目 组一定要本着项目的实际要求，选用合适、成熟的技术，千万不要无视项目 的 实际情况选用一些虽然先进但并非项目所必须且自己又不熟悉的技术。如果 项 目所要求的技术项目成员不具备或掌握不够，则需要重点关注该风险因素。

以上所说的各类风险都是项目成败的巨大隐患，它们对软件开发项目的 败有多大成影响，我们可以利用风险分析工具，对以上各类风险进行分析，并 以控制和管理，将风加组险将到最低。常用方法有风险条目检查表，它是利用一 提问来帮助项目风险管理者了解

检在项目和技术方面有哪些风险。在风险条目 查表中，列出了所有可能的与每一个风险因集素有关的提问，使得风险管理者 中来识别常见的、已知的和可预测的风险，如产品规模

风险、依赖性风险、 求风险、管理风险及技术风险等。 风险 条目检查表可以不同的方式组织，通过 假设分析、成本效益分析、风险剖面分析、判定树等，给出这些提问确定的 回 答，就可以帮助项目管理人员估算风险的影响。

另外，我们可以依据风险条目检查表，制作风险控制概图 （见图 1） ，让项 目管理和实施人员能很直观的看到在项目开发个阶段的风险存在状况和各风 险 的大小，并采取相应措施。从风险发生的概率来看，需求风险和管理风险对 项 目成败影响最大，当一个软件项目开发团队接手项目后，都是按照习惯性的 方 式来开发软件。需求风险意识比较淡薄，软件需求分析阶段的完成的不够细 致 ， 忽略和很多软件开发必要的内容。在整个软件开发过程中需求分析阶段的 风 险 控制尤为重要，如果控制不好，对软件开发项目影响巨大，甚至是失败。 管 理 风险实际上是项目开发管理层，对项目开发的风险的意识反映。国内的软 件 企 业大多规模较小，企业年轻，开发经验不足，软件工程师较年轻，缺少开 大 型 软件项目的经验，在管理方面缺少经验，特别是风险管理，更是缺乏。

2、风险管理

风险管理应是贯穿软件项目开发始末的一项重要任务，其中包括风险识 别、 风险评估、风险计划、风险解决和风险监控。它能让风险管理者主动“规 避” 风险，进行有效的风险管理。风险管理模型有： SEI风险管理模型、Riskit风 险管理模型、SoftRisk风险管理模型、IEEE风险管理过程模型、CMM风险 管 理模型、MSFM险管理模型等。在项目管理中，建立风 险管理策略，在项目 的 生命周期中不断控制风险是非常重要的，风险管理主要包括五个阶段：

(1)风险识别：识别风险的方法常用的有现场观察法、座谈法、流程图法、 财务报表法、

相关部门配合法和环境分析法等。

(1)风险评估：对已识别的风险要进行估计和评价，风险估计的主要任务是 确定风险发生的概率与后果，风险评价则是确定该风险的经济意义及处理的 费/

效分析，常用的方法有：概率分布、外推法、多目标分析法等。

(3) 计划进度：按照评估后的风险结果，制定相应的风险管理进度表，

后续的风险管理提供参考。

为

(4) 风险处理：一般而言，风险处理有三种方法，① 风险控制法，即主动

采取措施避免风险，消灭风险，中和风险或采用紧急方案降低风险。② 留，当风险量不大时可以余留风险。③ 风险转移。training.mypm.net

风险自

(5) 风险监控：包括对风险发生的监督和对风险管理的监督，前者是对 已 识别的风险

源进行监视和控制，后者是在项目实施过程中监督人们认真执行 风 险管理的组织和技术措施。

3、风险控制

(1) 建立有效的风险控制的组织机 构项目管理者联盟文章

①设置风险管理岗位：在软件开发项目管理过程中设置风险管理岗位， 该 岗位的主要职责是在制订与评估规划时，从风险管理的角度对项目规划或计 划 进行审核并发表意见，不断寻找可能出现的任何意外情况，试着指出各个风 险 的管理策略及常用的管理方法，以随时处理出现的风险，风险管理者最好是 由 项目主管以外的人担任。风险管理岗位的人数依据项目大小来决定，一般 2—3 人较为适合。

②双项目经理：为项目开发项目设定两个项目经理岗位，一个负责技术 位，另一个负责管理岗位。目前，国内的软件开发企业的项目经理一般都是 名，而且是技术出生的占绝对多数，他们主要擅长的是技术研发，在管理方 先天不足，这不利于项目风险管理和控制。通过增加专门的管理经理岗位， 以弥补技术出生的项目经理的不足，提升软件开发项目的管理水平。而且这 的经验也已得到了国外业界大多企业的认可。

(2) 建立有效的风险控制管理过程

风险管理过程包括培训，风险识别、风险分析、风险计划、执行计划、 跟 踪计划等活动，有效的风险管理过程应是学习型的、持续的和不断改进的。 软 件企业应建立自己的风险管理数据库作为风险管理的基础，并在实施中不断 地 更新和完善。

根据企业和项目的实际情况，进行科学的项目风险和控制，对项目的成 功 研发有着举足轻重的意义。在项目开发的过程中，进行必要的项目风险分析 ， 制定符合项目特点的风险评估和监督机制，特别是要定期对项目的风险状况 进 行评估和监管，发现意外风险或者是风险超出预期的一定要重点关照。发现 问 题要立即上报，尽快解决。并建立风险监管日志，实行“岗位负责制 ”，将软件 开发项目的风险降到最低。 管理论坛

四：项目中常见风险及预防措施

在项目的建设过程中，风险几乎无处不在。如何有效地识别、控制和管理风 对项目的成功起着至关重要的影响。

险,

一个项目有可以预料的（包括已知的）风险和不可预料的风险，以下作者总 结自己多年的软件项目工程经验，整理出软件项目经常遇到的 15种可预料的 （包括已知的）风险及其预防措施，期望能为项目经理制定项目风险计划和 进 行风险预防、控制等提供富有价值的参考。 （1）合同风险

签订的合同不科学、不严谨，项目边界和各方面责任界定不清等是影响项目 成败的重大因素之一。

预防这种风险的办法是项目建设之初项目经理就需要全面准确地了解合同各 条款的内容、尽早和合同各方就模糊或不明确的条款签订补充协议。 （2）需求变更风险

需求变更是软件项目经常发生的事情。一个看似很有 目建设方也面临巨大的风险）。

钱途”的软件项目，往

项

往由于无限度的需求变更而让项目承建方苦不堪言，甚至最终亏损（实际上

预防这种风险的办法是项目建设之初就和用户书面约定好需求变更控制流程 记录并归档用户的需求变更申请。

3）沟通不良风险

项目组与项目各干系方沟通不良是影响项目顺利进展的一个非常重要的因素

预防这种风险的办法是项目建设之初就和项目各干系方约定好沟通的渠道和 方式、项目建设过程中多和项目各干系方交流和沟通、注意培养和锻炼自身 沟通技巧。 （4）缺乏领导支持风险

上层领导的支持是项目获得资源（包括人力资源、财力资源和物料资源等） 的有效保障，也是项目遇到困难时项目组最强有力的 “后台支撑 ”。

预防这种风险的办法是主动争取领导对项目的重视、确保和领导的沟通渠道 畅通、经常向领导汇报工作进展。

5）进度风险

有些项目对进度要求非常苛刻（进度要求不高的项目，我们同样要考虑该风 险），项目进度的延迟意味着违约或市场机会的错失。

预防这种风险的办法一般是分阶段交付产品、增加项目监控的频度和力度、 多运用可行的办法保证工作质量避免返工。

6）质量风险

有些项目，用户对软件质量有很高的要求，如果项目组成员同类型项目的开 发经验不足，则需要密切关注项目的质量风险。

预防这种风险的办法一般是经常和用户交流工作成果、品牌管理采用符合要 求的开发流程、认真组织对产出物的检查和评审、计划和组织严格的独立测

7）系统性能风险

有些软件项目属于多用户并发的应用系统，系统对性能要求很高，这时项目 组就需要关注项目的性能风险。

预防这种风险的办法一般是在进行项目开发之前先设计和搭建出系统的基础 架构并进行性能测试，确保架构符合性能指标后再进行后续工作。 （8）工具风险

软件项目开发和实施过程，所必须用到的管理工具、开发工具、测试工具等 是否能及时到位、到位的工具版本是否符合项目要求等，是项目组需要考虑 的 风险因素。

预防这种风险的办法一般是在项目的启动阶段就落实好各项工具的来源或可 能的替代工具，在这些工具需要使用之前（一般需要提前一个月左右）跟踪 并 落实工具的到位事宜。 （ 9）技术风险

在软件项目开发和建设的过程中，战略管理技术因素是一个非常重要的因素 。 项目组一定要本着项目的实际要求，选用合适、成熟的技术，千万不要无视 项 目的实际情况而选用一些虽然先进但并非项目所必须且自己又不熟悉的技术 。 如果项目所要求的技术项目成员不具备或掌握不够，则需要重点关注该风险 因 素。

预防这种风险的办法是选用项目所必须的技术、在技术应用之前，针对相关 人员开展好技术培训工作。

10）团队成员能 力和素质风险

团队成员的能力（包括业务能力和技术能力）和素质，对项目的进展、项目 的质量具有很大的影响，项目经理在项目的建设过程需要实时关注该因素。

预防这种风险的办法是在用人之前先选对人、开展有针对性的培训、将合适 的人安排到合适的岗位上。

11）团队成员协 作风险

团队成员是否能齐心协力为项目的共同目标服务，生产管理是影响进度和质 量的关键因素。 预防这种风险的办法是项目在建设之初项目经理就需要将项目目标、工作任 务等和项目成员沟通清楚，采用公平、公正、公开的绩效考评制度，倡导团 结 互助的工作风尚等。

12）人员流动风 险

项目成员特别是核心成员的流动给项目造成的影响是非常可怕的人力资源 人员的流动轻则影响项目进度，重则导致项目无法继续甚至被迫夭折。

预防这种风险的办法是尽可能将项目的核心工作分派给多人（而不要集中在 个别人身上）、加强同类型人才的培养和储备。

（ 13）工作环境风 险

工作环境（包括办公环境和人文环境）的好坏直接影响项目成员的工作情绪 和工作效率。 预防这种风险的办法是在项目建设之前就选择和建设好适合项目特点财务管 理和满足项目成员期望的办公环境、在项目的建设过程中不断培育和调整出 和 谐的人文环境。

14）系统运行环 境风险

目前，大部分项目系统集成和软件开发是分开进行的（甚至由不同公司承 接 ） 。因此，软件系统赖以运行的硬件环境和网络环境的建设进度对软件系统 是否 能顺利实施具有相当大的影响。 预防这种风险的办法是和用户签定相关的协议、跟进系统集成部分的实施进 度、及时提醒用户等。

15）分包商风险

有些项目管理可能会涉及到将系统的部分功能分包出去，这时项目组就需要 关注项目的分包商风险。

预防这种风险的办法一般是指定分包经理全程监控分包商活动、让分包商采 用经认可的开发流程、督促分包商及时提交和汇报工作成果、及时审计分包 商 工作成果等。

世间万物总是发展变化的，风险亦可能随时出现和变化。项目经理应该将 “防 患于未然 ”牢记于心并作为自己日常项目工作的 “座右铭 ”。项目经理不断培养 和 强化项目整个团队成员的风险意识，是确保项目顺利进展的最有效方法之一 。

以上列举的这些风险，应该是软件项目建设中经常出现的主要风险，但由于 项目本身的个性化特征，针对具体的项目，肯定会出现一些我们上面没有列 举

甚至是事先根本无法预期的风险，这就需要我们项目经理有敏锐的 别它们，从而更好地预防和控制它们。

嗅觉”去识

排 输入 序 风险事件 可能 性 影响 风险 采取的措施 值 1 客户的 sow 2 合同 需求不明确， 增加70% 需求，导 致需求曼延。 进度要求紧， 合同30% 金额和日 期有限。 开发人员对测 试工作不重视 对需求的开放 式系统标准没 有合适的测试 案例 50% 35% 请专业需求分析师和客户代表具体 深入细节的交谈，多了解客户的想 法，站在客户的角度上思考问题。 50% 15% 可以请一些实习的学生做辅助工作， 一来降低成本，二来可以加快进度。 3 历史项 目信息 30% 20% 40% 80% 12% 1 )强制性要求每段代码保留测试 单元，由SQA检查。 16% 找专业的测试公司完成测试工作 4 WBS 5 历史项 目信息 开发人员的流 动 15% 60% 9% 1) 2) 3) 4) 注意项目团队的沟通，及时 了解开发人员的动态。 控制好项目过程中的文档 从其它的项目组解调人员 从外部招聘有过此类开发经 验人员 6 系统设 计没有足够的时 间50% 评审 进行产品测 试 50% 25% 1) 2) 3) 采取加班的方法 修改计划去掉一些任务 与客户商量延长一些时间 培训开发人员 找专家作指导 采取边开发边学习的方法， 要求他们必须在规定的时间 内掌握技术 7 需求和 计划 米用新技术可 能导致进度的 延期 50% 30% 15% 1) 2) 3)

风险分析表 软件项目管理和其它的项目管理相比有相当的特殊性。首先，软件是纯 产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。 软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。幸 时问和预算都是可摔制的，并不是指我们可以控制时间快慢或长短， 知道哪一个时间点，需要何种产出物，而我们有多少的预算町以完 控制，我们需要一个标准的流程，只要照着规矩走，一切都好办。

知 识 其 次， 运 的是， 是如何叫确 成。为了有效