专家评论: Robert Peterson：防止范围渐变

仅有 5 到 15% 的企业软件项目能够真正实现它们的需求。本文提供了最受欢迎且经过验证的策略，可以通过这些策略来避免采用面向服务体系结构或企业 java? 的企业应用程序发生范围渐变。这些策略还可能与任何技术或行业的软件工程专业人员和架构师相关。
摘自 IBM WebSphere 开发者技术期刊。

　　 什么是范围渐变？

　　项目管理中的范围渐变（也称为需求渐变）是指项目范围的无控制更改。如果没有正确定义、记录和控制项目范围，就会出现这种现象。（摘自 IEEE Spectrum – Why Software Fails）

　　如果您是软件工程专业人员、架构师或者项目经理，该主题可能与您密切相关。毫无疑问，任何老练的 IT 专业人员都有这样的经历，某些项目的范围扩大太多，以致最终造成成本和资源大大超过最保守的预期。诚然，尽管对范围渐变现象没有万能良药，但可以通过一些 策略将发生这种情况的可能性降低到最小。

　　它为什么如此重要？

　　如果您是一名开发人员，您可能认为自己仅是向大型组织提供专门技能的代码管理人员；换句话说，避免范围渐变的需求应由担任管理或高级架构角色的人员负责。我希望改变这种普遍的看法，即需求的作用只是形成文档，仅需 IT 组织中特定角色的人关心就行了。

　　在我作为 WebSphere 顾问的工作中，范围渐变是我最为关注的内容。研究表明只有 5-15% 的企业系统在从需求到生产的过程中做到了这一点。企业软件开发相当困难；例如，需要仔细安排大量的资源、协作和规程才能使华尔街的银行系统投入生产。尽管 我紧跟信息时代的一些前沿技术，如 Web 服务、服务组件体系结构 (SCA) 和 J2EE，但发现我能为我工作的组织带来最有价值东西的并不是提供多少技术最佳实践，而是进行风险分析和巩固需求，这些来得更现实。早些关注范围渐变，并 了解如何使组织防止范围渐变的最佳实践，通常是将项目带入那 5-15% 可靠成功的关键。

　　 定义现实需求的技巧

　　如上面的定义所述，范围渐变的基本原因时常涉及需求这一主题。如果没有准确地定义需求，范围渐变的风险指数将上升。但是，仅仅注意到这一点是不够的。 我曾见过一些虽然非常详细但却无助于避免范围渐变的需求文档。一种情形是，文档专家可能在未得到来自开发人员或最终用户的反馈的情况下编写需求；而另一种 更常见的情形是，专业人员干脆忽略了这些需求——如果这些需求包含在 100 页的技术文档中，而且这些文档又非常晦涩难懂，这能责怪他们吗？

　　请考虑下面的建议，以便帮助您开发能够发挥重要作用的有效需求。

　　1. 通过测试驱动的开发来巩固需求

　　在防止范围渐变方面，我喜欢的最佳实践是以敏捷方法为基础，例如极限编程：在可以将应用程序代码作为明确的可靠需求之前，对编写的断言代码进行测试。例如，一个较好的测试断言为 JUnit 测试，即当且仅当 Web 服务返回的 SOAP 信封与预定义的 XML 文档完全相同时，返回 true。

　　尽管这是一种定义需求的好方法，容易被开发组织理解，并且可以清楚地验证软件系统功能，但单独的测试用例很少适合作为完整的需求。最适合将测试断言作 为需求的项目是应用程序的最终用户自己掌握技术的项目。事实上，如果客户没有掌握技术，仅使用测试断言可能很快变成反模式，在这种情况下，可行的测试用例 对最终用户几乎毫无意义。

　　例如，使用测试断言来巩固需求的理想情形是开发由另一个应用程序调用的组件。假设开发用于访问遗留系统的自定义 J2EE JCA 连接器，以供工作流应用程序远程使用。在此情形中，最终用户很有可能是工作流应用程序的架构师和开发人员，因此使用可执行的测试断言作为他们与 JCA 连接器开发团队的需求契约比较合适。

　　我极力提倡使用测试框架，如 JUnit、httpUnit 和 Cactus。如果您在开发 J2EE 应用程序时常常没有将 JUnit.jar 放在类路径中，并按照 JUnit.org Test Infected Tutorial 的说明运行，那么我极力建议您花二十分钟的时间编写您的第一个断言。

　　2. 使用真实说明最终用户需求的用例

　　我的经验是，大多数企业开发组非常了解需要将用例作为需求过程的一部分，不过他们通常认为用例肯定会带来麻烦，而且生成的用例文档在开发过程中提供的 价值也微乎其微。带项目符号的文本对于编写有效用例几乎毫无作用。作为技术专业人员，我们有许多工具可用于定义最终用户的需求。例如，如果用户是一个使用 Web 门户的呼叫中心专家，则召开一次会议，专门讨论用例将采用哪种形式，并经每个人同意后采用这些用例的内容。对于这种特定的情况，我们建议采用下面这些表示 用例的方法：

• 用户案例。 极限编程需要充当用例角色的用户案例。这些用户案例是仅由最终用户编写的简短段落，其中不包含任何技术术语。
• 难点问题。 研 究表明，当将难题作为一个问题设计时，将创造一个环境，相关各方可以在一起自由讨论可能的解决方案。考虑提出一些直接来自最终用户的问题，例如“如何让以 前的客户呼叫列表显示在状态屏上？”可以用例的形式列举每个问题，并针对相关问题的难点添加上下文。上下文不应包括解决方案或任何技术行话。
• 流程图。 可以使用 UML 工具或业务流程工具创建流程图，说明最终用户业务需求的情形。
• 用户界面视图。 作为需求过程的一部分，实现待定应用程序的简化视图组件可能非常有效。例如，不带图形或高级格式的最基本的 HTML——甚至是白板草图、简单的构思图、纸上的原型图——可以帮助最终用户直观地想象系统的未来模样。

　　3. 首先追求实用，然后讲究准确

　　考虑使用迭代或增量软件工程方法之一。无论组织文化和所选的软件开发技术如何，实现应用程序的垂直切片（即，关系到预期最终系统中的每个组件的某些功 能）可以大大降低风险，并帮助确定影响项目范围的关键问题。然后，可以重构垂直切片，直到满足最终系统需求为止。支持组件体系结构（例如 J2EE、SCA、JSF 和 Eclipse 插件体系结构）的技术可以大大降低重构的复杂性。

　　尽管我非常相信垂直切片原则，但正确遵守此原则需要采用许多规程，不会立即完成。在通常情况下，企业系统需要许多基础服务和必备组件才能使垂直切片发挥作用，这样会带来很大的困难。

　　例如，考虑这样一种情形，最初的系统开发集中于获取客户帐户。真正正确地实现此功能需要连接到 LDAP 服务器，构建一个面向对象的映射层来抽象数据库，构造 Web 服务、安全、适当的错误处理、无状态业务逻辑，以便于进行集群和与 CICS 集成等。要构建忠实反映最终应用程序的垂直切片，必须构建最终应用程序所需的每个必要组件和服务，使之能够有效地进行重构，或者在实现时充分考虑将来的扩 展，以便最终发布的系统能够按原样使用。您必须采用此规程并说服项目参与者相信此观点，这是避免范围渐变的关键所在。

　　4. 有步骤地更改计划

　　事实上，组织很少能够接受系统的最初需求会不断改变这种可能性。遗憾的是，从传统体系结构借鉴来的技术常常会在我们的领域导致严重的问题：软件需求不 是蓝本。在传统的建筑物结构中，需求通常是固定的；建筑物的大小和位置始终保持不变，一个建筑物不必依赖于另一个建筑物的结构，而且，甚至连小孩也可以一 眼看出建筑物的构造状态。如果将这些确定建筑物构造状态的方法的准确性与软件开发项目经理使用的任何度量标准的准确性相比较，则不可避免地存在大量错误。 由于未预见到项目的复杂性，通常会出现这样的情况：经评估完成状态为 90% 的项目需要数年的时间进行额外的开发。
　
　　因此，防止范围渐变的一个关键最佳实践是，在开发过程的任一阶段都能够方便地进行需求更改。没有必要为了更改某个用例而召开几十次会议和得到主管的批准。请考虑以下建议：

• 提供一个过程，以便参与项目的任何人都可以提出改进需求的建议。 重要的是，每个人都可以研究需求，每个人都有资格提出更改建议。例如，专门用于项目需求的维基 (Wiki) 或邮件列表在这方面会非常有效。毫不夸张地说，大多数更改管理产品都可以采用 HTML 格式保存项目日程或需求，以便于定期发布。我个人的观点是，对需求进行编号，并力求简洁，这样繁忙的开发人员就可以方便地跟踪它们。
• 针对每个步骤获得用户反馈。 争取与最终用户一起举行检查点会议，举行的次数无论如何不可少于与管理人员或其他参与者举行的会议的次数。如果建议对需求进行更改，则应请求用户提供反馈意见。
• 合并风险分析。 大多数流行的软件工程方法都大力提倡对整个开发生命周期进行风险分析。例如，Rational 统一过程要求根据体系结构的影响来确定和跟踪主要风险因素。与需求跟踪类似，我极力建议风险分析应简单明了，让每个人可以看到并能够对其进行更新，同时应该根据严重程度设定优先级。

　　 结束语

　　范围渐变是企业软件开发中的正常现象。应该预料到这一现象必将出现，并在软件开发过程中建立起相应的机制，以对其进行动态响应。但愿在阅读了这篇文章 后，您能够学到一些有用的东西，帮助您更好地完成工作，同时得到更多的回报和进行更好的控制。

<!-- #EndEditable -->

---