软件项目中的风险和风险管理 摘要： 软件开发是利用软件开发生命周期以适当的方式开发软件的艺术。开发是一 种动态的活动，在这个过程中需要大量的理性思考。随着软件开发变得更加系统 化和工具驱动，风险也在增加。但对风险管理的思考与关注仍然不够。本文针对 影响软件质量和软件过程的 14 个最突出的风险因素，提出了处理方法和规避策 略，并描述了在风险管理中使用的不同框架和范式。 关键词：软件风险管理；风险因素；框架 1.引言 如今，项目管理已经成为所有组织的重要组成部分。为了成功地完成任何项 目，有必要计划和管理项目的所有活动。IT 项目最重要的方面之一是风险。风险 是指所选择的行动或活动(包括不采取行动的选择)可能导致损失(不希望看到的 结果)。这一概念意味着对结果产生影响的选择有时是存在的。潜在损失本身也 可以被称为“风险”。任何人类的努力都有风险，但有些风险更大。这种风险的 定义本身就促进了风险的消极方面。在 IT 或软件项目中，也有积极的风险和机 会。因此，项目风险是一种不确定性，它可以对项目目标的实现产生消极或积极 的影响。风险项目管理包括识别、评估、监测和控制项目可能涉及的风险。风险 与机遇之间应该保持平衡。IT 行业中的软件项目风险是指在软件开发过程中遇 到的预算、进度等方面的问题，以及这些问题对软件项目的影响。软件的项目风 险可能会影响项目计划的实现，如果项目风险变为现实，将会影响项目的进度， 增加项目的成本，甚至使软件项目变得不可行。软件项目开发是一种可能导致损 失的活动。无论如何实施开发过程，超支和延迟都是经常发生的。项目的开发模 式并不能保证项目的最终成功。我们在项目开发过程中必须承担风险，并对项目 风险进行分析。在对项目进行风险分析时，必须注意对每个风险的不确定性程度 和等效损失程度的度量。项目风险管理的目标是将潜在的负风险最小化，同时将 潜在的正风险最大化。风险可分为: 1.已知的风险:在仔细评估项目计划、商业和技术环境以及其他可靠的信息 来源之后可以发现的风险(例如:不现实的交付时间、没有需求、软件文件和糟糕 的开发环境) 2.未知的风险:也许它们真的会出现，但很难提前发现它们。 3.可预测的风险:可以从之前的经验推断出来(例如:人员调整，没有与客户 沟通，开发人员因为维护而分散精力)。 在软件项目开发过程中可能会遇到各种类型的风险: 1.技术风险：包括语言、项目规模、项目功能、平台、方法、标准或过程方 面的问题。这些风险可能来自于过度的约束、缺乏经验、定义不良的参数，或者 依赖于项目团队直接控制之外的组织。 2.管理风险：包括缺乏计划、缺乏管理经验和培训、沟通问题、组织问题、 缺乏权威和控制问题。 3.财务风险：包括现金流、资本和预算问题，以及投资回报限制。 4.合同和法律风险：包括不断变化的需求、市场驱动的时间表、健康和安全 问题、政府法规和产品保修问题。 5.人员风险包括人员配备滞后、经验和培训问题、伦理和道德问题、员工冲 突和生产力问题。 6.其他资源风险包括设备和供应品无法获得或延迟交付、工具不足、设施不 足、位置分散、计算机资源无法获得以及响应时间慢。 2.风险因素及规避策略 软件风险管理不仅要识别风险因素，更要识别风险因素产生的原因及采用手 段规避风险。Pressman 尝试识别软件风险，并提供了 10 个更广泛的风险因素。 Bohme 在他的工作中也提出了十大风险类别。沙赫扎德确定软件风险因素列表， 并确定每个风险因素的相对影响，根据风险因素发生的频率和它们所具有的影响 对其进行了优先排序，因此编制了一份关于其总影响的 18 个风险因素清单。在 列表中确定的风险因素被期望涵盖可能进入软件开发过程的风险的边界范围。人 们强烈认为，特别是风险识别是一个不断进行的过程，显然，随着新技术、人、 环境、管理和环境的出现，风险因素不断增加。因此，要求对整个软件过程中的 所有风险因素进行详尽的识别可能是不现实的。通过计算每个可用风险因素的总 体影响和频率，可用风险因素的有序列表也可在中获得。下面对常见的风险因素 进行简要介绍并给出该风险要素的处理过程或规避方法。 2.1 需求不明确 必须使用多种需求获取方法;这包括问卷调查、访谈和直接沟通。部署在需 求获取上的团队应该能够从来自不同来源的信息组中提取准确的/有价值的信息。 如果预期需求会动态变化，客户必须允许开发团队有一个灵活的时间表。只有不 影响软件体系结构的微小更改可以动态更改。开发团队必须熟悉 Enhanced Information Deployment 技术，以满足客户没有明确提到的默认需求。 2.2 错误估计时间及成本 管理层应该从不同的来源获得多个评估，并根据时间和成本建议一个灵活的 时间表。如果资金和时间不灵活，开发的增量模型可能是一个解决方案。随着时 间的增长，如果资金或时间崩溃，至少有一些东西可以呈现给客户，而不是什么 都没有。开发团队必须设法找到可重用代码的最大数量，可重用代码的可用性将 产生三维的积极影响。它将减少开发时间、成本，以及测试组件所需的资源。有 经验的开发人员和管理团队可以与客户协商，确定是否存在任何可能不会损害软 件整体工作的可删除需求。为了节省时间和成本，可以取消这些要求。在时间和 成本紧迫的项目中，不允许实施工程。 2.3 用户的压力比预期的要大 开发人员必须始终预期并考虑到客户不能够描述所有的需求。如果可能的话， 开发人员必须以一种能够承受额外负担的方式来设计和实现系统。开发人员还必 须进行广泛的压力测试，以确保软件能够处理用户的负载和压力。开发团队可以 在组件级、环境级、体系结构级和端到端级对软件进行压力测试。 2.4 较少的可重用代码或组件 在估计项目成本和资源需求时，开发人员必须知道有多少软件可用来重用， 这应该是一个合理的决定，因为如果不能使用可重用的代码，开发此类代码的工 作将被复制。因为不仅要开发代码，而且要在与其他组件集成之前对组件进行测 试。在可用的开发人员中，最好的开发人员应该被部署来开发组件，从而使预期 的开发和测试时间最小化。 2.5 交付日期时间紧张或变动情况 由于截止日期的压力或新要求的导向，管理者会以某种方式尝试改变环境。 一开始对需求的绝对定义确保了情况保持不变，期限不会收紧。开发公司的开发 团队和管理人员必须具有预见能力，并应努力在不影响公司自身的情况下适应动 态环境。FAST 方法可用于加速需求获取，从而减少期限收紧的负面影响。 2.6 资金流失 为了确保资金问题保持有序，开发团队必须首先确保软件按时开发，按时开 发不仅有助于提高收入和利润，而且还将确保资金在整个软件开发周期中都是可 用的。与资助机构保持友好关系是很重要的。除了与资助机构的友好关系之外， 让资助机构随时了解软件开发过程的进展，以及在这个过程中遇到的任何问题也 是很重要的。了解了问题和成就后，资助机构将在一个更好的地方帮助发展公司 继续资助。 2.7 技术不能满足人们的期望 只有在充分考虑了可用的工具和技术之后，才应该做出技术选择的决定，而 且只能由有经验的从业人员做出决定。在某些情况下，客户可能会允许技术上的 变更，但是这种变更必须不会对软件的质量产生任何负面影响。如果工具的变更 在客户和开发团队之间达成了一致，那么开发团队必须在与客户协商的情况下尽 量选择可用的最佳工具。 2.8 缺乏工具培训或工作人员经验不足 开发公司可以通过为员工提供新兴工具的培训来保持他们的更新。公司可能 会雇佣顶尖大学的应届毕业生，对当前的工具有一定的了解。公司可以对他们进 行培训，并为他们提供一些小任务，以便完成培训，使他们成为公司有用的一员。 为每个项目建立团队是很重要的。发展团队结构不仅有助于提高工作效率，而且 还有助于为新成员提供经验。这也将有助于新成员学习如何流畅地处理繁琐的工 作。 2.9 员工流失 员工，特别是有经验的员工是任何公司的资产，公司通常会尽最大努力留住 这些人。但这是非常明显的，有学问的人还是想换工作，虽然这种趋势可能不会 消除，但可以减少。雇主应该诚实地估计市场上有经验的人的工资。实际经验表 明，员工喜欢与更关心员工家庭的雇主一起工作。雇主可能会提供像，免费家庭 医疗，子女学费，汽车津贴，住房租金等服务，以保持员工的吸引力。雇主应为 员工提供其他社交聚会和会议机会，以帮助在组织中建立家庭文化。这次聚会是 一个很好的机会，让初级职员与公司的高层管理人员见面，并听取他们对公司未 来商业战略的看法和设想。雇主必须努力让员工保持更新，并应该为员工提供机 会来更新他们对新兴工具和技术的知识。这可以通过在他们自己的地点安排课程， 或把员工送到专门的机构进行培训来实现。雇主可推出一项贷款计划，帮助有需 要的人士，并可分期还款，无利率或最低利率。 2.10 未备份或实际文件、数据丢失 备份必须在多个站点进行，以便在任何物理或技术损坏的情况下，备份本身 保持完整。管理部门必须努力在公司引入无纸化环境，这将有助于保持高效、安 全和可追溯的工作环境。备份站点可能会频繁更新，并应定期检查更新情况。团 队约束应该在开发环境中实现，这不仅改善了工作环境，而且还有助于减少对个 人的依赖，因为团队成员保持活跃，并保持对某人在开发中使用的趋势和模式的 了解。这不仅有助于在团队成员中引入和谐，也会提高工作环境的效率。 2.11 火灾、洪水等自然灾害 公司必须确保整个组织的工作环境不仅有利于员工，而且对员工是安全的。 建筑物内必须安装适当的烟雾探测器和火灾警报器，以探测火灾，并提供紧急出 口，以防发生紧急情况。组织还必须确保建筑规范得到遵守，结构符合规定的标 准。随着近年来世界地震频发的趋势，建筑结构的发展也很重要，它能使建筑结 构在一定程度上减轻地震的冲击。 2.12 开发错误太多 尽管测试技术可以帮助识别错误，开发团队必须努力工作准确而且连续检查 所做的工作。由开发人员必须审查由一些资深的同事,以便在不造成严重危害的 情况下，尽早提供指导意见并进行修正。随着检查的可用性，开发人员必须对他 正在开发的软件进行单元测试，必须确保代码没有错误，并且满足需求。有时， 在一段代码中会发现很多错误，纠正这些错误不仅会浪费时间，还会浪费资源。 在这种情况下，重新开发该组成部分可能比纠正现有的组成部分更容易。同样重 要的是，测试过程要运行良好，例如，与忽略错误相比，识别出太多错误的危害 仍然较小，因为识别出的错误可以以某种方式处理。 2.13 删库跑路 在任命时，人力资源(HR)部门必须确保他们正在雇用的人是足够可靠的，并 有良好的工作历史。他的信誉可以向以前的雇主查证。雇主提供的联系方式必须 在雇员被永久聘用之前进行核实。备份必须在多个站点进行，以便在任何物理或 技术损坏的情况下，备份本身保持完整。备份站点可能会频繁更新，应该对更新 进行检查。 2.14 缺乏“直觉” 据观察，经验丰富的个人可以帮助估计任何项目的成本、预算和人力，只要 使用他们的直觉。他们提供的猜测一般是准确的，从而给组织带来巨大的利益。 组织必须做足够的努力来留住这些人，并且应该继续从他们的经验中受益。有才 能的人必须与有经验的人一起工作，这样他们就可以学习如何利用之前的知识和 直觉进行评估。 3.风险管理模型 3.1 SRE 的项目风险管理模式 由软件工程研究所(SEI)开发的模型如图 1 所示。这种方法以分类问卷的形 式集中于项目中的所有风险领域。SRE 不仅是一个项目的诊断工具，也是一个项 目的决策工具。这种技术处理来自产品、过程和约束的风险。它识别那些风险并 对项目风险声明进行分类。SRE 提供了清晰易懂的项目风险图。它诊断风险，并 决定启动一个项目是否存在可接受的风险。为了在风险成为项目威胁之前识别风 险，SRE 创建了风险基线。它还可以重置项目的风险基线。它按照 SEI 标准工作， 并处理 SEI(软件工程学会)风险范式的识别、分析、计划和沟通元素。SRE 活动 也完全涵盖了分析风险元素。在可持续发展战略中，制定高级别缓解战略计划部 分涉及规划要素。SRE 对沟通元素也有重要的作用。 图 1 SRE 的项目风险管理模式 Identify：在能够管理风险之前，必须在对项目产生不利影响之前识别风险。 建立一个鼓励人们提出关注和问题的环境，并在项目的所有阶段进行质量审查， 是识别风险的常见技术。 Analyze：分析是将风险数据转换为风险决策信息。它包括审查、确定优先 级和选择要处理的最关键的风险。软件风险评估(SRE)团队根据其对成本、进度、 性能和产品质量的影响来分析每个确定的风险。 Plan:计划将风险信息转化为当前和未来的决策和行动。规划包括制定应对单个 风险的行动，确定风险行动的优先级，并创建风险管理计划。风险行动计划的关 键是考虑今天所做决定的未来后果。 Track：跟踪包括监视风险的状态和为降低风险而采取的行动。 Control：风险控制依靠项目管理过程来控制风险行动计划，纠正计划的变 化，响应触发事件，并改进风险管理过程。风险控制活动记录在风险管理计划中。 Communicate：沟通贯穿于风险管理的所有职能。没有有效的沟通，就没有 可行的风险管理方法。它是所有其他风险管理活动的组成部分。 3.2 团队风险管理过程集 团队风险管理定义了在软件开发计划生命周期的所有阶段中管理风险的组 织结构和操作活动，这样，直接参与计划的组织、团体、部门和机构中的所有个 人都是参与团队的成员。通过采用团队风险管理，政府和承包商提供了过程、方 法和工具，使两个组织，单独或联合，在决策过程中日益预期。这种技术确保了 在整个项目中以迭代和协作的方式进行持续的风险管理。团队风险管理的过程也 通过四个过程来处理 SEI 范式的所有五个步骤。它将 SEI 标准的识别和分析步骤 结合到日常的风险识别和分析过程中。风险不仅存在于一个阶段，而且可能出现 在项目的整个生命周期中。所以这项技术是一个识别和控制风险的连续过程。在 这里，团队风险管理执行一组连续循环的计划活动，以管理风险。 图 2 团队风险管理过程集 TRM 的工作流程是:识别风险，定期审查和分析新的风险，计划合理运用资 源缓解风险，跟踪风险和风险常态化行动，开始控制转变为问题的风险，最后开 始项目中所有伙伴之间的风险沟通。 3.3 项目风险管理框架 另一个模型表明，风险管理包括两个主要活动，风险评估和风险控制，每个 活动都有三个附属步骤，如图 3 所示。风险识别生成可能影响项目成功的项目特 定风险项列表。风险分析和风险优先级通过评估每个风险项的损失概率和严重程 度，对确定的风险项进行排序。风险管理计划通过定义减少风险的任务、职责、 活动和预算等来定义如何在一个特定的项目中减少风险。风险减少活动必须考虑 到过程、组织和技术。风险解决会产生风险项被消除或以其他方式解决的情况。 风险监控包括跟踪项目的进展，以解决其风险项，并在适当的地方执行纠正活动。 图 3 项目风险管理框架 3.4 项目风险管理流程 图 4 说明了风险管理流程。这个过程从识别潜在风险列表开始。然后对每一 个风险进行分析和排序。创建风险管理计划，确定将降低风险发生概率和/或降 低风险转变为问题时的影响的遏制措施。该计划还包括在风险变成问题时将采取 的应急行动以及相关的触发器(指示风险变成问题的指示器)。然后执行计划的控 制部分并采取行动。跟踪步骤包括监测已知风险的状态以及降低风险行动的结果。 如果触发器指示问题的出现，则执行相应的应急计划。随着获得新的状态和信息， 风险管理计划也相应更新。跟踪还可能导致新识别的风险的增加或已知风险的关 闭。 图 4 项目风险管理流程 3.5 风险管理流程 另一种方法认为，风险管理有以下 6 个步骤: 1.Planning risk management：决定如何处理和计划项目的风险管理活动。 2.Identifying risks：确定哪些风险可能会影响项目，并记录每个风险的特征。 3.Performing qualitative risk analysis：根据风险发生的概率和影响对其 进行排序。 4.Performing quantitative risk analysis：用数值方法估计风险对项目目标的影 响。 5.Planning risk responses：采取措施增加机会，减少实现项目目标的威胁。 6.Monitoring and controlling risks：监控已识别和残留的风险，识别新的风险， 执行风险应对计划，评估项目整个生命周期风险策略的有效性。 图 5 风险管理流程 4.总结 软件开发过程是复杂的，需要有效地处理可用的资源。糟糕的计划会带来难 以处理的风险因素。一旦在软件过程中确定了风险，本文就提出了避免或克服风 险的可能策略。虽然不可能列出一份完整的软件风险因素清单，但随着新工具和 技术的发展，风险因素会不断增加，因此我们会考虑列出一份完整的软件风险因 素清单，以提供有关处理和规避机制的知识。本文也描述了各种软件项目风险管 理框架。这些模型或框架作为指导项目经理执行有效风险管理的工具。那些开发 中小型软件的软件公司尤其可以通过遵循规避策略或应用风险管理模型或框架 而受益。