在项目策划中，项目评估已经成为最有风险的方面之一。这并不是因为评估人员普遍地不合格或者缺乏见识－－主是因为在软件项目评估时，必须考虑越来越多的复杂性和依赖关系。由于软件项目、软件产品和 IT 环境不可避免地变得越来越复杂，因此评估项目的费用和项目的进度变得越来越难。与这个挑战对应的是，作为很多评估技术的基础的那些已经建立的参数，将不再普遍适用，或者能够象以前那样简单地计算。因此很多评估人员正在寻找那些能产生更精确结果的方法。

在第 1 部分，我将调查那些得到评估专家们支持的评估方法、技术、模型和工具，以及一些有趣的、似乎有光明前景的方法的革新。在第 2 部分，我将讨论不同的评估情况，即在什么环境下最好采用什么样的方法，以及如何最有效地使用这些方法。

为什么需要评估

在日常的生活中，我们人类往往不断地进行评估。我们评估一件事情花多长时间，一件事情花多少钱，餐后甜点中有多少卡路里，等等。对于一个组织来说，评估同样是至关重要的，因为它的经济可行性很大程度上依赖于决策者做出的决策的质量。业务决策人员基于以下的原因进行评估：

• 预算。预算不仅仅是与如何花银行帐号里的钱有关，而是关于如何对现有资源和未来资源进行战略性分配，给组织争取最大的利益。您计划花费的现金可能还没有准备，而且很有可能永远也不会准备好－－这就是评估人员需要试图预测的一个因素。
• 项目策划。对软件项目来说，评估是预测项目费用、进度和资源的一部分，也是企业的目标之间达成一致的平衡过程。评估对于内部项目的策划和执行也是十分重要的，因为它们影响项目的生命周期（迭代、增量等等），甚至影响最终的项目成果和人员的生产力。
• 风险管理和权衡分析。在企业的风险分析和管理中，评估是一个主要的因素，因为每个企业的决策都要对事件的活动做出假定，而这在很大程度上是基于评估的。
• IT 基础架构和过程改进分析。对于企业架构的实施和管理来说，评估是不可或缺的一部分，主要包括评估对企业过程改进的选择，以及他们对其它过程的影响，也包括对软件、硬件和服务是开发还是外购的选择的考虑。

评估的方法、技术、模型和工具

在早期的 IT 开发中，人们发明了简单的方法来评估软件开发工作。那时总的来说，软件评估是一个有代码行和人员数目组成的线性方程。随着IT的特征和任务变得越来越复杂，评估技术也应用于这些软件项目。这些简单的技术在使用单一编程语言环境时能够工作，但是在现在的与以前不同的环境中不再适用了。 这就需要考虑更多的因素，包括已经出现的多种平台和应用程序框架、IT 服务的日常化和 IT 项目的规模和复杂度的不断增加，这些因素促进了评估技术的发展和迅速引入非线性参数。

为了应对这些日益增长的评估挑战，改革者想出了很多方法和技术，有一些基于数学模型，其它的则利用人的因素。图1 分类列出了很多可用的评估资源。

图1：评估的资源

自顶向下和自底向上的评估

或许在评估的最根本方面，不仅仅在软件开发中，而是在几乎所有项目中，都是从自顶向下和自底向上这两种评估策略中选择一种（见图2）。自底向上的计算方法先单独评估不同的项目活动，然后求和。而自顶向下的方法则基于把项目作为一个整体，评估项目的所有活动。

图2：自顶向下和自底向上的评估

自底向上的方法

在早期的IT编程中，大部分软件的评估使用自底向上的方式。一个关键的评估变量是手工编写的代码行数，它被用来计算项目的总规模。其它的关键变量是开发人员生产力，这也很容易量化。随着引入了多种编程语言（C, Pascal, Ada, Lisp等等），编程方法（面向对象、基于模板等等）、硬件架构和平台，以及代码产生工具，情况开始发生变化。

与后面要讨论的自顶向下的方法相比，自底向上的方法一般被认为更直观、更不容易出错。在部件能够很好地隔离的情况下，它可以产生非常准确的评估。然而，如果只使用自顶向下的方法，非常容易忽略那些重要的系统级的限制和费用，在没有足够的需求数据的情况下尤其如此。

自顶向下的方法

自顶向下的方法，又称为宏观模型。它先划分项目范围，然后用特定组织或者业界的平均水平评估费用，并评估与项目各部分的实现和他们之间联系相关的复杂度。

自顶向下方法的与众不同的特色是它把重点放在整个系统的属性，如集成、变更管理、增量发布等等。然而正如上面提到的，单纯的自顶向下的方法不如自底向上的方法更加能够关注级别较低的因素，如项目的具体问题、应用设计的特点、实施的细节等。这些因素往往迅速累计并很大程度上影响评估的准确性。

流行的评估技术和模型

尽管这些技术没有明确说明，下面讨论的技术通常都是自顶向下和自底向上的方法的结合。

所有的评估技术可以分为以下三类：基于经验的模型、面向学习的模型和基于算法（统计或数学）的模型。

基于经验的技术

基于经验的技术主要依赖于相关的主题专家或专家组的主观判断（见图3）。

与那些比较严格的参数模型相比，这类技术主要依靠人的经验和洞察力，这也是这类技术的主要缺点。这一点可以通过扩大评估人员的规模来得到改善。

图3：基于经验的评估

Delphi 技术

在 Delphi 技术中，要求一组主题专家对一个问题进行评估。在第一轮评估中，每个专家给出独立的评估，不和其它专家交换意见。对第一轮结果进行收集和整理之后，专家们再进行第二轮评估。这时专家可以和其他专家交换评估信息和意见。这轮过后，大家的结果应该更加靠近，原因是一些差别较大的相关问题被专家们更仔细地考虑，并修正他们的评估。经过几轮之后，大家应该达成基本一致的评估。

工作分解结构（Work Breakdown Structure, WBS）

更加结构化的基于经验的评估是工作分解结构技术。为了进行评估，这个技术建立方案的结构化的模型，并对实现方案的过程进行分解。这些结构基于高层解决方案的架构和项目计划来确定，然后可以他们分解为一个个的小的单元，这些单元可以描述和测量（见图4）。对每个单元进行评估，所有评估的总和即为总的方案的评估。

图4：工作分解结构
点击放大

面向学习的技术

各种研究表明，超过四分之三的软件评估都是构建在对以前完成的方案的分析和比较之上的－－也就是说他们利用了称为面向学习的评估的技术。尽管从直观上非常类似于基于经验的技术，但面向学习的技术采用了不同的角度。它们的目标是寻找某种类似的完成的系统，通过了解新的系统与已经完成的系统的属性的不同，对新的系统进行外推的评估（见图5）。

面向学习的技术的最明显的优势就是，它们的评估是基于已经证实的特性，而不是象基于经验的评估那样仅仅依靠经验。这种技术的限制是需要确定用来描述方案的最重要的变量，以及它们与基线的区别。这些目标的达成有可能很困难，或者非常耗时。

图5：面向学习的评估

案例研究

在案例研究技术中，评估人员使用课程，并从调查与要构建的系统类似的例子进行启发式的学习。这个过程包括以下步骤，最后形成评估结果。

• 第一步，对于方案的原则特性达成一致，这些特性包括方案的基本特点和要发布的关键点。
• 第二步，从组织（或其他地方）的知识库中选择参考方案，这些方案的核心特征与第一步中得到的特性应该一致或者接近。
• 第三步，通过与已有的方案的架构比较，确定新方案的独有的特征。
• 第四步，针对新方案独有内容，对评估模型进行必要的调整。
• 第五步，使用第四步中调整过的模型进行评估，得到结果。

算法的方法

算法的方法使用数学模型。它们使用历史的、经过计算的或者统计的度量数据和环境因素作为输入，产生已知准确性范围和程度的评估。度量数据包括代码行、功能个数等等。环境因素则包括编程平台、框架、硬件平台和设计方法等等。由于它们能够接受不同的度量数据，这类方法也称为基于度量的方法（见图6）。

不象那些非算法的技术，算法的方法可以产生可重复的评估，而且它们很容易进行调整。当然，这些方法对不准确的输入数据更加敏感，如果不进行适当的校准和调整的话，将产生很差的评估结果。当然这些方法也不能有效处理特殊的情况，如员工能力很强、员工很懒惰，以及团队能力特别强或者特别差的情况。

图6：算法评估

对任何企业决策来说，费用可以说是最重要的因素。因此很多算法方法都面向费用评估。费用本身也可能是产品的其它要素，包括产品工期，资源环境等。

COCOMO 和 COCOMO 2.0

COnstructive COst MOdel，即COCOMO模型，使用一个简单的公式把需要的人月工作量（Man-Months Of Effort，MMOE）与交付的千行源码（Thousands Of Delivered Source Code Instruments，TODSI）联系起来。这个公式是：

MMOE = K1*(TODSI)^K2

这里的 K1 和 K2 取决于环境和设计上的制约因素，如规模、可靠性和性能，也有项目的制约因素，如团队在技术和方法上的专长和经验。模型创建者的想法是在整个项目执行中可以进行多次计算，每次都会产生更精确的结果。

随着更多的过程模型、技术和方法的出现，原始的 COCOMO 模型，由于它仅仅基于软件代码行（Software Lines of Code ，SLOC)），很快地失去了对评估人员的价值。这就导致了 COCOMO 2.0 的诞生。

COCOMO 2.0去掉了原来的模型的缺点，就是只考虑 SLOC。新的模型包括一个动态的可调整的规模的模型。这个版本包括对象和方法点、功能点和代码行。模型根据已有的不同设计模式（如面向对象、基于组件、基于 CTOS、原型等等）、使用的开发方法（RUP、XP、SCRUM、瀑布等等）和项目类型（维护、全新开发、再工程等）进行校准。 COCOMO 2.0也包括一套反映对规模和成果的潜在影响的校正因数。这些内容可以增加评估的准确性，当然，要使用它们需要更高层次的知识。

软件生命周期模型

另一个主流的费用模型是 Putnam 的软件生命周期模型（Software Lifecycle Model，SLIM）。

它主要依靠 SLOC 和项目人员分布的 Raleigh 模型（见图7）。 Raleigh 的基本公式把 SLOC 与需要的开发时间（Required Development Time，RDT）用一个称为技术常数（Technical Constant ，TC）的系数联系起来：

TC = SLOC*TPM^1/3*RDT^4/3

这里的 TC 是方法的核心，因为它可以帮助跟踪环境因素。经过计算后，它的范围可以从很差的200到很优秀的12000。

从前面的公式可以导出：

TPM=1/RDT⁴*(SLOC/TC)³

经过上面的公式进行计算后，评估的结果可以使用 Raleigh 曲线（图7）进行微调。评估人员可以操作两个参数进行调整：slope，表示初始人力（initial manpower buildup，MBI），以及生产力因数（productivity factor，PF）。这个方法提供了两种方式来设置这些参数的值，要么使用过去项目的平均值，要么通过回答一系列基本问题来确定。

这种模型与原始的 COCOMO 存在同样的缺点：它需要有能力推算出要实现的软件的 SLOC。因为这很不容易计算，特别是在项目开始阶段，由于在几乎每个现代系统中，都有很大一部分可执行代码由独立的部件或中间件产生或者重用，因此使用这种方法很难达到可接受的准确度。

图7：项目人员分布的 Raleigh 模型

功能点分析

为了计算人月的成果以及总人月成果，COCOMO 和 SLIM 都需要评估人员计算 SLOC，但这在现代的各种不同的IT环境下是不可能的任务。这就是为什么自顶向下和自底向上的方法、专家经验、学习和基于模型的技术能够共同使用的原因，而且它们也应该一起使用。这一点将在后面讨论。

功能点分析是一个重要的选择方案，它基于对更加具有技术无关性的功能点的概念的评估。具体来说，功能点可以表示任何东西，从使用用例和业务过程到服务和Web页面。

在基于功能点的方法中，功能点的计算包括以下因素：外部输入个数、外部输出个数、外部查询数、内部文件数和外部接口数，每个因素有三个复杂度因子：简单、中等和复杂。计算功能的数量，结果也称为功能计数（function count ，FC），然后在乘以前面指定的复杂度因子，最后得到总的功能点计数（见图8）。然后这个值再用环境复杂度进行调整，这里的环境复杂度由14个表示环境的不同方面的加权因子表示。最后的功能影响因子最大可能达到0.35。

图8：基于功能点分析的评估

使用功能点来代替代码行进行分析的主要优点是，功能点可以从需求、分析、设计规格导出。另外功能点方法允许从特定的语言、方法或技术中抽象出来，并且对非技术人员、外部利益相关者和用户来说，它很容易理解和解释。

最流行的功能点评估方法有 ESTIMACS 和 SPQR/20。

SPOR/20对基本的功能点分析进行了扩展，它按照算法、代码和数据的复杂度把功能点分为不同的类别，每个类别在评估过程中有不同的权重。在基于功能点计算出总的费用以后，这种方法会要求评估人员回答一系列的问题，从“项目目标是：a) 原型，b) 可重用模块”到“期望的响应时间是多少”。根据这些回答，该方法计算出风险因子，用来调整最后的结果。

而 ESTIMACS 则把重点放在关键的“业务因素”。它引入了所谓“评估维度”的概念，这些维度是一些对业务至关重要的内容，包括工作时间、人员数量和成本、硬件、风险和投资的影响。ESTIMACS 也包括项目因素的类别，如“工作时间”分类下有“客户复杂性”、“业务功能的规模”。这可以让您把“评估维度”同用功能点表达的系统的主要功能部分联系起来。另外，除了这些内容，ESTIMACS还支持增量的评估方法，它把评估过程分为三个阶段，并形成紧密的循环（见图9）。

图9：ESTIMACS方法的三个阶段

新出现的技术和模型

尽管 COCOMO、SLIM 和 FC 技术是最常用的评估方法，关注一些新出现的有前途的模型和技术也是很重要的。

神经网络

由于 IT 架构的复杂度越来越高，评估的技术和方法也就更为复杂。一个最新的在评估中使用的技术是神经网络。这个技术具有“包装”功能点和其它基于方程的算法的能力。由于它允许您基于历史数据动态调整底层的算法，因此这是一种很有前途的方法（见图10）。

图10：神经网络评估
点击放大

有意思的是，神经网络是一种对学习型评估的进化，算法经过训练后其行为就像是一个人类专家。

当今的趋势是评估工具在向过程工具靠拢（例如在IBM® Rational® Method Composer过程框架中有一个评估部件）。同样，过程工具现在与设计工具和投资管理工具也日益紧密结合。对评估人员来说，这些趋势意味着他们能够得到更一致和及时的数据，他们将走向神经网络的美好的未来。

动态评估技术

动态评估技术强调项目状态在整个项目执行期间在不断地波动，这将影响软件开发的生产率，这在很多评估方法中是一个核心要素。因此，评估不能只局限于项目过程中的有限的几个快照，而是应该持续不断地、动态地采集项目数据。

给项目动态行为建模的一种方法是使用图来描述评估模型的结构。在基于图的模型中，节点作为项目的可变因素，而边则表示影响这些因素的信息流。使用这样的图，您可以知道一个项目因素是如何影响其它项目因素，并最终影响开发速率的（见图11）。

图11：系统动态模型

基于回归的技术

当存在大量可供分析的数据时，基于回归的技术是最有帮助的。这些技术，包括“标准回归”和“鲁棒回归”，使用大量的数据进行统计分析，以调整他们的模型。正如他们的名称表示的那样，这些方法使用不断变化的项目的实际经验数据来校准基本模型，这些基本模型可以使 COCOMO、COMOMO 2、或者 SLIM（见图12）。

图12：基于回归的评估技术

混合技术

为了做出最好的评估，更可取的办法是把算法、统计、基于经验的和面向学习的评估技术组合在一个单一的方法中。这种方式将适合解决方案和项目的特点，并且可以针对具体的情况选择最合适和最灵活的方法选择。

混合方法的一个很好的例子是 Bayesian 分析技术，它允许评估人员以一致和可预期的方式来使用项目数据和专家的分析。这个方法的核心有统计和基于经验的过程，这些过程基于以前的经验和观测数据尽量去预测项目的参数。首先，使用一个标准的方法或技术产生一个评估的基数。有了基数后，评估人员计算最后的实际值和基数匹配的概率。计算的概率然后应用于最后评估的基数中（见图13）。

图13：基于概率的评估
点击方法

虽然混合评估方法仍处于初级阶段，可以期望在不久的将来它会有积极的发展。

评估工具

数量越来越庞大的评估技术和方法的出现，使得有可能产生广谱的评估工具。起初，评估工具集中在单一的方法和技术。但很快，复杂多变的IT现实意味着单一技术不能够普遍应用，而且没有任何成功的希望。

目前广泛应用于很多机构的工具有：COCOMO II、CoStar、CostXpert、ESTIMATE Professional、KnowldgePlan、PRICE-S、SEER、SLIM、以及SoftCost。其它过去常用，现在仍然使用的工具有：COCOMO、CheckPoint、ESTIMACS、REVIC、以及 SPQR/20。表1给出了一些流行的评估工具的简要描述：

结论

仅仅认识到可用的技术和工具的类型对于您成为评估专家是不够的。准确的评估需要在目标业务、技术和工作领域等方面的经验，以及对什么技术能够合理地在应用在什么情况下的清晰的理解（这一点将在第 2 部分中描述）。评估是一个非常有风险的事情，误差可以有很大的波动。这些误差是由于多种因素造成的，其中有些因素甚至很难预测，更不要说计算了。

不过，有一点是很重要的，就是理解评估的依赖性和及时的数据的需求，以便避免过高或者过低评估以及给出具有合理程度的、实际精度的评估结果。第 2 部分会谈到更多的内容。

致谢

这里作者要感谢 ActionInfo Consulting 的 Larry Simon 和 Cal Rosen，他们在各自专长的工作领域给本文提供重要的内容。

注释和参考

1. 阅读更多的有关使用 TOGAF 和 RUP 将本文中的企业架构和解决方案实现结合起来的内容：“TOGAF 或非 TOGAF：在 RUP 之上扩展企业架构”。
2. 此文来自于 Rational Edge，提供了增量评估实践的有益总结： Estimating use-case driven iterative development for "fixed-cost" projects。
3. 尽管有点过时，由 Barry Boehm 和 Chris Abts 所坐的此篇文章仍然是软件开发成本评估方法的一个优秀的纵览： Software Development Cost Estimation Approaches – A Survey。
4. 由 Liming Wu 所作的一篇优秀的评估方法对比文章： The Comparison of the Software Cost Estimating Methods。
5. 由 Amit Bhagwat 所作的来自于 Rational Edge 此篇文章提供了一种在迭代化，用例驱动评估的“关注成本”项目方面的观点： Estimating use-case driven iterative development for "fixed-cost" projects。
6. 另外一个在预测迭代化项目上的有趣观点： Predicting Iterative Projects。
7. 由 Chris F. Kemerer 所作的此篇研究文章包含了软件成本评估模型的基于经验的验证：An empirical validation of software cost estimation models。
8. IBM Rational Method Composer 产品库提供了指南和有用的建议：Product library: Rational Method Composer。
9. 这是由 Cutter 专家所写的有关评估的许多文章之一。这篇文章值得一看，但是可能要求付费订阅： Business and IT Alignment: Estimating the Costs of the Initiative

参考资料

学习

• 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
  
  
• 您可以参阅 Rational Edge 电子月刊中文版 的其他文章。
  
  
• 您可以参阅 本系列的第二部分：企业范围的软件评估，第 2 部分：评估的生命周期。
  
  

讨论

• 一个 新论坛 已经专门创建用于 Rational Edge 文章， 因此您现在可以共享您对本文或其它在当前问题或我们的档案上的想法。阅读您的遍及世界的同事所阐述的言论，阐述您自己的讨论，或者加入进行种的讨论。点击 这里开始。
  
  
• 全球 Rational 用户组社区
  
  

关于作者

Vitalie Temnenco 是加拿大安大略省工作场所安全与保险委员会的架构师。他主要负责项目实施方面的架构指导，以及帮助团队建立RUP和企业架构的概念。他的经历包括在不同的业务领域为客户提供架构和构建解决方案 ，这些领域有银行、金融、保险、零售和电信业。在这期间，他教授客户，在构建新系统时如何有效地使用UML和RUP进行业务和系统分析。在业余时间，他在方法论、框架和技术方面写一些罕见的、非标准的和创新的应用。他的联系方式为：vit@umlconsulting.com

为本文评分

评论

回页首

内容

• 为什么需要评估
• 评估的方法、技术、模型和工具
• 流行的评估技术和模型
• 新出现的技术和模型
• 评估工具
• 结论
• 致谢
• 注释和参考
• 参考资料
• 关于作者
• 建议