本文是演示了在分布式的、基于 J2EE 的项目中使用 Rational 工具的系列文章（如下面所列）的第 7 部分。
第 1 部分: 项目介绍；高层次计划
第 2 部分: 风险管理；需求管理 第 3 部分: 模型创建和访问控制；需求分析--
第 3 部分: 模型创建和访问控制；需求分析
第 4 部分: 用例细化；产成报告；工具和技术选择
第 5 部分: 体系架构和设计
第 6 部分: 详细设计；早期开发；双向工程；早期单元测试
第 7 部分: 继续开发；早期的构建；演示 第 8 部分: 单元测试策略；功能测试；GUI 测试脚本--
第 8 部分: 单元测试策略；功能测试；GUI 测试脚本 第 9 部分: 系统构建和测试；缺陷跟踪；产品交付--
第 9 部分: 系统构建和测试；缺陷跟踪；产品交付 第 10 部分: 项目完成；结论；未来的工作--
第 10 部分: 项目完成；结论；未来的工作
本文中所虚构我们是一家软件公司 Lookoff Technologies Incorporated，我们的客户 Audiophile Speaker Design, Inc. (ASDI)，它雇用我们实现他们最初的 IT 需求。对于更详细的信息，参见 第 1 部分。
这个系列文章的第七部分主要关注在我们继续开发的构建和演示上。这些话题在 Rational 统一过程（RUP）中只是很简略的被提到，因为这个话题对特定项目的本质有着非常大的依赖。你将如何并在什么时候集成和演示你的系统依靠于你的客户、项目规模和项目风险。
第 7 部分快照
在第 7 部分演示的工具和技术：
Rational 统一过程 (RUP) — 用于构建和演示计划的指导方针
被创建或者更新的产物：
在继续开发期间代码和设计模型的更新
被创建的构建和演示计划
在细化和构建阶段的演示
演示发生在 ASDI 项目的几个点上，尤其是在 RUP 的细化和构建阶段。然而，构建却是迭代过程、集成被分别开发的组件和作为小的里程碑为跟踪开发过程服务的常规部分，演示更趋向于特殊的目标。在我们的项目中，这些目标依赖于项目进展到什么地方而不同，并且这些目标依次的确定了演示的精确性和他的观众。演示可以是基于构建的，也可以不是（例如，他们可以是被模拟的用户界面），演示可以是针对公司内部的，也可以是针对于外部用户的。
演示的目标
在细化阶段，演示具有下列的目标：
显示现货供应（OTS）软件产品的评估结果。
展示用户界面的模拟，显示主要屏幕的草图，并且有时显示系统的工作流程。
通过演进产品的非常早期的演示来管理客户的期望。
减少架构方面的风险。
获取分析的反馈。
在构建阶段中，演示有这样一些目标：
向客户提供团队的进展信息。
通过在阶段的早期使用接口识别出问题以减轻子系统的集成。
避免“巨大系统”的集成和在项目末期才得到交付系统。
通过让团队在一个或者多个子系统演示的会议中看到项目的进展来鼓舞项目人员的士气。
另外，早期的演示为后面被集成与测试人员进行的正式的构建提供了实践上的指导，正式的构建包括测试所有的需求和完整的构建文档等等。
内部演示 VS. 外部演示
内部团队的演示很自然要比外部演示的次数和花费的精力要少。无论何时我们向客户显示软件，我们都希望在向客户演示时避免任何的故障，但是这在内部演示检查时并不是十分重要的。
内部演示通常在一周中比较晚的时候被执行，也许是周五下午的晚些时候的团队片刻休息的时间。在演示的过程中工作在一个特定子系统或者线程的一个或者多个开发人员可以讨论他们的进展、显示他们的工作进度和讨论任何他们遇到的问题，我们能够在演示中收集到这些信息。讨论必然伴随着有关方案、好的想法和被其他团队成员发现的一致性问题的产生。这些演示要求很少的准备 — 也许只是不加修饰的构建版本并且快速的执行构建版本的使用过程以确定系统是可以被接受的。演示很少会非常顺利，但是我们并不把这种现象看作成问题，因为我们知道对他们进行精化将意味着额外的准备和测试的工作。
外部演示具有一个被增加的正式的标准。因为我们希望维持客户的信心，并且不浪费他们的时间，我们遵循了这样一些指导方针：
使用议程和其他指引的形式事先沟通演示的目标。
准备好清晰、明确的测试数据集合。
最好是从被版本化的资源存储库中重新构建计划（schema）和代码基础。
为演示生成脚本。
在演示场所与团队领导一起执行一次实际的演示过程。
确保在演示期间所有的工程团队成员停止使用任何共享的资源（尤其是被存储在 DB2 数据库中的公共数据和表）。
用一个小时的时间进行演示，大概花费另外两个小时的时间进行演示的反馈和讨论。
这些防范措施看起来似乎有些过分，但是我们发现一个准备不充分的客户演示将产生很少的价值，并且是浪费时间和项目预算的。
构建和演示计划
表 1 列出了在 ASDI 项目的细化与构建阶段我们为构建和演示制定的大致计划：
我们很多的演示是可以被合并的，或者可以与其他的会议并行的发生。
为了准备演示，一些构建是必要的。
我们很多的子系统的构建和局部系统的构建是”小的构建版本“，这些构建版本不是非常正式的，并且花费我们很少的时间。
RUP 阶段
构建或者演示的种类
频率
时间选择
细化阶段
工具评估原型
一次
OTS 产品评估交付之前
用户界面模拟
每个 GUI 用例两次
在用例分析活动早期和细化阶段后期
架构原型
一次，满足性能的要求
在软件架构文档(SAD)交付之前
构建阶段
用户界面外观
两次，分别在两周执行
构建阶段的早期
设计原型
一次
SAD 交付的几周后
组件演示
每周
开始于构建阶段早期
子系统构建
每周
进入构建阶段的 1 到 2 周
子系统演示和局部系统的构建
半个月
进入构建阶段的 3 到 4 周
完整系统构建和系统演示
每月
进入构建阶段的 4 到 6 周
表 1: 构建和演示计划
演示方法
有很多方法能够执行演示。这些方法看起来是相当明显的活动，但是有一些能够增加演示价值的新颖的方法。
联合应用开发（JAD）
联合应用开发（JAD）基本上包括为了非常集中和激烈的自由讨论活动，将所有的项目涉众集中在在一个演示场所中，典型的包括一些演示的种类。我们在我们的项目中尝试了几次 JAD 方法，但是我们发现这个方法执行起来是困难的，并且产生了一些混合的结果。我们所检查的多个参考（有两个参考被列在文章结束部分的"相关资源"中）都强调了 JAD 仲裁者的重要性，JAD 仲裁者应具备很高的技能和远见，我们觉得我们在这个方面能够做的更好。
在我们的项目中， JAD 意味着将 ASDI 的问题领域专家、 ASDI 的 IT 领导、我们的高级工程师和来自于双方的项目经理集中到一起。我们关注我们在需求和用户界面设计方面的讨论（虽然不是在同一时间）。在 JAD 会议之前，我们已经提供了一个议程安排，从议程安排中仲裁者将引导会议进行。会议中进行很多的讨论，并且一个高级的图被画在了白板上。（我们使用了一个数码的白板，我们可以在这个数码白板上保存和打印被画出的图，这是非常节省时间的。）我们也让一个工程团队的成员花费一些时间来记录任何支持图的注释。
我们在项目的两个阶段尝试使用了 JAD 方法：在早期的细化阶段针对角色（actor）和用例（use case）需求；和在后期的细化阶段针对用户应用程序的工作流程和设计（主要是用户界面设计）。这里我们将转向到我们的例子的后者。
在这个第二次的 JAD 会议上，我们项目中在 JSP 和 HTML 方面做擅长的开发人员展示了基于用例分析和注释的早期用户界面模拟。我们在每个屏幕界面上花费和 15 分钟的时间，与全体参加会议的人员针对特定的用户界面外貌和整体的界面感观、被展示的功能和贯穿系统的导航进行集体的谈论。当有任何建议时，我们在现场对这些建议进行了探讨。我们将所以的讨论结果结合到了一起，并在过程中学到这些教训：
对于开发人员来说，在计算机上跟上被建议的重大改变是困难的。我们需要使用一种特殊的快速构建原型的工具、限制建议的范围，或者由多个开发人员并行的实现改变。
仲裁者必须在引导会议流程方面是非常老练的：具有足够的技术背景以跟随讨论，但也必须是足够外向的以使每一个参与讨论的人在轻松自然的氛围中，并且从中立的角度来引导讨论。
仲裁者不应该负责跟踪时间。相反，应该由另一个人来关注会议中的任务和被分配的时间的控制。如果某一个议题超过了规定的时间，那么这个议题应该被推延到其他的时间再讨论。
JAD 会议要求在保护范围和时间计划上有一个微妙的平衡，并且鼓励反馈和改进的想法。
显示和解说
我们发现简单的显示和解说的演示方法是最有效的并且最容易管理的方法。不像在现实的 JAD 会议中处理问题那样，使用被大约一周左右的周期分开的小的演示可以给我们时间来考虑关于请求的影响，并且我们可以提出针对于被识别出的问题的解决方案。如果经过批准我们能够有额外的 JAD 的培训，我们也许能够将几个显示和解说的演示压缩到一个或者两个 JAD 会议中；在同一场所中保持每一个人进行有效的协作可以节省我们计划中的大量时间。
客户实际操作的机会
随着构建阶段的进展，我们的系统到达了客户能够开始对其进行操作的时候了。如 表 1 所示，系统演示开始了四到六周时，我们就进入了构建阶段。在这些演示期间，我们允许 ASDI 直接的使用系统。这不仅给了他们更多的参与到项目中的感觉，而且我们也从他们那里得到了关于系统的反馈，如果不让他们使用系统，我们将无法得到这些反馈。当系统逐渐成熟起来时， ASDI 花费了更多的时间在系统上，并且他们为我们提供了免费的测试工作和在产品开发早期修改一些问题的机会。然而，伴随着允许客户自由的访问一个不成熟的系统也会存在一定的风险：
如果系统从外表上看是相当优雅的（也就是说，在它的用户界面上），客户也许会假定所有的工作都已经几乎被完成了。
如果系统从外表上看是很粗糙的（比如，缺乏错误处理和稳定性），客户也许会对团队的进度感到不安。
当 ASDI 操作系统的早期版本时，我们必须不断的提醒他们，我们仅仅是在创建第一阶段的概念验证，并且那些“外表漂亮”的非关键特性将会被延迟到后续的项目工作中完成。然而，我们确保了他们所有的建议都被记录了下来，因为他们的许多想法都是非常好的，并且值得我们在接下来的工作中再次的考虑。通常，ASDI 理解我们为他们提供实际操作系统的机会的意图和限制，因此上面所提到的风险对于我们来说不是什么问题。
系统的正面 VS. 系统的早期版本
开发团队花费了一些时间来辩论对于早期的演示创建系统正面相比于使用一个演进的产品的优点。典型的，正面是一个掩藏了系统背后场景的产品，它被尽可能快速并且低成本的实现。另一方面，使用演进的产品需要投入更多的设计和实现的工作到早期的版本中。
实际上，在 ASDI 项目的第一阶段中，为了演示图形化的用户界面，在分析用户工作流程的过程中我们尝试使用了这两种方法。表 2 比较了两种方法的结果。
演示外表
正面
系统早期版本
被使用的开发工具
Microsoft FrontPage
JSP/Text 编辑器
在第一个演示之前准备时间
3 天
1.5 周
向客户传达工作流程/GUI 的能力
好
好
转移类似的外表到最终产品的能力
一般
好
针对请求和建议的回复更改演示的速度
非常快
慢到中等速度
在演示后的重用机会
不好
一般
培训时间
短期培训
短期培训（因为团队在在 JSP 上经过了培训）
与后端的 servlet 和数据库集成的容易程度
不好到一般
表 2: 使用正面演示 UI VS. 使用早期代码版本演示 UI
我们在项目的初始阶段和细化阶段的早期为演示使用了正面。虽然经常会有一些零散的演示，但是我们觉得投入是值得的。我们使用了 FrontPage ，因为我们没有与 Java servlet 和数据库集成的困难，因为我们还没有任何需要连接的数据库计划或者组件。因为我们在项目中使用了 FrontPage ，FrontPage 2002 的数据库集成能力已经得到了改进，如果我们在将来的项目中需要，我们甚至可以使用它来从数据库计划中显示测试数据。
一旦设计开始稳定，我们就进入到了一个使用 JSP 和 servlet 的迭代的编码周期。在项目的早期部分（在初始和细化期间）编写零散的 Java 代码是价值很小的，因为在那个时候除了 Java 我们甚至不能确定我们将要使用 JSP 和 servlet 。使用 FrontPage 是更快更容易的，并且我们不用担心任何隐含的技术选择。
早期并且经常的构建
在项目的构建阶段的早期开始产生系统的构建版本能够更加快速的消除问题，并且频繁的产生构建版本能够帮助保持项目中每一个成员的同步。在 ASDI 项目中在过多和过少的构建版本之间找到一个平衡点是重要的。选择频繁的构建就必须考虑到项目复杂性、休假计划、团队技能、客户可用性（对于外部演示）和组件和子系统之间的依赖的问题。
子系统的构建
我们的子系统集成了被分别开发的组件，并且有时导致生成系统的演示。我们并没有坚持要求所有的子系统的构建版本都具有演示；而是团队领导会实行一个内部的构建版本 — 通常每个构建版本的计划时间是每周一次 — 恰好确保了各部分代码能够集合在一起。这同步了工作在子系统中的每一个人，因为例如，他们所有的人都必须为构建版本使用相同的数据库计划。当团队领导选择演示被集成的子系统时，这个演示会在周末的团队会议上被展示，通过观看他们负责的系统部分是如何被改进的，给团队一种成就觉。
团队领导在建立这些演示上是高效的。整个团队都知道在星期五的上午开始修改他们的代码以为集成工作做准备。典型的，生成构建版本是在中午过后，如果在集成过程中出现了任何问题，允许在一个或者两个小时时间修改和讨论。在确保所有的最近被更新的代码都已经被检入（check in）后，团队领导将从源代码存储库库中提出所有的代码。
我们的配置管理工具是我们这个项目的一块绊脚石。我们没有选择 Rational ClearCase 作为我们的配置管理方法，而是使用了免费的 CVS (Concurrent Versioning System) 工具提供的能力。配置管理是软件管理的重要组成部分，并且在项目之后，我们希望我们能够投入更多的时间在我们的配置管理工具的选择、集成和使用的指导上。我们没有使用一个集成的方案就意味着：
团队几乎不可能以一种正规的基础来检入（check out）和检出（check in）文件。
数据在不良的配置管理中丢失。
变更不能被容易的关联到集成与测试（I&T）的问题或者软件的变更请求上。
使用不好的 CVS 工具将使团队的工作效率大大降低。
我们决定如果我们赢得了项目的第二阶段的和约，我们将评估 ClearCase 作为我们使用的另一个 Rational 工具集中的工具。
系统的构建
一些或许所有的最近开发的子系统被集成成为一个系统构建版本，就像子系统构建一样，系统的构建有相同的好处和目标，除了：
系统构建会花费更多的准备工作，对团队有更大的影响，并且对于我们来说是更大的分散注意力的原因。
他们通常揭示了大量的问题，甚至是能够威胁项目成功的更加严重的问题。
他们在构建阶段的后期开始，因为我们需要足够数量的子系统来调整集成的工作。
完整的系统构建最终要由集成与测试（I&T）团队的介入。
工程团队在没有集成与测试团队的帮助下完成了首先两个完整系统的试验版本。这些最初的构建工作是痛苦的：我们在配置管理上有很多问题；一些子系统接口级别的细节已经丢失了；并且一些子系统稍微的落后于计划。在第二个试验版本中集成与测试团队作为观察者的身份加入了进来，并且开始了下一个系统构建的集成工作。这有利于向集成与测试团队平滑的转移职责和知识，同时也不会在首先两个构建版本中浪费时间。
对于工程团队和后期的集成与测试团队来说，对在每一个构建版本中应该包括什么有一个清晰的概念是十分重要的；否则，构建工作将会很慢的执行，并且会以浪费团队的时间结束。实际上，我们很好的理解了迭代构建的过程和每一个集成工作的目标，并且我们能够成本高效的执行构建的工作。
总结
我们的构建和内部演示工作通常进行的非常平稳；然而，远程个构建需要来自于项目工程师的额外注意。对于远程开发的子系统的计划经常不能按时完成，因为远程的开发团队不能访问和核心工程团队一样的资源。
我们的客户演示是非常成功的。我们非常自信我们在构建阶段的早期拥有一个清晰的客户需求的描述，并且客户对我们构建的产品也有一个清晰的概念。在最终的产品交付期间，存在很少的错误期望和惊讶。
计划未来
现在系统的构建开始进行了，我们很快的将步入测试工作。我们计划使用 Rational 的测试工具帮助我们完成测试工作。我们需要确保所有 ASDI 项目的功能都被适当的执行过，并且在一定的负载下测试我们 Web 应用的性能。这些活动也增加了集成与测试团队对系统的熟悉，并且开始学习使用测试工具。
主要风险
我们的构建和演示没有增加任何的新的风险；实际上，发现并修改早期的问题帮助减少了风险。我们继续的感觉到在时间进度上的压力，然而，我们知道构建必须以快速的步伐进行。在起草我们的功能测试说明中我们已经落后于计划了。 RUP 建议在项目的更早的时候开始这些工作，我们现在承受了巨大的压力，因为我们已经延迟了个活动。
资源
"Joint Application Development (JAD) for Requirements Collection and Management" by Alan Cline (Carolla Development, Inc. whitepaper)
"Joint Application Development (JAD) — What do you really want?" by the University of Texas at Austin
关于作者
Steven Franklin 在软件的设计、架构和工程过程方面有非常广泛的背景，这些经验通常被用到大的，分布式的信息管理和控制系统中。他从1997年开始使用 Rational 工具，他主要的兴趣在 XML 、J2EE、无线和软件工程技术方面。你可以通过 steve@sfranklin.net联系 Steven.
