小组软件开发过程8.

《小组软件开发过程8.》由会员分享，可在线阅读，更多相关《小组软件开发过程8.（50页珍藏版）》请在金锄头文库上搜索。

1、第八章 产品实现 n本章描述了实现过程，我们从讨论设计完成 标准、实现标准、实现策略以及复核和检查 开始。然后我们依据IMP1和IMPn草案一步 步地描述TSPi实现过程。 81 设计完成标准 n在开始实现之前，检查你是否真正完成了总 体设计。对大的系统而言，总体设计常常要 求几个阶段。在第一层次，你将系统划分为 子系统，部件或模块。你应该采用第七章描 述的 DES1或 DESn过程的步骤来做这件工 作。最后，你应该对每个子系统、部件或模 块加上外部详细说明，还应有为系统所做的 最高层次的详细设计。 811 设计的层次 n如果这些子系统相当大，应对每个子系统或部件重 复总体设计过程。而且，你最

2、后应有每个子系统部 件的外部规范，还应有为子系统成员所做的最高层 次详细设计。依据系统的大小，你可能要反复进行 这个过程。最后你会得到关于系统最低层原子模块 的外部规范。那时就是你从总体设计进入实现之时 。对于真正的大系统，一个连续的系统层次可能是 ： n .系统， n 子系统， n .产品， n 部件， n 模块。 n 继续这个重复设计过程，直到你得到对系统真正 的基本元素的外部规范为止。这些元素小到可以直 接实现，而且它们的大小通常为150或更少的LOC。 尽管这些模块可能包含更低层的目标或程序，但这 些附属的程序不是相当小，就是已被开发，或者是 复用部分，或者是可获得的库功能。 n 达到

3、最低层次的详细说明可能要付出大量的努 力，但除非你已经准备好进入实现阶段，你应该继 续重复DES1和DESn草案。然而，对于大的系统，你 有时必须在结束其它部分的设计之前实现某些产品 元素。 812 并行的实现 n如果有一个足够大的开发小组，你就能在完 成部件的外部规范之后，立刻开始实现这些 。尽管在你定义好最高层次所有规范之前， 开始实现系统的任何部分都是有风险的，但 你靠将大系统分割为部件，然后在成员的外 部规范完成且检查之后实现它们，这能最小 化风险。如果开发周期短这一点很重要，那 么这种方式将能节省大量时间。 82 实现标准 n 关于标准的重要性可以谈出相当多的东西，但实 际开发和使用

4、标准不应该占大量的时间。在工程初 期用少量时间定义标准，以后就能节省大量的时间 。首先，当一个小组对需要的标准意见一致后，你 就安排一两名小组成员来开发这个草案。然后小组 才能有效地讨论该草案，并对他们将使用的具体标 准的内容取得一致。质量进度监督经理领导小组的 制定这些标准的活动。 n 实现标准加入并扩宽了设计阶段定义的标准。 在外几段我们探讨这些标准问题： n标准的复核 n .命名、界面和消息标准： n 编码标准； n 大小标准； n 缺陷标推； n 预防缺陷。 尽管通常不被认为预防缺陷是一个标准问 题，但它与缺陷标准联系紧密，故于此处讨 论。 821 标准的复核 n注意实用性。如果一个被

5、提出的标准看来有用， 你就使用它，并在你熟悉它之后改进它。不要尝 试第一次就产生一个完美的标准。你会很容易地 在讨论抽象的提议时浪费大量时间。如果你以一 个合理的草案为起点，并在尝试着使用它们之后 更新它们，你将用较少的时间产生较好的标准。 n 复核在设计阶段完成的命名、界面和信息标 准，以确保它们仍是合理的并被合适地使用着。 还要检查可复用程序的列表是否完整以及所有小 组成员是否正在使用它。 n下一步，复核命名词汇表来确保每个人都对 同样的条款使用了同样的名字，以及整个系 统范围的名字都被记录在词汇表中。还要检 查部件和子元素名字，并复核被共用的变量 、 参数和文件名是否一致。还要检查界面和

6、消 息来确保所有系统内外部界面和消息已被定 义，被记录在词汇表中，并为所有的小组成 员了解和使用。 822 编码标准 n如果你计划使用你在PSP课程中使用的语言，你可能 使用同样的编码标准。但要确认整个小组都同意使 用同样的标准。一个共同的编码标准确保小组的所 有代码看来都一样。这种一致性将使代码检查更容 易迅速且更有效。 n 一个被精心构造的编码标准还定义了注释约定 。好的注释约定可以加快代码的复核，并在以后的 开发周期中使升级更容易。一个公共的编码标准还 使小组成员间的代码共享更容易。当一个程序看来 像你写的代码，并且它使用了同样的惯例和注释约 定时，你很可能考虑在你的程序中复用它。这样的

7、 复用常常能节省大量的设计和实现时间。 823 大小标准 n需要一个共同的小组标准。如果你对设计阶段的标 准不同意，现在就做一个标准。 n 除了LOC以外，绝大多数的项目产生几种产品， 如SRS和SDS文档即是一例。在TSPi中，我们建议你 使用页数来度量文档大小。下面是一些可能需要度 量大小的产品元素： n 需求文档（SRS）； n 总体设计文档（SDS）； n 细节设计； n 屏幕和报告； n 数据库； n 信息； n 测试草案和测试材料。 n 对于需求，你可以使用文章页数、段落数或 “shall”来计数。“shall” 定义了计划的产品被 要求具有的功能。一个shall说明通常用于代表一

8、个 所期望的功能。举例来说，“4M一当某行代码被 删除后，在程序中该行被删掉的地方要用注释来保 存被删掉的那一行。” n 总体设计的最简单度量方式是样板的页数，文 本行数或使用场合。对于细节设计而言，伪代码行 数是一种度量方式。对于小的程序，我们使用LOC来 估计。然后当有了实际的LOC数时，我们使用实际的 LOC来度量细节设计产品的大小。 8.2.4度量其他类型产品的大小 n度量剩余的部分是比较困难的。如果你的小组正在 一学期的课程中实现一个相对小的产品，可能除了 文本页数和LOC外，你不需要考虑其它任何大小的度 量。你应集中精力来建立这个产品。 n 如果你仍需要附加的度量，请考虑两个问题：

9、 第一，时间是否用在了代表整个工程工作的重要部 分的产品类型上？如果不是这样，那么工程从度量 得到的收益很小或是没有。相关的工程工作可能是 如此小以致不能判断有关大小的估计和计划。因为 你想要度量大小的主要原因是帮助估计和跟踪工作 ，当某种产品类型的工作仅是总工作中的一小部分 时，你没有必要知道有关大小的估计，仅需要估计 你期望这项工作花的时间。 n 假定一种产品类型代表了工作的重要部分，那么你需 要一种与开发这个产品所用时间相关的大小度量。如果 你能完成那样的一种度量，那么就足够了。如果你不能 ，你唯一的选择是使用产品元素的数量来作为大小估计 。例如对于屏幕，就使用屏幕数及开发一个屏幕的平均

10、 经验时间来估计。 n 对于相当多的数据，你能使用PSP中用于目标LOC上 的同样的过程。将这些屏幕数据划分为一些类。在PSP 中使用的方法是将数据分成特小（VS），小（S），中 （M），大（L），以及特大（VL）这些类别。将你的经 验数据划分为这几类，并为每一类产生一个平均开发时 间。如果还有很多数据，你可以将这些产品数据再划分 一些类型，如数据输入，菜单选择等。 n 然后在计划时，你估计需要多少屏幕，而且判 断进入这五个类别的各有多少。对于任何其它的 大小度量，你能使用同样的方法。要了解怎样以 这种方式估计大小及使用大小数据，请参考软 件工程规则。 82.5 缺陷标准 n标准的PSP缺陷类

11、型对你的需要来说应当是足够了。然 而，PSP并没有讨论测试资料的缺陷。 n 在你创造任何新的缺陷类型之前，请考虑以下几点 。第一，存在无穷多种方式来定义缺陷类型。因此，你 和你的小组成员可能要花时间来争论你所偏好的类型。 n 第二，将缺陷归为一些类型的目的是帮助分析、改 进开发过程。尽管缺陷类型帮助你将大量的缺陷数据分 类，但你一定要仔细检查关于某个特定缺陷的报告来改 进过程。做这件事的共同步骤是首先分析你的数据来确 认关键的类型。 n 对单个缺陷类型（例，类80的功能缺陷），在专门 的类80缺陷报告中寻找有关细节来看哪种类型导致了 大部分的问题。当你确定了一个关键的问题区域（例如 ，只有一个

12、被遗漏）， n要确定如何在设计和编码复核中发现这些缺陷。 然而，你可能将类80分解成了多个子类，那么做 这就是困难的。原因在于你将总有一个其它类别 包含了大多数情形。如果你有一个足够好的分解 来避免这个问题，你将有一个非常大的缺陷类型 列表，而这个列表只能用于研究，毫无实用价值 。 n第三，缺陷类型标准仅当它们很少时才有用。在标准中 的类型越多，你在为缺陷选择类型时犯的缺陷就越多， 而且分类与记录每个缺陷所花的时间也越多。这说明你 仅需要在有足够多的一种新类型的缺陷数据时，才对 PSP标准有所添加。 n 许多人混淆缺陷原因和缺陷类型，他们认为缺陷类 型是不完整的需求，贫乏的应用知识，设计的误解

13、或语 言上无经验。这些不是缺陷类型，而是缺陷原因。举例 来说，绝大多数早期没有纠正的需求缺陷导致了最终产 品的功能缺陷。那样的缺陷是在需求分析阶段产生，通 常是由没很好定义的需求导致的，但缺陷类型通常是数 据（70）、功能（80）或系统（90）。 826 预防缺陷 n缺陷原因的理解有助于预防缺陷。将缺陷原因 分类是困难的。不得不返回去看专门的缺陷报 告来理解这些问题，然后找出如何预防它们。 此处的困难是普遍性的。为限制原因类型的数 目，这些类型必须是非常普通的，但你不能为 普通的原因创造出预防措施。 n建议你从以下四类开始： n 教育：学习有关语言、环境和应用的更 多知识； n 交流：修正这个

14、过程； n 事务处理：使用更好的工具； n 监督：改善你的过程，使用更好的方法 。 n尽管在缺陷预防上有很多种用来分析缺陷原因的方法 ，但笔者发现以下方式是最有效的。 n 选择出那些看来引起绝大多数麻烦的缺陷类型 。这些缺陷可能浪费了绝大多数的测试时间，或者是 很难诊治和修正的，或者是非常令人厌烦的。 n 检查这种类型的一些缺陷来确定专门的缺陷原 因，并决定哪些原因应被强调。 n 当你看到一个你认为自己能避免的缺陷时，你 要做出一个过程改变来避免它。 n 假如这种方式是有效的，开始寻找下一个缺陷 类别，并以同样的方式处理它。 n缺陷预防的关键在于寻找可以预防缺陷的改变。然 后再在你的过程中将这

15、些改变组合起来。下一步， 跟踪执行来看这个变化是怎样起作用的。如果这些 缺陷类型仍存在，找出先前的变化不起作用的原因 ，然后再一次进行调整。 n 当你知道了缺陷的原因时，在LOGD表的注释里 记上它。但如果你以同样的标准混淆了缺陷类型和 缺陷原因，你的数据将是无用的。原因在于同样的 缺陷类型可能出现在几个不同的地方，这使你不能 靠频率来排列缺陷类型。 83 实现策略 n实现策略通常应和设计策略保持一致，也就是 说，你应与设计它们的方式保持一致地实现程 序。为避免实现和测试的问题，我建议你考虑 以下三个论题： n .复核； n .复用： n 测试。 831 实现策略：复核 n在设计时，应从大局入

16、手逐渐深入到细节。但在复核时，应 考虑从细节入手逐渐拓宽到大局。笔者发现的最有效的策略 是从底部开始复核。首先，复核所有没有从属部分的最低层 次的对象。当你确信这些原子对象是按照它们的外部说明一 致时，进入下一个高一级的层次。然后，当你在下一个高一 级的层次复核碰到这些对象时，你能信任它们，并且不必去 再一次复核它们。 n 为遵循从底部入手策略，实现同样首先应从最低层次的 对象做起，然后逐渐移向高一点的层次。这通常是确认最低 层次对象规范中的问题的最快方式。靠早点发现这些详细说 明中的问题，你能在它们被广泛实现前修正它们。这项工作 还能节省大量的测试和返工时间。因为最低层的原子对象最 容易被复用，故一个从底部入手的实现策略也使复用更方便 。 832 实现策略：复用 n靠遵循一些简单的实现惯例，你能使程序的复用更容易。举例 来说，对每个源程序采用标准注释题头。这个题头应集中提供 所有重要的使用信息，帮助潜在