级别： 初级 Kris D. Hansen (kris.hansen@mac.com), 解决方案架构师, 自由作者
2008 年 1 月 24 日 IT 架构师经常参与软件开发项目的评估工作，而评估对项目的成败有着很大的影响。很多因素都可能影响开发的时间安排和计划。通过本文，您可以了解评估方法、获得改进评估的建议，并了解进行评估时应该考虑的事项。
有时候，软件开发项目会失败。出现失败时并不怎么有趣，而且在大多数情况下，涉及此项目的人都会卷铺盖走人。根据客观的分析，48% 的失败项目都是因为计划和评估不当造成的。在这些情况下，如果准确地对项目进行了评估，这些项目本应该成功实现的。如果考虑了所有问题，给出的计划和成本就应该非常准确。
应该由谁进行评估呢？在有些组织中，这是项目经理的职责范围。而在其他组织中，评估由架构师进行，或由项目经理和架构师合作完成。在任何情况下，对于软件开发活动，都应该由熟悉软件开发的人参与此过程！
本文将介绍在进行评估时必须考虑的事项以及要加以避免的失误。本文从架构师的角度对评估进行了说明，重点是实践提示和能够帮助您提高评估准确性的各种做法。
技能和能力
评估经常是以非正式的方式进行的，经常在去开会的半路上得出的结论，通常缺乏信息，而且时间比较紧急。“嘿，如果启动 FooBar 8000 采用 Java 运行的话，我们的成本是多少？”是不是听起来有些耳熟？很容易忍不住抛出个数字，但避免这种冲动，继续阅读下文！
评估具有令人难以置信的重要性。它是项目的关键，可形成开发工作分解结构，并将成为项目计划（项目经理和团队的其他人将在项目持续期间使用此计划）的基础。开发人员要么将评估捧上天，要么将其咒下地，但他们必须依赖于这个评估。这也相当主观，基本上就是凭经验对实现目标所需工作的猜测。我们的目标是减少猜测，尽可能提供可靠的评估。
评估中面临的挑战
在技术项目中，设计期间不知道的事项通常都是以后对您影响最大的事项。项目开始时，项目如何完成的细节通常是未知的。另外，很多项目交付方法在执行的抽象和详细设计方面的角色和阶段都有所变化。
体系结构评估中的一项主要活动就是区分已经完全了解的内容和尚比较模糊的内容——并理清未知组件的潜在复杂性。如果您通常是较为乐观的人，请在此部分评估期间采取较为悲观的看法。对您的假设和思维方式提出质疑。将与过去实现不同的东西确定为增加的风险因素，并从可能会出问题的方面考虑问题。
构建评估框架
可以通过多种方式进行评估。关于此过程有很多文章进行了讨论，而且大多数专家都彼此存在异议，即评估很困难，而且无论考虑了多少科学、心理或数学方法，评估中仍然存在主观元素。关键是要选择一种方法，构建评估框架，并且在其应用中保持一致。如果与框架保持一致，分析结果之后您就可以对框架进行优化，从而及时地提高评估能力。
在框架内，包含捕获和测定项目的实际数据的方法。通过将其与实际的交付进行比较，从而跟踪评估的有效性；然后在进行新的评估时运用这个实际信息。可以将实际交付时间的相当简单的存储库编译和存储在电子表格中，以便将来检索。可以作为项目收尾工作的一部分进行此工作，这样做将会物有所值。
这个实际信息在改进评估准确性方面很有用处。可以将实际数据各个方面细分为可重用组件，并使用其形成将来评估的构建块。例如，您的团队所执行的任何任务（如服务器构建、数据库实现和数据库表开发）都意味着 JavaServer Pages (JSP) 页面开发时间、Servlet 开发时间和团队的项目会议中占用的平均时间。任何可帮助对未来活动进行准确判断的此类数据都可以减少评估时的猜测。
评估的重要性
如果您的组织了解准确评估的重要性和评估偏差导致的不良后果，则更可能认真地对待评估，并提供足够的时间和资源有效地进行评估。理想情况下，如果可以形成严格评估的氛围，则可以消除即兴评估的要求。组织内的人员还应该了解，评估是交付项目的指南，有时候必须在项目执行期间重新进行评估。
未能正确地评估项目可能会导致不现实地安排工作。您的项目可能会进行得很顺利，但由于存在不现实的预期值，因此让人觉得是极大的失败。应该在组织内制定恰当评估的指南，并正式化为组织项目交付方法的一部分。形成执行评估的一致方法，包括在项目的生命周期中适当的时间让正确的人员加入评估工作中。
如果您发现自己的组织不看重评估工作，则需要大力宣传高质量评估的重要性。告诉您组织内的人们低质量评估的影响，说明如何进行高质量评估，并让他们参与到创建更为准确的评估的过程中。说明实际信息的好处，并清楚地说明评估和风险（与项目超限及失败相关联）之间的关系。向他们介绍电气电子工程师协会（Institute of Electrical and Electronics Engineers，IEEE）“软件错误集锦”(Software Hall of Shame)（请参见参考资料），并说明拥有可靠的评估框架将如何帮助您的组织避免其中的问题。
工具和技术
本文中包括了我使用过的一些评估方法。（请参见参考资料部分提供的链接。）其中有些方法将要求进行额外的研究工作，才能供您使用。其他方法更为实用，都是基于我作为开发人员、项目经理和架构师的项目开发经验。评估方法之间的主要区别在于定义工作的单位。哪个单位最相关？这取决于所构建的对象以及如何以最佳方式对其进行量化。
评估工具
没有能够为您执行评估的神奇工具——需要的是专业知识和判断力。工具可以在设计方面帮助您清楚地说明所构建的对象，帮助对其的理解。还可以使用工具来帮助进行评估方法和最佳实践的应用。
我发现在设计软件和形成评估时有用的设计工具包括：
-
IBM® Rational® Software Modeler：此工具是基于 Eclipse 的统一建模语言（Unified Modeling Language，UML）V2.0 编辑器。它采用模型驱动的体系结构方法处理软件开发，可以在其中设计类对象，并映射这些对象间的交互。此方法允许高度准确地描述系统，但需要明确的需求才能创建模型。在 Rational Software Modeler 中，您可以将模型转换为其他模型，或将其导出为代码，从而除了提供关系图之外还提供一些示例代码，以帮助缩小体系结构和开发团队之间的差距。
-
Cost Xpert：此工具可帮助对需求尚不清楚的情况进行评估。它指引您了解很多环境因素和其他因素，并提供用于各种评估方法（功能点、自底向上等等）的电子表格。此工具的一个特点是，可以在流程中选择项目方法，此工具将在评估时考虑此方法——这点非常重要，因为每种方法都有自己的文档和“习惯”，会影响项目时间安排。
-
Construx Estimator：此工具免费提供（有限许可），从可用的功能而言，这相当有价值。它以代码行、功能点或其他标准的形式接受输入，然后应用统计概率分析来确定工作的范围和完成项目的持续时间。也可以在此工具中存储和使用实际数据。
-
ISBSG Early Estimate Checker：如图 1 中所示，使用此工具对早期评估进行健全性检查。您的评估（在功能点方面）将通过实际项目结果的国际软件基准组织（International Software Benchmarking Standards Group，ISBSG）存储库进行验证。
图 1. 将早期评估与实际结果的 ISBSG 存储库进行验证
还可以使用很多其他工具，但与工具相比，用于进行评估的基础方法更为重要一些（虽然工具可以帮助保持评估的一致性和减少与创建工作相关的一些工作）。
一种评估方法要求您完全了解希望完成的目标，然后考虑从头至尾所需的每个详细任务。通常，我会在 Microsoft® Office Project 或 Excel 中将这种评估表示为甘特图，如图 2 中所示，以将其作为规划交付步骤的起点。此时，您应该非常清楚地确定要使用哪种软件开发方法，因为阶段和步骤将会根据您的方法不同而有所变化。
图 2. 使用功能点评估的 Web 应用程序项目的示例甘特图
评估方法的方式和结果各不相同。因此，每种方法经常具有不同的结果，如图 3 中所示。
图 3. 相同项目的不同评估方法的不同结果
经常，多种评估方法的平均结果对确定工作、计划和成本很有用。清楚地定义了目标后，可以使用多种方法来对项目进行评估，包括：
-
基于团队的自底向上的评估：对于此方法，您将向每个团队成员提供一个项目计划的副本，然后要求每个人提供对项目任务的独立“自底向上”评估。自底向上评估 是通过编译计划中的详细任务的评估得到的结果。让团队成员也添加他们认为缺少的任务，并删除他们认为无根据的的任务，这样的做法很好。然后您将大家召集到一起讨论其评估、假设和任务。如果您是团队负责人或架构师，并计划让您的团队在项目期间提供自底向上评估，此次会议可很好地帮助您的团队确定评估方法——面临最后期限时的重要信息。
-
评估存储库：正如前面提到的，如果可以建立实际单位的存储库，则可以将其作为基础进行评估。从之前的实际数据进行归因，可帮助提高评估的准确性，并可在所有的组件都放入存储库后形成“工厂”评估方法，从而基于其进行正确评估。
-
代码行：应用于传统（非可视化或基于 Web）开发工作时，此方法可能最为有用，因为在此类工作中，代码是逐行编写的，关于开发工作的效率假设与其他因素实现了分离。您要提出的基本问题是，开发人员编写一行代码需要多长时间以及此项目需要多少行代码。
-
功能点：
功能点 考虑的是确定与目标系统相关的功能和功能复杂性。通常，这涉及到统计输入、输出、查询、文件和接口的数量，然后为各自制定一个复杂性系数。如果提供了详细的需求，而且功能能够进行计数，则功能点方法最为有用。
-
Internet 点：Internet 点以功能点为基础，另外还包含基于 Web 开发范式的其他描述符。例如，对动态屏幕与静态屏幕进行了区分。
-
UML 用例点：对于遵循 IBM Rational Unified Process® (RUP®) 进行开发或依赖于 UML 设计模型的项目，可以通过用例点来基于活动中的场景和接受度测试用例的数量进行评估，如图 4 中所示。
图 4. Rational Software Modeler V7 中的示例用例
环境因素
如果编写初始化变量并将输出写入到终端的一行代码（采用任何编程语言）需要多长时间，您可能会认为执行这个简单的任务相对比较容易和迅速，提供的评估表明所需的工作量很少。现在，如果告诉您程序将支持 300 万并发用户，必须以极高的速度写入，而且必须支持 Nepali 语言，您的评估是否会发生变化？当然会。这是一个极端的例子，但在每种情况下，环境因素都会影响交付计划和预算。
评估时要考虑的环境因素包括：
-
团队合作：团队协作的情况如何？如果没有太多的合作经验，这将增加他们学习如何无缝协作的时间。
-
灵活性：客户（内部或外部）是否坚持将代码部署在特定的应用服务器上或使用特定的第三方产品？项目中任何“可移动对象”都将增加发现必须解决的问题的风险。
-
优先级：您的团队是否经常为此客户进行这种类型的项目？如果是，就可以降低风险。如果不是，不要忘记花点时间就流程对客户进行培训。特别对于不熟悉软件开发项目（特别是迭代设计方法）的客户更要如此。
-
环境和位置：如果项目有自己的空间，专门设计便于安静地不间断地以团队/协作方式完成工作，这是最理想的了。任何其他的情况都可能降低效率和增加成本、延长计划。如果团队的很多成员上下班都很远，或者在不太方便的地方工作（例如，珠穆朗玛峰顶），则必须将这也考虑进去。
-
软件开发生命周期工具：您团队所使用的用于方便软件开发的任何工具都可以提高效率。如果您的团队不熟悉这些工具，请在培训方面予以投资，并分配相应的时间，以便提高团队工作效率。
-
客户：在项目的生命周期中，您的客户将必须进行决策。在进行评估时，了解客户的决策方法以及他们的“周转时间”非常重要。如果团队在作出决策前出于停滞状态，这就可能将项目计划延长数天、数周甚至数月。
-
非功能需求：进行评估时，务必全面了解可用性、可伸缩性、可维护性、质量、可用性、可靠性和其他方面的预期值。其中很多元素都是关于质量的，您的项目可能需要以非常具体的术语对其进行定义，以实现目标。
-
集成和测试：您可能在构建一个小组件，但此组件可能连接到其他系统的错综复杂的大型组件。如果是这样，这将需要大量的时间进行集成和测试。考虑测试时，不要忘记考虑在进行性能问题修复时需要分配的性能测试工作和时间。
里程碑
本文给出更多的是信息而不是真理一类的东西，主要目的是为您提供实用的可用信息，下面是努力实现更为准确的评估的一些里程碑：
-
建立一致的工作标准：与组织中的其他评估人员就如何分配类似项目的工作达成一致。是否所有的 Web 应用程序都要使用用例关系图和 UML 用例点进行建模？是否在 IBM AIX® 环境中编写的所有
C 程序都将基于源代码行（Source Lines Of Code，SLOC）？通过在整个组织中实现此一致性，并在存储库中跟踪结果，可帮助在组织内形成关于评估和交付的可重用知识。
-
优化评估框架：创建了评估框架后，您可以通过实际值跟踪评估效果，从而持续改进框架和评估方法，以实现更高的准确性。
-
提高需求和目标的明了度：作为架构师，我喜欢尽可能减少我和说明需求的用户之间的中间层。有机会了解目标和确定需求，在解释需求和设计满足全面需求的系统方面有着重大的意义。
-
在组织内积累相关知识：实际上这指的是在组织内的人员应该有足够的经验，以确保不会在评估时漏掉任何东西。这听起来简单，但却是一项非常重要的注意事项。应用程序部署是否包括在评估中？是否考虑了用户接受度测试（User Acceptance Testing，UAT）以及可能会由于 UAT 导致的额外迭代？
-
制定强制性的时间安排：有时候进行评估的目的是为了确定哪个答案正确。这些不称为评估，实际是要设置时间安排，需要进行其他类型的分析——分析团队在制定时间内能完成什么。请确保将这种类型的活动与评估区分开来。组织实现这一点时，就到达了一个重要的里程碑，可充分说明评估作为项目成功的主要元素的重要性。
-
利用行业信息：可能会有关于组织所进行的项目类型的效率级别的信息。另外，请检查 ISBSG 提供的基准，该组织编译形成了包含超过 4100 个项目结果的跨组织存储库。
总结
评估是项目计划和安排的一个重要组成部分，评估不当的结果就是项目失败。要改进评估效果，请以规范的方式对其加以处理。请选择适当的方法，测定结果，然后重点进行改进。
参考资料 学习
获得产品和技术
讨论
关于作者  | 
| | Kris Hansen 是企业技术架构师和撰稿人，使用 IBM 技术已有 10 多年。他获得了七项 IBM 认证，包括 IBM 认证解决方案架构师 (IBM Certified Solutions Architect)、解决方案设计师 (Solutions Designer) 和解决方案技术专家 (Solutions Technologist)。Kris 是位于夏威夷檀香山的一家 IBM 业务合作伙伴的 VP/CTO，并带领他的团队完成了很多成功项目的体系结构、评估和交付工作。他最近返回了加拿大，为一家快速扩大的地区银行设计技术解决方案。 |
对本文的评价
| 
