指南:
|
工作流程的部分 |
注释 |
---|---|
集成和构建管理 | 角色集成人员和活动:计划系统集成连同工件:集成构建计划一起通常在项目早期引进。其它集成相关活动(例如活动:计划子系统集成、活动:集成子系统和活动:集成系统)仅在集成开始之后适时地引进。 |
实施组件 | 角色实施者和代码复审人员以及他们的活动和工件是在每个迭代中实施开始时引进的。 |
将决策 下,作为项目特定流程的一部分。
决定要使用哪些工件和每个工件的使用方法。下表描述您必须拥有的工件以及在某些情况下使用的工件。关于如何定制每个工件的更多详细信息,以及该特定工件的优缺点的讨论,请阅读每个工件的标题为“定制”的部分。
对于每个工件,决定应如何使用工件:必须拥有、应该拥有、可以拥有或不能拥有。
工件 | 用途 |
定制(可选,建议使用) |
---|---|---|
|
实施模型是指在运行时环境中构建和管理系统所需要的源代码、可执行文件和所有其它工件。 实施由实施元素组成,包括代码(源、二进制文件和可执行文件)和含有信息的文件(例如启动文件或自述文件)。 实施子系统是实施元素和其它实施子系统的集合,用来将实施模型分成几个较小的部分来进行构造。 |
所有软件项目都有一个实施模型,实施模型所具有的实施元素至少包括一些源代码和可执行文件。 有些项目还包括子系统、库和可视化模型。 如果要组织大量的实施元素,那么子系统就有用了。 |
集成构建计划 | 定义组件的实施顺序、集成系统时要创建的工作版本以及它们的评估方式。 |
可选。 如果需要计划集成,则建议使用。只有在集成不重要时才省略它。 |
根据项目的需要定制每个工件。关于定制注意事项,请参阅工件的描述页
决定执行单元测试的程度以及代码覆盖的级别,它的规模可从非正式的一直到 100% 的代码覆盖。
单元测试覆盖级别常常受集成和系统测试人员(代码移交给这些测试人员)需要的驱动。系统测试人员的工作取决于代码的质量。 如果代码的缺陷过多,集成和系统测试人员就会过于频繁地将代码发回给实施者。 这是开发流程欠佳的信号,其解决方案可能就是要求实施者进行更彻底的单元测试。
当然,您不能期望经过单元测试的代码完全没有缺陷。不过,您需要在单元测试和质量之间找出一个“健康的”平衡。
单元测试覆盖的级别在不同阶段之间也可能不同。即使是在构造和移交阶段需要 100% 代码覆盖的安全关键项目,通常在精化阶段也不需要这样,因为在该阶段有许多类只是部分实施。
决定代码的复审程度。
代码复审的优点有:
代码复审的缺点有:
关于代码复审的更多信息,还请参阅活动:复审代码。
代码复审对项目有着重要的意义。所有开始度量代码复审相关错误和维护问题级别的项目,均称它们因为复审而提高了绩效。 但对于许多组织,他们都难以“着手”进行代码复审,原因如下:
请记住以下几点,以尽可能充分利用代码复审:
Rational Unified Process
|