小组软件开发过程8.ppt

第八章 产品实现 本章描述了实现过程，我们从讨论设计完成标准、实现标准、实现策略以及复核和检查开始。然后我们依据IMP1和IMPn草案一步步地描述TSPi实现过程。 8．1 设计完成标准 在开始实现之前，检查你是否真正完成了总体设计。对大的系统而言，总体设计常常要求几个阶段。在第一层次，你将系统划分为子系统，部件或模块。你应该采用第七章描述的 DES1或 DESn过程的步骤来做这件工作。最后，你应该对每个子系统、部件或模块加上外部详细说明，还应有为系统所做的最高层次的详细设计。 8．1．1 设计的层次 如果这些子系统相当大，应对每个子系统或部件重复总体设计过程。而且，你最后应有每个子系统部件的外部规范，还应有为子系统成员所做的最高层次详细设计。依据系统的大小，你可能要反复进行这个过程。最后你会得到关于系统最低层原子模块的外部规范。那时就是你从总体设计进入实现之时。对于真正的大系统，一个连续的系统层次可能是： .系统， ．子系统， .产品， ．部件， ．模块。 继续这个重复设计过程，直到你得到对系统真正的基本元素的外部规范为止。这些元素小到可以直接实现，而且它们的大小通常为150或更少的LOC。尽管这些模块可能包含更低层的目标或程序，但这些附属的程序不是相当小，就是已被开发，或者是复用部分，或者是可获得的库功能。 达到最低层次的详细说明可能要付出大量的努力，但除非你已经准备好进入实现阶段，你应该继续重复DES1和DESn草案。然而，对于大的系统，你有时必须在结束其它部分的设计之前实现某些产品元素。 8．1．2 并行的实现 如果有一个足够大的开发小组，你就能在完成部件的外部规范之后，立刻开始实现这些。尽管在你定义好最高层次所有规范之前，开始实现系统的任何部分都是有风险的，但你靠将大系统分割为部件，然后在成员的外部规范完成且检查之后实现它们，这能最小化风险。如果开发周期短这一点很重要，那么这种方式将能节省大量时间。 8．2 实现标准 关于标准的重要性可以谈出相当多的东西，但实际开发和使用标准不应该占大量的时间。在工程初期用少量时间定义标准，以后就能节省大量的时间。首先，当一个小组对需要的标准意见一致后，你就安排一两名小组成员来开发这个草案。然后小组才能有效地讨论该草案，并对他们将使用的具体标准的内容取得一致。质量进度监督经理领导小组的制定这些标准的活动。 实现标准加入并扩宽了设计阶段定义的标准。在外几段我们探讨这些标准问题： ．标准的复核 .命名、界面和消息标准： ．编码标准； ．大小标准； ．缺陷标推； ．预防缺陷。 尽管通常不被认为预防缺陷是一个标准问题，但它与缺陷标准联系紧密，故于此处讨论。 8．2．1 标准的复核 注意实用性。如果一个被提出的标准看来有用，你就使用它，并在你熟悉它之后改进它。不要尝试第一次就产生一个完美的标准。你会很容易地在讨论抽象的提议时浪费大量时间。如果你以一个合理的草案为起点，并在尝试着使用它们之后更新它们，你将用较少的时间产生较好的标准。 复核在设计阶段完成的命名、界面和信息标准，以确保它们仍是合理的并被合适地使用着。还要检查可复用程序的列表是否完整以及所有小组成员是否正在使用它。 下一步，复核命名词汇表来确保每个人都对同样的条款使用了同样的名字，以及整个系统范围的名字都被记录在词汇表中。还要检查部件和子元素名字，并复核被共用的变量、 参数和文件名是否一致。还要检查界面和消息来确保所有系统内外部界面和消息已被定义，被记录在词汇表中，并为所有的小组成员了解和使用。 8．2．2 编码标准 如果你计划使用你在PSP课程中使用的语言，你可能使用同样的编码标准。但要确认整个小组都同意使用同样的标准。一个共同的编码标准确保小组的所有代码看来都一样。这种一致性将使代码检查更容易迅速且更有效。 一个被精心构造的编码标准还定义了注释约定。好的注释约定可以加快代码的复核，并在以后的开发周期中使升级更容易。一个公共的编码标准还使小组成员间的代码共享更容易。当一个程序看来像你写的代码，并且它使用了同样的惯例和注释约定时，你很可能考虑在你的程序中复用它。这样的复用常常能节省大量的设计和实现时间。。 8．2．3 大小标准 需要一个共同的小组标准。如果你对设计阶段的标准不同意，现在就做一个标准。 除了LOC以外，绝大多数的项目产生几种产品，如SRS和SDS文档即是一例。在TSPi中，我们建议你使用页数来度量文档大小。下面是一些可能需要度量大小的产品元素： ．需求文档（SRS）； ．总体设计文档（SDS）； ．细节设计； ．屏幕和报告； ．数