指南:实施中的重要决策
本指南描述了在定制流程的“实施”方面时需考虑的一些重要事项。
关系
主要描述

决定如何使用工作产品

决定要使用的工作产品以及使用这些工作产品的方式。除了确定要使用的工作产品之外,定制每个要使用的工作产品来适应项目需求也很重要。 

下表指定了建议使用哪些“实施”工作产品,以及其中哪些被认为是可选的(即,只能在某些情况下使用)。关于其他的定制注意事项,请参阅工作产品描述页面的定制部分。

工作产品 用途

定制(可选,建议使用)

实施模型

实施子系统实施元素

实施模型是指在运行时环境中构建和管理系统所需要的源代码、可执行程序和所有其他工作产品。

实施由实施元素组成,包括代码(源、二进制文件和可执行程序)和包含信息的文件(例如启动文件或自述文件)。

实施子系统是实施元素和其他实施子系统的集合,用来将实施模型分成几个较小的部分来进行构造。

所有软件项目都有一个实施模型,实施模型所具有的实施元素至少包括一些源代码和可执行程序。

有些项目还包括子系统、库和可视化模型。

如果要组织大量的实施元素,那么子系统就有用了。

集成构建计划 定义组件的实施顺序、集成系统时要创建的工作版本以及它们的评估方式。

可选。

如果需要计划集成,则建议使用。只有在集成不重要时才省略它。



决定单元测试覆盖

决定执行单元测试的程度以及代码覆盖的级别,它的规模可从非正式的一直到 100% 的代码覆盖。 此规模在 测试计划中有所描述。

单元测试覆盖级别常常受集成和系统测试人员(代码移交给这些测试人员)需要的驱动。系统测试人员的工作取决于代码的质量。 如果代码的缺陷过多,集成和系统测试人员就会过于频繁地将代码发回给实施者。 这是开发流程欠佳的信号,其解决方案可能就是要求实施者进行更彻底的单元测试。

当然,您不能期望经过单元测试的代码完全没有缺陷。不过,您需要在单元测试和质量之间找到一个“稳健的”平衡。

单元测试覆盖的级别在不同阶段之间也可能不同。即使是在构造和移交阶段需要 100% 代码覆盖的安全关键项目,通常在精化阶段也不需要这样,因为在该阶段有许多类只是部分实施。

决定如何复审代码

决定代码的复审程度。 

代码复审的优点有:

  • 强迫和鼓励在项目中使用共同的编码风格。代码复审是一种使项目成员遵循编程指南的有效方式。为确保这一点,复审所有作者和实施者的结果比复审所有源代码文件更显重要。
  • 查找自动化测试未能发现的错误。代码复审可发现在测试中未遇到的错误。
  • 在个人之间共享知识,以及将知识从更有经验的人传递到经验较少的人。

代码复审的缺点有:

  • 它会耗费时间和资源。
  • 如果执行不当,则可能缺乏效率。存在这样一种危险:即认为之所以进行代码复审,“是因为我们必须这样做”,而不是将其作为自动测试的有效补充。

关于代码复审的更多信息,另请参阅任务:复审代码

代码复审对项目有着重要的意义。所有开始度量代码复审相关错误和维护问题级别的项目,均称它们因为复审而提高了绩效。 然而,在许多组织中,代码复审却由于以下几个原因而很难“展开”:

  • 未收集足够数据来验证代码复审是否实际起作用。
  • 收集的数据过多。
  • 实施者对他们的代码的防护意识过强。
  • 复审陷入形式上的困境。
  • 管理复审事宜耗费过多的工作。

请记住以下几点,以尽可能充分利用代码复审:

  • 只收集适量的数据。
  • 度量复审的成绩,并显示结果。
  • 以“简洁”的方式使用复审。

关于复审级别的更多信息,请参阅指南:复审级别。