目的:
|
定义要在特定于项目的流程中覆盖哪些流程领域。
|
分析项目资源以及他们在类似软件开发项目中的经验的结果有助于确定定制工作的范围。特定于项目的流程不必包含 RUP 中的所有规程,也不必覆盖 RUP 中定义的所有角色。请记住,RUP
是适合范围很广的项目类型的流程框架,因此一个特定的项目要遵循它,就有太多的内容需要遵循。在项目的流程中选择覆盖的领域极大地依赖于项目成员现有的技能组合以及当前项目的性质。以下是确定定制工作范围时一般需要考虑的一些事项。
-
项目成员已经有统一工作方式的领域,在这些领域没有必要引进新的流程和工具。例如,如果他们知道如何测试,那么最好就不要引进 RUP 的测试规程,以降低新因素的数量。您可以重点引进 RUP
的一些部分,以纠正其现有流程中存在的问题。请参阅概念:在项目中实施流程,“改进流程和工具”一节,获取详细信息。
-
项目必须引进新的流程和工具的领域(规程),因为其中没有现有的工作方式。在有些情况下没有可以依赖的现有的流程和工具,这样就有必要引进大多数 RUP 及其支持工具。请参阅概念:在项目中实施流程,“彻底更改”一节,获取详细信息。
-
现有流程中存在的问题。侧重于改进组织有问题的领域。
-
要使用哪些工具?如果项目已经决定使用某些工具,开发流程一般就应该覆盖 RUP 中相应的领域。
-
项目对于变更的容量。在考虑组织的问题时,往往倾向于尝试一次解决所有问题,特别因为这些问题中很多是一起出现的。这通常是个致命的陷阱。
组织就像个人一样,可以包容变更,但只是在有限的范围内。如果对于变更的容量很低,您就必须跟着降低,可能在第一个项目中只能引进一个或两个 RUP 规程。
-
项目成员缺乏知识或者是他们的弱项的领域。让开发流程覆盖这些领域。 要确保能很容易在 RUP 中找到恰当的信息。
关于定义定制工作范围的更多信息,请参阅指南:RUP
定制。
关于影响针对项目定制流程因素的描述,请参阅指南:流程判别式。
确定要改进的领域不必在相同的项目中第一次引进。 减少未知因素的数量,并查看开发组织过去深受其苦的领域。 我们建议您用迭代的方式实施 RUP,就像概念:在项目中实施流程中所描述的那样。 示例:小型项目采纳 RUP 中也有小项目的指导信息。
虽然可能会发现数个规程中有改进的需要,请考虑在几个项目期间以迭代的方式进行改进,而不要尝试“一次改变一切”的方法。
这种折衷的一个示例是:如果以前的项目受不清晰和/或不充分的需求之苦,或者如果用户主要抱怨交付的产品不能满足他们的需要,那么就可以引入“用例需求”而推迟引入新的 CM 流程。
作出的折衷和生成的范围应记录为此流程的一部分,以将范围决策传达给外部项目干系人。