工件:
|
![]() |
工作版本是系统或一部分系统的一个可操作版本,演示了最终产品中提供的能力子集。工作版本由一个或更多实施元素(通常可执行)组成,通常由编译和链接源代码的进程从其它元素构造每个元素。 | |
角色: | 集成员 | |
---|---|---|
可选性/存在性: | 用于每个迭代。 | |
模板和报告: |
|
|
示例: | ||
UML 表示: | 实施模型中的包(其顶级包或实施子系统),定型为 <<工作版本>>。 | |
更多信息: | ||
活动输入: | 活动输出: |
从实施中的其它元素构造的工作版本的目的是交付系统运行时功能和能力的可测试子集。Rational Unified Process(RUP)建议在迭代期间构造一系列工作版本,当添加或改进实施子系统的元素时,对每个工作版本添加能力。可以在系统的所有级别(包括单个或多个子系统)构造工作版本,但在 RUP 中,特别关注在工件:集成构建计划中定义的工作版本,因为这些工作版本是完成迭代的铺路石。如果系统大小或复杂性证明有必要,可以将集成构建计划优化为多个计划,涵盖各个子系统。
注意实施者可以因为几个原因(例如单元测试)而构造非正式的工作版本 - 相应地使用实施者私有开发工作区和子系统和系统集成工作区中的元素。但是,正如此处使用该术语,由集成者从已确定版本的元素中构造工作版本,这些元素由实施者交付到子系统或系统集成工作区(如工件:集成构建计划中所定义)。
特征名称 |
简述 |
UML 表示 |
---|---|---|
描述 | 工作版本的简要文本描述 | “简短文本”类型的标注值 |
实施子系统 | 在工作版本中表示的子系统 | 通过元关联“表示”拥有,或通过元聚集“拥有”递归地拥有 |
元素 | 工作版本中的实施元素,由子系统拥有 | 通过元聚集“拥有”递归地拥有 |
集成构建计划引用 | 对相应集成构建计划中详细工作版本描述的引用 | 标注值 |
按工件:集成构建计划中所定义,对每个迭代构造工作版本。RUP 不要求任何特定的计时或频率:按项目特定需求选择合适的值。当然可以使用适当程度的自动化来采取一个每日工作版本策略:从实施者获取稳定的元素流,集成这些元素,并在晚间测试生成的工作版本。这不会适合所有项目,特别是那些很大且需要漫长回归测试的项目。
集成者负责生成工作版本。如果是围绕子系统(有关联的团队)来计划开发,然后将这些子系统集成到系统中,则可以有几名人员扮演集成者的角色,例如每个子系统团队中有一名人员执行子系统级别的集成,并且有一名人员执行系统级别的集成。
工作版本显然是必需的,但是项目产生的工作版本的类型将随着生命周期而有所变化。在先启阶段中,主要问题可能在于产生一个原型,作为更好地理解问题或与客户交流的一种方法;在精化阶段中,要产生一个稳定的体系结构,而在构建中,要添加功能。在移交阶段中,侧重点将转向确保软件达到可交付的质量。
Rational Unified Process
|