软件度量模型比较（总结）

1 Barry Boehm的模型

     Boehm用公式RE=P(UO)*L(UO)对风险进行定义，其中RE表示风险或者风险所造成的影响，P(UO)表示令人不满意的结果所发生的概率，L(UO)表示糟糕的结果会产生的破坏性的程度。在风险管理步骤上，Boehm基本沿袭了传统的项目风险管理理论，指出风险管理由风险评估和风险控制两大部分组成，风险评估又可分为识别、分析、设置优先级3个子步骤，风险控制则包括制定管理计划、解决和监督风险3步。

    Boehm思想的核心是10大风险因素列表，其中包括人员短缺、不合理的进度安排和预算、不断的需求变动等。针对每个风险因素，Boehm都给出了一系列的风险管理策略。在实际操作时，以10大风险列表为依据，总结当前项目具体的风险因素，评估后进行计划和实施，在下一次定期召开的会议上再对这10大风险因素的解决情况进行总结，产生新的10大风险因素表，依此类推。

    10大风险列表的思想可以将管理层的注意力有效地集中在高风险、高权重、严重影响项目成功的关键因素上，而不需要考虑众多低优先级的细节问题。而且，这个列表是通过对美国几个大型航空或国防系统软件项目的深入调查，编辑整理而成的，因此有一定的普遍性和实际性。但是它只是基于对风险因素集合的归纳，尚未有文章论述其具体的理论基础、原始数据及其归纳方法。另外，Boehm也没有清晰明确地说明风险管理模型到底要捕获哪些软件风险的特殊方面，因为列举的风险因素会随着多个风险管理方法而变动，同时也互相影响。这就意味着风险列表需要改进和扩充，管理步骤也需要优化。

    虽然其理论存在一些不足，但Boehm毕竟可以说是软件项目风险管理的开山鼻祖。在其之后，更多的组织和个人开始了对风险管理的研究，软件项目风险管理的重要性日益得到认同。

2 SEI的CRM模型

SEI（Software Engineering Institution）作为世界上著名的旨在改善软件工程管理实践的组织，也对风险管理投入了大量的热情。SEI提出了持续风险管理管理模型CRM（Continuous Risk Management）。

    SEI的风险管理原则是：不断地评估可能造成恶劣后果的因素；决定最迫切需要处理的风险；实施控制风险的策略；评测并确保风险策略实施的有效性。

    CRM模型要求在项目生命周期的所有阶段都关注风险识别和管理，它将风险管理划分为5个步骤：风险识别、分析、计划、跟踪、控制。图2-2所示的框架显示了应用CRM的基础活动及其之间的交互关系，该活动在项目开发过程中反复持续的进行。每个风险因素一般都需要按顺序经过这些活动，但是对不同风险因素开展的不同活动可以是并发的或者交替出现的。

3团队风险管理（Team Risk Management)

团队风险管理在风险管理中加入了面向团队的活动，这些活动涉及投资和供应双方，通过投资方和供应方共同实施风险管理。团队风险管理建立在过程、方法和工具之上的环境中，在这个环境中投资方和供应方可以协同工作，在软件系统的整个生命周期中持续地进行风险管理。它也建立在前面讨论过的风险管理的七条原则之上并依赖于团队精神。在这七条原则的指导下，团队风险管理扩展了SEI的风险管理模型，在模型中加入了两个功能——初始化和创建团队。各个风险依次通过这些功能，在整个项目生命周期中活动是持续、同时、重复发生的。

SEI最初制定的风险管理原则只有五条：全局观察，前瞻性，开放式交流，集成管理和持续的过程。此时，投资方和供应方都在其各自的范围内实施风险管理。随着系统开发的进行，投资方和供应方都会产生对项目成功所必须的直接和最终结果的看法。不幸的是，所有经常出现的结果，虽然为双方所共享，但是往往被其中的任一方提前关注。而那些先前未见到的事情往往会扭曲系统的进展和最终结果。为了解决上述问题，SEI开发团队风险管理在最初的五条原则的基础上又加入了两条原则：共享产品视图和团队精神，扩展了开放式交流，从而形成了目前风险管理的七条原则。团队风险管理建立在项目所有层次间协同工作的环境中，项目组的每个成员均有能力且主动地在风险发展成问题之前去发现并处理它们。因此，借助于团队风险管理，投资方和供应方通过协作、共同通过管理项目风险而预知或避免问题的发生。

4 基于Leavitt模型的风险管理

    SEI的CRM和Boehm的模型均以风险管理过程为主体，研究每个过程所需要的参照信息及其操作。而Aalborg大学提出的思路则是以 Leavitt模型为基础，着重从导致软件开发风险的不同角度出发探讨风险管理。  

    1964年提出的Leavitt模型将形成各种系统的组织划分为4个组成部分：任务、结构、角色和技术。这4个组成部分与软件开发的因素对应起来：角色覆盖了项目所有的参与者，如软件用户、项目经理和设计人员等；结构表示项目组织和其它制度上的安排；技术则包括开发工具、方法、硬件软件平台；任务描述了项目的目标和预期结果。Leavitt模型的关键思路是：模型的各个组成部分是密切相关的，一个组成部分的变化会影响其它的组成部分，如果一个组成部分的状态和其它的状态不一致，就会造成比较严重的后果，并且可能降低整个系统的性能。

    将这个模型和软件风险的概念相对应，即一个系统开发过程中任何Leavitt组成成分的修改都会产生一些问题，甚至导致软件修改的失败。根据Leavitt模型，任何导致风险发生的因素都可以归结为模型中的组成部分，例如技术及其可行性；或者归结为组成部分之间的联系，例如程序开发人员使用某一技术的能力。因此，使用Leavitt模型从4个方面分别识别和分析软件项目的风险是极其有条理并且比较全面。在进行软件项目管理时，可以采用不同的方法对不同方面进行风险管理。

    Leavitt模型实际上是提出一个框架，可以更加广泛和系统地将软件风险的相关信息组织起来。Leavitt理论的设计方法和实现研究已经广泛应用于信息系统中，它所考虑的都是软件风险管理中十分重要的环节，而且简单、定义良好、适用于分析风险管理步骤。

5 SEIRM(Software Engineering Risk Model)模型

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

该模型的主要目的是识别、分析、交流和消除技术风险。技术风险包括：潜在的设计、界面、实现、验证和维护的问题；二义性，技术上的不确定性，过时的技术和主要的边缘技术。用风险分类学和基于分类的问卷来识别开发中的商业风险，商业风险包括：市场风险，产品风险，管理风险和预算风险。

优点：提供的关于风险管理的数据来源于大量的实际经验，表明了实际开发中的经验在此后软件开发中所起的重要作用，对他们有重要的指导意义和实施开发的依据。

缺点：经验的获取需要一定的时间积累，对于新公司或开发不规范的公司来说，没有经验数据的积累减小了其适用范围。

6 MSF 风险管理过程

MSF 风险管理原则提倡前摄的风险管理、持续的风险评估以及项目或操作生命周期的决策集成。风险被持续地评估、监控和积极地管理，直到被解决或是转化为可以处理的故障为止。图2-4中描述的MSF 风险管理原则定义了项目团队管理现有的风险、计划、执行风险管理策略以及为企业获取知识过程中的六个逻辑阶段。分别是：识别，分析和分级，计划和调度，跟踪和报告，控制和学习。

优点：将以前的开发经验作为风险管理的一个阶段，有力的说明了以前开发经验对以后开发工作的重要指导意义。

缺点：团队合作现在已经成为软件开发过程中不可忽略的一个重要组成部分，对开发的成功与失败有重大的影响，尤其是在当今的软件开发过程中更是如此，而在该模型中却未能清楚的表现出来。