活动:
|
目的
|
|
角色:流程工程师 | |
频率:该工作大部分在项目开始时进行。必要时可在任何迭代中重复 | |
步骤 | |
输入工件: | 生成的工件: |
工具向导: | |
更多信息: |
工作流程明细: |
目的: | 获得对当前问题和项目可用资源的了解。 |
开发流程与当前项目以及项目的大小和形式需求相关对于项目的成功很关键。流程太大往往会妨碍创造性和效率。流程太小会导致混乱的环境,通常会让项目的个人成员作出局部的决策,可能造成低效、不一致和不可预测的结果。
流程仪式在不同的开发组织中有很大不同。有些组织的流程非常成熟,有专门的流程小组管理整个组织内的开发流程的定义和改善。某些其它组织则只关心特定于项目的定制。这些项目一般从 RUP 产品随带的一个预定义的配置开始,并从该配置将每个项目的流程实例化。定制项目流程的方法大大依赖于几个因素,例如:
请参阅指南:流程判别式获得详细信息。
目的: | 定义要在特定于项目的流程中覆盖哪些流程领域。 |
分析项目资源以及他们在类似软件开发项目中的经验的结果有助于确定定制工作的范围。特定于项目的流程不必包含 RUP 中的所有规程,也不必覆盖 RUP 中定义的所有角色。请记住,RUP 是适合范围很广的项目类型的流程框架,因此一个特定的项目要遵循它,就有太多的内容需要遵循。选择在项目的流程中覆盖哪些领域大大依赖于项目成员现有的技能组合以及当前项目的性质。以下是确定定制工作范围时一般需要考虑的一些事项。
确定要改进的领域不必在相同的项目中第一次引进。减少未知因素的数量,并查看开发组织过去深受其苦的领域。我们建议您用迭代的方式实现 RUP,就像概念:在项目中实现流程中所描述的那样。虽然可能会发现数个规程中有改进的需要,请考虑在几个项目期间以迭代的方式进行改进,而不要尝试“一次改变一切”的方法。
这种折衷的一个示例是:如果以前的项目受不清晰和/或不充分的需求之苦,或者如果最终用户主要抱怨交付的产品不能满足他们的需要,那么就可以引入“用例需求”而推迟引入新的 CM 流程。
作出的折衷应该记录下来,以将确定范围的决策告诉外部涉众。在 RUP Builder 产品中创建配置时,这些决策可以记录为配置的说明并将出现在发布的 Web 站点上面。
目的: | 将更多的流程专业知识添加到特定于项目的流程中,添加到认为 RUP 流程框架中的覆盖率对于项目不足的领域。 |
RUP 流程框架的一个优势是它可以应用于范围广泛的项目和环境。但同时这也可以当作缺点,因为流程说明往往会变得有点泛泛而谈。RUP 插件技术设计来允许工具或技术供应商和单个公司通过插件创建更具体的流程说明,从而解决其中的一些问题。您会在 developerWorks®:Rational® 的 RUP 部分找到一系列最新的、可供下载的插件。
Rational Process Workbench™(RPW)产品使您能够使用 RUP 插件技术创建 RUP 扩展。按照对该技术的建议,RUP 框架可以用两种方式进行扩展。您可以创建结构插件来扩展 RUP 流程模型,或者可以创建通过瘦插件将开发组织的相关可重用资产提供给项目的扩展。
创建 RUP 插件(结构插件)本身应该当作一个项目,因为它有独立的规划、预算和控制机制。您应该根据投资收益率分析为它定义业务案例。插件的实际开发将受益于遵照 RUP 中的生命周期和规程进行操作。我们建议您在实际项目中实践插件背后的主要思想,然后再开始开发插件的项目。
请参阅指南:RUP 定制,“扩展 RUP”一节,获得更多信息。
目的: | 合理地确定流程的大小,以支持项目的确切需要。 |
RUP 框架由一套流程组件和插件组成,每个组件都包含一套相关的流程元素。创建 RUP 配置意味着从一套流程组件中选择。为给定的项目选择一套恰当的组件不是一个小任务。要使流程有效,流程必须存在相关性,并且在不同方面都应该确定恰当的大小,如项目大小(资源和日历时间)、形式、技术平台、领域等等。
有关配置 RUP 的更详细的信息,请参阅
目的: | 定义配置的流程如何在项目中实施。 |
为项目配置的流程说明往往达不到可以立即实施的详细程度。例如,流程根据选择的相关流程组件定义一套要使用的工件(如上一节创建 RUP 配置中所描述),但它不为这个特定的项目指定工件的计时和形式需求。规定的指南和部分实例化的工件模板也被认为是实例化的、特定于项目的流程的一部分。执行这一步骤必需的工作大大依赖于配置的流程的精确度。任何此类偏离底层的流程的情况都应该进行调整,并记录为特定于项目的流程的一部分。
次主题:
在项目中将配置的流程实例化的工作涉及确定一个生命周期模型供项目遵循,包括向阶段和迭代的细分。对于这部分定制工作,流程工程师应该与项目经理紧密协作,因为选择的生命周期模型将充当项目规划流程的基础。根据项目的性质,可能需要调整 RUP 生命周期,以更好地与具体的需要相匹配。例如,原始开发通常要求比维护项目更多的努力。因此,生命周期说明应该根据项目的性质进行调整。关于各种类型的生命周期模型的讨论,请参阅概念:迭代。
配置的流程包含关于期望由项目生成的工件的说明。由于配置可能被定义来适合特定类型的项目,因此这个选择应当作为实例化过程的一部分提出。如果您不能解释为什么需要某个工件,就不要规划生成这个工件。工件还应该根据以下等信息加以规范化:
这些信息可以保存在能从流程 Web 站点访问的电子表格或文档中,或者可以作为流程说明整体的一部分。
作为任何特定于项目的流程的一部分,都应该有一套定制的可用资源,为生成项目工件提供具体的帮助和参考材料。举例来说,这样的资源有:
在项目开始时,项目经理一般与流程工程师合作选择一套适当的资源,并使它们作为特定于项目的流程的一部分供项目成员使用。对其它资源的需要在每个迭代开始时重新提出。
目的: | 使特定于项目的流程可以为项目成员所用。 |
完成初始的定制工作后,结果得到的流程需要发布为可使用的格式。RUP Builder 产品提供发布配置的流程的方法,结果生成的是一个仅包含选择的流程组件和资源的 RUP Web 站点。 流程工程师需要与项目经理合作,公布特定于项目的流程,并决定如何培训项目成员。根据项目的大小和项目成员对类似开发流程的熟悉程度,这个过程可以是只有两小时的非正式演示,也可以是更加正式的培训。流程在项目生命周期中的每个重要更新都应该对项目重新启动,重点突出变更。
特定于项目的流程的 Web 站点可以发布到组织网络上的 Web 服务器,或者安装到每个个人团队成员的计算机上。如果项目成员大多数时间都连接到了网络,则建议将 RUP Web 站点部署到 Web 服务器,以避免在项目生命周期期间由于流程更新而产生的任何开销。
虽然定制工作大部分是在项目早期完成的,但它应该持续保持最新状态,因为项目团队在流程中不断发现障碍和其它问题。项目期间作出的评估是改进流程的重要输入。小的调整一般由项目进行处理,而对特定于项目的流程的更新则是作为为即将到来的迭代准备开发环境的一部分进行的。 更为复杂的问题被作为对流程的变更请求提出。这通常由项目界线外的流程组进行处理,该流程组为整个组织负责软件开发流程。
迭代式开发的主要好处之一是它使项目团队能够逐步改善开发软件的方式。我们建议每个项目都包含流程工程小周期,由下列步骤组成:
Rational Process Workbench 产品内的 Process Engineering Process 包含关于组织设置中的“流程改进”的信息。
Rational Unified Process
|