导读：
级别： 初级
Vitalie Temnenco, 架构师, Uniserve Communications Corporation
2007 年 9 月 17 日
本文来自于 Rational Edge：本文是两部分的系列文章的第 2 部分，对在软件开发项目生命周期的特定阶段使用什么评估方法提供了一些建议，以及一些如何更有效地使用这些方法的技巧。本文第一部分介绍了软件项目评估中使用的方法、技术、模型和工具。
来自 The Rational Edge。
我在软件开发项目实践中学到的一件事情是，很多人可以使用来自评估领域的复杂的术语产生超出他们实际能够做到的精度和准确度的评估。这样做的一些原因是由于个体的技术不同，或者存在来自商业、技术或操作方面的偏见。也有一部分原因是缺乏这方面的广泛的知识和经验。评估的工具和方法有很多种，但是很难应用在特定的软件项目中。
在本文 第 1 部分我介绍了软件开发项目评估中使用的技术、模型和工具。现在，在第 2 部分，我将讨论在软件开发项目生命周期中何时和如何最好地使用这些评估方法。我也会讨论一些能够帮助您避免错误的通用的最佳实践。
软件评估过程的回顾
在很久以前，评估就是企业计划过程的重要部分。在第一台计算机安装，写出第一个程序开始，企业管理人员就开始判断开发一个软件方案将花费多少成本和时间。在过去，管理人员能够很精确地知道软件项目将花费多少钱和多长时间。但是现在 IT 业界不断分化和复杂度的增加结束了这段理想时代。
为了降低对于未来时间和成本的固有的不确定的预期的风险，人们试图构建一些简单的、可靠的软件开发评估实践，比如软件代码行（Software Lines of Code，SLOC）。这些简单的方法可以在一段时间内有用，现在仍然在到处应用。但是它们评估的结果越来越差，因为实际项目变得越来越依赖于新技能的引入，以及软件项目和程序不断增长的复杂性也导致这些方法越来越不适用。
在今天的软件开发工业中，商业和技术管理人员总体上都对项目成本和日程表的准确性表示不满。现在几乎每个项目都在成本或者日程上超出预算，项目失败已经成为常规。按照最近的 Cutter 的研究，只有 14% 的公司报告它们的软件日程表和预算评估比较好 1。开发商业软件方案的成本在增长，而很多组织按时间和预算交付有质量的最终产品的能力却很成问题，甚至最有希望的减轻风险的过程方法也不能扭转局面。精确评估成本和日程的挑战已经成为主要的问题。
评估的挑战和趋势
在软件项目中导致准确预期成本、日程和人员需求很困难的问题包括：
增加的复杂性和技术和技能的分化
不断增长的在最好和最差的软件开发人员在性能上的“生产力差距”
在使用什么样的评估技术上面不明确
可能在评估技术和组织的方法和最佳实践方面有潜在的不匹配
图 1 描述了这些挑战。
图 1：软件开发评估的挑战：这些因素阻止了评估的广泛工业化应用
技术复杂度的提升
随着时间流逝，IT 市场也变得越来越分化。现在市场上有超过一打的硬件平台，超过 25 种操作系统，超过 100 种编程语言，更不要提数不过来的库、应用框架和中间件，以及它们可能的组合等等。这种混乱的复杂性使得有些评估概念，如 SLOC，在很多情况下不再适用。同样，功能点技术在这种情况下也变得越来越难以应用，因为它们经常需要映射到不同的环境和专门知识，以及复杂的配置变化中，以便能够有效地使用。
这些技术退化的一个原因是，今天的方案的实现使用了打包的软件和中间件，方案至少部分是从模型和模式中产生的，在某些情况下，是从已经存在的代码中构建的。这些实践有希望改善软件的质量和可靠性，但是它们不会使评估更容易。相反，那些构架、设计和集成软件系统的任务会变得更复杂，在评估过程中出现这些额外的不确定性对评估的准确度有负面的影响。
评估假设的变更
软件开发不断增加的复杂性已经改变了基本的评估假设。在过去，只使用一两种编程语言用来生成程序，运行在单一平台上。评估开发成本和成果的任务相对直接一些。人们可以安全地假定，比如，在相同的时间周期中开发两倍 SLOC 的产品，应该需要两倍的人力资源。但是现在这种关系不再是线性的了。现在为了使开发时间加快 20%，您就有可能需要两倍的资源（如图 2）。对于很大的和专门的项目，人员和时间的关系甚至更加非线性。
当项目运行到中间需要增加资源时，会出现另外的问题。在这种情况下，由于时间已经落后，需要吸收新的人力资源，需要的资源和预计的交付时间的关系甚至更加复杂。在极端的情况下，它会遵循 Brooks 定律，也就是说：“给一个延迟的项目增加人力资源将会使它更加延迟。”2
图 2：时间 / 资源曲线
资源生产力差距
类似于图 2 的曲线依赖于项目特定的因素。一个具有很重要影响的因素是个体资源之间生产力的不同。在早期的 IT 日子中，评估的生产力的比率，即在最好的个体生产力和最差的之间的比值，最大可以达到 5:1。换句话说，最好的职员能够做 5 倍于最差职员的工作。现在，生产力比率可以达到 40:1。更不要说在最好的最差的之间还有很多生产力高低不等的职员分布。因此准确地评估时间和资源的需求越来越依赖于申请到预期质量的项目资源的能力。
项目结果不再具有代表性
由于软件项目的复杂度不断增长，在一个项目中收集的生产力数据经常不能完全应用于类似项目，则就给面向学习的和基于经验的评估技术造成了问题。不同于项目管理，这时开发生产力和技术细节是主要的原因。另外一个问题是复杂的方案需要更复杂的技术，这就需要正确地使用更多的技能和专门知识。还有一个问题是随着项目、工具和技术的复杂度的增长，评估方法无法跟上它们的发展。
评估精度的降低
当产生一个评估时，通常包括一个与精度有关的可信区间。类似于“在有 5 个资源可用和三天的周期时，方案可以按照成本 1000 美元 (+/-5%) 交付。”这个声明表示出在提供合适的资源时，评估人员确信方案成本不会超过 1050 美元。
随着项目成本的提高，评估人员评估的精度也随之下降。对于大项目的评估可能有更大的可信区间，例如“在有 15 个高级资源可用和 30 天的周期时，方案可以按照成本 100，000 美元 (+/-15%) 交付。”。注意到这里指明了“高级资源”以减少较差的资源对项目评估的影响。
对上百万美元的项目进行评估时，情况会更加糟糕。不仅需要痛苦地努力计算可能影响项目的所有变量，而且可信区间本身与推测之间没有太大差别了。这种情况下，推荐的方法是收集业界平均数据，并遵循最佳实践的指导。很多软件评估包允许您把这些变量设置为可配置参数。
象评估本身一样，评估精度的值在不同的评估下通常也不一致，特别是在使用基于专家经验的方法时。如果环境发生轻微变化时必须要进行评估的话，结果也可能不同。即使使用基于算法的方法，对于大的项目要想产生更精确的评估值的话，评估的精度和准确度也会受到输入数据的很大影响。
单一的评估方法不再满足要求
对于软件团队来说，一个很大的问题是在项目中选择哪些最佳的技术或者评估方法的组合。单一的评估方法不可能在过程的每一步产生可靠的评估结果。这通常是因为在需要评估时，评估方法需要的特定的输入数据可能不可用，或者精度不够。因此，需要采用的方法必须与那些方法和技术的情况相一致。在企业和项目生命周期不同阶段可以采用不同的方法（参见后面的建议）。近来出现了混合和自适应的方法，它们组合了若干种方法和技术。
评估不是开发方法论的一部分
评估并不是大多数软件开发方法，如 IBM Rational Unified Process (RUP)，的明确的一部分。大多数软件开发方法简单地在生命周期早期对一些东西做出假设，然后在随后的项目计划和评估活动中使用。比如，在 RUP 中，使用用例模型可以作为复杂度和风险的度量，随后作为项目和迭代计划的输入。
不管团队是否使用 RUP、The Open Group Architecture Framework (TOGAF)、IT Infrastructure Library (ITIL) 或者它们的组合，评估技术都应该与生命周期紧密结合。类似地，评估活动也将利用软件开发方法的产品，提供明确文档化的输入。
跨越整个软件开发生命周期的评估
当今的软件开发和项目评估活动具有较高的优先级，当需要分配预算或者安排日程时，就会指派一个专家完成评估任务。评估也应该是一个跨越不同方法、技术的持续的过程，它应该用在软件开发生命周期的不同阶段，产生递增的评估结果 3。如图 3 所示。
图 3：企业软件开发评估生命周期
在下面的章节中，我将讨论在企业软件开发生命周期的不同点上发生的评估，以及在过程的不同阶段，哪些评估方法最适合
猜测或者评估是如何诞生的
依赖于情况的不同，最初的评估可能来自于企业计划人员的头脑中，或者来自分配的项目专家如项目架构师或有经验的项目经理。评估过程一般起源于简单的问题，如感兴趣的管理人员会问：“您认为这个项目将花费我们多少 ...？”。对这类问题的回答可能是：“按照我以前的经验，它可能是从 X 到 Y。”这种在 IT 领域很常见的非正式的过程，属于“猜测”，因为它来自基于个体的经验和分析能力的推测。它基本上属于基于经验的快速的评估。
尽管一定程度的“猜测”在很多评估活动中是不可避免的，它的主要风险在于它依赖于个体的知识、经验以及本能。有些人可能比其它人评估的更好，因此依赖于这样的评估是不合适的，因为它们的精度非常低，可能导致错误的预期。如果您被问起这类问题，不要害怕说“我能不能稍后再回答这个问题？”，然后您可以使用标准的评估技术。
企业架构方面的评估
在现代企业中，由于使用了最新的几种企业架构的框架，不断增长的企业架构（Enterprise Architecture ，EA）方法的任务已经变得更加安全可靠了。这些框架包括定义和实施企业架构的指导，以及标准业界解决方案和过程模板的库，可以用来描述现在和未来的业务和系统部件。
在 EA 的环境中，“实现”意味着有能力创建需要的产物，这些产物定义、描述和支持交付下一代企业业务过程和系统。一个这样的 EA 框架是 Open Group's TOGAF。
评估和 TOGAF
TOGAF Architecture Development Method (ADM) 是一个周期性的阶段化的过程，它可以帮助企业团队构建它们现有和未来的企业架构（见图 4）4。每个 TOGAF 生命周期的阶段有一个目标，最后阶段给出实现组织图景的完全的企业架构。全部企业架构的实施过程将持续很多年，包括多个具体项目的实施。
使用 TOGAF ADM 实施 EA 在一个周期可以进行几次评估。
图 4：TOGAF ADM 生命周期
用评估连接 EA 图景
首先，在 TOGAF ADM 实施过程的阶段 A 产生高层的评估。在这个阶段的产出物利用了对 EA 当前阶段的理解，以及对未来方向的知识。这个阶段可以使用基于专家经验的评估，它可以使用自顶向下的方法来确定在当前组织变更周期中由多少工作要做，这些工作可能需要两年到十年，或者更长。
业务案例的评估
对很多组织来说典型的是为它们的大型项目产生业务案例，也称为 " 规划 " 或者 " 计划 "。一个业务案例文档，是过程阶段 B 的结果，通常包括有关规划实施的一系列假定和高层的陈述。业务案例和 TOGAF Vision 产出物的不同是业务案例可以要求特定的，尽管是高层的，行动。例如，业务案例可以提出改善公司业务系统的需求，可以要求增加新的商业服务、或者推荐一些改善业务系统可用性的措施。通常，业务案例包括一些没有指定方法、项目和技术的陈述。然而，它通常包括高层的费用和持续的分析。
业务案例评估通常使用面向学习的技术，它从以前的内部和外部项目中获取相关信息。有时，业务案例的评估可以基于咨询商提供的报价单，这些报价来自于在以前的类似活动中得到的经验。业务案例评估的精度经常很低，由于通常不能完成细节的功能分析，可信区间通常高达 50%。使用算法方法显然是不切实际的，这主要是因为项目主要参数无法计算。
评估和 EA 实施计划
在 TOGAF 阶段 E 需要再次进行评估，这时确定的机会和提议的方案都已经成型并经过讨论。由于在这个阶段的产物包括开始具体实施的建议，因此需要比阶段 A 和 B 更加严格的评估。建议的解决方案可以是创建或者购买新的软件组件、升级现有的软件应用、改善网络架构或者要求进行更加详细的分析。
在这个阶段，一个自然地选择是组合基于功能点的分析和面向学习的评估。由于没有使用用例或者等效的功能单元可用，基于算法的方法如 COnstructive COst MOdel (COCOMO) 可以使用来自业务过程活动或者业务服务的数据作为它的输入。评估也可以采用以前完成的 EA 实施周期的生产力数据，或者在初始循环中使用业界平均值。
在 TOGAF 阶段 E 产生的评估可以在这个阶段进一步修正，因为项目的实施通常专注于实现实施范围内的商业和系统的分析。在图 5 中，使用 RUP 作为方案实施的方法论。这里，项目分析可以带来项目实施次序和项目和部件依赖关系的更多的细节，分析通常基于基本的使用用例、场景、特性、任务或者作为方案生命周期方法论中的其它可用单元。项目分析通常由基于专家经验的评估来支持，这些评估来自于那些作为商业和技术专家的项目领导人。
使用基于专家经验的方法最多到 RUP 的精化或者构建阶段，这以后它不如使用算法评估，通常在这以后主要的需求（通常超过 90%）已经明确了。
图 5：组合 TOGAF ADM 和 RUP 生命周期
评估和未来的 EA 计划
在 TOGAF 最后一个阶段 G，这时所有的方案都已经实施，这就到了为新的 EA 实施周期设置目标的时候了。在这个阶段 EA 团队可以使用当前 EA 实施周期上一次的评估结果。面向学习和基于专家经验的技术可以在这里使用，以便研究提议的新的活动的可行性，以及确定下一个 EA 周期的参数。
软件实施的评估
有句话说：“企业就是它的项目的总和。”每个企业运作、产品或者服务的变更，不管是大还是小，都需要一个项目来运作。当企业的产品和服务变化时，它们的项目也有类似的变化，它们分析、现代化、重组现有的应用和过程，或者创建新的应用和过程。
今天处理项目运作有大量的方法和技术，从与具体领域无关的方法，如项目管理知识体（Project Management Body of Knowledge，PMBOK），到那些与特定活动关联的方法，如软件开发方法 (RUP, Feature-Driven Development (FDD), Extreme Programming (XP)) 或者 IT Service Management (ITIL, proprietary ITSM methodologies)。
瀑布方法中的评估
尽管瀑布开发方法的缺点受到了广泛的批评，但是它仍然非常流行。管理人员喜欢它，因为它假装可以在项目早期提供更详细的答案（不管它是不是正确地），而开发人员使用它，是由于他们受到压力，必须提供超出他们实际能提供的更多的答案。瀑布方法似乎可以直观地上手，因为它不需要任何方法上的培训。
基本上，瀑布开发的评估可以看作是在一个点上交付全部方案。在一个标准的瀑布项目中，在开始阶段有一个长期的过程，专门进行全面的可行性研究和需求分析。很多项目管理人员真诚地相信，通过完成对方案的全面的分析，可以得到一个鲁棒的方案设计。在项目的开始阶段，这个假设证明是正确的，项目也按照预期运行，这归结于在项目开始进行了全面的需求分析。然而，在长时间的项目运行中，这种策略通常证明效果不大，因为无法预料的复杂性会悄悄出现，影响项目范围，并最终使得项目开始时的评估变得不准确或者无效（见图 6）。
瀑布方法在小的项目和协调很好的团队中可以工作。这个方法通常在可行性分析和收集需求活动以后产生单一的评估。严格的初始分析和计划阶段有能力产生足够的参数化的数据，以支持基于算法的方法，比如 COCOMO 和 Software Lifecycle Model (SLIM)。
迭代软件开发中的评估
在当今的环境中，硬件和软件的复杂度在不断增长，需求持续变更，这时迭代开发方法由于他们的成功率而占有优势。迭代方法通过牺牲一些初始的需求明确性而有效地改善了总体效率并节约了时间 / 成本（见图 6）。
图 6：瀑布和迭代生命周期中的评估
下面是一些使用迭代方法与瀑布方法相比的优势：
由于最有风险的使用用例和问题可以早期发现，项目风险会降低。
它通过描述和实现最有风险的用例以及最依赖其它用例的用例，以减少需求变更的影响。由于使用用例是递增地描述的，受到新的用例影响的部分不需要重写，这就节约了时间和成本。
一些需求的实现在其它需求详细描述之前实现，这允许渐进的更有效的分配人力，从而提高了工作效率，并降低了成本。
迭代软件开发项目的评估活动与瀑布方法的主要不同之处是：
产生一系列迭代的评估，而不是单一的评估。
不像瀑布项目，项目评估在每次迭代中进行调整，不断改善精度。
项目评估可以在迭代开发生命周期的很早阶段产生，更好地支持项目计划。
RUP 项目的评估
RUP 是最主要的迭代软件方法。RUP 由多种形式（比如，系统工程等等）。但是不同的形式都有同样的基本原理，比如迭代的方法和尽早缓解风险。RUP 迭代方法的实现并不仅仅在软件开发领域，也可以用在其它类型的项目中，比如商业成品 (COTS) 软件项目，系统分析和基础架构管理等。
典型的 RUP 项目由多次迭代组成，每次迭代都实现一组在项目初期识别的预先选择的使用用例。RUP 包括如何建立、选择和分组使用用例以及如何把它们分配到迭代中的指导。除了当前迭代中正在实现的用例外，其它的用例都是动态的，也就是说，这些在项目开始阶段产生的用例可以在后面的迭代中经过进一步的分析而修改。
RUP 软件开发计划的一部分是构建整个项目的实施计划。迭代计划产生子迭代时也是同样的任务。在执行这个任务期间，项目决策基于可用的经验数据，比如基本的用例数，以及它们的复杂度，评估的总用例数等。这些数据也用在评估给定可用资源时需要建立多少次项目迭代，以及每次迭代中需要实现的用例数。正如您在图 6 中看到的，在迭代生命周期中评估也是迭代和增量进行的，在项目期间也要进行多次评估。
RUP 项目中评估精度的重要性不能被夸大。不像瀑布方法，RUP 更加依赖于基于专家经验的评估，特别是在开始阶段。当建立初步的项目计划时，它仅仅基于基本的使用用例和这个阶段可用的仅有的架构单元的数据。项目经理可以使用基本的使用用例来确定需要多少次迭代。基于专家经验的评估就在手边，而此时只有很少的关于系统构建的细节数据，这就限制了使用算法评估模型的机会。在这个早期阶段，使用面向学习的评估方法来估算前几个迭代需要的资源也是有用的。在第一个精化迭代结束后，由于由更加结构化的需求数据支持，因此基于算法的评估方法将更加有用。
在第二个以及更以后的精化迭代中，更多更深入的需求变得可用。因此可以用实际的性能数据来选择一种算法评估方法，以改善项目评估结果和项目计划。类似于 COCOMO 和 SLIM 这样的方法开始放出光芒，而基于专家经验的技术则逐渐失去作用。
尽管 RUP 本身包含一些有关评估的建议，IBM Rational Method Composer 作为最广泛使用的平台，仍然给出了选择评估技术以及在 RUP 生命周期活动中组织评估活动的指导。5
敏捷（Agile）项目中的评估
敏捷开发方法和敏捷开发人员对待评估的态度和其它常规工作一样，那就是“忽略尽可能多的东西，尽可能地快”。然而，即使是最激进的管理人员和最受敏捷开发影响的项目团队仍然必须指定交付日期，以及项目需要的预算和资源，这就自然地给项目带来了评估问题。
所有敏捷方法都会问的一个问题是：“多少评估足够了？”。比较一致的意见是评估必须表现为对一种单元的测量，这种单元必须容易产出，并且是过程流的一个逻辑部分。这种单元可以是特性驱动开发（Feature-Driven Development，FDD) 中的特性，Extreme Programming (XP) 中的场景，或者轻量级 RUP 和 Unified Process (UP) 方法中的用例。
很明显，敏捷社区比较偏向基于专家经验的评估，而不是基于算法的方法。当然它不能全部排除使用功能点分析。在敏捷项目中评估的底线是不管是用什么技术，项目组都有最专门的人评估他们的工作内容，而不是一个专家产生对整个项目或者对每个人的工作的评估。评估应该针对短的迭代，应该进行多次增量评估，这样可以与 sprint、迭代和其它方法指定的间隔一致。
在敏捷方法中，建立一个良好的企业范围的评估比产生一个项目的评估更加困难。不过，刚刚讨论的原理同样适用。大的单元比如项目、子系统和业务过程可以作为测量单元，代替小的单元入使用用例、场景和特性等。基于专家经验和面向学习的技术在企业敏捷评估中仍然适用，同样可以用自顶向下的方法。
敏捷 COCOMO
敏捷 COCOMO 是一种用于轻量级的增量的成本和日程评估的工具。它由 USC 软件工程中心的 Cyrus Fakharzadeh 和 Gunjan Sharmanby 创建 6。这个方法基于 COCOMO II 2000，并和面向学习的评估方法结合。
传统的 COMOMO II 方法需要评估人员使用全部 22 个参数。而在敏捷 COCOMO 中，评估人员可以选择和设置一个关键参数，如总成本或者总人月工作量，然后逐渐地增加成本或者日程有关的参数，这些参数与作为参考方案的实际构建系统中的有一定区别。这个方法允许您在这些参数在项目执行期间可用时使用它们进行评估，这就使得这个方法适合使用敏捷或者迭代方法的项目。
其它方法和最佳实践的评估
企业的方案不会只停留在软件开发方面，它还包括其它领域，如应用程序支持，商业智能（Business Intelligence，BI）、网络架构管理、数据库管理、安全管理等。尽管它们每种都有自己的方法论，而且似乎需要独特的评估成本和工作量的方法，但是前面讨论的很多评估方法和技术，例如基于专家经验的方法和面向学习的技术，都是通用于各个领域的。其它评估技术，如功能点分析，需要进行一些调整才能使用。
企业方案领域评估不同之处时它们的测量单元（Units of Measure，UM）。软件开发的测量单元是使用用例、角色、场景等，而在 BI 和 DW 中是数据源、模式 , 线索、报告，在数据库管理中是数据库，库结构和关联的对象，在网络管理中是服务器、集群、工作站和网段等，在安全管理中是域、配置、组、页面和证书等（见图 7）。
图 7：在不同的方案领域中使用功能点分析技术
改善评估的一致性和质量
这一节包括如何改善评估效率和精度的一些建议。本节探索了技术和方法上的问题，也包括社会和文化方面，最后给出了一些基本的建议。
方法的选择
尽管有很多方法选择的指导，但是很多项目的实践表明，采用什么样的方法的问题并没有唯一正确的答案。选择通常依赖于很多因素，如果使用基于算法的方法，那么就需要知道很多配置参数。而限制就是在很多情况下没有足够的信息确定这些参数，或者可用的信息不具有代表性。这时算法评估结果就不如基于专家经验的技术。
基于专家经验和面向学习的评估技术非常擅长于预期编码或者编程工作。它们的弱点在于预期需求、设计、文档和管理工作、测试、维护和返工方面。人类专家在预期支持工作时一贯是乐观主义者。这是由于人们不能够全面认识项目的范围，以及作为复杂的项目实施一部分的间接的管理和支持活动。而基于算法的评估技术则可以正确地处理这些问题，因为它可以使用已经度量的组织特定的数据，或者使用业界平均值。这样那些间接的成本会自动加到生成的评估中。
总而言之，大的软件实施项目倾向于在文档工作和修复 bug 方面比生成可交付的软件投入更多的工作。而这些项目工作很难用基于专家经验和面向学习的评估技术来考虑，因为这时没有可以察觉或者度量的实体，这样它们就从手边溜走了。很多基于算法的方法在这方面具有优势，因为它们迫使用户从一个完整的过程来考虑。
对于所有的评估方法和技术来说，评估的精度是需求复杂度、完整度和质量的产物。给定同样的初始条件，不同的技术会产生不同精度的结果。在基于专家经验的方法中，精度来源于评估人员的知识和经验，很难测量和验证。在面向学习的方法中，精度依赖于参考的项目和方案、从这些参考中获取的知识的数量，以及评估人员的经验。基于算法的方法则不同，它可以调整算法适应目标环境，而使精度得到改善。
在开发过程的不同阶段，一些技术可能比其它技术产生更好的结果。在项目开始阶段，基于专家经验的技术通常比使用公式的技术要好。然而，随着项目进行，情况很快发生变化，算法模型可以配置和剪裁以适应项目环境。
用积极的态度面对评估
软件成本评估的可靠性不仅仅与使用正确的工具和技术有关。它也与现实的观点有关，即什么可以做，什么时候能做，以及什么不能做。很多软件工程师在可交付产品和他们可能的影响方面开始欺骗他们自己和他们的上司。这通常发生在他们处理技术和项目的复杂性时缺乏经验。
任何参与企业项目计划的人都要牢记准确的评估首先与正确的态度有关。它不仅涉及软件开发人员提供现实的数据，而且涉及高级管理人员对软件方案的评估的挑战的理解，也包括在项目实施开始阶段产生精确评估的困难性。当开发人员和评估人员都比较保守并且避免过度承诺的时候，管理人员就会接受这种渐进的软件开发和评估过程，并支持他们的职员在这条道路上前进。
调整组织的文化和政策
不要欺骗您自己，以为您可以改变的的组织的文化。相反，您需要研究它，试图接受它，或者至少不要与它过于对抗。评估任务必须适应文化的现实，即您能实际给出多少承诺，以及何时给出。适应组织文化不是说您必须屈服于您不相信的东西，而是对作为企业一部分的真实的人的价值观和节奏的理解，以便为了总体的利益对您产生的评估结果进行智能地调整。
一部分评估是为了确保项目相关的组织对履行您的承诺做出保证。不管是否发生这种情况，内部的政治和官僚都可能扮演这角色，因为这对组织和个人都有文化和社会的利益。
由于很明显的原因，这些因素一般不作为评估方法和工具的参数考虑。政治和文化的问题很难量化，而且讨论起来太敏感。因此，评估方法中包含这些内容将会产生更多的问题。有些组织因素可以作为一个基本因素来计算，因为它们的影响已经超出很多更容易量化的因素，比如技术风险，的影响。在有些组织中文化因素的影响是巨大的，组织只能勉强前进。通常情况下，大型公司和政府机构比私营小公司和中型公司更加容易受到影响。一个经验法则是，在您生成评估时，保证来自不同组的承诺按照文化进行调整。
保卫您的评估
现在，评估工作有时类似于马匹贸易，您必须进行谈判而不是证明您的评估的正确性。高级管理人员、项目发起人和客户倾向于给中层管理人员和评估人员施加各种压力，这种压力通常是乐观评估方向。
关键在于能够产生面对争论时受到保护的评估结果。一个策略是把评估和类似项目的历史数据集合一起呈现。然而，更好的策略是给管理人员和相关人员逐渐灌输对您的信任。一旦您达到了相互理解和信任的阶段，您的评估结果会受到您的同事和老板的尊重和保护，就像那些结果是他们自己产生的一样。
给利益相关者呈现您的评估也是非常重要的。不要仅仅呈现几个简单的数据。利益相关者想要看到您使用的方法的描述，至少是作为您的评估的基础的部分数据样本，而且有可能的话，最好给出对过去成功项目的实际成本和工作的对比描述的图表－－这样您的利益相关者可以在他们向他们的老板呈现您的评估时可以作为证据引用。创建高层的成本和时间的分解图也是很有价值的，也可以给出一两页关于您的项目假设和您使用的技术的简单文档。
基于结构化需求的评估
评估的精度与它最弱的那一项相当，通常是作为评估基础的需求。需求的变更、不完备、不正确或者没有明确描述，可能是评估失败的最大原因，这将导致项目失败和挫折。
对于基于算法的方法和基于专家经验的方法来说，最好的来源是结构化的需求。它们称为结构化的原因是这些它们的结构是按照一致的规划确定的。使用预定义的规划可以保证需求的内容的一致性，即使它们是由不同的人产生的。从评估的观点来看，使用用例就是一个结构化的需求，它们有一系列步骤，前置和后置条件、以及其它参数和输出组成。这样的需求可以准确的进行评估，基于步骤、场景和包含的对其它需求的引用的数据来进行评估。同样，它们也能够很好地预期，变更对其它需求和项目的影响也可以计算出来。
组合不同技术产生可靠的结果
尽管现在已经有了一些组合的评估方法，它们包括来自不同方法和技术的原理和实践，评估人员仍然应该了解采用多种技术来进行评估通常是最好的方法。应用多种方法通常会产生意料意外的结果，尽管它们并不总是正确的，然是这种实践是很值得进行的。针对一个问题得到不同的意见是很有价值的，这也是做事情的正确的方法。
配置评估模型
基于经验和面向学习的技术可以作为配置算法方法的一个有效的工具。当使用公式得到最初的评估后，可以和过去类似项目进行比较。基于这样比较的结果，可以有新的考虑，对产生评估的参数值也可以重新审视并调整。这种对比可以帮助您发现新的未考虑到的因素和参数。
保持更新的评估
在评估建立以后就应该尽可能保持更新。RUP 和其它迭代方法建议评估应该在整个项目中始终保持最新。瀑布方法和其它强调计划的方法则没有这么明显的要求。一般来说，评估过程应该与特定的方法的原则相一致，不在整个项目中保持最新的评估将导致在项目实施团队和管理团队之间产生预期的差距，从而导致双方的误解和不满，最终甚至可以导致项目部分或者全部失败。
如果由于一些原因，项目不能保持评估的更新，那么交付的评估就应该包括一些条款，以指示评估在什么条件下有效。这些条款可以帮助保障评估效果，以及把评估和建立评估的环境和需求联系起来。这些条款可以作为保证评估的一致性的基础，并且可以保护评估的效果。
鼓励开发最佳实践
为了进行优秀的评估，仅仅掌握方法和工具是不够的。评估同样依赖于组织一致地交付产品的能力，即组织的成熟度。一个事实是，团队如果使用最佳实践，掌握好的支持工具，则组织就能够可预测地一致地交付它们的承诺。为了生成评估，很多评估方法都需要询问评估人员有关在他的环境中标准的开发方法和设计开发实践是什么的问题。这些问题可能是“团队具有什么样的软件开发生命周期实践？”或者“在组织中标准的设计最佳实践和工具是什么？”
在使用正确的方法和工具帮助提高评估质量的同时，您也应该鼓励开发组织应用最佳实践和工具，采用这些可以直接影响评估的可信度。
结论
使用严谨的技术建立您的评估－－不要依赖于本能。尽量少使用基于专家经验的评估，因为它们与基于算法的方法相比是不可重复的，仅仅在您有足够的需求支持这些方法，而且不会给过程增加不必要的摩擦的时候也可以使用这些方法。看一看混合的方法，在混合不同的技术面前不要犹豫。调整评估的结果以适应您的组织的文化，如果必要的话，保护您的评估。培养对正式的评估实践的正确的态度，并集中在在您的团队中建立对评估的信任。鼓励使用软件开发最佳实践和工具，努力增加交付过程的可重复性。
进一步的资料
尽管有点过时，由 Barry Boehm 和 Chris Abts 所坐的此篇文章仍然是软件开发成本评估方法的一个优秀的概览：http://sunset.usc.edu/publications/TECHRPTS/2000/usccse2000-505/usccse2000-505.pdf
由 Liming Wu 所作的一篇优秀的评估方法对比文章：http://www.computing.dcu.ie/~renaat/ca421/LWu1.html
由 Amit Bhagwat 所作的来自于 The Rational Edge的此篇文章提供了一种在迭代化，用例驱动评估的“关注成本”项目方面的观点：http://www.ibm.com/developerworks/rational/library/content/RationalEdge/oct03/f_estimate_b.pdf
另外一个在预测迭代化项目上的有趣观点：http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=6781
这篇有关大项目的软件成本评估方法的文章讨论了在评估非常复杂项目上的挑战：http://www.stsc.hill.af.mil/CrossTalk/2005/04/0504Jones.html
由 Chris F. Kemerer 所作的此篇研究文章包含了软件成本评估模型的基于经验的验证：http://portal.acm.org/citation.cfm?id=22906&dl=
注释
1有关更多信息，请参见 http://www.cutter.com/content/alignment/fulltext/advisor/2006/bit061220.html。需要付费订阅。
2来自 Frederik Brooks 的经典的 1975 版的书 The Mythical Man-Month。有关更多信息，请参见 http://en.wikipedia.org/wiki/Brooks'_law
3对于增量评估实践的好的总结，请参见 http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/oct03/f_estimate_b.pdf
4有关更多信息，请参见我最近的在 http://www.ibm.com/developerworks/rational/library/jan07/temnenco/index.html上的 Rational Edge文章。
5咨询 Rational Method Composer 目录数据库 (http://www.ibm.com/developerworks/views/rational/library.jsp)，以寻求建议。
参考资料
学习
您可以参阅本文在 developerWorks 全球网站上的 英文原文。
您可以参阅 Rational Edge 电子月刊中文版的其他文章。
您可以参阅 本系列的第一部分：企业范围的软件评估，第 1 部分：原因和方法。
讨论
参与论坛讨论。
已经专门为 Rational Edge文章创建了一个 新讨论区，因此您现在可以共享您对本文或其它在当前问题或我们存档上的文章的想法。阅读您的遍及世界的同事所阐述的言论，阐述您自己的讨论，或者加入进行中的讨论。点击 这里开始。
全球 Rational 用户组社区
关于作者
Vitalie Temnenco 是加拿大安大略省工作场所安全与保险委员会的架构师。他主要负责项目实施方面的架构指导，以及帮助团队建立RUP和企业架构的概念。他的经历包括在不同的业务领域为客户提供架构和构建解决方案 ，这些领域有银行、金融、保险、零售和电信业。在这期间，他教授客户，在构建新系统时如何有效地使用UML和RUP进行业务和系统分析。在业余时间，他在方法论、框架和技术方面写一些罕见的、非标准的和创新的应用。他的联系方式为：vit@umlconsulting.com
本文转自
http://www.ibm.com/developerworks/cn/rational/rationaledge/content/aug07/temnenco/