决定要使用的工作产品以及使用这些工作产品的方式。除了确定要使用的工作产品之外,定制每个要使用的工作产品来适应项目需求也很重要。
下表指定了建议使用哪些“实施”工作产品,以及其中哪些被认为是可选的(即,只能在某些情况下使用)。关于其他的定制注意事项,请参阅工作产品描述页面的定制部分。
工作产品
|
用途
|
定制(可选,建议使用)
|
实施模型
(实施子系统,实施元素)
|
实施模型是指在运行时环境中构建和管理系统所需要的源代码、可执行程序和所有其他工作产品。
实施由实施元素组成,包括代码(源、二进制文件和可执行程序)和包含信息的文件(例如启动文件或自述文件)。
实施子系统是实施元素和其他实施子系统的集合,用来将实施模型分成几个较小的部分来进行构造。
|
所有软件项目都有一个实施模型,实施模型所具有的实施元素至少包括一些源代码和可执行程序。
有些项目还包括子系统、库和可视化模型。
如果要组织大量的实施元素,那么子系统就有用了。
|
集成构建计划
|
定义组件的实施顺序、集成系统时要创建的工作版本以及它们的评估方式。
|
可选。
如果需要计划集成,则建议使用。只有在集成不重要时才省略它。
|
决定执行单元测试的程度以及代码覆盖的级别,它的规模可从非正式的一直到 100% 的代码覆盖。 此规模在 测试计划中有所描述。
单元测试覆盖级别常常受集成和系统测试人员(代码移交给这些测试人员)需要的驱动。系统测试人员的工作取决于代码的质量。 如果代码的缺陷过多,集成和系统测试人员就会过于频繁地将代码发回给实施者。
这是开发流程欠佳的信号,其解决方案可能就是要求实施者进行更彻底的单元测试。
当然,您不能期望经过单元测试的代码完全没有缺陷。不过,您需要在单元测试和质量之间找到一个“稳健的”平衡。
单元测试覆盖的级别在不同阶段之间也可能不同。即使是在构造和移交阶段需要 100% 代码覆盖的安全关键项目,通常在精化阶段也不需要这样,因为在该阶段有许多类只是部分实施。
决定代码的复审程度。
代码复审的优点有:
-
强迫和鼓励在项目中使用共同的编码风格。代码复审是一种使项目成员遵循编程指南的有效方式。为确保这一点,复审所有作者和实施者的结果比复审所有源代码文件更显重要。
-
查找自动化测试未能发现的错误。代码复审可发现在测试中未遇到的错误。
-
在个人之间共享知识,以及将知识从更有经验的人传递到经验较少的人。
代码复审的缺点有:
-
它会耗费时间和资源。
-
如果执行不当,则可能缺乏效率。存在这样一种危险:即认为之所以进行代码复审,“是因为我们必须这样做”,而不是将其作为自动测试的有效补充。
关于代码复审的更多信息,另请参阅任务:复审代码。
代码复审对项目有着重要的意义。所有开始度量代码复审相关错误和维护问题级别的项目,均称它们因为复审而提高了绩效。 然而,在许多组织中,代码复审却由于以下几个原因而很难“展开”:
-
未收集足够数据来验证代码复审是否实际起作用。
-
收集的数据过多。
-
实施者对他们的代码的防护意识过强。
-
复审陷入形式上的困境。
-
管理复审事宜耗费过多的工作。
请记住以下几点,以尽可能充分利用代码复审:
-
只收集适量的数据。
-
度量复审的成绩,并显示结果。
-
以“简洁”的方式使用复审。
关于复审级别的更多信息,请参阅指南:复审级别。
|