主题

白皮书:


简介 回到页首

Rational Unified Process(RUP)是 Rational Software 已改进了多年的流程框架,它已被广泛用于从小型到大型的、所有类型的软件项目。最近,数量不断增长的“灵活”流程 - 如 eXtreme Programming(XP)、SCRUM、功能驱动的开发(FDD)和 Crystal Clear Methodology - 已被公认为建立较小系统的有效方法。(有关 Agile Alliance 的进一步信息,请参阅 www.agilealliance.org。)

以下各节旨在帮助那些项目团队评估在其中一种方法中找到的一部分“灵活”做法,以查看它们是如何按由 RUP 定义的更完整的软件开发流程来处理的。

概述 回到页首

灵活团体综合了许多特别适用于小型、协同进行的项目团队的“最佳实践”。尽管 RUP 是针对所有规模的项目团队的,它也能成功地应用于小型项目。通常,RUP 和灵活团体的流程对于开发高质量软件所需的关键最佳实践具有相似的观点 - 例如,应用迭代开发和侧重于最终用户。

以下各节解释了如何将在灵活团体中确定的某些“最佳实践”应用于基于 RUP 的项目(这些项目希望从这些做法的某一些中获益)。在这种情况下,焦点将明确放在那些由 eXtreme Programming(XP)方法提出的做法上。(有关 XP 的更多信息,请参阅 Web 站点:http://www.extremeprogramming.org。)

XP 做法 回到页首

XP 包含四个基本“活动”(编码、测试、侦听和设计),实际上,它们与 RUP 规程更紧密地保持一致。使用需要附加活动(这些活动映射到 RUP 中的某些其它规程)性能的一组做法来执行这些 XP 活动。按照 Extreme Programming Explained,XP 的做法是:

  • 计划博弈:通过结合业务优先级和技术评估来快速确定下一个发行版的范围。当现实情况超出计划时,就更新计划。
  • 小型发布:将简单系统快速投入生产,然后在很短的周期内发行新的版本。
  • 系统隐喻:使用讲述整个系统如何运行的简单共享叙述来指导所有开发。
  • 简单设计:在任何给定时刻,应将系统设计得尽可能的简单。一发现额外的复杂性就除去它。
  • 测试:程序员持续不断地编写单元测试,为了开发得以继续,测试必须无错误地运行通过。客户编写测试,证明功能已完成。
  • 代码重构:程序员重构系统,而不更改它的行为,以除去重复、改进通信、简化系统或增加灵活性。
  • 成对编程:所有生产代码都由两个程序员在一台机器上编写。
  • 集体所有权:任何人可以在任何时间更改系统任何位置的任何代码。
  • 持续集成:一天内多次集成和建立系统,每完成一项任务就执行一次。
  • 每周 40 小时工作制:将每周工作不超过 40 个小时作为一条规则。在连续的一周中从不加班。
  • 现场客户:团队中包含真实存在的用户,可专职回答问题。
  • 编码标准:程序员按照强调通过代码沟通的规则来编写所有代码。

例如,作为“计划博弈”做法的结果而执行的活动将主要映射到 RUP 的项目管理规程。但某些 RUP 主题(如业务建模和发布软件的部署)在 XP 的范围之外。需求征集大部分在 XP 的范围之外,因为由客户定义和提供需求。另外,由于 XP 处理更简单的开发项目,因此可以非常轻松地处理 RUP 详细包含在配置和变更管理规程以及环境规程中的问题。

与 RUP 兼容的 XP 做法 回到页首

在 XP 和 RUP 都包含的规程中,XP 中描述的以下做法可以(在某些情况下已经)在 RUP 中使用:

  • 计划博弈:XP 关于计划的指导可以用于实现很多在 RUP 项目管理规程中为非常小的项目提出的目标。这对于正式程度低的项目(不需要生产正式的中间项目管理工件)尤其有用。
  • 测试优先设计和重构:这些是可应用于 RUP 实施规程的很好的技术。要求测试优先设计的 XP 测试做法对于详细阐明需求是特别出色的方法。正如我们将在下一节中看到的,对于更大型系统,重构可能不能很好扩展。
  • 持续集成:RUP 在子系统和系统级别上(一个迭代内)通过工作版本支持此做法。在新兴系统环境中集成和测试单元测试组件。
  • 现场客户:很多 RUP 活动会因为让客户作为团队成员留在现场而大大受益,这可以减少所需的中间可交付工件(特别是文档)的数量。作为“客户-开发人员”交流的首选媒介,XP 强调对话,它的成功依赖于连续性和熟悉性;但是,当必须转换系统(甚至是小型系统)时,将不只需要对话。XP 允许将这作为后添加的内容,例如,项目结束时的设计文档。虽然它不禁止产生文档或其它工件,但 XP 指示您应该只产生真正需要的那些文档或工件。RUP 同意这样,但当连续性和熟悉性不够理想时,RUP 会继续描述您的可能需要。
  • 编码标准:RUP 具有工件编程指南 - 几乎总是被视作是必需的。(大多数项目风险情况,作为定制指南的主要驱使因素,促成了这个事实。)
  • 每周 40 小时工作制:正如在 XP 中的那样,RUP 建议工作超时不应是一个长期情况。XP 不建议固定限制为 40 小时,认可对工作时间的不同的容忍度。软件工程师是以长时间工作而没有额外报酬而闻名的 - 只是为了对看到事情完成感到满意,而管理人员就不必强制阻止了。管理人员从不应该做的是利用或强加此做法。他们始终应该收集实际工作的小时数统计(即使是无报酬的)。如果在很长的一段时间中,任何人工作的时数记录似乎很高,那么肯定要对这进行调查;但是,这些问题应当在认识到团队其他人员的所有关注方面的前提下,就在出现问题的环境中(在管理人员和个人之间)解决。40 个小时只是一个引导方向,但不是强制的。
  • 成对编程:XP 声明成对编程对于代码质量是有益的并且一旦获得了此技能,它将变得更加令人享受。RUP 不以细分的方式描述代码生产的机制,尽管在基于 RUP 的流程中使用成对编程肯定是可能的。关于成对编程以及测试优先设计和重构的某些信息现在随 RUP 以白皮书的形式提供。显然,不要求使用 RUP 中的任何做法,但是在拥有开放交流的文化的团队环境中,我们斗胆猜测成对编程(在对总体生命周期成本的影响方面)的好处是很难被认清的。在合作良好的团队中,人们将很自然地一起讨论和解决问题,而不会被强迫这样做。

好的流程必须在“细微”的层面上执行,这个建议经常是令人不快的并且可能不适合某些公司文化。因此,RUP 不提倡严格强制。但是,在某些情况下,成对工作和 XP 提倡的某些其它基于团队的做法是明显有优势的,因为每个团队成员可以帮助其它团队成员;例如:

  • 在团队形成的头几天,当人员渐渐熟识时,
  • 在对于某些新技术缺乏经验的团队中,
  • 在混合了有经验的人员和新手的团队中。

不能很好扩展的 XP 做法 回到页首

对于较大的系统,以下 XP 做法不能很好地扩展(XP 也未声明它们可以),因此对它们的使用要遵守 RUP 中的此限制性条款。

  • 系统隐喻:对于较大、复杂的系统,像隐喻一样的体系结构是明显不够的。RUP 为体系结构提供了丰富得多的描述框架,它不只是(如 Extreme Programming Explained 描述的)“大框架和连接”。即使在 XP 团体中,系统隐喻目前也不被推荐。它不再是 XP 中的其中一种做法(直到它们可以想出如何描述好它 - 或许系统隐喻可以帮助它们)。
  • 集体所有权:如果负责小型系统或子系统的团队成员熟悉所有代码,这是有用的。但是,是否要让所有团队成员同样能够在任何位置做出更改应当根据代码的复杂性。由当前处理相关代码段的个人(或成对人员)做出修正通常将更快一些(并更安全)。甚至是编写得最好的代码,对代码的熟悉程度也会随着时间的过去而急剧下降,当代码的算法很复杂时尤其如此。
  • 代码重构:在大型系统中,经常性的重构不能代替体系结构的缺乏。Extreme Programming Explained 认为“XP 的设计策略类似于梯度算法。您获得一个简单的设计,然后使其变得稍稍复杂一些,接着简单一些,然后再更复杂一些。梯度算法的问题在达到局部的最优化,在此,没有小的变更可以改进状况,但大的变更可以做到。”在 RUP 中,体系结构提供“宽广范围”的视图以及对它的访问,使大型、复杂的系统易于处理。
  • 小型发布:客户可以接受和部署新的发行版的速率将依赖于多个因素,通常包括系统大小,这通常与业务影响相关。两个月的周期对于某些类型的系统来说可能太短了;部署逻辑可能会禁用它。

需要警告的 XP 做法 回到页首

最后,在 RUP 简单设计中乍一看可能有用的 XP 做法,在通常应用时需要某些精化和警告。

  • 简单设计
    XP 是非常强调功能驱动的:选择用户叙述,将它们分解成任务,然后实现。按照 Extreme Programming Explained,在任何给定时间,软件的正确设计是能运行所有测试、没有重复逻辑、陈述每个对于程序员都很重要的意图并具有尽可能少的类和方法。XP 不认为添加对于为客户提供业务价值所不需要的任何内容是有用的。

    在处理 RUP 调用“非功能”需求时,这里有一个问题,类似于局部最优化的问题。这些需求也为客户提供业务价值,但将它们表示成叙述会更困难。XP 调用的某些约束即属于此类别。RUP 不提倡以任何推测的方式设计多于必需的内容,但 RUP 提倡在头脑中构思体系结构模型 - 此模型是符合非功能需求的关键因素之一。

    因此,RUP 同意 XP 的以下观点,即“简单设计”应该包括运行所有测试,但附加条件是这包括证明软件将符合非功能需求的测试。同样,这只在系统规模和复杂性增加时或者体系结构空前或非功能需求难以负担时才成为主要问题。例如,对编组数据(在不同种类的分发式环境中操作)的需要似乎使代码过于复杂,但在整个系统中它将仍然是需要的。

针对小型项目的工件映射 回到页首

当针对小型项目定制 RUP 并因而减少工件需求时,这如何与 XP 项目中的工件的等价物相比呢?通过查看 RUP 中的../../../examples/devcase_sp/dc_index.htm -- This hyperlink in not present in this generated website小型项目的示例开发案例,我们看到样本 RUP 配置被配置成产生更少的工件(如表 1 所示)。

XP 工件
RUP 工件
(来自../../../examples/devcase_sp/dc_index.htm -- This hyperlink in not present in this generated website小型项目的示例开发案例
叙述
来自对话的其它文档
远景
词汇表
用例模型
约束 补充规范
验收测试和单元测试
测试数据和测试结果

../../../process/artifact/ar_tstpl.htm -- This hyperlink in not present in this generated website测试计划
../../../process/artifact/ar_tstcs.htm -- This hyperlink in not present in this generated website测试用例../../../process/artifact/ar_tstste.htm -- This hyperlink in not present in this generated website
测试套件
(包括../../../process/artifact/ar_tstsc.htm -- This hyperlink in not present in this generated website测试脚本../../../process/artifact/ar_tstdta.htm -- This hyperlink in not present in this generated website测试数据
../../../process/artifact/ar_tstlog.htm -- This hyperlink in not present in this generated website测试日志
测试评估概要

软件(代码) 实施模型
发行版 ../../../process/artifact/ar_prdct.htm -- This hyperlink in not present in this generated website产品(部署单元)
../../../process/artifact/ar_rlsnt.htm -- This hyperlink in not present in this generated website发行说明
系统隐喻 软件体系结构文档
设计(CRC、UML 草图)
技术任务和其它任务
最终产生的设计文档
支持文档
设计模型
编码标准 ../../../process/artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated website特定于项目的指南
工作区
测试框架和工具
../../../process/artifact/ar_devcs.htm -- This hyperlink in not present in this generated website开发案例
../../../process/artifact/ar_tstenv.htm -- This hyperlink in not present in this generated website测试环境配置
发行计划
迭代计划
叙述评估和任务评估
软件开发计划
迭代计划
全面计划和预算 业务用例
风险列表
进度报告
任务运行的时间记录
度量数据(包括资源、范围、质量和时间)
结果跟踪
会议报告和记录
状态评估
迭代评估
复审记录
缺陷(和关联数据) 变更请求
代码管理工具 项目存储库
../../../process/artifact/ar_wkspc.htm -- This hyperlink in not present in this generated website工作区
最高点(解决方案)

原型
用户界面原型
体系结构概念验证

XP 自身(建议和指南)

../../../process/artifact/ar_tstidslst.htm -- This hyperlink in not present in this generated website测试构想列表
../../../process/artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated website特定于项目的指南

[不包括在 XP 中]

数据模型
../../../process/artifact/ar_eusm.htm -- This hyperlink in not present in this generated website最终用户支持材料。

表 1:针对小型项目的工件的“XP-RUP”映射

虽然两边的工件详细程度不同,但通常情况下, RUP 中小型项目(XP 可轻松处理的那一类)的工件与 XP 项目的同等工件映射得相当好。

请注意,../../../examples/devcase_sp/dc_index.htm -- This hyperlink in not present in this generated website小型项目的示例开发案例也包括 XP 不涵盖的但许多项目需要的一些工件。这些工件包括数据模型和与部署相关的工件,如../../../process/artifact/ar_eusm.htm -- This hyperlink in not present in this generated website最终用户支持材料。

活动 回到页首

RUP 将活动定义为由角色执行的工作 - 使用和转换输入工件或产生新的和经过更改的输出工件。RUP 继续列举这些活动并按照 RUP 规程对它们分类。这些规程包括:业务建模、需求、分析与设计、部署以及项目管理(还有别的)。

活动通过它们生产和消耗的工件与时间建立关系:当输入可用时(且处于适当成熟的状态),活动从逻辑上就可以开始。这意味着,“生产者-消费者”活动对可以在时间上有重叠(如果工件状态允许的话);它们不必严格依次进行。活动旨在对于应如何生产工件提供强有力的指导,并也可用于帮助项目经理做出计划。

在 RUP 中迂回行进的(如从生命周期、工件和活动方面所述)是“最佳实践”:某些软件工程原则,它们被证实可产出以可预测的日程安排和预算构建的高质量软件。RUP 通过活动(和关联工件)支持和实现这些最佳实践 - 它们是贯穿 RUP 的主题。请注意,XP 也使用“做法”概念,但应该看到,它与 RUP 的最佳实践概念并不完全一致。

XP 极具吸引力地将软件开发简单描述为包含四个基本活动 - 编码、测试、侦听和设计 - 可按照某些支持做法(如第 9 章“Extreme Programming Explained”所讨论)启用和构造这些活动。实际上,如较早前提到的,在范围上,XP 的活动更接近 RUP 规程而不是 RUP 活动,并且发生在 XP 项目上的许多活动(除了四个基本活动)将来自 XP 做法的精化和应用。

因此,在 XP 中存在 RUP 活动的等价活动,但 XP 的“活动”并没有像这样正式确定或描述。例如,请看 Extreme Programming Installed 中的第 4 章“用户叙述”,您将发现标题“使用写在卡片上的叙述定义需求”,并且在一整章中综合了流程描述和关于用户叙述是什么以及应如何(和由谁)产生的指示信息。延续那种方式,在 XP 书的各节(在综合了侧重于工件和侧重于活动的各个标题下)中以不同的规定和详细程度描述了“产生的事情”和“完成的事情”。

RUP 的级别明显很高的规定是由于它在处理活动及其输入和输出中的完整性和更大正式性。XP 不缺乏规定,但可能试图保持容易执行,简单地略过了正式性和详细性。明确性的缺乏既不是优点也不是缺点,但在 XP 中详细信息的缺乏却不应混淆为简明扼要。没有详细信息对于较有经验的开发人员是没问题的,但在许多情况下,更多的详细信息对于新的团队成员和仍在努力赶上团队软件开发速度的团队成员有很大的帮助。

对于活动,正如对于工件一样,始终侧重于努力实现的目标是很重要的。盲目执行活动从来不是好的做法。在为达到目标而需要时,有活动和相关指导可供参考,但不应将它们用作不必思考要努力实现的目标的借口。在 XP 中很好地明确了这种思想,并且我们相信每个 RUP 用户都应遵循这一点。

角色 回到页首

在 RUP 中,活动据称是由角色(或更准确些,是由扮演角色的个人或组)执行的。角色也负责特定的工件;负责的角色通常将创建该工件并确保由其它角色做出的任何变更(如果完全允许)不会破坏该工件。个人或分组人员可以只执行一个角色或执行几个角色。角色不必只映射到组织中的单个职位或“位置”。

Extreme Programming Explained 确定了适用于 XP 的七种角色:程序员、客户、测试员、跟踪人员、辅导人员、咨询人员和重要主管,并描述了他们的职责和将执行这些角色的人员所需的能力。在一些其它的 XP 书中也引用了这些角色。XP 和 RUP 中角色数量的区别可很容易地解释:

  • XP 不涵盖所有的 RUP 规程。
  • 对于组织内的职位(可能具有多个职责)和 RUP 角色,XP 角色与前者更可比。例如,XP 的程序员实际执行多个 RUP 角色 - 实施者、代码复审员和集成员,这些角色要求的能力稍有差别。

小型项目上的 XP 和 RUP 角色 回到页首

当将 RUP 角色映射到小型项目时,它们所对应的、类似 XP 的角色的数量明显减少 - 职位或工作头衔的数量是 5。表 3(摘自 RUP)显示了这种与对应 XP 角色的映射。

XP 角色 示例 RUP 小型项目团队成员 RUP 角色
辅导人员
咨询人员
重要主管
Sally Slalom,高级经理 项目经理
../../../process/workers/wk_depm.htm -- This hyperlink in not present in this generated website部署管理员
技术复审员
配置管理员
变更控制管理员
客户 涉众(如远景中所记录)
管理复查员
技术复审员(需求)
客户
重要主管
跟踪人员
Tom Telemark,高级软件工程师 系统分析人员
需求指定员
用户界面设计员
软件设计人员
技术复审员
测试经理
../../../process/workers/wk_tstanl.htm -- This hyperlink in not present in this generated website测试分析人员

以及(在较次要的程度上)开发人员角色。

程序员
测试员

Susan Snow,软件工程师

Henry Halfpipe,初级软件工程师

设计人员
实施者
技术复审员
集成员
../../../process/workers/wk_tstds.htm -- This hyperlink in not present in this generated website测试设计员
../../../process/workers/wk_tstr.htm -- This hyperlink in not present in this generated website测试员
../../../process/workers/wk_tchwr.htm -- This hyperlink in not present in this generated website技术作者
跟踪人员 Patrick Powder,管理助理 负责维护项目 Web 站点、辅助“项目经理”角色计划/安排活动以及辅助“变更控制管理员”角色控制工件的变更。还可能按需为其它角色提供帮助。

表 3:在小型项目上将 XP 角色映射到 RUP 角色

在 RUP 中应用 XP 做法 回到页首

RUP 是流程框架,可以从它配置然后实例化特定流程。必须配置 RUP - 这是 RUP 自身中定义的必需步骤。严格地说,我们应该将定制版本的 RUP 和 XP 相比较 - 即在 RUP 根据 XP 明确设定的项目特征(和可推断出的项目特征)进行定制之后。这样一个定制的 RUP 流程可容纳很多 XP 做法(如成对编程、测试优先设计和重构),但它仍然与 XP 不同,因为 RUP 强调体系结构、抽象(在建模中)和风险的重要性以及时间上的不同结构(阶段和迭代)。

XP 旨在为小型项目实施简单流程。在实施过程中,它还包含未完全精化的描述(至少在书中)。在 XP 实施中,始终会有需要随时发现、创造或定义的事情。RUP 将容纳在规模和种类方面都适合而又超过 XP 范围的项目。正如此指南所示,RUP 实际上与 XP 著作中描述的大多数做法相当一致。

请记住,XP 的本质是侧重于组织、人员和文化。这在所有项目中都很重要并毫无疑问适用于使用 RUP 的那些项目。小型项目可从一起使用这些做法中大大受益。

灵活的流程引用 回到页首

  • eXtreme 编程(XP)(有关更多信息,请参阅 http://www.extremeprogramming.org/more.html。):
    • Extreme Programming Explained: Embrace Change。Kent Beck 解释了极限编程背后的概念和原理。这本书教授了内容和原因,但没有教授将如何做。
    • Refactoring Improving the Design of Existing Code。Martin Fowler 撰写了关于重构的首本权威书籍。以模式呈现。有大量 Java 形式的示例。这本书教授了如何和为什么重构。
    • Extreme Programming Installed。作者是 Ron Jeffries、Chet Hendrickson 和 Ann Anderson。这本书比“Expreme Programming Explained”更详细地讲述了具体的 XP 做法。它教授了如何按 XP 风格编程。
    • Planning Extreme Programming。作者是 Kent Beck 和 Martin Fowler。这本书简介了关于如何在快速交付环境中规划软件的最新思想。它教授了如何运行 XP 项目。
    • Extreme Programming Examined。作者是 Giancarlo Succi 和 Michele Marchesi。在 XP2000 上提出的论文。一套全面的论文讲述了大多数主题。
    • Extreme Programming in Practice。作者是 Robert C. Martin 和 James W. Newkirk。以切实的详细程度描述了一个使用 XP 的真实项目。
    • Extreme Programming Explored。作者是 William C. Wake。基于流行的 XPlorations Web 站点。详细探讨了具体的主题。
    • Extreme Programming Applied: Playing to Win。作者是 Ken Auer 和 Roy Miller。来自前沿人士的、应用 XP 的经验。即将在九月出版。
  • 有关 Agile Alliance 的其它成员的信息,请参阅 http://www.agilealliance.org/home



Rational Unified Process   2003.06.15