概念:
|
白皮书: |
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 包含四个基本“活动”(编码、测试、侦听和设计),实际上,它们与 RUP 规程更紧密地保持一致。使用需要附加活动(这些活动映射到 RUP 中的某些其它规程)性能的一组做法来执行这些 XP 活动。按照 Extreme Programming Explained,XP 的做法是:
例如,作为“计划博弈”做法的结果而执行的活动将主要映射到 RUP 的项目管理规程。但某些 RUP 主题(如业务建模和发布软件的部署)在 XP 的范围之外。需求征集大部分在 XP 的范围之外,因为由客户定义和提供需求。另外,由于 XP 处理更简单的开发项目,因此可以非常轻松地处理 RUP 详细包含在配置和变更管理规程以及环境规程中的问题。
在 XP 和 RUP 都包含的规程中,XP 中描述的以下做法可以(在某些情况下已经)在 RUP 中使用:
好的流程必须在“细微”的层面上执行,这个建议经常是令人不快的并且可能不适合某些公司文化。因此,RUP 不提倡严格强制。但是,在某些情况下,成对工作和 XP 提倡的某些其它基于团队的做法是明显有优势的,因为每个团队成员可以帮助其它团队成员;例如:
对于较大的系统,以下 XP 做法不能很好地扩展(XP 也未声明它们可以),因此对它们的使用要遵守 RUP 中的此限制性条款。
最后,在 RUP 简单设计中乍一看可能有用的 XP 做法,在通常应用时需要某些精化和警告。
在处理 RUP 调用“非功能”需求时,这里有一个问题,类似于局部最优化的问题。这些需求也为客户提供业务价值,但将它们表示成叙述会更困难。XP 调用的某些约束即属于此类别。RUP 不提倡以任何推测的方式设计多于必需的内容,但 RUP 提倡在头脑中构思体系结构模型 - 此模型是符合非功能需求的关键因素之一。
因此,RUP 同意 XP 的以下观点,即“简单设计”应该包括运行所有测试,但附加条件是这包括证明软件将符合非功能需求的测试。同样,这只在系统规模和复杂性增加时或者体系结构空前或非功能需求难以负担时才成为主要问题。例如,对编组数据(在不同种类的分发式环境中操作)的需要似乎使代码过于复杂,但在整个系统中它将仍然是需要的。
当针对小型项目定制 RUP 并因而减少工件需求时,这如何与 XP 项目中的工件的等价物相比呢?通过查看 RUP 中的小型项目的示例开发案例,我们看到样本 RUP 配置被配置成产生更少的工件(如表 1 所示)。
XP 工件
|
RUP 工件
(来自 ![]() |
---|---|
叙述 来自对话的其它文档 |
远景 词汇表 用例模型 |
约束 | 补充规范 |
验收测试和单元测试 测试数据和测试结果 |
|
软件(代码) | 实施模型 |
发行版 | ![]() ![]() |
系统隐喻 | 软件体系结构文档 |
设计(CRC、UML 草图) 技术任务和其它任务 最终产生的设计文档 支持文档 |
设计模型 |
编码标准 | ![]() |
工作区 测试框架和工具 |
![]() ![]() |
发行计划 迭代计划 叙述评估和任务评估 |
软件开发计划
迭代计划 |
全面计划和预算 | 业务用例 风险列表 |
进度报告 任务运行的时间记录 度量数据(包括资源、范围、质量和时间) 结果跟踪 会议报告和记录 |
状态评估 迭代评估 复审记录 |
缺陷(和关联数据) | 变更请求 |
代码管理工具 | 项目存储库 ![]() |
最高点(解决方案) | |
XP 自身(建议和指南) | |
[不包括在 XP 中] |
表 1:针对小型项目的工件的“XP-RUP”映射
虽然两边的工件详细程度不同,但通常情况下, RUP 中小型项目(XP 可轻松处理的那一类)的工件与 XP 项目的同等工件映射得相当好。
请注意,小型项目的示例开发案例也包括 XP 不涵盖的但许多项目需要的一些工件。这些工件包括数据模型和与部署相关的工件,如
最终用户支持材料。
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 中角色数量的区别可很容易地解释:
当将 RUP 角色映射到小型项目时,它们所对应的、类似 XP 的角色的数量明显减少 - 职位或工作头衔的数量是 5。表 3(摘自 RUP)显示了这种与对应 XP 角色的映射。
XP 角色 | 示例 RUP 小型项目团队成员 | RUP 角色 |
---|---|---|
辅导人员 咨询人员 重要主管 |
Sally Slalom,高级经理 | 项目经理![]() 技术复审员 配置管理员 变更控制管理员 |
客户 | 涉众(如远景中所记录) |
管理复查员 技术复审员(需求) |
客户 重要主管 跟踪人员 |
Tom Telemark,高级软件工程师 | 系统分析人员 需求指定员 用户界面设计员 软件设计人员 技术复审员 测试经理 ![]() 以及(在较次要的程度上)开发人员角色。 |
程序员 测试员 |
Susan Snow,软件工程师 Henry Halfpipe,初级软件工程师 |
设计人员 实施者 技术复审员 集成员 ![]() ![]() ![]() |
跟踪人员 | Patrick Powder,管理助理 | 负责维护项目 Web 站点、辅助“项目经理”角色计划/安排活动以及辅助“变更控制管理员”角色控制工件的变更。还可能按需为其它角色提供帮助。 |
表 3:在小型项目上将 XP 角色映射到 RUP 角色
RUP 是流程框架,可以从它配置然后实例化特定流程。必须配置 RUP - 这是 RUP 自身中定义的必需步骤。严格地说,我们应该将定制版本的 RUP 和 XP 相比较 - 即在 RUP 根据 XP 明确设定的项目特征(和可推断出的项目特征)进行定制之后。这样一个定制的 RUP 流程可容纳很多 XP 做法(如成对编程、测试优先设计和重构),但它仍然与 XP 不同,因为 RUP 强调体系结构、抽象(在建模中)和风险的重要性以及时间上的不同结构(阶段和迭代)。
XP 旨在为小型项目实施简单流程。在实施过程中,它还包含未完全精化的描述(至少在书中)。在 XP 实施中,始终会有需要随时发现、创造或定义的事情。RUP 将容纳在规模和种类方面都适合而又超过 XP 范围的项目。正如此指南所示,RUP 实际上与 XP 著作中描述的大多数做法相当一致。
请记住,XP 的本质是侧重于组织、人员和文化。这在所有项目中都很重要并毫无疑问适用于使用 RUP 的那些项目。小型项目可从一起使用这些做法中大大受益。
Rational Unified Process
|