| UML软件工程组织 | |||
| |
|||
|
|||
基于 COTS 项目的 IBM Rational Unified Process：介绍
2008-03-19 作者：Cécile Péraire,Russell Pannone 来源：IBM
本文来自于 Rational Edge：根据 Commercial-Off-the-Shelf（COTS）包建立解决方案呈现出独特的挑战。本文介绍一种 IBM Rational Unified Process®，或 RUP® 的结构，专用于针对评测、推荐、获得、安装、配置、实施及发展 COTS 包解决方案的项目。该 RUP 结构是基于 CMU/SEI Evolutionary Process for Integrating COTS-Based Systems（EPIC）方法论的。 根据预先存在的 Commercial-Off-the-Shelf（COTS）包建立解决方案与从头开始开发是不同的。许多项目试图通过定义需求、明确地定制满足那些需求的体系结构，并尝试用 COTS 包适应该体系结构来集成预先存在的 COTS 包，这样做都失败了。独特的 COTS 包特性引入了必须适应的动态的并具体的约束。根据 COTS 包建立解决方案的项目需要专门的指导。 本文将介绍 IBM Rational Unified Process® for Commercial-Off-the-Shelf Package Delivery（或称 RUP® for COTS）1。RUP for COTS 是 IBM Rational Unified Process，或 RUP 的一种结构,它能够满足那些需要能够评估、推荐、获取、安装、配置、实施，并发展基于 COTS 包的解决方案的项目过程指导的 IBM 客户的需求。在本文中，我们首先要介绍一些 COTS 项目的最佳实践。然后，我们将定义 RUP for COTS 的基础。最后，我们将通过介绍每个阶段的目标、路标、角色、活动、工件和里程碑来遍历基于 COTS 的项目的所有 RUP 阶段。 RUP for COTS 是基于 Evolutionary Process for Integrating COTS-Based Systems （EPIC）2的，一个由 CMU-SEI（Carnegie Mellon University-Software Engineering Institute）开发的公认的方法论。特别的，RUP for COTS 基于 EPIC 概念和原则（影响范围、迭代会聚的决策、知识的堆聚，及风险承担者出钱投资的增加）。此外，一些阶段目标、路标描述、工件和里程碑的基础来自于 EPIC。 COTS 项目的最佳实践本部分的目的是识别 COTS 包的独特特征，并从这些特征中得出一些 COTS 项目的最佳实践。我们将从 COTS 包的定义开始考虑。 COTS 包3是一个软件产品，即：
根据该定义，我们可以辨别出 COTS 包的一列独特特征4
RUP for COTS 是基于这些最佳实践的。RUP for COTS 为 IBM 客户提供过程指导以评估、推荐、获取、安装、配置、实施 并发展 COTS 包解决方案。 COTS 包解决方案是下面一个或多个部分的综合体6：
RUP for COTS 插件的基础以下几部分介绍形成 RUP for COTS 基础的 EPIC 概念和原则。 影响的四个半球表现出在形成有效利用来自市场的预先存在的 COTS 包的可行的解决方案时所考虑到的竞争利益。影响的四个半球是：
在项目的生命周期中要同时定义并利用这四个半球，因为在一个半球中的决策会通知并很可能限制在其他半球中做出的决策。例如，任何已知的预先存在的 COTS 包也许都不能描述风险承担者的需求。 为了维护四个半球之间的平衡，EPIC 创建一个在系统地减少每个半球中的交换空间时支持四个半球的迭代定义的环境。该环境允许一个半球中的决策影响，并被其他半球中的决策影响。最初，如图 1 左部所示，交换空间可能很大。在风险承担者需求和最终用户业务过程之间、体系结构和设计之间、市场供应和其他来源之间，及计划和风险之间存在权衡的灵活性。随着 EPIC 用于向解决方案的精确理解推进，权衡空间收缩了。随着在不对其他半球产生重要影响的情况下在任何单个半球中制定的决策越来越少，这些半球在不断地重叠。  图 1：随着知识和风险承担者投资的增长，影响的四个半球不断地重叠。 由于为了优化可用 COTS 包的使用而考虑并调整影响的四个半球，迭代开发过程对保持需求和体系结构的不固定是必需的。每个迭代包含了从四个半球收集信息的活动。每个迭代都会通过分析及与受影响的风险承担者商议来改进新收集来的信息，用来形成组合实现解决方案并支持必需的最终用户业务过程的可执行系统所需要的协调的知识。迭代由四个 RUP 阶段和相关的里程碑进行管理，如图 2 所示。  图 2：RUP 阶段和迭代环境中的影响的四个半球 与影响的四个半球之间的交换空间的缩小同时，关于解决方案的知识必须按照受控的步伐增长。该知识在评估、推荐、获取、安装、配置、实施，并发展解决方案所必需的工件集合中反映出来。随着收集并提炼更多的信息，大多数工件在概要形式中开始并得到扩展。该知识包含了对下面内容愈加详细的理解：
特别重要的是保持当前关于 COTS 包的知识对解决方案和市场或提供 COTS 包的其他来源是关键的。这使组织跟踪可能会随着时间的增长而影响解决方案的趋势。这也使组织保持市场的反复无常与建立、实施，及支持运转的解决方案所需的稳定性相平衡。监控和评估开始于项目开始阶段并继续到解决方案退役时。 虽然决策在聚集且知识在积累，但是风险承担者必须增加对解决方案的发展的定义的委托。因为这些风险承担者可能是广泛的且可能完全不同的团体，所以对许多项目来说这是困难的，因为这是一个重大的委托且可能在组织中是空前的。然而，来自风险承担者的积极参与对解决方案的成功是必不可少的。创建一个包含直接受到最终用户业务过程中的任意变更影响的风险承担者（或授权代表）的环境提供了快速解决要素（如可用的 COTS 包、所期望的最终用户业务过程，和确定的风险承担者需求）间的已发现的错误搭配的可能。同样重要的是，对风险承担者友好的环境可以证明在带有可接受的风险的成本和进度约束中可以建立解决方案。 随着对可用的 COTS 包的了解的增加，最终用户需求成熟起来并变化了。最终用户日常的涉入是必要的，因为识别、评估并选择 COTS 包的活动将形成最终用户业务过程并定义要交付的功能。与此同时，体系结构风险承担者确保所考虑的 COTS 包能够有效地集成到更宽广的组织的现有系统中以满足所需的性能参数。业务分析人员必须确保可行的厂商支持并发展 COTS 包。厂商的涉入可以增强对 COTS 包的功能和厂商对组织需求的潜在洞察力的可见性。受影响的风险承担者之间的持续的商议和调和导致在使代表团满意方面对 COTS 包的更有效的使用。 风险承担者确认并增加他们对基于迭代和增量的可以得到持续论证的功能增长的解决方案的发展的定义的投资和委托。一个可执行系统 —— 不仅是计划和预测 —— 对减少由于误解或不能预测的技术和操作因素所带来的风险是必要的。 RUP for COTS 项目阶段是如何定义的？本部分遍历了基于 COTS 项目的四个 RUP 阶段（初始、精化、构建、产品化）。其中介绍了每个阶段的目标、路标、角色、活动、工件，和里程碑。 初始 阶段的目标是实现项目生命周期目标上的风险承担者见的合作。初始 阶段确定项目是否值得做，以及存在一个或多个可行的候选解决方案。下面的部分描述了 初始 目标、路标、角色、活动、工件和里程碑。 在执行 COTS 包评估、推荐、获取、安装、配置、实施，及发展的项目的上下文中，初始 阶段的主要目标包括：
大多数这些目标适应于任意 RUP 软件开发项目，除了相当具体到 COTS 包项目的目标 5 到 8。 初始 阶段的焦点首先是从影响的四个半球中收集信息并围绕该信息取得风险承担者之间的合作。 一旦从半球中收集到了信息，就可以组合并分析这些信息以定义能够满足最关键的用例和非功能需求、体系结构和设计约束，及带有合理风险的项目管理约束（时间、金钱、人、范围等）的候选解决方案。这可以通过执行项目需求和市场上可用的内容之间的差距分析来完成。目标是了解哪里匹配、哪里不匹配，及在错误匹配的情况下与有关的风险承担者商议权衡。根据该理解，形成候选解决方案，并为每个解决方案概括出体系结构的草图。 每个候选解决方案的可行性必须通过会聚体系结构的概念试验来论证。体系结构概念试验可能采取许多形式，如解决方案的概念模型的梗概（利用符号，如带有一些屏幕快照的 UML）、解决方案的模拟、可执行的原型，或这些不同要素的联合。体系结构概念试验帮助以业务观点证明候选解决方案的可行性。实际上，体系结构概念试验应该用于为对与每个解决方案相关的最终用户业务过程的变更形成原型。 处理业务变更很可能是 COTS 项目的最有挑战性的部分，7 因此在过程早期包含受解决方案影响的风险承担者，并确保他们真正理解了这些业务变更并赞成实现解决方案所选择的变更是重要的。 候选解决方案的定义及体系结构的概念试验的会聚允许识别满足关键用例和非功能需求、体系结构和设计约束，及带有合理风险的项目管理约束的要求的最有关的可行候选解决方案。根据业务目标，推荐是用于在后面的迭代中进一步调查这些候选解决方案。 注意到，在 初始 阶段，目标不是从每个半球中收集具体信息，也不是具体定义候选解决方案。取而代之，目标只集中在关键信息及实现当前迭代的目标所必要的候选解决方案的一些方面。图 3 阐明了 初始 阶段的典型迭代。  图 3：基于 COTS 的项目的 RUP 初始 阶段中的典型迭代 初始 阶段中至少有一次迭代。所需的进一步的迭代的数量依据候选解决方案的复杂性并依据最初的风险承担者期望和由合理的成本、进度和风险实施的功能。 本部分介绍一些对 RUP 来说很新的角色、活动，和工件实例，因为它们具体到基于 COTS 的项目，所以才进行介绍。这些要素在 初始 阶段扮演一个重要角色，即使整个项目生命周期中都涉及到它们。参阅附录以得到新要素的完整列表。 新的需求方（Acquirer）角色在 初始 阶段扮演着关键角色。需求方监督 COTS 包的评估、推荐，和获得。在 初始 中，需求方负责执行称为识别有关的 COTS 包和厂商（Identify Relevant COTS Packages and Vendors）的新活动。此活动的一个目标是获取由解决方案中考虑到进行使用的竞争的 COTS 包所表现出来的广大的市场特征。这些特征包括参与到市场中的厂商和需求方、所提供的 COTS 包、自动化的过程、所表现的技术、所实践的获得策略，和市场竞争力。焦点在于大范围的市场动力，而不是单个 COTS 包的分析。另一个目标是识别可能应用于解决方案的 COTS 包。导致此信息的任务一般称为“产品评估”。它承担了 COTS 包特性和所支持的业务过程的分析，且我们建议经由产品试验这样做得越多越好。在新的识别有关的 COTS 包和厂商的活动中收集来的信息由以下新工件获取：市场片段信息（Market Segment Information）、COTS 包档案（COTS Package Dossiers），和 厂商档案（Vendor Dossiers）（每个有关的 COTS 包一个档案且每个厂商一个档案，因此，举例来说，当一个厂商卖出多个 COTS 包时，我们会避免冗余）。 此外，过程提供灵活性来决定是否使用一些更正式的技术用于产品评估，如邀请厂商来回应对信息的请求（Request for Information，RFI）、对建议的请求（Request for Proposal，RFP），或者在评估车间中论证他们的产品。根据获得组织的需要和实践，过程允许采用各种级别的规定程序。 图 4 说明了一些在 初始 阶段中扮演重要角色的新角色、活动，和工件。  图 4：COTS 项目的 RUP 初始 阶段中的角色、活动，和工件 因为需求方的视野是宽广的，所以需求方很少参与详细的评估、推荐和获取活动，更喜欢把这些工作留给更专门的参与者。例如，需求方可能需要与系统分析人员合作来组织产品评估，并和实现人员合作来执行产品试验。 只有在达到阶段目标时，初始 阶段才会终止，如生命周期目标里程碑中描述的。如果项目没有达到此里程碑，那么可能就会失败或需要重新考虑。在涉及 COTS 包的项目中，初始 阶段的退出标准如下定义：
精化 阶段的目标是达到需求和体系结构的足够稳定，选择并获取 COTS 包，并减少风险以便可以用可预言的成本和进度识别单个，高保真的解决方案。下面的部分描述了 精化 目标、路标、角色、活动、工件，和里程碑。 在针对执行 COTS 包评估、推荐、获取、安装、实施，和发展的项目上下文中，精化 阶段的主要目标包括：
精化 阶段的焦点首先是在 初始 阶段定义的候选解决方案中选择一个最能满足用例和非功能需求、体系结构和设计约束，及带有合理风险的项目管理约束（时间、金钱、人、范围等）的需求的可行解决方案。这是通过继续从影响的四个半球中收集信息（包括对正待考虑的 COTS 包的详细评估）并通过使用收集来的信息以精练候选解决方案来完成的。这包括继续执行项目需求和市场上可用的内容之间的差距分析，在错配的情况下与风险承担者商议权衡，并精练每个候选解决方案的体系结构和设计。一个目标是获取有关将 COTS 包集成到需求方环境中的信息，COTS 包的必要配置，必要的数据移植，和对定制开发的需求。 精化 阶段专注于由最终用户和工程师对候选解决方案进行的深入的，传呈下去的试验。对于每个候选解决方案，在试验工具环境中建立起一个执行系统（精化 阶段称为“可执行的体系结构原型”）。试验工具应该尽可能接近或实际的复制运行环境（包括对任何重要的外部系统的接口）。建立执行系统的一个关键目标是更好地了解引入到 COTS 包集成、COTS 包配置、数据移植，和定制开发中的复杂性。另一个目标是为更好地了解每个候选解决方案中包含的 COTS 包如何影响最终用户的业务过程并确保风险承担者了解每个解决方案对业务的影响，而继续为对最终用户的业务过程的变更形成原型。 当充分了解了候选解决方案后，就选出一个将成为 构建 阶段基础的解决方案。利用试验工具对所选的解决方案进一步提炼，直到能够表明解决方案已经达到需求和体系结构上的足够稳定，并且已经处理了所有体系结构上的重要风险。然后团队就根据系统需求和公认的体系结构，建议获取形成所选解决方案及在 构建 阶段实现解决方案所需的 COTS 包。COTS 包的获取是最新的，包括商议价格和支付条款，及获得向厂商购买的许可。8 图 5 描述了 精化 阶段中的典型迭代。  图 5：基于 COTS 的项目的 RUP 精化 阶段中的典型迭代 迭代的实际次数依赖于所要功能中固有的复杂性和风险。精化 阶段中至少有两次迭代，如图 5 所描述。早期的迭代评估来自 初始 阶段的候选解决方案以选择最佳的单个解决方案，随后的迭代建立所选的解决方案，达到能使 构建 阶段开始的足够详细的级别。在随后的迭代中，探究所选的解决方案来减缓风险并为建造产品质量解决方案开发具体的计划。要减少技术、程序设计，和运作风险并实现所选解决方案需求和体系结构的稳定基础需要多种迭代。 本部分介绍一些对 RUP 来说很新的角色、活动，和工件实例，因为它们具体到基于 COTS 的项目，所以才进行介绍。这些要素在 精化 阶段扮演一个重要角色（即使整个项目生命周期中都涉及到它们）。参阅附录以得到新要素的完整列表。 出自 RUP for Systems Engineering 版本的新角色是系统架构师（System Architect）。系统架构师俯视整个系统及可能影响到开发的所有因素。系统架构师建立并提炼系统逻辑和物理结构并关注就主要的系统要素和接口而言的结构最优化，以及在竞争因素和约束中进行权衡。 系统架构师负责执行称为定义解决方案（Define Solution）的新活动。目标是联合从影响的四个半球收集来的信息以形成候选的解决方案。这通过执行项目需求和市场上有用的内容之间的差距分析，在错配的情况下与风险承担者商议权衡，并定义候选解决方案的体系结构和设计来完成。 每个候选解决方案都由称为解决方案档案（Solution Dossier）的新工件定义而成。解决方案档案聚集所有形成解决方案的工件，成为一个逻辑单元。例如，解决方案档案中也许包含每解决方案中包含的 COTS 包一个 COTS 包档案，每 COTS 包厂商一个厂商档案，以及定义了解决方案的体系结构和设计的工件（如设计模型、软件体系结构文档、包配置规范，和数据移植规范）。这些只是形成解决方案档案的工件实例。 因为系统架构师的视野是宽广的且横跨整个系统，所以系统架构师很少涉及到系统具体工程的深度，他们更喜欢把那些工作留给各种工程专业中的其他参与者。因此，系统架构师很少作为形成解决方案档案的单个工件的所有者。 例如，新的包配置规范（Package Configuration Specification）工件属于设计人员（Designer）并在新的指定包配置（Specify Package Configuration）活动的环境中生成。目标是指定 COTS 包配置需求。这涉及到定义配置工作的范围（同时记住未来升级 COTS 包的功能），以及识别 COTS 包参数和定义具体到最终用户的包版本所需的值。这些参数与要素，如功能、安全和控制，及报告，有关。 类似的，新的数据移植规范（Data Migration Specification）工件属于数据设计人员（Data Designer）并在新的指定数据移植（Specify Data Migration）活动的环境中生成。目标是定义数据移植工作的范围，指定数据概要文件，并在数据源和目标数据库间映射，以及识别手工和自动的数据移植。 图 6 描述了 精化 阶段中扮演重要角色的一些新角色、活动，和工件。  图 6：基于 COTS 的项目的 精化 阶段中的角色、活动和工件 只有在达到阶段目标时，精化 阶段才会终止，如生命周期体系结构里程碑中描述的。如果项目没有达到此里程碑，那么可能就会失败或需要重新考虑。在涉及 COTS 包的项目中，精化 阶段的退出标准如下定义：
构建 阶段的目标是实现为用户团体准备的产品质量版本。所选的解决方案是为实施准备的。以下的部分描述 构建 目标、路标、角色、活动、工件和里程碑。 在针对执行 COTS 包评估、推荐、获取、安装、配置、实施，及发展的项目的上下文中，构建 阶段的主要目标包括：
构建 阶段的焦点是准备适用于实施的所选解决方案的产品质量版本。在此阶段的一个工作内容是继续从影响的四个半球中收集信息以搜集完成解决方案 构建 所必需的任何信息。一旦从半球中收集来信息，解决方案的设计中的所有的遗留细节就完成了。这包括与 COTS 包、COTS 包配置、数据移植、任何定义开发，及修改的遗留构件相关的详细设计要素。最终，产品精度应用于完成解决方案的实现和测试。 构建 阶段为实施准备解决方案。它包括必需的支持材料（如培训材料、安装指导，和用户手册）的支持策略（例如，依据指导教师和基于 Web 的培训、及时监控、帮助平台和技术支持的联合）和设计的准备。需要开发执行可接受测试所必需的和解决方案最初展示所必需的所有支持材料。构建 阶段还包括准备对与解决方案相关的最终用户的业务过程的变更。例如，这涉及按照需要重构组织，及为支持解决方案开发新的策略和步骤。对执行可接受测试所必需的和解决方案首次展示所必需的最终用户的业务过程的所有变更需要得以实现。 图 7 展示了 构建 阶段中的典型迭代。  图 7：基于 COTS 的项目的 RUP 构建 阶段中的典型迭代 构建 阶段中至少有一次迭代。所需的迭代的实际次数依赖于完成解决方案的设计、实现和测试，以及实现用于实施的产品质量版本所必需的工作总量。例如，与 COTS 包配置相关的大量工作很可能增加迭代次数。 虽然在 精化 阶段中每项工作都做到了，以稳定解决方案并处理风险，但是一些不曾预料的变更出现在 构建 阶段过程中的需求中、COTS 包本身中，及体系结构和设计中。特别的，由于市场的不稳定特性，当厂商添加、变更或去掉功能时，所选 COTS 包的新版本可能需要更详细的研究。对市场的不断监控和对新的及变更了的 COTS 包的评估用于预料变更并确定适当的 COTS 包升级方法。为了支持 精化 阶段而创建的试验工具继续用于评估新的和变更了的 COTS 包。由任意变更所表现出来的 构建 阶段的成本和进度风险必须与没有升级并交付的废弃 COTS 包的风险平衡。对于次要的变更，在识别、验证并实现调整时，可以临时延迟 构建 阶段。对于主要变更，在生命周期体系结构里程碑（或甚至在生命周期目标里程碑）中做出的决策也许不得不被重新审阅或者变更遵从下一代解决方案。 本部分介绍一些对 RUP 来说很新的，且具体到基于 COTS 项目的角色、活动，和工件实例。这些要素在 构建 阶段扮演一个重要角色，即使整个项目生命周期中都涉及到它们。参阅附录以得到新要素的完整列表。 实现人员（现有的 RUP 角色）在 构建 阶段扮演着重要角色，它负责（在其他事情中）配置 COTS 包及移植数据。称为执行包配置（Perform Package Configuration）的新的实现人员活动，描述了根据包配置规范（Package Configuration Specification）配置由厂商提供的配置文件的过程。另一个实现人员的新活动称为执行数据移植（Perform Data Migration），描述了根据数据移植规范（Data Migration Specification）将数据从遗留数据库移植到目标数据库中的过程。此外，该活动涉及了新的数据移植评估（Data Migration Evaluation）工件中结果的数据移植过程和文档的评估。 图 8 展示了 构建 阶段中扮演重要角色的一些新活动和工件。  图 8：基于 COTS 的项目的 RUP 构建 阶段中的角色、活动和工件 只有在达到阶段目标时，构建 阶段才会终止，如初始运作功能里程碑中描述的。如果项目没有达到此里程碑，那么可能就会失败或需要重新考虑。在涉及 COTS 包的项目中，构建 阶段的退出标准如下定义：
产品化 阶段的目标是向用户团体实施所选则的解决方案并提供必需的支持。以下部分描述了 产品化 目标、路标、活动、工件和里程碑。 在针对执行 COTS 包评估、推荐、获取、安装、配置、实施，及发展的项目的上下文中，产品化 阶段的主要目标包括：
产品化 阶段着重于对用户团体的解决方案的集成和部署。这要求最终用户 1) 精通解决方案及解决方案所支持的最终用户业务过程，2) 受到激发而使用解决方案，且 3) 在解决方案的使用中是自支持的。 产品化 阶段的一个工作是为受到将要实施的解决方案所影响的任何变更监控影响的四个半球。如果在阶段中存在 COTS 包变更，那么变更也许是必要的，或者对满足具体的安装站点的独特需要是必要的，或者对适应由运行经验所导致的变更请求（如缺陷和次要增加请求）是必要的。在 产品化 阶段，用户反馈应该针对解决方案的微调，因而主要着重于配置、安装和可用性问题。所有的主要结构问题都应该在生命周期更早的时期得到处理。一旦从半球中收集来信息，这些信息就用于提炼解决方案定义并执行实现解决方案系统。 产品化 阶段中的另一个工作是跨用户基础实施解决发案。它包括提炼并实现支持策略并开发必需的支持材料（如培训和用户手册）。举例来说，支持策略可以依据教师指导和基于 Web 的培训、及时监控、帮助平台和技术支持的联合，以及鼓励采取解决方案的机制。实际上，在实施过程中，经历实现新功能的阻力是很平常的。有了全球的受尊重的专家对解决方案的精心拥护，和对采用解决方案的用户进行奖励的激励，有时候也能克服该阻力。实施还包括实现对最终用户业务过程的变更。例如，一些人有新的责任并依照新的业务规程。 产品化 阶段围绕着对解决方案的持续支持。一旦将解决方案对用户实施，重点就转移到安排并实现解决方案的维护版本上了。这些维护版本是响应各种需求所需要的：
计划包括确定要修正的缺陷和每个版本中要进行的增强。每个维护版本需要一到多次迭代。 在解决方案的支持中要小心地平衡 COTS 包的废弃和解决方案稳定性。产品化 阶段管理引入更新的 COTS 包，而还要继续满足运行环境的要求。持续的市场监控用于预料变更。为 COTS 包评估维护试验工具以评估对新的或变更了的 COTS 包的潜在影响是必要的。在一些情况下，新的 COTS 包版本可能要求再次实现最初用于集成 COTS 包的 COTS 包配置和集成。 当解决方案退役或被新一代解决方案代替时，产品化 阶段就结束了。新一代解决方案需要新的 RUP 发展循环（重复所有的 RUP 阶段）。新的 RUP 发展循环与维护版本不同，因为变更的范围导致改变了解决方案的体系结构，改变了取得一致的最终用户业务过程，或超过此阶段门槛的成本。 图 9 展示了 产品化 阶段中的典型迭代。  图 9：基于 COTS 的项目的 RUP 产品化 阶段中的典型迭代 实际的迭代次数依赖于将解决方案转移到最终用户并提供支持的工作中所涉及的复杂度。在 产品化 阶段至少有两次迭代：早期迭代显示跨用户基础的解决方案，随后的迭代着重于解决方案的长期支持。根据，例如，最终用户的数量、他们接受变更的能力和愿望、他们在应用领域和解决方案中的经历，以及新的或修改的业务过程的数量，多重迭代对跨用户基础展示解决方案是必要的。多重迭代对实现解决方案的长期支持策略也是必要的。例如，必需计划许多维护版本，根据要修正的缺陷的数量和要做出的增强的复杂度，每个版本由一次或多次迭代构成。 本部分介绍一些对 RUP 来说很新的，且具体到基于 COTS 项目的角色、活动，和工件实例。这些要素在 产品化 阶段扮演一个重要角色（即使整个项目生命周期中都涉及到它们）。参阅附录以得到新要素的完整列表。 在 产品化 阶段中扮演关键角色的新工件（在 初始 阶段创建的且在后继的阶段得到更新）是业务过程变更管理计划（Business Process Change Management Plan），由项目经理（Project Manager）所有并在称为开发业务过程变更管理计划（Develop Business Process Change Management Plan）的新活动环境中创建而成，如图 10 所示。  图 10：基于 COTS 的项目的 RUP 产品化 阶段中的角色、活动和工件 目标是创建有效且编制好的计划来提高成功实现最终用户业务过程变更的可能性，并提供结构化的方法来管理对完成策略业务目标很关键的人的要素。这些新活动和工件的一个关键目标是确保业务过程变更管理得到认可 —— 在所有组织级别上 —— 像一个触及到组织中正在运作的许多社会技术活动，而不是一个孤立的活动的过程。然而，为了完全从事非常复杂的业务再工程工作（在此种情况下，COTS 包项目也许是次要考虑），业务过程变更管理计划可能需要归入此 RUP 结构中不包括的一组专用工件和相关业务再工程过程中。此处我们的目的是只以对成功的 COTS 包解决方案部署必需的程度来处理业务过程变更。 只有在达到阶段目标时，产品化 阶段才会终止，如产品发布里程碑中描述的。在涉及 COTS 包的项目中，产品化 阶段的退出标准如下定义：
结束语RUP for COTS 实现了各种基于 COTS 的项目的最佳实践，这些最佳实践考虑了 COTS 包的独特特征。例如，它提议一个 COTS 包（及市场）推动解决方案的发展定义的迭代方法。该方法帮助 IT 团队将具有恢复力的系统体系结构作为中央控制的资产进行开发和维护，这平衡了 COTS 包的退化与解决方案的稳定性，并合并了改变最终用户业务过程的活动。 参阅 RUP for COTS Web 站点以得到过程的完整介绍。对于每个 RUP 阶段，该 Web 站点提供了对目标、里程碑、路标、角色、活动，和工件的具体描述以及示例迭代计划。 要下载描述 RUP for COTS 的 PowerPoint 介绍，单击此处。在显示出的“Download”框中，您将看到文件名“rup4cots_intro.zip”，要开始下载，点击右边的词“FTP”。 致谢作者要对所有评论家的贡献表示感谢，并感谢他们对本文早期草稿具有深刻见解的评论。特别地，作者还想诚心地感谢来自 CMU/SEI 的 Lisa Brownword。她对创建 EPIC 的 RUP 版本的积极性、她对项目的支持，以及花在分享她在 EPIC 上的经验的时间，都对项目的成功做出了非常大的贡献。 更多读物：
附录：RUP for COTS 的新要素对于每个 RUP 规程，本附录概述了具体到基于 COTS 项目或在基于 COTS 项目中很重要的 RUP for COTS 的要素。查阅 RUP for COTS Web 站点以得到每个要素更详细的描述。
注释1 IBM Corporation。RUP Plug-In for COTS Package Delivery，V1.0。在 developerWorks 可获得：http://www.ibm.com/developerworks/rational/library/05/510_cots/ 2 Cecilia Albert 和 Lisa Brownsword“Evolutionary Process for Integrating COTS-Based Systems (EPIC). Building, Fielding, and Supporting Commercial-Off-the-Shelf (COTS)-Based Solutions，” Techical Report，CMU/SEI-2002-TR-005，ESC-TR-2002-005，2002 年 11 月 3 同上。 4 P. Oberndorf、L. Brownsword，和 C. Sledge。“An Activity Framework for COTS-Based Systems，”(CMU/SEI-2000-TR-010 ADA383836)。Pittsburgh，PA: Software Engineering Institute，Carnegie Mellon University，2000 年。 5参见 P. Oberndorf、L. Brownsword，和 C. Sledge。“An Activity Framework for COTS-Based Systems，”(CMU/SEI-2000-TR-010 ADA383836)。Pittsburgh，PA: Software Engineering Institute，Carnegie Mellon University，2000 年。 6 Albert 和 Brownsword，前面引用的书。 7 Christopher Koch。The ABCs of ERP。Enterprise Resource Planning Research Center，“The Pros and Cons of Automating the Company's Functional Areas。”CIO.com，2002 年 3 月。 8 要了解更多关于 COTS 包的先进知识，参见 Max Wideman 的五部分系列文章“Progressive
Acquisition and the RUP”2002 年 12 月到 2003 年 4 月间于Rational Edge上发表： 参考资料
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
